Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
Il 10/04/24 21:03, Rob Herring ha scritto:
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Signed-off-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,aal.yaml| 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml| 25 +++-
.../display/mediatek/mediatek,dsc.yaml| 24 +++
.../display/mediatek/mediatek,dsi.yaml| 27 -
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 +
.../display/mediatek/mediatek,merge.yaml | 23 +++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml| 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index b4c28e96dd55..623cf7e37fe3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -61,6 +61,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: AAL input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -88,5 +109,24 @@ examples:
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = < SUBSYS_1401 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
};
};
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..71ea277a5d8e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -54,6 +54,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: CCORR input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
Il 09/04/24 17:45, Dmitry Baryshkov ha scritto: On Tue, 9 Apr 2024 at 18:41, AngeloGioacchino Del Regno wrote: Il 09/04/24 17:20, Dmitry Baryshkov ha scritto: On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote: The display IPs in MediaTek SoCs support being interconnected with different instances of DDP IPs (for example, merge0 or merge1) and/or with different DDP IPs (for example, rdma can be connected with either color, dpi, dsi, merge, etc), forming a full Display Data Path that ends with an actual display. The final display pipeline is effectively board specific, as it does depend on the display that is attached to it, and eventually on the sensors supported by the board (for example, Adaptive Ambient Light would need an Ambient Light Sensor, otherwise it's pointless!), other than the output type. With the color and gamma being in play, should the configuration be board-driver or rather use-case driven with the driver being able to reroute some of the blocks at runtime? The driver can already set some blocks to "BYPASS MODE" at runtime, meaning that those will work as simple pass-through, performing *no* processing at all, so that's addressed from the very beginning. This doesn't mean that a specific pipeline must always support the "DISP_GAMMA" or the "DISP_CCOLOR" block(s) alone, or together, or in combination with another specific block. I was thinking about slightly different case: do you have enough colour blocks to drive all outputs or do you have to select them for the particular output only? Sorry for the very very very very .. very late reply, your email slipped through the cracks and I just noticed it. That depends on the SoC, but generally... no, you have to select them for the particular output. There is a restricted set of outputs that support this block, but between this set, there are still not enough blocks for all of them. (excuse me, I didn't check the platform details). You (and me, and everyone else) can't really invest hours of time to check on how each and every SoC on the planet works - that's normal. No worries ;-) Cheers, Angelo For any other question, clarification, etc, I'm here :-) Cheers! Add support for OF graphs to most of the MediaTek DDP (display) bindings to add flexibility to build custom hardware paths, hence enabling board specific configuration of the display pipeline and allowing to finally migrate away from using hardcoded paths. Signed-off-by: AngeloGioacchino Del Regno
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
>
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
>
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,aal.yaml| 40 +++
> .../display/mediatek/mediatek,ccorr.yaml | 21 ++
> .../display/mediatek/mediatek,color.yaml | 22 ++
> .../display/mediatek/mediatek,dither.yaml | 22 ++
> .../display/mediatek/mediatek,dpi.yaml| 25 +++-
> .../display/mediatek/mediatek,dsc.yaml| 24 +++
> .../display/mediatek/mediatek,dsi.yaml| 27 -
> .../display/mediatek/mediatek,ethdr.yaml | 22 ++
> .../display/mediatek/mediatek,gamma.yaml | 19 +
> .../display/mediatek/mediatek,merge.yaml | 23 +++
> .../display/mediatek/mediatek,od.yaml | 22 ++
> .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
> .../display/mediatek/mediatek,ovl.yaml| 22 ++
> .../display/mediatek/mediatek,postmask.yaml | 21 ++
> .../display/mediatek/mediatek,rdma.yaml | 22 ++
> .../display/mediatek/mediatek,ufoe.yaml | 21 ++
> 16 files changed, 372 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index b4c28e96dd55..623cf7e37fe3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -61,6 +61,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: AAL input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + AAL output to the next component's input, for example could be one
> + of many gamma, overdrive or other blocks.
> +
> +required:
> + - port@0
> + - port@1
> +
> required:
>- compatible
>- reg
> @@ -88,5 +109,24 @@ examples:
> power-domains = < MT8173_POWER_DOMAIN_MM>;
> clocks = < CLK_MM_DISP_AAL>;
> mediatek,gce-client-reg = < SUBSYS_1401 0x5000 0x1000>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + aal0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + aal0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> };
> };
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index 8c2a737237f2..71ea277a5d8e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -54,6 +54,27 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> maxItems: 1
>
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description:
> + Input and output ports can have multiple endpoints, each of those
> + connects to either the primary, secondary, etc, display pipeline.
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: CCORR input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
>
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
On Tue, 9 Apr 2024 at 18:41, AngeloGioacchino Del Regno wrote: > > Il 09/04/24 17:20, Dmitry Baryshkov ha scritto: > > On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote: > >> The display IPs in MediaTek SoCs support being interconnected with > >> different instances of DDP IPs (for example, merge0 or merge1) and/or > >> with different DDP IPs (for example, rdma can be connected with either > >> color, dpi, dsi, merge, etc), forming a full Display Data Path that > >> ends with an actual display. > >> > >> The final display pipeline is effectively board specific, as it does > >> depend on the display that is attached to it, and eventually on the > >> sensors supported by the board (for example, Adaptive Ambient Light > >> would need an Ambient Light Sensor, otherwise it's pointless!), other > >> than the output type. > > > > With the color and gamma being in play, should the configuration be > > board-driver or rather use-case driven with the driver being able to > > reroute some of the blocks at runtime? > > > > The driver can already set some blocks to "BYPASS MODE" at runtime, meaning > that those will work as simple pass-through, performing *no* processing at > all, so that's addressed from the very beginning. > > This doesn't mean that a specific pipeline must always support the > "DISP_GAMMA" > or the "DISP_CCOLOR" block(s) alone, or together, or in combination with > another > specific block. I was thinking about slightly different case: do you have enough colour blocks to drive all outputs or do you have to select them for the particular output only? (excuse me, I didn't check the platform details). > For any other question, clarification, etc, I'm here :-) > > Cheers! > > >> > >> Add support for OF graphs to most of the MediaTek DDP (display) bindings > >> to add flexibility to build custom hardware paths, hence enabling board > >> specific configuration of the display pipeline and allowing to finally > >> migrate away from using hardcoded paths. > >> > >> Signed-off-by: AngeloGioacchino Del Regno > >> > > > -- With best wishes Dmitry
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
Il 09/04/24 17:20, Dmitry Baryshkov ha scritto: On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote: The display IPs in MediaTek SoCs support being interconnected with different instances of DDP IPs (for example, merge0 or merge1) and/or with different DDP IPs (for example, rdma can be connected with either color, dpi, dsi, merge, etc), forming a full Display Data Path that ends with an actual display. The final display pipeline is effectively board specific, as it does depend on the display that is attached to it, and eventually on the sensors supported by the board (for example, Adaptive Ambient Light would need an Ambient Light Sensor, otherwise it's pointless!), other than the output type. With the color and gamma being in play, should the configuration be board-driver or rather use-case driven with the driver being able to reroute some of the blocks at runtime? The driver can already set some blocks to "BYPASS MODE" at runtime, meaning that those will work as simple pass-through, performing *no* processing at all, so that's addressed from the very beginning. This doesn't mean that a specific pipeline must always support the "DISP_GAMMA" or the "DISP_CCOLOR" block(s) alone, or together, or in combination with another specific block. For any other question, clarification, etc, I'm here :-) Cheers! Add support for OF graphs to most of the MediaTek DDP (display) bindings to add flexibility to build custom hardware paths, hence enabling board specific configuration of the display pipeline and allowing to finally migrate away from using hardcoded paths. Signed-off-by: AngeloGioacchino Del Regno
Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote: > The display IPs in MediaTek SoCs support being interconnected with > different instances of DDP IPs (for example, merge0 or merge1) and/or > with different DDP IPs (for example, rdma can be connected with either > color, dpi, dsi, merge, etc), forming a full Display Data Path that > ends with an actual display. > > The final display pipeline is effectively board specific, as it does > depend on the display that is attached to it, and eventually on the > sensors supported by the board (for example, Adaptive Ambient Light > would need an Ambient Light Sensor, otherwise it's pointless!), other > than the output type. With the color and gamma being in play, should the configuration be board-driver or rather use-case driven with the driver being able to reroute some of the blocks at runtime? > > Add support for OF graphs to most of the MediaTek DDP (display) bindings > to add flexibility to build custom hardware paths, hence enabling board > specific configuration of the display pipeline and allowing to finally > migrate away from using hardcoded paths. > > Signed-off-by: AngeloGioacchino Del Regno > -- With best wishes Dmitry
