[PATCH v2 2/2] media: imx: vdic: Introduce mem2mem VDI deinterlacer driver
Philipp Zabel
p.zabel at pengutronix.de
Tue Oct 8 07:23:16 PDT 2024
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
More information about the linux-arm-kernel
mailing list