[Intel-gfx] [PATCH 03/14] drm/i915: implement ironlake_wait_for_vblank

[Daniel Vetter]

On Tue, May 08, 2012 at 02:44:24PM +0200, Daniel Vetter wrote:
> On Tue, May 08, 2012 at 09:34:18AM -0300, Paulo Zanoni wrote:
> > 2012/5/8 Daniel Vetter <daniel at ffwll.ch>:
> > > On Fri, May 04, 2012 at 05:18:15PM -0300, Paulo Zanoni wrote:
> > >> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > >>
> > >> intel_wait_for_vblank uses PIPESTAT, which does not exist on Ironlake
> > >> and newer, so now we use PIPEFRAME.
> > >>
> > >> There's also a check to see if the pipe is stopped.
> > >
> > > Hm, why do we have this check here? The other wait_for_vblank
> > > implementation doesn't bother with this. And if we call wait_for_vblank on
> > > a disabled pipe, that's a bug imo.
> > > -Daniel
> > 
> > Because not checking for a stopped pipe adds a useless 50ms delay
> > (it's the wait_for() timeout). We're currently calling
> > wait_for_vblank() on disabled pipes.
> > - Maybe I should add a DRM_DEBUG_KMS message there and then start
> > fixing these cases?
> > - Maybe I should move the check to intel_wait_for_vblank (including
> > the debug message)?
> 
> Either is fine, the thing that irked was just that now the semantics of
> wait_for_vblank changed depending upon which chipset it runs on:
> - for ilk, it will immediately return if the pipe is off
> - for pre-ilk, it will time out for 50 ms, complain with a debug message
>   and then return.
> 
> I'm leaning towards fixing up the callers to not call wait_for_vblank when
> the pipe is off (and ditching the check from the ilk wait_for_vblank).

Paulo acked this on irc, so I've queued the patch for -next with the pipe
check removed, thanks.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48