[PATCH v3 00/10] drm: Add DSI/DP support for Renesas r8a779h0 V4M and grey-hawk board

[PATCH v3 00/10] drm: Add DSI/DP support for Renesas r8a779h0 V4M and grey-hawk board

[Tomi Valkeinen]

Add everything needed to support the DSI output on Renesas r8a779h0
(V4M) SoC, and the DP output (via sn65dsi86 DSI to DP bridge) on the
Renesas grey-hawk board.

Overall the DSI and the board design is almost identical to Renesas
r8a779g0 and white-hawk board.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
Changes in v3:
- Update "Write DPTSR only if there are more than one crtc" patch to
  "Write DPTSR only if the second source exists"
- Add Laurent's Rb
- Link to v2: https://lore.kernel.org/r/20241205-rcar-gh-dsi-v2-0-42471851df86@ideasonboard.com

Changes in v2:
- Add the DT binding with a new conditional block, so that we can set
  only the port@0 as required
- Drop port@1 from r8a779h0.dtsi (there's no port@1)
- Add a new patch to write DPTSR only if num_crtcs > 1
- Drop RCAR_DU_FEATURE_NO_DPTSR (not needed anymore)
- Add Cc: stable to the fix, and move it as first patch
- Added the tags from reviews
- Link to v1: https://lore.kernel.org/r/20241203-rcar-gh-dsi-v1-0-738ae1a95d2a@ideasonboard.com

---
Tomi Valkeinen (10):
      drm/rcar-du: dsi: Fix PHY lock bit check
      drm/rcar-du: Write DPTSR only if the second source exists
      dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779h0
      dt-bindings: display: renesas,du: Add r8a779h0
      clk: renesas: r8a779h0: Add display clocks
      drm/rcar-du: dsi: Add r8a779h0 support
      drm/rcar-du: Add support for r8a779h0
      arm64: dts: renesas: gray-hawk-single: Fix indentation
      arm64: dts: renesas: r8a779h0: Add display support
      arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

 .../display/bridge/renesas,dsi-csi2-tx.yaml        |   1 +
 .../devicetree/bindings/display/renesas,du.yaml    |  52 ++++++++-
 .../boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 119 ++++++++++++++++++---
 arch/arm64/boot/dts/renesas/r8a779h0.dtsi          |  73 +++++++++++++
 drivers/clk/renesas/r8a779h0-cpg-mssr.c            |   4 +
 drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c      |  18 ++++
 drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c    |  24 +++--
 drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c    |   4 +-
 .../gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h   |   1 -
 9 files changed, 272 insertions(+), 24 deletions(-)
---
base-commit: adc218676eef25575469234709c2d87185ca223a
change-id: 20241008-rcar-gh-dsi-9c01f5deeac8

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

[PATCH v3 01/10] drm/rcar-du: dsi: Fix PHY lock bit check

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

The driver checks for bit 16 (using CLOCKSET1_LOCK define) in CLOCKSET1
register when waiting for the PPI clock. However, the right bit to check
is bit 17 (CLOCKSET1_LOCK_PHY define). Not only that, but there's
nothing in the documents for bit 16 for V3U nor V4H.

So, fix the check to use bit 17, and drop the define for bit 16.

Fixes: 155358310f01 ("drm: rcar-du: Add R-Car DSI driver")
Fixes: 11696c5e8924 ("drm: Place Renesas drivers in a separate dir")
Cc: stable@vger.kernel.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c      | 2 +-
 drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
index 2dba7c5ffd2c..92f4261305bd 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
@@ -587,7 +587,7 @@ static int rcar_mipi_dsi_startup(struct rcar_mipi_dsi *dsi,
 	for (timeout = 10; timeout > 0; --timeout) {
 		if ((rcar_mipi_dsi_read(dsi, PPICLSR) & PPICLSR_STPST) &&
 		    (rcar_mipi_dsi_read(dsi, PPIDLSR) & PPIDLSR_STPST) &&
-		    (rcar_mipi_dsi_read(dsi, CLOCKSET1) & CLOCKSET1_LOCK))
+		    (rcar_mipi_dsi_read(dsi, CLOCKSET1) & CLOCKSET1_LOCK_PHY))
 			break;
 
 		usleep_range(1000, 2000);
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h
index f8114d11f2d1..a6b276f1d6ee 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h
@@ -142,7 +142,6 @@
 
 #define CLOCKSET1			0x101c
 #define CLOCKSET1_LOCK_PHY		(1 << 17)
-#define CLOCKSET1_LOCK			(1 << 16)
 #define CLOCKSET1_CLKSEL		(1 << 8)
 #define CLOCKSET1_CLKINSEL_EXTAL	(0 << 2)
 #define CLOCKSET1_CLKINSEL_DIG		(1 << 2)

-- 
2.43.0

[PATCH v3 02/10] drm/rcar-du: Write DPTSR only if the second source exists

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Currently the driver always writes DPTSR when setting up the hardware.
However, writing the register is only meaningful when the second source
for a plane is used, and the register is not even documented for SoCs
that do not have the second source.

So move the write behind a condition.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
 drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
index 2ccd2581f544..1ec806c8e013 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
@@ -185,11 +185,21 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
 		dorcr |= DORCR_PG1T | DORCR_DK1S | DORCR_PG1D_DS1;
 	rcar_du_group_write(rgrp, DORCR, dorcr);
 
-	/* Apply planes to CRTCs association. */
-	mutex_lock(&rgrp->lock);
-	rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
-			    rgrp->dptsr_planes);
-	mutex_unlock(&rgrp->lock);
+	/*
+	 * DPTSR is used to select the source for the planes of a group. The
+	 * first source is chosen by writing 0 to the respective bits, and this
+	 * is always the default value of the register. In other words, writing
+	 * DPTSR is only needed if the SoC supports choosing the second source.
+	 *
+	 * The SoCs documentations seems to confirm this, as the DPTSR register
+	 * is not documented if only the first source exists on that SoC.
+	 */
+	if (rgrp->channels_mask & BIT(1)) {
+		mutex_lock(&rgrp->lock);
+		rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
+				    rgrp->dptsr_planes);
+		mutex_unlock(&rgrp->lock);
+	}
 }
 
 /*

-- 
2.43.0

Re: [PATCH v3 02/10] drm/rcar-du: Write DPTSR only if the second source exists

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Fri, Dec 06, 2024 at 11:32:35AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> 
> Currently the driver always writes DPTSR when setting up the hardware.
> However, writing the register is only meaningful when the second source
> for a plane is used, and the register is not even documented for SoCs
> that do not have the second source.

I've confirmed that for all the models currently supported by the DU
driver.

> So move the write behind a condition.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

I will test the series on an M3N board.

> ---
>  drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> index 2ccd2581f544..1ec806c8e013 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> @@ -185,11 +185,21 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
>  		dorcr |= DORCR_PG1T | DORCR_DK1S | DORCR_PG1D_DS1;
>  	rcar_du_group_write(rgrp, DORCR, dorcr);
>  
> -	/* Apply planes to CRTCs association. */
> -	mutex_lock(&rgrp->lock);
> -	rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> -			    rgrp->dptsr_planes);
> -	mutex_unlock(&rgrp->lock);
> +	/*
> +	 * DPTSR is used to select the source for the planes of a group. The
> +	 * first source is chosen by writing 0 to the respective bits, and this
> +	 * is always the default value of the register. In other words, writing
> +	 * DPTSR is only needed if the SoC supports choosing the second source.
> +	 *
> +	 * The SoCs documentations seems to confirm this, as the DPTSR register
> +	 * is not documented if only the first source exists on that SoC.
> +	 */
> +	if (rgrp->channels_mask & BIT(1)) {
> +		mutex_lock(&rgrp->lock);
> +		rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> +				    rgrp->dptsr_planes);
> +		mutex_unlock(&rgrp->lock);
> +	}
>  }
>  
>  /*
> 

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 02/10] drm/rcar-du: Write DPTSR only if the second source exists

[Laurent Pinchart]

On Tue, Dec 10, 2024 at 01:04:19AM +0200, Laurent Pinchart wrote:
> On Fri, Dec 06, 2024 at 11:32:35AM +0200, Tomi Valkeinen wrote:
> > From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > 
> > Currently the driver always writes DPTSR when setting up the hardware.
> > However, writing the register is only meaningful when the second source
> > for a plane is used, and the register is not even documented for SoCs
> > that do not have the second source.
> 
> I've confirmed that for all the models currently supported by the DU
> driver.
> 
> > So move the write behind a condition.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
> I will test the series on an M3N board.

Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> # On R-Car M3-N

> > ---
> >  drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 20 +++++++++++++++-----
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > index 2ccd2581f544..1ec806c8e013 100644
> > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > @@ -185,11 +185,21 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
> >  		dorcr |= DORCR_PG1T | DORCR_DK1S | DORCR_PG1D_DS1;
> >  	rcar_du_group_write(rgrp, DORCR, dorcr);
> >  
> > -	/* Apply planes to CRTCs association. */
> > -	mutex_lock(&rgrp->lock);
> > -	rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> > -			    rgrp->dptsr_planes);
> > -	mutex_unlock(&rgrp->lock);
> > +	/*
> > +	 * DPTSR is used to select the source for the planes of a group. The
> > +	 * first source is chosen by writing 0 to the respective bits, and this
> > +	 * is always the default value of the register. In other words, writing
> > +	 * DPTSR is only needed if the SoC supports choosing the second source.
> > +	 *
> > +	 * The SoCs documentations seems to confirm this, as the DPTSR register
> > +	 * is not documented if only the first source exists on that SoC.
> > +	 */
> > +	if (rgrp->channels_mask & BIT(1)) {
> > +		mutex_lock(&rgrp->lock);
> > +		rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> > +				    rgrp->dptsr_planes);
> > +		mutex_unlock(&rgrp->lock);
> > +	}
> >  }
> >  
> >  /*
> > 

-- 
Regards,

Laurent Pinchart

[PATCH v3 03/10] dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779h0

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Extend the Renesas DSI display bindings to support the r8a779h0 V4M.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 .../devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml          | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
index d33026f85e19..c167795c63f6 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
@@ -19,6 +19,7 @@ properties:
     enum:
       - renesas,r8a779a0-dsi-csi2-tx    # for V3U
       - renesas,r8a779g0-dsi-csi2-tx    # for V4H
+      - renesas,r8a779h0-dsi-csi2-tx    # for V4M
 
   reg:
     maxItems: 1

-- 
2.43.0

[PATCH v3 04/10] dt-bindings: display: renesas,du: Add r8a779h0

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Extend the Renesas DU display bindings to support the r8a779h0 V4M.

Note that we remove the requirement for two ports from the global part
of the bindings, as each conditional part defines the number of required
ports already. This came up with r8a779h0 as it's the first one that has
only one port.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 .../devicetree/bindings/display/renesas,du.yaml    | 52 ++++++++++++++++++++--
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
index c5b9e6812bce..7dec47aea052 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -41,6 +41,7 @@ properties:
       - renesas,du-r8a77995 # for R-Car D3 compatible DU
       - renesas,du-r8a779a0 # for R-Car V3U compatible DU
       - renesas,du-r8a779g0 # for R-Car V4H compatible DU
+      - renesas,du-r8a779h0 # for R-Car V4M compatible DU
 
   reg:
     maxItems: 1
@@ -69,10 +70,6 @@ properties:
         $ref: /schemas/graph.yaml#/properties/port
         unevaluatedProperties: false
 
-    required:
-      - port@0
-      - port@1
-
     unevaluatedProperties: false
 
   renesas,cmms:
@@ -807,6 +804,53 @@ allOf:
         - reset-names
         - renesas,vsps
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - renesas,du-r8a779h0
+    then:
+      properties:
+        clocks:
+          items:
+            - description: Functional clock
+
+        clock-names:
+          items:
+            - const: du.0
+
+        interrupts:
+          maxItems: 1
+
+        resets:
+          maxItems: 1
+
+        reset-names:
+          items:
+            - const: du.0
+
+        ports:
+          properties:
+            port@0:
+              description: DSI 0
+            port@1: false
+            port@2: false
+            port@3: false
+
+          required:
+            - port@0
+
+        renesas,vsps:
+          minItems: 1
+
+      required:
+        - clock-names
+        - interrupts
+        - resets
+        - reset-names
+        - renesas,vsps
+
 additionalProperties: false
 
 examples:

-- 
2.43.0

Re: [PATCH v3 04/10] dt-bindings: display: renesas,du: Add r8a779h0

[Rob Herring]

On Fri, Dec 06, 2024 at 11:32:37AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> 
> Extend the Renesas DU display bindings to support the r8a779h0 V4M.
> 
> Note that we remove the requirement for two ports from the global part
> of the bindings, as each conditional part defines the number of required
> ports already. This came up with r8a779h0 as it's the first one that has
> only one port.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  .../devicetree/bindings/display/renesas,du.yaml    | 52 ++++++++++++++++++++--
>  1 file changed, 48 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
> index c5b9e6812bce..7dec47aea052 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> @@ -41,6 +41,7 @@ properties:
>        - renesas,du-r8a77995 # for R-Car D3 compatible DU
>        - renesas,du-r8a779a0 # for R-Car V3U compatible DU
>        - renesas,du-r8a779g0 # for R-Car V4H compatible DU
> +      - renesas,du-r8a779h0 # for R-Car V4M compatible DU
>  
>    reg:
>      maxItems: 1
> @@ -69,10 +70,6 @@ properties:
>          $ref: /schemas/graph.yaml#/properties/port
>          unevaluatedProperties: false
>  
> -    required:
> -      - port@0
> -      - port@1
> -
>      unevaluatedProperties: false
>  
>    renesas,cmms:
> @@ -807,6 +804,53 @@ allOf:
>          - reset-names
>          - renesas,vsps
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - renesas,du-r8a779h0
> +    then:
> +      properties:
> +        clocks:
> +          items:
> +            - description: Functional clock
> +
> +        clock-names:
> +          items:
> +            - const: du.0
> +
> +        interrupts:
> +          maxItems: 1
> +
> +        resets:
> +          maxItems: 1
> +
> +        reset-names:
> +          items:
> +            - const: du.0
> +
> +        ports:
> +          properties:
> +            port@0:
> +              description: DSI 0
> +            port@1: false
> +            port@2: false
> +            port@3: false
> +
> +          required:
> +            - port@0
> +
> +        renesas,vsps:
> +          minItems: 1

maxItems? The min is already 1.

Note maxItems is missing in all the other cases too. Since the top-level 
definition has no constraints, all the constraints under if/then schemas 
need both minItems and maxItems. (Unless there's no max).

> +
> +      required:
> +        - clock-names
> +        - interrupts
> +        - resets
> +        - reset-names
> +        - renesas,vsps
> +
>  additionalProperties: false
>  
>  examples:
> 
> -- 
> 2.43.0
> 

Re: [PATCH v3 04/10] dt-bindings: display: renesas,du: Add r8a779h0

[Tomi Valkeinen]

Hi,

On 11/12/2024 17:45, Rob Herring wrote:
> On Fri, Dec 06, 2024 at 11:32:37AM +0200, Tomi Valkeinen wrote:
>> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>
>> Extend the Renesas DU display bindings to support the r8a779h0 V4M.
>>
>> Note that we remove the requirement for two ports from the global part
>> of the bindings, as each conditional part defines the number of required
>> ports already. This came up with r8a779h0 as it's the first one that has
>> only one port.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>>   .../devicetree/bindings/display/renesas,du.yaml    | 52 ++++++++++++++++++++--
>>   1 file changed, 48 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
>> index c5b9e6812bce..7dec47aea052 100644
>> --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
>> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
>> @@ -41,6 +41,7 @@ properties:
>>         - renesas,du-r8a77995 # for R-Car D3 compatible DU
>>         - renesas,du-r8a779a0 # for R-Car V3U compatible DU
>>         - renesas,du-r8a779g0 # for R-Car V4H compatible DU
>> +      - renesas,du-r8a779h0 # for R-Car V4M compatible DU
>>   
>>     reg:
>>       maxItems: 1
>> @@ -69,10 +70,6 @@ properties:
>>           $ref: /schemas/graph.yaml#/properties/port
>>           unevaluatedProperties: false
>>   
>> -    required:
>> -      - port@0
>> -      - port@1
>> -
>>       unevaluatedProperties: false
>>   
>>     renesas,cmms:
>> @@ -807,6 +804,53 @@ allOf:
>>           - reset-names
>>           - renesas,vsps
>>   
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - renesas,du-r8a779h0
>> +    then:
>> +      properties:
>> +        clocks:
>> +          items:
>> +            - description: Functional clock
>> +
>> +        clock-names:
>> +          items:
>> +            - const: du.0
>> +
>> +        interrupts:
>> +          maxItems: 1
>> +
>> +        resets:
>> +          maxItems: 1
>> +
>> +        reset-names:
>> +          items:
>> +            - const: du.0
>> +
>> +        ports:
>> +          properties:
>> +            port@0:
>> +              description: DSI 0
>> +            port@1: false
>> +            port@2: false
>> +            port@3: false
>> +
>> +          required:
>> +            - port@0
>> +
>> +        renesas,vsps:
>> +          minItems: 1
> 
> maxItems? The min is already 1.
> 
> Note maxItems is missing in all the other cases too. Since the top-level
> definition has no constraints, all the constraints under if/then schemas
> need both minItems and maxItems. (Unless there's no max).

Thanks. I have sent a v4, with a new patch that adds the maxItems to all 
SoCs, and also fixed this patch similarly.

  Tomi

[PATCH v3 05/10] clk: renesas: r8a779h0: Add display clocks

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Add display related clocks for DU, DSI, FCPVD, and VSPD.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/clk/renesas/r8a779h0-cpg-mssr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/renesas/r8a779h0-cpg-mssr.c b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
index e20c048bfa9b..dc37e987c0e6 100644
--- a/drivers/clk/renesas/r8a779h0-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
@@ -179,6 +179,9 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
 	DEF_MOD("canfd0",	328,	R8A779H0_CLK_SASYNCPERD2),
 	DEF_MOD("csi40",	331,	R8A779H0_CLK_CSI),
 	DEF_MOD("csi41",	400,	R8A779H0_CLK_CSI),
+	DEF_MOD("dis0",		411,	R8A779H0_CLK_S0D3),
+	DEF_MOD("dsitxlink0",	415,	R8A779H0_CLK_DSIREF),
+	DEF_MOD("fcpvd0",	508,	R8A779H0_CLK_S0D3),
 	DEF_MOD("hscif0",	514,	R8A779H0_CLK_SASYNCPERD1),
 	DEF_MOD("hscif1",	515,	R8A779H0_CLK_SASYNCPERD1),
 	DEF_MOD("hscif2",	516,	R8A779H0_CLK_SASYNCPERD1),
@@ -227,6 +230,7 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
 	DEF_MOD("vin15",	811,	R8A779H0_CLK_S0D4_VIO),
 	DEF_MOD("vin16",	812,	R8A779H0_CLK_S0D4_VIO),
 	DEF_MOD("vin17",	813,	R8A779H0_CLK_S0D4_VIO),
+	DEF_MOD("vspd0",	830,	R8A779H0_CLK_S0D1_VIO),
 	DEF_MOD("wdt1:wdt0",	907,	R8A779H0_CLK_R),
 	DEF_MOD("cmt0",		910,	R8A779H0_CLK_R),
 	DEF_MOD("cmt1",		911,	R8A779H0_CLK_R),

-- 
2.43.0

Re: [PATCH v3 05/10] clk: renesas: r8a779h0: Add display clocks

[Geert Uytterhoeven]

Hi Tomi,

On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>
> Add display related clocks for DU, DSI, FCPVD, and VSPD.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v6.14.

> --- a/drivers/clk/renesas/r8a779h0-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
> @@ -179,6 +179,9 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
>         DEF_MOD("canfd0",       328,    R8A779H0_CLK_SASYNCPERD2),
>         DEF_MOD("csi40",        331,    R8A779H0_CLK_CSI),
>         DEF_MOD("csi41",        400,    R8A779H0_CLK_CSI),
> +       DEF_MOD("dis0",         411,    R8A779H0_CLK_S0D3),
> +       DEF_MOD("dsitxlink0",   415,    R8A779H0_CLK_DSIREF),
> +       DEF_MOD("fcpvd0",       508,    R8A779H0_CLK_S0D3),
>         DEF_MOD("hscif0",       514,    R8A779H0_CLK_SASYNCPERD1),
>         DEF_MOD("hscif1",       515,    R8A779H0_CLK_SASYNCPERD1),
>         DEF_MOD("hscif2",       516,    R8A779H0_CLK_SASYNCPERD1),
> @@ -227,6 +230,7 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
>         DEF_MOD("vin15",        811,    R8A779H0_CLK_S0D4_VIO),
>         DEF_MOD("vin16",        812,    R8A779H0_CLK_S0D4_VIO),
>         DEF_MOD("vin17",        813,    R8A779H0_CLK_S0D4_VIO),
> +       DEF_MOD("vspd0",        830,    R8A779H0_CLK_S0D1_VIO),
>         DEF_MOD("wdt1:wdt0",    907,    R8A779H0_CLK_R),
>         DEF_MOD("cmt0",         910,    R8A779H0_CLK_R),
>         DEF_MOD("cmt1",         911,    R8A779H0_CLK_R),

As mentioned by Laurent during his review on v1, all clock parents
should probably be some form of R8A779H0_CLK_S0Dx_VIO.
So I'm inclined to replace all of them by R8A779H0_CLK_VIOBUSD2 while
applying, which would match R-Car V4H.

Are you OK with that?

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 v3 05/10] clk: renesas: r8a779h0: Add display clocks

[Tomi Valkeinen]

Hi,

On 06/12/2024 15:43, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>
>> Add display related clocks for DU, DSI, FCPVD, and VSPD.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-clk for v6.14.
> 
>> --- a/drivers/clk/renesas/r8a779h0-cpg-mssr.c
>> +++ b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
>> @@ -179,6 +179,9 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
>>          DEF_MOD("canfd0",       328,    R8A779H0_CLK_SASYNCPERD2),
>>          DEF_MOD("csi40",        331,    R8A779H0_CLK_CSI),
>>          DEF_MOD("csi41",        400,    R8A779H0_CLK_CSI),
>> +       DEF_MOD("dis0",         411,    R8A779H0_CLK_S0D3),
>> +       DEF_MOD("dsitxlink0",   415,    R8A779H0_CLK_DSIREF),
>> +       DEF_MOD("fcpvd0",       508,    R8A779H0_CLK_S0D3),
>>          DEF_MOD("hscif0",       514,    R8A779H0_CLK_SASYNCPERD1),
>>          DEF_MOD("hscif1",       515,    R8A779H0_CLK_SASYNCPERD1),
>>          DEF_MOD("hscif2",       516,    R8A779H0_CLK_SASYNCPERD1),
>> @@ -227,6 +230,7 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
>>          DEF_MOD("vin15",        811,    R8A779H0_CLK_S0D4_VIO),
>>          DEF_MOD("vin16",        812,    R8A779H0_CLK_S0D4_VIO),
>>          DEF_MOD("vin17",        813,    R8A779H0_CLK_S0D4_VIO),
>> +       DEF_MOD("vspd0",        830,    R8A779H0_CLK_S0D1_VIO),
>>          DEF_MOD("wdt1:wdt0",    907,    R8A779H0_CLK_R),
>>          DEF_MOD("cmt0",         910,    R8A779H0_CLK_R),
>>          DEF_MOD("cmt1",         911,    R8A779H0_CLK_R),
> 
> As mentioned by Laurent during his review on v1, all clock parents
> should probably be some form of R8A779H0_CLK_S0Dx_VIO.
> So I'm inclined to replace all of them by R8A779H0_CLK_VIOBUSD2 while
> applying, which would match R-Car V4H.

What do you mean with the above? First you say the clock parents should 
be some form of S0Dx_VIO, but then you say you'll use VIOBUSD2. Aren't 
those unrelated clocks, from different PLLs?

> Are you OK with that?

I'm fine with that. I can't really get much out of the docs wrt. 
clocking, and the clocks I used were from the BSP. Afaics, it looks 
similar to V4H, so it's probably best have the same clocks, as you suggest.

  Tomi

Re: [PATCH v3 05/10] clk: renesas: r8a779h0: Add display clocks

[Geert Uytterhoeven]

Hi Tomi,

On Mon, Dec 9, 2024 at 6:26 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> On 06/12/2024 15:43, Geert Uytterhoeven wrote:
> > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >>
> >> Add display related clocks for DU, DSI, FCPVD, and VSPD.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > i.e. will queue in renesas-clk for v6.14.
> >
> >> --- a/drivers/clk/renesas/r8a779h0-cpg-mssr.c
> >> +++ b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
> >> @@ -179,6 +179,9 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
> >>          DEF_MOD("canfd0",       328,    R8A779H0_CLK_SASYNCPERD2),
> >>          DEF_MOD("csi40",        331,    R8A779H0_CLK_CSI),
> >>          DEF_MOD("csi41",        400,    R8A779H0_CLK_CSI),
> >> +       DEF_MOD("dis0",         411,    R8A779H0_CLK_S0D3),
> >> +       DEF_MOD("dsitxlink0",   415,    R8A779H0_CLK_DSIREF),
> >> +       DEF_MOD("fcpvd0",       508,    R8A779H0_CLK_S0D3),
> >>          DEF_MOD("hscif0",       514,    R8A779H0_CLK_SASYNCPERD1),
> >>          DEF_MOD("hscif1",       515,    R8A779H0_CLK_SASYNCPERD1),
> >>          DEF_MOD("hscif2",       516,    R8A779H0_CLK_SASYNCPERD1),
> >> @@ -227,6 +230,7 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
> >>          DEF_MOD("vin15",        811,    R8A779H0_CLK_S0D4_VIO),
> >>          DEF_MOD("vin16",        812,    R8A779H0_CLK_S0D4_VIO),
> >>          DEF_MOD("vin17",        813,    R8A779H0_CLK_S0D4_VIO),
> >> +       DEF_MOD("vspd0",        830,    R8A779H0_CLK_S0D1_VIO),
> >>          DEF_MOD("wdt1:wdt0",    907,    R8A779H0_CLK_R),
> >>          DEF_MOD("cmt0",         910,    R8A779H0_CLK_R),
> >>          DEF_MOD("cmt1",         911,    R8A779H0_CLK_R),
> >
> > As mentioned by Laurent during his review on v1, all clock parents
> > should probably be some form of R8A779H0_CLK_S0Dx_VIO.
> > So I'm inclined to replace all of them by R8A779H0_CLK_VIOBUSD2 while
> > applying, which would match R-Car V4H.
>
> What do you mean with the above? First you say the clock parents should
> be some form of S0Dx_VIO, but then you say you'll use VIOBUSD2. Aren't
> those unrelated clocks, from different PLLs?

Oops, copy-'n-paste went wrong. I did mean R8A779H0_VIOBUSD*.

> > Are you OK with that?
>
> I'm fine with that. I can't really get much out of the docs wrt.
> clocking, and the clocks I used were from the BSP. Afaics, it looks
> similar to V4H, so it's probably best have the same clocks, as you suggest.

Agreed.

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 v3 05/10] clk: renesas: r8a779h0: Add display clocks

[Laurent Pinchart]

On Mon, Dec 09, 2024 at 08:49:18AM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 9, 2024 at 6:26 AM Tomi Valkeinen wrote:
> > On 06/12/2024 15:43, Geert Uytterhoeven wrote:
> > > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen wrote:
> > >> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > >>
> > >> Add display related clocks for DU, DSI, FCPVD, and VSPD.
> > >>
> > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > >> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > >> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > i.e. will queue in renesas-clk for v6.14.
> > >
> > >> --- a/drivers/clk/renesas/r8a779h0-cpg-mssr.c
> > >> +++ b/drivers/clk/renesas/r8a779h0-cpg-mssr.c
> > >> @@ -179,6 +179,9 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
> > >>          DEF_MOD("canfd0",       328,    R8A779H0_CLK_SASYNCPERD2),
> > >>          DEF_MOD("csi40",        331,    R8A779H0_CLK_CSI),
> > >>          DEF_MOD("csi41",        400,    R8A779H0_CLK_CSI),
> > >> +       DEF_MOD("dis0",         411,    R8A779H0_CLK_S0D3),
> > >> +       DEF_MOD("dsitxlink0",   415,    R8A779H0_CLK_DSIREF),
> > >> +       DEF_MOD("fcpvd0",       508,    R8A779H0_CLK_S0D3),
> > >>          DEF_MOD("hscif0",       514,    R8A779H0_CLK_SASYNCPERD1),
> > >>          DEF_MOD("hscif1",       515,    R8A779H0_CLK_SASYNCPERD1),
> > >>          DEF_MOD("hscif2",       516,    R8A779H0_CLK_SASYNCPERD1),
> > >> @@ -227,6 +230,7 @@ static const struct mssr_mod_clk r8a779h0_mod_clks[] __initconst = {
> > >>          DEF_MOD("vin15",        811,    R8A779H0_CLK_S0D4_VIO),
> > >>          DEF_MOD("vin16",        812,    R8A779H0_CLK_S0D4_VIO),
> > >>          DEF_MOD("vin17",        813,    R8A779H0_CLK_S0D4_VIO),
> > >> +       DEF_MOD("vspd0",        830,    R8A779H0_CLK_S0D1_VIO),
> > >>          DEF_MOD("wdt1:wdt0",    907,    R8A779H0_CLK_R),
> > >>          DEF_MOD("cmt0",         910,    R8A779H0_CLK_R),
> > >>          DEF_MOD("cmt1",         911,    R8A779H0_CLK_R),
> > >
> > > As mentioned by Laurent during his review on v1, all clock parents
> > > should probably be some form of R8A779H0_CLK_S0Dx_VIO.
> > > So I'm inclined to replace all of them by R8A779H0_CLK_VIOBUSD2 while
> > > applying, which would match R-Car V4H.
> >
> > What do you mean with the above? First you say the clock parents should
> > be some form of S0Dx_VIO, but then you say you'll use VIOBUSD2. Aren't
> > those unrelated clocks, from different PLLs?
> 
> Oops, copy-'n-paste went wrong. I did mean R8A779H0_VIOBUSD*.
> 
> > > Are you OK with that?
> >
> > I'm fine with that. I can't really get much out of the docs wrt.
> > clocking, and the clocks I used were from the BSP. Afaics, it looks
> > similar to V4H, so it's probably best have the same clocks, as you suggest.
> 
> Agreed.

Works for me too.

-- 
Regards,

Laurent Pinchart

[PATCH v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Add support for DSI on r8a779h0. As it is identical to DSI on r8a779g0,
all we need is to handle the compatible string.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
index 92f4261305bd..36e902601f84 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
@@ -1081,6 +1081,8 @@ static const struct rcar_mipi_dsi_device_info v4h_data = {
 static const struct of_device_id rcar_mipi_dsi_of_table[] = {
 	{ .compatible = "renesas,r8a779a0-dsi-csi2-tx", .data = &v3u_data },
 	{ .compatible = "renesas,r8a779g0-dsi-csi2-tx", .data = &v4h_data },
+	/* DSI in r8a779h0 is identical to r8a779g0 */
+	{ .compatible = "renesas,r8a779h0-dsi-csi2-tx", .data = &v4h_data },
 	{ }
 };
 

-- 
2.43.0

[PATCH v3 07/10] drm/rcar-du: Add support for r8a779h0

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Add support for r8a779h0. It is very similar to r8a779g0, but has only
one output.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c   | 18 ++++++++++++++++++
 drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c |  4 +++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
index fb719d9aff10..7858e10839f2 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
@@ -545,6 +545,23 @@ static const struct rcar_du_device_info rcar_du_r8a779g0_info = {
 	.dsi_clk_mask =  BIT(1) | BIT(0),
 };
 
+static const struct rcar_du_device_info rcar_du_r8a779h0_info = {
+	.gen = 4,
+	.features = RCAR_DU_FEATURE_CRTC_IRQ
+		  | RCAR_DU_FEATURE_VSP1_SOURCE
+		  | RCAR_DU_FEATURE_NO_BLENDING,
+	.channels_mask = BIT(0),
+	.routes = {
+		/* R8A779H0 has one MIPI DSI output. */
+		[RCAR_DU_OUTPUT_DSI0] = {
+			.possible_crtcs = BIT(0),
+			.port = 0,
+		},
+	},
+	.num_rpf = 5,
+	.dsi_clk_mask = BIT(0),
+};
+
 static const struct of_device_id rcar_du_of_table[] = {
 	{ .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info },
 	{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
@@ -571,6 +588,7 @@ static const struct of_device_id rcar_du_of_table[] = {
 	{ .compatible = "renesas,du-r8a77995", .data = &rcar_du_r8a7799x_info },
 	{ .compatible = "renesas,du-r8a779a0", .data = &rcar_du_r8a779a0_info },
 	{ .compatible = "renesas,du-r8a779g0", .data = &rcar_du_r8a779g0_info },
+	{ .compatible = "renesas,du-r8a779h0", .data = &rcar_du_r8a779h0_info },
 	{ }
 };
 
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
index 1ec806c8e013..068c106e586c 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
@@ -107,10 +107,12 @@ static void rcar_du_group_setup_didsr(struct rcar_du_group *rgrp)
 		 */
 		rcrtc = rcdu->crtcs;
 		num_crtcs = rcdu->num_crtcs;
-	} else if (rcdu->info->gen >= 3 && rgrp->num_crtcs > 1) {
+	} else if ((rcdu->info->gen == 3 && rgrp->num_crtcs > 1) ||
+		   rcdu->info->gen == 4) {
 		/*
 		 * On Gen3 dot clocks are setup through per-group registers,
 		 * only available when the group has two channels.
+		 * On Gen4 the registers are there for single channel too.
 		 */
 		rcrtc = &rcdu->crtcs[rgrp->index * 2];
 		num_crtcs = rgrp->num_crtcs;

-- 
2.43.0

[PATCH v3 08/10] arm64: dts: renesas: gray-hawk-single: Fix indentation

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Fix the indent on the two regulators.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 .../boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 24 +++++++++++-----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
index 9a1917b87f61..057f959d67b3 100644
--- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
+++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
@@ -127,21 +127,21 @@ memory@480000000 {
 	};
 
 	reg_1p8v: regulator-1p8v {
-			compatible = "regulator-fixed";
-			regulator-name = "fixed-1.8V";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-boot-on;
-			regulator-always-on;
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-1.8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-boot-on;
+		regulator-always-on;
 	};
 
 	reg_3p3v: regulator-3p3v {
-			compatible = "regulator-fixed";
-			regulator-name = "fixed-3.3V";
-			regulator-min-microvolt = <3300000>;
-			regulator-max-microvolt = <3300000>;
-			regulator-boot-on;
-			regulator-always-on;
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		regulator-always-on;
 	};
 
 	sound_mux: sound-mux {

-- 
2.43.0

Re: [PATCH v3 08/10] arm64: dts: renesas: gray-hawk-single: Fix indentation

[Geert Uytterhoeven]

On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>
> Fix the indent on the two regulators.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.14.

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 v3 09/10] arm64: dts: renesas: r8a779h0: Add display support

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Add the device nodes for supporting DU and DSI.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 arch/arm64/boot/dts/renesas/r8a779h0.dtsi | 73 +++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779h0.dtsi b/arch/arm64/boot/dts/renesas/r8a779h0.dtsi
index 12d8be3fd579..4f97c483fd4b 100644
--- a/arch/arm64/boot/dts/renesas/r8a779h0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779h0.dtsi
@@ -1828,6 +1828,50 @@ csi41isp1: endpoint {
 			};
 		};
 
+		fcpvd0: fcp@fea10000 {
+			compatible = "renesas,fcpv";
+			reg = <0 0xfea10000 0 0x200>;
+			clocks = <&cpg CPG_MOD 508>;
+			power-domains = <&sysc R8A779H0_PD_C4>;
+			resets = <&cpg 508>;
+		};
+
+		vspd0: vsp@fea20000 {
+			compatible = "renesas,vsp2";
+			reg = <0 0xfea20000 0 0x8000>;
+			interrupts = <GIC_SPI 546 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 830>;
+			power-domains = <&sysc R8A779H0_PD_C4>;
+			resets = <&cpg 830>;
+			renesas,fcp = <&fcpvd0>;
+		};
+
+		du: display@feb00000 {
+			compatible = "renesas,du-r8a779h0";
+			reg = <0 0xfeb00000 0 0x40000>;
+			interrupts = <GIC_SPI 523 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 411>;
+			clock-names = "du.0";
+			power-domains = <&sysc R8A779H0_PD_C4>;
+			resets = <&cpg 411>;
+			reset-names = "du.0";
+			renesas,vsps = <&vspd0 0>;
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+					du_out_dsi0: endpoint {
+						remote-endpoint = <&dsi0_in>;
+					};
+				};
+			};
+		};
+
 		isp0: isp@fed00000 {
 			compatible = "renesas,r8a779h0-isp",
 				     "renesas,rcar-gen4-isp";
@@ -1996,6 +2040,35 @@ isp1vin15: endpoint {
 			};
 		};
 
+		dsi0: dsi-encoder@fed80000 {
+			compatible = "renesas,r8a779h0-dsi-csi2-tx";
+			reg = <0 0xfed80000 0 0x10000>;
+			clocks = <&cpg CPG_MOD 415>,
+				 <&cpg CPG_CORE R8A779H0_CLK_DSIEXT>,
+				 <&cpg CPG_CORE R8A779H0_CLK_DSIREF>;
+			clock-names = "fck", "dsi", "pll";
+			power-domains = <&sysc R8A779H0_PD_C4>;
+			resets = <&cpg 415>;
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+					dsi0_in: endpoint {
+						remote-endpoint = <&du_out_dsi0>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
 		prr: chipid@fff00044 {
 			compatible = "renesas,prr";
 			reg = <0 0xfff00044 0 4>;

-- 
2.43.0

Re: [PATCH v3 09/10] arm64: dts: renesas: r8a779h0: Add display support

[Geert Uytterhoeven]

On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>
> Add the device nodes for supporting DU and DSI.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.14.

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 v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Tomi Valkeinen]

From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

Add support for the mini DP output on the Gray Hawk board.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 .../boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 95 ++++++++++++++++++++++
 1 file changed, 95 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
index 057f959d67b3..7cdf07b6dde6 100644
--- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
+++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
@@ -59,6 +59,12 @@ chosen {
 		stdout-path = "serial0:921600n8";
 	};
 
+	sn65dsi86_refclk: clk-x6 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <38400000>;
+	};
+
 	keys {
 		compatible = "gpio-keys";
 
@@ -126,6 +132,27 @@ memory@480000000 {
 		reg = <0x4 0x80000000 0x1 0x80000000>;
 	};
 
+	mini-dp-con {
+		compatible = "dp-connector";
+		label = "CN5";
+		type = "mini";
+
+		port {
+			mini_dp_con_in: endpoint {
+				remote-endpoint = <&sn65dsi86_out0>;
+			};
+		};
+	};
+
+	reg_1p2v: regulator-1p2v {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-1.2V";
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
 	reg_1p8v: regulator-1p8v {
 		compatible = "regulator-fixed";
 		regulator-name = "fixed-1.8V";
@@ -200,6 +227,24 @@ channel1 {
 	};
 };
 
+&dsi0 {
+	status = "okay";
+
+	ports {
+		port@1 {
+			reg = <1>;
+			dsi0_out: endpoint {
+				remote-endpoint = <&sn65dsi86_in0>;
+				data-lanes = <1 2 3 4>;
+			};
+		};
+	};
+};
+
+&du {
+	status = "okay";
+};
+
 &extal_clk {
 	clock-frequency = <16666666>;
 };
@@ -269,6 +314,51 @@ eeprom@53 {
 	};
 };
 
+&i2c1 {
+	pinctrl-0 = <&i2c1_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+	clock-frequency = <400000>;
+
+	bridge@2c {
+		compatible = "ti,sn65dsi86";
+		reg = <0x2c>;
+
+		clocks = <&sn65dsi86_refclk>;
+		clock-names = "refclk";
+
+		interrupt-parent = <&intc_ex>;
+		interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+		enable-gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+
+		vccio-supply = <&reg_1p8v>;
+		vpll-supply = <&reg_1p8v>;
+		vcca-supply = <&reg_1p2v>;
+		vcc-supply = <&reg_1p2v>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				sn65dsi86_in0: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				sn65dsi86_out0: endpoint {
+					remote-endpoint = <&mini_dp_con_in>;
+				};
+			};
+		};
+	};
+};
+
 &i2c3 {
 	pinctrl-0 = <&i2c3_pins>;
 	pinctrl-names = "default";
@@ -361,6 +451,11 @@ i2c0_pins: i2c0 {
 		function = "i2c0";
 	};
 
+	i2c1_pins: i2c1 {
+		groups = "i2c1";
+		function = "i2c1";
+	};
+
 	i2c3_pins: i2c3 {
 		groups = "i2c3";
 		function = "i2c3";

-- 
2.43.0

Re: [PATCH v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Geert Uytterhoeven]

Hi Tomi,

On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>
> Add support for the mini DP output on the Gray Hawk board.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
> @@ -269,6 +314,51 @@ eeprom@53 {
>         };
>  };
>
> +&i2c1 {
> +       pinctrl-0 = <&i2c1_pins>;
> +       pinctrl-names = "default";
> +
> +       status = "okay";
> +       clock-frequency = <400000>;
> +
> +       bridge@2c {

Missing:

        pinctrl-0 = <&irq0_pins>;
        pinctrl-names = "default";

> +               compatible = "ti,sn65dsi86";
> +               reg = <0x2c>;
> +
> +               clocks = <&sn65dsi86_refclk>;
> +               clock-names = "refclk";
> +
> +               interrupt-parent = <&intc_ex>;
> +               interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;

interrupts-extended = ...

> +
> +               enable-gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
> +
> +               vccio-supply = <&reg_1p8v>;
> +               vpll-supply = <&reg_1p8v>;
> +               vcca-supply = <&reg_1p2v>;
> +               vcc-supply = <&reg_1p2v>;
> +
> +               ports {
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +
> +                       port@0 {
> +                               reg = <0>;
> +                               sn65dsi86_in0: endpoint {
> +                                       remote-endpoint = <&dsi0_out>;
> +                               };
> +                       };
> +
> +                       port@1 {
> +                               reg = <1>;
> +                               sn65dsi86_out0: endpoint {
> +                                       remote-endpoint = <&mini_dp_con_in>;
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
>  &i2c3 {
>         pinctrl-0 = <&i2c3_pins>;
>         pinctrl-names = "default";
> @@ -361,6 +451,11 @@ i2c0_pins: i2c0 {
>                 function = "i2c0";
>         };
>
> +       i2c1_pins: i2c1 {
> +               groups = "i2c1";
> +               function = "i2c1";
> +       };
> +
>         i2c3_pins: i2c3 {
>                 groups = "i2c3";
>                 function = "i2c3";

Missing:

        irq0_pins: irq0 {
                groups = "intc_ex_irq0_a";
                function = "intc_ex";
        };

I'll fix that up while applying.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.14.

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 v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Tomi Valkeinen]

Hi,

On 10/12/2024 18:34, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>
>> Add support for the mini DP output on the Gray Hawk board.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> Thanks for your patch!
> 
>> --- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
>> @@ -269,6 +314,51 @@ eeprom@53 {
>>          };
>>   };
>>
>> +&i2c1 {
>> +       pinctrl-0 = <&i2c1_pins>;
>> +       pinctrl-names = "default";
>> +
>> +       status = "okay";
>> +       clock-frequency = <400000>;
>> +
>> +       bridge@2c {
> 
> Missing:
> 
>          pinctrl-0 = <&irq0_pins>;
>          pinctrl-names = "default";
> 
>> +               compatible = "ti,sn65dsi86";
>> +               reg = <0x2c>;
>> +
>> +               clocks = <&sn65dsi86_refclk>;
>> +               clock-names = "refclk";
>> +
>> +               interrupt-parent = <&intc_ex>;
>> +               interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> 
> interrupts-extended = ...

Is that just to use the same style in the whole dts, or is there some 
specific need for the extended one here?

>> +
>> +               enable-gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
>> +
>> +               vccio-supply = <&reg_1p8v>;
>> +               vpll-supply = <&reg_1p8v>;
>> +               vcca-supply = <&reg_1p2v>;
>> +               vcc-supply = <&reg_1p2v>;
>> +
>> +               ports {
>> +                       #address-cells = <1>;
>> +                       #size-cells = <0>;
>> +
>> +                       port@0 {
>> +                               reg = <0>;
>> +                               sn65dsi86_in0: endpoint {
>> +                                       remote-endpoint = <&dsi0_out>;
>> +                               };
>> +                       };
>> +
>> +                       port@1 {
>> +                               reg = <1>;
>> +                               sn65dsi86_out0: endpoint {
>> +                                       remote-endpoint = <&mini_dp_con_in>;
>> +                               };
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>>   &i2c3 {
>>          pinctrl-0 = <&i2c3_pins>;
>>          pinctrl-names = "default";
>> @@ -361,6 +451,11 @@ i2c0_pins: i2c0 {
>>                  function = "i2c0";
>>          };
>>
>> +       i2c1_pins: i2c1 {
>> +               groups = "i2c1";
>> +               function = "i2c1";
>> +       };
>> +
>>          i2c3_pins: i2c3 {
>>                  groups = "i2c3";
>>                  function = "i2c3";
> 
> Missing:
> 
>          irq0_pins: irq0 {
>                  groups = "intc_ex_irq0_a";
>                  function = "intc_ex";
>          };
> 
> I'll fix that up while applying.

Thanks!

  Tomi

> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-devel for v6.14.
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

Re: [PATCH v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Geert Uytterhoeven]

Hi Tomi,

On Tue, Dec 10, 2024 at 7:10 PM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:

> On 10/12/2024 18:34, Geert Uytterhoeven wrote:
> > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >>
> >> Add support for the mini DP output on the Gray Hawk board.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks for your patch!
> >
> >> --- a/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts
> >> +++ b/arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts

> >> +               compatible = "ti,sn65dsi86";
> >> +               reg = <0x2c>;
> >> +
> >> +               clocks = <&sn65dsi86_refclk>;
> >> +               clock-names = "refclk";
> >> +
> >> +               interrupt-parent = <&intc_ex>;
> >> +               interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> >
> > interrupts-extended = ...
>
> Is that just to use the same style in the whole dts, or is there some
> specific need for the extended one here?

There is no real technical need to use the extended one, but it is
more concise. That's why we just converted all such cases in Renesas
DTS files in v6.13-rc1.

And of course it reduces the difference between
arch/arm64/boot/dts/renesas/white-hawk-cpu-common.dtsi and
arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts.

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 v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Geert Uytterhoeven]

Hi Tomi,

On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>
> Add support for the mini DP output on the Gray Hawk board.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Thanks for your patch, which is now commit b1000645dc29701f
("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
in renesas-devel/renesas-dts-for-v6.14.

Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
is not available, the ti_sn65dsi86.bridge part fails to probe with
-EPROBE_DEFER and "failed to attach dsi host".  Still, the sn65dsi86
driver must do something critical, as resuming from s2idle now hangs.
I haven't identified yet where exactly it hangs.

As a result, s2idle is broken in current renesas-devel, which only
has the DTS changes.  Perhaps I should drop the DTS until the issue
is resolved?

However, I suspect White Hawk has the same issue (if
CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
Hawk is currently not available for kernel testing.

Do you have a clue?
Thanks!

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 v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Tomi Valkeinen]

Hi,

On 16/12/2024 15:33, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>
>> Add support for the mini DP output on the Gray Hawk board.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
> Thanks for your patch, which is now commit b1000645dc29701f
> ("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
> in renesas-devel/renesas-dts-for-v6.14.
> 
> Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
> v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
> when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
> is not available, the ti_sn65dsi86.bridge part fails to probe with
> -EPROBE_DEFER and "failed to attach dsi host".  Still, the sn65dsi86
> driver must do something critical, as resuming from s2idle now hangs.
> I haven't identified yet where exactly it hangs.
> > As a result, s2idle is broken in current renesas-devel, which only
> has the DTS changes.  Perhaps I should drop the DTS until the issue
> is resolved?

I'm fine with that. The DT bindings are still under work anyway.

> However, I suspect White Hawk has the same issue (if
> CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
> Hawk is currently not available for kernel testing.

I can reproduce on White Hawk. And I agree that it's probably related to 
sn65dsi86.

I use modules, so I tried dropping modules to see when the issue goes 
away. And it's always sn65dsi86. So without the rcar DRM & DSI modules 
loaded, if I load or don't load sn65dsi86, I see or don't see the hang, 
respectively.

Even if I drop the ti_sn65dsi86_pm_ops, it doesn't help. And looks like 
just doing the i2c_add_driver() part in ti_sn65dsi86_init() will cause 
the issue, so it's something that happens there.

I'll continue the debug later.

  Tomi

Re: [PATCH v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Tomi Valkeinen]

Hi,

On 16/12/2024 17:15, Tomi Valkeinen wrote:
> Hi,
> 
> On 16/12/2024 15:33, Geert Uytterhoeven wrote:
>> Hi Tomi,
>>
>> On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com> wrote:
>>> From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>>
>>> Add support for the mini DP output on the Gray Hawk board.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
>>> Reviewed-by: Laurent Pinchart 
>>> <laurent.pinchart+renesas@ideasonboard.com>
>>> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> Thanks for your patch, which is now commit b1000645dc29701f
>> ("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
>> in renesas-devel/renesas-dts-for-v6.14.
>>
>> Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
>> v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
>> when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
>> is not available, the ti_sn65dsi86.bridge part fails to probe with
>> -EPROBE_DEFER and "failed to attach dsi host".  Still, the sn65dsi86
>> driver must do something critical, as resuming from s2idle now hangs.
>> I haven't identified yet where exactly it hangs.
>> > As a result, s2idle is broken in current renesas-devel, which only
>> has the DTS changes.  Perhaps I should drop the DTS until the issue
>> is resolved?
> 
> I'm fine with that. The DT bindings are still under work anyway.
> 
>> However, I suspect White Hawk has the same issue (if
>> CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
>> Hawk is currently not available for kernel testing.
> 
> I can reproduce on White Hawk. And I agree that it's probably related to 
> sn65dsi86.
> 
> I use modules, so I tried dropping modules to see when the issue goes 
> away. And it's always sn65dsi86. So without the rcar DRM & DSI modules 
> loaded, if I load or don't load sn65dsi86, I see or don't see the hang, 
> respectively.
> 
> Even if I drop the ti_sn65dsi86_pm_ops, it doesn't help. And looks like 
> just doing the i2c_add_driver() part in ti_sn65dsi86_init() will cause 
> the issue, so it's something that happens there.
> 
> I'll continue the debug later.

I wrote a minimal kernel module that has an i2c driver that does 
nothing, using ti,sn65dsi86 as the compatible string. I can still see 
the hang with that driver (i.e. no DRM drivers loaded at all). So it's 
not an issue in the driver.

I didn't really figure anything out, but I did notice that if I comment 
the following lines from the dts, the problem goes away:

		interrupt-parent = <&intc_ex>;
		interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;

		enable-gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;

		vccio-supply = <&reg_1p8v>;
		vpll-supply = <&reg_1p8v>;
		vcca-supply = <&reg_1p2v>;
		vcc-supply = <&reg_1p2v>;

  Tomi

Re: [PATCH v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Geert Uytterhoeven]

On Mon, Dec 16, 2024 at 2:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
> > From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >
> > Add support for the mini DP output on the Gray Hawk board.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks for your patch, which is now commit b1000645dc29701f
> ("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
> in renesas-devel/renesas-dts-for-v6.14.
>
> Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
> v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
> when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
> is not available, the ti_sn65dsi86.bridge part fails to probe with
> -EPROBE_DEFER and "failed to attach dsi host".  Still, the sn65dsi86
> driver must do something critical, as resuming from s2idle now hangs.
> I haven't identified yet where exactly it hangs.
>
> As a result, s2idle is broken in current renesas-devel, which only
> has the DTS changes.  Perhaps I should drop the DTS until the issue
> is resolved?
>
> However, I suspect White Hawk has the same issue (if
> CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
> Hawk is currently not available for kernel testing.

Confirmed on White Hawk by Tomi and me.

When the hang occurs, magic sysrq no longer works. However, the system
still prints "nfs server not responding" once in a while, so I added
calls to various sysrq print functions to rpc_check_timeout().
This revealed that the system is blocked on wait_for_completion()
in dpm_wait_for_superior(), called from device_resume_noirq().
Printing the actual device and parent gives:

    platform fed80000.dsi-encoder: PM: device_resume_noirq
    platform fed80000.dsi-encoder: PM: dpm_wait_for_superior: parent
fed80000.dsi-encoder

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 v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

[Geert Uytterhoeven]

CC Saravana

On Tue, Dec 17, 2024 at 2:29 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Dec 16, 2024 at 2:33 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> > > From: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > >
> > > Add support for the mini DP output on the Gray Hawk board.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks for your patch, which is now commit b1000645dc29701f
> > ("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
> > in renesas-devel/renesas-dts-for-v6.14.
> >
> > Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
> > v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
> > when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
> > is not available, the ti_sn65dsi86.bridge part fails to probe with
> > -EPROBE_DEFER and "failed to attach dsi host".  Still, the sn65dsi86
> > driver must do something critical, as resuming from s2idle now hangs.
> > I haven't identified yet where exactly it hangs.
> >
> > As a result, s2idle is broken in current renesas-devel, which only
> > has the DTS changes.  Perhaps I should drop the DTS until the issue
> > is resolved?
> >
> > However, I suspect White Hawk has the same issue (if
> > CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
> > Hawk is currently not available for kernel testing.
>
> Confirmed on White Hawk by Tomi and me.
>
> When the hang occurs, magic sysrq no longer works. However, the system
> still prints "nfs server not responding" once in a while, so I added
> calls to various sysrq print functions to rpc_check_timeout().
> This revealed that the system is blocked on wait_for_completion()
> in dpm_wait_for_superior(), called from device_resume_noirq().
> Printing the actual device and parent gives:
>
>     platform fed80000.dsi-encoder: PM: device_resume_noirq
>     platform fed80000.dsi-encoder: PM: dpm_wait_for_superior: parent fed80000.dsi-encoder

So it's waiting for itself, i.e. deadlock :-(

When the DSI driver is available:

    rcar-mipi-dsi fed80000.dsi-encoder: PM: device_resume_noirq:627
    rcar-mipi-dsi fed80000.dsi-encoder: PM: dpm_wait_for_superior:280
    rcar-mipi-dsi fed80000.dsi-encoder: PM: dpm_wait_for_superior:296:
parent fed80000.dsi-encoder

still waiting for itself, but it does continue!
Note that the fed80000.dsi-encoder block is now bound, and
"rcar-mipi-dsi" is printed instead of "platform".

fw_devlink issue?

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