[PATCH v4 3/9] media: chips-media: wave6: Add Wave6 VPU interface

[Nas Chung]

Hi, Nicolas.

Sorry, I just realized that I never replied to your earlier email.

>-----Original Message-----
>From: Nicolas Dufresne <nicolas at ndufresne.ca>
>Sent: Thursday, December 11, 2025 4:54 AM
>To: Nas Chung <nas.chung at chipsnmedia.com>; mchehab at kernel.org;
>hverkuil at xs4all.nl; robh at kernel.org; krzk+dt at kernel.org;
>conor+dt at kernel.org; shawnguo at kernel.org; s.hauer at pengutronix.de
>Cc: linux-media at vger.kernel.org; devicetree at vger.kernel.org; linux-
>kernel at vger.kernel.org; linux-imx at nxp.com; linux-arm-
>kernel at lists.infradead.org; jackson.lee <jackson.lee at chipsnmedia.com>;
>lafley.kim <lafley.kim at chipsnmedia.com>; marek.vasut at mailbox.org; Ming Qian
><ming.qian at oss.nxp.com>
>Subject: Re: [PATCH v4 3/9] media: chips-media: wave6: Add Wave6 VPU
>interface
>
>Hi,
>
>Le mercredi 22 octobre 2025 à 16:47 +0900, Nas Chung a écrit :
>> Add an interface layer to manage hardware register configuration
>> and communication with the Chips&Media Wave6 video codec IP.
>>
>> The interface provides low-level helper functions used by the
>> Wave6 core driver to implement video encoding and decoding operations.
>> It handles command submission to the firmware via MMIO registers,
>> and waits for a response by polling the firmware busy flag.
>>
>> Signed-off-by: Nas Chung <nas.chung at chipsnmedia.com>
>> Tested-by: Ming Qian <ming.qian at oss.nxp.com>
>> Tested-by: Marek Vasut <marek.vasut at mailbox.org>
>> ---

[...]

>
>[...]
>
>stopping there for now. I feel like we did a big mistake in wave5 by
>allowing a
>heavy abstraction, its a lot harder to fix and it served no purpose since
>you
>went for a fresh driver for wave6. I think its proper to ask for a slimmer
>interface.
>
>The V4L2 API is the front-end, and where all the validation should take
>place.
>The HW interface should simply manage the HW in a readable and non-
>redundant
>way. In V4L2, strides and buffer size are part of the try/s/g_fmt API, so
>these
>should not be duplicated here and they should clearly use the common code.

I agree that the HW interface should be slimmer and should not duplicate
validation handled in the V4L2 layer.

>
>I know its painful to ear, but you will be remove 50% of the code, which
>long
>term will be a massive win on maintenance.

I am reworking the series to address your earlier feedback as well, and I will
include that in the next patch version.

Thanks again for your feedback.

Thanks.
Nas.

>
>regards,
>Nicolas