Re: RFC: cedrus: time to more to mainline?

From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: "Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Jernej Škrabec" <jernej.skrabec@gmail.com>
Subject: Re: RFC: cedrus: time to more to mainline?
Date: Tue, 7 Nov 2023 15:25:27 +0100	[thread overview]
Message-ID: <ZUpI151wvt455TcF@aptenodytes> (raw)
In-Reply-To: <c7accc1c-57a8-4722-a4f7-2278eb035429@xs4all.nl>

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

Hi Hans,

On Tue 07 Nov 23, 14:54, Hans Verkuil wrote:
> Looking at the cedrus TODO:
> 
> Before this stateless decoder driver can leave the staging area:
> * The Request API needs to be stabilized;
> * The codec-specific controls need to be thoroughly reviewed to ensure they
>   cover all intended uses cases;
> * Userspace support for the Request API needs to be reviewed;
> * Another stateless decoder driver should be submitted;
> * At least one stateless encoder driver should be submitted.
> 
> I would say that all items are done, except for the last item.
> 
> But this is a decoder driver, so I'm not sure why the TODO would mention
> something about encoders.

I agree. This didn't prevent the hantro driver form being unstaged anyway.

> Anything else that needs to be done before it can be moved out of staging?

I'm actually working on a big rework of the driver, because its architecture
is vastly sub-optimal and overall very messy. This is in particular needed for
the work to support H.264 encoding.

The plan for now is to publish this work in a downstream repository (at Bootlin)
since we don't yet have a uAPI for encoding. The rework is also not split into
nice transition commits but it's instead a big all-in-one commit for the moment.

However I would like to see this rework hit mainline after the publication of
the encoding work, because it's a much needed cleanup for the decode side too.
I will of course split it into nice commits at that point.

So I'm not sure whether this conflicts with unstaging or not. It could make
sense to wait until the rework is achieved to unstage, but I would also be fine
with unstaging first. It would just make me slightly happier to bring big
changes to a staging driver instead of a fully-merged one.

What do you think?

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]