more intel drm issues (was Re: [git pull] drm intel only fixes)

Linus Torvalds torvalds at
Thu Jan 20 12:44:24 PST 2011

On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds
<torvalds at> wrote:
> So how about just doing this in the loop? It will mean that the
> _first_ read uses the fast cached one (the common case, hopefully),
> but then if we loop, we'll use the slow exact one.
> (cut-and-paste, so whitespace isn't good):
>  diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>  index 03e3370..11bbfb5 100644
>  --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>  +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>  @@ -961,6 +961,8 @@ int intel_wait_ring_buffer(struct
> intel_ring_buffer *ring, int n)
>                  msleep(1);
>                  if (atomic_read(&dev_priv->mm.wedged))
>                          return -EAGAIN;
>  +               /* Force a re-read. FIXME: what if read_status_page
> says 0 too */
>  +               ring->actual_head = 0;
>          } while (!time_after(jiffies, end));
>          trace_i915_ring_wait_end (dev);
>          return -EBUSY;

This makes no difference. And the reason is exactly that we get the
zero case that I had in the comment.

But THIS attached patch actually seems to fix the slow suspend for me.
I removed the accesses to "actual_head", because that whole field
seems to not be used.

So it seems like the intel_read_status_page() thing returns zero
forever when suspending. Maybe you can explain why.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 1715 bytes
Desc: not available
URL: <>

More information about the dri-devel mailing list