[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend

2010-07-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=29062

--- Comment #5 from Alex Deucher  2010-07-21 20:55:44 PDT 
---
Created an attachment (id=37291)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37291
 Review: https://bugs.freedesktop.org/review?bug=29062=37291

fix resume

I've sent the attached patch to Dave to be included upstream.

-- 
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: fix legacy LVDS dpms sequence

2010-07-21 Thread Alex Deucher
Add delay after turning off the LVDS encoder.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16389

Tested-by: Jan Kreuzer 
Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index bad77f4..5688a0c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -108,6 +108,7 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)
udelay(panel_pwr_delay * 1000);
WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
WREG32_PLL(RADEON_PIXCLKS_CNTL, pixclks_cntl);
+   udelay(panel_pwr_delay * 1000);
break;
}

-- 
1.7.1.1



[PATCH] drm/radeon/kms: fix legacy LVDS dpms sequence

2010-07-21 Thread Alex Deucher
Add delay after turning off the LVDS encoder.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16389

Tested-by: Jan Kreuzer 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index bad77f4..5688a0c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -108,6 +108,7 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)
udelay(panel_pwr_delay * 1000);
WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
WREG32_PLL(RADEON_PIXCLKS_CNTL, pixclks_cntl);
+   udelay(panel_pwr_delay * 1000);
break;
}

-- 
1.7.1.1



[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.

2010-07-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28671

--- Comment #29 from Alex Deucher  2010-07-21 17:05:58 PDT 
---
Created an attachment (id=37285)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37285
 Review: https://bugs.freedesktop.org/review?bug=28671=37285

reverse digital encoder mapping

Does this patch help with the digital monitors?

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


[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.

2010-07-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28671

--- Comment #28 from Alex Deucher  2010-07-21 17:05:02 PDT 
---
(In reply to comment #27)
> I tested analog and dmcp works fine. However DVI has no output on monitor with
> either connector.

What's dmcp?  With the analog monitor is the driver able to get an edid from
the monitor on both ports?  check 'xrandr --verbose' to see if there is an
edid.  If so, then we've gotten the ddc lines correct and the digital encoder
are probably reversed.

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


Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Rafał Miłecki
W dniu 21 lipca 2010 11:30 u?ytkownik Rafa? Mi?ecki  
napisa?:
> First bisect try gave me:
> bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
> drm/radeon: optimize default 3D state for r6xx/r7xx blits
>
> I'm leaving today, not sure if I manage to confirm this before next week.

I switched back to rebased drm-radeon-testing and confirmed lockup.
Then reverted that single patch and it helped. I'm quite sure it's the
"bad one".

I use KDE4 with effects enabled, so 3D is enabled here.

Not time to dig into this problem deeper, leaving now.

-- 
Rafa?


[PATCH] drm/radeon/kms: fix RADEON_INFO_CRTC_FROM_ID info ioctl

2010-07-21 Thread Alex Deucher
Return the crtc_id, not the counter value.  They are not
necessarily the same.

Cc: Jerome Glisse 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_kms.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 9012e6f..8931c8e 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -134,7 +134,8 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
for (i = 0, found = 0; i < rdev->num_crtc; i++) {
crtc = (struct drm_crtc *)minfo->crtcs[i];
if (crtc && crtc->base.id == value) {
-   value = i;
+   struct radeon_crtc *radeon_crtc = 
to_radeon_crtc(crtc);
+   value = radeon_crtc->crtc_id;
found = 1;
break;
}
-- 
1.7.1.1



Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Alex Deucher
2010/7/21 Rafa? Mi?ecki :
> W dniu 21 lipca 2010 11:30 u?ytkownik Rafa? Mi?ecki  
> napisa?:
>> First bisect try gave me:
>> bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
>> drm/radeon: optimize default 3D state for r6xx/r7xx blits
>>
>> I'm leaving today, not sure if I manage to confirm this before next week.
>
> I switched back to rebased drm-radeon-testing and confirmed lockup.
> Then reverted that single patch and it helped. I'm quite sure it's the
> "bad one".
>
> I use KDE4 with effects enabled, so 3D is enabled here.
>
> Not time to dig into this problem deeper, leaving now.

When you get back can you revert the original and test version 2 of
that patch (attached).  It puts back the original state, but
reorganizes the emit order to reduce the number of dwords.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-optimize-default-3D-state-for-r6xx-r7xx-b.patch
Type: text/x-patch
Size: 16674 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100721/8cb845b7/attachment-0001.bin>


[Bug 29200] New: [wine] Warcraft 3 crashes after trying to launch again

2010-07-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=29200

   Summary: [wine] Warcraft 3 crashes after trying to launch again
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: magnus at jensenligan.se


Hi, i'm trying to play Warcraft III and i can get it to launch sometimes but if
i exit after a succesful launch it will not launch again and i have to reboot.

i Get error message in dmesg about rejected command stream, please tell me
about how to debug this error further if that will help the driver.

radeon :01:00.0: r600_cs_track_check:286 mask 0x000F | 0x000F no cb
for 0
radeon :01:00.0: r600_packet3_check:1247 invalid cmd stream 470
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream

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


Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Rafał Miłecki
W dniu 21 lipca 2010 00:36 u?ytkownik Dave Airlie  
napisa?:
> On Tue, 2010-07-20 at 23:37 +0200, Rafa? Mi?ecki wrote:
>> OK, next question :/ How can I rebase local d-r-t onto Linus's tree?
>> I've Linus's remote tree added and fetched but can not rebase against
>> it.
>>
>> # git rebase linus
>> Current branch drm-radeon-testing is up to date.
>>
>> # git rebase --onto linus drm-radeon-testing
>> Current branch drm-radeon-testing is up to date.
>>
>
> git rebase linus/master

Thanks a lot!

First bisect try gave me:
bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
drm/radeon: optimize default 3D state for r6xx/r7xx blits

I'm leaving today, not sure if I manage to confirm this before next week.

-- 
Rafa?


[PATCH 1/2] drm: Return EBUSY if the framebuffer is unbound when flipping.

2010-07-21 Thread Dave Airlie
On Sat, 2010-07-17 at 18:08 -0700, Jesse Barnes wrote:
> On Sat, 17 Jul 2010 20:23:26 +0100
> Chris Wilson  wrote:
> 
> > It looks like there is a race condition between unbinding a
> > framebuffer on a hotplug event and user space trying to flip:
> > 
> 
> Nice, yeah that would definitely be a problem.  Alternately we could
> solder everyone's configuration into something they couldn't change. :)
> 
> Reviewed-by: Jesse Barnes 
> 

pushed to drm-core-next.

Thanks,
Dave.



[PATCH] drm: add "auto" dithering method

2010-07-21 Thread Dave Airlie
On Fri, 2010-07-16 at 15:09 +1000, Ben Skeggs wrote:
> From: Ben Skeggs 
> 
> There's no convenient/reliable way for drivers to both obey the dithering
> mode property, and to be able to attempt to provide a good default in all
> cases.
> 
> This commit adds an "auto" method to the property which drivers can default
> to if they wish, whilst still allowing the user to override the choice as
> they do now.

Pushed to drm-core-next.

Thanks,
Dave.



drivers/gpu/drm/radeon/r600_blit.c: fix possible NULL pointer derefernce

2010-07-21 Thread Alexander Y. Fomichev
On Wed, Jul 21, 2010 at 1:29 AM, Alex Deucher  wrote:
> On Tue, Jul 20, 2010 at 5:07 PM, Alexander Y. Fomichev
>  wrote:
>> On Wed, Jul 21, 2010 at 1:00 AM, Alex Deucher  
>> wrote:
>>> On Tue, Jul 20, 2010 at 4:13 PM, Alexander Y. Fomichev
>>>  wrote:
 On Tue, Jul 20, 2010 at 9:37 PM, Alex Deucher  
 wrote:
> On Mon, Jul 19, 2010 at 5:42 PM, Alexander Y. Fomichev
>  wrote:
>> This patch fix possible NULL pointer dereference when
>> r600_prepare_blit_copy tries to fill dev_priv->blit_vb->file_priv
>> without check of dev_priv->blit_vb. dev_priv->blit_vb should be
>> filled by r600_nomm_get_vb but latest can fail with EAGAIN.
>> Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16375
>>
>> ---
>> ?drivers/gpu/drm/radeon/r600_blit.c | ? ?2 ++
>> ?1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
>> b/drivers/gpu/drm/radeon/r600_blit.c
>> index f4fb88e..0df4a2b 100644
>> --- a/drivers/gpu/drm/radeon/r600_blit.c
>> +++ b/drivers/gpu/drm/radeon/r600_blit.c
>> @@ -541,6 +541,8 @@ r600_prepare_blit_copy(struct drm_device *dev, 
>> struct drm_file *file_priv)
>> ? ? ? ?DRM_DEBUG("\n");
>>
>> ? ? ? ?r600_nomm_get_vb(dev);
>> + ? ? ? if (!dev_priv->blit_vb)
>> + ? ? ? ? ? ? ? return;
>
> r600_prepare_blit_copy returns an int so something like this would be 
> better:
> --- a/drivers/gpu/drm/radeon/r600_blit.c
> +++ b/drivers/gpu/drm/radeon/r600_blit.c
> @@ -539,8 +539,10 @@ r600_prepare_blit_copy(struct drm_device *dev,
> struct drm_file *file_priv)
> ?{
> ? ? ? ?drm_radeon_private_t *dev_priv = dev->dev_private;
> ? ? ? ?DRM_DEBUG("\n");
> + ? ? ? int ret = r600_nomm_get_vb(dev);
>
> - ? ? ? r600_nomm_get_vb(dev);
> + ? ? ? if (ret)
> + ? ? ? ? ? ? ? return ret;
>
> ? ? ? ?dev_priv->blit_vb->file_priv = file_priv;
>
>
> Alex
>
>>
>> ? ? ? ?dev_priv->blit_vb->file_priv = file_priv;
>>
>> --
>> 1.7.1.1
>>
>

 i haven't any preferneces, the only thing is - it would be logical
 to have every check in common style, so other cases
 (r600_blit_copy, r600_blit_swap) should be fixed, nop?
>>>
>>> Those are void functions so there's nothing to return.
>>
>> i mean both of them call r600_nomm_get_vb and both of them
>> check if (!dev_priv->blit_vb), not return ?value.I mean would be
>> logical to check it the same way everytime r600_nomm_get_vb
>> gets called.
>
> yeah, either way. ?You just need to return an error in r600_prepare_blit_copy.
uh-huh, i've missed

> Alex
>
>>
>>> Alex
>>>

 --
 Best regards.
 ? ? ?? Alexander Y. Fomichev 

>>>
>>
>>
>>
>> --
>> Best regards.
>> ? ? ?? Alexander Y. Fomichev 
>>
>


-- 
Best regards.
? ? ?? Alexander Y. Fomichev 


[PATCH 4/7] cifs: use workqueue instead of slow-work

2010-07-21 Thread Steve French
On Tue, Jul 20, 2010 at 3:34 PM, Tejun Heo  wrote:
> Workqueue can now handle high concurrency. ?Use system_nrt_wq
> instead of slow-work.
>
> * Updated is_valid_oplock_break() to not call cifs_oplock_break_put()
> ?as advised by Steve French. ?It might cause deadlock. ?Instead,
> ?reference is increased after queueing succeeded and
> ?cifs_oplock_break() briefly grabs GlobalSMBSeslock before putting
> ?the cfile to make sure it doesn't put before the matching get is
> ?finished.
>
> * Anton Blanchard reported that cifs conversion was using now gone
> ?system_single_wq. ?Use system_nrt_wq which provides non-reentrance
> ?guarantee which is enough and much better.
>
> Signed-off-by: Tejun Heo 
> Cc: Steve French 
> Cc: Anton Blanchard 
> ---
> ?fs/cifs/Kconfig ? ?| ? ?1 -
> ?fs/cifs/cifsfs.c ? | ? ?5 -
> ?fs/cifs/cifsglob.h | ? ?8 +---
> ?fs/cifs/dir.c ? ? ?| ? ?2 +-
> ?fs/cifs/file.c ? ? | ? 30 +-
> ?fs/cifs/misc.c ? ? | ? 20 
> ?6 files changed, 31 insertions(+), 35 deletions(-)

Acked-by: Steve French 



-- 
Thanks,

Steve


drivers/gpu/drm/radeon/r600_blit.c: fix possible NULL pointer derefernce

2010-07-21 Thread Dave Airlie
On Wed, 2010-07-21 at 01:07 +0400, Alexander Y. Fomichev wrote:
> On Wed, Jul 21, 2010 at 1:00 AM, Alex Deucher  
> wrote:
> > On Tue, Jul 20, 2010 at 4:13 PM, Alexander Y. Fomichev
> >  wrote:
> >> On Tue, Jul 20, 2010 at 9:37 PM, Alex Deucher  
> >> wrote:
> >>> On Mon, Jul 19, 2010 at 5:42 PM, Alexander Y. Fomichev
> >>>  wrote:
>  This patch fix possible NULL pointer dereference when
>  r600_prepare_blit_copy tries to fill dev_priv->blit_vb->file_priv
>  without check of dev_priv->blit_vb. dev_priv->blit_vb should be
>  filled by r600_nomm_get_vb but latest can fail with EAGAIN.
>  Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16375
> 
>  ---
>   drivers/gpu/drm/radeon/r600_blit.c |2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
>  b/drivers/gpu/drm/radeon/r600_blit.c
>  index f4fb88e..0df4a2b 100644
>  --- a/drivers/gpu/drm/radeon/r600_blit.c
>  +++ b/drivers/gpu/drm/radeon/r600_blit.c
>  @@ -541,6 +541,8 @@ r600_prepare_blit_copy(struct drm_device *dev, 
>  struct drm_file *file_priv)
> DRM_DEBUG("\n");
> 
> r600_nomm_get_vb(dev);
>  +   if (!dev_priv->blit_vb)
>  +   return;
> >>>
> >>> r600_prepare_blit_copy returns an int so something like this would be 
> >>> better:
> >>> --- a/drivers/gpu/drm/radeon/r600_blit.c
> >>> +++ b/drivers/gpu/drm/radeon/r600_blit.c
> >>> @@ -539,8 +539,10 @@ r600_prepare_blit_copy(struct drm_device *dev,
> >>> struct drm_file *file_priv)
> >>>  {
> >>>drm_radeon_private_t *dev_priv = dev->dev_private;
> >>>DRM_DEBUG("\n");
> >>> +   int ret = r600_nomm_get_vb(dev);
> >>>
> >>> -   r600_nomm_get_vb(dev);
> >>> +   if (ret)
> >>> +   return ret;
> >>>
> >>>dev_priv->blit_vb->file_priv = file_priv;
> >>>
> >>>
> >>> Alex
> >>>
> 
> dev_priv->blit_vb->file_priv = file_priv;
> 
>  --
>  1.7.1.1
> 
> >>>
> >>
> >> i haven't any preferneces, the only thing is - it would be logical
> >> to have every check in common style, so other cases
> >> (r600_blit_copy, r600_blit_swap) should be fixed, nop?
> >
> > Those are void functions so there's nothing to return.
> 
> i mean both of them call r600_nomm_get_vb and both of them
> check if (!dev_priv->blit_vb), not return  value.I mean would be
> logical to check it the same way everytime r600_nomm_get_vb
> gets called.

I'm going to go with Alex's patch, as none of the other callsites return
an error, and your patch doesn't return value from a function which has
a int return type, causing a warning.

Dave.





[Bug 28932] KWin crash (KDE 4.4.90) during call to r600 driver

2010-07-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28932

--- Comment #5 from Darin McBride  2010-07-21 10:18:47 
PDT ---
KDE devs recommended turning down my "Texture filter" from trilinear to
bilinear, and I've not got any crashes since.  Hopefully that helps narrow down
the problem?

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


[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

2010-07-21 Thread Dave Airlie
On Tue, 2010-07-20 at 16:34 -0700, Jesse Barnes wrote:
> On Wed, 21 Jul 2010 09:27:54 +1000
> Dave Airlie  wrote:
> 
> > On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > > On Wed, 21 Jul 2010 08:54:30 +1000
> > > Dave Airlie  wrote:
> > > 
> > > > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > > > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > > > > provide their own EDID fetch routine.  Export the bit banging DDC over
> > > > > i2c version of the EDID fetching routine and make the drivers use it.
> > > > > This sets the stage for GMBUS support in the Intel driver.
> > > > > 
> > > > 
> > > > I think this needs some rework.
> > > > 
> > > > You might want to checkout what the radeon driver does for hw i2c
> > > > engine. You should set up your own i2c hw handlers and use those instead
> > > > of bypassing the i2c stack. GMBUS is just another i2c hw block.
> > > 
> > > I'll check it out, but I don't see what using the i2c stack buys us
> > > here except for obfuscation...
> > > 
> > 
> > You'll want to use GMBUS for SDVO at some point in the future, or
> > something else, or you'll want to expose it to userspace for DDC/CI
> > users. Lots of reasons, its not obfuscation at all, what you are doing
> > is dodgy shortcuts.
> 
> Using it for SDVO and other things means some other changes to the
> GMBUS code unfortunately.  Still not seeing how using i2c makes
> userspace exposure or SDVO usage easier, but I don't care, I'll switch
> it around to use i2c core code.
> 

You can expose /dev/i2c devices properly to userspace, you can't do that
with the code you proposed.

Dave.




[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

2010-07-21 Thread Dave Airlie
On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> On Wed, 21 Jul 2010 08:54:30 +1000
> Dave Airlie  wrote:
> 
> > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > > provide their own EDID fetch routine.  Export the bit banging DDC over
> > > i2c version of the EDID fetching routine and make the drivers use it.
> > > This sets the stage for GMBUS support in the Intel driver.
> > > 
> > 
> > I think this needs some rework.
> > 
> > You might want to checkout what the radeon driver does for hw i2c
> > engine. You should set up your own i2c hw handlers and use those instead
> > of bypassing the i2c stack. GMBUS is just another i2c hw block.
> 
> I'll check it out, but I don't see what using the i2c stack buys us
> here except for obfuscation...
> 

You'll want to use GMBUS for SDVO at some point in the future, or
something else, or you'll want to expose it to userspace for DDC/CI
users. Lots of reasons, its not obfuscation at all, what you are doing
is dodgy shortcuts.

Dave.




[PATCH 1/2] drm: allow drivers to provide their own EDID fetching routine

2010-07-21 Thread Dave Airlie
On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> Make drm_edid_read take a new argument, edid_read, to allow drivers to
> provide their own EDID fetch routine.  Export the bit banging DDC over
> i2c version of the EDID fetching routine and make the drivers use it.
> This sets the stage for GMBUS support in the Intel driver.
> 

I think this needs some rework.

You might want to checkout what the radeon driver does for hw i2c
engine. You should set up your own i2c hw handlers and use those instead
of bypassing the i2c stack. GMBUS is just another i2c hw block.

Dave.

> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/drm_edid.c  |   42 +++---
>  drivers/gpu/drm/i915/intel_drv.h|1 +
>  drivers/gpu/drm/i915/intel_hdmi.c   |2 +-
>  drivers/gpu/drm/i915/intel_modes.c  |3 +-
>  drivers/gpu/drm/i915/intel_sdvo.c   |9 --
>  drivers/gpu/drm/nouveau/nouveau_connector.c |8 -
>  drivers/gpu/drm/radeon/radeon_connectors.c  |5 ++-
>  drivers/gpu/drm/radeon/radeon_display.c |6 ++--
>  include/drm/drm_crtc.h  |5 ++-
>  include/drm/drm_edid.h  |3 ++
>  10 files changed, 47 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 83d8072..fb720e2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -214,10 +214,10 @@ EXPORT_SYMBOL(drm_edid_is_valid);
>   *
>   * Try to fetch EDID information by calling i2c driver function.
>   */
> -static int
> -drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
> -   int block, int len)
> +int
> +drm_ddc_i2c_edid_read(void *data, unsigned char *buf, int block, int len)
>  {
> + struct i2c_adapter *adapter = data;
>   unsigned char start = block * EDID_LENGTH;
>   struct i2c_msg msgs[] = {
>   {
> @@ -238,9 +238,13 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>  
>   return -1;
>  }
> +EXPORT_SYMBOL(drm_ddc_i2c_edid_read);
>  
>  static u8 *
> -drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
> +drm_do_get_edid(struct drm_connector *connector,
> + int (*edid_read)(void *data, unsigned char *buf, int block,
> +  int len),
> + void *data)
>  {
>   int i, j = 0;
>   u8 *block, *new;
> @@ -250,7 +254,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
> i2c_adapter *adapter)
>  
>   /* base block fetch */
>   for (i = 0; i < 4; i++) {
> - if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH))
> + if (edid_read(data, block, 0, EDID_LENGTH))
>   goto out;
>   if (drm_edid_block_valid(block))
>   break;
> @@ -269,8 +273,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
> i2c_adapter *adapter)
>  
>   for (j = 1; j <= block[0x7e]; j++) {
>   for (i = 0; i < 4; i++) {
> - if (drm_do_probe_ddc_edid(adapter, block, j,
> -   EDID_LENGTH))
> + if (edid_read(data, block, j, EDID_LENGTH))
>   goto out;
>   if (drm_edid_block_valid(block + j * EDID_LENGTH))
>   break;
> @@ -291,20 +294,6 @@ out:
>  }
>  
>  /**
> - * Probe DDC presence.
> - *
> - * \param adapter : i2c device adaptor
> - * \return 1 on success
> - */
> -static bool
> -drm_probe_ddc(struct i2c_adapter *adapter)
> -{
> - unsigned char out;
> -
> - return (drm_do_probe_ddc_edid(adapter, , 0, 1) == 0);
> -}
> -
> -/**
>   * drm_get_edid - get EDID data, if available
>   * @connector: connector we're probing
>   * @adapter: i2c adapter to use for DDC
> @@ -315,12 +304,17 @@ drm_probe_ddc(struct i2c_adapter *adapter)
>   * Return edid data or NULL if we couldn't find any.
>   */
>  struct edid *drm_get_edid(struct drm_connector *connector,
> -   struct i2c_adapter *adapter)
> +   int (*edid_read)(void *data, unsigned char *buf,
> +int block, int len),
> +   void *data)
>  {
>   struct edid *edid = NULL;
> + unsigned char out;
>  
> - if (drm_probe_ddc(adapter))
> - edid = (struct edid *)drm_do_get_edid(connector, adapter);
> + /* Check for presence first */
> + if (edid_read(data, , 0, 1) == 0)
> + edid = (struct edid *)drm_do_get_edid(connector, edid_read,
> +   data);
>  
>   connector->display_info.raw_edid = (char *)edid;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3fbedd8..75c7161 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> 

Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Dave Airlie
On Tue, 2010-07-20 at 23:37 +0200, Rafa? Mi?ecki wrote:
> OK, next question :/ How can I rebase local d-r-t onto Linus's tree?
> I've Linus's remote tree added and fetched but can not rebase against
> it.
> 
> # git rebase linus
> Current branch drm-radeon-testing is up to date.
> 
> # git rebase --onto linus drm-radeon-testing
> Current branch drm-radeon-testing is up to date.
> 

git rebase linus/master





[git pull] drm fixes

2010-07-21 Thread Dave Airlie

Hi Linus,

core: build fixes + a vgaarb header fix
radeon: IGP fixes to fix some issues since 2.6.34, a quirk + another fix 
for messy shared DDC lines
nouveau: two regression fixes
i915: I know you normally get these from Eric, but I wanted to get this 
upstream asap, as its a major stabilisation fix for 945GM systems, a large 
selection of 945GM machines have had stability problems and lockups over 
the past few years, I finally managed to get an enterprise reason to track 
it down and fix it. Keith's patch just adds docs for the necessary bits.

The following changes since commit 1c5474a65bf15a4cb162dfff86d6d0b5a08a740c:

  Linux 2.6.35-rc5 (2010-07-12 14:55:33 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (6):
  drm/radeon/kms: fix legacy tv-out pal mode
  drm/radeon/kms: fix possible mis-detection of sideport on rs690/rs740
  drm/radeon/kms: fix gtt MC base alignment on rs4xx/rs690/rs740 asics
  drm/radeon/kms: fix shared ddc harder
  drm/radeon/kms: add quirk for ASUS HD 3600 board
  drm/r600: fix possible NULL pointer derefernce

Ben Hutchings (1):
  drm/ttm: Fix build on architectures without AGP

Ben Skeggs (1):
  drm/nouveau: fix pcirom vbios shadow breakage from acpi rom patch

Dan Carpenter (2):
  fb: handle allocation failure in alloc_apertures()
  vmwgfx: return -EFAULT if copy_to_user fails

Dave Airlie (1):
  drm/i915: enable low power render writes on GEN3 hardware.

Doug Goldstein (1):
  include/linux/vgaarb.h: add missing part of include guard

Francisco Jerez (1):
  drm/nouveau: Fix crashes during fbcon init on single head cards.

Keith Packard (1):
  drm/i915: Define MI_ARB_STATE bits

Kulikov Vasiliy (1):
  drm: radeon: check kzalloc() result

 drivers/gpu/drm/i915/i915_gem.c|   10 
 drivers/gpu/drm/i915/i915_reg.h|   64 
 drivers/gpu/drm/nouveau/nouveau_bios.c |   33 --
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|3 +-
 drivers/gpu/drm/radeon/r100.c  |1 +
 drivers/gpu/drm/radeon/r300.c  |3 +
 drivers/gpu/drm/radeon/r520.c  |1 +
 drivers/gpu/drm/radeon/r600.c  |1 +
 drivers/gpu/drm/radeon/r600_blit.c |5 ++-
 drivers/gpu/drm/radeon/radeon.h|1 +
 drivers/gpu/drm/radeon/radeon_atombios.c   |   20 -
 drivers/gpu/drm/radeon/radeon_connectors.c |   23 --
 drivers/gpu/drm/radeon/radeon_device.c |8 ++--
 drivers/gpu/drm/radeon/radeon_legacy_tv.c  |4 +-
 drivers/gpu/drm/radeon/rs400.c |5 ++-
 drivers/gpu/drm/radeon/rs600.c |1 +
 drivers/gpu/drm/radeon/rs690.c |1 +
 drivers/gpu/drm/radeon/rv515.c |1 +
 drivers/gpu/drm/ttm/ttm_page_alloc.c   |2 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|1 +
 include/linux/fb.h |2 +
 include/linux/vgaarb.h |1 +
 22 files changed, 142 insertions(+), 49 deletions(-)


drivers/gpu/drm/radeon/r600_blit.c: fix possible NULL pointer derefernce

2010-07-21 Thread Alexander Y. Fomichev
On Wed, Jul 21, 2010 at 1:00 AM, Alex Deucher  wrote:
> On Tue, Jul 20, 2010 at 4:13 PM, Alexander Y. Fomichev
>  wrote:
>> On Tue, Jul 20, 2010 at 9:37 PM, Alex Deucher  
>> wrote:
>>> On Mon, Jul 19, 2010 at 5:42 PM, Alexander Y. Fomichev
>>>  wrote:
 This patch fix possible NULL pointer dereference when
 r600_prepare_blit_copy tries to fill dev_priv->blit_vb->file_priv
 without check of dev_priv->blit_vb. dev_priv->blit_vb should be
 filled by r600_nomm_get_vb but latest can fail with EAGAIN.
 Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16375

 ---
 ?drivers/gpu/drm/radeon/r600_blit.c | ? ?2 ++
 ?1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
 b/drivers/gpu/drm/radeon/r600_blit.c
 index f4fb88e..0df4a2b 100644
 --- a/drivers/gpu/drm/radeon/r600_blit.c
 +++ b/drivers/gpu/drm/radeon/r600_blit.c
 @@ -541,6 +541,8 @@ r600_prepare_blit_copy(struct drm_device *dev, struct 
 drm_file *file_priv)
 ? ? ? ?DRM_DEBUG("\n");

 ? ? ? ?r600_nomm_get_vb(dev);
 + ? ? ? if (!dev_priv->blit_vb)
 + ? ? ? ? ? ? ? return;
>>>
>>> r600_prepare_blit_copy returns an int so something like this would be 
>>> better:
>>> --- a/drivers/gpu/drm/radeon/r600_blit.c
>>> +++ b/drivers/gpu/drm/radeon/r600_blit.c
>>> @@ -539,8 +539,10 @@ r600_prepare_blit_copy(struct drm_device *dev,
>>> struct drm_file *file_priv)
>>> ?{
>>> ? ? ? ?drm_radeon_private_t *dev_priv = dev->dev_private;
>>> ? ? ? ?DRM_DEBUG("\n");
>>> + ? ? ? int ret = r600_nomm_get_vb(dev);
>>>
>>> - ? ? ? r600_nomm_get_vb(dev);
>>> + ? ? ? if (ret)
>>> + ? ? ? ? ? ? ? return ret;
>>>
>>> ? ? ? ?dev_priv->blit_vb->file_priv = file_priv;
>>>
>>>
>>> Alex
>>>

 ? ? ? ?dev_priv->blit_vb->file_priv = file_priv;

 --
 1.7.1.1

>>>
>>
>> i haven't any preferneces, the only thing is - it would be logical
>> to have every check in common style, so other cases
>> (r600_blit_copy, r600_blit_swap) should be fixed, nop?
>
> Those are void functions so there's nothing to return.

i mean both of them call r600_nomm_get_vb and both of them
check if (!dev_priv->blit_vb), not return  value.I mean would be
logical to check it the same way everytime r600_nomm_get_vb
gets called.

> Alex
>
>>
>> --
>> Best regards.
>> ? ? ?? Alexander Y. Fomichev 
>>
>



-- 
Best regards.
? ? ?? Alexander Y. Fomichev 


drivers/gpu/drm/radeon/r600_blit.c: fix possible NULL pointer derefernce

2010-07-21 Thread Alexander Y. Fomichev
On Tue, Jul 20, 2010 at 9:37 PM, Alex Deucher  wrote:
> On Mon, Jul 19, 2010 at 5:42 PM, Alexander Y. Fomichev
>  wrote:
>> This patch fix possible NULL pointer dereference when
>> r600_prepare_blit_copy tries to fill dev_priv->blit_vb->file_priv
>> without check of dev_priv->blit_vb. dev_priv->blit_vb should be
>> filled by r600_nomm_get_vb but latest can fail with EAGAIN.
>> Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16375
>>
>> ---
>> ?drivers/gpu/drm/radeon/r600_blit.c | ? ?2 ++
>> ?1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
>> b/drivers/gpu/drm/radeon/r600_blit.c
>> index f4fb88e..0df4a2b 100644
>> --- a/drivers/gpu/drm/radeon/r600_blit.c
>> +++ b/drivers/gpu/drm/radeon/r600_blit.c
>> @@ -541,6 +541,8 @@ r600_prepare_blit_copy(struct drm_device *dev, struct 
>> drm_file *file_priv)
>> ? ? ? ?DRM_DEBUG("\n");
>>
>> ? ? ? ?r600_nomm_get_vb(dev);
>> + ? ? ? if (!dev_priv->blit_vb)
>> + ? ? ? ? ? ? ? return;
>
> r600_prepare_blit_copy returns an int so something like this would be better:
> --- a/drivers/gpu/drm/radeon/r600_blit.c
> +++ b/drivers/gpu/drm/radeon/r600_blit.c
> @@ -539,8 +539,10 @@ r600_prepare_blit_copy(struct drm_device *dev,
> struct drm_file *file_priv)
> ?{
> ? ? ? ?drm_radeon_private_t *dev_priv = dev->dev_private;
> ? ? ? ?DRM_DEBUG("\n");
> + ? ? ? int ret = r600_nomm_get_vb(dev);
>
> - ? ? ? r600_nomm_get_vb(dev);
> + ? ? ? if (ret)
> + ? ? ? ? ? ? ? return ret;
>
> ? ? ? ?dev_priv->blit_vb->file_priv = file_priv;
>
>
> Alex
>
>>
>> ? ? ? ?dev_priv->blit_vb->file_priv = file_priv;
>>
>> --
>> 1.7.1.1
>>
>

i haven't any preferneces, the only thing is - it would be logical
to have every check in common style, so other cases
(r600_blit_copy, r600_blit_swap) should be fixed, nop?

-- 
Best regards.
? ? ?? Alexander Y. Fomichev 


Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Rafał Miłecki
OK, next question :/ How can I rebase local d-r-t onto Linus's tree?
I've Linus's remote tree added and fetched but can not rebase against
it.

# git rebase linus
Current branch drm-radeon-testing is up to date.

# git rebase --onto linus drm-radeon-testing
Current branch drm-radeon-testing is up to date.

-- 
Rafa?


Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Rafał Miłecki
W dniu 20 lipca 2010 13:15 u?ytkownik Marius Gr?ger
 napisa?:
> Am 20.07.2010 12:14, schrieb Rafa? Mi?ecki:
>>
>> I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added
>> 2.6.35-rc5 from package. In both cases suspending and resuming works
>> fine.
>>
>> Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and
>> resuming works fine.
>>
>> When trying d-r-t with the same config my machine locks up on
>> suspending, just before machine is expected to turn off.
>>
>> How can I use "git bisect" command to bisect d-r-t specific commits?
>
> Fwiw, for me (HD3200, RS780) current d-r-t resume from suspend to ram does
> not work. Last thing it shows is the text console with some random colored
> pixels, but not the X display where it was suspended from. It appeared liked
> the kernel was still running, but X was completely crashed and stuck. I
> haven't had the time yet to further debug this.

Now when I managed to merge Linus's tree into d-r-t suspend works fine
for me, but I get lock up after resuming. It's quite funny effect,
PANEL slowly blinks for 3 times and then it freezes.

I guess I'll have to learn rebasing instead of merging, so I'll have
all d-r-t specific patches on top or rc5, which will let me bisect.

-- 
Rafa?


No subject

2010-07-21 Thread
crappy monitors are still crappy.  The hw i2c engines are mostly there
to reduce CPU usage and allow i2c transactions to be interrupt driven.

Alex


Re: drivers/gpu/drm/radeon/r600_blit.c: fix possible NULL pointer derefernce

2010-07-21 Thread Alexander Y. Fomichev
On Wed, Jul 21, 2010 at 1:29 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Tue, Jul 20, 2010 at 5:07 PM, Alexander Y. Fomichev
 git.u...@gmail.com wrote:
 On Wed, Jul 21, 2010 at 1:00 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Tue, Jul 20, 2010 at 4:13 PM, Alexander Y. Fomichev
 git.u...@gmail.com wrote:
 On Tue, Jul 20, 2010 at 9:37 PM, Alex Deucher alexdeuc...@gmail.com 
 wrote:
 On Mon, Jul 19, 2010 at 5:42 PM, Alexander Y. Fomichev
 git.u...@gmail.com wrote:
 This patch fix possible NULL pointer dereference when
 r600_prepare_blit_copy tries to fill dev_priv-blit_vb-file_priv
 without check of dev_priv-blit_vb. dev_priv-blit_vb should be
 filled by r600_nomm_get_vb but latest can fail with EAGAIN.
 Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16375

 ---
  drivers/gpu/drm/radeon/r600_blit.c |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600_blit.c 
 b/drivers/gpu/drm/radeon/r600_blit.c
 index f4fb88e..0df4a2b 100644
 --- a/drivers/gpu/drm/radeon/r600_blit.c
 +++ b/drivers/gpu/drm/radeon/r600_blit.c
 @@ -541,6 +541,8 @@ r600_prepare_blit_copy(struct drm_device *dev, 
 struct drm_file *file_priv)
        DRM_DEBUG(\n);

        r600_nomm_get_vb(dev);
 +       if (!dev_priv-blit_vb)
 +               return;

 r600_prepare_blit_copy returns an int so something like this would be 
 better:
 --- a/drivers/gpu/drm/radeon/r600_blit.c
 +++ b/drivers/gpu/drm/radeon/r600_blit.c
 @@ -539,8 +539,10 @@ r600_prepare_blit_copy(struct drm_device *dev,
 struct drm_file *file_priv)
  {
        drm_radeon_private_t *dev_priv = dev-dev_private;
        DRM_DEBUG(\n);
 +       int ret = r600_nomm_get_vb(dev);

 -       r600_nomm_get_vb(dev);
 +       if (ret)
 +               return ret;

        dev_priv-blit_vb-file_priv = file_priv;


 Alex


        dev_priv-blit_vb-file_priv = file_priv;

 --
 1.7.1.1



 i haven't any preferneces, the only thing is - it would be logical
 to have every check in common style, so other cases
 (r600_blit_copy, r600_blit_swap) should be fixed, nop?

 Those are void functions so there's nothing to return.

 i mean both of them call r600_nomm_get_vb and both of them
 check if (!dev_priv-blit_vb), not return  value.I mean would be
 logical to check it the same way everytime r600_nomm_get_vb
 gets called.

 yeah, either way.  You just need to return an error in r600_prepare_blit_copy.
uh-huh, i've missed

 Alex


 Alex


 --
 Best regards.
        Alexander Y. Fomichev git.u...@gmail.com





 --
 Best regards.
        Alexander Y. Fomichev git.u...@gmail.com




-- 
Best regards.
       Alexander Y. Fomichev git.u...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Rafał Miłecki
W dniu 21 lipca 2010 00:36 użytkownik Dave Airlie airl...@redhat.com napisał:
 On Tue, 2010-07-20 at 23:37 +0200, Rafał Miłecki wrote:
 OK, next question :/ How can I rebase local d-r-t onto Linus's tree?
 I've Linus's remote tree added and fetched but can not rebase against
 it.

 # git rebase linus
 Current branch drm-radeon-testing is up to date.

 # git rebase --onto linus drm-radeon-testing
 Current branch drm-radeon-testing is up to date.


 git rebase linus/master

Thanks a lot!

First bisect try gave me:
bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
drm/radeon: optimize default 3D state for r6xx/r7xx blits

I'm leaving today, not sure if I manage to confirm this before next week.

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


Re: Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Rafał Miłecki
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zaj...@gmail.com napisał:
 First bisect try gave me:
 bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
 drm/radeon: optimize default 3D state for r6xx/r7xx blits

 I'm leaving today, not sure if I manage to confirm this before next week.

I switched back to rebased drm-radeon-testing and confirmed lockup.
Then reverted that single patch and it helped. I'm quite sure it's the
bad one.

I use KDE4 with effects enabled, so 3D is enabled here.

Not time to dig into this problem deeper, leaving now.

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


Re: [PATCH 4/7] cifs: use workqueue instead of slow-work

2010-07-21 Thread Steve French
On Tue, Jul 20, 2010 at 3:34 PM, Tejun Heo t...@kernel.org wrote:
 Workqueue can now handle high concurrency.  Use system_nrt_wq
 instead of slow-work.

 * Updated is_valid_oplock_break() to not call cifs_oplock_break_put()
  as advised by Steve French.  It might cause deadlock.  Instead,
  reference is increased after queueing succeeded and
  cifs_oplock_break() briefly grabs GlobalSMBSeslock before putting
  the cfile to make sure it doesn't put before the matching get is
  finished.

 * Anton Blanchard reported that cifs conversion was using now gone
  system_single_wq.  Use system_nrt_wq which provides non-reentrance
  guarantee which is enough and much better.

 Signed-off-by: Tejun Heo t...@kernel.org
 Cc: Steve French sfre...@samba.org
 Cc: Anton Blanchard an...@samba.org
 ---
  fs/cifs/Kconfig    |    1 -
  fs/cifs/cifsfs.c   |    5 -
  fs/cifs/cifsglob.h |    8 +---
  fs/cifs/dir.c      |    2 +-
  fs/cifs/file.c     |   30 +-
  fs/cifs/misc.c     |   20 
  6 files changed, 31 insertions(+), 35 deletions(-)

Acked-by: Steve French sfre...@us.ibm.com



-- 
Thanks,

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


Re: Suspend lockup: How to bisect d-r-t specific commits?

2010-07-21 Thread Alex Deucher
2010/7/21 Rafał Miłecki zaj...@gmail.com:
 W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zaj...@gmail.com 
 napisał:
 First bisect try gave me:
 bad: [d8c253f30d0eb975e5c42c31587ef718517f5067]
 drm/radeon: optimize default 3D state for r6xx/r7xx blits

 I'm leaving today, not sure if I manage to confirm this before next week.

 I switched back to rebased drm-radeon-testing and confirmed lockup.
 Then reverted that single patch and it helped. I'm quite sure it's the
 bad one.

 I use KDE4 with effects enabled, so 3D is enabled here.

 Not time to dig into this problem deeper, leaving now.

When you get back can you revert the original and test version 2 of
that patch (attached).  It puts back the original state, but
reorganizes the emit order to reduce the number of dwords.

Alex
From 97b2c5f6475c6018638ed41b44b37b001dc4e682 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 21 Jul 2010 13:18:44 -0400
Subject: [PATCH] drm/radeon: optimize default 3D state for r6xx/r7xx blits (v2)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Re-organize emit order to reduce the number of dwords in the
default 3D state.  This change reduces the default state size
from 514 dwords to 340.

v2: add back more state, should fix resume failure
Reported-by: Rafał Miłecki zaj...@gmail.com

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/r600_blit_shaders.c |  568 ++--
 1 files changed, 122 insertions(+), 446 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c b/drivers/gpu/drm/radeon/r600_blit_shaders.c
index 0271b53..c7b1dae 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
@@ -45,9 +45,6 @@ const u32 r6xx_default_state[] =
 	0x8000,
 	0x8000,
 	0xc0016800,
-	0x0010,
-	0x8000,
-	0xc0016800,
 	0x0542,
 	0x0703,
 	0xc0016800,
@@ -62,11 +59,9 @@ const u32 r6xx_default_state[] =
 	0xc0016800,
 	0x060e,
 	0x01020204,
-	0xc0016f00,
+	0xc0026f00,
 	0x,
 	0x,
-	0xc0016f00,
-	0x0001,
 	0x,
 	0xc0096900,
 	0x022a,
@@ -82,31 +77,28 @@ const u32 r6xx_default_state[] =
 	0xc0016900,
 	0x0004,
 	0x,
-	0xc0016900,
+	0xc0026900,
 	0x000a,
 	0x,
-	0xc0016900,
-	0x000b,
 	0x,
-	0xc0016900,
+	0xc0026900,
 	0x010c,
 	0x,
-	0xc0016900,
-	0x010d,
 	0x,
 	0xc0016900,
 	0x0200,
 	0x,
-	0xc0016900,
+	0xc0026900,
 	0x0343,
 	0x0060,
-	0xc0016900,
-	0x0344,
 	0x0040,
 	0xc0016900,
 	0x0351,
 	0xaa00,
 	0xc0016900,
+	0x0203,
+	0x0210,
+	0xc0016900,
 	0x0104,
 	0x,
 	0xc0016900,
@@ -124,237 +116,178 @@ const u32 r6xx_default_state[] =
 	0x,
 	0x,
 	0xc0046900,
-	0x030c,
-	0x0100,
-	0x,
-	0x,
-	0x,
-	0xc0046900,
 	0x0048,
 	0x3f80,
 	0x,
 	0x3f80,
 	0x3f80,
-	0xc0016900,
-	0x008e,
-	0x000f,
-	0xc0016900,
-	0x0080,
+	0xc0046900,
+	0x030c,
+	0x0100,
 	0x,
-	0xc0016900,
-	0x0083,
-	0x,
-	0xc0016900,
-	0x0084,
 	0x,
-	0xc0016900,
-	0x0085,
-	0x20002000,
-	0xc0016900,
-	0x0086,
 	0x,
 	0xc0016900,
-	0x0087,
-	0x20002000,
-	0xc0016900,
-	0x0088,
-	0x,
+	0x008f,
+	0x000f,
 	0xc0016900,
-	0x0089,
-	0x20002000,
+	0x01e8,
+	0x0001,
 	0xc0016900,
-	0x008a,
+	0x0080,
 	0x,
 	0xc0016900,
-	0x008b,
-	0x20002000,
+	0x0083,
+	0x,
 	0xc0016900,
 	0x008c,
 	0x,
-	0xc0016900,
+	0xc0026900,
 	0x0094,
 	0x8000,
-	0xc0016900,
-	0x0095,
 	0x20002000,
 	0xc0026900,
 	0x00b4,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x0096,
 	0x8000,
-	0xc0016900,
-	0x0097,
 	0x20002000,
 	0xc0026900,
 	0x00b6,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x0098,
 	0x8000,
-	0xc0016900,
-	0x0099,
 	0x20002000,
 	0xc0026900,
 	0x00b8,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x009a,
 	0x8000,
-	0xc0016900,
-	0x009b,
 	0x20002000,
 	0xc0026900,
 	0x00ba,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x009c,
 	0x8000,
-	0xc0016900,
-	0x009d,
 	0x20002000,
 	0xc0026900,
 	0x00bc,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x009e,
 	0x8000,
-	0xc0016900,
-	0x009f,
 	0x20002000,
 	0xc0026900,
 	0x00be,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x00a0,
 	0x8000,
-	0xc0016900,
-	0x00a1,
 	0x20002000,
 	0xc0026900,
 	0x00c0,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x00a2,
 	0x8000,
-	0xc0016900,
-	0x00a3,
 	0x20002000,
 	0xc0026900,
 	0x00c2,
 	0x,
 	0x3f80,
-	0xc0016900,
+	0xc0026900,
 	0x00a4,
 	0x8000,
-	0xc0016900,
-	0x00a5,
 	0x20002000,
 	0xc0026900,
 	

[Bug 29200] New: [wine] Warcraft 3 crashes after trying to launch again

2010-07-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29200

   Summary: [wine] Warcraft 3 crashes after trying to launch again
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mag...@jensenligan.se


Hi, i'm trying to play Warcraft III and i can get it to launch sometimes but if
i exit after a succesful launch it will not launch again and i have to reboot.

i Get error message in dmesg about rejected command stream, please tell me
about how to debug this error further if that will help the driver.

radeon :01:00.0: r600_cs_track_check:286 mask 0x000F | 0x000F no cb
for 0
radeon :01:00.0: r600_packet3_check:1247 invalid cmd stream 470
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream

-- 
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: fix legacy LVDS dpms sequence

2010-07-21 Thread Alex Deucher
Add delay after turning off the LVDS encoder.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16389

Tested-by: Jan Kreuzer kontrolla...@gmx.de
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index bad77f4..5688a0c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -108,6 +108,7 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)
udelay(panel_pwr_delay * 1000);
WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
WREG32_PLL(RADEON_PIXCLKS_CNTL, pixclks_cntl);
+   udelay(panel_pwr_delay * 1000);
break;
}
 
-- 
1.7.1.1

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


[Bug 28671] Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.

2010-07-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28671

--- Comment #28 from Alex Deucher ag...@yahoo.com 2010-07-21 17:05:02 PDT ---
(In reply to comment #27)
 I tested analog and dmcp works fine. However DVI has no output on monitor with
 either connector.

What's dmcp?  With the analog monitor is the driver able to get an edid from
the monitor on both ports?  check 'xrandr --verbose' to see if there is an
edid.  If so, then we've gotten the ddc lines correct and the digital encoder
are probably reversed.

-- 
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 quirk to make HP DV5000 laptop resume

2010-07-21 Thread Alex Deucher
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=29062

Reported-by:  Andres Cimmarusti acimmaru...@gmail.com
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_combios.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 3426dd2..5e45cb2 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -3047,6 +3047,14 @@ void radeon_combios_asic_init(struct drm_device *dev)
rdev-pdev-subsystem_device == 0x308b)
return;
 
+   /* quirk for rs4xx HP dv5000 laptop to make it resume
+* - it hangs on resume inside the dynclk 1 table.
+*/
+   if (rdev-family == CHIP_RS480 
+   rdev-pdev-subsystem_vendor == 0x103c 
+   rdev-pdev-subsystem_device == 0x30a4)
+   return;
+
/* DYN CLK 1 */
table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE);
if (table)
-- 
1.7.1.1

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


[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend

2010-07-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=29062

--- Comment #5 from Alex Deucher ag...@yahoo.com 2010-07-21 20:55:44 PDT ---
Created an attachment (id=37291)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37291
 Review: https://bugs.freedesktop.org/review?bug=29062attachment=37291

fix resume

I've sent the attached patch to Dave to be included upstream.

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