From: Marek Vasut <marex@denx.de>
To: 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>,
Philipp Zabel <p.zabel@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: Mon, 29 Jul 2024 04:16:46 +0200 [thread overview]
Message-ID: <8aea6cc0-10bf-48b8-add9-eb3f1caa2d66@denx.de> (raw)
In-Reply-To: <5e5fba4fd6c3c0c9df23697bd328367e5fdfa923.camel@ndufresne.ca>
On 7/24/24 6:08 PM, Nicolas Dufresne wrote:
> Hi Marek,
Hi,
> Le mercredi 24 juillet 2024 à 02:19 +0200, Marek Vasut a écrit :
>> Introduce dedicated memory-to-memory IPUv3 VDI deinterlacer driver.
>> Currently the IPUv3 can operate VDI in DIRECT mode, from sensor to
>> memory. This only works for single stream, that is, one input from
>> one camera is deinterlaced on the fly with a helper buffer in DRAM
>> and the result is written into memory.
>>
>> The i.MX6Q/QP does support up to four analog cameras via two IPUv3
>> instances, each containing one VDI deinterlacer block. In order to
>> deinterlace all four streams from all four analog cameras live, it
>> is necessary to operate VDI in INDIRECT mode, where the interlaced
>> streams are written to buffers in memory, and then deinterlaced in
>> memory using VDI in INDIRECT memory-to-memory mode.
>
> Just a quick design question. Is it possible to chain the deinterlacer and the
> csc-scaler ?
I think you could do that.
> If so, it would be much more efficient if all this could be
> combined into the existing m2m driver, since you could save a memory rountrip
> when needing to deinterlace, change the colorspace and possibly scale too.
The existing PRP/IC driver is similar to what this driver does, yes, but
it uses a different DMA path , I believe it is IDMAC->PRP->IC->IDMAC .
This driver uses IDMAC->VDI->IC->IDMAC . I am not convinced mixing the
two paths into a single driver would be beneficial, but I am reasonably
sure it would be very convoluted. Instead, this driver could be extended
to do deinterlacing and scaling using the IC if that was needed. I think
that would be the cleaner approach.
next prev parent reply other threads:[~2024-07-29 2:22 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 [this message]
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
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=8aea6cc0-10bf-48b8-add9-eb3f1caa2d66@denx.de \
--to=marex@denx.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=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=p.zabel@pengutronix.de \
--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).