Message-ID: <5b0ed6dd7190496d70fe625ac9b4539eb0181c0a.camel@mediatek.com>
Date: Mon, 13 May 2024 06:15:01 +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 Fri, 2024-05-10 at 12:14 +0200, AngeloGioacchino Del Regno wrote:
> Il 10/05/24 11:34, CK Hu (胡俊光) ha scritto:
> > On Thu, 2024-05-09 at 11:27 +0200, AngeloGioacchino Del Regno
> > wrote:
> > > Il 09/05/24 07:42, CK Hu (胡俊光) ha scritto:
> > > > On Wed, 2024-05-08 at 15:03 +0200, AngeloGioacchino Del Regno
> > > > wrote:
> > > > > Il 08/05/24 09:19, CK Hu (胡俊光) ha scritto:
> > > > > > On Tue, 2024-05-07 at 16:07 +0200, AngeloGioacchino Del
> > > > > > Regno
> > > > > > wrote:
> > > > > > > Il 07/05/24 08:59, CK Hu (胡俊光) ha scritto:
> > > > > > > > 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.ya
> > > > > > > > > > > ml |
> > > > > > > > > > > 23
> > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > >       1 file changed, 23 insertions(+)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.y
> > > > > > > > > > > aml
> > > > > > > > > > > b/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.y
> > > > > > > > > > > aml
> > > > > > > > > > > index b3c6888c1457..4e9acd966aa5 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.y
> > > > > > > > > > > aml
> > > > > > > > > > > +++
> > > > > > > > > > > b/Documentation/devicetree/bindings/arm/mediatek/
> > > > > > > > > > > medi
> > > > > > > > > > > atek
> > > > > > > > > > > ,mms
> > > > > > > > > > > ys.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,
> > > > > > > > ...>;
> > > > > > > > 
> > > > > > > 
> > > > > > > There's no need to list all of the VDO0/VDO1/mmsys
> > > > > > > devices in
> > > > > > > one
> > > > > > > big
> > > > > > > array
> > > > > > > property, because the actual possible devices can be
> > > > > > > defined:
> > > > > > >       1. In the bindings; and
> > > > > > >       2. In the actual OF graph that we write for each
> > > > > > > SoC+board
> > > > > > > combination.
> > > > > > > 
> > > > > > > A graph cannot contain a connection to a device that
> > > > > > > cannot
> > > > > > > be
> > > > > > > connected to
> > > > > > > the previous, so, your "mmsys-subdev" list can be
> > > > > > > retrieved
> > > > > > > by
> > > > > > > looking at the
> > > > > > > graph:
> > > > > > >      - Start from VDO0/1 or MMSYS
> > > > > > >      - Walk through (visually, even) OUTPUT ports
> > > > > > >        - VDO0 (read output ep) -> ovl0 (read output ep)
> > > > > > > ->
> > > > > > > rdma0
> > > > > > > (read
> > > > > > > output ep) ->
> > > > > > >          color0 (...) -> etc
> > > > > > >      - Nothing more - it's all defined there.
> > > > > > > 
> > > > > > > > 
> > > > > > > > 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?
> > > > > > > 
> > > > > > > There are multiple ways of doing this, but one that comes
> > > > > > > to
> > > > > > > my
> > > > > > > mind
> > > > > > > right now and
> > > > > > > that looks clean as well is the following:
> > > > > > > 
> > > > > > > ovl0@...1 {
> > > > > > >        .....
> > > > > > >       ports {
> > > > > > >         port@0 {
> > > > > > >           reg = <0>;
> > > > > > >           ovl0_in: endpoint {
> > > > > > >             remote-endpoint = <&vdosys0_out>;
> > > > > > >           };
> > > > > > >         };
> > > > > > 
> > > > > > I'm not sure how do you define this port from OVL to
> > > > > > vdosys. If
> > > > > > this
> > > > > > port means 'master relationship', others could add port in
> > > > > > COLOR to
> > > > > > point to vdosys because COLOR and vdosys has the 'master
> > > > > > relationship'
> > > > > > and I could not reject this. So we need more specific
> > > > > > definition of
> > > > > > this port.
> > > > > 
> > > > > 
> > > > > > Only the 'first' device in pipeline could have this port?
> > > > > 
> > > > > Correct. Only the first device in a pipeline - and this is
> > > > > actually a
> > > > > restriction
> > > > > that the generic binding definition of port already gives, in
> > > > > a
> > > > > way.
> > > > > 
> > > > > 
> > > > > > In mt8173, one pipeline is
> > > > > > 
> > > > > > ovl -> color -> aal -> od -> rdma -> ufo -> dsi
> > > > > > 
> > > > > > But rdma has an option to read data from od or directly
> > > > > > from
> > > > > > DRAM.
> > > > > > If
> > > > > > from DRAM, the pipeline would be changed to
> > > > > > 
> > > > > > rdma -> ufo -> dsi
> > > > > > 
> > > > > > 
> > > > > > So it's confused which one is 'first'.
> > > > > 
> > > > > That's why the pipeline is *board-specific* and not soc-
> > > > > generic!
> > > > > 
> > > > > And what you described is *exactly* the reason why I'm adding
> > > > > support
> > > > > for the
> > > > > OF graphs in mediatek-drm: specifying the correct pipeline
> > > > > for
> > > > > each
> > > > > board as per
> > > > > what each board wants to use (said differently: for each
> > > > > board's
> > > > > *capabilities*).
> > > > > 
> > > > > So, if on a certain board you want to skip OD, you can hook
> > > > > RDMA
> > > > > up
> > > > > directly to
> > > > > MMSYS/VDOSYS.
> > > > > 
> > > > > In MT8173, one pipeline for one board uses endpoints IN/OUT
> > > > > like
> > > > > this:
> > > > > 
> > > > > MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
> > > > > 
> > > > > and for another board, endpoints will be like
> > > > > 
> > > > > MMSYS -> RDMA -> UFO -> DSI
> > > > > 
> > > > > ...which is the exact same as you described, and I think that
> > > > > your
> > > > > confusion comes
> > > > > from the fact that you didn't put MMSYS at the beginning of
> > > > > the
> > > > > pipeline :-)
> > > > 
> > > > In one board, both OVL and RDMA could switch dynamically.
> > > > Because
> > > > each
> > > > one could be the first in one board, mmsys point to both ovl
> > > > and
> > > > rdma?
> > > > 
> > > 
> > > No.
> > > 
> > > MMSYS would still point ONLY to OVL, because OVL is the "earliest
> > > point"
> > > of the pipeline that this one board does support.
> > > 
> > > In that case, RDMA being present at a later point in the pipeline
> > > does not
> > > matter and does not prevent us from *temporarily* skipping OVL-
> > > COLOR-
> > > AAL-OD
> > > and going MMSYS->RDMA *directly*.
> > > 
> > > Switching dynamically is a driver duty and will be 100% possible
> > > (as
> > > much
> > > as it is right now) to dynamically switch OVL and RDMA as long as
> > > both are
> > > present in the pipeline.
> > > 
> > > With this exact pipeline:
> > > 
> > > MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
> > > 
> > > the driver _can switch dynamically_ between MMSYS->OVL->...->RDMA 
> > > and
> > > MMSYS->RDMA as the driver itself *is allowed to* temporarily
> > > ignore
> > > part
> > > of the pipeline.
> > > 
> > > Please note that, in case it is needed (trust me on this: it's
> > > not
> > > needed)
> > > a custom property in the endpoint node can always be introduced
> > > later, so
> > > that you can declare a node like
> > > 
> > >            endpoint@0 {
> > >              remote-endpoint = <&ovl0_in>;
> > >              mediatek,short-path = <&rdma0_in>;
> > >            };
> > > 
> > > ...but again, that's never going to be needed, as the driver
> > > already
> > > does
> > > have knowledge of the fact that RDMA is in the pipeline, so it is
> > > possible
> > > to simply do a temporary override in the driver.
> > > 
> > > What the OF Graph support does is to build the same arrays, that
> > > we
> > > currently
> > > have hardcoded in mediatek-drm, by reading from device tree.
> > > 
> > > Nothing else and nothing more - for now.
> > > 
> > > Having the OF Graph support makes us able to also add new dual-
> > > path
> > > support
> > > with more complicated connections than the current ones, without
> > > any
> > > problem
> > > and, in many cases, without even modifying the bindings from what
> > > I
> > > provided
> > > in this series.
> > 
> > OK, please add the information we discussed into binding document
> > to
> > prevent anyone misusing this binding.
> > 
> 
> Sorry CK, but the binding *does* already have this information inside
> - not
> in terms of "phrases", but in terms of restrictions of the binding...
> 
> If you want, though, I can add this information in the description of
> the
> commit that is adding this binding, is that okay for you?

I think what we discuss could be translated to restrictions. This is a
restriction description:

If one component has option to be first component or middle component
of one pipeline, it's treated as middle component not first component.

In mt8195, there are 8 vdo1_rdma. So each one is the first component of
display pipeline. So the maximum display pipe number is not 3, maybe 8
or more.

Regards,
CK


> 
> Thanks,
> Angelo
> 
> > Regards,
> > CK
> > 
> > > 
> > > Cheers,
> > > Angelo
> > > 
> > > > Regards,
> > > > CK
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > In case you need any *temporary override* on any board that
> > > > > defines a
> > > > > pipeline like
> > > > > 
> > > > > MMSYS -> OVL -> COLOR -> AAL -> OD -> RDMA -> UFO -> DSI
> > > > > 
> > > > > so that the pipeline *temporarily* becomes (for power
> > > > > management,
> > > > > or
> > > > > for any other
> > > > > reason) RDMA -> UFO -> DSI .... that's not a concern: the
> > > > > graph
> > > > > is
> > > > > present, and it
> > > > > is used to tell to the driver what is the regular pipeline to
> > > > > use.
> > > > > Eventual temporary overrides can be managed transparently
> > > > > inside
> > > > > of
> > > > > the driver with
> > > > > C code and no changes to the devicetree are required.
> > > > > 
> > > > > 
> > > > > > I don't know how to decide which device could point to
> > > > > > mmsys/vdosys. So
> > > > > > please give a specific definition.
> > > > > > 
> > > > > 
> > > > > Nothing points TO mmsys/vdosys. It is mmsys/vdosys pointing
> > > > > to a
> > > > > device.
> > > > > 
> > > > > So, mmsys/vdosys must point to the *first device in the
> > > > > pipeline*.
> > > > > 
> > > > > Any other doubt?
> > > > > 
> > > > > Cheers,
> > > > > Angelo
> > > > > 
> > > > > > Regards,
> > > > > > CK
> > > > > > 
> > > > > > > 
> > > > > > >         port@1 {
> > > > > > >           reg = <1>;
> > > > > > >           ovl0_out0: endpoint@0 {
> > > > > > >             remote-endpoint = <&rdma0_in>;
> > > > > > >           };
> > > > > > >           ovl0_out1: endpoint@1 {
> > > > > > >             remote-endpoint = <&rdma1_in>;
> > > > > > >           };
> > > > > > >         };
> > > > > > >       };
> > > > > > > };
> > > > > > > 
> > > > > > > rdma0@...4 {
> > > > > > >        .....
> > > > > > >       ports {
> > > > > > >         port@0 {
> > > > > > >           reg = <0>;
> > > > > > >           rdma0_in: endpoint {
> > > > > > >             remote-endpoint = <&ovl0_out0>; /* assuming
> > > > > > > ovl0
> > > > > > > outputs to
> > > > > > > rdma0...*/
> > > > > > >           };
> > > > > > >         };
> > > > > > >         port@1 {
> > > > > > >           reg = <1>;
> > > > > > >           rdma0_out: endpoint@1 {
> > > > > > >             remote-endpoint = <&dsi_dual_intf0_in>;
> > > > > > >           };
> > > > > > >         };
> > > > > > >       };
> > > > > > > };
> > > > > > > 
> > > > > > > 
> > > > > > > rdma1@...8 {
> > > > > > >        .....
> > > > > > >       ports {
> > > > > > >         port@0 {
> > > > > > >           reg = <0>;
> > > > > > >           rdma1_in: endpoint {
> > > > > > >             /* assuming ovl0 outputs to rdma1 as well...
> > > > > > > can
> > > > > > > be
> > > > > > > something else. */
> > > > > > >             remote-endpoint = <&ovl0_out1>;
> > > > > > >           };
> > > > > > >         };
> > > > > > >         port@1 {
> > > > > > >           reg = <1>;
> > > > > > >           rdma1_out: endpoint {
> > > > > > >             remote-endpoint = <&dsi_dual_intf1_in>;
> > > > > > >           };
> > > > > > >         };
> > > > > > >       };
> > > > > > > };
> > > > > > > 
> > > > > > > 
> > > > > > > dsi@...cd {
> > > > > > >        .....
> > > > > > >       ports {
> > > > > > >         port@0 {
> > > > > > >           reg = <0>;
> > > > > > >           /* Where endpoint@0 could be always DSI LEFT
> > > > > > > CTRL */
> > > > > > >           dsi_dual_intf0_in: endpoint@0 {
> > > > > > >             remote-endpoint = <&rdma0_out>;
> > > > > > >           };
> > > > > > >           /* ...and @1 could be always DSI RIGHT CTRL */
> > > > > > >           dsi_dual_intf1_in: endpoint@1 {
> > > > > > >             remote-endpoint = <&rdma1_out>;
> > > > > > >           };
> > > > > > >         };
> > > > > > > 
> > > > > > >         port@1 {
> > > > > > >           reg = <1>;
> > > > > > >           dsi0_out: endpoint {
> > > > > > >             remote-endpoint = <&dsi_panel_in>;
> > > > > > >           };
> > > > > > >         };
> > > > > > >       };
> > > > > > > };
> > > > > > > 
> > > > > > > ...for a dual-dsi panel, it'd be a similar graph.
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > Angelo
> > > > > > > 
> > > > > > > > 
> > > > > > > > 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
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> > > 
> 
> 

Powered by blists - more mailing lists