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

[Paul Kocialkowski]

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@xxxxxxxxxxx>
---
 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.
-- 
2.42.0