Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
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.delre...@collabora.com> --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 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_mt_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 = <, , , ...>, <, , , ...>; 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
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
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.delre...@collabora.com> --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml b/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml index b3c6888c1457..4e9acd966aa5 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek ,mms ys.y aml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek ,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_mt_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 = <, , , ...>, <, , , ...>; 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)
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
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.delre...@collabora.com> --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms ys.y aml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms ys.y aml index b3c6888c1457..4e9acd966aa5 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mms ys.y aml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,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_mt_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 = <, , , ...>, <, , , ...>; 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.
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
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.delre...@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_mt_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 = <, , , ...>, <, , , ...>; 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
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
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.delre...@collabora.com> --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index b3c6888c1457..4e9acd966aa5 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -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_mt_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. 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. Cheers, Angelo Regards, CK required: - compatible - reg
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Il 10/04/24 21:15, Rob Herring ha scritto: On Tue, Apr 09, 2024 at 02:02:10PM +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 --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index b3c6888c1457..4e9acd966aa5 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -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. I'm have a hard time understanding this, but is it 3 outputs simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports for the former and endpoints for the latter. Yes I feel you, MediaTek SoCs are a bit strange, but I do have a reason to use one port and multiple endpoints, instead of multiple ports and one endpoint. On MediaTek SoCs, there are multiple ports: those multiple ports are represented by multiple MMSYS or multiple VDOSYS (depending on the SoC), which do then have multiple endpoints. However, the multiple ports, at least for now, are represented by multiple MMSYS and/or multiple VDOSYS nodes instead of one MM/VDO node with multiple iostart for the multiple blocks in `reg`. The multiple iostart "thing" was the initial design by MediaTek, but there was no way to get them really connected the right way unless adding an iostart restriction in the driver itself (so that the mmsys driver would check an iostart to probe the mediatek-drm components for the right IP number), so, after quite many reviews and many series versions, they had to resort to use multiple nodes for each VDO. I think that, after this series, we could also clean that mess up (sorry for the strong words) and make it right - assigning the MMIO for all VDOSYS blocks to one node, and adding the multiple ports - however, that will require a bit of work that is simply too much for this series alone. Summarizing, so that you don't have to carefully proof-read all this wall of text: - MediaTek SoCs have got multiple `port` for MMSYS and VDOSYS - Currently the driver implementation doesn't allow that - MediaTek had to work around no OF graph support! - Multiple ports are the multiple MMSYS/VDOSYS - One MMSYS / One VDOSYS have multiple `endpoints` That's how the HW is. Hope that's clear now? Cheers, Angelo +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 + required: - compatible - reg -- 2.44.0
Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:10PM +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 > > --- > .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > index b3c6888c1457..4e9acd966aa5 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > @@ -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. I'm have a hard time understanding this, but is it 3 outputs simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports for the former and endpoints for the latter. > +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 > + > required: >- compatible >- reg > -- > 2.44.0 >
[PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
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 --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index b3c6888c1457..4e9acd966aa5 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -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 + required: - compatible - reg -- 2.44.0
