On Tue, May 08, 2012 at 09:34:18AM -0300, Paulo Zanoni wrote: > 2012/5/8 Daniel Vetter <dan...@ffwll.ch>: > > On Fri, May 04, 2012 at 05:18:15PM -0300, Paulo Zanoni wrote: > >> From: Paulo Zanoni <paulo.r.zan...@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). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
