On Fri, Feb 11, 2022 at 04:40:55PM +0100, Paul Kocialkowski wrote:
> Hi,
> 
> On Wed 09 Feb 22, 10:26, Maxime Ripard wrote:
> > On Sat, Feb 05, 2022 at 07:53:55PM +0100, Paul Kocialkowski wrote:
> > > This introduces a new state structure and associated helpers for
> > > capture, which handles the buffer queue and state for each submitted
> > > buffer.
> > > 
> > > Besides from the code refactoring, this changes the page flip point
> > > to vsync instead of frame done, which allows working with only
> > > two buffers without losing frames. This is apparently a more
> > > appropriate thing to do with this controller.
> > 
> > Why? What issues were you seeing before, how does using a separate
> > interrupt addresses it, and what makes you think it's more appropriate?
> 
> I'll try to update the commit log to address this, thanks.
> 
> One of the main issues that the rework is trying to address is the way
> that double buffering is handled, which currently requires up to 3 buffers
> to work, due to how buffer configuration is implemented. In particular,
> it's synchronizing to the frame done interrupt which seems to hit after
> scanout of the next frame begins, so page flips are always delayed by one
> frame.
> 
> This is currently solved by setting two buffers when starting the stream:
> the first one is set before vcap is enabled and seems to be sampled when the
> first frame scan begins and the second one is set after and stays until the
> second vsync hits, at which point it becomes the current active buffer.
> This way no frame is lost but 3 frames are needed to start.
> 
> This proposal changes the sync point to vsync which allows page flipping to
> happen for the next frame, thus only 2 buffers are required.

This should be in your commit log

Maxime