Date: Fri, 16 Sep 2011 20:45:30 +
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
};
This adds a new function intel_drm_get_valid_edid, which is used instead
of drm_get_edid within the i915 driver.
It does a similar check to the one in previous patch, but it is limited to
i915 driver.
The check is similar to the first part of EDID discovery performed by the
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
(Resending with small improvements - also sending to dri-devel for feedback).
This is the the forth iteration of potential fixes for slow edid detection
issues over non-existent outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions
were posted to the bug and were
https://bugs.freedesktop.org/show_bug.cgi?id=41579
Summary: R300 Segfaults when using mupen64plus
Product: Mesa
Version: 7.11
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority:
On 10/07/2011 03:38 PM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
In any case, I'm not saying fences is the
On 10/07/2011 03:24 PM, Alex Deucher wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
In any case, I'm not saying fences is the
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 272 +++
1 files changed, 215 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
Contexts, surfaces and streams allocate persistent kernel memory as the
direct result of user-space requests. Make sure this memory is
accounted as graphics memory, to avoid DOS vulnerabilities.
Also take the TTM read lock around resource creation to block
switched-out dri clients from allocating
Two fixes on top of previous patches.
The first removes a DOS vulnerabilty.
The second one implements some screen object fixes.
From: Alex Deucher
When force == false, we don't do load detection in the connector
detect functions. Unforunately, we also return the previous
connector state so we never get disconnect events for DVI-I, DVI-A,
or VGA. Save whether we detected the monitor via load
From: Alex Deucher
DVI-D and HDMI-A are digital only, so there's no need to
attempt analog load detect. Also, skip bail before the
!force check, or we fail to get a disconnect events.
The next patches in the series attempt to fix disconnect
events for connectors with
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52097|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52096|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #3 from Robert Nelson 2011-10-07
11:26:21 PDT ---
Created an attachment (id=52097)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52097)
lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52095|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #2 from Robert Nelson 2011-10-07
11:26:04 PDT ---
Created an attachment (id=52096)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52096)
Xorg log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #1 from Robert Nelson 2011-10-07
11:25:48 PDT ---
Created an attachment (id=52095)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52095)
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Robert Nelson changed:
What|Removed |Added
Summary|[r600 KMS] Asus A35T|[r600 KMS] Asus A53T
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Summary: [r600 KMS] Asus A35T A4-3400
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #8 from Alex Deucher 2011-10-07 11:16:14 PDT
---
(In reply to comment #6)
> Results:
>
> DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after
> the
> connector has been used for VGA, but I get an event
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Alex Deucher changed:
What|Removed |Added
CC||qjn at gmx.de
--- Comment #7 from Alex
https://bugs.freedesktop.org/show_bug.cgi?id=40252
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Ol??k wrote:
>
> +enum ttm_buffer_usage {
> +TTM_USAGE_READ = 1,
> +TTM_USAGE_WRITE = 2,
> +TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
> +};
>
>
Please don't use enums for bit operations.
#define
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #6 from Simon Farnsworth
2011-10-07 10:53:04 PDT ---
I've applied both patches, and am testing on a machine with DVI-I and
DisplayPort.
Test sequence:
1) Boot system with no outputs connected.
2) Attach a DVI-D monitor, then
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #5 from Alex Deucher 2011-10-07 10:35:43 PDT
---
Created an attachment (id=52094)
View: https://bugs.freedesktop.org/attachment.cgi?id=52094
Review: https://bugs.freedesktop.org/review?bug=41561=52094
2/2: fix the mixed and
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #4 from Alex Deucher 2011-10-07 10:35:06 PDT
---
Created an attachment (id=52093)
View: https://bugs.freedesktop.org/attachment.cgi?id=52093
Review: https://bugs.freedesktop.org/review?bug=41561=52093
1/2: fix the digital only
On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom
wrote:
> On 10/07/2011 03:24 PM, Alex Deucher wrote:
>>
>> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>>
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
On 10/07/2011 12:42 AM, Marek Ol??k wrote:
> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
> wrote:
>
>> In any case, I'm not saying fences is the best way to flush but since the bo
>> code assumes that signaling a sync object means "make the buffer contents
>> available for CPU read /
On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> ?wrote:
>>>
In any case, I'm not saying fences is the best way to
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #3 from Simon Farnsworth
2011-10-07 09:26:08 PDT ---
So, I think I see the proximate cause of the bug, but not the reason for it:
In radeon_dvi_detect at radeon_connectors.c:962, I see:
if (!force) {
ret =
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #2 from Simon Farnsworth
2011-10-07 09:07:40 PDT ---
drm_helper_hpd_irq_event() isn't generating uevents, because connector->status
is not being updated somewhere, and is remaining at connector_status_connected,
when it should be
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #1 from Alex Deucher 2011-10-07 08:59:22 PDT
---
If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting
scheduled. From there drm_helper_hpd_irq_event() gets called which actually
generates the uevent.
--
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Simon Farnsworth changed:
What|Removed |Added
Summary|Hotplug detect does not |[r600 KMS] Hotplug detect
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Summary: Hotplug detect does not work for HDMI monitor on
Fusion E-350 board
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom wrote:
> In any case, I'm not saying fences is the best way to flush but since the bo
> code assumes that signaling a sync object means "make the buffer contents
> available for CPU read / write", it's usually a good way to do it; there's
> even a
Commit 9b9fe724 accidentally used RADEON_GPIO_EN_* where
RADEON_GPIO_MASK_* was intended. This caused improper initialization
of I2C buses, mostly visible when setting i2c_algo_bit.bit_test=1.
Using the right constants fixes the problem.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Alex
-Original Message-
From: Jean Delvare [mailto:jdelv...@suse.de]
Sent: Thursday, October 06, 2011 12:16 PM
To: David Airlie
Cc: Deucher, Alexander; dri-devel@lists.freedesktop.org; Jerome Glisse
Subject: [PATCH] drm/radeon/kms: Fix I2C mask definitions
Commit 9b9fe724 accidentally
Keith Packard wrote:
On Thu, 6 Oct 2011 10:12:57 -0700, Linus
Torvaldstorva...@linux-foundation.org wrote:
[drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH
Thanks. I've got a patch series that fixes a pile of refclk bugs which
is still out for review that should fix this.
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org wrote:
In any case, I'm not saying fences is the best way to flush but since the bo
code assumes that signaling a sync object means make the buffer contents
available for CPU read
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum ttm_buffer_usage {
+TTM_USAGE_READ = 1,
+TTM_USAGE_WRITE = 2,
+TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
+};
Please don't use enums for bit operations.
#define
Two fixes on top of previous patches.
The first removes a DOS vulnerabilty.
The second one implements some screen object fixes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Contexts, surfaces and streams allocate persistent kernel memory as the
direct result of user-space requests. Make sure this memory is
accounted as graphics memory, to avoid DOS vulnerabilities.
Also take the TTM read lock around resource creation to block
switched-out dri clients from allocating
From: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 272 +++
1 files changed, 215 insertions(+), 57 deletions(-)
diff --git
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying fences is the best way to flush but since the
bo
code assumes that
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying fences is the best way to flush but since the
bo
code assumes that
On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not
On 10/07/2011 03:24 PM, Alex Deucher wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying fences
On 10/07/2011 03:38 PM, Jerome Glisse wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstromtho...@shipmail.org
wrote:
In any case, I'm not saying
On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 10/07/2011 03:24 PM, Alex Deucher wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstromtho...@shipmail.org
wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Summary: Hotplug detect does not work for HDMI monitor on
Fusion E-350 board
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Simon Farnsworth simon.farnswo...@onelan.co.uk changed:
What|Removed |Added
Summary|Hotplug detect does not |[r600
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #1 from Alex Deucher ag...@yahoo.com 2011-10-07 08:59:22 PDT ---
If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting
scheduled. From there drm_helper_hpd_irq_event() gets called which actually
generates
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #2 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-10-07
09:07:40 PDT ---
drm_helper_hpd_irq_event() isn't generating uevents, because connector-status
is not being updated somewhere, and is remaining at
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #6 from Simon Farnsworth simon.farnswo...@onelan.co.uk 2011-10-07
10:53:04 PDT ---
I've applied both patches, and am testing on a machine with DVI-I and
DisplayPort.
Test sequence:
1) Boot system with no outputs connected.
2)
https://bugs.freedesktop.org/show_bug.cgi?id=40252
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
CC||q...@gmx.de
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #8 from Alex Deucher ag...@yahoo.com 2011-10-07 11:16:14 PDT ---
(In reply to comment #6)
Results:
DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after
the
connector has been used for VGA, but I get an
From: Alex Deucher alexander.deuc...@amd.com
DVI-D and HDMI-A are digital only, so there's no need to
attempt analog load detect. Also, skip bail before the
!force check, or we fail to get a disconnect events.
The next patches in the series attempt to fix disconnect
events for connectors with
From: Alex Deucher alexander.deuc...@amd.com
When force == false, we don't do load detection in the connector
detect functions. Unforunately, we also return the previous
connector state so we never get disconnect events for DVI-I, DVI-A,
or VGA. Save whether we detected the monitor via load
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Summary: [r600 KMS] Asus A35T A4-3400
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Robert Nelson robertcnel...@gmail.com changed:
What|Removed |Added
Summary|[r600 KMS] Asus A35T|[r600 KMS] Asus
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #1 from Robert Nelson robertcnel...@gmail.com 2011-10-07 11:25:48
PDT ---
Created an attachment (id=52095)
-- (https://bugs.freedesktop.org/attachment.cgi?id=52095)
dmesg
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #2 from Robert Nelson robertcnel...@gmail.com 2011-10-07 11:26:04
PDT ---
Created an attachment (id=52096)
-- (https://bugs.freedesktop.org/attachment.cgi?id=52096)
Xorg log
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #52095|application/octet-stream|text/plain
mime
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #3 from Robert Nelson robertcnel...@gmail.com 2011-10-07 11:26:21
PDT ---
Created an attachment (id=52097)
-- (https://bugs.freedesktop.org/attachment.cgi?id=52097)
lspci
--
Configure bugmail:
Date: Fri, 16 Sep 2011 20:45:30 +
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
};
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse j.gli...@gmail.com wrote:
I should have look at the patch long ago ... anyway i think a better
approach would be to expose fence id as 64bits unsigned to each
userspace client. I was thinking of mapping a page readonly (same page
as the one gpu
(Resending with small improvements - also sending to dri-devel for feedback).
This is the the forth iteration of potential fixes for slow edid detection
issues over non-existent outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions
were posted to the bug and were
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom tho...@shipmail.org wrote:
OK. First I think we need to make a distinction: bo sync objects vs driver
fences. The bo sync obj api is there to strictly provide functionality that
the ttm bo subsystem is using, and that follows a simple set of
This adds a new function intel_drm_get_valid_edid, which is used instead
of drm_get_edid within the i915 driver.
It does a similar check to the one in previous patch, but it is limited to
i915 driver.
The check is similar to the first part of EDID discovery performed by the
https://bugs.freedesktop.org/show_bug.cgi?id=41579
Summary: R300 Segfaults when using mupen64plus
Product: Mesa
Version: 7.11
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority:
75 matches
Mail list logo