linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Marek Vasut <marex@denx.de>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	 linux-media@vger.kernel.org
Cc: Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>,
	Fabio Estevam <festevam@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Helge Deller <deller@gmx.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>,
	 Steve Longerbeam <slongerbeam@gmail.com>,
	dri-devel@lists.freedesktop.org, imx@lists.linux.dev,
	 linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org,  linux-staging@lists.linux.dev
Subject: Re: [PATCH v2 2/2] media: imx: vdic: Introduce mem2mem VDI deinterlacer driver
Date: Tue, 08 Oct 2024 16:23:16 +0200	[thread overview]
Message-ID: <05c5b863f98bb61f67e79e83e05ca341285db205.camel@pengutronix.de> (raw)
In-Reply-To: <0da39b8f-4cca-438f-9a39-40da7c34c895@denx.de>

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


  reply	other threads:[~2024-10-08 14:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24  0:19 [PATCH v2 1/2] gpu: ipu-v3: vdic: Simplify ipu_vdi_setup() Marek Vasut
2024-07-24  0:19 ` [PATCH v2 2/2] media: imx: vdic: Introduce mem2mem VDI deinterlacer driver Marek Vasut
2024-07-24 16:08   ` Nicolas Dufresne
2024-07-29  2:16     ` Marek Vasut
2024-07-30 16:05       ` Nicolas Dufresne
2024-09-24 15:42         ` Marek Vasut
2024-10-15 17:31       ` Nicolas Dufresne
2024-07-24 16:16   ` Dan Carpenter
2024-07-29  2:19     ` Marek Vasut
2024-09-06  9:01   ` Philipp Zabel
2024-09-24 15:28     ` Marek Vasut
2024-09-25 15:07       ` Philipp Zabel
2024-09-25 20:14         ` Marek Vasut
2024-09-26 11:14           ` Philipp Zabel
2024-10-03 15:11             ` Marek Vasut
2024-10-15 17:46       ` Nicolas Dufresne
2024-09-25 17:58   ` Nicolas Dufresne
2024-09-25 20:45     ` Marek Vasut
2024-09-26 11:16       ` Philipp Zabel
2024-10-03 14:57         ` Marek Vasut
2024-10-08 14:23           ` Philipp Zabel [this message]
2024-10-15 18:13           ` Nicolas Dufresne
2024-09-27 19:33       ` Nicolas Dufresne
2024-10-03 17:13         ` Marek Vasut
2024-09-04  9:05 ` [PATCH v2 1/2] gpu: ipu-v3: vdic: Simplify ipu_vdi_setup() Philipp Zabel
2024-09-24 10:47   ` Marek Vasut
2024-09-25 16:43     ` Philipp Zabel
2024-09-25 19:47       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05c5b863f98bb61f67e79e83e05ca341285db205.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=marex@denx.de \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=slongerbeam@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).