RFC: cedrus: time to more to mainline?

RFC: cedrus: time to more to mainline?

[Hans Verkuil]

Hi all,

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.

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

Regards,

	Hans

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

[Paul Kocialkowski]

[-- 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 --]

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

[Hans Verkuil]

On 07/11/2023 15:25, Paul Kocialkowski wrote:
> 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?

Fine with me, but I would appreciate it if you can post a patch updating the TODO
file. That's really out of date, and you can mention the rework you are doing.

Regards,

	Hans

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

[Paul Kocialkowski]

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

Hans,

On Tue 07 Nov 23, 16:00, Hans Verkuil wrote:
> On 07/11/2023 15:25, Paul Kocialkowski wrote:
> > 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?
> 
> Fine with me, but I would appreciate it if you can post a patch updating the TODO
> file. That's really out of date, and you can mention the rework you are doing.

Great, I've just sent out a patch which replaces the current TODO with a
description of the rework.

Thanks,

Paul

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

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