linux-kernel - Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path

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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4dfb09b9c437ab2baa0898eca13a43fd7475047a.camel@mediatek.com>
Date: Tue, 7 May 2024 06:59:02 +0000
From: CK Hu (胡俊光) <ck.hu@...iatek.com>
To: "angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>, "chunkuang.hu@...nel.org"
	<chunkuang.hu@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"wenst@...omium.org" <wenst@...omium.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "tzimmermann@...e.de" <tzimmermann@...e.de>,
	Shawn Sung (宋孝謙) <Shawn.Sung@...iatek.com>,
	"mripard@...nel.org" <mripard@...nel.org>,
	Jitao Shi (石记涛) <jitao.shi@...iatek.com>,
	"daniel@...ll.ch" <daniel@...ll.ch>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"robh@...nel.org" <robh@...nel.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "airlied@...il.com" <airlied@...il.com>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"kernel@...labora.com" <kernel@...labora.com>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, Yu-chang Lee (李禹璋)
	<Yu-chang.Lee@...iatek.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph
 support for board path

On Thu, 2024-05-02 at 10:50 +0200, AngeloGioacchino Del Regno wrote:
> Il 25/04/24 04:23, CK Hu (胡俊光) ha scritto:
> > Hi, Angelo:
> > 
> > On Tue, 2024-04-09 at 14:02 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP
> > > paths
> > > per HW instance (so potentially up to six displays for multi-vdo
> > > SoCs).
> > > 
> > > The MMSYS or VDOSYS is always the first component in the DDP
> > > pipeline,
> > > so it only supports an output port with multiple endpoints -
> > > where
> > > each
> > > endpoint defines the starting point for one of the (currently
> > > three)
> > > possible hardware paths.
> > > 
> > > Signed-off-by: AngeloGioacchino Del Regno <
> > > angelogioacchino.delregno@...labora.com>
> > > ---
> > >   .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23
> > > +++++++++++++++++++
> > >   1 file changed, 23 insertions(+)
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
> > > aml
> > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
> > > aml
> > > index b3c6888c1457..4e9acd966aa5 100644
> > > ---
> > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
> > > aml
> > > +++
> > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.y
> > > aml
> > > @@ -93,6 +93,29 @@ properties:
> > >     '#reset-cells':
> > >       const: 1
> > >   
> > > +  port:
> > > +    $ref: /schemas/graph.yaml#/properties/port
> > > +    description:
> > > +      Output port node. This port connects the MMSYS/VDOSYS
> > > output
> > > to
> > > +      the first component of one display pipeline, for example
> > > one
> > > of
> > > +      the available OVL or RDMA blocks.
> > > +      Some MediaTek SoCs support up to three display outputs per
> > > MMSYS.
> > > +    properties:
> > > +      endpoint@0:
> > > +        $ref: /schemas/graph.yaml#/properties/endpoint
> > > +        description: Output to the primary display pipeline
> > > +
> > > +      endpoint@1:
> > > +        $ref: /schemas/graph.yaml#/properties/endpoint
> > > +        description: Output to the secondary display pipeline
> > > +
> > > +      endpoint@2:
> > > +        $ref: /schemas/graph.yaml#/properties/endpoint
> > > +        description: Output to the tertiary display pipeline
> > > +
> > > +    required:
> > > +      - endpoint@0
> > > +
> > 
> > mmsys/vdosys does not output data to the first component of display
> > pipeline, so this connection looks 'virtual'. Shall we add
> > something
> > virtual in device tree? You add this in order to decide which
> > pipeline
> > is 1st, 2nd, 3rd, but for device it don't care which one is first.
> > In
> > computer, software could change which display is the primary
> > display.
> > I'm not sure it's good to decide display order in device tree?
> > 
> 
> Devicetree describes hardware, so nothing virtual can be present -
> and in any case,
> the primary/secondary/tertiary pipeline is in relation to MM/VDO SYS,
> not referred
> to software.
> 
> Better explaining, the primary pipeline is not necessarily the
> primary display in
> DRM terms: that's a concept that is completely detached from the
> scope of this
> series and this graph - and it's something that shall be managed
> solely by the
> driver (mediatek-drm in this case).
> 
> Coming back to the connection looking, but *not* being virtual: the
> sense here is
> that the MM/VDOSYS blocks are used in the display pipeline to
> "stitch" together
> the various display pipeline hardware blocks, or, said differently,
> setting up the
> routing between all of those (P.S.: mmsys_mtxxxx_routing_table!)
> through the VDO
> Input Selection (VDOx_SEL_IN) or Output Selection (VDOx_SEL_OUT) and
> with the
> assistance of the VDO Multiple Output Mask (VDOx_MOUT) for the
> multiple outputs
> usecase, both of which, are described by this graph.

I agree this part, but this is related to display device OF graph.
These display device would output video data from one device and input
to another video device. These video device would not input or output
video data to mmsys/vdosys.

> 
> This means that the VDOSYS is really the "master" of the display
> pipeline since
> everything gets enabled, mixed and matched from there - and that's in
> the sense
> of hardware operation, so we are *really* (and not virtually!)
> flipping switches.

I agree mmsys/vdosys is master of video pipeline, so let's define what
the port in mmsys/vdosys is. If the port means the master relationship,
mmsys/vdosys should output port to every display device. Or use a
simply way to show the master relation ship

mmsys-subdev = <&ovl0, &rdma0, &color0, ...>, <&ovl1, &rdma1, &color1,
...>;


Another problem is how to group display device? If two pipeline could
be route to the same display interface, such as

rdma0 -> dsi
rdma1 -> dsi

Would this be single group?

mmsys-subdev = <&rdma0, &rdma1, &dsi>;

Or two group?

mmsys-subdev = <&rdma0, &dsi>, <&rdma1, &dsi>;

I think we should clearly define this.

Regards,
CK

> 
> 
> Cheers,
> Angelo
> 
> > Regards,
> > CK
> > 
> > 
> > >   required:
> > >     - compatible
> > >     - reg
> 
>