Re: [PATCH v3 10/10] media: platform: mtk-mdp3: decompose hardware-related information in shared memory

From: AngeloGioacchino Del Regno
Date: Thu Nov 03 2022 - 06:02:37 EST


Il 03/11/22 07:48, Moudy Ho ha scritto:
The communication between the MDP3 kernel driver and SCP is to
pass a shared memory through the cooperation of "mtk-mdp3-vpu.c" and
remoteproc driver.
The data structure of this shared memory is defined in "mtk-img-ipi.h",
as shown below:

vpu->work_addr -> +-----------------------------------------+
| |
| To SCP : Input frame parameters |
| (struct img_ipi_frameparam) |
| |
vpu->pool -> +-----------------------------------------+
| |
| From SCP : Output component config pool |
| (struct img_config) |
| |
| *struct img_confg 1 |
| | |
| | |
| v |
| *struct img_config N |
| (N = MDP_CONFIG_POOL_SIZE) |
+-----------------------------------------+

One output component configuration contains the components
currently used by the pipeline, and has the register settings
that each component needs to set.

Since the quantity, type and function of components on each chip
will vary, the effect is that the size of the "struct img_config"
and its substructures will be different on each chip.
In addition, all chips will have to update their SCP firmware for
every change if the output component config structure is defined
and shared by a common header.

Therefore, all functions that operate on "struct img_config" and
its substructures must be separated by chips and so are the
relevant definations.

Signed-off-by: Moudy Ho <moudy.ho@xxxxxxxxxxxx>

Hi Moudy,
thanks for this much needed rework of the IMG-IPI parameter passing architecture!

I can for sure go for a review of the code that you've currently pushed, but I
would prefer that you also push support for MT8192 and/or MT8195 (requiring the
different IPI structures and alignment), as previously discussed.

That will make us able to actually perform validation and will make us able to
give you a better code review.

Since this series is definitely big (hence, a bit difficult to review, but that's
fine, as there are no alternatives!), you can push support for the new chip(s) in
a separate series, dependent on this one, so that we also won't block this rework
for SoC-specific implementation code reviews.

Many thanks again!

P.S.: There's a typo in this commit message `*struct img_confg` :-)

Cheers,
Angelo