https://bugs.freedesktop.org/show_bug.cgi?id=28003
Michel Dänzer changed:
What|Removed |Added
CC||olva...@gmail.com
--- Comment #3 from Mi
On Don, 2010-05-06 at 18:52 +0200, Jerome Glisse wrote:
> Bring radeon up to speed with the async event synchronization for
> drmWaitVblank. See c9a9c5e02aedc1a2815877b0268f886d2640b771 for
> more information. Without this patch event never get delivered
> to userspace client.
>
> Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=28003
Chia-I Wu changed:
What|Removed |Added
CC||airl...@freedesktop.org
--- Comment #4 from
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #5 from Michel Dänzer 2010-05-07 02:18:21 PDT
---
(In reply to comment #4)
> I might not be able to find the time to work on it anytime soon.
FWIW I think it's a regression of one of your EGL reworks though.
> If no one volunteers,
On Fri, May 07, 2010 at 09:52:12AM +0200, Michel Dänzer wrote:
> On Don, 2010-05-06 at 18:52 +0200, Jerome Glisse wrote:
> > Bring radeon up to speed with the async event synchronization for
> > drmWaitVblank. See c9a9c5e02aedc1a2815877b0268f886d2640b771 for
> > more information. Without this patc
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #6 from Chia-I Wu 2010-05-07 03:11:11 PDT ---
Created an attachment (id=35484)
View: https://bugs.freedesktop.org/attachment.cgi?id=35484
Review: https://bugs.freedesktop.org/review?bug=28003&attachment=35484
work around the assert
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #7 from Chia-I Wu 2010-05-07 03:19:48 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > I might not be able to find the time to work on it anytime soon.
>
> FWIW I think it's a regression of one of your EGL reworks thou
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #8 from Chia-I Wu 2010-05-07 03:23:55 PDT ---
(In reply to comment #7)
> Ok, I've created a patch to work around the bug triggered by 968bf963. It
> restores the old (and wrong) behavior, but with comments. Could you or Scott
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Summary: [REGR] RV635 GPU lockup after enabling unmappable VRAM
V2 (KMS, Radeon)
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=28016
--- Comment #1 from Grzegorz Kowal 2010-05-07 04:42:22 PDT ---
Created an attachment (id=35493)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35493)
lspci -v output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Grzegorz Kowal changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=28016
--- Comment #2 from Grzegorz Kowal 2010-05-07 04:48:35 PDT ---
To be more precise, I bisected the commit introducing the problem. It is
6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 (drm/radeon/kms: enable use of
unmappable VRAM V2). Before it everyt
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=27822
Alex Deucher changed:
What|Removed |Added
CC||astron...@op.pl
--- Comment #10 from Alex
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #7 from fdele...@mail.cpod.fr 2010-05-07 06:28:14 PDT ---
(In reply to comment #6)
> Could you try either:
>
> - Installing the libtxc_dxtn library (should be available somewhere for your
> distro, otherwise get it here:
> http://home
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #8 from Sven Arvidsson 2010-05-07 07:02:53 PDT ---
(In reply to comment #7)
> Installing that library has solved the textures and bitmaps corruption
> problem,
> thanks! However, the GPU still hangs as mentionned in dmesg.
>
> I tri
https://bugs.freedesktop.org/show_bug.cgi?id=27868
--- Comment #4 from Bobby Weinmann 2010-05-07
07:26:32 PDT ---
Created an attachment (id=35497)
View: https://bugs.freedesktop.org/attachment.cgi?id=35497
Review: https://bugs.freedesktop.org/review?bug=27868&attachment=35497
PATCH for crash
Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
crtc id. Bump the minor version so userspace can enable conditionaly
features depend on this.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 18
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Grzegorz Kowal changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://bugs.freedesktop.org/show_bug.cgi?id=28016
--- Comment #5 from Grzegorz Kowal 2010-05-07 08:36:30 PDT ---
Created an attachment (id=35498)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35498)
dmesg output from drm-next
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.
On Fri, May 7, 2010 at 11:18 AM, Jerome Glisse wrote:
> Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
> crtc id. Bump the minor version so userspace can enable conditionaly
> features depend on this.
Just curious what we need this for? Couldn't the id be handled in the
drm vi
On Fri, May 07, 2010 at 11:40:41AM -0400, Alex Deucher wrote:
> On Fri, May 7, 2010 at 11:18 AM, Jerome Glisse wrote:
> > Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
> > crtc id. Bump the minor version so userspace can enable conditionaly
> > features depend on this.
>
> Jus
On Fri, May 7, 2010 at 11:40 AM, Alex Deucher wrote:
> On Fri, May 7, 2010 at 11:18 AM, Jerome Glisse wrote:
>> Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
>> crtc id. Bump the minor version so userspace can enable conditionaly
>> features depend on this.
>
> Just curious wh
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #9 from fdele...@mail.cpod.fr 2010-05-07 09:36:34 PDT ---
(In reply to comment #8)
Thanks for your suggestions, installing the latest git of Mesa and/or
2.6.34-rc6 solved the GPU hang problem.
Now the game plays, but some models are d
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #10 from fdele...@mail.cpod.fr 2010-05-07 09:37:29 PDT ---
Created an attachment (id=35500)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35500)
Polygons stretched / models of characters distorted (not the buildings?)
--
Confi
https://bugs.freedesktop.org/show_bug.cgi?id=3382
Kristian Høgsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #11 from Sven Arvidsson 2010-05-07 11:24:09 PDT ---
(In reply to comment #9)
> Now the game plays, but some models are distorted: the polygons extend out of
> the characters(?).
>
> Furthermore, about 1 pixel is chopped of the letter
https://bugs.freedesktop.org/show_bug.cgi?id=11093
Kristian Høgsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=20961
--- Comment #1 from Kristian Høgsberg 2010-05-07 13:12:08
PDT ---
Did this get fixed? Can you try a recent version of the stack? Thanks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=21777
Kristian Høgsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Previously we just set them to dpms off. This should save
additional power.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b
This set of patches applies on top of the code in drm-radeon-testing.
I've been testing this code pretty hard this week and it's been solid.
In addition to some fixes on top of what's in d-r-t, it also reworks
the pm code to support two basic methods:
1. "dynpm"
2. "profile"
You can select the m
voltage drop, dynamic voltage, dynamic sclk, pcie lane adjust, etc,
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/rs600.c | 14 ++
drivers/gpu/drm/radeon/rs600d.h |2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rs600.c b/d
voltage drop, dynamic voltage, dynamic sclk, pcie lane adjust, etc,
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 493b9b4..14b7541 100644
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 2eb675e..bded834 100644
--- a/drivers/gpu/drm/radeon/
From: Matthew Garrett
We need to handle the ring while we've already locked it, so split out
the allocation and commit functions in order to allow them to be used.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/radeon.h |2 ++
drivers/gpu/drm/radeon/radeon_ring.c | 27 +++
From: Matthew Garrett
GUI idle interrupts don't seem to work terribly well on r500 and earlier,
so let's use a fence instead.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/radeon_pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ra
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 39 +++--
1 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 6cc4259..261e98a 100644
--- a/drivers/
The lowest power states often cause display problems, so only enable
them when all displays are off.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |9 +++---
drivers/gpu/drm/radeon/r100.c | 12 ++--
drivers/gpu/drm/radeon/r600.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 16
drivers/gpu/drm/radeon/r600.c | 14 +++---
drivers/gpu/drm/radeon/radeon_pm.c | 16
drivers/gpu/drm/radeon/rs600.c |2 +-
4 files changed, 24 insertions(+), 24 del
On Sun, 02 May 2010 Bruno Prémont wrote:
> On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
>
> When the system is able to suspend it takes an eternity (more than 3
> minutes to wake-up, the radeon apparently being responsible for quite
> a big share of that slowness.
>
>
> Duri
On Fri, May 7, 2010 at 5:23 PM, Matthew Garrett wrote:
> On Fri, May 07, 2010 at 05:16:11PM -0400, Alex Deucher wrote:
>
>> "auto" selects between low and high power states based on the whether the
>> system
>> is on battery power or not. Even lower power states are selected when the
>> monitor
https://bugs.freedesktop.org/show_bug.cgi?id=23591
Kristian Høgsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Whoops, sent out an old version of this patch. newer version
attached, I can also send out a change against drm-next if you'd
prefer.
Alex
On Fri, May 7, 2010 at 5:05 PM, Alex Deucher wrote:
> Previously we just set them to dpms off. This should save
> additional power.
>
> Signed-off-by: Alex
On Fri, May 7, 2010 at 11:15 PM, Alex Deucher wrote:
> Whoops, sent out an old version of this patch. newer version
> attached, I can also send out a change against drm-next if you'd
> prefer.
And the incremental patch if you'd prefer.
Alex
>
> Alex
>
> On Fri, May 7, 2010 at 5:05 PM, Alex Deu
https://bugs.freedesktop.org/show_bug.cgi?id=20961
--- Comment #2 from Reilly Grant 2010-05-07 22:12:12 PDT
---
(In reply to comment #1)
> Did this get fixed? Can you try a recent version of the stack? Thanks.
Haha, I forgot about this problem. I'm currently running
xf86-video-intel-2.9.1 on
Two ttm cleanups, remove some unused code that we don't want anyone to use
by accident, and fix a missing hook in the radeon kms driver.
The following changes since commit 68b3adb429e0abf5c0a3deb75d71671436b3af10:
Alex Deucher (1):
drm/radeon/kms/legacy: only enable load detection prop
https://bugs.freedesktop.org/show_bug.cgi?id=28003
Michel D?nzer changed:
What|Removed |Added
CC||olvaffe at gmail.com
--- Comment #3 from
On Don, 2010-05-06 at 18:52 +0200, Jerome Glisse wrote:
> Bring radeon up to speed with the async event synchronization for
> drmWaitVblank. See c9a9c5e02aedc1a2815877b0268f886d2640b771 for
> more information. Without this patch event never get delivered
> to userspace client.
>
> Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=28003
Chia-I Wu changed:
What|Removed |Added
CC||airlied at freedesktop.org
--- Comment #4 fr
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #5 from Michel D?nzer 2010-05-07 02:18:21
PDT ---
(In reply to comment #4)
> I might not be able to find the time to work on it anytime soon.
FWIW I think it's a regression of one of your EGL reworks though.
> If no one volunteers,
On Fri, May 07, 2010 at 09:52:12AM +0200, Michel D?nzer wrote:
> On Don, 2010-05-06 at 18:52 +0200, Jerome Glisse wrote:
> > Bring radeon up to speed with the async event synchronization for
> > drmWaitVblank. See c9a9c5e02aedc1a2815877b0268f886d2640b771 for
> > more information. Without this patc
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #6 from Chia-I Wu 2010-05-07 03:11:11 PDT ---
Created an attachment (id=35484)
View: https://bugs.freedesktop.org/attachment.cgi?id=35484
Review: https://bugs.freedesktop.org/review?bug=28003&attachment=35484
work around the assert
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #7 from Chia-I Wu 2010-05-07 03:19:48 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > I might not be able to find the time to work on it anytime soon.
>
> FWIW I think it's a regression of one of your EGL reworks thou
https://bugs.freedesktop.org/show_bug.cgi?id=28003
--- Comment #8 from Chia-I Wu 2010-05-07 03:23:55 PDT ---
(In reply to comment #7)
> Ok, I've created a patch to work around the bug triggered by 968bf963. It
> restores the old (and wrong) behavior, but with comments. Could you or Scott
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Summary: [REGR] RV635 GPU lockup after enabling unmappable VRAM
V2 (KMS, Radeon)
Product: DRI
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=28016
--- Comment #1 from Grzegorz Kowal 2010-05-07 04:42:22 PDT
---
Created an attachment (id=35493)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35493)
lspci -v output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=em
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Grzegorz Kowal changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=28016
--- Comment #2 from Grzegorz Kowal 2010-05-07 04:48:35 PDT
---
To be more precise, I bisected the commit introducing the problem. It is
6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 (drm/radeon/kms: enable use of
unmappable VRAM V2). Before it every
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=27822
Alex Deucher changed:
What|Removed |Added
CC||astronomo at op.pl
--- Comment #10 from A
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #7 from fdelente at mail.cpod.fr 2010-05-07 06:28:14 PDT ---
(In reply to comment #6)
> Could you try either:
>
> - Installing the libtxc_dxtn library (should be available somewhere for your
> distro, otherwise get it here:
> http://h
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #8 from Sven Arvidsson 2010-05-07 07:02:53 PDT ---
(In reply to comment #7)
> Installing that library has solved the textures and bitmaps corruption
> problem,
> thanks! However, the GPU still hangs as mentionned in dmesg.
>
> I tri
https://bugs.freedesktop.org/show_bug.cgi?id=27868
--- Comment #4 from Bobby Weinmann 2010-05-07
07:26:32 PDT ---
Created an attachment (id=35497)
View: https://bugs.freedesktop.org/attachment.cgi?id=35497
Review: https://bugs.freedesktop.org/review?bug=27868&attachment=35497
PATCH for crash
Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
crtc id. Bump the minor version so userspace can enable conditionaly
features depend on this.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 18
https://bugs.freedesktop.org/show_bug.cgi?id=28016
Grzegorz Kowal changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://bugs.freedesktop.org/show_bug.cgi?id=28016
--- Comment #5 from Grzegorz Kowal 2010-05-07 08:36:30 PDT
---
Created an attachment (id=35498)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35498)
dmesg output from drm-next
--
Configure bugmail: https://bugs.freedesktop.org/userprefs
On Fri, May 7, 2010 at 11:18 AM, Jerome Glisse wrote:
> Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
> crtc id. Bump the minor version so userspace can enable conditionaly
> features depend on this.
Just curious what we need this for? Couldn't the id be handled in the
drm vi
On Fri, May 07, 2010 at 11:40:41AM -0400, Alex Deucher wrote:
> On Fri, May 7, 2010 at 11:18 AM, Jerome Glisse wrote:
> > Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
> > crtc id. Bump the minor version so userspace can enable conditionaly
> > features depend on this.
>
> Jus
On Fri, May 7, 2010 at 11:40 AM, Alex Deucher wrote:
> On Fri, May 7, 2010 at 11:18 AM, Jerome Glisse wrote:
>> Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
>> crtc id. Bump the minor version so userspace can enable conditionaly
>> features depend on this.
>
> Just curious wh
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #9 from fdelente at mail.cpod.fr 2010-05-07 09:36:34 PDT ---
(In reply to comment #8)
Thanks for your suggestions, installing the latest git of Mesa and/or
2.6.34-rc6 solved the GPU hang problem.
Now the game plays, but some models ar
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #10 from fdelente at mail.cpod.fr 2010-05-07 09:37:29 PDT ---
Created an attachment (id=35500)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35500)
Polygons stretched / models of characters distorted (not the buildings?)
--
Co
https://bugs.freedesktop.org/show_bug.cgi?id=3382
Kristian H?gsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=28000
--- Comment #11 from Sven Arvidsson 2010-05-07 11:24:09 PDT ---
(In reply to comment #9)
> Now the game plays, but some models are distorted: the polygons extend out of
> the characters(?).
>
> Furthermore, about 1 pixel is chopped of the letter
https://bugs.freedesktop.org/show_bug.cgi?id=11093
Kristian H?gsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=20961
--- Comment #1 from Kristian H?gsberg 2010-05-07
13:12:08 PDT ---
Did this get fixed? Can you try a recent version of the stack? Thanks.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=21777
Kristian H?gsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Previously we just set them to dpms off. This should save
additional power.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_encoders.c | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b
This set of patches applies on top of the code in drm-radeon-testing.
I've been testing this code pretty hard this week and it's been solid.
In addition to some fixes on top of what's in d-r-t, it also reworks
the pm code to support two basic methods:
1. "dynpm"
2. "profile"
You can select the m
voltage drop, dynamic voltage, dynamic sclk, pcie lane adjust, etc,
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/rs600.c | 14 ++
drivers/gpu/drm/radeon/rs600d.h |2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rs600.c b/d
voltage drop, dynamic voltage, dynamic sclk, pcie lane adjust, etc,
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 493b9b4..14b7541 100644
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 2eb675e..bded834 100644
--- a/drivers/gpu/drm/radeon/
From: Matthew Garrett
We need to handle the ring while we've already locked it, so split out
the allocation and commit functions in order to allow them to be used.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/radeon.h |2 ++
drivers/gpu/drm/radeon/radeon_ring.c | 27 +++
From: Matthew Garrett
GUI idle interrupts don't seem to work terribly well on r500 and earlier,
so let's use a fence instead.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/radeon/radeon_pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ra
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 39 +++--
1 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 6cc4259..261e98a 100644
--- a/drivers/
The lowest power states often cause display problems, so only enable
them when all displays are off.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |9 +++---
drivers/gpu/drm/radeon/r100.c | 12 ++--
drivers/gpu/drm/radeon/r600.c
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 16
drivers/gpu/drm/radeon/r600.c | 14 +++---
drivers/gpu/drm/radeon/radeon_pm.c | 16
drivers/gpu/drm/radeon/rs600.c |2 +-
4 files changed, 24 insertions(+), 24 del
On Sun, 02 May 2010 Bruno Pr?mont wrote:
> On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
>
> When the system is able to suspend it takes an eternity (more than 3
> minutes to wake-up, the radeon apparently being responsible for quite
> a big share of that slowness.
>
>
> Duri
On Fri, May 7, 2010 at 5:23 PM, Matthew Garrett wrote:
> On Fri, May 07, 2010 at 05:16:11PM -0400, Alex Deucher wrote:
>
>> "auto" selects between low and high power states based on the whether the
>> system
>> is on battery power or not. ?Even lower power states are selected when the
>> monitor
https://bugs.freedesktop.org/show_bug.cgi?id=23591
Kristian H?gsberg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
if (radeon_encoder_is_digital(encoder)) {
> ? ? ? ? ? ? ? ?if (atombios_get_encoder_mode(encoder) ==
> ATOM_ENCODER_MODE_HDMI)
> ? ? ? ? ? ? ? ? ? ? ? ?r600_hdmi_disable(encoder);
> --
> 1.5.6.3
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-atom-disable-the-encoders-in-encoder.patch
Type: application/mbox
Size: 2791 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100507/4f32acfc/attachment.bin>
tombios_tv_setup(encoder, ATOM_DISABLE);
>> + ? ? ? ? ? ? ? break;
>> + ? ? ? }
>> +
>> ? ? ? ?if (radeon_encoder_is_digital(encoder)) {
>> ? ? ? ? ? ? ? ?if (atombios_get_encoder_mode(encoder) ==
>> ATOM_ENCODER_MODE_HDMI)
>> ? ? ? ? ? ? ? ? ? ? ? ?r600_hdmi_disable(encoder);
>> --
>> 1.5.6.3
>>
>>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-fix-copy-pasto-in-disable-encoders-p.patch
Type: application/mbox
Size: 1076 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100507/9667a847/attachment-0001.bin>
https://bugs.freedesktop.org/show_bug.cgi?id=20961
--- Comment #2 from Reilly Grant 2010-05-07 22:12:12
PDT ---
(In reply to comment #1)
> Did this get fixed? Can you try a recent version of the stack? Thanks.
Haha, I forgot about this problem. I'm currently running
xf86-video-intel-2.9.1 on
- Separate dynpm and profile based power management methods. You can select
the pm method
by echoing the selected method ("dynpm" or "profile") to power_method in
sysfs.
- Expose basic 4 profile in profile method
"default" - default clocks
"auto" - select between low and high based on ac/d
On Fri, May 07, 2010 at 05:16:11PM -0400, Alex Deucher wrote:
> "auto" selects between low and high power states based on the whether the
> system
> is on battery power or not. Even lower power states are selected when the
> monitors
> are in the dpms off state.
Beyond the constraints imposed
95 matches
Mail list logo
