Re: [PATCH] media: cedrus: Update TODO with future rework plans

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Le mardi 07 novembre 2023 à 21:06 +0100, Paul Kocialkowski a écrit :
> The current TODO list of the cedrus driver is now outdated as most of the points
> it mentions were already tackled. In addition it is no longer considered
> relevant to wait for a stateless encoder driver to move it out of staging.
> The hantro/verisilicon driver was already unstaged without this condition.
> 
> However the driver suffers from a bad initial design that showed to be very
> limiting. It was also not a very good fit for a video codec driver either.
> 
> Since a rework of the driver was already carried out for the purpose of adding
> encoding support, update the TODO list with a description of the rework.
> This reworked driver will be published soon and transitional commits from the
> current driver will be submitted upstreamer after that.
> 
> It seems best to wait for the rework to land upstream before unstaging the
> driver, since a major rework is best operated on a staging driver instead of a
> fully upstream one.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>

> ---
>  drivers/staging/media/sunxi/cedrus/TODO | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/TODO b/drivers/staging/media/sunxi/cedrus/TODO
> index ec277ece47af..00aa304a7e36 100644
> --- a/drivers/staging/media/sunxi/cedrus/TODO
> +++ b/drivers/staging/media/sunxi/cedrus/TODO
> @@ -1,7 +1,16 @@
> -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.
> +This driver suffers from a bad initial design that results in various aspects
> +being intricated, making it difficult to scale to new codecs and to add encoding
> +support in the future.
> +
> +Before leaving the staging area, it should be reworked to clearly distinguish
> +between different aspects:
> +- platform, with resources management, interrupt handler, watchdog,
> +  v4l2 and m2m devices registration;
> +- proc, with video device registration and related operations;
> +- context, with m2m context, queue and controls management;
> +- engine, with each individual codec job execution and codec-specific
> +  operation callbacks;
> +
> +This will make it possible to register two different procs (decoder and
> +encoder) while sharing significant common infrastructure, common v4l2 and m2m
> +devices but exposing distinct video devices.