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

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

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
>>
>>