RE: [PATCH 01/16] dt-bindings: display: bridge: renesas,dsi: Document RZ/G3L

Hi Krzysztof Kozlowski/Geert,

> -----Original Message-----
> From: Biju Das
> Sent: 24 July 2026 10:33
> Subject: RE: [PATCH 01/16] dt-bindings: display: bridge: renesas,dsi: Document RZ/G3L
> 
> Hi Krzysztof Kozlowski,
> 
> > -----Original Message-----
> > From: Krzysztof Kozlowski <[email protected]>
> > Sent: 12 July 2026 16:24
> > Subject: Re: [PATCH 01/16] dt-bindings: display: bridge: renesas,dsi:
> > Document RZ/G3L
> >
> > On Wed, Jul 08, 2026 at 09:39:01AM +0000, Biju Das wrote:
> > > Hi Krzysztof Kozlowski,
> > >
> > > Thanks for the feedback.
> > >
> > > > -----Original Message-----
> > > > From: Krzysztof Kozlowski <[email protected]>
> > > > 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:
> > > > > From: Biju Das <[email protected]>
> > > > >
> > > > > 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 <[email protected]>
> > > > > ---
> > > > >  .../bindings/display/bridge/renesas,dsi.yaml      | 15 +++++++++++++++
> > > > >  1 file changed, 15 insertions(+)
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.y
> > > > > am
> > > > > l
> > > > > b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.y
> > > > > am l index c20625b8425e..b114ac3b111a 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.y
> > > > > am
> > > > > l
> > > > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,d
> > > > > +++ si
> > > > > +++ .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.
> 
> Can you please provide some pointers for the binding and other stuff to model this as power sequence
> driver?
> 
> SYSC driver has PWRRDY register (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/tree/drivers/soc/renesas/r9a08g046-sysc.c?h=next-20260723#n28)
> 
> It Controls PWRRDY terminal of USB, DSI and CSI
> 0: PWRRDY
> 1: PWRRDY down
> 
> You mean Power sequence has a handle to sysc IP. Please let me know.
> 
> There is no other resource apart from phandle to SYSC.
> 
>     sys-power-ready {
>         compatible = "renesas, r9a08g046-sys=pwrrdy";
> 	  renesas,sysc-pwrrdy = <&sysc 0xd70>;
>     };
> 
>    phyrst: usbphy-ctrl@11e00000 {
> 			compatible = "renesas,r9a08g046-usbphy-ctrl";
> 			reg = <0 0x11e00000 0 0x10000>;
> 
> 			phyrst-power-sequence = <&sys-power-ready 1>;
>    }
> 
>     dsi: dsi@10850000 {
> 			compatible = "renesas,r9a08g046-mipi-dsi";
> 			reg = <0 0x10850000 0 0x20000>;
> 
> 			dsi-power-sequence = <&sys-power-ready 2>;
>    }
> 
> Currently it is modelled as,
> 
>    phyrst: usbphy-ctrl@11e00000 {
> 			compatible = "renesas,r9a08g046-usbphy-ctrl";
> 			reg = <0 0x11e00000 0 0x10000>;
> 
> 			renesas,sysc-pwrrdy = <&sysc 0xd70 1>;
>    }
> 
>    dsi: dsi@10850000 {
> 			compatible = "renesas,r9a08g046-mipi-dsi";
> 			reg = <0 0x10850000 0 0x20000>;
> 
> 			renesas,sysc-pwrrdy = <&sysc 0xd70 2>;
>    }


What about

RZ/SYSC driver instantiate RZ/G3L power sequence auxiliary driver and
DSI driver uses the Power sequence driver to control the power ready signal?

In that case renesas,sysc-pwrrdy may not be needed. The power sequence driver
should get regmap from parent and use that one for controlling the pwrrdy signals.

Cheers,
Biju