date:20100507

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=28003

Michel Dänzer  changed:

   What|Removed |Added

 CC||olva...@gmail.com

--- Comment #3 from Michel Dänzer  2010-05-07 00:49:58 PDT 
---
(In reply to comment #1)
> This is a state tracker bug. We shouldn't get two different formats in
> surface_copy.

Indeed. There should never be a need for copies for texture-from-pixmap anyway,
should probably use a sampler view.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: async event synchronization for drmWaitVblank

2010-05-07 Thread Michel Dänzer

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: Jerome Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 4b05563..b3749d4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -216,6 +216,7 @@ static struct drm_driver driver_old = {
>.mmap = drm_mmap,
>.poll = drm_poll,
>.fasync = drm_fasync,
> +  .read = drm_read,
>  #ifdef CONFIG_COMPAT
>.compat_ioctl = radeon_compat_ioctl,
>  #endif
> @@ -304,6 +305,7 @@ static struct drm_driver kms_driver = {
>.mmap = radeon_mmap,
>.poll = drm_poll,
>.fasync = drm_fasync,
> +  .read = drm_read,
>  #ifdef CONFIG_COMPAT
>.compat_ioctl = radeon_kms_compat_ioctl,
>  #endif

At least the KMS DRM minor should be bumped for this and checked by the
X driver before enabling the DRI2 functionality that needs it, otherwise
clients trying to use that functionality will hang.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=28003

Chia-I Wu  changed:

   What|Removed |Added

 CC||airl...@freedesktop.org

--- Comment #4 from Chia-I Wu  2010-05-07 01:53:20 PDT ---
(In reply to comment #3)
> Indeed. There should never be a need for copies for texture-from-pixmap 
> anyway,
> should probably use a sampler view.
The assertion failure is hit when using an RGBA pixmap as an RGB texture.  It
was discussed here

  http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg12992.html

and using a sampler view should be the correct fix to my knowledge.

I might not be able to find the time to work on it anytime soon.  If no one
volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for RGBA visuals
should be a valid workaround, if compiz does check the attribute.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-daemon

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, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for 
> RGBA
> visuals should be a valid workaround, if compiz does check the attribute.

I suspect that would take about the same amount of work, and I wouldn't
consider it very useful (not sure if compiz/kwin/... could even handle it).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: async event synchronization for drmWaitVblank

2010-05-07 Thread Jerome Glisse

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 patch event never get delivered
> > to userspace client.
> > 
> > Signed-off-by: Jerome Glisse 
> > ---
> >  drivers/gpu/drm/radeon/radeon_drv.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> > b/drivers/gpu/drm/radeon/radeon_drv.c
> > index 4b05563..b3749d4 100644
> > --- a/drivers/gpu/drm/radeon/radeon_drv.c
> > +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> > @@ -216,6 +216,7 @@ static struct drm_driver driver_old = {
> >  .mmap = drm_mmap,
> >  .poll = drm_poll,
> >  .fasync = drm_fasync,
> > +.read = drm_read,
> >  #ifdef CONFIG_COMPAT
> >  .compat_ioctl = radeon_compat_ioctl,
> >  #endif
> > @@ -304,6 +305,7 @@ static struct drm_driver kms_driver = {
> >  .mmap = radeon_mmap,
> >  .poll = drm_poll,
> >  .fasync = drm_fasync,
> > +.read = drm_read,
> >  #ifdef CONFIG_COMPAT
> >  .compat_ioctl = radeon_kms_compat_ioctl,
> >  #endif
> 
> At least the KMS DRM minor should be bumped for this and checked by the
> X driver before enabling the DRI2 functionality that needs it, otherwise
> clients trying to use that functionality will hang.
> 

I need another interface change before using this functionality
i will bump minor with the new interface i will send patch today.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-daemon

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 assertion failure

Does this patch help?  It effectively reverts
968bf9634ec03e61441834603f13f0c914bbb0ce by ignoring internal_format in
st/mesa.  It is better than reverting the commit in that the workaround is
closer to the bug (both in st/mesa).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-daemon

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 though.
> 
> > If no one volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for 
> > RGBA
> > visuals should be a valid workaround, if compiz does check the attribute.
> 
> I suspect that would take about the same amount of work, and I wouldn't
> consider it very useful (not sure if compiz/kwin/... could even handle it).
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
help me verify the patch?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-daemon

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
^
I meant, "wrong, but better than the assertion failure".  I am sorry to
introduce the regression in the first place.
> help me verify the patch?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] New: [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

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)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: astron...@op.pl


Created an attachment (id=35492)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=35492)
kernel log with the backtrace

I have tested recent branches drm-radeon-testing (last commit
7a1ffce50373c177d3f6eecce52badc40c90e1dd) and drm-next (last commit
9e51159c14c29ebd485a45ba56f148e180d62c29) from
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git.  These branches
contain patches for enabling unmappable VRAM. However, soon after booting I am
getting a GPU lockup and corrupted console and X.

My hardware is laptop ASUS M50SA with 4GB system memory, and graphics 1GB
Mobility Radeon HD 3650.

I am attaching the kernel output with the backtrace and lspci -v output.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

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=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=28016

Grzegorz Kowal  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

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 everything works fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=28016

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Alex Deucher  2010-05-07 06:18:03 PDT ---


*** This bug has been marked as a duplicate of bug 27822 ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 27822] [REGR] Soft lockup with "[TTM] Buffer eviction failed" on resume

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=27822

Alex Deucher  changed:

   What|Removed |Added

 CC||astron...@op.pl

--- Comment #10 from Alex Deucher  2010-05-07 06:18:03 PDT ---
*** Bug 28016 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-daemon

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://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html )

Installing that library has solved the textures and bitmaps corruption problem,
thanks! However, the GPU still hangs as mentionned in dmesg.

I tried getting a dump, but I couldn't find intel_reg_dumper in
intel-gpu-tools-1.0.2, I only found intel_gpu_dump. However, it doesn't work as
a user, and it hangs the machine as root, forcing me to reboot (I tried
intel_gpu_dump > gpu_dump as root, and the machine becomes completely
unresponsive).

> - Setting "Enable S3TC texture compression" to "Yes" in driconf. (or just
> force_s3tc_enable=true )

I couldn't find driconf, and I don't know where to put force_s3tc_enable=true;
however, since installing libtxc_dxtn worked, I guess it isn't mandatory?

Thanks for your help!

-- 
F. Delente

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-daemon

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 tried getting a dump, but I couldn't find intel_reg_dumper in
> intel-gpu-tools-1.0.2, I only found intel_gpu_dump. However, it doesn't work 
> as
> a user, and it hangs the machine as root, forcing me to reboot (I tried
> intel_gpu_dump > gpu_dump as root, and the machine becomes completely
> unresponsive).

The GPU reset function will probably mean that you won't get a meaningful dump
with that kernel anyway. The best way is to retry with git master of Mesa, and
the latest rc of 2.6.34. 

If the hang is still there, grab a dump with intel_error_decode.

(At least this is what I usually do.)

> I couldn't find driconf, and I don't know where to put force_s3tc_enable=true;
> however, since installing libtxc_dxtn worked, I guess it isn't mandatory?

No, shouldn't be necessary if the lib is used.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 27868] [r600] on new campaign, Vegastrike crashes or freezes Xorg

2010-05-07 Thread bugzilla-daemon

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 after "valide"

PATCH:

I have run into a crash after a "cannot valide it" warning.  The unmap function
in radeon_bo_legacy is called sometimes when the memory is no longer mapped. 
The radeon_bo_legacy->map_count goes negative which means statements like

if (radeon_bo_legacy->map_count) ...

will return true.

The attached patch prevents the count from going negative and fixes the crash
for me.

Crash was with the r200 driver (Radeon 9250SE) playing UrbanTerror using UMS. 
I made the patch using the Ubuntu Lucid 10.04 source package.

Bobby

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Jerome Glisse

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 ++
 include/drm/radeon_drm.h|1 +
 3 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index b3749d4..df96ace 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -44,9 +44,10 @@
  * - 2.1.0 - add square tiling interface
  * - 2.2.0 - add r6xx/r7xx const buffer support
  * - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
+ * - 2.4.0 - add crtc id query
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   3
+#define KMS_DRIVER_MINOR   4
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index d3657dc..04ad452 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
 {
struct radeon_device *rdev = dev->dev_private;
struct drm_radeon_info *info;
+   struct radeon_mode_info *minfo = &rdev->mode_info;
uint32_t *value_ptr;
uint32_t value;
+   struct drm_crtc *crtc;
+   int i, found;
 
info = data;
value_ptr = (uint32_t *)((unsigned long)info->value);
+   value = *value_ptr;
switch (info->request) {
case RADEON_INFO_DEVICE_ID:
value = dev->pci_device;
@@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
case RADEON_INFO_ACCEL_WORKING:
value = rdev->accel_working;
break;
+   case RADEON_INFO_CRTC_FROM_ID:
+   for (i = 0, found = 0; i < 6; i++) {
+   crtc = (struct drm_crtc *)minfo->crtcs[i];
+   if (crtc && crtc->base.id == value) {
+   value = i;
+   found = 1;
+   break;
+   }
+   }
+   if (!found) {
+   DRM_ERROR("unknown crtc id %d\n", value);
+   return -EINVAL;
+   }
+   break;
default:
DRM_DEBUG("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 81e614b..3ff9fc0 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -902,6 +902,7 @@ struct drm_radeon_cs {
 #define RADEON_INFO_NUM_GB_PIPES   0x01
 #define RADEON_INFO_NUM_Z_PIPES0x02
 #define RADEON_INFO_ACCEL_WORKING  0x03
+#define RADEON_INFO_CRTC_FROM_ID   0x04
 
 struct drm_radeon_info {
uint32_trequest;
-- 
1.7.0.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=28016

Grzegorz Kowal  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |

--- Comment #4 from Grzegorz Kowal  2010-05-07 08:35:57 PDT ---
I am reopening the bug since the patch included in bug 27822 does not resolve
my problem.

I have tested once again the recent branch drm-next with the last commit
"drm/ttm: fix, avoid iomapping system memory"
(9e51159c14c29ebd485a45ba56f148e180d62c29) and the problem remains.

I am attaching dmesg output from this as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-daemon

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.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Alex Deucher

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 via relocs?

Alex

>
> Signed-off-by: Jerome Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |    3 ++-
>  drivers/gpu/drm/radeon/radeon_kms.c |   18 ++
>  include/drm/radeon_drm.h            |    1 +
>  3 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index b3749d4..df96ace 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -44,9 +44,10 @@
>  * - 2.1.0 - add square tiling interface
>  * - 2.2.0 - add r6xx/r7xx const buffer support
>  * - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
> + * - 2.4.0 - add crtc id query
>  */
>  #define KMS_DRIVER_MAJOR       2
> -#define KMS_DRIVER_MINOR       3
> +#define KMS_DRIVER_MINOR       4
>  #define KMS_DRIVER_PATCHLEVEL  0
>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>  int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index d3657dc..04ad452 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
>  {
>        struct radeon_device *rdev = dev->dev_private;
>        struct drm_radeon_info *info;
> +       struct radeon_mode_info *minfo = &rdev->mode_info;
>        uint32_t *value_ptr;
>        uint32_t value;
> +       struct drm_crtc *crtc;
> +       int i, found;
>
>        info = data;
>        value_ptr = (uint32_t *)((unsigned long)info->value);
> +       value = *value_ptr;
>        switch (info->request) {
>        case RADEON_INFO_DEVICE_ID:
>                value = dev->pci_device;
> @@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
>        case RADEON_INFO_ACCEL_WORKING:
>                value = rdev->accel_working;
>                break;
> +       case RADEON_INFO_CRTC_FROM_ID:
> +               for (i = 0, found = 0; i < 6; i++) {
> +                       crtc = (struct drm_crtc *)minfo->crtcs[i];
> +                       if (crtc && crtc->base.id == value) {
> +                               value = i;
> +                               found = 1;
> +                               break;
> +                       }
> +               }
> +               if (!found) {
> +                       DRM_ERROR("unknown crtc id %d\n", value);
> +                       return -EINVAL;
> +               }
> +               break;
>        default:
>                DRM_DEBUG("Invalid request %d\n", info->request);
>                return -EINVAL;
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 81e614b..3ff9fc0 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -902,6 +902,7 @@ struct drm_radeon_cs {
>  #define RADEON_INFO_NUM_GB_PIPES       0x01
>  #define RADEON_INFO_NUM_Z_PIPES        0x02
>  #define RADEON_INFO_ACCEL_WORKING      0x03
> +#define RADEON_INFO_CRTC_FROM_ID       0x04
>
>  struct drm_radeon_info {
>        uint32_t                request;
> --
> 1.7.0.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Jerome Glisse

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.
> 
> Just curious what we need this for?  Couldn't the id be handled in the
> drm via relocs?
> 
> Alex
> 

It's for vblank event, i would have prefer that vblank event
directly took kms crtc id but as intel also supported UMS this
wasn't an option i guess. I am pondering on adding a new interface
which directly took drm crtc_id.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Alex Deucher

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 what we need this for?  Couldn't the id be handled in the
> drm via relocs?
>

Nevermind, just saw the ddx patch.

> Alex
>
>>
>> Signed-off-by: Jerome Glisse 
>> ---
>>  drivers/gpu/drm/radeon/radeon_drv.c |    3 ++-
>>  drivers/gpu/drm/radeon/radeon_kms.c |   18 ++
>>  include/drm/radeon_drm.h            |    1 +
>>  3 files changed, 21 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index b3749d4..df96ace 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -44,9 +44,10 @@
>>  * - 2.1.0 - add square tiling interface
>>  * - 2.2.0 - add r6xx/r7xx const buffer support
>>  * - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
>> + * - 2.4.0 - add crtc id query
>>  */
>>  #define KMS_DRIVER_MAJOR       2
>> -#define KMS_DRIVER_MINOR       3
>> +#define KMS_DRIVER_MINOR       4
>>  #define KMS_DRIVER_PATCHLEVEL  0
>>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>  int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index d3657dc..04ad452 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>>  {
>>        struct radeon_device *rdev = dev->dev_private;
>>        struct drm_radeon_info *info;
>> +       struct radeon_mode_info *minfo = &rdev->mode_info;
>>        uint32_t *value_ptr;
>>        uint32_t value;
>> +       struct drm_crtc *crtc;
>> +       int i, found;
>>
>>        info = data;
>>        value_ptr = (uint32_t *)((unsigned long)info->value);
>> +       value = *value_ptr;
>>        switch (info->request) {
>>        case RADEON_INFO_DEVICE_ID:
>>                value = dev->pci_device;
>> @@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>>        case RADEON_INFO_ACCEL_WORKING:
>>                value = rdev->accel_working;
>>                break;
>> +       case RADEON_INFO_CRTC_FROM_ID:
>> +               for (i = 0, found = 0; i < 6; i++) {
>> +                       crtc = (struct drm_crtc *)minfo->crtcs[i];
>> +                       if (crtc && crtc->base.id == value) {
>> +                               value = i;
>> +                               found = 1;
>> +                               break;
>> +                       }
>> +               }
>> +               if (!found) {
>> +                       DRM_ERROR("unknown crtc id %d\n", value);
>> +                       return -EINVAL;
>> +               }
>> +               break;
>>        default:
>>                DRM_DEBUG("Invalid request %d\n", info->request);
>>                return -EINVAL;
>> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
>> index 81e614b..3ff9fc0 100644
>> --- a/include/drm/radeon_drm.h
>> +++ b/include/drm/radeon_drm.h
>> @@ -902,6 +902,7 @@ struct drm_radeon_cs {
>>  #define RADEON_INFO_NUM_GB_PIPES       0x01
>>  #define RADEON_INFO_NUM_Z_PIPES        0x02
>>  #define RADEON_INFO_ACCEL_WORKING      0x03
>> +#define RADEON_INFO_CRTC_FROM_ID       0x04
>>
>>  struct drm_radeon_info {
>>        uint32_t                request;
>> --
>> 1.7.0.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-daemon

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 distorted: the polygons extend out of
the characters(?).

Furthermore, about 1 pixel is chopped of the letters (see screenshot).

Thanks again anyway!

-- 
F. Delente

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-daemon

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?)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 3382] Dynamically generate GL dispatch functions for ia64

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=3382

Kristian Høgsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Kristian Høgsberg  2010-05-07 10:28:53 
PDT ---
Not going to happen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-daemon

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 letters (see screenshot).

These I can't reproduce, sorry.

I guess either the demo isn't enough to reproduce this, or it's a problem
specific to your hardware (I use a X4500HD).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 11093] libdrm COPYING file

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=11093

Kristian Høgsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #2 from Kristian Høgsberg  2010-05-07 13:11:27 
PDT ---
Thanks, but I suspect we won't be able to keep that up to date.  The copyright
terms are in the individual files.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 20961] libdrm_intel segfault on Firefox load

2010-05-07 Thread bugzilla-daemon

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 this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 21777] libdrm-2.4.11 fails with LDFLAGS="-Wl,--as-needed"

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=21777

Kristian Høgsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Kristian Høgsberg  2010-05-07 13:14:14 
PDT ---
Looks like this got worked out, if not please reopen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms/atom: disable the encoders in encoder_disable

2010-05-07 Thread Alex Deucher

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/drivers/gpu/drm/radeon/radeon_encoders.c
index 559c9ce..607d00b 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1504,10 +1504,49 @@ static void radeon_atom_encoder_commit(struct 
drm_encoder *encoder)
 
 static void radeon_atom_encoder_disable(struct drm_encoder *encoder)
 {
+   struct drm_device *dev = encoder->dev;
+   struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig;
radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
 
+   switch (radeon_encoder->encoder_id) {
+   case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+   case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+   atombios_digital_setup(encoder, PANEL_ENCODER_ACTION_DISABLE);
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+   if (ASIC_IS_DCE4(rdev))
+   /* disable the transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   else {
+   /* disable the encoder and transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   atombios_dig_encoder_setup(encoder, ATOM_DISABLE);
+   }
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_DDI:
+   atombios_ddia_setup(encoder, ATOM_DISABLE);
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+   atombios_external_tmds_setup(encoder, ATOM_DISABLE);
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_DAC1:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1:
+   case ENCODER_OBJECT_ID_INTERNAL_DAC2:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
+   atombios_dac_setup(encoder, ATOM_DISABLE);
+   if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT | 
ATOM_DEVICE_CV_SUPPORT))
+   atombios_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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/9] drm/radeon/kms: update pm code

2010-05-07 Thread Alex Deucher

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 methods via sysfs.  Echo "dynpm" or "profile" to
/sys/class/drm/card-0/device/power_method.

The "dynpm" method dynamically changes the clocks based on the number of pending
fences, so performance is ramped up when running GPU intensive apps, and
ramped down when the GPU is idle.  The reclocking is attemped during
vertical blanking periods, but due to the timing of the reclocking
functions, doesn't not always complete in the blanking period, which can
lead to flicker in the display.  Due to this, dynpm only works when a single
head is active.

The "profile" method exposes 4 profiles that can be selected from:
1. "default"
2. "auto"
3. "low"
4. "high"
Select the profile by echoing the selected profile to
/sys/class/drm/card-0/device/power_profile.

"default" uses the default clocks and does not change the power state.  This is
the default behavior.
"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.
"low" forces the gpu to be in the low power state all the time.  Even lower 
power
states are selected when the monitors are in the dpms off state.
"high" forces the gpu to be in the high power state all the time.  Even lower 
power
states are selected when the monitors are in the dpms off state.

The "profile" method is not as agressive as "dynpm," but is currently much more
stable and flicker free and works with multiple heads active.

The default power management method is "profile" using the "default" profile.
The default should eventaully be changed to "profile" "auto".

For upstream, we may want to squash some of these.  I'm open to suggestions.
Everthing that's been added since drm-linus?

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/9] drm/radeon/kms: enable misc pm power state features on r5xx, rs6xx

2010-05-07 Thread Alex Deucher

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/drivers/gpu/drm/radeon/rs600.c
index c3890b7..8e0c460 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -48,12 +48,11 @@ int rs600_mc_wait_for_idle(struct radeon_device *rdev);
 
 void rs600_pm_misc(struct radeon_device *rdev)
 {
-#if 0
int requested_index = rdev->pm.requested_power_state_index;
struct radeon_power_state *ps = &rdev->pm.power_state[requested_index];
struct radeon_voltage *voltage = &ps->clock_info[0].voltage;
u32 tmp, dyn_pwrmgt_sclk_length, dyn_sclk_vol_cntl;
-   u32 hdp_dyn_cntl, mc_host_dyn_cntl;
+   u32 hdp_dyn_cntl, /*mc_host_dyn_cntl,*/ dyn_backbias_cntl;
 
if ((voltage->type == VOLTAGE_GPIO) && (voltage->gpio.valid)) {
if (ps->misc & ATOM_PM_MISCINFO_VOLTAGE_DROP_SUPPORT) {
@@ -112,13 +111,21 @@ void rs600_pm_misc(struct radeon_device *rdev)
else
hdp_dyn_cntl |= HDP_FORCEON;
WREG32_PLL(HDP_DYN_CNTL, hdp_dyn_cntl);
-
+#if 0
+   /* mc_host_dyn seems to cause hangs from time to time */
mc_host_dyn_cntl = RREG32_PLL(MC_HOST_DYN_CNTL);
if (ps->misc & ATOM_PM_MISCINFO_DYNAMIC_MC_HOST_BLOCK_EN)
mc_host_dyn_cntl &= ~MC_HOST_FORCEON;
else
mc_host_dyn_cntl |= MC_HOST_FORCEON;
WREG32_PLL(MC_HOST_DYN_CNTL, mc_host_dyn_cntl);
+#endif
+   dyn_backbias_cntl = RREG32_PLL(DYN_BACKBIAS_CNTL);
+   if (ps->misc & ATOM_PM_MISCINFO2_DYNAMIC_BACK_BIAS_EN)
+   dyn_backbias_cntl |= IO_CG_BACKBIAS_EN;
+   else
+   dyn_backbias_cntl &= ~IO_CG_BACKBIAS_EN;
+   WREG32_PLL(DYN_BACKBIAS_CNTL, dyn_backbias_cntl);
 
/* set pcie lanes */
if ((rdev->flags & RADEON_IS_PCIE) &&
@@ -130,7 +137,6 @@ void rs600_pm_misc(struct radeon_device *rdev)
  ps->pcie_lanes);
DRM_INFO("Setting: p: %d\n", ps->pcie_lanes);
}
-#endif
 }
 
 void rs600_pm_prepare(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rs600d.h b/drivers/gpu/drm/radeon/rs600d.h
index 8f62434..a27c13a 100644
--- a/drivers/gpu/drm/radeon/rs600d.h
+++ b/drivers/gpu/drm/radeon/rs600d.h
@@ -655,6 +655,8 @@
 #define   HDP_FORCEON  (1 << 0)
 #define MC_HOST_DYN_CNTL   0x1e
 #define   MC_HOST_FORCEON  (1 << 0)
+#define DYN_BACKBIAS_CNTL  0x29
+#define   IO_CG_BACKBIAS_EN(1 << 0)
 
 /* mmreg */
 #define DOUT_POWER_MANAGEMENT_CNTL 0x7ee0
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/9] drm/radeon/kms: enable misc pm power state features on r1xx-r4xx

2010-05-07 Thread Alex Deucher

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
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -220,7 +220,6 @@ void r100_set_power_state(struct radeon_device *rdev, bool 
static_switch)
 
 void r100_pm_misc(struct radeon_device *rdev)
 {
-#if 0
int requested_index = rdev->pm.requested_power_state_index;
struct radeon_power_state *ps = &rdev->pm.power_state[requested_index];
struct radeon_voltage *voltage = &ps->clock_info[0].voltage;
@@ -308,7 +307,6 @@ void r100_pm_misc(struct radeon_device *rdev)
  ps->pcie_lanes);
DRM_INFO("Setting: p: %d\n", ps->pcie_lanes);
}
-#endif
 }
 
 void r100_pm_prepare(struct radeon_device *rdev)
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/9] drm/radeon/kms: re-enable gui idle interrupts on r6xx+

2010-05-07 Thread Alex Deucher

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/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -64,17 +64,19 @@ static void radeon_pm_set_clocks(struct radeon_device 
*rdev, int static_switch)
mutex_lock(&rdev->ddev->struct_mutex);
mutex_lock(&rdev->vram_mutex);
mutex_lock(&rdev->cp.mutex);
-#if 0
-   /* wait for GPU idle */
-   rdev->pm.gui_idle = false;
-   rdev->irq.gui_idle = true;
-   radeon_irq_set(rdev);
-   wait_event_interruptible_timeout(
-   rdev->irq.idle_queue, rdev->pm.gui_idle,
-   msecs_to_jiffies(RADEON_WAIT_IDLE_TIMEOUT));
-   rdev->irq.gui_idle = false;
-   radeon_irq_set(rdev);
-#endif
+
+   /* gui idle int has issues on older chips it seems */
+   if (rdev->family >= CHIP_R600) {
+   /* wait for GPU idle */
+   rdev->pm.gui_idle = false;
+   rdev->irq.gui_idle = true;
+   radeon_irq_set(rdev);
+   wait_event_interruptible_timeout(
+   rdev->irq.idle_queue, rdev->pm.gui_idle,
+   msecs_to_jiffies(RADEON_WAIT_IDLE_TIMEOUT));
+   rdev->irq.gui_idle = false;
+   radeon_irq_set(rdev);
+   }
radeon_unmap_vram_bos(rdev);
 
if (!static_switch) {
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/9] radeon: Split out ring locking and allocation

2010-05-07 Thread Alex Deucher

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 +--
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 93ac88e..e39e2b4 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -471,7 +471,9 @@ int radeon_ib_test(struct radeon_device *rdev);
 extern void radeon_ib_bogus_add(struct radeon_device *rdev, struct radeon_ib 
*ib);
 /* Ring access between begin & end cannot sleep */
 void radeon_ring_free_size(struct radeon_device *rdev);
+int radeon_ring_alloc(struct radeon_device *rdev, unsigned ndw);
 int radeon_ring_lock(struct radeon_device *rdev, unsigned ndw);
+void radeon_ring_commit(struct radeon_device *rdev);
 void radeon_ring_unlock_commit(struct radeon_device *rdev);
 void radeon_ring_unlock_undo(struct radeon_device *rdev);
 int radeon_ring_test(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index f6e1e8d..6cc4259 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -258,31 +258,41 @@ void radeon_ring_free_size(struct radeon_device *rdev)
}
 }
 
-int radeon_ring_lock(struct radeon_device *rdev, unsigned ndw)
+int radeon_ring_alloc(struct radeon_device *rdev, unsigned ndw)
 {
int r;
 
/* Align requested size with padding so unlock_commit can
 * pad safely */
ndw = (ndw + rdev->cp.align_mask) & ~rdev->cp.align_mask;
-   mutex_lock(&rdev->cp.mutex);
while (ndw > (rdev->cp.ring_free_dw - 1)) {
radeon_ring_free_size(rdev);
if (ndw < rdev->cp.ring_free_dw) {
break;
}
r = radeon_fence_wait_next(rdev);
-   if (r) {
-   mutex_unlock(&rdev->cp.mutex);
+   if (r)
return r;
-   }
}
rdev->cp.count_dw = ndw;
rdev->cp.wptr_old = rdev->cp.wptr;
return 0;
 }
 
-void radeon_ring_unlock_commit(struct radeon_device *rdev)
+int radeon_ring_lock(struct radeon_device *rdev, unsigned ndw)
+{
+   int r;
+
+   mutex_lock(&rdev->cp.mutex);
+   r = radeon_ring_alloc(rdev, ndw);
+   if (r) {
+   mutex_unlock(&rdev->cp.mutex);
+   return r;
+   }
+   return 0;
+}
+
+void radeon_ring_commit(struct radeon_device *rdev)
 {
unsigned count_dw_pad;
unsigned i;
@@ -295,6 +305,11 @@ void radeon_ring_unlock_commit(struct radeon_device *rdev)
}
DRM_MEMORYBARRIER();
radeon_cp_commit(rdev);
+}
+
+void radeon_ring_unlock_commit(struct radeon_device *rdev)
+{
+   radeon_ring_commit(rdev);
mutex_unlock(&rdev->cp.mutex);
 }
 
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/9] radeon: Use fences to gate entry to reclocking on

2010-05-07 Thread Alex Deucher

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/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index bded834..1ee7fc9 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -76,6 +76,14 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev, 
int static_switch)
msecs_to_jiffies(RADEON_WAIT_IDLE_TIMEOUT));
rdev->irq.gui_idle = false;
radeon_irq_set(rdev);
+   } else {
+   struct radeon_fence *fence;
+   radeon_ring_alloc(rdev, 64);
+   radeon_fence_create(rdev, &fence);
+   radeon_fence_emit(rdev, fence);
+   radeon_ring_commit(rdev);
+   radeon_fence_wait(fence, false);
+   radeon_fence_unref(&fence);
}
radeon_unmap_vram_bos(rdev);
 
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/9] drm/radeon/kms: fix lock ordering in ring, ib handling

2010-05-07 Thread Alex Deucher

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/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -219,24 +219,26 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
 void radeon_ib_pool_fini(struct radeon_device *rdev)
 {
int r;
+   struct radeon_bo *robj;
 
if (!rdev->ib_pool.ready) {
return;
}
mutex_lock(&rdev->ib_pool.mutex);
radeon_ib_bogus_cleanup(rdev);
+   robj = rdev->ib_pool.robj;
+   rdev->ib_pool.robj = NULL;
+   mutex_unlock(&rdev->ib_pool.mutex);
 
-   if (rdev->ib_pool.robj) {
-   r = radeon_bo_reserve(rdev->ib_pool.robj, false);
+   if (robj) {
+   r = radeon_bo_reserve(robj, false);
if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev->ib_pool.robj);
-   radeon_bo_unpin(rdev->ib_pool.robj);
-   radeon_bo_unreserve(rdev->ib_pool.robj);
+   radeon_bo_kunmap(robj);
+   radeon_bo_unpin(robj);
+   radeon_bo_unreserve(robj);
}
-   radeon_bo_unref(&rdev->ib_pool.robj);
-   rdev->ib_pool.robj = NULL;
+   radeon_bo_unref(&robj);
}
-   mutex_unlock(&rdev->ib_pool.mutex);
 }
 
 
@@ -359,20 +361,23 @@ int radeon_ring_init(struct radeon_device *rdev, unsigned 
ring_size)
 void radeon_ring_fini(struct radeon_device *rdev)
 {
int r;
+   struct radeon_bo *ring_obj;
 
mutex_lock(&rdev->cp.mutex);
-   if (rdev->cp.ring_obj) {
-   r = radeon_bo_reserve(rdev->cp.ring_obj, false);
+   ring_obj = rdev->cp.ring_obj;
+   rdev->cp.ring = NULL;
+   rdev->cp.ring_obj = NULL;
+   mutex_unlock(&rdev->cp.mutex);
+
+   if (ring_obj) {
+   r = radeon_bo_reserve(ring_obj, false);
if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev->cp.ring_obj);
-   radeon_bo_unpin(rdev->cp.ring_obj);
-   radeon_bo_unreserve(rdev->cp.ring_obj);
+   radeon_bo_kunmap(ring_obj);
+   radeon_bo_unpin(ring_obj);
+   radeon_bo_unreserve(ring_obj);
}
-   radeon_bo_unref(&rdev->cp.ring_obj);
-   rdev->cp.ring = NULL;
-   rdev->cp.ring_obj = NULL;
+   radeon_bo_unref(&ring_obj);
}
-   mutex_unlock(&rdev->cp.mutex);
 }
 
 
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/9] drm/radeon/kms/pm: add support for no display power states

2010-05-07 Thread Alex Deucher

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   |   20 --
 drivers/gpu/drm/radeon/radeon.h |7 +++-
 drivers/gpu/drm/radeon/radeon_atombios.c|   37 ++
 drivers/gpu/drm/radeon/radeon_combios.c |2 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |9 +++---
 drivers/gpu/drm/radeon/radeon_pm.c  |   38 ++
 8 files changed, 94 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 4151ad8..03dd6c4 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -245,13 +245,15 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
 
switch (mode) {
case DRM_MODE_DPMS_ON:
+   radeon_crtc->enabled = true;
+   /* adjust pm to dpms changes BEFORE enabling crtcs */
+   radeon_pm_compute_clocks(rdev);
atombios_enable_crtc(crtc, ATOM_ENABLE);
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, ATOM_ENABLE);
atombios_blank_crtc(crtc, ATOM_DISABLE);
drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
radeon_crtc_load_lut(crtc);
-   radeon_crtc->enabled = true;
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
@@ -262,11 +264,10 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
atombios_enable_crtc_memreq(crtc, ATOM_DISABLE);
atombios_enable_crtc(crtc, ATOM_DISABLE);
radeon_crtc->enabled = false;
+   /* adjust pm to dpms changes AFTER disabling crtcs */
+   radeon_pm_compute_clocks(rdev);
break;
}
-
-   /* adjust pm to dpms change */
-   radeon_pm_compute_clocks(rdev);
 }
 
 static void
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 14b7541..4161a35 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -87,7 +87,7 @@ void r100_get_power_state(struct radeon_device *rdev,
} else {
if (rdev->pm.active_crtc_count > 1) {
for (i = 0; i < rdev->pm.num_power_states; i++) 
{
-   if (rdev->pm.power_state[i].flags & 
RADEON_PM_SINGLE_DISPLAY_ONLY)
+   if (rdev->pm.power_state[i].flags & 
RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
continue;
else if (i >= 
rdev->pm.current_power_state_index) {

rdev->pm.requested_power_state_index = rdev->pm.current_power_state_index;
@@ -101,6 +101,12 @@ void r100_get_power_state(struct radeon_device *rdev,
rdev->pm.requested_power_state_index =
rdev->pm.current_power_state_index - 1;
}
+   /* don't use the power state if crtcs are active and no display 
flag is set */
+   if ((rdev->pm.active_crtc_count > 0) &&
+   
(rdev->pm.power_state[rdev->pm.requested_power_state_index].clock_info[0].flags 
&
+RADEON_PM_MODE_NO_DISPLAY)) {
+   rdev->pm.requested_power_state_index++;
+   }
break;
case PM_ACTION_UPCLOCK:
if (rdev->pm.current_power_state_index == 
(rdev->pm.num_power_states - 1)) {
@@ -109,7 +115,7 @@ void r100_get_power_state(struct radeon_device *rdev,
} else {
if (rdev->pm.active_crtc_count > 1) {
for (i = (rdev->pm.num_power_states - 1); i >= 
0; i--) {
-   if (rdev->pm.power_state[i].flags & 
RADEON_PM_SINGLE_DISPLAY_ONLY)
+   if (rdev->pm.power_state[i].flags & 
RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
continue;
else if (i <= 
rdev->pm.current_power_state_index) {

rdev->pm.requested_power_state_index = rdev->pm.current_power_state_index;
@@ -215,7 +221,7 @@ void r100_set_power_state(struct radeon_device *rdev, bool 
static_switch)
rdev->pm.current_power_state_index = 
rdev->pm.requested_power_state_index;
rdev->pm.current_clock_mode_index = 
rdev->pm.requested_clock_mode_index;
} else
-   DRM_INFO("GUI not idle!!!\n");
+

[PATCH 9/9] drm/radeon/kms/pm: make pm spam debug only

2010-05-07 Thread Alex Deucher

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 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5d21b..9a59ba4 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -141,13 +141,13 @@ void r100_pm_get_dynpm_state(struct radeon_device *rdev)
/* only one clock mode per power state */
rdev->pm.requested_clock_mode_index = 0;
 
-   DRM_INFO("Requested: e: %d m: %d p: %d\n",
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].sclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].mclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-pcie_lanes);
+   DRM_DEBUG("Requested: e: %d m: %d p: %d\n",
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].sclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].mclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ pcie_lanes);
 }
 
 void r100_pm_init_profile(struct radeon_device *rdev)
@@ -266,7 +266,7 @@ void r100_pm_misc(struct radeon_device *rdev)
 
rdev->pm.power_state[rdev->pm.current_power_state_index].pcie_lanes)) {
radeon_set_pcie_lanes(rdev,
  ps->pcie_lanes);
-   DRM_INFO("Setting: p: %d\n", ps->pcie_lanes);
+   DRM_DEBUG("Setting: p: %d\n", ps->pcie_lanes);
}
 }
 
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 618d76d..0fef335 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -251,13 +251,13 @@ void r600_pm_get_dynpm_state(struct radeon_device *rdev)
}
}
 
-   DRM_INFO("Requested: e: %d m: %d p: %d\n",
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].sclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].mclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-pcie_lanes);
+   DRM_DEBUG("Requested: e: %d m: %d p: %d\n",
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].sclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].mclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ pcie_lanes);
 }
 
 static int r600_pm_get_type_index(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 1827317..c88edae 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -52,9 +52,9 @@ static int radeon_acpi_event(struct notifier_block *nb,
 
if (strcmp(entry->device_class, ACPI_AC_CLASS) == 0) {
if (power_supply_is_system_supplied() > 0)
-   DRM_INFO("pm: AC\n");
+   DRM_DEBUG("pm: AC\n");
else
-   DRM_INFO("pm: DC\n");
+   DRM_DEBUG("pm: DC\n");
 
if (rdev->pm.pm_method == PM_METHOD_PROFILE) {
if (rdev->pm.profile == PM_PROFILE_AUTO) {
@@ -183,7 +183,7 @@ static void radeon_set_power_state(struct radeon_device 
*rdev)
radeon_set_engine_clock(rdev, sclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev->pm.current_sclk = sclk;
-   DRM_INFO("Setting: e: %d\n", sclk);
+   DRM_DEBUG("Setting: e: %d\n", sclk);
}
 
/* set memory clock */
@@ -192,7 +192,7 @@ static void radeon_set_power_state(struct radeon_device 
*rdev)
radeon_set_memory_clock(rdev, mclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev->pm.current_mclk = mclk;
-   DRM_INFO("Setting: m: %d\n", mclk);
+   DRM_DEBUG("Setting: m: %d\n", mclk);
}

Re: s2ram slow resume - radeon versus no_console_suspend?

2010-05-07 Thread Bruno Prémont

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.
> 
> 
> During resume early it looks like every PCI access needs about a second,
> and there are a few cases where during lots of seconds nothing seems to
> happen and the first event following is related to radeon.

This slowness only happens when I run the kernel with no_console_suspend
parameter (e.g. to debug some suspend/resume issue).
This probably means that in this case radeon's PCI config recorded during
suspend and restored during early resume is all but appropriate...

Currently drm/radeon does not suspend when no_console_suspend is provided,
even so when the kernel logging does not happen on tty0 & co.

e.g. I would expect that a kernel run with
  no_console_suspend console=ttyS0
would just skip suspending serial port ttyS0 and not also skip suspending
KMS framebuffer as it currently does.

In most framebuffer devices I see usage of acquire_console_sem() and
release_console_sem() but except for kernel/printk.c and drivers/serial/
code nothing is considering console_suspend_enabled.

Currently I'm not sure what code path prevents suspend of KMS (at least
for radeon) when no_console_suspend has been passed, this code path should
probably have a conditional just as serial to take no_console_suspend only
if it's running kernel's console itself.

Thanks,
Bruno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] drm/radeon/kms: update pm code

2010-05-07 Thread Alex Deucher

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 
>> monitors
>> are in the dpms off state.
>
> Beyond the constraints imposed in terms of some modes not being
> available on battery, I'd prefer to leave the ac/battery decision up to
> userspace. Having it be default behaviour at the kernel level is
> plausibly confusing.

Sounds fine.  Just have userspace switch between the low and high
profiles for battery and ac rather than using auto.  auto is useful as
a user option in the interim while userspace gets updated.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 23591] cannot build libdrm-2.4.13: libudev.h: No such file or directory

2010-05-07 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=23591

Kristian Høgsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Kristian Høgsberg  2010-05-07 16:46:01 
PDT ---
As of today (version 2.4.20) this works for me.  The test programs that require
udev are conditional in test/Makefile.am and kick in when udev is enabled and
found.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms/atom: disable the encoders in encoder_disable

2010-05-07 Thread Alex Deucher

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 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/drivers/gpu/drm/radeon/radeon_encoders.c
> index 559c9ce..607d00b 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -1504,10 +1504,49 @@ static void radeon_atom_encoder_commit(struct 
> drm_encoder *encoder)
>
>  static void radeon_atom_encoder_disable(struct drm_encoder *encoder)
>  {
> +       struct drm_device *dev = encoder->dev;
> +       struct radeon_device *rdev = dev->dev_private;
>        struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>        struct radeon_encoder_atom_dig *dig;
>        radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
>
> +       switch (radeon_encoder->encoder_id) {
> +       case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
> +       case ENCODER_OBJECT_ID_INTERNAL_LVDS:
> +       case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
> +               atombios_digital_setup(encoder, PANEL_ENCODER_ACTION_DISABLE);
> +               break;
> +       case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
> +       case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> +       case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
> +               if (ASIC_IS_DCE4(rdev))
> +                       /* disable the transmitter */
> +                       atombios_dig_transmitter_setup(encoder, 
> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
> +               else {
> +                       /* disable the encoder and transmitter */
> +                       atombios_dig_transmitter_setup(encoder, 
> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
> +                       atombios_dig_encoder_setup(encoder, ATOM_DISABLE);
> +               }
> +               break;
> +       case ENCODER_OBJECT_ID_INTERNAL_DDI:
> +               atombios_ddia_setup(encoder, ATOM_DISABLE);
> +               break;
> +       case ENCODER_OBJECT_ID_INTERNAL_DVO1:
> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
> +               atombios_external_tmds_setup(encoder, ATOM_DISABLE);
> +               break;
> +       case ENCODER_OBJECT_ID_INTERNAL_DAC1:
> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1:
> +       case ENCODER_OBJECT_ID_INTERNAL_DAC2:
> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
> +               atombios_dac_setup(encoder, ATOM_DISABLE);
> +               if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT | 
> ATOM_DEVICE_CV_SUPPORT))
> +                       atombios_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
>
>


0001-drm-radeon-kms-atom-disable-the-encoders-in-encoder.patch
Description: application/mbox
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms/atom: disable the encoders in encoder_disable

2010-05-07 Thread Alex Deucher

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 Deucher  wrote:
>> 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/drivers/gpu/drm/radeon/radeon_encoders.c
>> index 559c9ce..607d00b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
>> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
>> @@ -1504,10 +1504,49 @@ static void radeon_atom_encoder_commit(struct 
>> drm_encoder *encoder)
>>
>>  static void radeon_atom_encoder_disable(struct drm_encoder *encoder)
>>  {
>> +       struct drm_device *dev = encoder->dev;
>> +       struct radeon_device *rdev = dev->dev_private;
>>        struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>>        struct radeon_encoder_atom_dig *dig;
>>        radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
>>
>> +       switch (radeon_encoder->encoder_id) {
>> +       case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
>> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
>> +       case ENCODER_OBJECT_ID_INTERNAL_LVDS:
>> +       case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
>> +               atombios_digital_setup(encoder, 
>> PANEL_ENCODER_ACTION_DISABLE);
>> +               break;
>> +       case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
>> +       case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>> +       case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
>> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
>> +               if (ASIC_IS_DCE4(rdev))
>> +                       /* disable the transmitter */
>> +                       atombios_dig_transmitter_setup(encoder, 
>> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
>> +               else {
>> +                       /* disable the encoder and transmitter */
>> +                       atombios_dig_transmitter_setup(encoder, 
>> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
>> +                       atombios_dig_encoder_setup(encoder, ATOM_DISABLE);
>> +               }
>> +               break;
>> +       case ENCODER_OBJECT_ID_INTERNAL_DDI:
>> +               atombios_ddia_setup(encoder, ATOM_DISABLE);
>> +               break;
>> +       case ENCODER_OBJECT_ID_INTERNAL_DVO1:
>> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
>> +               atombios_external_tmds_setup(encoder, ATOM_DISABLE);
>> +               break;
>> +       case ENCODER_OBJECT_ID_INTERNAL_DAC1:
>> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1:
>> +       case ENCODER_OBJECT_ID_INTERNAL_DAC2:
>> +       case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
>> +               atombios_dac_setup(encoder, ATOM_DISABLE);
>> +               if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT 
>> | ATOM_DEVICE_CV_SUPPORT))
>> +                       atombios_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
>>
>>
>


0001-drm-radeon-kms-fix-copy-pasto-in-disable-encoders-p.patch
Description: application/mbox
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 20961] libdrm_intel segfault on Firefox load

2010-05-07 Thread bugzilla-daemon

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 Linux 2.6.32 with KMS and everything seems to be
working.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes

2010-05-07 Thread Dave Airlie


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 property on DVI-I

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

Jerome Glisse (1):
  drm/radeon: async event synchronization for drmWaitVblank

Thomas Hellstrom (2):
  drm/ttm: Remove some leftover debug messages.
  drm/ttm: Remove the ttm_bo_block_reservation() function.

 drivers/gpu/drm/radeon/radeon_drv.c |2 ++
 drivers/gpu/drm/ttm/ttm_bo.c|   30 +-
 drivers/gpu/drm/ttm/ttm_lock.c  |5 +
 include/drm/ttm/ttm_bo_driver.h |   28 
 4 files changed, 4 insertions(+), 61 deletions(-)

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=28003

Michel D?nzer  changed:

   What|Removed |Added

 CC||olvaffe at gmail.com

--- Comment #3 from Michel D?nzer  2010-05-07 00:49:58 
PDT ---
(In reply to comment #1)
> This is a state tracker bug. We shouldn't get two different formats in
> surface_copy.

Indeed. There should never be a need for copies for texture-from-pixmap anyway,
should probably use a sampler view.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: async event synchronization for drmWaitVblank

2010-05-07 Thread Michel Dänzer

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: Jerome Glisse 
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 4b05563..b3749d4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -216,6 +216,7 @@ static struct drm_driver driver_old = {
>.mmap = drm_mmap,
>.poll = drm_poll,
>.fasync = drm_fasync,
> +  .read = drm_read,
>  #ifdef CONFIG_COMPAT
>.compat_ioctl = radeon_compat_ioctl,
>  #endif
> @@ -304,6 +305,7 @@ static struct drm_driver kms_driver = {
>.mmap = radeon_mmap,
>.poll = drm_poll,
>.fasync = drm_fasync,
> +  .read = drm_read,
>  #ifdef CONFIG_COMPAT
>.compat_ioctl = radeon_kms_compat_ioctl,
>  #endif

At least the KMS DRM minor should be bumped for this and checked by the
X driver before enabling the DRI2 functionality that needs it, otherwise
clients trying to use that functionality will hang.


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=28003

Chia-I Wu  changed:

   What|Removed |Added

 CC||airlied at freedesktop.org

--- Comment #4 from Chia-I Wu  2010-05-07 01:53:20 PDT ---
(In reply to comment #3)
> Indeed. There should never be a need for copies for texture-from-pixmap 
> anyway,
> should probably use a sampler view.
The assertion failure is hit when using an RGBA pixmap as an RGB texture.  It
was discussed here

  http://www.mail-archive.com/mesa3d-dev at lists.sourceforge.net/msg12992.html

and using a sampler view should be the correct fix to my knowledge.

I might not be able to find the time to work on it anytime soon.  If no one
volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for RGBA visuals
should be a valid workaround, if compiz does check the attribute.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for 
> RGBA
> visuals should be a valid workaround, if compiz does check the attribute.

I suspect that would take about the same amount of work, and I wouldn't
consider it very useful (not sure if compiz/kwin/... could even handle it).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: async event synchronization for drmWaitVblank

2010-05-07 Thread Jerome Glisse

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 patch event never get delivered
> > to userspace client.
> > 
> > Signed-off-by: Jerome Glisse 
> > ---
> >  drivers/gpu/drm/radeon/radeon_drv.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> > b/drivers/gpu/drm/radeon/radeon_drv.c
> > index 4b05563..b3749d4 100644
> > --- a/drivers/gpu/drm/radeon/radeon_drv.c
> > +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> > @@ -216,6 +216,7 @@ static struct drm_driver driver_old = {
> >  .mmap = drm_mmap,
> >  .poll = drm_poll,
> >  .fasync = drm_fasync,
> > +.read = drm_read,
> >  #ifdef CONFIG_COMPAT
> >  .compat_ioctl = radeon_compat_ioctl,
> >  #endif
> > @@ -304,6 +305,7 @@ static struct drm_driver kms_driver = {
> >  .mmap = radeon_mmap,
> >  .poll = drm_poll,
> >  .fasync = drm_fasync,
> > +.read = drm_read,
> >  #ifdef CONFIG_COMPAT
> >  .compat_ioctl = radeon_kms_compat_ioctl,
> >  #endif
> 
> At least the KMS DRM minor should be bumped for this and checked by the
> X driver before enabling the DRI2 functionality that needs it, otherwise
> clients trying to use that functionality will hang.
> 

I need another interface change before using this functionality
i will bump minor with the new interface i will send patch today.

Cheers,
Jerome

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 assertion failure

Does this patch help?  It effectively reverts
968bf9634ec03e61441834603f13f0c914bbb0ce by ignoring internal_format in
st/mesa.  It is better than reverting the commit in that the workaround is
closer to the bug (both in st/mesa).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 though.
> 
> > If no one volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for 
> > RGBA
> > visuals should be a valid workaround, if compiz does check the attribute.
> 
> I suspect that would take about the same amount of work, and I wouldn't
> consider it very useful (not sure if compiz/kwin/... could even handle it).
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
help me verify the patch?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28003] [r300g] Compiz fails to start using gallium on rv350.

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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
^
I meant, "wrong, but better than the assertion failure".  I am sorry to
introduce the regression in the first place.
> help me verify the patch?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28016] New: [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: astronomo at op.pl


Created an attachment (id=35492)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=35492)
kernel log with the backtrace

I have tested recent branches drm-radeon-testing (last commit
7a1ffce50373c177d3f6eecce52badc40c90e1dd) and drm-next (last commit
9e51159c14c29ebd485a45ba56f148e180d62c29) from
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git.  These branches
contain patches for enabling unmappable VRAM. However, soon after booting I am
getting a GPU lockup and corrupted console and X.

My hardware is laptop ASUS M50SA with 4GB system memory, and graphics 1GB
Mobility Radeon HD 3650.

I am attaching the kernel output with the backtrace and lspci -v output.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=28016

Grzegorz Kowal  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 everything works fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=28016

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Alex Deucher  2010-05-07 06:18:03 PDT 
---


*** This bug has been marked as a duplicate of bug 27822 ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 27822] [REGR] Soft lockup with "[TTM] Buffer eviction failed" on resume

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=27822

Alex Deucher  changed:

   What|Removed |Added

 CC||astronomo at op.pl

--- Comment #10 from Alex Deucher  2010-05-07 06:18:03 PDT 
---
*** Bug 28016 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html )

Installing that library has solved the textures and bitmaps corruption problem,
thanks! However, the GPU still hangs as mentionned in dmesg.

I tried getting a dump, but I couldn't find intel_reg_dumper in
intel-gpu-tools-1.0.2, I only found intel_gpu_dump. However, it doesn't work as
a user, and it hangs the machine as root, forcing me to reboot (I tried
intel_gpu_dump > gpu_dump as root, and the machine becomes completely
unresponsive).

> - Setting "Enable S3TC texture compression" to "Yes" in driconf. (or just
> force_s3tc_enable=true )

I couldn't find driconf, and I don't know where to put force_s3tc_enable=true;
however, since installing libtxc_dxtn worked, I guess it isn't mandatory?

Thanks for your help!

-- 
F. Delente

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 tried getting a dump, but I couldn't find intel_reg_dumper in
> intel-gpu-tools-1.0.2, I only found intel_gpu_dump. However, it doesn't work 
> as
> a user, and it hangs the machine as root, forcing me to reboot (I tried
> intel_gpu_dump > gpu_dump as root, and the machine becomes completely
> unresponsive).

The GPU reset function will probably mean that you won't get a meaningful dump
with that kernel anyway. The best way is to retry with git master of Mesa, and
the latest rc of 2.6.34. 

If the hang is still there, grab a dump with intel_error_decode.

(At least this is what I usually do.)

> I couldn't find driconf, and I don't know where to put force_s3tc_enable=true;
> however, since installing libtxc_dxtn worked, I guess it isn't mandatory?

No, shouldn't be necessary if the lib is used.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 27868] [r600] on new campaign, Vegastrike crashes or freezes Xorg

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 after "valide"

PATCH:

I have run into a crash after a "cannot valide it" warning.  The unmap function
in radeon_bo_legacy is called sometimes when the memory is no longer mapped. 
The radeon_bo_legacy->map_count goes negative which means statements like

if (radeon_bo_legacy->map_count) ...

will return true.

The attached patch prevents the count from going negative and fixes the crash
for me.

Crash was with the r200 driver (Radeon 9250SE) playing UrbanTerror using UMS. 
I made the patch using the Ubuntu Lucid 10.04 source package.

Bobby

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Jerome Glisse

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 ++
 include/drm/radeon_drm.h|1 +
 3 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index b3749d4..df96ace 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -44,9 +44,10 @@
  * - 2.1.0 - add square tiling interface
  * - 2.2.0 - add r6xx/r7xx const buffer support
  * - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
+ * - 2.4.0 - add crtc id query
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   3
+#define KMS_DRIVER_MINOR   4
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index d3657dc..04ad452 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
 {
struct radeon_device *rdev = dev->dev_private;
struct drm_radeon_info *info;
+   struct radeon_mode_info *minfo = &rdev->mode_info;
uint32_t *value_ptr;
uint32_t value;
+   struct drm_crtc *crtc;
+   int i, found;

info = data;
value_ptr = (uint32_t *)((unsigned long)info->value);
+   value = *value_ptr;
switch (info->request) {
case RADEON_INFO_DEVICE_ID:
value = dev->pci_device;
@@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
case RADEON_INFO_ACCEL_WORKING:
value = rdev->accel_working;
break;
+   case RADEON_INFO_CRTC_FROM_ID:
+   for (i = 0, found = 0; i < 6; i++) {
+   crtc = (struct drm_crtc *)minfo->crtcs[i];
+   if (crtc && crtc->base.id == value) {
+   value = i;
+   found = 1;
+   break;
+   }
+   }
+   if (!found) {
+   DRM_ERROR("unknown crtc id %d\n", value);
+   return -EINVAL;
+   }
+   break;
default:
DRM_DEBUG("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 81e614b..3ff9fc0 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -902,6 +902,7 @@ struct drm_radeon_cs {
 #define RADEON_INFO_NUM_GB_PIPES   0x01
 #define RADEON_INFO_NUM_Z_PIPES0x02
 #define RADEON_INFO_ACCEL_WORKING  0x03
+#define RADEON_INFO_CRTC_FROM_ID   0x04

 struct drm_radeon_info {
uint32_trequest;
-- 
1.7.0.1

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=28016

Grzegorz Kowal  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |

--- Comment #4 from Grzegorz Kowal  2010-05-07 08:35:57 PDT 
---
I am reopening the bug since the patch included in bug 27822 does not resolve
my problem.

I have tested once again the recent branch drm-next with the last commit
"drm/ttm: fix, avoid iomapping system memory"
(9e51159c14c29ebd485a45ba56f148e180d62c29) and the problem remains.

I am attaching dmesg output from this as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28016] [REGR] RV635 GPU lockup after enabling unmappable VRAM V2 (KMS, Radeon)

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Alex Deucher

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 via relocs?

Alex

>
> Signed-off-by: Jerome Glisse 
> ---
> ?drivers/gpu/drm/radeon/radeon_drv.c | ? ?3 ++-
> ?drivers/gpu/drm/radeon/radeon_kms.c | ? 18 ++
> ?include/drm/radeon_drm.h ? ? ? ? ? ?| ? ?1 +
> ?3 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index b3749d4..df96ace 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -44,9 +44,10 @@
> ?* - 2.1.0 - add square tiling interface
> ?* - 2.2.0 - add r6xx/r7xx const buffer support
> ?* - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
> + * - 2.4.0 - add crtc id query
> ?*/
> ?#define KMS_DRIVER_MAJOR ? ? ? 2
> -#define KMS_DRIVER_MINOR ? ? ? 3
> +#define KMS_DRIVER_MINOR ? ? ? 4
> ?#define KMS_DRIVER_PATCHLEVEL ?0
> ?int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
> ?int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index d3657dc..04ad452 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
> ?{
> ? ? ? ?struct radeon_device *rdev = dev->dev_private;
> ? ? ? ?struct drm_radeon_info *info;
> + ? ? ? struct radeon_mode_info *minfo = &rdev->mode_info;
> ? ? ? ?uint32_t *value_ptr;
> ? ? ? ?uint32_t value;
> + ? ? ? struct drm_crtc *crtc;
> + ? ? ? int i, found;
>
> ? ? ? ?info = data;
> ? ? ? ?value_ptr = (uint32_t *)((unsigned long)info->value);
> + ? ? ? value = *value_ptr;
> ? ? ? ?switch (info->request) {
> ? ? ? ?case RADEON_INFO_DEVICE_ID:
> ? ? ? ? ? ? ? ?value = dev->pci_device;
> @@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
> ? ? ? ?case RADEON_INFO_ACCEL_WORKING:
> ? ? ? ? ? ? ? ?value = rdev->accel_working;
> ? ? ? ? ? ? ? ?break;
> + ? ? ? case RADEON_INFO_CRTC_FROM_ID:
> + ? ? ? ? ? ? ? for (i = 0, found = 0; i < 6; i++) {
> + ? ? ? ? ? ? ? ? ? ? ? crtc = (struct drm_crtc *)minfo->crtcs[i];
> + ? ? ? ? ? ? ? ? ? ? ? if (crtc && crtc->base.id == value) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? value = i;
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? found = 1;
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? if (!found) {
> + ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("unknown crtc id %d\n", value);
> + ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?DRM_DEBUG("Invalid request %d\n", info->request);
> ? ? ? ? ? ? ? ?return -EINVAL;
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 81e614b..3ff9fc0 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -902,6 +902,7 @@ struct drm_radeon_cs {
> ?#define RADEON_INFO_NUM_GB_PIPES ? ? ? 0x01
> ?#define RADEON_INFO_NUM_Z_PIPES ? ? ? ?0x02
> ?#define RADEON_INFO_ACCEL_WORKING ? ? ?0x03
> +#define RADEON_INFO_CRTC_FROM_ID ? ? ? 0x04
>
> ?struct drm_radeon_info {
> ? ? ? ?uint32_t ? ? ? ? ? ? ? ?request;
> --
> 1.7.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Jerome Glisse

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.
> 
> Just curious what we need this for?  Couldn't the id be handled in the
> drm via relocs?
> 
> Alex
> 

It's for vblank event, i would have prefer that vblank event
directly took kms crtc id but as intel also supported UMS this
wasn't an option i guess. I am pondering on adding a new interface
which directly took drm crtc_id.

Cheers,
Jerome

[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info

2010-05-07 Thread Alex Deucher

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 what we need this for? ?Couldn't the id be handled in the
> drm via relocs?
>

Nevermind, just saw the ddx patch.

> Alex
>
>>
>> Signed-off-by: Jerome Glisse 
>> ---
>> ?drivers/gpu/drm/radeon/radeon_drv.c | ? ?3 ++-
>> ?drivers/gpu/drm/radeon/radeon_kms.c | ? 18 ++
>> ?include/drm/radeon_drm.h ? ? ? ? ? ?| ? ?1 +
>> ?3 files changed, 21 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index b3749d4..df96ace 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -44,9 +44,10 @@
>> ?* - 2.1.0 - add square tiling interface
>> ?* - 2.2.0 - add r6xx/r7xx const buffer support
>> ?* - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
>> + * - 2.4.0 - add crtc id query
>> ?*/
>> ?#define KMS_DRIVER_MAJOR ? ? ? 2
>> -#define KMS_DRIVER_MINOR ? ? ? 3
>> +#define KMS_DRIVER_MINOR ? ? ? 4
>> ?#define KMS_DRIVER_PATCHLEVEL ?0
>> ?int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>> ?int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index d3657dc..04ad452 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>> ?{
>> ? ? ? ?struct radeon_device *rdev = dev->dev_private;
>> ? ? ? ?struct drm_radeon_info *info;
>> + ? ? ? struct radeon_mode_info *minfo = &rdev->mode_info;
>> ? ? ? ?uint32_t *value_ptr;
>> ? ? ? ?uint32_t value;
>> + ? ? ? struct drm_crtc *crtc;
>> + ? ? ? int i, found;
>>
>> ? ? ? ?info = data;
>> ? ? ? ?value_ptr = (uint32_t *)((unsigned long)info->value);
>> + ? ? ? value = *value_ptr;
>> ? ? ? ?switch (info->request) {
>> ? ? ? ?case RADEON_INFO_DEVICE_ID:
>> ? ? ? ? ? ? ? ?value = dev->pci_device;
>> @@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>> ? ? ? ?case RADEON_INFO_ACCEL_WORKING:
>> ? ? ? ? ? ? ? ?value = rdev->accel_working;
>> ? ? ? ? ? ? ? ?break;
>> + ? ? ? case RADEON_INFO_CRTC_FROM_ID:
>> + ? ? ? ? ? ? ? for (i = 0, found = 0; i < 6; i++) {
>> + ? ? ? ? ? ? ? ? ? ? ? crtc = (struct drm_crtc *)minfo->crtcs[i];
>> + ? ? ? ? ? ? ? ? ? ? ? if (crtc && crtc->base.id == value) {
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? value = i;
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? found = 1;
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
>> + ? ? ? ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? if (!found) {
>> + ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("unknown crtc id %d\n", value);
>> + ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
>> + ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? break;
>> ? ? ? ?default:
>> ? ? ? ? ? ? ? ?DRM_DEBUG("Invalid request %d\n", info->request);
>> ? ? ? ? ? ? ? ?return -EINVAL;
>> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
>> index 81e614b..3ff9fc0 100644
>> --- a/include/drm/radeon_drm.h
>> +++ b/include/drm/radeon_drm.h
>> @@ -902,6 +902,7 @@ struct drm_radeon_cs {
>> ?#define RADEON_INFO_NUM_GB_PIPES ? ? ? 0x01
>> ?#define RADEON_INFO_NUM_Z_PIPES ? ? ? ?0x02
>> ?#define RADEON_INFO_ACCEL_WORKING ? ? ?0x03
>> +#define RADEON_INFO_CRTC_FROM_ID ? ? ? 0x04
>>
>> ?struct drm_radeon_info {
>> ? ? ? ?uint32_t ? ? ? ? ? ? ? ?request;
>> --
>> 1.7.0.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 are distorted: the polygons extend out of
the characters(?).

Furthermore, about 1 pixel is chopped of the letters (see screenshot).

Thanks again anyway!

-- 
F. Delente

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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?)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 3382] Dynamically generate GL dispatch functions for ia64

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=3382

Kristian H?gsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Kristian H?gsberg  2010-05-07 
10:28:53 PDT ---
Not going to happen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28000] [Mobile GM965/GL96][Wine][3D] Display and textures corrupted in Warhammer 40k Soulstorm

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 letters (see screenshot).

These I can't reproduce, sorry.

I guess either the demo isn't enough to reproduce this, or it's a problem
specific to your hardware (I use a X4500HD).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 11093] libdrm COPYING file

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=11093

Kristian H?gsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #2 from Kristian H?gsberg  2010-05-07 
13:11:27 PDT ---
Thanks, but I suspect we won't be able to keep that up to date.  The copyright
terms are in the individual files.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 20961] libdrm_intel segfault on Firefox load

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 this mail because: ---
You are the assignee for the bug.

[Bug 21777] libdrm-2.4.11 fails with LDFLAGS="-Wl,--as-needed"

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=21777

Kristian H?gsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Kristian H?gsberg  2010-05-07 
13:14:14 PDT ---
Looks like this got worked out, if not please reopen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms/atom: disable the encoders in encoder_disable

2010-05-07 Thread Alex Deucher

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/drivers/gpu/drm/radeon/radeon_encoders.c
index 559c9ce..607d00b 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1504,10 +1504,49 @@ static void radeon_atom_encoder_commit(struct 
drm_encoder *encoder)

 static void radeon_atom_encoder_disable(struct drm_encoder *encoder)
 {
+   struct drm_device *dev = encoder->dev;
+   struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig;
radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);

+   switch (radeon_encoder->encoder_id) {
+   case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+   case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+   atombios_digital_setup(encoder, PANEL_ENCODER_ACTION_DISABLE);
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+   if (ASIC_IS_DCE4(rdev))
+   /* disable the transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   else {
+   /* disable the encoder and transmitter */
+   atombios_dig_transmitter_setup(encoder, 
ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
+   atombios_dig_encoder_setup(encoder, ATOM_DISABLE);
+   }
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_DDI:
+   atombios_ddia_setup(encoder, ATOM_DISABLE);
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+   atombios_external_tmds_setup(encoder, ATOM_DISABLE);
+   break;
+   case ENCODER_OBJECT_ID_INTERNAL_DAC1:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1:
+   case ENCODER_OBJECT_ID_INTERNAL_DAC2:
+   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
+   atombios_dac_setup(encoder, ATOM_DISABLE);
+   if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT | 
ATOM_DEVICE_CV_SUPPORT))
+   atombios_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

[PATCH 0/9] drm/radeon/kms: update pm code

2010-05-07 Thread Alex Deucher

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 methods via sysfs.  Echo "dynpm" or "profile" to
/sys/class/drm/card-0/device/power_method.

The "dynpm" method dynamically changes the clocks based on the number of pending
fences, so performance is ramped up when running GPU intensive apps, and
ramped down when the GPU is idle.  The reclocking is attemped during
vertical blanking periods, but due to the timing of the reclocking
functions, doesn't not always complete in the blanking period, which can
lead to flicker in the display.  Due to this, dynpm only works when a single
head is active.

The "profile" method exposes 4 profiles that can be selected from:
1. "default"
2. "auto"
3. "low"
4. "high"
Select the profile by echoing the selected profile to
/sys/class/drm/card-0/device/power_profile.

"default" uses the default clocks and does not change the power state.  This is
the default behavior.
"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.
"low" forces the gpu to be in the low power state all the time.  Even lower 
power
states are selected when the monitors are in the dpms off state.
"high" forces the gpu to be in the high power state all the time.  Even lower 
power
states are selected when the monitors are in the dpms off state.

The "profile" method is not as agressive as "dynpm," but is currently much more
stable and flicker free and works with multiple heads active.

The default power management method is "profile" using the "default" profile.
The default should eventaully be changed to "profile" "auto".

For upstream, we may want to squash some of these.  I'm open to suggestions.
Everthing that's been added since drm-linus?

Alex

[PATCH 1/9] drm/radeon/kms: enable misc pm power state features on r5xx, rs6xx

2010-05-07 Thread Alex Deucher

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/drivers/gpu/drm/radeon/rs600.c
index c3890b7..8e0c460 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -48,12 +48,11 @@ int rs600_mc_wait_for_idle(struct radeon_device *rdev);

 void rs600_pm_misc(struct radeon_device *rdev)
 {
-#if 0
int requested_index = rdev->pm.requested_power_state_index;
struct radeon_power_state *ps = &rdev->pm.power_state[requested_index];
struct radeon_voltage *voltage = &ps->clock_info[0].voltage;
u32 tmp, dyn_pwrmgt_sclk_length, dyn_sclk_vol_cntl;
-   u32 hdp_dyn_cntl, mc_host_dyn_cntl;
+   u32 hdp_dyn_cntl, /*mc_host_dyn_cntl,*/ dyn_backbias_cntl;

if ((voltage->type == VOLTAGE_GPIO) && (voltage->gpio.valid)) {
if (ps->misc & ATOM_PM_MISCINFO_VOLTAGE_DROP_SUPPORT) {
@@ -112,13 +111,21 @@ void rs600_pm_misc(struct radeon_device *rdev)
else
hdp_dyn_cntl |= HDP_FORCEON;
WREG32_PLL(HDP_DYN_CNTL, hdp_dyn_cntl);
-
+#if 0
+   /* mc_host_dyn seems to cause hangs from time to time */
mc_host_dyn_cntl = RREG32_PLL(MC_HOST_DYN_CNTL);
if (ps->misc & ATOM_PM_MISCINFO_DYNAMIC_MC_HOST_BLOCK_EN)
mc_host_dyn_cntl &= ~MC_HOST_FORCEON;
else
mc_host_dyn_cntl |= MC_HOST_FORCEON;
WREG32_PLL(MC_HOST_DYN_CNTL, mc_host_dyn_cntl);
+#endif
+   dyn_backbias_cntl = RREG32_PLL(DYN_BACKBIAS_CNTL);
+   if (ps->misc & ATOM_PM_MISCINFO2_DYNAMIC_BACK_BIAS_EN)
+   dyn_backbias_cntl |= IO_CG_BACKBIAS_EN;
+   else
+   dyn_backbias_cntl &= ~IO_CG_BACKBIAS_EN;
+   WREG32_PLL(DYN_BACKBIAS_CNTL, dyn_backbias_cntl);

/* set pcie lanes */
if ((rdev->flags & RADEON_IS_PCIE) &&
@@ -130,7 +137,6 @@ void rs600_pm_misc(struct radeon_device *rdev)
  ps->pcie_lanes);
DRM_INFO("Setting: p: %d\n", ps->pcie_lanes);
}
-#endif
 }

 void rs600_pm_prepare(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rs600d.h b/drivers/gpu/drm/radeon/rs600d.h
index 8f62434..a27c13a 100644
--- a/drivers/gpu/drm/radeon/rs600d.h
+++ b/drivers/gpu/drm/radeon/rs600d.h
@@ -655,6 +655,8 @@
 #define   HDP_FORCEON  (1 << 0)
 #define MC_HOST_DYN_CNTL   0x1e
 #define   MC_HOST_FORCEON  (1 << 0)
+#define DYN_BACKBIAS_CNTL  0x29
+#define   IO_CG_BACKBIAS_EN(1 << 0)

 /* mmreg */
 #define DOUT_POWER_MANAGEMENT_CNTL 0x7ee0
-- 
1.5.6.3

[PATCH 2/9] drm/radeon/kms: enable misc pm power state features on r1xx-r4xx

2010-05-07 Thread Alex Deucher

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
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -220,7 +220,6 @@ void r100_set_power_state(struct radeon_device *rdev, bool 
static_switch)

 void r100_pm_misc(struct radeon_device *rdev)
 {
-#if 0
int requested_index = rdev->pm.requested_power_state_index;
struct radeon_power_state *ps = &rdev->pm.power_state[requested_index];
struct radeon_voltage *voltage = &ps->clock_info[0].voltage;
@@ -308,7 +307,6 @@ void r100_pm_misc(struct radeon_device *rdev)
  ps->pcie_lanes);
DRM_INFO("Setting: p: %d\n", ps->pcie_lanes);
}
-#endif
 }

 void r100_pm_prepare(struct radeon_device *rdev)
-- 
1.5.6.3

[PATCH 3/9] drm/radeon/kms: re-enable gui idle interrupts on r6xx+

2010-05-07 Thread Alex Deucher

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/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -64,17 +64,19 @@ static void radeon_pm_set_clocks(struct radeon_device 
*rdev, int static_switch)
mutex_lock(&rdev->ddev->struct_mutex);
mutex_lock(&rdev->vram_mutex);
mutex_lock(&rdev->cp.mutex);
-#if 0
-   /* wait for GPU idle */
-   rdev->pm.gui_idle = false;
-   rdev->irq.gui_idle = true;
-   radeon_irq_set(rdev);
-   wait_event_interruptible_timeout(
-   rdev->irq.idle_queue, rdev->pm.gui_idle,
-   msecs_to_jiffies(RADEON_WAIT_IDLE_TIMEOUT));
-   rdev->irq.gui_idle = false;
-   radeon_irq_set(rdev);
-#endif
+
+   /* gui idle int has issues on older chips it seems */
+   if (rdev->family >= CHIP_R600) {
+   /* wait for GPU idle */
+   rdev->pm.gui_idle = false;
+   rdev->irq.gui_idle = true;
+   radeon_irq_set(rdev);
+   wait_event_interruptible_timeout(
+   rdev->irq.idle_queue, rdev->pm.gui_idle,
+   msecs_to_jiffies(RADEON_WAIT_IDLE_TIMEOUT));
+   rdev->irq.gui_idle = false;
+   radeon_irq_set(rdev);
+   }
radeon_unmap_vram_bos(rdev);

if (!static_switch) {
-- 
1.5.6.3

[PATCH 4/9] radeon: Split out ring locking and allocation

2010-05-07 Thread Alex Deucher

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 +--
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 93ac88e..e39e2b4 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -471,7 +471,9 @@ int radeon_ib_test(struct radeon_device *rdev);
 extern void radeon_ib_bogus_add(struct radeon_device *rdev, struct radeon_ib 
*ib);
 /* Ring access between begin & end cannot sleep */
 void radeon_ring_free_size(struct radeon_device *rdev);
+int radeon_ring_alloc(struct radeon_device *rdev, unsigned ndw);
 int radeon_ring_lock(struct radeon_device *rdev, unsigned ndw);
+void radeon_ring_commit(struct radeon_device *rdev);
 void radeon_ring_unlock_commit(struct radeon_device *rdev);
 void radeon_ring_unlock_undo(struct radeon_device *rdev);
 int radeon_ring_test(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index f6e1e8d..6cc4259 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -258,31 +258,41 @@ void radeon_ring_free_size(struct radeon_device *rdev)
}
 }

-int radeon_ring_lock(struct radeon_device *rdev, unsigned ndw)
+int radeon_ring_alloc(struct radeon_device *rdev, unsigned ndw)
 {
int r;

/* Align requested size with padding so unlock_commit can
 * pad safely */
ndw = (ndw + rdev->cp.align_mask) & ~rdev->cp.align_mask;
-   mutex_lock(&rdev->cp.mutex);
while (ndw > (rdev->cp.ring_free_dw - 1)) {
radeon_ring_free_size(rdev);
if (ndw < rdev->cp.ring_free_dw) {
break;
}
r = radeon_fence_wait_next(rdev);
-   if (r) {
-   mutex_unlock(&rdev->cp.mutex);
+   if (r)
return r;
-   }
}
rdev->cp.count_dw = ndw;
rdev->cp.wptr_old = rdev->cp.wptr;
return 0;
 }

-void radeon_ring_unlock_commit(struct radeon_device *rdev)
+int radeon_ring_lock(struct radeon_device *rdev, unsigned ndw)
+{
+   int r;
+
+   mutex_lock(&rdev->cp.mutex);
+   r = radeon_ring_alloc(rdev, ndw);
+   if (r) {
+   mutex_unlock(&rdev->cp.mutex);
+   return r;
+   }
+   return 0;
+}
+
+void radeon_ring_commit(struct radeon_device *rdev)
 {
unsigned count_dw_pad;
unsigned i;
@@ -295,6 +305,11 @@ void radeon_ring_unlock_commit(struct radeon_device *rdev)
}
DRM_MEMORYBARRIER();
radeon_cp_commit(rdev);
+}
+
+void radeon_ring_unlock_commit(struct radeon_device *rdev)
+{
+   radeon_ring_commit(rdev);
mutex_unlock(&rdev->cp.mutex);
 }

-- 
1.5.6.3

[PATCH 5/9] radeon: Use fences to gate entry to reclocking on

2010-05-07 Thread Alex Deucher

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/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index bded834..1ee7fc9 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -76,6 +76,14 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev, 
int static_switch)
msecs_to_jiffies(RADEON_WAIT_IDLE_TIMEOUT));
rdev->irq.gui_idle = false;
radeon_irq_set(rdev);
+   } else {
+   struct radeon_fence *fence;
+   radeon_ring_alloc(rdev, 64);
+   radeon_fence_create(rdev, &fence);
+   radeon_fence_emit(rdev, fence);
+   radeon_ring_commit(rdev);
+   radeon_fence_wait(fence, false);
+   radeon_fence_unref(&fence);
}
radeon_unmap_vram_bos(rdev);

-- 
1.5.6.3

[PATCH 6/9] drm/radeon/kms: fix lock ordering in ring, ib handling

2010-05-07 Thread Alex Deucher

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/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -219,24 +219,26 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
 void radeon_ib_pool_fini(struct radeon_device *rdev)
 {
int r;
+   struct radeon_bo *robj;

if (!rdev->ib_pool.ready) {
return;
}
mutex_lock(&rdev->ib_pool.mutex);
radeon_ib_bogus_cleanup(rdev);
+   robj = rdev->ib_pool.robj;
+   rdev->ib_pool.robj = NULL;
+   mutex_unlock(&rdev->ib_pool.mutex);

-   if (rdev->ib_pool.robj) {
-   r = radeon_bo_reserve(rdev->ib_pool.robj, false);
+   if (robj) {
+   r = radeon_bo_reserve(robj, false);
if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev->ib_pool.robj);
-   radeon_bo_unpin(rdev->ib_pool.robj);
-   radeon_bo_unreserve(rdev->ib_pool.robj);
+   radeon_bo_kunmap(robj);
+   radeon_bo_unpin(robj);
+   radeon_bo_unreserve(robj);
}
-   radeon_bo_unref(&rdev->ib_pool.robj);
-   rdev->ib_pool.robj = NULL;
+   radeon_bo_unref(&robj);
}
-   mutex_unlock(&rdev->ib_pool.mutex);
 }


@@ -359,20 +361,23 @@ int radeon_ring_init(struct radeon_device *rdev, unsigned 
ring_size)
 void radeon_ring_fini(struct radeon_device *rdev)
 {
int r;
+   struct radeon_bo *ring_obj;

mutex_lock(&rdev->cp.mutex);
-   if (rdev->cp.ring_obj) {
-   r = radeon_bo_reserve(rdev->cp.ring_obj, false);
+   ring_obj = rdev->cp.ring_obj;
+   rdev->cp.ring = NULL;
+   rdev->cp.ring_obj = NULL;
+   mutex_unlock(&rdev->cp.mutex);
+
+   if (ring_obj) {
+   r = radeon_bo_reserve(ring_obj, false);
if (likely(r == 0)) {
-   radeon_bo_kunmap(rdev->cp.ring_obj);
-   radeon_bo_unpin(rdev->cp.ring_obj);
-   radeon_bo_unreserve(rdev->cp.ring_obj);
+   radeon_bo_kunmap(ring_obj);
+   radeon_bo_unpin(ring_obj);
+   radeon_bo_unreserve(ring_obj);
}
-   radeon_bo_unref(&rdev->cp.ring_obj);
-   rdev->cp.ring = NULL;
-   rdev->cp.ring_obj = NULL;
+   radeon_bo_unref(&ring_obj);
}
-   mutex_unlock(&rdev->cp.mutex);
 }


-- 
1.5.6.3

[PATCH 7/9] drm/radeon/kms/pm: add support for no display power states

2010-05-07 Thread Alex Deucher

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   |   20 --
 drivers/gpu/drm/radeon/radeon.h |7 +++-
 drivers/gpu/drm/radeon/radeon_atombios.c|   37 ++
 drivers/gpu/drm/radeon/radeon_combios.c |2 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |9 +++---
 drivers/gpu/drm/radeon/radeon_pm.c  |   38 ++
 8 files changed, 94 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 4151ad8..03dd6c4 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -245,13 +245,15 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)

switch (mode) {
case DRM_MODE_DPMS_ON:
+   radeon_crtc->enabled = true;
+   /* adjust pm to dpms changes BEFORE enabling crtcs */
+   radeon_pm_compute_clocks(rdev);
atombios_enable_crtc(crtc, ATOM_ENABLE);
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, ATOM_ENABLE);
atombios_blank_crtc(crtc, ATOM_DISABLE);
drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
radeon_crtc_load_lut(crtc);
-   radeon_crtc->enabled = true;
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
@@ -262,11 +264,10 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
atombios_enable_crtc_memreq(crtc, ATOM_DISABLE);
atombios_enable_crtc(crtc, ATOM_DISABLE);
radeon_crtc->enabled = false;
+   /* adjust pm to dpms changes AFTER disabling crtcs */
+   radeon_pm_compute_clocks(rdev);
break;
}
-
-   /* adjust pm to dpms change */
-   radeon_pm_compute_clocks(rdev);
 }

 static void
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 14b7541..4161a35 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -87,7 +87,7 @@ void r100_get_power_state(struct radeon_device *rdev,
} else {
if (rdev->pm.active_crtc_count > 1) {
for (i = 0; i < rdev->pm.num_power_states; i++) 
{
-   if (rdev->pm.power_state[i].flags & 
RADEON_PM_SINGLE_DISPLAY_ONLY)
+   if (rdev->pm.power_state[i].flags & 
RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
continue;
else if (i >= 
rdev->pm.current_power_state_index) {

rdev->pm.requested_power_state_index = rdev->pm.current_power_state_index;
@@ -101,6 +101,12 @@ void r100_get_power_state(struct radeon_device *rdev,
rdev->pm.requested_power_state_index =
rdev->pm.current_power_state_index - 1;
}
+   /* don't use the power state if crtcs are active and no display 
flag is set */
+   if ((rdev->pm.active_crtc_count > 0) &&
+   
(rdev->pm.power_state[rdev->pm.requested_power_state_index].clock_info[0].flags 
&
+RADEON_PM_MODE_NO_DISPLAY)) {
+   rdev->pm.requested_power_state_index++;
+   }
break;
case PM_ACTION_UPCLOCK:
if (rdev->pm.current_power_state_index == 
(rdev->pm.num_power_states - 1)) {
@@ -109,7 +115,7 @@ void r100_get_power_state(struct radeon_device *rdev,
} else {
if (rdev->pm.active_crtc_count > 1) {
for (i = (rdev->pm.num_power_states - 1); i >= 
0; i--) {
-   if (rdev->pm.power_state[i].flags & 
RADEON_PM_SINGLE_DISPLAY_ONLY)
+   if (rdev->pm.power_state[i].flags & 
RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
continue;
else if (i <= 
rdev->pm.current_power_state_index) {

rdev->pm.requested_power_state_index = rdev->pm.current_power_state_index;
@@ -215,7 +221,7 @@ void r100_set_power_state(struct radeon_device *rdev, bool 
static_switch)
rdev->pm.current_power_state_index = 
rdev->pm.requested_power_state_index;
rdev->pm.current_clock_mode_index = 
rdev->pm.requested_clock_mode_index;
} else
-   DRM_INFO("GUI not idle!!!\n");
+

[PATCH 9/9] drm/radeon/kms/pm: make pm spam debug only

2010-05-07 Thread Alex Deucher

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 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5d21b..9a59ba4 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -141,13 +141,13 @@ void r100_pm_get_dynpm_state(struct radeon_device *rdev)
/* only one clock mode per power state */
rdev->pm.requested_clock_mode_index = 0;

-   DRM_INFO("Requested: e: %d m: %d p: %d\n",
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].sclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].mclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-pcie_lanes);
+   DRM_DEBUG("Requested: e: %d m: %d p: %d\n",
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].sclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].mclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ pcie_lanes);
 }

 void r100_pm_init_profile(struct radeon_device *rdev)
@@ -266,7 +266,7 @@ void r100_pm_misc(struct radeon_device *rdev)
 
rdev->pm.power_state[rdev->pm.current_power_state_index].pcie_lanes)) {
radeon_set_pcie_lanes(rdev,
  ps->pcie_lanes);
-   DRM_INFO("Setting: p: %d\n", ps->pcie_lanes);
+   DRM_DEBUG("Setting: p: %d\n", ps->pcie_lanes);
}
 }

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 618d76d..0fef335 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -251,13 +251,13 @@ void r600_pm_get_dynpm_state(struct radeon_device *rdev)
}
}

-   DRM_INFO("Requested: e: %d m: %d p: %d\n",
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].sclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-clock_info[rdev->pm.requested_clock_mode_index].mclk,
-rdev->pm.power_state[rdev->pm.requested_power_state_index].
-pcie_lanes);
+   DRM_DEBUG("Requested: e: %d m: %d p: %d\n",
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].sclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ clock_info[rdev->pm.requested_clock_mode_index].mclk,
+ rdev->pm.power_state[rdev->pm.requested_power_state_index].
+ pcie_lanes);
 }

 static int r600_pm_get_type_index(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 1827317..c88edae 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -52,9 +52,9 @@ static int radeon_acpi_event(struct notifier_block *nb,

if (strcmp(entry->device_class, ACPI_AC_CLASS) == 0) {
if (power_supply_is_system_supplied() > 0)
-   DRM_INFO("pm: AC\n");
+   DRM_DEBUG("pm: AC\n");
else
-   DRM_INFO("pm: DC\n");
+   DRM_DEBUG("pm: DC\n");

if (rdev->pm.pm_method == PM_METHOD_PROFILE) {
if (rdev->pm.profile == PM_PROFILE_AUTO) {
@@ -183,7 +183,7 @@ static void radeon_set_power_state(struct radeon_device 
*rdev)
radeon_set_engine_clock(rdev, sclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev->pm.current_sclk = sclk;
-   DRM_INFO("Setting: e: %d\n", sclk);
+   DRM_DEBUG("Setting: e: %d\n", sclk);
}

/* set memory clock */
@@ -192,7 +192,7 @@ static void radeon_set_power_state(struct radeon_device 
*rdev)
radeon_set_memory_clock(rdev, mclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev->pm.current_mclk = mclk;
-   DRM_INFO("Setting: m: %d\n", mclk);
+   DRM_DEBUG("Setting: m: %d\n", mclk);
}

s2ram slow resume - radeon versus no_console_suspend?

2010-05-07 Thread Bruno Prémont

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.
> 
> 
> During resume early it looks like every PCI access needs about a second,
> and there are a few cases where during lots of seconds nothing seems to
> happen and the first event following is related to radeon.

This slowness only happens when I run the kernel with no_console_suspend
parameter (e.g. to debug some suspend/resume issue).
This probably means that in this case radeon's PCI config recorded during
suspend and restored during early resume is all but appropriate...

Currently drm/radeon does not suspend when no_console_suspend is provided,
even so when the kernel logging does not happen on tty0 & co.

e.g. I would expect that a kernel run with
  no_console_suspend console=ttyS0
would just skip suspending serial port ttyS0 and not also skip suspending
KMS framebuffer as it currently does.

In most framebuffer devices I see usage of acquire_console_sem() and
release_console_sem() but except for kernel/printk.c and drivers/serial/
code nothing is considering console_suspend_enabled.

Currently I'm not sure what code path prevents suspend of KMS (at least
for radeon) when no_console_suspend has been passed, this code path should
probably have a conditional just as serial to take no_console_suspend only
if it's running kernel's console itself.

Thanks,
Bruno

[PATCH 0/9] drm/radeon/kms: update pm code

2010-05-07 Thread Alex Deucher

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 
>> monitors
>> are in the dpms off state.
>
> Beyond the constraints imposed in terms of some modes not being
> available on battery, I'd prefer to leave the ac/battery decision up to
> userspace. Having it be default behaviour at the kernel level is
> plausibly confusing.

Sounds fine.  Just have userspace switch between the low and high
profiles for battery and ac rather than using auto.  auto is useful as
a user option in the interim while userspace gets updated.

Alex

[Bug 23591] cannot build libdrm-2.4.13: libudev.h: No such file or directory

2010-05-07 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=23591

Kristian H?gsberg  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Kristian H?gsberg  2010-05-07 
16:46:01 PDT ---
As of today (version 2.4.20) this works for me.  The test programs that require
udev are conditional in test/Makefile.am and kick in when udev is enabled and
found.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms/atom: disable the encoders in encoder_disable

2010-05-07 Thread Alex Deucher

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 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/drivers/gpu/drm/radeon/radeon_encoders.c
> index 559c9ce..607d00b 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -1504,10 +1504,49 @@ static void radeon_atom_encoder_commit(struct 
> drm_encoder *encoder)
>
> ?static void radeon_atom_encoder_disable(struct drm_encoder *encoder)
> ?{
> + ? ? ? struct drm_device *dev = encoder->dev;
> + ? ? ? struct radeon_device *rdev = dev->dev_private;
> ? ? ? ?struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> ? ? ? ?struct radeon_encoder_atom_dig *dig;
> ? ? ? ?radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
>
> + ? ? ? switch (radeon_encoder->encoder_id) {
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_LVDS:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
> + ? ? ? ? ? ? ? atombios_digital_setup(encoder, PANEL_ENCODER_ACTION_DISABLE);
> + ? ? ? ? ? ? ? break;
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
> + ? ? ? ? ? ? ? if (ASIC_IS_DCE4(rdev))
> + ? ? ? ? ? ? ? ? ? ? ? /* disable the transmitter */
> + ? ? ? ? ? ? ? ? ? ? ? atombios_dig_transmitter_setup(encoder, 
> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
> + ? ? ? ? ? ? ? else {
> + ? ? ? ? ? ? ? ? ? ? ? /* disable the encoder and transmitter */
> + ? ? ? ? ? ? ? ? ? ? ? atombios_dig_transmitter_setup(encoder, 
> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
> + ? ? ? ? ? ? ? ? ? ? ? atombios_dig_encoder_setup(encoder, ATOM_DISABLE);
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? break;
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DDI:
> + ? ? ? ? ? ? ? atombios_ddia_setup(encoder, ATOM_DISABLE);
> + ? ? ? ? ? ? ? break;
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DVO1:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
> + ? ? ? ? ? ? ? atombios_external_tmds_setup(encoder, ATOM_DISABLE);
> + ? ? ? ? ? ? ? break;
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DAC1:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DAC2:
> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
> + ? ? ? ? ? ? ? atombios_dac_setup(encoder, ATOM_DISABLE);
> + ? ? ? ? ? ? ? if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT | 
> ATOM_DEVICE_CV_SUPPORT))
> + ? ? ? ? ? ? ? ? ? ? ? atombios_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-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>

[PATCH] drm/radeon/kms/atom: disable the encoders in encoder_disable

2010-05-07 Thread Alex Deucher

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 Deucher  wrote:
>> 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/drivers/gpu/drm/radeon/radeon_encoders.c
>> index 559c9ce..607d00b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
>> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
>> @@ -1504,10 +1504,49 @@ static void radeon_atom_encoder_commit(struct 
>> drm_encoder *encoder)
>>
>> ?static void radeon_atom_encoder_disable(struct drm_encoder *encoder)
>> ?{
>> + ? ? ? struct drm_device *dev = encoder->dev;
>> + ? ? ? struct radeon_device *rdev = dev->dev_private;
>> ? ? ? ?struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> ? ? ? ?struct radeon_encoder_atom_dig *dig;
>> ? ? ? ?radeon_atom_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
>>
>> + ? ? ? switch (radeon_encoder->encoder_id) {
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_LVDS:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
>> + ? ? ? ? ? ? ? atombios_digital_setup(encoder, 
>> PANEL_ENCODER_ACTION_DISABLE);
>> + ? ? ? ? ? ? ? break;
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
>> + ? ? ? ? ? ? ? if (ASIC_IS_DCE4(rdev))
>> + ? ? ? ? ? ? ? ? ? ? ? /* disable the transmitter */
>> + ? ? ? ? ? ? ? ? ? ? ? atombios_dig_transmitter_setup(encoder, 
>> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
>> + ? ? ? ? ? ? ? else {
>> + ? ? ? ? ? ? ? ? ? ? ? /* disable the encoder and transmitter */
>> + ? ? ? ? ? ? ? ? ? ? ? atombios_dig_transmitter_setup(encoder, 
>> ATOM_TRANSMITTER_ACTION_DISABLE, 0, 0);
>> + ? ? ? ? ? ? ? ? ? ? ? atombios_dig_encoder_setup(encoder, ATOM_DISABLE);
>> + ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? break;
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DDI:
>> + ? ? ? ? ? ? ? atombios_ddia_setup(encoder, ATOM_DISABLE);
>> + ? ? ? ? ? ? ? break;
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DVO1:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
>> + ? ? ? ? ? ? ? atombios_external_tmds_setup(encoder, ATOM_DISABLE);
>> + ? ? ? ? ? ? ? break;
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DAC1:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_DAC2:
>> + ? ? ? case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
>> + ? ? ? ? ? ? ? atombios_dac_setup(encoder, ATOM_DISABLE);
>> + ? ? ? ? ? ? ? if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT 
>> | ATOM_DEVICE_CV_SUPPORT))
>> + ? ? ? ? ? ? ? ? ? ? ? atombios_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>

[Bug 20961] libdrm_intel segfault on Firefox load

2010-05-07 Thread bugzilla-dae...@freedesktop.org

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 Linux 2.6.32 with KMS and everything seems to be
working.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 8/9] drm/radeon/kms/pm: rework power management

2010-05-07 Thread Alex Deucher

- 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/dc state
  "low" - DC, low power mode
  "high" - AC, performance mode
  The current base profile is "default", but it should switched to "auto" once 
we've tested
  on more systems.  Switching the state is a matter of echoing the requested 
profile to
  power_profile in sysfs.  The lowest power states are selected automatically 
when dpms turns
  the monitors off in all states but default.
- Remove dynamic fence-based reclocking for the moment.  We can revisit this 
later once we
  have basic pm in.
- Move pm init/fini to modesetting path.  pm is tightly coupled with display 
state.  Make sure
  display side is initialized before pm.
- Add pm suspend/resume functions to make sure pm state is properly 
reinitialized on resume.
- Remove dynpm module option.  It's now selectable via sysfs.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/Kconfig  |1 +
 drivers/gpu/drm/radeon/evergreen.c  |3 -
 drivers/gpu/drm/radeon/r100.c   |  128 ++-
 drivers/gpu/drm/radeon/r300.c   |3 -
 drivers/gpu/drm/radeon/r420.c   |   32 ++-
 drivers/gpu/drm/radeon/r520.c   |2 -
 drivers/gpu/drm/radeon/r600.c   |  332 -
 drivers/gpu/drm/radeon/radeon.h |   87 +++--
 drivers/gpu/drm/radeon/radeon_asic.c|   56 ++--
 drivers/gpu/drm/radeon/radeon_asic.h|   12 +-
 drivers/gpu/drm/radeon/radeon_device.c  |2 +
 drivers/gpu/drm/radeon/radeon_display.c |4 +
 drivers/gpu/drm/radeon/radeon_drv.c |4 -
 drivers/gpu/drm/radeon/radeon_pm.c  |  628 +++
 drivers/gpu/drm/radeon/rs400.c  |3 -
 drivers/gpu/drm/radeon/rs600.c  |3 -
 drivers/gpu/drm/radeon/rs690.c  |3 -
 drivers/gpu/drm/radeon/rv515.c  |3 -
 drivers/gpu/drm/radeon/rv770.c  |3 -
 19 files changed, 790 insertions(+), 519 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 1c02d23..80c5b3e 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -1,6 +1,7 @@
 config DRM_RADEON_KMS
bool "Enable modesetting on radeon by default - NEW DRIVER"
depends on DRM_RADEON
+   depends on POWER_SUPPLY
help
  Choose this option if you want kernel modesetting enabled by default.

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 8d86d05..8c8e4d3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2115,8 +2115,6 @@ int evergreen_init(struct radeon_device *rdev)
r = radeon_clocks_init(rdev);
if (r)
return r;
-   /* Initialize power management */
-   radeon_pm_init(rdev);
/* Fence driver */
r = radeon_fence_driver_init(rdev);
if (r)
@@ -2178,7 +2176,6 @@ int evergreen_init(struct radeon_device *rdev)

 void evergreen_fini(struct radeon_device *rdev)
 {
-   radeon_pm_fini(rdev);
/*r600_blit_fini(rdev);*/
r700_cp_fini(rdev);
r600_wb_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4161a35..4c5d21b 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -68,22 +68,21 @@ MODULE_FIRMWARE(FIRMWARE_R520);
  * r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280
  */

-void r100_get_power_state(struct radeon_device *rdev,
- enum radeon_pm_action action)
+void r100_pm_get_dynpm_state(struct radeon_device *rdev)
 {
int i;
-   rdev->pm.can_upclock = true;
-   rdev->pm.can_downclock = true;
+   rdev->pm.dynpm_can_upclock = true;
+   rdev->pm.dynpm_can_downclock = true;

-   switch (action) {
-   case PM_ACTION_MINIMUM:
+   switch (rdev->pm.dynpm_planned_action) {
+   case DYNPM_ACTION_MINIMUM:
rdev->pm.requested_power_state_index = 0;
-   rdev->pm.can_downclock = false;
+   rdev->pm.dynpm_can_downclock = false;
break;
-   case PM_ACTION_DOWNCLOCK:
+   case DYNPM_ACTION_DOWNCLOCK:
if (rdev->pm.current_power_state_index == 0) {
rdev->pm.requested_power_state_index = 
rdev->pm.current_power_state_index;
-   rdev->pm.can_downclock = false;
+   rdev->pm.dynpm_can_downclock = false;
} else {
if (rdev->pm.active_crtc_count > 1) {
for (i = 0; i < rdev->pm.num_power_states; i++) 
{
@@ -108,10 +107,10 @@ void r100_get_power_state(struct radeon_device *rdev,
rdev->pm.requested_po

[PATCH 0/9] drm/radeon/kms: update pm code

2010-05-07 Thread Matthew Garrett

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 in terms of some modes not being 
available on battery, I'd prefer to leave the ac/battery decision up to 
userspace. Having it be default behaviour at the kernel level is 
plausibly confusing.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

95 matches

Mail list logo