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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 7 Nov 2022 06:35:30 +0000
From:   Moudy Ho (何宗原) <Moudy.Ho@...iatek.com>
To:     "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "hverkuil-cisco@...all.nl" <hverkuil-cisco@...all.nl>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>
Subject: Re: [PATCH v3 10/10] media: platform: mtk-mdp3: decompose
 hardware-related information in shared memory

On Thu, 2022-11-03 at 11:02 +0100, AngeloGioacchino Del Regno wrote:
> 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@...iatek.com>
> 
> 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

Hi Angelo,

Thank you for your time and patience in this matter.
As you said, the first 8195 settings related to this series will be
completed and released as soon as possible for review.
Also, the typo you pointed out(thanks a lot) will be corrected in the
next release.

Sincerely,
Moudy Ho