On Tue, Sep 22, 2015 at 03:36:44PM +0300, Ville Syrjälä wrote:
On Tue, Sep 22, 2015 at 11:10:50AM +0200, Daniel Vetter wrote:
On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala@linux.intel.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
The vblank timestamp ringbuffer only has two entries, so if the vblank->count is incremented by an even number readers may end up seeing the new vblank timestamp alongside the old vblank counter value.
Fix the problem by storing the vblank counter in a ringbuffer as well, and always increment the ringbuffer "slot" by one when storing a new timestamp+counter pair.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com
Imo if we bother with this we might as well just switch over to using full-blown seqlocks. They internally use a two-stage update which means race-free even with just one copy of the data we protect. Also more standardized to boot.
Any volunteers for that? I don't have time to start redoing this right now.
I guess we can keep it as a low-hanging thing for now, didn't seem to have annoyed anyone yet. It should be fairly simple since all the vblank counter access goes through the 2 functions I created a while back while polishing the barriers a bit. -Daniel