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
Attachment:
signature.asc
Description: PGP signature
