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