regression: 2.6.35-rc1 hangs on i865G with KMS

2010-06-04 Thread Ondrej Zary 
Hello,
I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After loading 
i915 module, the screen goes blank and the kernel hangs completely (same with 
2.6.35-rc1-git2). This does not happen with "i915.modeset=0" parameter.

This problem does not appear with 2.6.34. Is this a known regression?

-- 
Ondrej Zary

[PATCH] drm/radeon/kms: r600 dump last 64 dwords of ring.

2010-06-04 Thread Jerome Glisse 
On Fri, Jun 04, 2010 at 02:54:42PM +0200, Rafa? Mi?ecki wrote:
> 2010/6/4 Jerome Glisse :
> > Instead of dumping unprocessed dwords, dump the last 64
> > dwords of the ring. This make debugging of some case easier.
> >
> > Signed-off-by: Jerome Glisse 
> > ---
> > ?drivers/gpu/drm/radeon/r600.c | ? ?6 +++---
> > ?1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> > index f68cc92..1537079 100644
> > --- a/drivers/gpu/drm/radeon/r600.c
> > +++ b/drivers/gpu/drm/radeon/r600.c
> > @@ -3371,9 +3371,9 @@ static int r600_debugfs_cp_ring_info(struct seq_file 
> > *m, void *data)
> > ? ? ? ?seq_printf(m, "driver's copy of the CP_RB_RPTR 0x%08x\n", 
> > rdev->cp.rptr);
> > ? ? ? ?seq_printf(m, "%u free dwords in ring\n", rdev->cp.ring_free_dw);
> > ? ? ? ?seq_printf(m, "%u dwords in ring\n", count);
> > - ? ? ? i = rdev->cp.rptr;
> > - ? ? ? for (j = 0; j <= count; j++) {
> > - ? ? ? ? ? ? ? seq_printf(m, "r[%04d]=0x%08x\n", i, rdev->cp.ring[i]);
> > + ? ? ? i = (rdev->cp.wptr + (rdev->cp.ring_size / 4) - 64) & 
> > rdev->cp.ptr_mask;
> > + ? ? ? for (j = 0; j <= 64; j++) {
> > + ? ? ? ? ? ? ? seq_printf(m, "r[%04d]=0x%08X\n", i, rdev->cp.ring[i]);
> > ? ? ? ? ? ? ? ?i = (i + 1) & rdev->cp.ptr_mask;
> > ? ? ? ?}
> > ? ? ? ?return 0;
> > --
> > 1.7.0.1
> 
> What about same for r1xx-r5xx? Could you care?
> 
> -- 
> Rafa?

Yes will do the patch, sorry i was working on r6xx bug at the time i did
this patch.

Cheers,
Jerome

Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Marius Gröger 
Am Fri, 4 Jun 2010 11:17:12 -0400
schrieb Alex Deucher :

> 2010/6/4 Marius Gr?ger :
> > Alex Deucher schrieb:
> >> 2010/6/4 Marius Gr?ger :
> >>> Hi All,
> >>>
> >>> Michel D?nzer schrieb:
>  On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote:
> > Hello All,
> >
> > I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
> > drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The
> > primary application is mythtv which uses DRM syncing for the
> > frame syncronisation. Now, with the exact same userland
> > software I noticed the introduction of sync gliches in the
> > May-timeframe. The drm-radeon-testing on May 9 was still ok,
> > but both drm-next and drm-radeon-testing at the end of May
> > showed that glitch: every couple of seconds there's a very
> > visual hickup, especially in scroll texts.
> >
> > Apologies for such an unspecific description, and for what
> > almost seems like a support request for MythTV. I wouldn't post
> > here if I were not 100% sure it must be related with the recent
> > drm changes.
>  Note that the DRM APIs are intended for use by userspace
>  components of graphics drivers / API libraries, not applications
>  directly. MythTV shouldn't use the DRM directly for
>  synchronization but rather use GLX synchronization APIs.
> >>> What about that new dri2 vsync stuff which was mentioned related
> >>> to [Bug 28383]? Could the changes done for that in any way alter
> >>> the timing? BTW I measured the glitches I'm experiencing and the
> >>> appear to be to happen in intervals of 10 seconds. Again, all I'm
> >>> changing is the kernel, and even the kernel config is the same.
> >>> I'd be most grateful for any clues/hints/tips I could follow to
> >>> resolve this regression.
> >>>
>  If you have dynamic PM enabled, does disabling that help?
> >>> I checked again and there's method=profile and profile=default.
> >>> Afaict this is not using dynpm, right?
> >>>
> >>
> >> Correct.
> >
> > Ok so with dynpm more or less ruled out, what could have such a
> > visible impact on the latencies? For instance, are we now more
> > dependent (or less) on some kind of interrupt or deferred
> > processing than 6 weeks ago?
> >
> > Btw, I have HDMI audio pretty much ruled out as well.
> 
> Any chance you can bisect the problematic commit?

As I said, I already tried bisecting but failed. Perhaps I can try
again and replay at least part of the log... But since we're talking
about more than 120 commits I kinda was hoping to get some clues here
first. Even with a tailored .config building/rebooting/testing takes
ages. Well I suppose I needn't tell *you* guys... ;-)

Thanks
Marius

Flickering screen in Neverball on drm-radeon-testing

2010-06-04 Thread Michel Dänzer 
On Mit, 2010-06-02 at 16:38 +0200, Mario Kleiner wrote: 
> > --
> >
> > Message: 1
> > Date: Tue,  1 Jun 2010 12:25:42 -0700 (PDT)
> > From: bugzilla-daemon at freedesktop.org
> > Subject: [Bug 28341] Flickering screen in Neverball on
> > drm-radeon-testing
> > To: dri-devel at lists.freedesktop.org
> > Message-ID: <20100601192542.ACE5B1300E8 at annarchy.freedesktop.org>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=28341
> >
> > --- Comment #3 from Magnus Jensen   
> > 2010-06-01 12:25:42 PDT ---
> > Sorry. ignore my last attachment. These  errors continue to spawn  
> > and i don't
> > think they are related to neverball. i'm going to recompile mesa  
> > and ddx, and
> > post another dmesg soon.
> > Just waiting for a kernel compile to finish.
> >
> 
> I saw a similar flickering with latest Xorg stack (mesa master,  
> xserver, ddx etc. master) and the 2.6.34 tree from radeon testing  
> with my own toolkit on a R600 gpu. This setup uses the new dri sync &  
> swap bits and changes how glXSwapbuffers works.
> 
> My best hunch would be that submission of new rendering commands by  
> the direct rendering client to the gpu doesn't block after a  
> glXSwapbuffers() call until the bufferswap completed, i.e., some  
> synchronization is missing there.
> 
> This shows flickering, but load and timing dependent...
> 
>  glXXX rendering commands to draw image.
> glXSwapBuffers();
> glBegin(GL_POINTS);
> glVertex2i(10,10);
> glEnd();
> glFinish();
> Take a  swap completion timestamp here.
> glClear();
> ...more rendering commands
> 
> -> I use this glVertex2i,  glFinish() sequence to wait for swap  
> completion and get a timestamp. This works on any os/gpu combo ever  
> tested, but doesn't seem to work reliably anymore with the new radeon  
> sync & swap bits in place. Display flickers, presumably because the  
> glClear() executes almost immediately after the glXSwapBuffers is  
> scheduled, and before the bufferswap has actually taken place ->  
> Clear the backbuffer before swapping.
> 
> This however:
> 
>  glXXX rendering commands to draw image.
> glXSwapBuffers();
> glXWaitForSbcOML(...);
> glClear();
> ...
> 
> does work, because the new glXWaitForSbcOML() blocks the client until  
> swap completion, so glClear() can only get submitted to the gpu after  
> the swap completed.
> 
> [Except that glXWaitForSbcOML itself currently has a bug, for which  
> i'll send a patch for xorg master/1.8.1 soon].
> 
> Didn't do detailed testing, but maybe this points into the right  
> direction?

I think your analysis is spot on.

The ideal solution would probably be to make the kernel block in the
command stream (CS) submission ioctl if the CS renders to (and from?) a
buffer object (BO) which is involved in a pending swap.

Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help
here, YMMV.


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
-- next part --
A non-text attachment was scrubbed...
Name: dri2-flicker-mesa.diff
Type: text/x-patch
Size: 576 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100604/fdfc48ce/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: dri2-flicker-xf86-video-ati.diff
Type: text/x-patch
Size: 391 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100604/fdfc48ce/attachment-0001.bin>

[Bug 28341] Flickering screen in Neverball on drm-radeon-testing

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28341

--- Comment #5 from Andrew Randrianasulu  2010-06-04 
17:25:44 PDT ---
I was under impression  i hit same bug here on rv280 + wine + DeusEx, but after
manually applying patches from
http://article.gmane.org/gmane.comp.video.dri.devel/46630 i still have
flickering intro. This is with git xserver ...  should i wait for kernel-based
solution for testing my case or open different bug?

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

regression: 2.6.35-rc1 hangs on i865G with KMS

2010-06-04 Thread Eric Anholt 
On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary  
wrote:
> Hello,
> I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After 
> loading 
> i915 module, the screen goes blank and the kernel hangs completely (same with 
> 2.6.35-rc1-git2). This does not happen with "i915.modeset=0" parameter.
> 
> This problem does not appear with 2.6.34. Is this a known regression?

Not known as far as I know -- we'd enjoy a bisect with a bug report on
bugs.freedesktop.org.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100604/12743f1d/attachment.pgp>

Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Marius Gröger 
Alex Deucher schrieb:
> 2010/6/4 Marius Gr?ger :
>> Hi All,
>>
>> Michel D?nzer schrieb:
>>> On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote:
 Hello All,

 I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
 drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
 application is mythtv which uses DRM syncing for the frame
 syncronisation. Now, with the exact same userland software I noticed the
 introduction of sync gliches in the May-timeframe. The
 drm-radeon-testing on May 9 was still ok, but both drm-next and
 drm-radeon-testing at the end of May showed that glitch: every couple of
 seconds there's a very visual hickup, especially in scroll texts.

 Apologies for such an unspecific description, and for what almost seems
 like a support request for MythTV. I wouldn't post here if I were not
 100% sure it must be related with the recent drm changes.
>>> Note that the DRM APIs are intended for use by userspace components of
>>> graphics drivers / API libraries, not applications directly. MythTV
>>> shouldn't use the DRM directly for synchronization but rather use GLX
>>> synchronization APIs.
>> What about that new dri2 vsync stuff which was mentioned related to [Bug
>> 28383]? Could the changes done for that in any way alter the timing? BTW
>> I measured the glitches I'm experiencing and the appear to be to happen
>> in intervals of 10 seconds. Again, all I'm changing is the kernel, and
>> even the kernel config is the same. I'd be most grateful for any
>> clues/hints/tips I could follow to resolve this regression.
>>
>>> If you have dynamic PM enabled, does disabling that help?
>> I checked again and there's method=profile and profile=default. Afaict
>> this is not using dynpm, right?
>>
> 
> Correct.

Ok so with dynpm more or less ruled out, what could have such a visible
impact on the latencies? For instance, are we now more dependent (or
less) on some kind of interrupt or deferred processing than 6 weeks ago?

Btw, I have HDMI audio pretty much ruled out as well.

Thanks
Marius

Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Alex Deucher 
2010/6/4 Marius Gr?ger :
> Am Fri, 4 Jun 2010 11:17:12 -0400
> schrieb Alex Deucher :
>
>> 2010/6/4 Marius Gr?ger :
>> > Alex Deucher schrieb:
>> >> 2010/6/4 Marius Gr?ger :
>> >>> Hi All,
>> >>>
>> >>> Michel D?nzer schrieb:
>>  On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote:
>> > Hello All,
>> >
>> > I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
>> > drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The
>> > primary application is mythtv which uses DRM syncing for the
>> > frame syncronisation. Now, with the exact same userland
>> > software I noticed the introduction of sync gliches in the
>> > May-timeframe. The drm-radeon-testing on May 9 was still ok,
>> > but both drm-next and drm-radeon-testing at the end of May
>> > showed that glitch: every couple of seconds there's a very
>> > visual hickup, especially in scroll texts.
>> >
>> > Apologies for such an unspecific description, and for what
>> > almost seems like a support request for MythTV. I wouldn't post
>> > here if I were not 100% sure it must be related with the recent
>> > drm changes.
>>  Note that the DRM APIs are intended for use by userspace
>>  components of graphics drivers / API libraries, not applications
>>  directly. MythTV shouldn't use the DRM directly for
>>  synchronization but rather use GLX synchronization APIs.
>> >>> What about that new dri2 vsync stuff which was mentioned related
>> >>> to [Bug 28383]? Could the changes done for that in any way alter
>> >>> the timing? BTW I measured the glitches I'm experiencing and the
>> >>> appear to be to happen in intervals of 10 seconds. Again, all I'm
>> >>> changing is the kernel, and even the kernel config is the same.
>> >>> I'd be most grateful for any clues/hints/tips I could follow to
>> >>> resolve this regression.
>> >>>
>>  If you have dynamic PM enabled, does disabling that help?
>> >>> I checked again and there's method=profile and profile=default.
>> >>> Afaict this is not using dynpm, right?
>> >>>
>> >>
>> >> Correct.
>> >
>> > Ok so with dynpm more or less ruled out, what could have such a
>> > visible impact on the latencies? For instance, are we now more
>> > dependent (or less) on some kind of interrupt or deferred
>> > processing than 6 weeks ago?
>> >
>> > Btw, I have HDMI audio pretty much ruled out as well.
>>
>> Any chance you can bisect the problematic commit?
>
> As I said, I already tried bisecting but failed. Perhaps I can try
> again and replay at least part of the log... But since we're talking
> about more than 120 commits I kinda was hoping to get some clues here
> first. Even with a tailored .config building/rebooting/testing takes
> ages. Well I suppose I needn't tell *you* guys... ;-)
>

for vsync stuff, It's probably one of these:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=bc35afdb182d4c48c889fe27ba7a5d7ea0c8194d
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4fa07bf146aaee1e8409d35ab08624041c2e3867

Alex

> Thanks
> Marius
>

[Bug 28381] rv670 + tiling patches + tiling enabled = parse errors on some demos.

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28381

--- Comment #1 from Alex Deucher  2010-06-04 15:37:44 PDT 
---
Created an attachment (id=36064)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36064
 Review: https://bugs.freedesktop.org/review?bug=28381=36064

cs parser fix

This patch fixes it here.

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

Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Marius Gröger 
Hi All,

Michel D?nzer schrieb:
> On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote: 
>> Hello All,
>>
>> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
>> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
>> application is mythtv which uses DRM syncing for the frame
>> syncronisation. Now, with the exact same userland software I noticed the
>> introduction of sync gliches in the May-timeframe. The
>> drm-radeon-testing on May 9 was still ok, but both drm-next and
>> drm-radeon-testing at the end of May showed that glitch: every couple of
>> seconds there's a very visual hickup, especially in scroll texts.
>>
>> Apologies for such an unspecific description, and for what almost seems
>> like a support request for MythTV. I wouldn't post here if I were not
>> 100% sure it must be related with the recent drm changes.
> 
> Note that the DRM APIs are intended for use by userspace components of
> graphics drivers / API libraries, not applications directly. MythTV
> shouldn't use the DRM directly for synchronization but rather use GLX
> synchronization APIs.

What about that new dri2 vsync stuff which was mentioned related to [Bug
28383]? Could the changes done for that in any way alter the timing? BTW
I measured the glitches I'm experiencing and the appear to be to happen
in intervals of 10 seconds. Again, all I'm changing is the kernel, and
even the kernel config is the same. I'd be most grateful for any
clues/hints/tips I could follow to resolve this regression.

> If you have dynamic PM enabled, does disabling that help?

I checked again and there's method=profile and profile=default. Afaict
this is not using dynpm, right?

Marius

[PATCH] drm/radeon/kms: r600 dump last 64 dwords of ring.

2010-06-04 Thread Rafał Miłecki 
2010/6/4 Jerome Glisse :
> Instead of dumping unprocessed dwords, dump the last 64
> dwords of the ring. This make debugging of some case easier.
>
> Signed-off-by: Jerome Glisse 
> ---
> ?drivers/gpu/drm/radeon/r600.c | ? ?6 +++---
> ?1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index f68cc92..1537079 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3371,9 +3371,9 @@ static int r600_debugfs_cp_ring_info(struct seq_file 
> *m, void *data)
> ? ? ? ?seq_printf(m, "driver's copy of the CP_RB_RPTR 0x%08x\n", 
> rdev->cp.rptr);
> ? ? ? ?seq_printf(m, "%u free dwords in ring\n", rdev->cp.ring_free_dw);
> ? ? ? ?seq_printf(m, "%u dwords in ring\n", count);
> - ? ? ? i = rdev->cp.rptr;
> - ? ? ? for (j = 0; j <= count; j++) {
> - ? ? ? ? ? ? ? seq_printf(m, "r[%04d]=0x%08x\n", i, rdev->cp.ring[i]);
> + ? ? ? i = (rdev->cp.wptr + (rdev->cp.ring_size / 4) - 64) & 
> rdev->cp.ptr_mask;
> + ? ? ? for (j = 0; j <= 64; j++) {
> + ? ? ? ? ? ? ? seq_printf(m, "r[%04d]=0x%08X\n", i, rdev->cp.ring[i]);
> ? ? ? ? ? ? ? ?i = (i + 1) & rdev->cp.ptr_mask;
> ? ? ? ?}
> ? ? ? ?return 0;
> --
> 1.7.0.1

What about same for r1xx-r5xx? Could you care?

-- 
Rafa?

[Bug 28393] New: Radeon with two screens shows screwed up screen

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28393

   Summary: Radeon with two screens shows screwed up screen
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: nico-freedesktop.org at schottelius.org


Filled bug report at launchpad, adding this as a reference:

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/589850

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

[Bug 28375] [KMS][RV620] Lockup on PM reclock

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28375

--- Comment #15 from Rafa? Mi?ecki  2010-06-04 13:48:12 
PDT ---
I can confirm it's voltage setting that causes problem. Dropping it from
r600.c::r600_pm_misc makes d-r-t work again.

I didn't test your patch Alex, but it does not make much sense in my case.

1) Looking through all power modes I noticed only 2 different voltages: 950 and
1200.
2) Step is 250 anyway: 0018: USHORT usVoltageStep = 0x00fa (250)

-- 
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: r600 reset GPU at module load time v2

2010-06-04 Thread Jerome Glisse 
When loading/unloading several time the driver on r600 we
end up with the GPU in broken state and loading fail to
initialize acceleration. Reset the GPU at load time so
acceleration keep working over load/unload.

v2 Move status print after reset in asic_reset to avoid
cluttering log with this at module load time.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r600.c |   37 +++--
 1 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 1537079..b932f48 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1163,13 +1163,6 @@ int r600_gpu_soft_reset(struct radeon_device *rdev)
S_008014_CB2_BUSY(1) | S_008014_CB3_BUSY(1);
u32 tmp;

-   dev_info(rdev->dev, "GPU softreset \n");
-   dev_info(rdev->dev, "  R_008010_GRBM_STATUS=0x%08X\n",
-   RREG32(R_008010_GRBM_STATUS));
-   dev_info(rdev->dev, "  R_008014_GRBM_STATUS2=0x%08X\n",
-   RREG32(R_008014_GRBM_STATUS2));
-   dev_info(rdev->dev, "  R_000E50_SRBM_STATUS=0x%08X\n",
-   RREG32(R_000E50_SRBM_STATUS));
rv515_mc_stop(rdev, );
if (r600_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -1207,12 +1200,6 @@ int r600_gpu_soft_reset(struct radeon_device *rdev)
WREG32(R_008020_GRBM_SOFT_RESET, 0);
/* Wait a little for things to settle down */
mdelay(1);
-   dev_info(rdev->dev, "  R_008010_GRBM_STATUS=0x%08X\n",
-   RREG32(R_008010_GRBM_STATUS));
-   dev_info(rdev->dev, "  R_008014_GRBM_STATUS2=0x%08X\n",
-   RREG32(R_008014_GRBM_STATUS2));
-   dev_info(rdev->dev, "  R_000E50_SRBM_STATUS=0x%08X\n",
-   RREG32(R_000E50_SRBM_STATUS));
rv515_mc_resume(rdev, );
return 0;
 }
@@ -1245,7 +1232,23 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)

 int r600_asic_reset(struct radeon_device *rdev)
 {
-   return r600_gpu_soft_reset(rdev);
+   int r;
+
+   dev_info(rdev->dev, "GPU softreset \n");
+   dev_info(rdev->dev, "  R_008010_GRBM_STATUS=0x%08X\n",
+   RREG32(R_008010_GRBM_STATUS));
+   dev_info(rdev->dev, "  R_008014_GRBM_STATUS2=0x%08X\n",
+   RREG32(R_008014_GRBM_STATUS2));
+   dev_info(rdev->dev, "  R_000E50_SRBM_STATUS=0x%08X\n",
+   RREG32(R_000E50_SRBM_STATUS));
+   r = r600_gpu_soft_reset(rdev);
+   dev_info(rdev->dev, "  R_008010_GRBM_STATUS=0x%08X\n",
+   RREG32(R_008010_GRBM_STATUS));
+   dev_info(rdev->dev, "  R_008014_GRBM_STATUS2=0x%08X\n",
+   RREG32(R_008014_GRBM_STATUS2));
+   dev_info(rdev->dev, "  R_000E50_SRBM_STATUS=0x%08X\n",
+   RREG32(R_000E50_SRBM_STATUS));
+   return r;
 }

 static u32 r600_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
@@ -2460,6 +2463,12 @@ int r600_init(struct radeon_device *rdev)
DRM_INFO("GPU not posted. posting now...\n");
atom_asic_init(rdev->mode_info.atom_context);
}
+
+   /* GPU is sometimes in broken state (especialy after loading/unloading
+* the driver several time. Reset the GPU.
+*/
+   r600_gpu_soft_reset(rdev);
+
/* Initialize scratch registers */
r600_scratch_init(rdev);
/* Initialize surface registers */
-- 
1.7.0.1

[PATCH] drm/radeon/kms: r600 reset GPU at module load time

2010-06-04 Thread Jerome Glisse 
When loading/unloading several time the driver on r600 we
end up with the GPU in broken state and loading fail to
initialize acceleration. Reset the GPU at load time so
acceleration keep working over load/unload.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r600.c |   20 +---
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 1537079..5fc0525 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1163,13 +1163,6 @@ int r600_gpu_soft_reset(struct radeon_device *rdev)
S_008014_CB2_BUSY(1) | S_008014_CB3_BUSY(1);
u32 tmp;

-   dev_info(rdev->dev, "GPU softreset \n");
-   dev_info(rdev->dev, "  R_008010_GRBM_STATUS=0x%08X\n",
-   RREG32(R_008010_GRBM_STATUS));
-   dev_info(rdev->dev, "  R_008014_GRBM_STATUS2=0x%08X\n",
-   RREG32(R_008014_GRBM_STATUS2));
-   dev_info(rdev->dev, "  R_000E50_SRBM_STATUS=0x%08X\n",
-   RREG32(R_000E50_SRBM_STATUS));
rv515_mc_stop(rdev, );
if (r600_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -1245,6 +1238,13 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)

 int r600_asic_reset(struct radeon_device *rdev)
 {
+   dev_info(rdev->dev, "GPU softreset \n");
+   dev_info(rdev->dev, "  R_008010_GRBM_STATUS=0x%08X\n",
+   RREG32(R_008010_GRBM_STATUS));
+   dev_info(rdev->dev, "  R_008014_GRBM_STATUS2=0x%08X\n",
+   RREG32(R_008014_GRBM_STATUS2));
+   dev_info(rdev->dev, "  R_000E50_SRBM_STATUS=0x%08X\n",
+   RREG32(R_000E50_SRBM_STATUS));
return r600_gpu_soft_reset(rdev);
 }

@@ -2460,6 +2460,12 @@ int r600_init(struct radeon_device *rdev)
DRM_INFO("GPU not posted. posting now...\n");
atom_asic_init(rdev->mode_info.atom_context);
}
+
+   /* GPU is sometimes in broken state (especialy after loading/unloading
+* the driver several time. Reset the GPU.
+*/
+   r600_gpu_soft_reset(rdev);
+
/* Initialize scratch registers */
r600_scratch_init(rdev);
/* Initialize surface registers */
-- 
1.7.0.1

[PATCH] drm/radeon/kms: r600 dump last 64 dwords of ring.

2010-06-04 Thread Jerome Glisse 
Instead of dumping unprocessed dwords, dump the last 64
dwords of the ring. This make debugging of some case easier.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r600.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index f68cc92..1537079 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3371,9 +3371,9 @@ static int r600_debugfs_cp_ring_info(struct seq_file *m, 
void *data)
seq_printf(m, "driver's copy of the CP_RB_RPTR 0x%08x\n", 
rdev->cp.rptr);
seq_printf(m, "%u free dwords in ring\n", rdev->cp.ring_free_dw);
seq_printf(m, "%u dwords in ring\n", count);
-   i = rdev->cp.rptr;
-   for (j = 0; j <= count; j++) {
-   seq_printf(m, "r[%04d]=0x%08x\n", i, rdev->cp.ring[i]);
+   i = (rdev->cp.wptr + (rdev->cp.ring_size / 4) - 64) & rdev->cp.ptr_mask;
+   for (j = 0; j <= 64; j++) {
+   seq_printf(m, "r[%04d]=0x%08X\n", i, rdev->cp.ring[i]);
i = (i + 1) & rdev->cp.ptr_mask;
}
return 0;
-- 
1.7.0.1

[PATCH] drm/radeon/kms/evergreen: set accel_enabled

2010-06-04 Thread Jerome Glisse 
On Thu, Jun 03, 2010 at 07:07:09PM -0400, Alex Deucher wrote:
> This is needed to enable accel in the ddx.  However,
> due to a bug in older versions of the ddx, it relies
> on accel being disabled in order to load properly on
> evergreen chips.  To maintain compatility, we add a new
> get accel param and call that from the ddx.  The old one
> always returns false for evergreen cards.
> 
> Signed-off-by: Alex Deucher 

I am not sure i understand how it happened ? This really bad
that we have to add accel working2, this is ugly...

I am waiting for accel_working3

Cheers,
Jerome

> ---
>  drivers/gpu/drm/radeon/evergreen.c  |2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
>  drivers/gpu/drm/radeon/radeon_kms.c |9 -
>  include/drm/radeon_drm.h|1 +
>  4 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 0440c09..49c94ae 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2153,7 +2153,7 @@ int evergreen_init(struct radeon_device *rdev)
>   if (r)
>   return r;
>  
> - rdev->accel_working = false;
> + rdev->accel_working = true;
>   r = evergreen_startup(rdev);
>   if (r) {
>   dev_err(rdev->dev, "disabling GPU acceleration\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 902d173..e166fe4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -45,9 +45,10 @@
>   * - 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
> + * - 2.5.0 - add get accel 2 to work around ddx breakage for evergreen
>   */
>  #define KMS_DRIVER_MAJOR 2
> -#define KMS_DRIVER_MINOR 4
> +#define KMS_DRIVER_MINOR 5
>  #define KMS_DRIVER_PATCHLEVEL0
>  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 0406835..6a70c0d 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -118,7 +118,11 @@ int radeon_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file *filp)
>   value = rdev->num_z_pipes;
>   break;
>   case RADEON_INFO_ACCEL_WORKING:
> - value = rdev->accel_working;
> + /* xf86-video-ati 6.13.0 relies on this being false for 
> evergreen */
> + if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= 
> CHIP_HEMLOCK))
> + value = false;
> + else
> + value = rdev->accel_working;
>   break;
>   case RADEON_INFO_CRTC_FROM_ID:
>   for (i = 0, found = 0; i < rdev->num_crtc; i++) {
> @@ -134,6 +138,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
>   return -EINVAL;
>   }
>   break;
> + case RADEON_INFO_ACCEL_WORKING2:
> + value = rdev->accel_working;
> + 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 3ff9fc0..5347063 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -903,6 +903,7 @@ struct drm_radeon_cs {
>  #define RADEON_INFO_NUM_Z_PIPES  0x02
>  #define RADEON_INFO_ACCEL_WORKING0x03
>  #define RADEON_INFO_CRTC_FROM_ID 0x04
> +#define RADEON_INFO_ACCEL_WORKING2   0x05
>  
>  struct drm_radeon_info {
>   uint32_trequest;
> -- 
> 1.7.0.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/vmwgfx: return -EFAULT for copy_to_user errors

2010-06-04 Thread Dan Carpenter 
copy_to/from_user() returns the number of bytes remaining to be copied
but we want to return a negative error code here.  This gets returned to
userspace.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index f8fbbc6..8612378 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -597,8 +597,10 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,

ret = copy_from_user(srf->sizes, user_sizes,
 srf->num_sizes * sizeof(*srf->sizes));
-   if (unlikely(ret != 0))
+   if (unlikely(ret != 0)) {
+   ret = -EFAULT;
goto out_err1;
+   }

if (srf->scanout &&
srf->num_sizes == 1 &&
@@ -697,9 +699,11 @@ int vmw_surface_reference_ioctl(struct drm_device *dev, 
void *data,
if (user_sizes)
ret = copy_to_user(user_sizes, srf->sizes,
   srf->num_sizes * sizeof(*srf->sizes));
-   if (unlikely(ret != 0))
+   if (unlikely(ret != 0)) {
DRM_ERROR("copy_to_user failed %p %u\n",
  user_sizes, srf->num_sizes);
+   ret = -EFAULT;
+   }
 out_bad_resource:
 out_no_reference:
ttm_base_object_unref();
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index dbd36b8..ba15038 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -644,6 +644,7 @@ int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
ret = copy_from_user(cmd, user_cmd, arg->command_size);

if (unlikely(ret != 0)) {
+   ret = -EFAULT;
DRM_ERROR("Failed copying commands.\n");
goto out_commit;
}

[patch] drm/drm_crtc: return -EFAULT on copy_to_user errors

2010-06-04 Thread Dan Carpenter 
copy_from_user() returns the number of bytes left to be copied but we
want to return a negative error code here.  This is in the ioctl handler
so the error code get returned to userspace.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 994d23b..57cea01 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1840,8 +1840,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,

ret = copy_from_user(clips, clips_ptr,
 num_clips * sizeof(*clips));
-   if (ret)
+   if (ret) {
+   ret = -EFAULT;
goto out_err2;
+   }
}

if (fb->funcs->dirty) {

[Bug 28386] [KMS] echo standby > /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

--- Comment #3 from Andrew Randrianasulu  2010-06-04 
11:58:59 PDT ---
(In reply to comment #2)
> Is this a recent regression?  Has s/r worked previously for you with kms?

May be 0.5 year ago it was working, so not really recent. (I rarely use this
mode).

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

Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Alex Deucher 
2010/6/4 Marius Gr?ger :
> Alex Deucher schrieb:
>> 2010/6/4 Marius Gr?ger :
>>> Hi All,
>>>
>>> Michel D?nzer schrieb:
 On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote:
> Hello All,
>
> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
> application is mythtv which uses DRM syncing for the frame
> syncronisation. Now, with the exact same userland software I noticed the
> introduction of sync gliches in the May-timeframe. The
> drm-radeon-testing on May 9 was still ok, but both drm-next and
> drm-radeon-testing at the end of May showed that glitch: every couple of
> seconds there's a very visual hickup, especially in scroll texts.
>
> Apologies for such an unspecific description, and for what almost seems
> like a support request for MythTV. I wouldn't post here if I were not
> 100% sure it must be related with the recent drm changes.
 Note that the DRM APIs are intended for use by userspace components of
 graphics drivers / API libraries, not applications directly. MythTV
 shouldn't use the DRM directly for synchronization but rather use GLX
 synchronization APIs.
>>> What about that new dri2 vsync stuff which was mentioned related to [Bug
>>> 28383]? Could the changes done for that in any way alter the timing? BTW
>>> I measured the glitches I'm experiencing and the appear to be to happen
>>> in intervals of 10 seconds. Again, all I'm changing is the kernel, and
>>> even the kernel config is the same. I'd be most grateful for any
>>> clues/hints/tips I could follow to resolve this regression.
>>>
 If you have dynamic PM enabled, does disabling that help?
>>> I checked again and there's method=profile and profile=default. Afaict
>>> this is not using dynpm, right?
>>>
>>
>> Correct.
>
> Ok so with dynpm more or less ruled out, what could have such a visible
> impact on the latencies? For instance, are we now more dependent (or
> less) on some kind of interrupt or deferred processing than 6 weeks ago?
>
> Btw, I have HDMI audio pretty much ruled out as well.

Any chance you can bisect the problematic commit?

Alex

Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Alex Deucher 
2010/6/4 Marius Gr?ger :
> Hi All,
>
> Michel D?nzer schrieb:
>> On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote:
>>> Hello All,
>>>
>>> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
>>> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
>>> application is mythtv which uses DRM syncing for the frame
>>> syncronisation. Now, with the exact same userland software I noticed the
>>> introduction of sync gliches in the May-timeframe. The
>>> drm-radeon-testing on May 9 was still ok, but both drm-next and
>>> drm-radeon-testing at the end of May showed that glitch: every couple of
>>> seconds there's a very visual hickup, especially in scroll texts.
>>>
>>> Apologies for such an unspecific description, and for what almost seems
>>> like a support request for MythTV. I wouldn't post here if I were not
>>> 100% sure it must be related with the recent drm changes.
>>
>> Note that the DRM APIs are intended for use by userspace components of
>> graphics drivers / API libraries, not applications directly. MythTV
>> shouldn't use the DRM directly for synchronization but rather use GLX
>> synchronization APIs.
>
> What about that new dri2 vsync stuff which was mentioned related to [Bug
> 28383]? Could the changes done for that in any way alter the timing? BTW
> I measured the glitches I'm experiencing and the appear to be to happen
> in intervals of 10 seconds. Again, all I'm changing is the kernel, and
> even the kernel config is the same. I'd be most grateful for any
> clues/hints/tips I could follow to resolve this regression.
>
>> If you have dynamic PM enabled, does disabling that help?
>
> I checked again and there's method=profile and profile=default. Afaict
> this is not using dynpm, right?
>

Correct.

Alex

[PATCH] drm/radeon/kms/evergreen: set accel_enabled

2010-06-04 Thread Alex Deucher 
On Fri, Jun 4, 2010 at 6:37 AM, Jerome Glisse  wrote:
> On Thu, Jun 03, 2010 at 07:07:09PM -0400, Alex Deucher wrote:
>> This is needed to enable accel in the ddx. ?However,
>> due to a bug in older versions of the ddx, it relies
>> on accel being disabled in order to load properly on
>> evergreen chips. ?To maintain compatility, we add a new
>> get accel param and call that from the ddx. ?The old one
>> always returns false for evergreen cards.
>>
>> Signed-off-by: Alex Deucher 
>
> I am not sure i understand how it happened ? This really bad
> that we have to add accel working2, this is ugly...
>

Yeah it sucks.  Unfortunately I forgot to explicitly disable accel on
evergreen when we released 6.13.0 so it relies on accel working to
return false, otherwise it tries to init accel.

Alex

> I am waiting for accel_working3
>
> Cheers,
> Jerome
>
>> ---
>> ?drivers/gpu/drm/radeon/evergreen.c ?| ? ?2 +-
>> ?drivers/gpu/drm/radeon/radeon_drv.c | ? ?3 ++-
>> ?drivers/gpu/drm/radeon/radeon_kms.c | ? ?9 -
>> ?include/drm/radeon_drm.h ? ? ? ? ? ?| ? ?1 +
>> ?4 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index 0440c09..49c94ae 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -2153,7 +2153,7 @@ int evergreen_init(struct radeon_device *rdev)
>> ? ? ? if (r)
>> ? ? ? ? ? ? ? return r;
>>
>> - ? ? rdev->accel_working = false;
>> + ? ? rdev->accel_working = true;
>> ? ? ? r = evergreen_startup(rdev);
>> ? ? ? if (r) {
>> ? ? ? ? ? ? ? dev_err(rdev->dev, "disabling GPU acceleration\n");
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 902d173..e166fe4 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -45,9 +45,10 @@
>> ? * - 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
>> + * - 2.5.0 - add get accel 2 to work around ddx breakage for evergreen
>> ? */
>> ?#define KMS_DRIVER_MAJOR ? ? 2
>> -#define KMS_DRIVER_MINOR ? ? 4
>> +#define KMS_DRIVER_MINOR ? ? 5
>> ?#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 0406835..6a70c0d 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -118,7 +118,11 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>> ? ? ? ? ? ? ? value = rdev->num_z_pipes;
>> ? ? ? ? ? ? ? break;
>> ? ? ? case RADEON_INFO_ACCEL_WORKING:
>> - ? ? ? ? ? ? value = rdev->accel_working;
>> + ? ? ? ? ? ? /* xf86-video-ati 6.13.0 relies on this being false for 
>> evergreen */
>> + ? ? ? ? ? ? if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= 
>> CHIP_HEMLOCK))
>> + ? ? ? ? ? ? ? ? ? ? value = false;
>> + ? ? ? ? ? ? else
>> + ? ? ? ? ? ? ? ? ? ? value = rdev->accel_working;
>> ? ? ? ? ? ? ? break;
>> ? ? ? case RADEON_INFO_CRTC_FROM_ID:
>> ? ? ? ? ? ? ? for (i = 0, found = 0; i < rdev->num_crtc; i++) {
>> @@ -134,6 +138,9 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>> ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
>> ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? ? break;
>> + ? ? case RADEON_INFO_ACCEL_WORKING2:
>> + ? ? ? ? ? ? value = rdev->accel_working;
>> + ? ? ? ? ? ? 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 3ff9fc0..5347063 100644
>> --- a/include/drm/radeon_drm.h
>> +++ b/include/drm/radeon_drm.h
>> @@ -903,6 +903,7 @@ struct drm_radeon_cs {
>> ?#define RADEON_INFO_NUM_Z_PIPES ? ? ?0x02
>> ?#define RADEON_INFO_ACCEL_WORKING ? ?0x03
>> ?#define RADEON_INFO_CRTC_FROM_ID ? ? 0x04
>> +#define RADEON_INFO_ACCEL_WORKING2 ? 0x05
>>
>> ?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 28383] Cloned screens with different res/refresh cause problems with mesa demos since new dri2 vsync.

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28383

Michel D?nzer  changed:

   What|Removed |Added

Product|Mesa|xorg
  Component|Drivers/DRI/R600|Driver/Radeon
 AssignedTo|dri-devel at lists.freedesktop |xorg-driver-ati at 
lists.x.org
   |.org|
  QAContact||xorg-team at lists.x.org

--- Comment #1 from Michel D?nzer  2010-06-04 08:49:58 
PDT ---
DRI2 synchronization is handled by the X driver.

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

[Bug 28386] [KMS] echo standby > /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

--- Comment #2 from Alex Deucher  2010-06-04 08:38:17 PDT 
---
Is this a recent regression?  Has s/r worked previously for you with kms?

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

[Bug 28386] [KMS] echo standby > /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

--- Comment #1 from Andrew Randrianasulu  2010-06-04 
07:25:28 PDT ---
Created an attachment (id=36059)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=36059)
normal dmesg

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

[Bug 28386] New: [KMS] echo standby > /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

   Summary: [KMS] echo standby > /sys/power/state hang machine
forever
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: randrik at mail.ru


Using mainline kernel up to 

commit 03cd3739818d3fa7f973d0fb6d3aa63122ea00a0
Merge: 1067b6c 06b4367
Author: Linus Torvalds 
Date:   Thu Jun 3 07:20:28 2010 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6

i got hard-freeze right after monitor goes into standby mode (blinking led on
monitor itself).

Same kernel goes into standby mode OK with nouveau driver or with modprobe
radeon modeset=0.

This was observed right after console login, but starting X before makes no
difference.

Videocard:

01:00.0 0300: 1002:5964 (rev 01) (prog-if 00 [VGA controller])
Subsystem: 1787:5964
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-  /sys/power/pm_async) doesn't help
setting pm_test to [devices] freezes like plain "echo standby >
/sys/power/state"

I'll attach dmesg from normal boot

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

[Bug 28383] New: Cloned screens with different res/refresh cause problems with mesa demos since new dri2 vsync.

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28383

   Summary: Cloned screens with different res/refresh cause
problems with mesa demos since new dri2 vsync.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: lists at andyfurniss.entadsl.com


I think this is linked to the new dri2 vsync but mat be wrong...

rv670 mesa git, ddx git xorg git (2 weeks ago) drt kernels.

Not just latest drt and unrelated to tiling patches.

I am starting with a TV connected @ 1024x768 + vga monitor @ 1920x1080 so the
top left section of the monitor screen gets tv(50Hz) vsync - monitor is 60Hz.

If I start a mesa demo and it starts in the TV area it will sync to 50HZ if I
move it outside the top left area it will sync to 60Hz.

The problem is if I then move it back to the TV area it will stop rendering and
become unresponsive. I can  it but the window will remain. If I the
move the window around enough I can get xserver to segfault.

This doesn't happen with UMS or a drt from 29th April (uses old vsync).
It doesn't happen if I disable TV with xrandr.

[   489.682] 0: /home/andy/Src/Xorg-git/modular/bin/Xorg (xorg_backtrace+0x3b)
[0x80da21b]
[   489.682] 1: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x59ca5)
[0x80a1ca5]
[   489.682] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xe40c]
[   489.682] 3: /home/andy/Src/Xorg-git/modular/bin/Xorg (LocalClient+0x41)
[0x809d8d1]
[   489.682] 4:
/home/andy/Src/Xorg-git/modular/lib/xorg/modules/extensions/libdri2.so
(0xb73ce000+0x309b) [0xb73d109b]
[   489.682] 5: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x25198)
[0x806d198]
[   489.682] 6: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x1a86a)
[0x806286a]
[   489.682] 7: /lib/libc.so.6 (__libc_start_main+0xd0) [0xb7495380]
[   489.682] 8: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x1a481)
[0x8062481]
[   489.682] Segmentation fault at address 0x18

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

[Bug 28381] New: rv670 + tiling patches + tiling enabled = parse errors on some demos.

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28381

   Summary: rv670 + tiling patches + tiling enabled = parse errors
on some demos.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: lists at andyfurniss.entadsl.com


Running drt + patch that fixes
https://bugs.freedesktop.org/show_bug.cgi?id=28327.

Patched Mesa and ddx for tiling and did some testing - I can't reproduce

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

but if I enable tiling in xorg.conf I get parse errors with some demos, but not
others.

eg [glx]gears will quit with drmRadeonCmdBuffer: -22. Kernel failed to parse or
rejected command stream, dmesg =

radeon :02:00.0: r600_cs_track_validate_cb:216 cb height (306) invalid
radeon :02:00.0: r600_packet3_check:1245 invalid cmd stream 520
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

Other demos eg gloss, cubemap shadowtex also fail 
but others work OK eg.
morph3d, tunnel, geartrain, openarena, nexuiz and mplayer -vo gl.

I tried the ddx patch that fixes the cold boot bug above, but it doesn't help.

-- 
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/pm: add support for SetVoltage cmd table (V2)

2010-06-04 Thread Rafał Miłecki 
2010/5/28 Alex Deucher :
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index dac2534..d84d7cf 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -475,6 +475,12 @@ void r600_pm_init_profile(struct radeon_device *rdev)
>
> ?void r600_pm_misc(struct radeon_device *rdev)
> ?{
> + ? ? ? int requested_index = rdev->pm.requested_power_state_index;
> + ? ? ? struct radeon_power_state *ps = 
> >pm.power_state[requested_index];
> + ? ? ? struct radeon_voltage *voltage = >clock_info[0].voltage;
> +
> + ? ? ? if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
> + ? ? ? ? ? ? ? radeon_atom_set_voltage(rdev, voltage->voltage);
>
> ?}
>

In case of my RV620 I can see (using AtomDis):
0004:  UCHAR ucVoltageType = 0x01   (1)
so it looks that my GPU uses VOLTAGE_GPIO (it's 0x01).

You seem to do not use SetVoltage AtomBIOS command for VOLTAGE_GPIO.
However in case of my BIOS there is SetVoltage command table.

Could you comment on this, please?

-- 
Rafa?

[PATCH] drm/radeon/kms/pm: voltage fixes

2010-06-04 Thread Rafał Miłecki 
2010/5/27 Alex Deucher :
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 7b5e10d..102c744 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -2454,7 +2454,12 @@ default_mode:
> ? ? ? ?rdev->pm.power_state[state_index].clock_info[0].mclk = 
> rdev->clock.default_mclk;
> ? ? ? ?rdev->pm.power_state[state_index].clock_info[0].sclk = 
> rdev->clock.default_sclk;
> ? ? ? ?rdev->pm.power_state[state_index].default_clock_mode = 
> >pm.power_state[state_index].clock_info[0];
> - ? ? ? rdev->pm.power_state[state_index].clock_info[0].voltage.type = 
> VOLTAGE_NONE;
> + ? ? ? if ((state_index > 0) &&
> + ? ? ? ? ? (rdev->pm.power_state[0].clock_info[0].voltage.type = 
> VOLTAGE_GPIO))
> + ? ? ? ? ? ? ? rdev->pm.power_state[state_index].clock_info[0].voltage =
> + ? ? ? ? ? ? ? ? ? ? ? rdev->pm.power_state[0].clock_info[0].voltage;
> + ? ? ? else
> + ? ? ? ? ? ? ? rdev->pm.power_state[state_index].clock_info[0].voltage.type 
> = VOLTAGE_NONE;

Condition typo. Assignment -> comparison.

-- 
Rafa?

[Bug 28342] When cold-booting gfx is messed up with latest drm-radeon-testing kernel

2010-06-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=28342

--- Comment #29 from Magnus Jensen  2010-06-03 
23:43:31 PDT ---
(In reply to comment #28)
> Created an attachment (id=36045)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36045
 Review: https://bugs.freedesktop.org/review?bug=28342=36045

> emit DB_DEPTH_INFO
> 
> Try this ddx patch in case 2 instead of the last patch I attached.

Yes, that fixes it for me!

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 28342] When cold-booting gfx is messed up with latest drm-radeon-testing kernel

2010-06-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28342

--- Comment #29 from Magnus Jensen mag...@jensenligan.se 2010-06-03 23:43:31 
PDT ---
(In reply to comment #28)
 Created an attachment (id=36045)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36045
 Review: https://bugs.freedesktop.org/review?bug=28342attachment=36045

 emit DB_DEPTH_INFO
 
 Try this ddx patch in case 2 instead of the last patch I attached.

Yes, that fixes it for me!

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

Re: [PATCH] drm/radeon/kms/evergreen: set accel_enabled

2010-06-04 Thread Jerome Glisse 
On Thu, Jun 03, 2010 at 07:07:09PM -0400, Alex Deucher wrote:
 This is needed to enable accel in the ddx.  However,
 due to a bug in older versions of the ddx, it relies
 on accel being disabled in order to load properly on
 evergreen chips.  To maintain compatility, we add a new
 get accel param and call that from the ddx.  The old one
 always returns false for evergreen cards.
 
 Signed-off-by: Alex Deucher alexdeuc...@gmail.com

I am not sure i understand how it happened ? This really bad
that we have to add accel working2, this is ugly...

I am waiting for accel_working3

Cheers,
Jerome

 ---
  drivers/gpu/drm/radeon/evergreen.c  |2 +-
  drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
  drivers/gpu/drm/radeon/radeon_kms.c |9 -
  include/drm/radeon_drm.h|1 +
  4 files changed, 12 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/evergreen.c 
 b/drivers/gpu/drm/radeon/evergreen.c
 index 0440c09..49c94ae 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -2153,7 +2153,7 @@ int evergreen_init(struct radeon_device *rdev)
   if (r)
   return r;
  
 - rdev-accel_working = false;
 + rdev-accel_working = true;
   r = evergreen_startup(rdev);
   if (r) {
   dev_err(rdev-dev, disabling GPU acceleration\n);
 diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
 b/drivers/gpu/drm/radeon/radeon_drv.c
 index 902d173..e166fe4 100644
 --- a/drivers/gpu/drm/radeon/radeon_drv.c
 +++ b/drivers/gpu/drm/radeon/radeon_drv.c
 @@ -45,9 +45,10 @@
   * - 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
 + * - 2.5.0 - add get accel 2 to work around ddx breakage for evergreen
   */
  #define KMS_DRIVER_MAJOR 2
 -#define KMS_DRIVER_MINOR 4
 +#define KMS_DRIVER_MINOR 5
  #define KMS_DRIVER_PATCHLEVEL0
  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 0406835..6a70c0d 100644
 --- a/drivers/gpu/drm/radeon/radeon_kms.c
 +++ b/drivers/gpu/drm/radeon/radeon_kms.c
 @@ -118,7 +118,11 @@ int radeon_info_ioctl(struct drm_device *dev, void 
 *data, struct drm_file *filp)
   value = rdev-num_z_pipes;
   break;
   case RADEON_INFO_ACCEL_WORKING:
 - value = rdev-accel_working;
 + /* xf86-video-ati 6.13.0 relies on this being false for 
 evergreen */
 + if ((rdev-family = CHIP_CEDAR)  (rdev-family = 
 CHIP_HEMLOCK))
 + value = false;
 + else
 + value = rdev-accel_working;
   break;
   case RADEON_INFO_CRTC_FROM_ID:
   for (i = 0, found = 0; i  rdev-num_crtc; i++) {
 @@ -134,6 +138,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
 struct drm_file *filp)
   return -EINVAL;
   }
   break;
 + case RADEON_INFO_ACCEL_WORKING2:
 + value = rdev-accel_working;
 + 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 3ff9fc0..5347063 100644
 --- a/include/drm/radeon_drm.h
 +++ b/include/drm/radeon_drm.h
 @@ -903,6 +903,7 @@ struct drm_radeon_cs {
  #define RADEON_INFO_NUM_Z_PIPES  0x02
  #define RADEON_INFO_ACCEL_WORKING0x03
  #define RADEON_INFO_CRTC_FROM_ID 0x04
 +#define RADEON_INFO_ACCEL_WORKING2   0x05
  
  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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: r600 dump last 64 dwords of ring.

2010-06-04 Thread Jerome Glisse 
Instead of dumping unprocessed dwords, dump the last 64
dwords of the ring. This make debugging of some case easier.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index f68cc92..1537079 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3371,9 +3371,9 @@ static int r600_debugfs_cp_ring_info(struct seq_file *m, 
void *data)
seq_printf(m, driver's copy of the CP_RB_RPTR 0x%08x\n, 
rdev-cp.rptr);
seq_printf(m, %u free dwords in ring\n, rdev-cp.ring_free_dw);
seq_printf(m, %u dwords in ring\n, count);
-   i = rdev-cp.rptr;
-   for (j = 0; j = count; j++) {
-   seq_printf(m, r[%04d]=0x%08x\n, i, rdev-cp.ring[i]);
+   i = (rdev-cp.wptr + (rdev-cp.ring_size / 4) - 64)  rdev-cp.ptr_mask;
+   for (j = 0; j = 64; j++) {
+   seq_printf(m, r[%04d]=0x%08X\n, i, rdev-cp.ring[i]);
i = (i + 1)  rdev-cp.ptr_mask;
}
return 0;
-- 
1.7.0.1

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

[Bug 28383] New: Cloned screens with different res/refresh cause problems with mesa demos since new dri2 vsync.

2010-06-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28383

   Summary: Cloned screens with different res/refresh cause
problems with mesa demos since new dri2 vsync.
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: li...@andyfurniss.entadsl.com


I think this is linked to the new dri2 vsync but mat be wrong...

rv670 mesa git, ddx git xorg git (2 weeks ago) drt kernels.

Not just latest drt and unrelated to tiling patches.

I am starting with a TV connected @ 1024x768 + vga monitor @ 1920x1080 so the
top left section of the monitor screen gets tv(50Hz) vsync - monitor is 60Hz.

If I start a mesa demo and it starts in the TV area it will sync to 50HZ if I
move it outside the top left area it will sync to 60Hz.

The problem is if I then move it back to the TV area it will stop rendering and
become unresponsive. I can ctrlc it but the window will remain. If I the
move the window around enough I can get xserver to segfault.

This doesn't happen with UMS or a drt from 29th April (uses old vsync).
It doesn't happen if I disable TV with xrandr.

[   489.682] 0: /home/andy/Src/Xorg-git/modular/bin/Xorg (xorg_backtrace+0x3b)
[0x80da21b]
[   489.682] 1: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x59ca5)
[0x80a1ca5]
[   489.682] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xe40c]
[   489.682] 3: /home/andy/Src/Xorg-git/modular/bin/Xorg (LocalClient+0x41)
[0x809d8d1]
[   489.682] 4:
/home/andy/Src/Xorg-git/modular/lib/xorg/modules/extensions/libdri2.so
(0xb73ce000+0x309b) [0xb73d109b]
[   489.682] 5: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x25198)
[0x806d198]
[   489.682] 6: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x1a86a)
[0x806286a]
[   489.682] 7: /lib/libc.so.6 (__libc_start_main+0xd0) [0xb7495380]
[   489.682] 8: /home/andy/Src/Xorg-git/modular/bin/Xorg (0x8048000+0x1a481)
[0x8062481]
[   489.682] Segmentation fault at address 0x18

-- 
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: r600 reset GPU at module load time

2010-06-04 Thread Jerome Glisse 
When loading/unloading several time the driver on r600 we
end up with the GPU in broken state and loading fail to
initialize acceleration. Reset the GPU at load time so
acceleration keep working over load/unload.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c |   20 +---
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 1537079..5fc0525 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1163,13 +1163,6 @@ int r600_gpu_soft_reset(struct radeon_device *rdev)
S_008014_CB2_BUSY(1) | S_008014_CB3_BUSY(1);
u32 tmp;
 
-   dev_info(rdev-dev, GPU softreset \n);
-   dev_info(rdev-dev,   R_008010_GRBM_STATUS=0x%08X\n,
-   RREG32(R_008010_GRBM_STATUS));
-   dev_info(rdev-dev,   R_008014_GRBM_STATUS2=0x%08X\n,
-   RREG32(R_008014_GRBM_STATUS2));
-   dev_info(rdev-dev,   R_000E50_SRBM_STATUS=0x%08X\n,
-   RREG32(R_000E50_SRBM_STATUS));
rv515_mc_stop(rdev, save);
if (r600_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
@@ -1245,6 +1238,13 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)
 
 int r600_asic_reset(struct radeon_device *rdev)
 {
+   dev_info(rdev-dev, GPU softreset \n);
+   dev_info(rdev-dev,   R_008010_GRBM_STATUS=0x%08X\n,
+   RREG32(R_008010_GRBM_STATUS));
+   dev_info(rdev-dev,   R_008014_GRBM_STATUS2=0x%08X\n,
+   RREG32(R_008014_GRBM_STATUS2));
+   dev_info(rdev-dev,   R_000E50_SRBM_STATUS=0x%08X\n,
+   RREG32(R_000E50_SRBM_STATUS));
return r600_gpu_soft_reset(rdev);
 }
 
@@ -2460,6 +2460,12 @@ int r600_init(struct radeon_device *rdev)
DRM_INFO(GPU not posted. posting now...\n);
atom_asic_init(rdev-mode_info.atom_context);
}
+
+   /* GPU is sometimes in broken state (especialy after loading/unloading
+* the driver several time. Reset the GPU.
+*/
+   r600_gpu_soft_reset(rdev);
+
/* Initialize scratch registers */
r600_scratch_init(rdev);
/* Initialize surface registers */
-- 
1.7.0.1

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

[PATCH] drm/radeon/kms: r600 reset GPU at module load time v2

2010-06-04 Thread Jerome Glisse 
When loading/unloading several time the driver on r600 we
end up with the GPU in broken state and loading fail to
initialize acceleration. Reset the GPU at load time so
acceleration keep working over load/unload.

v2 Move status print after reset in asic_reset to avoid
cluttering log with this at module load time.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r600.c |   37 +++--
 1 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 1537079..b932f48 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1163,13 +1163,6 @@ int r600_gpu_soft_reset(struct radeon_device *rdev)
S_008014_CB2_BUSY(1) | S_008014_CB3_BUSY(1);
u32 tmp;
 
-   dev_info(rdev-dev, GPU softreset \n);
-   dev_info(rdev-dev,   R_008010_GRBM_STATUS=0x%08X\n,
-   RREG32(R_008010_GRBM_STATUS));
-   dev_info(rdev-dev,   R_008014_GRBM_STATUS2=0x%08X\n,
-   RREG32(R_008014_GRBM_STATUS2));
-   dev_info(rdev-dev,   R_000E50_SRBM_STATUS=0x%08X\n,
-   RREG32(R_000E50_SRBM_STATUS));
rv515_mc_stop(rdev, save);
if (r600_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
@@ -1207,12 +1200,6 @@ int r600_gpu_soft_reset(struct radeon_device *rdev)
WREG32(R_008020_GRBM_SOFT_RESET, 0);
/* Wait a little for things to settle down */
mdelay(1);
-   dev_info(rdev-dev,   R_008010_GRBM_STATUS=0x%08X\n,
-   RREG32(R_008010_GRBM_STATUS));
-   dev_info(rdev-dev,   R_008014_GRBM_STATUS2=0x%08X\n,
-   RREG32(R_008014_GRBM_STATUS2));
-   dev_info(rdev-dev,   R_000E50_SRBM_STATUS=0x%08X\n,
-   RREG32(R_000E50_SRBM_STATUS));
rv515_mc_resume(rdev, save);
return 0;
 }
@@ -1245,7 +1232,23 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)
 
 int r600_asic_reset(struct radeon_device *rdev)
 {
-   return r600_gpu_soft_reset(rdev);
+   int r;
+
+   dev_info(rdev-dev, GPU softreset \n);
+   dev_info(rdev-dev,   R_008010_GRBM_STATUS=0x%08X\n,
+   RREG32(R_008010_GRBM_STATUS));
+   dev_info(rdev-dev,   R_008014_GRBM_STATUS2=0x%08X\n,
+   RREG32(R_008014_GRBM_STATUS2));
+   dev_info(rdev-dev,   R_000E50_SRBM_STATUS=0x%08X\n,
+   RREG32(R_000E50_SRBM_STATUS));
+   r = r600_gpu_soft_reset(rdev);
+   dev_info(rdev-dev,   R_008010_GRBM_STATUS=0x%08X\n,
+   RREG32(R_008010_GRBM_STATUS));
+   dev_info(rdev-dev,   R_008014_GRBM_STATUS2=0x%08X\n,
+   RREG32(R_008014_GRBM_STATUS2));
+   dev_info(rdev-dev,   R_000E50_SRBM_STATUS=0x%08X\n,
+   RREG32(R_000E50_SRBM_STATUS));
+   return r;
 }
 
 static u32 r600_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
@@ -2460,6 +2463,12 @@ int r600_init(struct radeon_device *rdev)
DRM_INFO(GPU not posted. posting now...\n);
atom_asic_init(rdev-mode_info.atom_context);
}
+
+   /* GPU is sometimes in broken state (especialy after loading/unloading
+* the driver several time. Reset the GPU.
+*/
+   r600_gpu_soft_reset(rdev);
+
/* Initialize scratch registers */
r600_scratch_init(rdev);
/* Initialize surface registers */
-- 
1.7.0.1

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

Re: [PATCH] drm/radeon/kms: r600 dump last 64 dwords of ring.

2010-06-04 Thread Rafał Miłecki 
2010/6/4 Jerome Glisse jgli...@redhat.com:
 Instead of dumping unprocessed dwords, dump the last 64
 dwords of the ring. This make debugging of some case easier.

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/radeon/r600.c |    6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
 index f68cc92..1537079 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -3371,9 +3371,9 @@ static int r600_debugfs_cp_ring_info(struct seq_file 
 *m, void *data)
        seq_printf(m, driver's copy of the CP_RB_RPTR 0x%08x\n, 
 rdev-cp.rptr);
        seq_printf(m, %u free dwords in ring\n, rdev-cp.ring_free_dw);
        seq_printf(m, %u dwords in ring\n, count);
 -       i = rdev-cp.rptr;
 -       for (j = 0; j = count; j++) {
 -               seq_printf(m, r[%04d]=0x%08x\n, i, rdev-cp.ring[i]);
 +       i = (rdev-cp.wptr + (rdev-cp.ring_size / 4) - 64)  
 rdev-cp.ptr_mask;
 +       for (j = 0; j = 64; j++) {
 +               seq_printf(m, r[%04d]=0x%08X\n, i, rdev-cp.ring[i]);
                i = (i + 1)  rdev-cp.ptr_mask;
        }
        return 0;
 --
 1.7.0.1

What about same for r1xx-r5xx? Could you care?

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

Re: Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Marius Gröger 
Hi All,

Michel Dänzer schrieb:
 On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote: 
 Hello All,

 I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
 drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
 application is mythtv which uses DRM syncing for the frame
 syncronisation. Now, with the exact same userland software I noticed the
 introduction of sync gliches in the May-timeframe. The
 drm-radeon-testing on May 9 was still ok, but both drm-next and
 drm-radeon-testing at the end of May showed that glitch: every couple of
 seconds there's a very visual hickup, especially in scroll texts.

 Apologies for such an unspecific description, and for what almost seems
 like a support request for MythTV. I wouldn't post here if I were not
 100% sure it must be related with the recent drm changes.
 
 Note that the DRM APIs are intended for use by userspace components of
 graphics drivers / API libraries, not applications directly. MythTV
 shouldn't use the DRM directly for synchronization but rather use GLX
 synchronization APIs.

What about that new dri2 vsync stuff which was mentioned related to [Bug
28383]? Could the changes done for that in any way alter the timing? BTW
I measured the glitches I'm experiencing and the appear to be to happen
in intervals of 10 seconds. Again, all I'm changing is the kernel, and
even the kernel config is the same. I'd be most grateful for any
clues/hints/tips I could follow to resolve this regression.

 If you have dynamic PM enabled, does disabling that help?

I checked again and there's method=profile and profile=default. Afaict
this is not using dynpm, right?

Marius

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

[patch] drm/drm_crtc: return -EFAULT on copy_to_user errors

2010-06-04 Thread Dan Carpenter 
copy_from_user() returns the number of bytes left to be copied but we
want to return a negative error code here.  This is in the ioctl handler
so the error code get returned to userspace.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 994d23b..57cea01 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1840,8 +1840,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
 
ret = copy_from_user(clips, clips_ptr,
 num_clips * sizeof(*clips));
-   if (ret)
+   if (ret) {
+   ret = -EFAULT;
goto out_err2;
+   }
}
 
if (fb-funcs-dirty) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/vmwgfx: return -EFAULT for copy_to_user errors

2010-06-04 Thread Dan Carpenter 
copy_to/from_user() returns the number of bytes remaining to be copied
but we want to return a negative error code here.  This gets returned to
userspace.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index f8fbbc6..8612378 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -597,8 +597,10 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,
 
ret = copy_from_user(srf-sizes, user_sizes,
 srf-num_sizes * sizeof(*srf-sizes));
-   if (unlikely(ret != 0))
+   if (unlikely(ret != 0)) {
+   ret = -EFAULT;
goto out_err1;
+   }
 
if (srf-scanout 
srf-num_sizes == 1 
@@ -697,9 +699,11 @@ int vmw_surface_reference_ioctl(struct drm_device *dev, 
void *data,
if (user_sizes)
ret = copy_to_user(user_sizes, srf-sizes,
   srf-num_sizes * sizeof(*srf-sizes));
-   if (unlikely(ret != 0))
+   if (unlikely(ret != 0)) {
DRM_ERROR(copy_to_user failed %p %u\n,
  user_sizes, srf-num_sizes);
+   ret = -EFAULT;
+   }
 out_bad_resource:
 out_no_reference:
ttm_base_object_unref(base);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index dbd36b8..ba15038 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -644,6 +644,7 @@ int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
ret = copy_from_user(cmd, user_cmd, arg-command_size);
 
if (unlikely(ret != 0)) {
+   ret = -EFAULT;
DRM_ERROR(Failed copying commands.\n);
goto out_commit;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28386] [KMS] echo standby /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

--- Comment #1 from Andrew Randrianasulu rand...@mail.ru 2010-06-04 07:25:28 
PDT ---
Created an attachment (id=36059)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=36059)
normal dmesg

-- 
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/evergreen: set accel_enabled

2010-06-04 Thread Alex Deucher 
On Fri, Jun 4, 2010 at 6:37 AM, Jerome Glisse gli...@freedesktop.org wrote:
 On Thu, Jun 03, 2010 at 07:07:09PM -0400, Alex Deucher wrote:
 This is needed to enable accel in the ddx.  However,
 due to a bug in older versions of the ddx, it relies
 on accel being disabled in order to load properly on
 evergreen chips.  To maintain compatility, we add a new
 get accel param and call that from the ddx.  The old one
 always returns false for evergreen cards.

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com

 I am not sure i understand how it happened ? This really bad
 that we have to add accel working2, this is ugly...


Yeah it sucks.  Unfortunately I forgot to explicitly disable accel on
evergreen when we released 6.13.0 so it relies on accel working to
return false, otherwise it tries to init accel.

Alex

 I am waiting for accel_working3

 Cheers,
 Jerome

 ---
  drivers/gpu/drm/radeon/evergreen.c  |    2 +-
  drivers/gpu/drm/radeon/radeon_drv.c |    3 ++-
  drivers/gpu/drm/radeon/radeon_kms.c |    9 -
  include/drm/radeon_drm.h            |    1 +
  4 files changed, 12 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen.c 
 b/drivers/gpu/drm/radeon/evergreen.c
 index 0440c09..49c94ae 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -2153,7 +2153,7 @@ int evergreen_init(struct radeon_device *rdev)
       if (r)
               return r;

 -     rdev-accel_working = false;
 +     rdev-accel_working = true;
       r = evergreen_startup(rdev);
       if (r) {
               dev_err(rdev-dev, disabling GPU acceleration\n);
 diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
 b/drivers/gpu/drm/radeon/radeon_drv.c
 index 902d173..e166fe4 100644
 --- a/drivers/gpu/drm/radeon/radeon_drv.c
 +++ b/drivers/gpu/drm/radeon/radeon_drv.c
 @@ -45,9 +45,10 @@
   * - 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
 + * - 2.5.0 - add get accel 2 to work around ddx breakage for evergreen
   */
  #define KMS_DRIVER_MAJOR     2
 -#define KMS_DRIVER_MINOR     4
 +#define KMS_DRIVER_MINOR     5
  #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 0406835..6a70c0d 100644
 --- a/drivers/gpu/drm/radeon/radeon_kms.c
 +++ b/drivers/gpu/drm/radeon/radeon_kms.c
 @@ -118,7 +118,11 @@ int radeon_info_ioctl(struct drm_device *dev, void 
 *data, struct drm_file *filp)
               value = rdev-num_z_pipes;
               break;
       case RADEON_INFO_ACCEL_WORKING:
 -             value = rdev-accel_working;
 +             /* xf86-video-ati 6.13.0 relies on this being false for 
 evergreen */
 +             if ((rdev-family = CHIP_CEDAR)  (rdev-family = 
 CHIP_HEMLOCK))
 +                     value = false;
 +             else
 +                     value = rdev-accel_working;
               break;
       case RADEON_INFO_CRTC_FROM_ID:
               for (i = 0, found = 0; i  rdev-num_crtc; i++) {
 @@ -134,6 +138,9 @@ int radeon_info_ioctl(struct drm_device *dev, void 
 *data, struct drm_file *filp)
                       return -EINVAL;
               }
               break;
 +     case RADEON_INFO_ACCEL_WORKING2:
 +             value = rdev-accel_working;
 +             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 3ff9fc0..5347063 100644
 --- a/include/drm/radeon_drm.h
 +++ b/include/drm/radeon_drm.h
 @@ -903,6 +903,7 @@ struct drm_radeon_cs {
  #define RADEON_INFO_NUM_Z_PIPES      0x02
  #define RADEON_INFO_ACCEL_WORKING    0x03
  #define RADEON_INFO_CRTC_FROM_ID     0x04
 +#define RADEON_INFO_ACCEL_WORKING2   0x05

  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: Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Alex Deucher 
2010/6/4 Marius Gröger marius.groe...@googlemail.com:
 Hi All,

 Michel Dänzer schrieb:
 On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote:
 Hello All,

 I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
 drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
 application is mythtv which uses DRM syncing for the frame
 syncronisation. Now, with the exact same userland software I noticed the
 introduction of sync gliches in the May-timeframe. The
 drm-radeon-testing on May 9 was still ok, but both drm-next and
 drm-radeon-testing at the end of May showed that glitch: every couple of
 seconds there's a very visual hickup, especially in scroll texts.

 Apologies for such an unspecific description, and for what almost seems
 like a support request for MythTV. I wouldn't post here if I were not
 100% sure it must be related with the recent drm changes.

 Note that the DRM APIs are intended for use by userspace components of
 graphics drivers / API libraries, not applications directly. MythTV
 shouldn't use the DRM directly for synchronization but rather use GLX
 synchronization APIs.

 What about that new dri2 vsync stuff which was mentioned related to [Bug
 28383]? Could the changes done for that in any way alter the timing? BTW
 I measured the glitches I'm experiencing and the appear to be to happen
 in intervals of 10 seconds. Again, all I'm changing is the kernel, and
 even the kernel config is the same. I'd be most grateful for any
 clues/hints/tips I could follow to resolve this regression.

 If you have dynamic PM enabled, does disabling that help?

 I checked again and there's method=profile and profile=default. Afaict
 this is not using dynpm, right?


Correct.

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

Re: Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Marius Gröger 
Alex Deucher schrieb:
 2010/6/4 Marius Gröger marius.groe...@googlemail.com:
 Hi All,

 Michel Dänzer schrieb:
 On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote:
 Hello All,

 I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
 drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
 application is mythtv which uses DRM syncing for the frame
 syncronisation. Now, with the exact same userland software I noticed the
 introduction of sync gliches in the May-timeframe. The
 drm-radeon-testing on May 9 was still ok, but both drm-next and
 drm-radeon-testing at the end of May showed that glitch: every couple of
 seconds there's a very visual hickup, especially in scroll texts.

 Apologies for such an unspecific description, and for what almost seems
 like a support request for MythTV. I wouldn't post here if I were not
 100% sure it must be related with the recent drm changes.
 Note that the DRM APIs are intended for use by userspace components of
 graphics drivers / API libraries, not applications directly. MythTV
 shouldn't use the DRM directly for synchronization but rather use GLX
 synchronization APIs.
 What about that new dri2 vsync stuff which was mentioned related to [Bug
 28383]? Could the changes done for that in any way alter the timing? BTW
 I measured the glitches I'm experiencing and the appear to be to happen
 in intervals of 10 seconds. Again, all I'm changing is the kernel, and
 even the kernel config is the same. I'd be most grateful for any
 clues/hints/tips I could follow to resolve this regression.

 If you have dynamic PM enabled, does disabling that help?
 I checked again and there's method=profile and profile=default. Afaict
 this is not using dynpm, right?

 
 Correct.

Ok so with dynpm more or less ruled out, what could have such a visible
impact on the latencies? For instance, are we now more dependent (or
less) on some kind of interrupt or deferred processing than 6 weeks ago?

Btw, I have HDMI audio pretty much ruled out as well.

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

Re: Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Alex Deucher 
2010/6/4 Marius Gröger marius.groe...@googlemail.com:
 Alex Deucher schrieb:
 2010/6/4 Marius Gröger marius.groe...@googlemail.com:
 Hi All,

 Michel Dänzer schrieb:
 On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote:
 Hello All,

 I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
 drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary
 application is mythtv which uses DRM syncing for the frame
 syncronisation. Now, with the exact same userland software I noticed the
 introduction of sync gliches in the May-timeframe. The
 drm-radeon-testing on May 9 was still ok, but both drm-next and
 drm-radeon-testing at the end of May showed that glitch: every couple of
 seconds there's a very visual hickup, especially in scroll texts.

 Apologies for such an unspecific description, and for what almost seems
 like a support request for MythTV. I wouldn't post here if I were not
 100% sure it must be related with the recent drm changes.
 Note that the DRM APIs are intended for use by userspace components of
 graphics drivers / API libraries, not applications directly. MythTV
 shouldn't use the DRM directly for synchronization but rather use GLX
 synchronization APIs.
 What about that new dri2 vsync stuff which was mentioned related to [Bug
 28383]? Could the changes done for that in any way alter the timing? BTW
 I measured the glitches I'm experiencing and the appear to be to happen
 in intervals of 10 seconds. Again, all I'm changing is the kernel, and
 even the kernel config is the same. I'd be most grateful for any
 clues/hints/tips I could follow to resolve this regression.

 If you have dynamic PM enabled, does disabling that help?
 I checked again and there's method=profile and profile=default. Afaict
 this is not using dynpm, right?


 Correct.

 Ok so with dynpm more or less ruled out, what could have such a visible
 impact on the latencies? For instance, are we now more dependent (or
 less) on some kind of interrupt or deferred processing than 6 weeks ago?

 Btw, I have HDMI audio pretty much ruled out as well.

Any chance you can bisect the problematic commit?

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

[Bug 28386] [KMS] echo standby /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

--- Comment #2 from Alex Deucher ag...@yahoo.com 2010-06-04 08:38:17 PDT ---
Is this a recent regression?  Has s/r worked previously for you with kms?

-- 
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 28386] [KMS] echo standby /sys/power/state hang machine forever

2010-06-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28386

--- Comment #3 from Andrew Randrianasulu rand...@mail.ru 2010-06-04 11:58:59 
PDT ---
(In reply to comment #2)
 Is this a recent regression?  Has s/r worked previously for you with kms?

May be 0.5 year ago it was working, so not really recent. (I rarely use this
mode).

-- 
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: r600 dump last 64 dwords of ring.

2010-06-04 Thread Jerome Glisse 
On Fri, Jun 04, 2010 at 02:54:42PM +0200, Rafał Miłecki wrote:
 2010/6/4 Jerome Glisse jgli...@redhat.com:
  Instead of dumping unprocessed dwords, dump the last 64
  dwords of the ring. This make debugging of some case easier.
 
  Signed-off-by: Jerome Glisse jgli...@redhat.com
  ---
   drivers/gpu/drm/radeon/r600.c |    6 +++---
   1 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
  index f68cc92..1537079 100644
  --- a/drivers/gpu/drm/radeon/r600.c
  +++ b/drivers/gpu/drm/radeon/r600.c
  @@ -3371,9 +3371,9 @@ static int r600_debugfs_cp_ring_info(struct seq_file 
  *m, void *data)
         seq_printf(m, driver's copy of the CP_RB_RPTR 0x%08x\n, 
  rdev-cp.rptr);
         seq_printf(m, %u free dwords in ring\n, rdev-cp.ring_free_dw);
         seq_printf(m, %u dwords in ring\n, count);
  -       i = rdev-cp.rptr;
  -       for (j = 0; j = count; j++) {
  -               seq_printf(m, r[%04d]=0x%08x\n, i, rdev-cp.ring[i]);
  +       i = (rdev-cp.wptr + (rdev-cp.ring_size / 4) - 64)  
  rdev-cp.ptr_mask;
  +       for (j = 0; j = 64; j++) {
  +               seq_printf(m, r[%04d]=0x%08X\n, i, rdev-cp.ring[i]);
                 i = (i + 1)  rdev-cp.ptr_mask;
         }
         return 0;
  --
  1.7.0.1
 
 What about same for r1xx-r5xx? Could you care?
 
 -- 
 Rafał

Yes will do the patch, sorry i was working on r6xx bug at the time i did
this patch.

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

Re: Glitch in newer drm-next/drm-radeon-testing

2010-06-04 Thread Alex Deucher 
2010/6/4 Marius Gröger marius.groe...@googlemail.com:
 Am Fri, 4 Jun 2010 11:17:12 -0400
 schrieb Alex Deucher alexdeuc...@gmail.com:

 2010/6/4 Marius Gröger marius.groe...@googlemail.com:
  Alex Deucher schrieb:
  2010/6/4 Marius Gröger marius.groe...@googlemail.com:
  Hi All,
 
  Michel Dänzer schrieb:
  On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote:
  Hello All,
 
  I'm trying the top-of-trunk drm-2.6 trees (both drm-next and
  drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The
  primary application is mythtv which uses DRM syncing for the
  frame syncronisation. Now, with the exact same userland
  software I noticed the introduction of sync gliches in the
  May-timeframe. The drm-radeon-testing on May 9 was still ok,
  but both drm-next and drm-radeon-testing at the end of May
  showed that glitch: every couple of seconds there's a very
  visual hickup, especially in scroll texts.
 
  Apologies for such an unspecific description, and for what
  almost seems like a support request for MythTV. I wouldn't post
  here if I were not 100% sure it must be related with the recent
  drm changes.
  Note that the DRM APIs are intended for use by userspace
  components of graphics drivers / API libraries, not applications
  directly. MythTV shouldn't use the DRM directly for
  synchronization but rather use GLX synchronization APIs.
  What about that new dri2 vsync stuff which was mentioned related
  to [Bug 28383]? Could the changes done for that in any way alter
  the timing? BTW I measured the glitches I'm experiencing and the
  appear to be to happen in intervals of 10 seconds. Again, all I'm
  changing is the kernel, and even the kernel config is the same.
  I'd be most grateful for any clues/hints/tips I could follow to
  resolve this regression.
 
  If you have dynamic PM enabled, does disabling that help?
  I checked again and there's method=profile and profile=default.
  Afaict this is not using dynpm, right?
 
 
  Correct.
 
  Ok so with dynpm more or less ruled out, what could have such a
  visible impact on the latencies? For instance, are we now more
  dependent (or less) on some kind of interrupt or deferred
  processing than 6 weeks ago?
 
  Btw, I have HDMI audio pretty much ruled out as well.

 Any chance you can bisect the problematic commit?

 As I said, I already tried bisecting but failed. Perhaps I can try
 again and replay at least part of the log... But since we're talking
 about more than 120 commits I kinda was hoping to get some clues here
 first. Even with a tailored .config building/rebooting/testing takes
 ages. Well I suppose I needn't tell *you* guys... ;-)


for vsync stuff, It's probably one of these:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=bc35afdb182d4c48c889fe27ba7a5d7ea0c8194d
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4fa07bf146aaee1e8409d35ab08624041c2e3867

Alex

 Thanks
 Marius

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

[Bug 28381] rv670 + tiling patches + tiling enabled = parse errors on some demos.

2010-06-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28381

--- Comment #1 from Alex Deucher ag...@yahoo.com 2010-06-04 15:37:44 PDT ---
Created an attachment (id=36064)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36064
 Review: https://bugs.freedesktop.org/review?bug=28381attachment=36064

cs parser fix

This patch fixes it here.

-- 
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: regression: 2.6.35-rc1 hangs on i865G with KMS

2010-06-04 Thread Eric Anholt 
On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary li...@rainbow-software.org 
wrote:
 Hello,
 I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After 
 loading 
 i915 module, the screen goes blank and the kernel hangs completely (same with 
 2.6.35-rc1-git2). This does not happen with i915.modeset=0 parameter.
 
 This problem does not appear with 2.6.34. Is this a known regression?

Not known as far as I know -- we'd enjoy a bisect with a bug report on
bugs.freedesktop.org.


pgpkf9wVvvcm9.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel