Messages in this thread | | | Date | Tue, 7 May 2024 16:07:05 +0200 | Subject | Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path | From | AngeloGioacchino Del Regno <> |
| |
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@collabora.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, > ...>; >
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@ef01 { ..... ports { port@0 { reg = <0>; ovl0_in: endpoint { remote-endpoint = <&vdosys0_out>; }; };
port@1 { reg = <1>; ovl0_out0: endpoint@0 { remote-endpoint = <&rdma0_in>; }; ovl0_out1: endpoint@1 { remote-endpoint = <&rdma1_in>; }; }; }; };
rdma0@1234 { ..... 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@5678 { ..... 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@9abcd { ..... 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 >> >>
| |