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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel