https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #43 from Ilija Hadzic
2011-10-26 16:57:22 PDT ---
(In reply to comment #34)
> (In reply to comment #33)
>
> I booted into kde 4.7.0 with a 3.1.0-rc2 kernel and then I did:
> echo 7 > /sys/module/drm/parameters/debug
> and then I lau
On Wed, Oct 26, 2011 at 11:11:14AM -0500, Ilija Hadzic wrote:
> On Wed, 26 Oct 2011, Daniel Vetter wrote:
> >
> >Just to check before I dig into reviewing this: Have you check all the
> >other users of these data structure that these functions touch whether
> >they don't accidentally rely on the gl
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #10 from Mike Lothian 2011-10-26 13:16:58
PDT ---
I was wondering what actions I could take next
Would it be possible to have the switcheroo code detect that the laptop is
muxless and disable the radeon card from the start?
--
Con
On Wed, 26 Oct 2011 15:06:24 -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-responding bus repeatedly until we
> finally timeout after 15 attempts. We can do this by catching the -ENXIO
> error, provided by i2c_algo_bit:bit_doAddress call.
>
> Within the bit_doAddress we alr
On Wed, 26 Oct 2011, Michel [ISO-8859-1] D?nzer wrote:
>
> Does it really need drm_global_mutex at all, as opposed to e.g.
> dev->struct_mutex?
>
>
It doesn't. Actually, it would probably suffice to have a mutex that is
one-per-CRTC, because vlbank waits on different CRTCs don't step on each
https://bugs.freedesktop.org/show_bug.cgi?id=42297
Bug #: 42297
Summary: [r600g] Segfaults and failed assertions with piglit
test fbo-generatemipmap-formats
Classification: Unclassified
Product: Mesa
Version: git
Platf
On Wed, 26 Oct 2011, Daniel Vetter wrote:
>
> While you mess around with this code, please use the standard linux
> wait_event_* infrastructure.
Right now the order of entering the queue is guaranteed to be the same as
the order of entering the ioctl, which reflects the order of progressing
v
https://bugs.freedesktop.org/show_bug.cgi?id=41086
Harald Judt changed:
What|Removed |Added
Summary|[r600] Screen update|[r600] Screen update
|pr
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #43 from Ilija Hadzic 2011-10-26
16:57:22 PDT ---
(In reply to comment #34)
> (In reply to comment #33)
>
> I booted into kde 4.7.0 with a 3.1.0-rc2 kernel and then I did:
> echo 7 > /sys/module/drm/parameters/debug
> and then I lau
From: Alex Deucher
DP MST is DP multi-stream support, part of DP 1.2.
v2: switch to a helper macro as suggested by Michel.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |5 +++--
drivers/gpu/drm/radeon/radeon_encoders.c | 20 +---
drivers/gpu/d
On Wed, Oct 26, 2011 at 3:43 PM, Ilija Hadzic
wrote:
> radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
> hard code the loop to 6 which happens to be the current maximum
> number of crtcs and hpd pins; if one day an ASIC with more crtcs
> (or hpd pins) comes out, this is a trou
On Wed, 26 Oct 2011, Michel [ISO-8859-1] D�nzer wrote:
Does it really need drm_global_mutex at all, as opposed to e.g.
dev->struct_mutex?
It doesn't. Actually, it would probably suffice to have a mutex that is
one-per-CRTC, because vlbank waits on different CRTCs don't step on each
othe
radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
hard code the loop to 6 which happens to be the current maximum
number of crtcs and hpd pins; if one day an ASIC with more crtcs
(or hpd pins) comes out, this is a trouble waiting to happen.
introduce constants for maximum CRTC c
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us tha
On Wed, 26 Oct 2011, Daniel Vetter wrote:
While you mess around with this code, please use the standard linux
wait_event_* infrastructure.
Right now the order of entering the queue is guaranteed to be the same as
the order of entering the ioctl, which reflects the order of progressing
vbl
On Tue, Oct 25, 2011 at 01:35, Ilija Hadzic
wrote:
> On Mon, 24 Oct 2011, Michael Witten wrote:
>
>> This patch has not yet been applied. What's wrong?
>
> Maybe you are looking at the wrong branch, but I see it in drm-next (it has
> been there since Oct 10)
>
> http://cgit.freedesktop.org/~airli
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us tha
On Wed, 26 Oct 2011, Alex Deucher wrote:
>
> This is actually not quite right. The number of HPD (Hot Plug Detect)
> pins is not equal to the number of crtcs. Radeons have supported 6
> HPD pins long before we supported 6 crtcs (e.g., cards with more
> connectors than crtcs). The logic should
10/25/2011 06:46 PM, Jesse Barnes ? ?:
[snip]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8020798..d7f03aa 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -44,6 +44,7 @@ struct drm_framebuffer;
> #define DRM_MODE_OBJECT_PROPERTY 0xb0b0b0b0
>
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #10 from Mike Lothian 2011-10-26 13:16:58 PDT
---
I was wondering what actions I could take next
Would it be possible to have the switcheroo code detect that the laptop is
muxless and disable the radeon card from the start?
--
Con
https://bugs.freedesktop.org/show_bug.cgi?id=42175
Michel D?nzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
From: Alex Deucher
DP MST is DP multi-stream support, part of DP 1.2.
v2: switch to a helper macro as suggested by Michel.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |5 +++--
drivers/gpu/drm/radeon/radeon_encoders.c | 20 +---
drivers/gpu/d
On Wed, Oct 26, 2011 at 11:11:14AM -0500, Ilija Hadzic wrote:
> On Wed, 26 Oct 2011, Daniel Vetter wrote:
> >
> >Just to check before I dig into reviewing this: Have you check all the
> >other users of these data structure that these functions touch whether
> >they don't accidentally rely on the gl
On Wed, Oct 26, 2011 at 3:43 PM, Ilija Hadzic
wrote:
> radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
> hard code the loop to 6 which happens to be the current maximum
> number of crtcs and hpd pins; if one day an ASIC with more crtcs
> (or hpd pins) comes out, this is a trou
On Wed, 26 Oct 2011, Alex Deucher wrote:
This is actually not quite right. The number of HPD (Hot Plug Detect)
pins is not equal to the number of crtcs. Radeons have supported 6
HPD pins long before we supported 6 crtcs (e.g., cards with more
connectors than crtcs). The logic should probab
radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
hard code the loop to 6 which happens to be the current maximum
number of crtcs and hpd pins; if one day an ASIC with more crtcs
(or hpd pins) comes out, this is a trouble waiting to happen.
introduce constants for maximum CRTC c
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #10 from Stefan 2011-10-26 05:38:41 PDT ---
(In reply to comment #9)
> He might have an older, more buggy kernel than me.
I'm using the longterm kernel 2.6.35.14.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #9 from Marek Ol??k 2011-10-26 05:29:24 PDT
---
No, it doesn't make sense. :) He might have an older, more buggy kernel than
me. That would be the only explanation. I was working with the latest drm-fixes
branch (3.1 rc10). Anyway I
On Wed, 26 Oct 2011, Michel [ISO-8859-1] D?nzer wrote:
> On Die, 2011-10-25 at 22:40 -0400, Ilija Hadzic wrote:
>> it's better that radeon_crtc_commit and radeon_crtc_prepare call
>> crtc-specific dpms functions instead of hard-coding them to
>> radeon_crtc_dpms.
>
> Is it really better? If it's
On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> From: Jerome Glisse
>
> Cayman seems to be particularly sensitive to read cache returning
> old data after bind/unbind to GTT. Flush read cache for GTT range
> with each fences for all new hw. Should fix several rendering glitches.
> Like
>
> V2 flush w
From: Jerome Glisse
Cayman seems to be particularly sensitive to read cache returning
old data after bind/unbind to GTT. Flush read cache for GTT range
with each fences for all new hw. Should fix several rendering glitches.
Like
V2 flush whole address space
V3 also flush shader read cache
https
From: Alex Deucher
The existing function was getting too big and complex.
Break it down into a more manageable set of functions.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 340 --
1 files changed, 187 insertions(+), 153 deletions(-)
From: Alex Deucher
Use the regular logic for other bridge chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 0
From: Alex Deucher
Return the encoder id rather than a boolean. This is needed
for differentiate between multiple DP bridge chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 12 ++--
drivers/gpu/drm/radeon/atombios_dp.c |6 --
drivers/
From: Alex Deucher
The logic was messy and hard to follow.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 41 ++-
1 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/r
On Wed, Oct 26, 2011 at 11:13 AM, wrote:
> From: Jerome Glisse
>
> Cayman seems to be particularly sensitive to read cache returning
> old data after bind/unbind to GTT. Flush read cache for GTT range
> with each fences for all new hw. Should fix several rendering glitches.
> Like
>
> V2 flush w
On Wed, 26 Oct 2011, Daniel Vetter wrote:
>
> I've quickly checked current callsites of drm_fb_helper_init and I think
> you can just kill the two arguments crtc_count and max_conn_count.
It is a usable functionality (i.e. allows the driver to select which
connectors or CRTCs is fbcon allowed
From: Jerome Glisse
Cayman seems to be particularly sensitive to read cache returning
old data after bind/unbind to GTT. Flush read cache for GTT range
with each fences for all new hw. Should fix several rendering glitches.
Like
V2 flush whole address space
https://bugs.freedesktop.org/show_bug
On Wed, 26 Oct 2011, Daniel Vetter wrote:
>
> Just to check before I dig into reviewing this: Have you check all the
> other users of these data structure that these functions touch whether
> they don't accidentally rely on the global lock being taken?
I did and thought it was safe. I re-checke
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us tha
} else
> + p->relocs[i].handle = 0;
> }
> return radeon_bo_list_validate(&p->validated);
> }
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111026/322cd9c7/attachment.pgp>
On Wed, 26 Oct 2011 15:06:24 -0200, Eugeni Dodonov
wrote:
> This allows to avoid talking to a non-responding bus repeatedly until we
> finally timeout after 15 attempts. We can do this by catching the -ENXIO
> error, provided by i2c_algo_bit:bit_doAddress call.
>
> Within the bit_doAddress we al
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us tha
10/25/2011 08:13 PM, Jesse Barnes ? ?:
> On Tue, 25 Oct 2011 19:47:13 +0900
> Joonyoung Shim wrote:
>> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
>>> I've given up waiting for someone to implement support for these
>>> ioctls on another platform before they're merged, but I have
>>> received a lot of
On Wed, 26 Oct 2011, Michel [ISO-8859-1] D�nzer wrote:
On Die, 2011-10-25 at 22:40 -0400, Ilija Hadzic wrote:
it's better that radeon_crtc_commit and radeon_crtc_prepare call
crtc-specific dpms functions instead of hard-coding them to
radeon_crtc_dpms.
Is it really better? If it's always ra
On Die, 2011-10-25 at 22:20 -0400, Ilija Hadzic wrote:
> holding the drm_global_mutex in drm_wait_vblank and then
> going to sleep (via DRM_WAIT_ON) is a bad idea in general
> because it can block other processes that may issue ioctls
> that also grab drm_global_mutex. Blocking can occur until
> n
https://bugs.freedesktop.org/show_bug.cgi?id=41086
Harald Judt changed:
What|Removed |Added
Summary|[r600] Screen update|[r600] Screen update
|pr
On Tue, Oct 25, 2011 at 10:20:14PM -0400, Ilija Hadzic wrote:
> holding the drm_global_mutex in drm_wait_vblank and then
> going to sleep (via DRM_WAIT_ON) is a bad idea in general
> because it can block other processes that may issue ioctls
> that also grab drm_global_mutex. Blocking can occur unt
On Tue, Oct 25, 2011 at 10:20:13PM -0400, Ilija Hadzic wrote:
> drm_getmap, drm_getclient and drm_getstats are all
> protected with their own mutex (dev->struct_mutex)
> no need to hold global mutex; make them DRM_UNLOCKED
>
> Signed-off-by: Ilija Hadzic
Just to check before I dig into reviewing
On Tue, Oct 25, 2011 at 10:20:12PM -0400, Ilija Hadzic wrote:
> drm_getcap and drm_version ioctls only reads static data,
> there is no need to protect them with drm_global_mutex,
> so make them DRM_UNLOCKED
>
> Signed-off-by: Ilija Hadzic
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: danie
On Tue, Oct 25, 2011 at 09:57:17PM -0400, Ilija Hadzic wrote:
> The following two patches address potential problems that I
> called "troubles waiting to happen" in this note
> http://lists.freedesktop.org/archives/dri-devel/2011-October/015412.html
>
> I didn't hear anyone take on my question, s
On Tue, Oct 25, 2011 at 10:40 PM, Ilija Hadzic
wrote:
> the crtc check in radeon_get_vblank_timestamp_kms should be against
> the num_crtc field in radeon_device not against num_crtcs in drm_device
This more correct, but would there ever be a case where they are different?
Alex
Reviewed-by: Ale
On Die, 2011-10-25 at 22:40 -0400, Ilija Hadzic wrote:
> it's better that radeon_crtc_commit and radeon_crtc_prepare call
> crtc-specific dpms functions instead of hard-coding them to
> radeon_crtc_dpms.
Is it really better? If it's always radeon_crtc_dpms anyway, this
obfuscates that fact (and i
On Tue, Oct 25, 2011 at 10:40 PM, Ilija Hadzic
wrote:
> radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
> hard code the loop to 6 which happens to be the current maximum
> number of crtcs; if one day an ASIC with more crtcs comes out, this
> is a trouble waiting to happen. it'
10/25/2011 08:18 PM, Jesse Barnes ? ?:
> On Tue, 25 Oct 2011 19:53:02 +0900
> Joonyoung Shim wrote:
>>> +/**
>>> + * drm_plane - central DRM plane control structure
>>> + * @dev: DRM device this plane belongs to
>>> + * @kdev: kernel device
>>> + * @attr: kdev attributes
>>> + * @head: for list ma
On Wed, 26 Oct 2011, Daniel Vetter wrote:
I've quickly checked current callsites of drm_fb_helper_init and I think
you can just kill the two arguments crtc_count and max_conn_count.
It is a usable functionality (i.e. allows the driver to select which
connectors or CRTCs is fbcon allowed to
On Wed, 26 Oct 2011, Daniel Vetter wrote:
Just to check before I dig into reviewing this: Have you check all the
other users of these data structure that these functions touch whether
they don't accidentally rely on the global lock being taken?
I did and thought it was safe. I re-checked th
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #8 from Michel D?nzer 2011-10-26 01:47:13
PDT ---
(In reply to comment #7)
> No bisection required. The bug was fixed by this commit:
>
> "r600g: set correct tiling flags in depth info"
> http://cgit.freedesktop.org/mesa/mesa/commit
On Wed, Oct 26, 2011 at 11:41 AM, wrote:
> From: Jerome Glisse
>
> Cayman seems to be particularly sensitive to read cache returning
> old data after bind/unbind to GTT. Flush read cache for GTT range
> with each fences for all new hw. Should fix several rendering glitches.
> Like
>
> V2 flush w
From: Jerome Glisse
Cayman seems to be particularly sensitive to read cache returning
old data after bind/unbind to GTT. Flush read cache for GTT range
with each fences for all new hw. Should fix several rendering glitches.
Like
V2 flush whole address space
V3 also flush shader read cache
https
From: Alex Deucher
The existing function was getting too big and complex.
Break it down into a more manageable set of functions.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 340 --
1 files changed, 187 insertions(+), 153 deletions(-)
From: Alex Deucher
Use the regular logic for other bridge chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 0
From: Alex Deucher
Return the encoder id rather than a boolean. This is needed
for differentiate between multiple DP bridge chips.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 12 ++--
drivers/gpu/drm/radeon/atombios_dp.c |6 --
drivers/
From: Alex Deucher
The logic was messy and hard to follow.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 41 ++-
1 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/r
On Wed, Oct 26, 2011 at 11:13 AM, wrote:
> From: Jerome Glisse
>
> Cayman seems to be particularly sensitive to read cache returning
> old data after bind/unbind to GTT. Flush read cache for GTT range
> with each fences for all new hw. Should fix several rendering glitches.
> Like
>
> V2 flush w
From: Jerome Glisse
Cayman seems to be particularly sensitive to read cache returning
old data after bind/unbind to GTT. Flush read cache for GTT range
with each fences for all new hw. Should fix several rendering glitches.
Like
V2 flush whole address space
https://bugs.freedesktop.org/show_bug
On Tue, Oct 25, 2011 at 01:35, Ilija Hadzic
wrote:
> On Mon, 24 Oct 2011, Michael Witten wrote:
>
>> This patch has not yet been applied. What's wrong?
>
> Maybe you are looking at the wrong branch, but I see it in drm-next (it has
> been there since Oct 10)
>
> http://cgit.freedesktop.org/~airli
On Tue, Oct 25, 2011 at 10:40 PM, Ilija Hadzic
wrote:
> the crtc check in radeon_get_vblank_timestamp_kms should be against
> the num_crtc field in radeon_device not against num_crtcs in drm_device
This more correct, but would there ever be a case where they are different?
Alex
Reviewed-by: Ale
On Tue, Oct 25, 2011 at 10:40 PM, Ilija Hadzic
wrote:
> radeon_driver_irq_preinstall_kms and radeon_driver_irq_uninstall_kms
> hard code the loop to 6 which happens to be the current maximum
> number of crtcs; if one day an ASIC with more crtcs comes out, this
> is a trouble waiting to happen. it'
https://bugs.freedesktop.org/show_bug.cgi?id=42175
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #10 from Stefan 2011-10-26 05:38:41 PDT ---
(In reply to comment #9)
> He might have an older, more buggy kernel than me.
I'm using the longterm kernel 2.6.35.14.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #9 from Marek Olšák 2011-10-26 05:29:24 PDT ---
No, it doesn't make sense. :) He might have an older, more buggy kernel than
me. That would be the only explanation. I was working with the latest drm-fixes
branch (3.1 rc10). Anyway I t
https://bugs.freedesktop.org/show_bug.cgi?id=42175
--- Comment #8 from Michel Dänzer 2011-10-26 01:47:13 PDT
---
(In reply to comment #7)
> No bisection required. The bug was fixed by this commit:
>
> "r600g: set correct tiling flags in depth info"
> http://cgit.freedesktop.org/mesa/mesa/commit
Am Dienstag, den 25.10.2011, 17:04 +0200 schrieb Christian König:
> Only check the previusly checked relocs for
previ*o*usly
> dublicates.
du*p*licates (also in commit summary)
> Also leaving the handle uninitialized isn't such a good idea.
>
> Signed-off-by: Christian König
> ---
> drivers/
On Die, 2011-10-25 at 22:20 -0400, Ilija Hadzic wrote:
> holding the drm_global_mutex in drm_wait_vblank and then
> going to sleep (via DRM_WAIT_ON) is a bad idea in general
> because it can block other processes that may issue ioctls
> that also grab drm_global_mutex. Blocking can occur until
> n
On Tue, Oct 25, 2011 at 10:20:14PM -0400, Ilija Hadzic wrote:
> holding the drm_global_mutex in drm_wait_vblank and then
> going to sleep (via DRM_WAIT_ON) is a bad idea in general
> because it can block other processes that may issue ioctls
> that also grab drm_global_mutex. Blocking can occur unt
On Tue, Oct 25, 2011 at 10:20:13PM -0400, Ilija Hadzic wrote:
> drm_getmap, drm_getclient and drm_getstats are all
> protected with their own mutex (dev->struct_mutex)
> no need to hold global mutex; make them DRM_UNLOCKED
>
> Signed-off-by: Ilija Hadzic
Just to check before I dig into reviewing
On Tue, Oct 25, 2011 at 10:20:12PM -0400, Ilija Hadzic wrote:
> drm_getcap and drm_version ioctls only reads static data,
> there is no need to protect them with drm_global_mutex,
> so make them DRM_UNLOCKED
>
> Signed-off-by: Ilija Hadzic
Reviewed-by: Daniel Vetter
--
Daniel Vetter
Mail: dan..
On Tue, Oct 25, 2011 at 09:57:17PM -0400, Ilija Hadzic wrote:
> The following two patches address potential problems that I
> called "troubles waiting to happen" in this note
> http://lists.freedesktop.org/archives/dri-devel/2011-October/015412.html
>
> I didn't hear anyone take on my question, s
On Die, 2011-10-25 at 22:40 -0400, Ilija Hadzic wrote:
> it's better that radeon_crtc_commit and radeon_crtc_prepare call
> crtc-specific dpms functions instead of hard-coding them to
> radeon_crtc_dpms.
Is it really better? If it's always radeon_crtc_dpms anyway, this
obfuscates that fact (and i
80 matches
Mail list logo
