On Tue, May 20, 2014 at 4:20 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrjälä wrote: >> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote: >> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote: >> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote: >> > > > Now that we unconditionally dtrt when disabling/enabling crtcs we >> > > > don't need any hacks any longer to keep the vblank logic sane when >> > > > all the registers go poof. So let's rip it all out. >> > > >> > > Hmm. drm_update_vblank_count() will now see some kind of diff between >> > > the last and current value when the registers got cloberred. So the >> > > vblank counter reported to userspace will jump. But I guess that's fine >> > > as long as userspace realizes that the counter is not at all reliable >> > > across modesets. >> > >> > I've added checks for this (the rpm varianst) and for the similiar >> > suspend/resume issues (the suspend variants) to kms_flip. It seems to work >> > and we don't actually jump to far. But maybe the tests are horribly >> > broken. >> >> Hmm. If we can force the power well off at the start of the test and then >> set a mode, I'd expect the vblank counter to jump by almost max_vblank_count >> since the hw counter would appear to wrap. > > Oh, I think the tests are busted ... Need to look at this again. I've added some debug output and fixed the suspend variants of the tests and it actually seems to work. I.e. the frame counter before and after a runtime pm or suspend/resume cycle is monotonic and only increases by a few frames. The limit the test uses is 100 frames, which should be tight enough to not confuse userspace. Of course userspace still needs to be able to cope with cancelled vblank events, but that's just how it is. At least the frame counters look sane now. So I think we're good. -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
