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:
signature.asc
Description: PGP signature
