On 15.09.2015 04:43, ville.syrjala@linux.intel.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
When lacking am accurate hardware frame counter, we can fall back to using the vblank timestamps to guesstimagte how many vblanks have elapsed since the last time the vblank counter was updated.
Take the oppostunity to unify the vblank_disable_and_save() and drm_handle_vblank_events() to call the same function (drm_update_vblank_count()) to perform the vblank updates.
It would be nice to keep the drm_update_vblank_count unification separate. As it is, it's very hard to keep track of which parts of the patch are for each logical change.
BTW, I think the fact that I was hitting the problem fixed by 209e4dbc ("drm/vblank: Use u32 consistently for vblank counters") within a few days indicates that there's another bug which causes the counter to jump forward with drm_vblank_on/off(). It may not manifest itself with current Intel hardware because that has a full 32-bit hardware frame counter, turning the related calculations into no-ops. I haven't had time to investigate this further yet.