media: cedrus: Update TODO with future rework plans

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>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

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.