[PATCH 0/9] arm64: renesas: enable HDMI Display/Sound on R-Car M3-W+ Salvator-XS

[PATCH 0/9] arm64: renesas: enable HDMI Display/Sound on R-Car M3-W+ Salvator-XS

[Kuninori Morimoto]

Hi Geert, Laurent

These patches enables HDMI Display/Sound for R8A77961.
These are tested on R-Car M3-W+ Salvator-XS board.

Kuninori Morimoto (9):
  dt-bindings: display: renesas: du: Document the r8a77961 bindings
  dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
  drm: rcar-du: Add r8a77961 support
  arm64: dts: renesas: r8a77961: Add FCP device nodes
  arm64: dts: renesas: r8a77961: Add VSP device nodes
  arm64: dts: renesas: r8a77961: Add DU device nodes
  arm64: dts: renesas: r8a77961: Add HDMI device nodes
  arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support
  arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support

 .../display/bridge/renesas,dw-hdmi.txt        |   1 +
 .../bindings/display/renesas,du.txt           |   1 +
 .../boot/dts/renesas/r8a77961-salvator-xs.dts |  57 ++++++++
 arch/arm64/boot/dts/renesas/r8a77961.dtsi     | 132 +++++++++++++++++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c         |   1 +
 5 files changed, 190 insertions(+), 2 deletions(-)

-- 
2.25.1

[PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 Documentation/devicetree/bindings/display/renesas,du.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt
index 51cd4d162770..9e0c473cc4c0 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -18,6 +18,7 @@ Required Properties:
     - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
     - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
     - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
+    - "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU
     - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
     - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
     - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
-- 
2.25.1

Re: [PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings

[Geert Uytterhoeven]

Hi Morimoto-san,

On Mon, Sep 7, 2020 at 4:58 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -18,6 +18,7 @@ Required Properties:
>      - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>      - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>      - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +    - "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU
>      - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
>      - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
>      - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU

Looks good to me, but please also add an entry to the table below
describing the port mappings.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings

[Kuninori Morimoto]

Hi Geert

> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> > @@ -18,6 +18,7 @@ Required Properties:
> >      - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
> >      - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
> >      - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> > +    - "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU
> >      - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
> >      - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> >      - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
> 
> Looks good to me, but please also add an entry to the table below
> describing the port mappings.

Oops indeed.
Thank you for pointing it, I didn't noticed about it.
Will do in v2


Thank you for your help !!

Best regards
---
Kuninori Morimoto

[PATCH 2/9] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds R-Car M3-W+ (R8A77961) SoC bindings.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt       | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
index 819f3e31013c..6b2aa000b204 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -16,6 +16,7 @@ Required properties:
   - "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX
   - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
   - "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX
+  - "renesas,r8a77961-hdmi" for R8A77961 (R-Car M3-W+) compatible HDMI TX
   - "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX
   - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible
 			     HDMI TX
-- 
2.25.1

Re: [PATCH 2/9] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support

[Geert Uytterhoeven]

On Mon, Sep 7, 2020 at 4:58 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 3/9] drm: rcar-du: Add r8a77961 support

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds R-Car M3-W+ (R8A77961) support which has
compatible to R-Car M3-W (R8A77960).

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index f53b0ec71085..64533cbdbef0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -458,6 +458,7 @@ static const struct of_device_id rcar_du_of_table[] = {
 	{ .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info },
 	{ .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
 	{ .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
+	{ .compatible = "renesas,du-r8a77961", .data = &rcar_du_r8a7796_info },
 	{ .compatible = "renesas,du-r8a77965", .data = &rcar_du_r8a77965_info },
 	{ .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info },
 	{ .compatible = "renesas,du-r8a77980", .data = &rcar_du_r8a77970_info },
-- 
2.25.1

[PATCH 4/9] arm64: dts: renesas: r8a77961: Add FCP device nodes

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC.
This patch is test on R-Car M3-W+ Salvator-XS board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 52 +++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index 0abfea0b27be..fe0db11b9cb9 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -2004,6 +2004,58 @@ pciec1: pcie@ee800000 {
 			status = "disabled";
 		};
 
+		fcpf0: fcp@fe950000 {
+			compatible = "renesas,fcpf";
+			reg = <0 0xfe950000 0 0x200>;
+			clocks = <&cpg CPG_MOD 615>;
+			power-domains = <&sysc R8A77961_PD_A3VC>;
+			resets = <&cpg 615>;
+		};
+
+		fcpvb0: fcp@fe96f000 {
+			compatible = "renesas,fcpv";
+			reg = <0 0xfe96f000 0 0x200>;
+			clocks = <&cpg CPG_MOD 607>;
+			power-domains = <&sysc R8A77961_PD_A3VC>;
+			resets = <&cpg 607>;
+		};
+
+		fcpvi0: fcp@fe9af000 {
+			compatible = "renesas,fcpv";
+			reg = <0 0xfe9af000 0 0x200>;
+			clocks = <&cpg CPG_MOD 611>;
+			power-domains = <&sysc R8A77961_PD_A3VC>;
+			resets = <&cpg 611>;
+			iommus = <&ipmmu_vc0 19>;
+		};
+
+		fcpvd0: fcp@fea27000 {
+			compatible = "renesas,fcpv";
+			reg = <0 0xfea27000 0 0x200>;
+			clocks = <&cpg CPG_MOD 603>;
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 603>;
+			iommus = <&ipmmu_vi0 8>;
+		};
+
+		fcpvd1: fcp@fea2f000 {
+			compatible = "renesas,fcpv";
+			reg = <0 0xfea2f000 0 0x200>;
+			clocks = <&cpg CPG_MOD 602>;
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 602>;
+			iommus = <&ipmmu_vi0 9>;
+		};
+
+		fcpvd2: fcp@fea37000 {
+			compatible = "renesas,fcpv";
+			reg = <0 0xfea37000 0 0x200>;
+			clocks = <&cpg CPG_MOD 601>;
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 601>;
+			iommus = <&ipmmu_vi0 10>;
+		};
+
 		csi20: csi2@fea80000 {
 			reg = <0 0xfea80000 0 0x10000>;
 			/* placeholder */
-- 
2.25.1

Re: [PATCH 4/9] arm64: dts: renesas: r8a77961: Add FCP device nodes

[Sergei Shtylyov]

On 07.09.2020 5:58, Kuninori Morimoto wrote:

> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch is test on R-Car M3-W+ Salvator-XS board.

    Was tested?

> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[...]

MBR, Sergei

[PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
This patch is test on R-Car M3-W+ Salvator-XS board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index fe0db11b9cb9..c2a6918ed5e6 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
 			iommus = <&ipmmu_vi0 10>;
 		};
 
+		vspb: vsp@fe960000 {
+			compatible = "renesas,vsp2";
+			reg = <0 0xfe960000 0 0x8000>;
+			interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 626>;
+			power-domains = <&sysc R8A77961_PD_A3VC>;
+			resets = <&cpg 626>;
+
+			renesas,fcp = <&fcpvb0>;
+		};
+
+		vspd0: vsp@fea20000 {
+			compatible = "renesas,vsp2";
+			reg = <0 0xfea20000 0 0x5000>;
+			interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 623>;
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 623>;
+
+			renesas,fcp = <&fcpvd0>;
+		};
+
+		vspd1: vsp@fea28000 {
+			compatible = "renesas,vsp2";
+			reg = <0 0xfea28000 0 0x5000>;
+			interrupts = <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 622>;
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 622>;
+
+			renesas,fcp = <&fcpvd1>;
+		};
+
+		vspd2: vsp@fea30000 {
+			compatible = "renesas,vsp2";
+			reg = <0 0xfea30000 0 0x5000>;
+			interrupts = <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 621>;
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 621>;
+
+			renesas,fcp = <&fcpvd2>;
+		};
+
+		vspi0: vsp@fe9a0000 {
+			compatible = "renesas,vsp2";
+			reg = <0 0xfe9a0000 0 0x8000>;
+			interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 631>;
+			power-domains = <&sysc R8A77961_PD_A3VC>;
+			resets = <&cpg 631>;
+
+			renesas,fcp = <&fcpvi0>;
+		};
+
 		csi20: csi2@fea80000 {
 			reg = <0 0xfea80000 0 0x10000>;
 			/* placeholder */
-- 
2.25.1

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Sergei Shtylyov]

On 07.09.2020 5:59, Kuninori Morimoto wrote:

> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch is test on R-Car M3-W+ Salvator-XS board.

    Was tested?

> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[...]

MBR, Sergei

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Sergei Shtylyov]

On 07.09.2020 11:08, Sergei Shtylyov wrote:

>> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>
>> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
>> This patch is test on R-Car M3-W+ Salvator-XS board.
> 
>     Was tested?

    The same comment to the patches 6 & 7.

>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> [...]

MBR, Sergei

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Kieran Bingham]

Hi Morimoto-san,

On 07/09/2020 03:59, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch is test on R-Car M3-W+ Salvator-XS board.
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index fe0db11b9cb9..c2a6918ed5e6 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
>  			iommus = <&ipmmu_vi0 10>;
>  		};

The FCP's added are:

                fcpf0: fcp@fe950000 {
                fcpf1: fcp@fe951000 {
                fcpvb0: fcp@fe96f000 {
                fcpvb1: fcp@fe92f000 {
                fcpvi0: fcp@fe9af000 {
                fcpvi1: fcp@fe9bf000 {
                fcpvd0: fcp@fea27000 {
                fcpvd1: fcp@fea2f000 {
                fcpvd2: fcp@fea37000 {

So indeed, the first fcpf0 comes before fe960000.

Do we keep the items grouped by the first occurrence? or sort the nodes
based on address?

for some reason I thought we were ordering based on address, but I see
other situations where we group too - so I'm confused (and wishing there
was an automatic tool to get the sorting correct without fuss).

Is there a set policy?

--
Kieran


> +		vspb: vsp@fe960000 {
> +			compatible = "renesas,vsp2";
> +			reg = <0 0xfe960000 0 0x8000>;
> +			interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 626>;
> +			power-domains = <&sysc R8A77961_PD_A3VC>;
> +			resets = <&cpg 626>;
> +
> +			renesas,fcp = <&fcpvb0>;
> +		};
> +
> +		vspd0: vsp@fea20000 {
> +			compatible = "renesas,vsp2";
> +			reg = <0 0xfea20000 0 0x5000>;
> +			interrupts = <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 623>;
> +			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> +			resets = <&cpg 623>;
> +
> +			renesas,fcp = <&fcpvd0>;
> +		};
> +
> +		vspd1: vsp@fea28000 {
> +			compatible = "renesas,vsp2";
> +			reg = <0 0xfea28000 0 0x5000>;
> +			interrupts = <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 622>;
> +			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> +			resets = <&cpg 622>;
> +
> +			renesas,fcp = <&fcpvd1>;
> +		};
> +
> +		vspd2: vsp@fea30000 {
> +			compatible = "renesas,vsp2";
> +			reg = <0 0xfea30000 0 0x5000>;
> +			interrupts = <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 621>;
> +			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> +			resets = <&cpg 621>;
> +
> +			renesas,fcp = <&fcpvd2>;
> +		};
> +
> +		vspi0: vsp@fe9a0000 {
> +			compatible = "renesas,vsp2";
> +			reg = <0 0xfe9a0000 0 0x8000>;
> +			interrupts = <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_MOD 631>;
> +			power-domains = <&sysc R8A77961_PD_A3VC>;
> +			resets = <&cpg 631>;
> +
> +			renesas,fcp = <&fcpvi0>;
> +		};
> +
>  		csi20: csi2@fea80000 {
>  			reg = <0 0xfea80000 0 0x10000>;
>  			/* placeholder */
> 

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Kuninori Morimoto]

Hi Kieran

> > From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > 
> > This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> > This patch is test on R-Car M3-W+ Salvator-XS board.
> > 
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
(snip)
> Do we keep the items grouped by the first occurrence? or sort the nodes
> based on address?
(snip)
> Is there a set policy?

The order is same as r8a77960.dtsi, not my policy.
Will sort in v2


Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Geert Uytterhoeven]

Hi Kieran,

On Mon, Sep 7, 2020 at 5:55 PM Kieran Bingham
<kieran.bingham+renesas@ideasonboard.com> wrote:
> On 07/09/2020 03:59, Kuninori Morimoto wrote:
> > From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >
> > This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> > This patch is test on R-Car M3-W+ Salvator-XS board.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> >  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++++++++++++++++++++++
> >  1 file changed, 55 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > index fe0db11b9cb9..c2a6918ed5e6 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
> >                       iommus = <&ipmmu_vi0 10>;
> >               };
>
> The FCP's added are:
>
>                 fcpf0: fcp@fe950000 {
>                 fcpf1: fcp@fe951000 {
>                 fcpvb0: fcp@fe96f000 {
>                 fcpvb1: fcp@fe92f000 {
>                 fcpvi0: fcp@fe9af000 {
>                 fcpvi1: fcp@fe9bf000 {
>                 fcpvd0: fcp@fea27000 {
>                 fcpvd1: fcp@fea2f000 {
>                 fcpvd2: fcp@fea37000 {
>
> So indeed, the first fcpf0 comes before fe960000.
>
> Do we keep the items grouped by the first occurrence? or sort the nodes
> based on address?
>
> for some reason I thought we were ordering based on address, but I see
> other situations where we group too - so I'm confused (and wishing there
> was an automatic tool to get the sorting correct without fuss).
>
> Is there a set policy?

For nodes with a unit-address, we usually[*] sort by unit-address, but we keep
similar nodes grouped.  Hence I prefer this v1 over v2.

[*] Seems like FCP/VSP are interleaved in r8a77990.dsi, doh.

> > +             vspb: vsp@fe960000 {
> > +                     compatible = "renesas,vsp2";
> > +                     reg = <0 0xfe960000 0 0x8000>;
> > +                     interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
> > +                     clocks = <&cpg CPG_MOD 626>;
> > +                     power-domains = <&sysc R8A77961_PD_A3VC>;
> > +                     resets = <&cpg 626>;
> > +
> > +                     renesas,fcp = <&fcpvb0>;
> > +             };

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Kieran Bingham]

Hi Geert,

On 10/09/2020 10:44, Geert Uytterhoeven wrote:
> Hi Kieran,
> 
> On Mon, Sep 7, 2020 at 5:55 PM Kieran Bingham
> <kieran.bingham+renesas@ideasonboard.com> wrote:
>> On 07/09/2020 03:59, Kuninori Morimoto wrote:
>>> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>>
>>> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
>>> This patch is test on R-Car M3-W+ Salvator-XS board.
>>>
>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>> ---
>>>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++++++++++++++++++++++
>>>  1 file changed, 55 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
>>> index fe0db11b9cb9..c2a6918ed5e6 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
>>> @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
>>>                       iommus = <&ipmmu_vi0 10>;
>>>               };
>>
>> The FCP's added are:
>>
>>                 fcpf0: fcp@fe950000 {
>>                 fcpf1: fcp@fe951000 {
>>                 fcpvb0: fcp@fe96f000 {
>>                 fcpvb1: fcp@fe92f000 {
>>                 fcpvi0: fcp@fe9af000 {
>>                 fcpvi1: fcp@fe9bf000 {
>>                 fcpvd0: fcp@fea27000 {
>>                 fcpvd1: fcp@fea2f000 {
>>                 fcpvd2: fcp@fea37000 {
>>
>> So indeed, the first fcpf0 comes before fe960000.
>>
>> Do we keep the items grouped by the first occurrence? or sort the nodes
>> based on address?
>>
>> for some reason I thought we were ordering based on address, but I see
>> other situations where we group too - so I'm confused (and wishing there
>> was an automatic tool to get the sorting correct without fuss).
>>
>> Is there a set policy?
> 
> For nodes with a unit-address, we usually[*] sort by unit-address, but we keep
> similar nodes grouped.  Hence I prefer this v1 over v2.

I assume then the groups are sorted by the first entry,

I.e. hypothetically:

fdp@0
fcp@1
vsp@2
fdp@3
fcp@4
vsp@5
cmm@6
cmm@7

would become

fdp@0
fdp@3
fcp@1
fcp@4
vsp@2
vsp@5
cmm@6
cmm@7

Has anyone already created any scripting/validation to automate the
sorting requirements?

> 
> [*] Seems like FCP/VSP are interleaved in r8a77990.dsi, doh.
> 

Personally I prefer that - but my opinion doesn't matter here - so as
long as the rules are defined (or even better, automatically
enforceable) that's fine.


>>> +             vspb: vsp@fe960000 {
>>> +                     compatible = "renesas,vsp2";
>>> +                     reg = <0 0xfe960000 0 0x8000>;
>>> +                     interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
>>> +                     clocks = <&cpg CPG_MOD 626>;
>>> +                     power-domains = <&sysc R8A77961_PD_A3VC>;
>>> +                     resets = <&cpg 626>;
>>> +
>>> +                     renesas,fcp = <&fcpvb0>;
>>> +             };
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Geert Uytterhoeven]

Hi Kieran,

On Thu, Sep 10, 2020 at 12:34 PM Kieran Bingham
<kieran.bingham+renesas@ideasonboard.com> wrote:
> On 10/09/2020 10:44, Geert Uytterhoeven wrote:
> > On Mon, Sep 7, 2020 at 5:55 PM Kieran Bingham
> > <kieran.bingham+renesas@ideasonboard.com> wrote:
> >> On 07/09/2020 03:59, Kuninori Morimoto wrote:
> >>> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>>
> >>> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> >>> This patch is test on R-Car M3-W+ Salvator-XS board.
> >>>
> >>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>> ---
> >>>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++++++++++++++++++++++
> >>>  1 file changed, 55 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> >>> index fe0db11b9cb9..c2a6918ed5e6 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> >>> @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
> >>>                       iommus = <&ipmmu_vi0 10>;
> >>>               };
> >>
> >> The FCP's added are:
> >>
> >>                 fcpf0: fcp@fe950000 {
> >>                 fcpf1: fcp@fe951000 {
> >>                 fcpvb0: fcp@fe96f000 {
> >>                 fcpvb1: fcp@fe92f000 {
> >>                 fcpvi0: fcp@fe9af000 {
> >>                 fcpvi1: fcp@fe9bf000 {
> >>                 fcpvd0: fcp@fea27000 {
> >>                 fcpvd1: fcp@fea2f000 {
> >>                 fcpvd2: fcp@fea37000 {
> >>
> >> So indeed, the first fcpf0 comes before fe960000.
> >>
> >> Do we keep the items grouped by the first occurrence? or sort the nodes
> >> based on address?
> >>
> >> for some reason I thought we were ordering based on address, but I see
> >> other situations where we group too - so I'm confused (and wishing there
> >> was an automatic tool to get the sorting correct without fuss).
> >>
> >> Is there a set policy?
> >
> > For nodes with a unit-address, we usually[*] sort by unit-address, but we keep
> > similar nodes grouped.  Hence I prefer this v1 over v2.
>
> I assume then the groups are sorted by the first entry,
>
> I.e. hypothetically:
>
> fdp@0
> fcp@1
> vsp@2
> fdp@3
> fcp@4
> vsp@5
> cmm@6
> cmm@7
>
> would become
>
> fdp@0
> fdp@3
> fcp@1
> fcp@4
> vsp@2
> vsp@5
> cmm@6
> cmm@7

Exactly.  That's how we (Reneas SoCs) have been (trying to) doing it.
I am aware there are some deviations (e.g. do you keep all 4 possible
SCIF types together (they're all serial@), or do you group them per
type? And some nodes (ipmmu) may be sorted alphabetically by label).

> Has anyone already created any scripting/validation to automate the
> sorting requirements?

Not yet, AFAIK. I've been thinking about doing that several times,
though ;-)

> > [*] Seems like FCP/VSP are interleaved in r8a77990.dsi, doh.
> >
>
> Personally I prefer that - but my opinion doesn't matter here - so as
> long as the rules are defined (or even better, automatically
> enforceable) that's fine.

Indeed.

Perhaps creating rules is something to be handled at a higher level
(i.e. common for all DTS files)?

Summarizing "our" rules:
  1. Nodes without unit-address are sorted alphabetically, by node name,
  2. Nodes with unit-address are sorted numerically, by unit-address,
       a. Nodes of the same type are grouped together, i.e. the whole
          group is sorted w.r.t. to other nodes/groups based on the
          unit-address of the first member of the group.
  3. Anchors are sorted alphabetically, but anchor name.

Do they make sense?

> >>> +             vspb: vsp@fe960000 {
> >>> +                     compatible = "renesas,vsp2";
> >>> +                     reg = <0 0xfe960000 0 0x8000>;
> >>> +                     interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
> >>> +                     clocks = <&cpg CPG_MOD 626>;
> >>> +                     power-domains = <&sysc R8A77961_PD_A3VC>;
> >>> +                     resets = <&cpg 626>;
> >>> +
> >>> +                     renesas,fcp = <&fcpvb0>;
> >>> +             };

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Geert Uytterhoeven]

On Thu, Sep 10, 2020 at 1:09 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Sep 10, 2020 at 12:34 PM Kieran Bingham
> <kieran.bingham+renesas@ideasonboard.com> wrote:
> > On 10/09/2020 10:44, Geert Uytterhoeven wrote:
> > > On Mon, Sep 7, 2020 at 5:55 PM Kieran Bingham
> > > <kieran.bingham+renesas@ideasonboard.com> wrote:
> > >> On 07/09/2020 03:59, Kuninori Morimoto wrote:
> > >>> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > >>>
> > >>> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> > >>> This patch is test on R-Car M3-W+ Salvator-XS board.

> > >>> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > >>> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > >>> @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
> > >>>                       iommus = <&ipmmu_vi0 10>;
> > >>>               };
> > >>
> > >> The FCP's added are:
> > >>
> > >>                 fcpf0: fcp@fe950000 {
> > >>                 fcpf1: fcp@fe951000 {
> > >>                 fcpvb0: fcp@fe96f000 {
> > >>                 fcpvb1: fcp@fe92f000 {
> > >>                 fcpvi0: fcp@fe9af000 {
> > >>                 fcpvi1: fcp@fe9bf000 {
> > >>                 fcpvd0: fcp@fea27000 {
> > >>                 fcpvd1: fcp@fea2f000 {
> > >>                 fcpvd2: fcp@fea37000 {
> > >>
> > >> So indeed, the first fcpf0 comes before fe960000.
> > >>
> > >> Do we keep the items grouped by the first occurrence? or sort the nodes
> > >> based on address?
> > >>
> > >> for some reason I thought we were ordering based on address, but I see
> > >> other situations where we group too - so I'm confused (and wishing there
> > >> was an automatic tool to get the sorting correct without fuss).
> > >>
> > >> Is there a set policy?
> > >
> > > For nodes with a unit-address, we usually[*] sort by unit-address, but we keep
> > > similar nodes grouped.  Hence I prefer this v1 over v2.
> >
> > I assume then the groups are sorted by the first entry,
> >
> > I.e. hypothetically:
> >
> > fdp@0
> > fcp@1
> > vsp@2
> > fdp@3
> > fcp@4
> > vsp@5
> > cmm@6
> > cmm@7
> >
> > would become
> >
> > fdp@0
> > fdp@3
> > fcp@1
> > fcp@4
> > vsp@2
> > vsp@5
> > cmm@6
> > cmm@7
>
> Exactly.  That's how we (Reneas SoCs) have been (trying to) doing it.
> I am aware there are some deviations (e.g. do you keep all 4 possible
> SCIF types together (they're all serial@), or do you group them per
> type? And some nodes (ipmmu) may be sorted alphabetically by label).
>
> > Has anyone already created any scripting/validation to automate the
> > sorting requirements?
>
> Not yet, AFAIK. I've been thinking about doing that several times,
> though ;-)
>
> > > [*] Seems like FCP/VSP are interleaved in r8a77990.dsi, doh.
> > >
> >
> > Personally I prefer that - but my opinion doesn't matter here - so as
> > long as the rules are defined (or even better, automatically
> > enforceable) that's fine.
>
> Indeed.
>
> Perhaps creating rules is something to be handled at a higher level
> (i.e. common for all DTS files)?
>
> Summarizing "our" rules:
>   1. Nodes without unit-address are sorted alphabetically, by node name,
>   2. Nodes with unit-address are sorted numerically, by unit-address,
>        a. Nodes of the same type are grouped together, i.e. the whole
>           group is sorted w.r.t. to other nodes/groups based on the
>           unit-address of the first member of the group.
>   3. Anchors are sorted alphabetically, but anchor name.
>
> Do they make sense?

For comparison, scripts/dtc/dtx_diff uses "dtc -s" for sorting, which
sorts everything (nodes and properties) alphabetically.
While I can agree on sorting all nodes alphabetically, sorting
properties alphabetically goes IMHO a bit too far.  E.g. it's established
practice to put "compatible" and "reg" first.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes

[Geert Uytterhoeven]

On Mon, Sep 7, 2020 at 4:59 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch is test on R-Car M3-W+ Salvator-XS board.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 6/9] arm64: dts: renesas: r8a77961: Add DU device nodes

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds DU device nodes for R-Car M3-W+ (r8a77961) SoC.
This patch is test on R-Car M3-W+ Salvator-XS board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index c2a6918ed5e6..dcd92f5abad6 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -2165,8 +2165,19 @@ port@2 {
 		};
 
 		du: display@feb00000 {
+			compatible = "renesas,du-r8a77961";
 			reg = <0 0xfeb00000 0 0x70000>;
-			/* placeholder */
+			interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>,
+				 <&cpg CPG_MOD 722>;
+			clock-names = "du.0", "du.1", "du.2";
+			resets = <&cpg 724>, <&cpg 722>;
+			reset-names = "du.0", "du.2";
+
+			renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>;
+			status = "disabled";
 
 			ports {
 				#address-cells = <1>;
-- 
2.25.1

[PATCH 7/9] arm64: dts: renesas: r8a77961: Add HDMI device nodes

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds HDMI device nodes for R-Car M3-W+ (r8a77961) SoC.
This patch is test on R-Car M3-W+ Salvator-XS board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index dcd92f5abad6..5050cf8e7625 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -2145,14 +2145,23 @@ port@1 {
 		};
 
 		hdmi0: hdmi@fead0000 {
+			compatible = "renesas,r8a77961-hdmi", "renesas,rcar-gen3-hdmi";
 			reg = <0 0xfead0000 0 0x10000>;
-			/* placeholder */
+			interrupts = <GIC_SPI 389 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 729>, <&cpg CPG_CORE R8A77961_CLK_HDMI>;
+			clock-names = "iahb", "isfr";
+			power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+			resets = <&cpg 729>;
+			status = "disabled";
 
 			ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 				port@0 {
 					reg = <0>;
+					dw_hdmi0_in: endpoint {
+						remote-endpoint = <&du_out_hdmi0>;
+					};
 				};
 				port@1 {
 					reg = <1>;
@@ -2191,6 +2200,7 @@ du_out_rgb: endpoint {
 				port@1 {
 					reg = <1>;
 					du_out_hdmi0: endpoint {
+						remote-endpoint = <&dw_hdmi0_in>;
 					};
 				};
 				port@2 {
-- 
2.25.1

[PATCH 8/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board.
This patch is test on R-Car M3-W+ Salvator-XS board.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 .../boot/dts/renesas/r8a77961-salvator-xs.dts | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
index 2ffc7e31dd58..ca21a702db54 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
@@ -29,3 +29,31 @@ memory@600000000 {
 		reg = <0x6 0x00000000 0x1 0x00000000>;
 	};
 };
+
+&du {
+	clocks = <&cpg CPG_MOD 724>,
+		 <&cpg CPG_MOD 723>,
+		 <&cpg CPG_MOD 722>,
+		 <&versaclock6 1>,
+		 <&x21_clk>,
+		 <&versaclock6 2>;
+	clock-names = "du.0", "du.1", "du.2",
+		      "dclkin.0", "dclkin.1", "dclkin.2";
+};
+
+&hdmi0 {
+	status = "okay";
+
+	ports {
+		port@1 {
+			reg = <1>;
+			rcar_dw_hdmi0_out: endpoint {
+				remote-endpoint = <&hdmi0_con>;
+			};
+		};
+	};
+};
+
+&hdmi0_con {
+	remote-endpoint = <&rcar_dw_hdmi0_out>;
+};
-- 
2.25.1

Re: [PATCH 8/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support

[Sergei Shtylyov]

Hello!

On 07.09.2020 5:59, Kuninori Morimoto wrote:

> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board.
> This patch is test on R-Car M3-W+ Salvator-XS board.

    Was tested, perhaps?

> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[...]

MBR, Sergei

[PATCH 9/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board.
This patch is test on R-Car M3-W+ Salvator-XS board.

This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 .../boot/dts/renesas/r8a77961-salvator-xs.dts | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
index ca21a702db54..1e7603365106 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
@@ -51,9 +51,38 @@ rcar_dw_hdmi0_out: endpoint {
 				remote-endpoint = <&hdmi0_con>;
 			};
 		};
+		port@2 {
+			reg = <2>;
+			dw_hdmi0_snd_in: endpoint {
+				remote-endpoint = <&rsnd_endpoint1>;
+			};
+		};
 	};
 };
 
 &hdmi0_con {
 	remote-endpoint = <&rcar_dw_hdmi0_out>;
 };
+
+&rcar_sound {
+	ports {
+		/* rsnd_port0 is on salvator-common */
+		rsnd_port1: port@1 {
+			reg = <1>;
+			rsnd_endpoint1: endpoint {
+				remote-endpoint = <&dw_hdmi0_snd_in>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_endpoint1>;
+				frame-master = <&rsnd_endpoint1>;
+
+				playback = <&ssi2>;
+			};
+		};
+	};
+};
+
+&sound_card {
+	dais = <&rsnd_port0	/* ak4613 */
+		&rsnd_port1>;	/* HDMI0  */
+};
-- 
2.25.1