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.

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com