On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote:
> On Mon, 2014-02-24 at 14:11 +0200, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel Dänzer wrote:
> > > On Fre, 2014-02-21 at 21:03 +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> > > >
> > > > We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
> > > > there simply to make drm_vblank_get() fail during a modeset.
> > >
> > > Actually, their original purpose was to keep the DRM vblank counter
> > > consistent across modesets, assuming the modeset resets the hardware
> > > vblank counter.
> >
> > I see. Well, actually I really don't. The code is too funky for me to
> > tell what it actually ends up doing. The obvious way would be to
> > resample the hardware counter at drm_vblank_post_modeset(), which the
> > code certainly doesn't do. But maybe it did something sensible in the
> > past.
>
> When the pre/post-modeset hooks were originally added, it worked like
> this: the pre-modeset hook enabled the vblank interrupt, which updated
> the DRM vblank counter from the driver/HW counter. The post-modeset hook
> disabled the vblank interrupt again, which recorded the post-modeset
> driver/HW counter value.
>
> But the vblank code has changed a lot since then, not sure it still
> works like that.
It still works like that, but there's two fundamental issues with this
trick:
- There's a race where the vblank state is fubar right between the
completion of the modeset and before the first vblank happened.
- It doesn't work across suspend/resume since no one re-enables the vblank
interrupt.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
