[PATCH v2 32/66] media: sun6i-csi: Add capture state using vsync for page flip

Paul Kocialkowski paul.kocialkowski at bootlin.com
Fri Feb 11 07:40:55 PST 2022


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220211/b03261dc/attachment.sig>


More information about the linux-arm-kernel mailing list