On Do, 2024-10-03 at 16:57 +0200, Marek Vasut wrote: > On 9/26/24 1:16 PM, Philipp Zabel wrote: > > On Mi, 2024-09-25 at 22:45 +0200, Marek Vasut wrote: > > [...] > > > > The driver is not taking ownership of prev_buf, only curr_buf is > > > > guaranteed to > > > > exist until v4l2_m2m_job_finish() is called. Usespace could streamoff, > > > > allocate > > > > new buffers, and then an old freed buffer may endup being used. > > > > > > So, what should I do about this ? Is there some way to ref the buffer to > > > keep it around ? > > > > Have a look how other deinterlacers with temporal filtering do it. > > sunxi/sun8i-di or ti/vpe look like candidates. > I don't see exactly what those drivers are doing differently to protect > the prev buffer during deinterlacing . Can you be more specific ?
In the EOF interrupt you are calling v4l2_m2m_buf_done() on src_buf, which should be the same as ctx->curr_buf in the previous device_run. Instead, you could release ctx->prev_buf and then store src_buf into ctx->prev_buf. Storing curr_buf on the ctx doesn't seem to be necessary at all. The mentioned deinterlacer drivers do something similar [1][2]. [1] https://elixir.bootlin.com/linux/master/source/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c#L236 [2] https://elixir.bootlin.com/linux/master/source/drivers/media/platform/ti/vpe/vpe.c#L1481 regards Philipp
