On Wed, Jul 08, 2026 at 09:39:01AM +0000, Biju Das wrote:

Hi Krzysztof Kozlowski,

Thanks for the feedback.

quoted

-----Original Message-----
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: 08 July 2026 09:30
Subject: Re: [PATCH 01/16] dt-bindings: display: bridge: renesas,dsi: Document RZ/G3L

On Sat, Jul 04, 2026 at 10:34:11AM +0100, Biju wrote:

quoted

From: Biju Das <biju.das.jz@bp.renesas.com>

The RZ/G3L DSI IP is similar to the RZ/G2L but has different global
PHY timings and also the PLLCLK is ungateble clock. Add the compatible
string "renesas,r9a08g046-mipi-dsi" to handle these difference for the
Renesas RZ/G3L SoC. The power to DSI region is controlled by SYSC block.
Document renesas,sysc-pwrrdy property to handle the power control.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
 .../bindings/display/bridge/renesas,dsi.yaml      | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
index c20625b8425e..b114ac3b111a 100644
---
a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml

+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yam
+++ l

@@ -28,6 +28,7 @@ properties:
           - const: renesas,r9a09g057-mipi-dsi

       - enum:
+          - renesas,r9a08g046-mipi-dsi # RZ/G3L
           - renesas,r9a09g057-mipi-dsi # RZ/V2H(P)

   reg:

@@ -108,6 +109,20 @@ properties:
   power-domains:
     maxItems: 1

+  renesas,sysc-pwrrdy:
+    description:
+      The system controller PWRRDY indicates to the DSI region, if the power
+      supply is ready. PWRRDY needs to be set during power-on before applying
+      any other settings. It also needs to be set before powering off the DSI.
+    $ref: /schemas/types.yaml#/definitions/phandle-array

This feels a lot like a power domain. Please elaborate what is PWRRDY and why power-on/off and power
status within SoC (important!) is not encoded as power domain.

We already tried modelling signal as power domain in RZ/G3S and finally Ulf
agreed that it cannot be power-domain[1]

" SYSC signal seems best to be modelled as a reset.
Although, it looks like the USB PM domain provider should rather be
the consumer of that reset, instead of having the reset being consumed
by the consumers of the USB PM domain."

Then Phillip proposed power sequencing driver[2] and finally he and Rob ok for the 
solution [3] 

The problem is that you did not implement or reference here power
sequencing. You created phandle without corresponding any hardware
signal and used "driver" as an argument.

power sequencing does not mean you can stuff random phandles here and
there.

Best regards,
Krzysztof