[PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Hi,

Series adds initial USB support for the Renesas RZ/G3S SoC.

Series is split as follows:

- patch 01/16		- add clock reset and power domain support for USB
- patch 02-04/16	- add reset control support for a USB signal
			  that need to be controlled before/after
			  the power to USB area is turned on/off.
			  
			  Philipp, Ulf, Geert, all,
			  
			  I detailed my approach for this in patch
			  04/16, please have a look and let me know
			  your input.
			  
			  Thank you!

- patch 05/16		- moves SoC identification to SYSC driver
- patch 06-08/16	- updates USB PHY control driver for USB
			  support
- patch 09/16		- update documentation for USBHS
- patch 10-12/16	- updates the USB PHY driver for USB support
- patch 13-15/16	- updates the device tree with USB support
- patch 16/16		- enables the reset control driver

Thank you,
Claudiu Beznea

Claudiu Beznea (16):
  clk: renesas: r9a08g045: Add clocks, resets and power domains for USB
  dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for
    RZ/G3S
  dt-bindings: reset: renesas,r9a08g045-sysc: Add reset IDs for RZ/G3S
    SYSC reset
  soc: renesas: Add SYSC driver for Renesas RZ/G3S
  soc: renesas: sysc: Move RZ/G3S SoC detection on SYSC driver
  dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S SoC
  reset: rzg2l-usbphy-ctrl: Get reset control array
  reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
  dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC
  phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
  dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings
  phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC
  arm64: dts: renesas: Add #reset-cells to system controller node
  arm64: dts: renesas: r9a08g045: Add USB support
  arm64: dts: renesas: rzg3s-smarc: Enable USB support
  arm64: defconfig: Enable RZ/G3S SYSC reset driver

 .../bindings/phy/renesas,usb2-phy.yaml        |   4 +-
 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      |  35 +++-
 .../soc/renesas/renesas,rzg2l-sysc.yaml       |  16 ++
 .../bindings/usb/renesas,usbhs.yaml           |   2 +
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi    | 120 +++++++++++++
 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi  |  61 +++++++
 arch/arm64/configs/defconfig                  |   1 +
 drivers/clk/renesas/r9a08g045-cpg.c           |  17 ++
 drivers/phy/renesas/phy-rcar-gen3-usb2.c      |  60 ++++++-
 drivers/reset/Kconfig                         |   7 +
 drivers/reset/Makefile                        |   1 +
 drivers/reset/reset-rzg2l-usbphy-ctrl.c       |   3 +-
 drivers/reset/reset-rzg3s-sysc.c              | 140 ++++++++++++++++
 drivers/soc/renesas/Makefile                  |   1 +
 drivers/soc/renesas/renesas-soc.c             |  12 --
 drivers/soc/renesas/rzg3s-sysc.c              | 158 ++++++++++++++++++
 .../reset/renesas,r9a08g045-sysc.h            |  10 ++
 include/linux/soc/renesas/rzg3s-sysc-reset.h  |  24 +++
 18 files changed, 648 insertions(+), 24 deletions(-)
 create mode 100644 drivers/reset/reset-rzg3s-sysc.c
 create mode 100644 drivers/soc/renesas/rzg3s-sysc.c
 create mode 100644 include/dt-bindings/reset/renesas,r9a08g045-sysc.h
 create mode 100644 include/linux/soc/renesas/rzg3s-sysc-reset.h

-- 
2.39.2

[PATCH 01/16] clk: renesas: r9a08g045: Add clocks, resets and power domains for USB

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add clocks, resets and power domains for USB modules available on the
Renesas RZ/G3S SoC.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/clk/renesas/r9a08g045-cpg.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/clk/renesas/r9a08g045-cpg.c b/drivers/clk/renesas/r9a08g045-cpg.c
index a891bfc3ab5a..6e9529678307 100644
--- a/drivers/clk/renesas/r9a08g045-cpg.c
+++ b/drivers/clk/renesas/r9a08g045-cpg.c
@@ -207,6 +207,10 @@ static const struct rzg2l_mod_clk r9a08g045_mod_clks[] = {
 	DEF_MOD("sdhi2_imclk2",		R9A08G045_SDHI2_IMCLK2, CLK_SD2_DIV4, 0x554, 9),
 	DEF_MOD("sdhi2_clk_hs",		R9A08G045_SDHI2_CLK_HS, R9A08G045_CLK_SD2, 0x554, 10),
 	DEF_MOD("sdhi2_aclk",		R9A08G045_SDHI2_ACLK, R9A08G045_CLK_P1, 0x554, 11),
+	DEF_MOD("usb0_host",		R9A08G045_USB_U2H0_HCLK, R9A08G045_CLK_P1, 0x578, 0),
+	DEF_MOD("usb1_host",		R9A08G045_USB_U2H1_HCLK, R9A08G045_CLK_P1, 0x578, 1),
+	DEF_MOD("usb0_func",		R9A08G045_USB_U2P_EXR_CPUCLK, R9A08G045_CLK_P1, 0x578, 2),
+	DEF_MOD("usb_pclk",		R9A08G045_USB_PCLK, R9A08G045_CLK_P1, 0x578, 3),
 	DEF_COUPLED("eth0_axi",		R9A08G045_ETH0_CLK_AXI, R9A08G045_CLK_M0, 0x57c, 0),
 	DEF_COUPLED("eth0_chi",		R9A08G045_ETH0_CLK_CHI, R9A08G045_CLK_ZT, 0x57c, 0),
 	DEF_MOD("eth0_refclk",		R9A08G045_ETH0_REFCLK, R9A08G045_CLK_HP, 0x57c, 8),
@@ -230,6 +234,10 @@ static const struct rzg2l_reset r9a08g045_resets[] = {
 	DEF_RST(R9A08G045_SDHI0_IXRST, 0x854, 0),
 	DEF_RST(R9A08G045_SDHI1_IXRST, 0x854, 1),
 	DEF_RST(R9A08G045_SDHI2_IXRST, 0x854, 2),
+	DEF_RST(R9A08G045_USB_U2H0_HRESETN, 0x878, 0),
+	DEF_RST(R9A08G045_USB_U2H1_HRESETN, 0x878, 1),
+	DEF_RST(R9A08G045_USB_U2P_EXL_SYSRST, 0x878, 2),
+	DEF_RST(R9A08G045_USB_PRESETN, 0x878, 3),
 	DEF_RST(R9A08G045_ETH0_RST_HW_N, 0x87c, 0),
 	DEF_RST(R9A08G045_ETH1_RST_HW_N, 0x87c, 1),
 	DEF_RST(R9A08G045_I2C0_MRST, 0x880, 0),
@@ -277,6 +285,15 @@ static const struct rzg2l_cpg_pm_domain_init_data r9a08g045_pm_domains[] = {
 	DEF_PD("sdhi2",		R9A08G045_PD_SDHI2,
 				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(11)),
 				RZG2L_PD_F_NONE),
+	DEF_PD("usb0",		R9A08G045_PD_USB0,
+				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, GENMASK(6, 5)),
+				RZG2L_PD_F_NONE),
+	DEF_PD("usb1",		R9A08G045_PD_USB1,
+				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(7)),
+				RZG2L_PD_F_NONE),
+	DEF_PD("usb-phy",	R9A08G045_PD_USB_PHY,
+				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(4)),
+				RZG2L_PD_F_NONE),
 	DEF_PD("eth0",		R9A08G045_PD_ETHER0,
 				DEF_REG_CONF(CPG_BUS_PERI_COM_MSTOP, BIT(2)),
 				RZG2L_PD_F_NONE),
-- 
2.39.2

Re: [PATCH 01/16] clk: renesas: r9a08g045: Add clocks, resets and power domains for USB

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Add clocks, resets and power domains for USB modules available on the
> Renesas RZ/G3S SoC.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

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

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 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The RZ/G3S System controller has registers to control signals that need
to be de-asserted/asserted before/after different SoC areas are power
on/off. This signals are implemented as reset signals. For this document
the #reset-cells property.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
index 4386b2c3fa4d..6b0bb34485d9 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
@@ -42,12 +42,28 @@ properties:
       - const: cm33stbyr_int
       - const: ca55_deny
 
+  "#reset-cells":
+    const: 1
+
 required:
   - compatible
   - reg
 
 additionalProperties: false
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g045-sysc
+    then:
+      required:
+        - "#reset-cells"
+    else:
+      properties:
+        "#reset-cells": false
+
 examples:
   - |
     #include <dt-bindings/interrupt-controller/arm-gic.h>
-- 
2.39.2

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> The RZ/G3S System controller has registers to control signals that need
> to be de-asserted/asserted before/after different SoC areas are power
> on/off. This signals are implemented as reset signals. For this document
> the #reset-cells property.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> index 4386b2c3fa4d..6b0bb34485d9 100644
> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> @@ -42,12 +42,28 @@ properties:
>        - const: cm33stbyr_int
>        - const: ca55_deny
>  
> +  "#reset-cells":
> +    const: 1
> +
>  required:
>    - compatible
>    - reg
>  
>  additionalProperties: false
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r9a08g045-sysc
> +    then:
> +      required:
> +        - "#reset-cells"

Given this is new required property on an existing platform, I'd expect
some mention of why it used to be okay to not have this but is now
required. Did firmware or a bootloader stage take things out of reset?

> +    else:
> +      properties:
> +        "#reset-cells": false
> +
>  examples:
>    - |
>      #include <dt-bindings/interrupt-controller/arm-gic.h>
> -- 
> 2.39.2
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

On Thu, Aug 22, 2024 at 05:42:57PM +0100, Conor Dooley wrote:
> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > 
> > The RZ/G3S System controller has registers to control signals that need
> > to be de-asserted/asserted before/after different SoC areas are power
> > on/off. This signals are implemented as reset signals. For this document
> > the #reset-cells property.
> > 
> > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > ---
> >  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> > index 4386b2c3fa4d..6b0bb34485d9 100644
> > --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> > +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> > @@ -42,12 +42,28 @@ properties:
> >        - const: cm33stbyr_int
> >        - const: ca55_deny
> >  
> > +  "#reset-cells":
> > +    const: 1
> > +
> >  required:
> >    - compatible
> >    - reg
> >  
> >  additionalProperties: false
> >  
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: renesas,r9a08g045-sysc
> > +    then:
> > +      required:
> > +        - "#reset-cells"
> 
> Given this is new required property on an existing platform, I'd expect
> some mention of why it used to be okay to not have this but is now
> required. Did firmware or a bootloader stage take things out of reset?

Reading a bit more into the series, the peripherals in question were
just never used nor did a driver for the sysc exist, so there's neither
explanation of prior behaviour nor concerns about compatibility?

> 
> > +    else:
> > +      properties:
> > +        "#reset-cells": false
> > +
> >  examples:
> >    - |
> >      #include <dt-bindings/interrupt-controller/arm-gic.h>
> > -- 
> > 2.39.2
> > 



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[claudiu beznea]

On 22.08.2024 19:44, Conor Dooley wrote:
> On Thu, Aug 22, 2024 at 05:42:57PM +0100, Conor Dooley wrote:
>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>
>>> The RZ/G3S System controller has registers to control signals that need
>>> to be de-asserted/asserted before/after different SoC areas are power
>>> on/off. This signals are implemented as reset signals. For this document
>>> the #reset-cells property.
>>>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>> ---
>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>> index 4386b2c3fa4d..6b0bb34485d9 100644
>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>> @@ -42,12 +42,28 @@ properties:
>>>        - const: cm33stbyr_int
>>>        - const: ca55_deny
>>>  
>>> +  "#reset-cells":
>>> +    const: 1
>>> +
>>>  required:
>>>    - compatible
>>>    - reg
>>>  
>>>  additionalProperties: false
>>>  
>>> +allOf:
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: renesas,r9a08g045-sysc
>>> +    then:
>>> +      required:
>>> +        - "#reset-cells"
>>
>> Given this is new required property on an existing platform, I'd expect
>> some mention of why it used to be okay to not have this but is now
>> required. Did firmware or a bootloader stage take things out of reset?
> 
> Reading a bit more into the series, the peripherals in question were
> just never used nor did a driver for the sysc exist, so there's neither

Exactly.

> explanation of prior behaviour nor concerns about compatibility?

The newly introduced sysc driver is probed only for RZ/G3S and used to
control the USB, PCIe signals though reset control driver (registered by
sysc driver on auxiliary bus) and to identify the chip. The intention is to
later migrate the chip identification support for the rest of RZ/G2 devices
to this new driver and add more functionalities, when/if needed.

Thank you,
Claudiu Beznea

> 
>>
>>> +    else:
>>> +      properties:
>>> +        "#reset-cells": false
>>> +
>>>  examples:
>>>    - |
>>>      #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> -- 
>>> 2.39.2
>>>
> 
> 

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[claudiu beznea]

Hi, Conor,

On 22.08.2024 19:42, Conor Dooley wrote:
> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The RZ/G3S System controller has registers to control signals that need
>> to be de-asserted/asserted before/after different SoC areas are power
>> on/off. This signals are implemented as reset signals. For this document
>> the #reset-cells property.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>> index 4386b2c3fa4d..6b0bb34485d9 100644
>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>> @@ -42,12 +42,28 @@ properties:
>>        - const: cm33stbyr_int
>>        - const: ca55_deny
>>  
>> +  "#reset-cells":
>> +    const: 1
>> +
>>  required:
>>    - compatible
>>    - reg
>>  
>>  additionalProperties: false
>>  
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: renesas,r9a08g045-sysc
>> +    then:
>> +      required:
>> +        - "#reset-cells"
> 
> Given this is new required property on an existing platform, I'd expect
> some mention of why it used to be okay to not have this but is now
> required. Did firmware or a bootloader stage take things out of reset?

On previous SoCs the SYS controller has no support for controlling the
signals going to different peripherals (USB, PCIE in case of RZ/G3S).
I'll add a note about this on next version.

Thank you,
Claudiu Beznea


> 
>> +    else:
>> +      properties:
>> +        "#reset-cells": false
>> +
>>  examples:
>>    - |
>>      #include <dt-bindings/interrupt-controller/arm-gic.h>
>> -- 
>> 2.39.2
>>

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
> Hi, Conor,
> 
> On 22.08.2024 19:42, Conor Dooley wrote:
> > On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> The RZ/G3S System controller has registers to control signals that need
> >> to be de-asserted/asserted before/after different SoC areas are power
> >> on/off. This signals are implemented as reset signals. For this document
> >> the #reset-cells property.
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >> ---
> >>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >>  1 file changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >> index 4386b2c3fa4d..6b0bb34485d9 100644
> >> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >> @@ -42,12 +42,28 @@ properties:
> >>        - const: cm33stbyr_int
> >>        - const: ca55_deny
> >>  
> >> +  "#reset-cells":
> >> +    const: 1
> >> +
> >>  required:
> >>    - compatible
> >>    - reg
> >>  
> >>  additionalProperties: false
> >>  
> >> +allOf:
> >> +  - if:
> >> +      properties:
> >> +        compatible:
> >> +          contains:
> >> +            const: renesas,r9a08g045-sysc
> >> +    then:
> >> +      required:
> >> +        - "#reset-cells"
> > 
> > Given this is new required property on an existing platform, I'd expect
> > some mention of why it used to be okay to not have this but is now
> > required. Did firmware or a bootloader stage take things out of reset?
> 
> On previous SoCs the SYS controller has no support for controlling the
> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
> I'll add a note about this on next version.

My initial thought here wasn't about previous SoCs though, it was
because you didn't add the compatible in this series for /this/ SoC.
What's worth noting isn't about the prior SoCs, it is about what makes
it okay for this one.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[claudiu beznea]

On 23.08.2024 19:18, Conor Dooley wrote:
> On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
>> Hi, Conor,
>>
>> On 22.08.2024 19:42, Conor Dooley wrote:
>>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>
>>>> The RZ/G3S System controller has registers to control signals that need
>>>> to be de-asserted/asserted before/after different SoC areas are power
>>>> on/off. This signals are implemented as reset signals. For this document
>>>> the #reset-cells property.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>> ---
>>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>>>  1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>> index 4386b2c3fa4d..6b0bb34485d9 100644
>>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>> @@ -42,12 +42,28 @@ properties:
>>>>        - const: cm33stbyr_int
>>>>        - const: ca55_deny
>>>>  
>>>> +  "#reset-cells":
>>>> +    const: 1
>>>> +
>>>>  required:
>>>>    - compatible
>>>>    - reg
>>>>  
>>>>  additionalProperties: false
>>>>  
>>>> +allOf:
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            const: renesas,r9a08g045-sysc
>>>> +    then:
>>>> +      required:
>>>> +        - "#reset-cells"
>>>
>>> Given this is new required property on an existing platform, I'd expect
>>> some mention of why it used to be okay to not have this but is now
>>> required. Did firmware or a bootloader stage take things out of reset?
>>
>> On previous SoCs the SYS controller has no support for controlling the
>> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
>> I'll add a note about this on next version.
> 
> My initial thought here wasn't about previous SoCs though, it was
> because you didn't add the compatible in this series for /this/ SoC.

RZ/G3S compatible is already present in this file:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26

Thank you,
Claudiu Beznea

> What's worth noting isn't about the prior SoCs, it is about what makes
> it okay for this one.

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]

On Fri, Aug 23, 2024 at 07:26:42PM +0300, claudiu beznea wrote:
> On 23.08.2024 19:18, Conor Dooley wrote:
> > On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
> >> Hi, Conor,
> >>
> >> On 22.08.2024 19:42, Conor Dooley wrote:
> >>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> >>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>
> >>>> The RZ/G3S System controller has registers to control signals that need
> >>>> to be de-asserted/asserted before/after different SoC areas are power
> >>>> on/off. This signals are implemented as reset signals. For this document
> >>>> the #reset-cells property.
> >>>>
> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>> ---
> >>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >>>>  1 file changed, 16 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>> index 4386b2c3fa4d..6b0bb34485d9 100644
> >>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>> @@ -42,12 +42,28 @@ properties:
> >>>>        - const: cm33stbyr_int
> >>>>        - const: ca55_deny
> >>>>  
> >>>> +  "#reset-cells":
> >>>> +    const: 1
> >>>> +
> >>>>  required:
> >>>>    - compatible
> >>>>    - reg
> >>>>  
> >>>>  additionalProperties: false
> >>>>  
> >>>> +allOf:
> >>>> +  - if:
> >>>> +      properties:
> >>>> +        compatible:
> >>>> +          contains:
> >>>> +            const: renesas,r9a08g045-sysc
> >>>> +    then:
> >>>> +      required:
> >>>> +        - "#reset-cells"
> >>>
> >>> Given this is new required property on an existing platform, I'd expect
> >>> some mention of why it used to be okay to not have this but is now
> >>> required. Did firmware or a bootloader stage take things out of reset?
> >>
> >> On previous SoCs the SYS controller has no support for controlling the
> >> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
> >> I'll add a note about this on next version.
> > 
> > My initial thought here wasn't about previous SoCs though, it was
> > because you didn't add the compatible in this series for /this/ SoC.
> 
> RZ/G3S compatible is already present in this file:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26

I know, first thing I did when I read the original patch was open the
file ;)
I don't care about the old SoCs, cos you're not applying the property to
them, so what's changed between SoCs isn't really relevant. It's a mention
of why, on this SoC, it is safe to add new required properties that I want.

AFAIU the answer is that no consumer of the resets existed before, so
there's not some special state there, and I am guessing that the new
sysc driver you're adding isn't going to fail to probe if there are no
resets, it just won't register a reset controller? Which is fine, cos all
devicetrees that have the new peripherals will have #reset-cells etc.

> > What's worth noting isn't about the prior SoCs, it is about what makes
> > it okay for this one.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[claudiu beznea]

On 23.08.2024 19:33, Conor Dooley wrote:
> On Fri, Aug 23, 2024 at 07:26:42PM +0300, claudiu beznea wrote:
>> On 23.08.2024 19:18, Conor Dooley wrote:
>>> On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
>>>> Hi, Conor,
>>>>
>>>> On 22.08.2024 19:42, Conor Dooley wrote:
>>>>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
>>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>>
>>>>>> The RZ/G3S System controller has registers to control signals that need
>>>>>> to be de-asserted/asserted before/after different SoC areas are power
>>>>>> on/off. This signals are implemented as reset signals. For this document
>>>>>> the #reset-cells property.
>>>>>>
>>>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>> ---
>>>>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
>>>>>>  1 file changed, 16 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>>>> index 4386b2c3fa4d..6b0bb34485d9 100644
>>>>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
>>>>>> @@ -42,12 +42,28 @@ properties:
>>>>>>        - const: cm33stbyr_int
>>>>>>        - const: ca55_deny
>>>>>>  
>>>>>> +  "#reset-cells":
>>>>>> +    const: 1
>>>>>> +
>>>>>>  required:
>>>>>>    - compatible
>>>>>>    - reg
>>>>>>  
>>>>>>  additionalProperties: false
>>>>>>  
>>>>>> +allOf:
>>>>>> +  - if:
>>>>>> +      properties:
>>>>>> +        compatible:
>>>>>> +          contains:
>>>>>> +            const: renesas,r9a08g045-sysc
>>>>>> +    then:
>>>>>> +      required:
>>>>>> +        - "#reset-cells"
>>>>>
>>>>> Given this is new required property on an existing platform, I'd expect
>>>>> some mention of why it used to be okay to not have this but is now
>>>>> required. Did firmware or a bootloader stage take things out of reset?
>>>>
>>>> On previous SoCs the SYS controller has no support for controlling the
>>>> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
>>>> I'll add a note about this on next version.
>>>
>>> My initial thought here wasn't about previous SoCs though, it was
>>> because you didn't add the compatible in this series for /this/ SoC.
>>
>> RZ/G3S compatible is already present in this file:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26
> 
> I know, first thing I did when I read the original patch was open the
> file ;)
> I don't care about the old SoCs, cos you're not applying the property to
> them, so what's changed between SoCs isn't really relevant. It's a mention
> of why, on this SoC, it is safe to add new required properties that I want.


> 
> AFAIU the answer is that no consumer of the resets existed before, so

That's true.

> there's not some special state there, and I am guessing that the new
> sysc driver you're adding isn't going to fail to probe if there are no
> resets, 

That's true.

it just won't register a reset controller?

It will register it but,

the new sysc driver is going to probe only for this SoC (RZ/G3S). On RZ/G3S
we have 2 resets. These well be registered unconditionally, currently, only
for RZ/G3S. If there will be no DT users for it then it should be no
problem, AFAICT.

SYSC variants have common features b/w different SoC variants (one of them
being chip identification). The feature implemented though reset controller
in this series is not common but particular to RZ/G3S.

When the SYSC will be extended for other SoCs the reset driver registration
would have to be adapted to not be registered. At the moment, as the SYC is
compatible only with RZ/G3S and the reset driver is registered on auxiliary
bus though SYSC there is no restriction, reset is registered all the time,
but SYSC is only compatible with RZ/G3S.

> Which is fine, cos all
> devicetrees that have the new peripherals will have #reset-cells etc.
> 
>>> What's worth noting isn't about the prior SoCs, it is about what makes
>>> it okay for this one.

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

On Mon, Aug 26, 2024 at 01:15:43PM +0300, claudiu beznea wrote:
> 
> 
> On 23.08.2024 19:33, Conor Dooley wrote:
> > On Fri, Aug 23, 2024 at 07:26:42PM +0300, claudiu beznea wrote:
> >> On 23.08.2024 19:18, Conor Dooley wrote:
> >>> On Fri, Aug 23, 2024 at 10:54:06AM +0300, claudiu beznea wrote:
> >>>> Hi, Conor,
> >>>>
> >>>> On 22.08.2024 19:42, Conor Dooley wrote:
> >>>>> On Thu, Aug 22, 2024 at 06:27:47PM +0300, Claudiu wrote:
> >>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>>>
> >>>>>> The RZ/G3S System controller has registers to control signals that need
> >>>>>> to be de-asserted/asserted before/after different SoC areas are power
> >>>>>> on/off. This signals are implemented as reset signals. For this document
> >>>>>> the #reset-cells property.
> >>>>>>
> >>>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>>> ---
> >>>>>>  .../bindings/soc/renesas/renesas,rzg2l-sysc.yaml | 16 ++++++++++++++++
> >>>>>>  1 file changed, 16 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>>>> index 4386b2c3fa4d..6b0bb34485d9 100644
> >>>>>> --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
> >>>>>> @@ -42,12 +42,28 @@ properties:
> >>>>>>        - const: cm33stbyr_int
> >>>>>>        - const: ca55_deny
> >>>>>>  
> >>>>>> +  "#reset-cells":
> >>>>>> +    const: 1
> >>>>>> +
> >>>>>>  required:
> >>>>>>    - compatible
> >>>>>>    - reg
> >>>>>>  
> >>>>>>  additionalProperties: false
> >>>>>>  
> >>>>>> +allOf:
> >>>>>> +  - if:
> >>>>>> +      properties:
> >>>>>> +        compatible:
> >>>>>> +          contains:
> >>>>>> +            const: renesas,r9a08g045-sysc
> >>>>>> +    then:
> >>>>>> +      required:
> >>>>>> +        - "#reset-cells"
> >>>>>
> >>>>> Given this is new required property on an existing platform, I'd expect
> >>>>> some mention of why it used to be okay to not have this but is now
> >>>>> required. Did firmware or a bootloader stage take things out of reset?
> >>>>
> >>>> On previous SoCs the SYS controller has no support for controlling the
> >>>> signals going to different peripherals (USB, PCIE in case of RZ/G3S).
> >>>> I'll add a note about this on next version.
> >>>
> >>> My initial thought here wasn't about previous SoCs though, it was
> >>> because you didn't add the compatible in this series for /this/ SoC.
> >>
> >> RZ/G3S compatible is already present in this file:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml#n26
> > 
> > I know, first thing I did when I read the original patch was open the
> > file ;)
> > I don't care about the old SoCs, cos you're not applying the property to
> > them, so what's changed between SoCs isn't really relevant. It's a mention
> > of why, on this SoC, it is safe to add new required properties that I want.
> 
> 
> > 
> > AFAIU the answer is that no consumer of the resets existed before, so
> 
> That's true.
> 
> > there's not some special state there, and I am guessing that the new
> > sysc driver you're adding isn't going to fail to probe if there are no
> > resets, 
> 
> That's true.
> 
> it just won't register a reset controller?
> 
> It will register it but,
> 
> the new sysc driver is going to probe only for this SoC (RZ/G3S). On RZ/G3S
> we have 2 resets. These well be registered unconditionally, currently, only
> for RZ/G3S. If there will be no DT users for it then it should be no
> problem, AFAICT.

Okay, sounds it doesn't break for existing devicetrees.
Acked-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 02/16] dt-bindings: soc: renesas: renesas,rzg2l-sysc: Add #reset-cells for RZ/G3S

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The RZ/G3S System controller has registers to control signals that need
> to be de-asserted/asserted before/after different SoC areas are power
> on/off. This signals are implemented as reset signals. For this document
> the #reset-cells property.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 03/16] dt-bindings: reset: renesas,r9a08g045-sysc: Add reset IDs for RZ/G3S SYSC reset

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add reset IDs for the Renesas RZ/G3S SYSC reset controller driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 include/dt-bindings/reset/renesas,r9a08g045-sysc.h | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 include/dt-bindings/reset/renesas,r9a08g045-sysc.h

diff --git a/include/dt-bindings/reset/renesas,r9a08g045-sysc.h b/include/dt-bindings/reset/renesas,r9a08g045-sysc.h
new file mode 100644
index 000000000000..675872a32121
--- /dev/null
+++ b/include/dt-bindings/reset/renesas,r9a08g045-sysc.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RESET_R9A08G045_SYSC_H
+#define __DT_BINDINGS_RESET_R9A08G045_SYSC_H
+
+#define R9A08G045_SYSC_RESET_USB	0
+#define R9A08G045_SYSC_RESET_PCIE	1
+
+#endif /* __DT_BINDINGS_RESET_SAMA7G5_H */
+
-- 
2.39.2

Re: [PATCH 03/16] dt-bindings: reset: renesas,r9a08g045-sysc: Add reset IDs for RZ/G3S SYSC reset

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

On Thu, Aug 22, 2024 at 06:27:48PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Add reset IDs for the Renesas RZ/G3S SYSC reset controller driver.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 03/16] dt-bindings: reset: renesas,r9a08g045-sysc: Add reset IDs for RZ/G3S SYSC reset

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Add reset IDs for the Renesas RZ/G3S SYSC reset controller driver.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 04/16] soc: renesas: Add SYSC driver for Renesas RZ/G3S

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The RZ/G3S SYS Controller has 2 registers (one for PCIE one for USB) that
need to be configured before/after powering off/on the PCI or USB
ares. The bits in these registers control signals to PCIE and USB that
need to be de-asserted/asserted after/before power on/off event. For this
add SYSC controller driver that registers a reset controller driver on
auxiliary bus which allows USB, PCIE drivers to control these signals.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---

Hi, Philipp, Ulf, Geert, all,

In this series the control of USB and PCIE signals was implemented
though a reset control driver. This approach was chosen as a result
of looking though the HW manual and trying to understand how these
signals behave. HW manual can be downloaded from [1] (download
manual hardware button -> confirm -> extract archive ->
Deliverables -> r01uh1014ej0110-rzg3s.pdf).

The description of the USB and PCIE control registers is as follows:

SYS_USB_PWRRDY Register (Signal is called PWRRDY), Chapter 6.3.83:

Controls PWRRDY terminal of USB:
0: PWRRDY
1: PWRRDY down
When turning off the USB region power, set this bit to 1.
When turning on the USB region power, set this bit to 0.

SYS_PCIE_RST_RSM_B (Signal is called RST_RSM_B), Chapter 6.3.84:

Controls RST_RSM_B terminal of PCIe
0: RST_RSM_B=0
1: RST_RSM_B=1
Set RST_RSM_B=1 after PCIe power is applied.
When the power in the PCIe region is turned off, set RST_RSM_B=0
before turning off the power supply.

From this description I understood that the control of the USB PWRRDY,
PCIE RST_RSM_B signals and the power control for the domains
the USB, PCI belongs are different things [A].

As of Figure 41.1 (Power Domain and Power Supply) and Table 41.1 (Power
Domain to which Power Supply Pins Belong) the USB and PCIE belongs to
PD_ISOVCC power domain controlled though PMIC [B].

The USB, PCI signals are also reference in HW manual in the low power
consumption chapter describing the transition to different power
modes. E.g., chapter 41.6.1 (ALL_ON to VBATT), Table 41.8 (Example
Transition Flow Outline from ALL_ON Mode to VBATT Mode) says at
steps 6 and 7:

6. USB PHY PWRRDY signal control (if using USB) SYS_USB_PWRRDY
7. PCIe RST_RSM_B signal control (if using PCIe) SYS_PCIE_RST_RSM_B

Meaning these signals need to be controlled before going to VBATT
power mode (where the power supply to USB is turned off) [C].

Due to [A], [B] and [C] I chosed to have the implementation of these
signals though a reset control driver.

Other option I explored was though power domains as follows:
1/ registering one domain for USB, one of PCIE
2/ passed the domain ID to USB though device tree
3/ attach from USB PHY control driver to the USB power domain
   with dev_pm_domain_attach_by_name()
4/ and controlling the SYSC registers with
   pm_runtime_resume_and_get(usb_sysc_domain).

Please let me know what do you think about this!

Thank you,
Claudiu Beznea


[1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250

 drivers/reset/Kconfig                        |   7 +
 drivers/reset/Makefile                       |   1 +
 drivers/reset/reset-rzg3s-sysc.c             | 140 +++++++++++++++++++
 drivers/soc/renesas/Makefile                 |   1 +
 drivers/soc/renesas/rzg3s-sysc.c             | 113 +++++++++++++++
 include/linux/soc/renesas/rzg3s-sysc-reset.h |  24 ++++
 6 files changed, 286 insertions(+)
 create mode 100644 drivers/reset/reset-rzg3s-sysc.c
 create mode 100644 drivers/soc/renesas/rzg3s-sysc.c
 create mode 100644 include/linux/soc/renesas/rzg3s-sysc-reset.h

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 67bce340a87e..fbdf860b2293 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -218,6 +218,13 @@ config RESET_RZG2L_USBPHY_CTRL
 	  Support for USBPHY Control found on RZ/G2L family. It mainly
 	  controls reset and power down of the USB/PHY.
 
+config RESET_RZG3S_SYSC
+	tristate "Renesas RZ/G3S SYSC reset driver"
+	depends on ARCH_R9A08G045 || COMPILE_TEST
+	help
+	  Support for SYSC reset found on RZ/G3S family. It mainly
+	  controls reset on USB and PCIE.
+
 config RESET_SCMI
 	tristate "Reset driver controlled via ARM SCMI interface"
 	depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 27b0bbdfcc04..ee5ca21acc44 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_RESET_QCOM_AOSS) += reset-qcom-aoss.o
 obj-$(CONFIG_RESET_QCOM_PDC) += reset-qcom-pdc.o
 obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_RZG2L_USBPHY_CTRL) += reset-rzg2l-usbphy-ctrl.o
+obj-$(CONFIG_RESET_RZG3S_SYSC) += reset-rzg3s-sysc.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
 obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
diff --git a/drivers/reset/reset-rzg3s-sysc.c b/drivers/reset/reset-rzg3s-sysc.c
new file mode 100644
index 000000000000..56af03f1d8a2
--- /dev/null
+++ b/drivers/reset/reset-rzg3s-sysc.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas RZ/G3S SYSC reset driver
+ *
+ * Copyright (C) 2024 Renesas Electronics Corp.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/soc/renesas/rzg3s-sysc-reset.h>
+
+#include <dt-bindings/reset/renesas,r9a08g045-sysc.h>
+
+#define RZG3S_SYSC_USB_PWRRDY		0xd70
+#define RZG3S_SYSC_PCIE_RST_RSM_B	0xd74
+#define RZG3S_SYSC_RESET_MASK		0x1
+
+/**
+ * struct rzg3s_sysc_reset_info - SYSC reset information
+ * @offset: offset to configure the reset
+ * @assert_val: value to write to register on assert
+ * @deassert_val: value to write to register on de-assert
+ */
+struct rzg3s_sysc_reset_info {
+	u16 offset;
+	u8 assert_val;
+	u8 deassert_val;
+};
+
+/**
+ * struct rzg3s_sysc_reset - SYSC reset
+ * @info: SYSC reset information
+ * @radev: SYSC reset auxiliary device
+ * @rcdev: reset controller device
+ */
+struct rzg3s_sysc_reset {
+	const struct rzg3s_sysc_reset_info *info;
+	struct rzg3s_sysc_reset_adev *radev;
+	struct reset_controller_dev rcdev;
+};
+
+#define to_rzg3s_sysc_reset(r)	container_of(r, struct rzg3s_sysc_reset, rcdev)
+
+static int rzg3s_sysc_reset_set(struct reset_controller_dev *rcdev,
+				unsigned long id, bool assert)
+{
+	struct rzg3s_sysc_reset *reset = to_rzg3s_sysc_reset(rcdev);
+	struct rzg3s_sysc_reset_adev *radev = reset->radev;
+	struct rzg3s_sysc_reset_info info = reset->info[id];
+	unsigned long flags;
+	u32 tmp;
+
+	spin_lock_irqsave(radev->lock, flags);
+	tmp = readl(radev->base + info.offset);
+	tmp &= ~RZG3S_SYSC_RESET_MASK;
+	tmp |= assert ? info.assert_val : info.deassert_val;
+	writel(tmp, radev->base + info.offset);
+	spin_unlock_irqrestore(radev->lock, flags);
+
+	return 0;
+}
+
+static int rzg3s_sysc_reset_assert(struct reset_controller_dev *rcdev,
+				   unsigned long id)
+{
+	return rzg3s_sysc_reset_set(rcdev, id, true);
+}
+
+static int rzg3s_sysc_reset_deassert(struct reset_controller_dev *rcdev,
+				     unsigned long id)
+{
+	return rzg3s_sysc_reset_set(rcdev, id, false);
+}
+
+static int rzg3s_sysc_reset_status(struct reset_controller_dev *rcdev,
+				   unsigned long id)
+{
+	struct rzg3s_sysc_reset *reset = to_rzg3s_sysc_reset(rcdev);
+	const struct rzg3s_sysc_reset_info info = reset->info[id];
+	struct rzg3s_sysc_reset_adev *radev = reset->radev;
+	u32 tmp;
+
+	tmp = readl(radev->base + info.offset);
+	tmp = !!(tmp & RZG3S_SYSC_RESET_MASK);
+
+	return info.assert_val ? tmp : !tmp;
+}
+
+static const struct reset_control_ops rzg3s_sysc_reset_ops = {
+	.assert = rzg3s_sysc_reset_assert,
+	.deassert = rzg3s_sysc_reset_deassert,
+	.status = rzg3s_sysc_reset_status,
+};
+
+static const struct rzg3s_sysc_reset_info rzg3s_sysc_reset_info[] = {
+	[R9A08G045_SYSC_RESET_USB] = {
+		.offset = RZG3S_SYSC_USB_PWRRDY, .assert_val = 1, .deassert_val = 0
+	},
+	[R9A08G045_SYSC_RESET_PCIE] = {
+		.offset = RZG3S_SYSC_PCIE_RST_RSM_B, .assert_val = 0, .deassert_val = 1
+	},
+};
+
+static int rzg3s_sysc_reset_probe(struct auxiliary_device *adev,
+				  const struct auxiliary_device_id *id)
+{
+	struct rzg3s_sysc_reset_adev *reset_adev = to_rzg3s_sysc_reset_adev(adev);
+	struct device *dev = &adev->dev;
+	struct rzg3s_sysc_reset *reset;
+
+	reset = devm_kzalloc(dev, sizeof(*reset), GFP_KERNEL);
+	if (!reset)
+		return -ENOMEM;
+
+	reset->radev = reset_adev;
+	reset->info = rzg3s_sysc_reset_info;
+
+	reset->rcdev.ops = &rzg3s_sysc_reset_ops;
+	reset->rcdev.of_reset_n_cells = 1;
+	reset->rcdev.nr_resets = ARRAY_SIZE(rzg3s_sysc_reset_info);
+	reset->rcdev.of_node = dev->parent->of_node;
+	reset->rcdev.dev = dev;
+
+	return devm_reset_controller_register(dev, &reset->rcdev);
+}
+
+static const struct auxiliary_device_id rzg3s_sysc_reset_ids[] = {
+	{ .name = "rzg3s_sysc.reset" },
+	{ }
+};
+MODULE_DEVICE_TABLE(auxiliary, rzg3s_sysc_reset_ids);
+
+static struct auxiliary_driver rzg3s_sysc_reset_driver = {
+	.probe		= rzg3s_sysc_reset_probe,
+	.id_table	= rzg3s_sysc_reset_ids,
+};
+module_auxiliary_driver(rzg3s_sysc_reset_driver);
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 734f8f8cefa4..74c72ac46f91 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SOC_RENESAS)	+= renesas-soc.o
 ifdef CONFIG_SMP
 obj-$(CONFIG_ARCH_R9A06G032)	+= r9a06g032-smp.o
 endif
+obj-$(CONFIG_ARCH_R9A08G045)	+= rzg3s-sysc.o
 
 # Family
 obj-$(CONFIG_PWC_RZV2M)		+= pwc-rzv2m.o
diff --git a/drivers/soc/renesas/rzg3s-sysc.c b/drivers/soc/renesas/rzg3s-sysc.c
new file mode 100644
index 000000000000..e664d29ce5c3
--- /dev/null
+++ b/drivers/soc/renesas/rzg3s-sysc.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/G3S System controller driver
+ *
+ * Copyright (C) 2024 Renesas Electronics Corp.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/platform_device.h>
+
+#include <linux/soc/renesas/rzg3s-sysc-reset.h>
+
+/**
+ * struct rzg3s_sysc - SYSC private data structure
+ * @base: base address
+ * @dev: device
+ * @lock: lock
+ */
+struct rzg3s_sysc {
+	void __iomem *base;
+	struct device *dev;
+	spinlock_t lock;
+};
+
+static void rzg3s_sysc_reset_adev_release(struct device *dev)
+{
+	struct auxiliary_device *adev = to_auxiliary_dev(dev);
+	struct rzg3s_sysc_reset_adev *reset_adev = to_rzg3s_sysc_reset_adev(adev);
+
+	kfree(reset_adev);
+}
+
+static void rzg3s_sysc_reset_unregister_adev(void *adev)
+{
+	auxiliary_device_delete(adev);
+	auxiliary_device_uninit(adev);
+}
+
+static int rzg3s_sysc_reset_probe(struct rzg3s_sysc *sysc, const char *adev_name,
+				  u32 adev_id)
+{
+	struct rzg3s_sysc_reset_adev *radev;
+	struct auxiliary_device *adev;
+	int ret;
+
+	radev = kzalloc(sizeof(*radev), GFP_KERNEL);
+	if (!radev)
+		return -ENOMEM;
+
+	radev->base = sysc->base;
+	radev->lock = &sysc->lock;
+
+	adev = &radev->adev;
+	adev->name = adev_name;
+	adev->dev.parent = sysc->dev;
+	adev->dev.release = rzg3s_sysc_reset_adev_release;
+	adev->id = adev_id;
+
+	ret = auxiliary_device_init(adev);
+	if (ret)
+		return ret;
+
+	ret = auxiliary_device_add(adev);
+	if (ret) {
+		auxiliary_device_uninit(adev);
+		return ret;
+	}
+
+	return devm_add_action_or_reset(sysc->dev, rzg3s_sysc_reset_unregister_adev, adev);
+}
+
+static int rzg3s_sysc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rzg3s_sysc *sysc;
+
+	sysc = devm_kzalloc(dev, sizeof(*sysc), GFP_KERNEL);
+	if (!sysc)
+		return -ENOMEM;
+
+	sysc->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(sysc->base))
+		return PTR_ERR(sysc->base);
+
+	sysc->dev = dev;
+	spin_lock_init(&sysc->lock);
+
+	return rzg3s_sysc_reset_probe(sysc, "reset", 0);
+}
+
+static const struct of_device_id rzg3s_sysc_match[] = {
+	{ .compatible = "renesas,r9a08g045-sysc" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, rzg3s_sysc_match);
+
+static struct platform_driver rzg3s_sysc_driver = {
+	.driver = {
+		.name = "renesas-rzg3s-sysc",
+		.of_match_table = rzg3s_sysc_match
+	},
+	.probe = rzg3s_sysc_probe
+};
+
+static int __init rzg3s_sysc_init(void)
+{
+	return platform_driver_register(&rzg3s_sysc_driver);
+}
+subsys_initcall(rzg3s_sysc_init);
+
+MODULE_DESCRIPTION("Renesas RZ/G3S System Controller Driver");
+MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/soc/renesas/rzg3s-sysc-reset.h b/include/linux/soc/renesas/rzg3s-sysc-reset.h
new file mode 100644
index 000000000000..813cbe82a68a
--- /dev/null
+++ b/include/linux/soc/renesas/rzg3s-sysc-reset.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __SOC_RENESAS_SYSC_RESET_RZG3S_H
+#define __SOC_RENESAS_SYSC_RESET_RZG3S_H
+
+#include <linux/auxiliary_bus.h>
+#include <linux/spinlock_types.h>
+#include <linux/container_of.h>
+
+/**
+ * struct rzg3s_sysc_reset_adev - SYSC reset auxiliary device
+ * @base: base address
+ * @lock: lock
+ * @adev: auxiliary device
+ */
+struct rzg3s_sysc_reset_adev {
+	void __iomem *base;
+	spinlock_t *lock;
+	struct auxiliary_device adev;
+};
+
+#define to_rzg3s_sysc_reset_adev(a)	container_of(a, struct rzg3s_sysc_reset_adev, adev)
+
+#endif
-- 
2.39.2

Re: [PATCH 04/16] soc: renesas: Add SYSC driver for Renesas RZ/G3S

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The RZ/G3S SYS Controller has 2 registers (one for PCIE one for USB) that
> need to be configured before/after powering off/on the PCI or USB
> ares. The bits in these registers control signals to PCIE and USB that
> need to be de-asserted/asserted after/before power on/off event. For this
> add SYSC controller driver that registers a reset controller driver on
> auxiliary bus which allows USB, PCIE drivers to control these signals.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch!

> --- /dev/null
> +++ b/drivers/reset/reset-rzg3s-sysc.c
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Renesas RZ/G3S SYSC reset driver
> + *
> + * Copyright (C) 2024 Renesas Electronics Corp.
> + */
> +
> +#include <linux/auxiliary_bus.h>

Using the Auxiliary Bus requires selecting AUXILIARY_BUS.
Elsse you might run into build failures:

aarch64-linux-gnu-ld: drivers/soc/renesas/rzg3s-sysc.o: in function
`rzg3s_sysc_probe':
rzg3s-sysc.c:(.text+0x21c): undefined reference to `auxiliary_device_init'
aarch64-linux-gnu-ld: rzg3s-sysc.c:(.text+0x264): undefined reference
to `__auxiliary_device_add'
aarch64-linux-gnu-ld: drivers/reset/reset-rzg3s-sysc.o: in function
`rzg3s_sysc_reset_driver_init':
reset-rzg3s-sysc.c:(.init.text+0x1c): undefined reference to
`__auxiliary_driver_register'
aarch64-linux-gnu-ld: drivers/reset/reset-rzg3s-sysc.o: in function
`rzg3s_sysc_reset_driver_exit':
reset-rzg3s-sysc.c:(.exit.text+0x10): undefined reference to
`auxiliary_driver_unregister'

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 04/16] soc: renesas: Add SYSC driver for Renesas RZ/G3S

[claudiu beznea]

Hi, Geert,

On 24.09.2024 14:32, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The RZ/G3S SYS Controller has 2 registers (one for PCIE one for USB) that
>> need to be configured before/after powering off/on the PCI or USB
>> ares. The bits in these registers control signals to PCIE and USB that
>> need to be de-asserted/asserted after/before power on/off event. For this
>> add SYSC controller driver that registers a reset controller driver on
>> auxiliary bus which allows USB, PCIE drivers to control these signals.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Thanks for your patch!
> 
>> --- /dev/null
>> +++ b/drivers/reset/reset-rzg3s-sysc.c
>> @@ -0,0 +1,140 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Renesas RZ/G3S SYSC reset driver
>> + *
>> + * Copyright (C) 2024 Renesas Electronics Corp.
>> + */
>> +
>> +#include <linux/auxiliary_bus.h>
> 
> Using the Auxiliary Bus requires selecting AUXILIARY_BUS.

Thank you for pointing it. I'll adjust it in the next version, if it will
be one.


> Elsse you might run into build failures:
> 
> aarch64-linux-gnu-ld: drivers/soc/renesas/rzg3s-sysc.o: in function
> `rzg3s_sysc_probe':
> rzg3s-sysc.c:(.text+0x21c): undefined reference to `auxiliary_device_init'
> aarch64-linux-gnu-ld: rzg3s-sysc.c:(.text+0x264): undefined reference
> to `__auxiliary_device_add'
> aarch64-linux-gnu-ld: drivers/reset/reset-rzg3s-sysc.o: in function
> `rzg3s_sysc_reset_driver_init':
> reset-rzg3s-sysc.c:(.init.text+0x1c): undefined reference to
> `__auxiliary_driver_register'
> aarch64-linux-gnu-ld: drivers/reset/reset-rzg3s-sysc.o: in function
> `rzg3s_sysc_reset_driver_exit':
> reset-rzg3s-sysc.c:(.exit.text+0x10): undefined reference to
> `auxiliary_driver_unregister'
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: [PATCH 04/16] soc: renesas: Add SYSC driver for Renesas RZ/G3S

[Geert Uytterhoeven]

Hi Claudiu,

On Wed, Sep 25, 2024 at 9:50 AM claudiu beznea <claudiu.beznea@tuxon.dev> wrote:
> On 24.09.2024 14:32, Geert Uytterhoeven wrote:
> > On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> The RZ/G3S SYS Controller has 2 registers (one for PCIE one for USB) that
> >> need to be configured before/after powering off/on the PCI or USB
> >> ares. The bits in these registers control signals to PCIE and USB that
> >> need to be de-asserted/asserted after/before power on/off event. For this
> >> add SYSC controller driver that registers a reset controller driver on
> >> auxiliary bus which allows USB, PCIE drivers to control these signals.
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >
> > Thanks for your patch!
> >
> >> --- /dev/null
> >> +++ b/drivers/reset/reset-rzg3s-sysc.c
> >> @@ -0,0 +1,140 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Renesas RZ/G3S SYSC reset driver
> >> + *
> >> + * Copyright (C) 2024 Renesas Electronics Corp.
> >> + */
> >> +
> >> +#include <linux/auxiliary_bus.h>
> >
> > Using the Auxiliary Bus requires selecting AUXILIARY_BUS.
>
> Thank you for pointing it. I'll adjust it in the next version, if it will
> be one.

Thanks, the rest LGTM.

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 05/16] soc: renesas: sysc: Move RZ/G3S SoC detection on SYSC driver

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Now that we have a driver for SYSC driver for RZ/G3S move the SoC detection
for RZ/G3S in SYSC driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/soc/renesas/renesas-soc.c | 12 ---------
 drivers/soc/renesas/rzg3s-sysc.c  | 45 +++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 172d59e6fbcf..425d9037dcd0 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -71,10 +71,6 @@ static const struct renesas_family fam_rzg2ul __initconst __maybe_unused = {
 	.name	= "RZ/G2UL",
 };
 
-static const struct renesas_family fam_rzg3s __initconst __maybe_unused = {
-	.name	= "RZ/G3S",
-};
-
 static const struct renesas_family fam_rzv2h __initconst __maybe_unused = {
 	.name	= "RZ/V2H",
 };
@@ -176,11 +172,6 @@ static const struct renesas_soc soc_rz_g2ul __initconst __maybe_unused = {
 	.id     = 0x8450447,
 };
 
-static const struct renesas_soc soc_rz_g3s __initconst __maybe_unused = {
-	.family = &fam_rzg3s,
-	.id	= 0x85e0447,
-};
-
 static const struct renesas_soc soc_rz_v2h __initconst __maybe_unused = {
 	.family = &fam_rzv2h,
 	.id     = 0x847a447,
@@ -410,9 +401,6 @@ static const struct of_device_id renesas_socs[] __initconst __maybe_unused = {
 #ifdef CONFIG_ARCH_R9A07G054
 	{ .compatible = "renesas,r9a07g054",	.data = &soc_rz_v2l },
 #endif
-#ifdef CONFIG_ARCH_R9A08G045
-	{ .compatible = "renesas,r9a08g045",	.data = &soc_rz_g3s },
-#endif
 #ifdef CONFIG_ARCH_R9A09G011
 	{ .compatible = "renesas,r9a09g011",	.data = &soc_rz_v2m },
 #endif
diff --git a/drivers/soc/renesas/rzg3s-sysc.c b/drivers/soc/renesas/rzg3s-sysc.c
index e664d29ce5c3..1dd48c7255d1 100644
--- a/drivers/soc/renesas/rzg3s-sysc.c
+++ b/drivers/soc/renesas/rzg3s-sysc.c
@@ -6,10 +6,16 @@
  */
 
 #include <linux/auxiliary_bus.h>
+#include <linux/io.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/sys_soc.h>
 
 #include <linux/soc/renesas/rzg3s-sysc-reset.h>
 
+#define RZG3S_SYS_LSI_DEVID		0xa04
+#define RZG3S_SYS_LSI_DEVID_REV		GENMASK(31, 28)
+
 /**
  * struct rzg3s_sysc - SYSC private data structure
  * @base: base address
@@ -71,8 +77,14 @@ static int rzg3s_sysc_reset_probe(struct rzg3s_sysc *sysc, const char *adev_name
 
 static int rzg3s_sysc_probe(struct platform_device *pdev)
 {
+	const char *soc_id_start, *soc_id_end, *compatible;
+	struct soc_device_attribute *soc_dev_attr;
 	struct device *dev = &pdev->dev;
+	struct soc_device *soc_dev;
 	struct rzg3s_sysc *sysc;
+	char soc_id[32] = {0};
+	u32 devid, revision;
+	u8 size;
 
 	sysc = devm_kzalloc(dev, sizeof(*sysc), GFP_KERNEL);
 	if (!sysc)
@@ -85,6 +97,39 @@ static int rzg3s_sysc_probe(struct platform_device *pdev)
 	sysc->dev = dev;
 	spin_lock_init(&sysc->lock);
 
+	compatible = of_get_property(dev->of_node, "compatible", NULL);
+	if (!compatible)
+		return -ENODEV;
+
+	soc_id_start = strchr(compatible, ',') + 1;
+	soc_id_end = strchr(compatible, '-');
+	size = soc_id_end - soc_id_start;
+	if (size > 32)
+		size = 32;
+	strscpy(soc_id, soc_id_start, size);
+
+	soc_dev_attr = devm_kzalloc(dev, sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENOMEM;
+
+	soc_dev_attr->family = "RZ/G3S";
+	soc_dev_attr->soc_id = devm_kstrdup(dev, soc_id, GFP_KERNEL);
+	if (!soc_dev_attr->soc_id)
+		return -ENOMEM;
+
+	devid = readl(sysc->base + RZG3S_SYS_LSI_DEVID);
+	revision = FIELD_GET(RZG3S_SYS_LSI_DEVID_REV, devid);
+	soc_dev_attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%u", revision);
+	if (!soc_dev_attr->revision)
+		return -ENOMEM;
+
+	dev_info(dev, "Detected Renesas %s %s Rev %s\n", soc_dev_attr->family,
+		 soc_dev_attr->soc_id, soc_dev_attr->revision);
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev))
+		return PTR_ERR(soc_dev);
+
 	return rzg3s_sysc_reset_probe(sysc, "reset", 0);
 }
 
-- 
2.39.2

Re: [PATCH 05/16] soc: renesas: sysc: Move RZ/G3S SoC detection on SYSC driver

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Now that we have a driver for SYSC driver for RZ/G3S move the SoC detection
> for RZ/G3S in SYSC driver.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch!

> --- a/drivers/soc/renesas/rzg3s-sysc.c
> +++ b/drivers/soc/renesas/rzg3s-sysc.c
> @@ -85,6 +97,39 @@ static int rzg3s_sysc_probe(struct platform_device *pdev)
>         sysc->dev = dev;
>         spin_lock_init(&sysc->lock);
>
> +       compatible = of_get_property(dev->of_node, "compatible", NULL);
> +       if (!compatible)
> +               return -ENODEV;

Please use of_match_device() and of_device_id.compatible instead.

> +
> +       soc_id_start = strchr(compatible, ',') + 1;
> +       soc_id_end = strchr(compatible, '-');
> +       size = soc_id_end - soc_id_start;
> +       if (size > 32)
> +               size = 32;
> +       strscpy(soc_id, soc_id_start, size);
> +
> +       soc_dev_attr = devm_kzalloc(dev, sizeof(*soc_dev_attr), GFP_KERNEL);
> +       if (!soc_dev_attr)
> +               return -ENOMEM;
> +
> +       soc_dev_attr->family = "RZ/G3S";
> +       soc_dev_attr->soc_id = devm_kstrdup(dev, soc_id, GFP_KERNEL);
> +       if (!soc_dev_attr->soc_id)
> +               return -ENOMEM;
> +
> +       devid = readl(sysc->base + RZG3S_SYS_LSI_DEVID);
> +       revision = FIELD_GET(RZG3S_SYS_LSI_DEVID_REV, devid);
> +       soc_dev_attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%u", revision);
> +       if (!soc_dev_attr->revision)
> +               return -ENOMEM;
> +
> +       dev_info(dev, "Detected Renesas %s %s Rev %s\n", soc_dev_attr->family,
> +                soc_dev_attr->soc_id, soc_dev_attr->revision);
> +
> +       soc_dev = soc_device_register(soc_dev_attr);
> +       if (IS_ERR(soc_dev))
> +               return PTR_ERR(soc_dev);
> +
>         return rzg3s_sysc_reset_probe(sysc, "reset", 0);
>  }

My first thought was "oh no, now this is handled/duplicated in two
places", but if you later migrate the chip identification support for
the rest of RZ/G2L devices to here, it may start to look better ;-)

One caveat is that soc_device_match() can be called quite early in
the boot process, hence renesas_soc_init() is an early_initcall().
So registering the soc_device from a platform_driver might be too late,
especially since fw_devlinks won't help you in this particular case.
However, I think all real early calls to soc_device_match() are gone
since the removal of the support for R-Car H3 ES1.x, and all remaining
calls impact only R-Car and RZ/Gx (not G2L) SoCs.

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 05/16] soc: renesas: sysc: Move RZ/G3S SoC detection on SYSC driver

[claudiu beznea]

Hi, Geert,

On 08.10.2024 16:23, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> Now that we have a driver for SYSC driver for RZ/G3S move the SoC detection
>> for RZ/G3S in SYSC driver.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Thanks for your patch!
> 
>> --- a/drivers/soc/renesas/rzg3s-sysc.c
>> +++ b/drivers/soc/renesas/rzg3s-sysc.c
>> @@ -85,6 +97,39 @@ static int rzg3s_sysc_probe(struct platform_device *pdev)
>>         sysc->dev = dev;
>>         spin_lock_init(&sysc->lock);
>>
>> +       compatible = of_get_property(dev->of_node, "compatible", NULL);
>> +       if (!compatible)
>> +               return -ENODEV;
> 
> Please use of_match_device() and of_device_id.compatible instead.

OK.

> 
>> +
>> +       soc_id_start = strchr(compatible, ',') + 1;
>> +       soc_id_end = strchr(compatible, '-');
>> +       size = soc_id_end - soc_id_start;
>> +       if (size > 32)
>> +               size = 32;
>> +       strscpy(soc_id, soc_id_start, size);
>> +
>> +       soc_dev_attr = devm_kzalloc(dev, sizeof(*soc_dev_attr), GFP_KERNEL);
>> +       if (!soc_dev_attr)
>> +               return -ENOMEM;
>> +
>> +       soc_dev_attr->family = "RZ/G3S";
>> +       soc_dev_attr->soc_id = devm_kstrdup(dev, soc_id, GFP_KERNEL);
>> +       if (!soc_dev_attr->soc_id)
>> +               return -ENOMEM;
>> +
>> +       devid = readl(sysc->base + RZG3S_SYS_LSI_DEVID);
>> +       revision = FIELD_GET(RZG3S_SYS_LSI_DEVID_REV, devid);
>> +       soc_dev_attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%u", revision);
>> +       if (!soc_dev_attr->revision)
>> +               return -ENOMEM;
>> +
>> +       dev_info(dev, "Detected Renesas %s %s Rev %s\n", soc_dev_attr->family,
>> +                soc_dev_attr->soc_id, soc_dev_attr->revision);
>> +
>> +       soc_dev = soc_device_register(soc_dev_attr);
>> +       if (IS_ERR(soc_dev))
>> +               return PTR_ERR(soc_dev);
>> +
>>         return rzg3s_sysc_reset_probe(sysc, "reset", 0);
>>  }
> 
> My first thought was "oh no, now this is handled/duplicated in two
> places", but if you later migrate the chip identification support for
> the rest of RZ/G2L devices to here, it may start to look better ;-)

Yes, this is how I see it going forward.

> 
> One caveat is that soc_device_match() can be called quite early in
> the boot process, hence renesas_soc_init() is an early_initcall().
> So registering the soc_device from a platform_driver might be too late,
> especially since fw_devlinks won't help you in this particular case.
> However, I think all real early calls to soc_device_match() are gone
> since the removal of the support for R-Car H3 ES1.x, and all remaining
> calls impact only R-Car and RZ/Gx (not G2L) SoCs.

That is good to know. I get that we should be safe going forward with this
approach.

Thank you,
Claudiu Beznea

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

[PATCH 06/16] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S SoC

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Document the Renesas RZ/G3S USB PHY Control IP. This is similar with the
one found on the RZ/G2L SoC the exception being that the SYSC USB specific
signal need to be configured before accessing the USB area. This is
done though a reset signal.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      | 35 +++++++++++++++----
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
index b0b20af15313..5f053981474e 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
@@ -15,12 +15,15 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
-          - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
-          - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
-      - const: renesas,rzg2l-usbphy-ctrl
+    oneOf:
+      - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
+
+      - items:
+          - enum:
+              - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
+              - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
+              - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
+          - const: renesas,rzg2l-usbphy-ctrl
 
   reg:
     maxItems: 1
@@ -29,7 +32,8 @@ properties:
     maxItems: 1
 
   resets:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   power-domains:
     maxItems: 1
@@ -59,6 +63,23 @@ required:
 
 additionalProperties: false
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g045-usbphy-ctrl
+    then:
+      properties:
+        resets:
+          items:
+            - description: USB PHY Control module reset
+            - description: USB area reset
+    else:
+      properties:
+        resets:
+          maxItems: 1
+
 examples:
   - |
     #include <dt-bindings/clock/r9a07g044-cpg.h>
-- 
2.39.2

Re: [PATCH 06/16] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S SoC

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Thu, Aug 22, 2024 at 06:27:51PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Document the Renesas RZ/G3S USB PHY Control IP. This is similar with the
> one found on the RZ/G2L SoC the exception being that the SYSC USB specific
> signal need to be configured before accessing the USB area. This is
> done though a reset signal.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 06/16] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S SoC

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Document the Renesas RZ/G3S USB PHY Control IP. This is similar with the
> one found on the RZ/G2L SoC the exception being that the SYSC USB specific
> signal need to be configured before accessing the USB area. This is
> done though a reset signal.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> @@ -15,12 +15,15 @@ description:
>
>  properties:
>    compatible:
> -    items:
> -      - enum:
> -          - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
> -          - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
> -          - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
> -      - const: renesas,rzg2l-usbphy-ctrl
> +    oneOf:
> +      - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
> +

Unneeded blank line.

> +      - items:
> +          - enum:
> +              - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
> +              - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
> +              - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
> +          - const: renesas,rzg2l-usbphy-ctrl

Nit: usually these are sorted by part number, so the RZ/G3S section
should be last.

For the contents:
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 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the
SYS_USB_PWRRDY register need to be cleared. When USB area is not used the
PWRRDY bit of the SYS_USB_PWRRDY register need to be set. This register is
in the SYSC controller address space and the assert/de-assert of the
signal handled by SYSC_USB_PWRRDY was implemented as a reset signal.

The USB modules available on the RZ/G3S SoC that need this bit set are:
- USB ch0 (supporting host and peripheral mode)
- USB ch2 (supporting host mode)
- USBPHY control

As the USBPHY control is the root device for all the other USB channels
(USB ch0, USB ch1) add support to set the PWRRDY for the USB area when
initializing the USBPHY control. As this is done though reset signals
get the reset array in the USBPHY control driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
index 1cd157f4f03b..8b64c12f3bec 100644
--- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
+++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
@@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
 	if (IS_ERR(regmap))
 		return PTR_ERR(regmap);
 
-	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
+	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
 	if (IS_ERR(priv->rstc))
 		return dev_err_probe(dev, PTR_ERR(priv->rstc),
 				     "failed to get reset\n");
-- 
2.39.2

RE: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea@tuxon.dev>
> Sent: Thursday, August 22, 2024 4:28 PM
> Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
> 
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the SYS_USB_PWRRDY register need to
> be cleared. When USB area is not used the PWRRDY bit of the SYS_USB_PWRRDY register need to be set.
> This register is in the SYSC controller address space and the assert/de-assert of the signal handled
> by SYSC_USB_PWRRDY was implemented as a reset signal.
> 
> The USB modules available on the RZ/G3S SoC that need this bit set are:
> - USB ch0 (supporting host and peripheral mode)
> - USB ch2 (supporting host mode)
> - USBPHY control
> 
> As the USBPHY control is the root device for all the other USB channels (USB ch0, USB ch1) add support
> to set the PWRRDY for the USB area when initializing the USBPHY control. As this is done though reset
> signals get the reset array in the USBPHY control driver.
> 

Comment applicable, if the USB PWRRDY signal is modelled as reset signal.

There is no user for this patch. The first user is RZ/G3S and is there is no support yet.
I think you should merge this patch with next one so that there is a user(RZ/G3S)
for this patch.

Cheers,
Biju

> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> index 1cd157f4f03b..8b64c12f3bec 100644
> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> @@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
> 
> -	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> +	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
>  	if (IS_ERR(priv->rstc))
>  		return dev_err_probe(dev, PTR_ERR(priv->rstc),
>  				     "failed to get reset\n");
> --
> 2.39.2

Re: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array

[claudiu beznea]

Hi, Biju,

On 23.08.2024 10:25, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Claudiu <claudiu.beznea@tuxon.dev>
>> Sent: Thursday, August 22, 2024 4:28 PM
>> Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
>>
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the SYS_USB_PWRRDY register need to
>> be cleared. When USB area is not used the PWRRDY bit of the SYS_USB_PWRRDY register need to be set.
>> This register is in the SYSC controller address space and the assert/de-assert of the signal handled
>> by SYSC_USB_PWRRDY was implemented as a reset signal.
>>
>> The USB modules available on the RZ/G3S SoC that need this bit set are:
>> - USB ch0 (supporting host and peripheral mode)
>> - USB ch2 (supporting host mode)
>> - USBPHY control
>>
>> As the USBPHY control is the root device for all the other USB channels (USB ch0, USB ch1) add support
>> to set the PWRRDY for the USB area when initializing the USBPHY control. As this is done though reset
>> signals get the reset array in the USBPHY control driver.
>>
> 
> Comment applicable, if the USB PWRRDY signal is modelled as reset signal.
> 
> There is no user for this patch. The first user is RZ/G3S and is there is no support yet.
> I think you should merge this patch with next one so that there is a user(RZ/G3S)
> for this patch.

I have nothing against to squash it. I was seeing it differently:
- this patch prepares the ground for the addition of RZ/G3S
- the next patch just enables the support for RZ/G3S

It looks to me more modular like this, patches are simpler, easier for
review and each issue is described differently in patch description.

I can do it either ways.


Thank you,
Claudiu Beznea


> Cheers,
> Biju
> 
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> index 1cd157f4f03b..8b64c12f3bec 100644
>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> @@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
>>  	if (IS_ERR(regmap))
>>  		return PTR_ERR(regmap);
>>
>> -	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
>> +	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
>>  	if (IS_ERR(priv->rstc))
>>  		return dev_err_probe(dev, PTR_ERR(priv->rstc),
>>  				     "failed to get reset\n");
>> --
>> 2.39.2
> 

RE: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Friday, August 23, 2024 9:05 AM
> Subject: Re: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array
> 
> Hi, Biju,
> 
> On 23.08.2024 10:25, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea@tuxon.dev>
> >> Sent: Thursday, August 22, 2024 4:28 PM
> >> Subject: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control
> >> array
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the
> >> SYS_USB_PWRRDY register need to be cleared. When USB area is not used the PWRRDY bit of the
> SYS_USB_PWRRDY register need to be set.
> >> This register is in the SYSC controller address space and the
> >> assert/de-assert of the signal handled by SYSC_USB_PWRRDY was implemented as a reset signal.
> >>
> >> The USB modules available on the RZ/G3S SoC that need this bit set are:
> >> - USB ch0 (supporting host and peripheral mode)
> >> - USB ch2 (supporting host mode)
> >> - USBPHY control
> >>
> >> As the USBPHY control is the root device for all the other USB
> >> channels (USB ch0, USB ch1) add support to set the PWRRDY for the USB
> >> area when initializing the USBPHY control. As this is done though reset signals get the reset array
> in the USBPHY control driver.
> >>
> >
> > Comment applicable, if the USB PWRRDY signal is modelled as reset signal.
> >
> > There is no user for this patch. The first user is RZ/G3S and is there is no support yet.
> > I think you should merge this patch with next one so that there is a
> > user(RZ/G3S) for this patch.
> 
> I have nothing against to squash it. I was seeing it differently:
> - this patch prepares the ground for the addition of RZ/G3S
> - the next patch just enables the support for RZ/G3S
> 
> It looks to me more modular like this, patches are simpler, easier for review and each issue is
> described differently in patch description.
> 
> I can do it either ways.

If it is complicated restructuring for supporting new SoC then it make sense to split into
a number of patches.

This is straight forward. You need a device quirk to support RZ/G3S.
So this kind of changes can go in a single patch, as on second patch
you are just filling device entry.

Previously I got feedback from mainline to add a patch, if there is a user.

Cheers,
Biju


> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >> ---
> >>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> index 1cd157f4f03b..8b64c12f3bec 100644
> >> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> @@ -132,7 +132,7 @@ static int rzg2l_usbphy_ctrl_probe(struct platform_device *pdev)
> >>  	if (IS_ERR(regmap))
> >>  		return PTR_ERR(regmap);
> >>
> >> -	priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> >> +	priv->rstc = devm_reset_control_array_get_exclusive(&pdev->dev);
> >>  	if (IS_ERR(priv->rstc))
> >>  		return dev_err_probe(dev, PTR_ERR(priv->rstc),
> >>  				     "failed to get reset\n");
> >> --
> >> 2.39.2
> >

Re: [PATCH 07/16] reset: rzg2l-usbphy-ctrl: Get reset control array

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Before accessing the USB area of the RZ/G3S SoC the PWRRDY bit of the
> SYS_USB_PWRRDY register need to be cleared. When USB area is not used the
> PWRRDY bit of the SYS_USB_PWRRDY register need to be set. This register is
> in the SYSC controller address space and the assert/de-assert of the
> signal handled by SYSC_USB_PWRRDY was implemented as a reset signal.
>
> The USB modules available on the RZ/G3S SoC that need this bit set are:
> - USB ch0 (supporting host and peripheral mode)
> - USB ch2 (supporting host mode)
> - USBPHY control
>
> As the USBPHY control is the root device for all the other USB channels
> (USB ch0, USB ch1) add support to set the PWRRDY for the USB area when
> initializing the USBPHY control. As this is done though reset signals
> get the reset array in the USBPHY control driver.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add support for RZ/G3S SoC. It needs its own compatible as it uses 2
reset signals and it cannot work w/o both of them. To be able to
fully validate this on DT schema, too, the RZ/G3S uses it's own compatible
w/o a fallback (as if the fallback will be used the RZ/G3S will not work
anyway).

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
index 8b64c12f3bec..08b18d7de7ad 100644
--- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
+++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
@@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
 
 static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
 	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
+	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
 	{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
-- 
2.39.2

RE: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea@tuxon.dev>
> Sent: Thursday, August 22, 2024 4:28 PM
> Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
> 
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2 reset signals and it cannot work
> w/o both of them. To be able to fully validate this on DT schema, too, the RZ/G3S uses it's own
> compatible w/o a fallback (as if the fallback will be used the RZ/G3S will not work anyway).

Other than reset/ power domain approach for handling USBPWRRDY signal

Can't USBPWRRDY signal handled in SYSC driver directly? Since SYSC driver init happens at very early boot stage
Check for USBPHY control device availability and handle USBPWRRDY signal there??

Cheers,
Biju

> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> index 8b64c12f3bec..08b18d7de7ad 100644
> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> @@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
> 
>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
> +	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
>  	{ /* Sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
> --
> 2.39.2

Re: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S

[claudiu beznea]

Hi, Biju,

On 22.08.2024 19:59, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Claudiu <claudiu.beznea@tuxon.dev>
>> Sent: Thursday, August 22, 2024 4:28 PM
>> Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
>>
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2 reset signals and it cannot work
>> w/o both of them. To be able to fully validate this on DT schema, too, the RZ/G3S uses it's own
>> compatible w/o a fallback (as if the fallback will be used the RZ/G3S will not work anyway).
> 
> Other than reset/ power domain approach for handling USBPWRRDY signal
> 
> Can't USBPWRRDY signal handled in SYSC driver directly? Since SYSC driver init happens at very early boot stage
> Check for USBPHY control device availability and handle USBPWRRDY signal there??

In theory, it can be done this way, too.  The downside I see at the moment
with this approach would be that the USB, PCIe drivers will not be in
charge with handling their signals, there will be no direct dependency
available b/w SYSC and USB drivers.

The HW manual doesn't mention anything about the power consumption of the
USB, PCI areas based on the state of the signals from SYSC, so, I don't
know if there will be any implication on this if the signals will be just
de-asserted from the SYSC driver.


Thank you,
Claudiu Beznea


> Cheers,
> Biju
> 
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> index 8b64c12f3bec..08b18d7de7ad 100644
>> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
>> @@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct reset_controller_dev *rcdev,
>>
>>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
>>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
>> +	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
>>  	{ /* Sentinel */ }
>>  };
>>  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
>> --
>> 2.39.2
> 

RE: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Friday, August 23, 2024 9:41 AM
> Subject: Re: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S
> 
> Hi, Biju,
> 
> On 22.08.2024 19:59, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea@tuxon.dev>
> >> Sent: Thursday, August 22, 2024 4:28 PM
> >> Subject: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for
> >> RZ/G3S
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2
> >> reset signals and it cannot work w/o both of them. To be able to
> >> fully validate this on DT schema, too, the RZ/G3S uses it's own compatible w/o a fallback (as if
> the fallback will be used the RZ/G3S will not work anyway).
> >
> > Other than reset/ power domain approach for handling USBPWRRDY signal
> >
> > Can't USBPWRRDY signal handled in SYSC driver directly? Since SYSC
> > driver init happens at very early boot stage Check for USBPHY control device availability and handle
> USBPWRRDY signal there??
> 
> In theory, it can be done this way, too.  The downside I see at the moment with this approach would be
> that the USB, PCIe drivers will not be in charge with handling their signals, there will be no direct
> dependency available b/w SYSC and USB drivers.

SYSC driver probe/init will happen before USB driver because of early init calls.
So, I don't think there will be a problem.

Cheers,
Biju



> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >> ---
> >>  drivers/reset/reset-rzg2l-usbphy-ctrl.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> index 8b64c12f3bec..08b18d7de7ad 100644
> >> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c
> >> @@ -93,6 +93,7 @@ static int rzg2l_usbphy_ctrl_status(struct
> >> reset_controller_dev *rcdev,
> >>
> >>  static const struct of_device_id rzg2l_usbphy_ctrl_match_table[] = {
> >>  	{ .compatible = "renesas,rzg2l-usbphy-ctrl" },
> >> +	{ .compatible = "renesas,r9a08g045-usbphy-ctrl" },
> >>  	{ /* Sentinel */ }
> >>  };
> >>  MODULE_DEVICE_TABLE(of, rzg2l_usbphy_ctrl_match_table);
> >> --
> >> 2.39.2
> >

Re: [PATCH 08/16] reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Add support for RZ/G3S SoC. It needs its own compatible as it uses 2
> reset signals and it cannot work w/o both of them. To be able to
> fully validate this on DT schema, too, the RZ/G3S uses it's own compatible

its

> w/o a fallback (as if the fallback will be used the RZ/G3S will not work
> anyway).
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 09/16] dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The USBHS IP block on RZ/G3S SoC is identitcal to the one found on the
RZ/G2L device. Document the RZ/G3S USBHS IP block.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
index c63db3ebd07b..0f84cba872ce 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
@@ -26,6 +26,7 @@ properties:
               - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five
               - renesas,usbhs-r9a07g044 # RZ/G2{L,LC}
               - renesas,usbhs-r9a07g054 # RZ/V2L
+              - renesas,usbhs-r9a08g045 # RZ/G3S
           - const: renesas,rzg2l-usbhs
 
       - items:
@@ -126,6 +127,7 @@ allOf:
               - renesas,usbhs-r9a07g043
               - renesas,usbhs-r9a07g044
               - renesas,usbhs-r9a07g054
+              - renesas,usbhs-r9a08g045
     then:
       properties:
         interrupts:
-- 
2.39.2

Re: [PATCH 09/16] dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Thu, Aug 22, 2024 at 06:27:54PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> The USBHS IP block on RZ/G3S SoC is identitcal to the one found on the
> RZ/G2L device. Document the RZ/G3S USBHS IP block.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 09/16] dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The USBHS IP block on RZ/G3S SoC is identitcal to the one found on the
> RZ/G2L device. Document the RZ/G3S USBHS IP block.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

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

> --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> @@ -26,6 +26,7 @@ properties:
>                - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five
>                - renesas,usbhs-r9a07g044 # RZ/G2{L,LC}
>                - renesas,usbhs-r9a07g054 # RZ/V2L
> +              - renesas,usbhs-r9a08g045 # RZ/G3S
>            - const: renesas,rzg2l-usbhs
>
>        - items:

So we do have new users of the HS-USB block!
If you do have a need for renesas,enable-gpios, it may be a good idea
to proceed as per the discussion in "[PATCH 1/2] dt-bindings: usb:
renesas,usbhs: Deprecate renesas,enable-gpio"
(https://lore.kernel.org/all/20241002213652.GA1330004-robh@kernel.org/).

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 09/16] dt-bindings: usb: renesas,usbhs: Document RZ/G3S SoC

[claudiu beznea]

Hi, Geert,

On 08.10.2024 17:51, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The USBHS IP block on RZ/G3S SoC is identitcal to the one found on the
>> RZ/G2L device. Document the RZ/G3S USBHS IP block.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
>> --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
>> +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
>> @@ -26,6 +26,7 @@ properties:
>>                - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five
>>                - renesas,usbhs-r9a07g044 # RZ/G2{L,LC}
>>                - renesas,usbhs-r9a07g054 # RZ/V2L
>> +              - renesas,usbhs-r9a08g045 # RZ/G3S
>>            - const: renesas,rzg2l-usbhs
>>
>>        - items:
> 
> So we do have new users of the HS-USB block!
> If you do have a need for renesas,enable-gpios, it may be a good idea
> to proceed as per the discussion in "[PATCH 1/2] dt-bindings: usb:
> renesas,usbhs: Deprecate renesas,enable-gpio"
> (https://lore.kernel.org/all/20241002213652.GA1330004-robh@kernel.org/).

Thank you for letting me know. As of my current investigation there is no
need for this property. I'll keep it in mind, anyway.

Thank you,
Claudiu Beznea

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

[PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The Renesas RZ/G3S need to initialize the USB BUS before transferring data
due to hardware limitation. As the register that need to be touched for
this is in the address space of the USB PHY, and the UBS PHY need to be
initialized before any other USB drivers handling data transfer, add
support to initialize the USB BUS.

As the USB PHY is probed before any other USB drivers that enables
clocks and de-assert the reset signals and the BUS initialization is done
in the probe phase, we need to add code to de-assert reset signal and
runtime resume the device (which enables its clocks) before accessing
the registers.

As the reset signals are not required by the USB PHY driver for the other
USB PHY hardware variants, the reset signals and runtime PM was handled
only in the function that initialize the USB BUS.

The PHY initialization was done right after runtime PM enable to have
all in place when the PHYs are registered.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50 ++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 7594f64eb737..cf4299cea579 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -19,12 +19,14 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
+#include <linux/reset.h>
 #include <linux/string.h>
 #include <linux/usb/of.h>
 #include <linux/workqueue.h>
 
 /******* USB2.0 Host registers (original offset is +0x200) *******/
 #define USB2_INT_ENABLE		0x000
+#define USB2_AHB_BUS_CTR	0x008
 #define USB2_USBCTR		0x00c
 #define USB2_SPD_RSM_TIMSET	0x10c
 #define USB2_OC_TIMSET		0x110
@@ -40,6 +42,10 @@
 #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
 #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
 
+/* AHB_BUS_CTR */
+#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
+#define USB2_AHB_BUS_CTR_MBL_INCR4	2
+
 /* USBCTR */
 #define USB2_USBCTR_DIRPD	BIT(2)
 #define USB2_USBCTR_PLL_RST	BIT(1)
@@ -111,6 +117,7 @@ struct rcar_gen3_chan {
 	struct extcon_dev *extcon;
 	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
 	struct regulator *vbus;
+	struct reset_control *rstc;
 	struct work_struct work;
 	struct mutex lock;	/* protects rphys[...].powered */
 	enum usb_dr_mode dr_mode;
@@ -125,6 +132,7 @@ struct rcar_gen3_chan {
 struct rcar_gen3_phy_drv_data {
 	const struct phy_ops *phy_usb2_ops;
 	bool no_adp_ctrl;
+	bool init_bus;
 };
 
 /*
@@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
 	return candidate;
 }
 
+static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
+{
+	struct device *dev = channel->dev;
+	int ret;
+	u32 val;
+
+	channel->rstc = devm_reset_control_array_get_shared(dev);
+	if (IS_ERR(channel->rstc))
+		return PTR_ERR(channel->rstc);
+
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret)
+		return ret;
+
+	ret = reset_control_deassert(channel->rstc);
+	if (ret)
+		goto rpm_put;
+
+	val = readl(channel->base + USB2_AHB_BUS_CTR);
+	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
+	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
+	writel(val, channel->base + USB2_AHB_BUS_CTR);
+
+rpm_put:
+	pm_runtime_put(dev);
+
+	return ret;
+}
+
 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 {
 	const struct rcar_gen3_phy_drv_data *phy_data;
@@ -703,6 +740,15 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 		goto error;
 	}
 
+	platform_set_drvdata(pdev, channel);
+	channel->dev = dev;
+
+	if (phy_data->init_bus) {
+		ret = rcar_gen3_phy_usb2_init_bus(channel);
+		if (ret)
+			goto error;
+	}
+
 	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
 	if (phy_data->no_adp_ctrl)
 		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN;
@@ -733,9 +779,6 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 		channel->vbus = NULL;
 	}
 
-	platform_set_drvdata(pdev, channel);
-	channel->dev = dev;
-
 	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
 	if (IS_ERR(provider)) {
 		dev_err(dev, "Failed to register PHY provider\n");
@@ -762,6 +805,7 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
 	if (channel->is_otg_channel)
 		device_remove_file(&pdev->dev, &dev_attr_role);
 
+	reset_control_assert(channel->rstc);
 	pm_runtime_disable(&pdev->dev);
 };
 
-- 
2.39.2

RE: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea@tuxon.dev>
> Sent: Thursday, August 22, 2024 4:28 PM
> Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
> 
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware limitation.
> As the register that need to be touched for this is in the address space of the USB PHY, and the UBS
> PHY need to be initialized before any other USB drivers handling data transfer, add support to
> initialize the USB BUS.
> 
> As the USB PHY is probed before any other USB drivers that enables clocks and de-assert the reset
> signals and the BUS initialization is done in the probe phase, we need to add code to de-assert reset
> signal and runtime resume the device (which enables its clocks) before accessing the registers.
> 
> As the reset signals are not required by the USB PHY driver for the other USB PHY hardware variants,
> the reset signals and runtime PM was handled only in the function that initialize the USB BUS.
> 
> The PHY initialization was done right after runtime PM enable to have all in place when the PHYs are
> registered.

There is no user for this patch. The first user is RZ/G3S and you should merge this patch with
next one.

Cheers,
Biju

> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50 ++++++++++++++++++++++--
>  1 file changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index 7594f64eb737..cf4299cea579 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -19,12 +19,14 @@
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
>  #include <linux/string.h>
>  #include <linux/usb/of.h>
>  #include <linux/workqueue.h>
> 
>  /******* USB2.0 Host registers (original offset is +0x200) *******/
>  #define USB2_INT_ENABLE		0x000
> +#define USB2_AHB_BUS_CTR	0x008
>  #define USB2_USBCTR		0x00c
>  #define USB2_SPD_RSM_TIMSET	0x10c
>  #define USB2_OC_TIMSET		0x110
> @@ -40,6 +42,10 @@
>  #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
>  #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
> 
> +/* AHB_BUS_CTR */
> +#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
> +#define USB2_AHB_BUS_CTR_MBL_INCR4	2
> +
>  /* USBCTR */
>  #define USB2_USBCTR_DIRPD	BIT(2)
>  #define USB2_USBCTR_PLL_RST	BIT(1)
> @@ -111,6 +117,7 @@ struct rcar_gen3_chan {
>  	struct extcon_dev *extcon;
>  	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
>  	struct regulator *vbus;
> +	struct reset_control *rstc;
>  	struct work_struct work;
>  	struct mutex lock;	/* protects rphys[...].powered */
>  	enum usb_dr_mode dr_mode;
> @@ -125,6 +132,7 @@ struct rcar_gen3_chan {  struct rcar_gen3_phy_drv_data {
>  	const struct phy_ops *phy_usb2_ops;
>  	bool no_adp_ctrl;
> +	bool init_bus;
>  };
> 
>  /*
> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
>  	return candidate;
>  }
> 
> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
> +{
> +	struct device *dev = channel->dev;
> +	int ret;
> +	u32 val;
> +
> +	channel->rstc = devm_reset_control_array_get_shared(dev);
> +	if (IS_ERR(channel->rstc))
> +		return PTR_ERR(channel->rstc);
> +
> +	ret = pm_runtime_resume_and_get(dev);
> +	if (ret)
> +		return ret;
> +
> +	ret = reset_control_deassert(channel->rstc);
> +	if (ret)
> +		goto rpm_put;
> +
> +	val = readl(channel->base + USB2_AHB_BUS_CTR);
> +	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
> +	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
> +	writel(val, channel->base + USB2_AHB_BUS_CTR);
> +
> +rpm_put:
> +	pm_runtime_put(dev);
> +
> +	return ret;
> +}
> +
>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)  {
>  	const struct rcar_gen3_phy_drv_data *phy_data; @@ -703,6 +740,15 @@ static int
> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>  		goto error;
>  	}
> 
> +	platform_set_drvdata(pdev, channel);
> +	channel->dev = dev;
> +
> +	if (phy_data->init_bus) {
> +		ret = rcar_gen3_phy_usb2_init_bus(channel);
> +		if (ret)
> +			goto error;
> +	}
> +
>  	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
>  	if (phy_data->no_adp_ctrl)
>  		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN; @@ -733,9 +779,6 @@ static int
> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>  		channel->vbus = NULL;
>  	}
> 
> -	platform_set_drvdata(pdev, channel);
> -	channel->dev = dev;
> -
>  	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
>  	if (IS_ERR(provider)) {
>  		dev_err(dev, "Failed to register PHY provider\n"); @@ -762,6 +805,7 @@ static void
> rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
>  	if (channel->is_otg_channel)
>  		device_remove_file(&pdev->dev, &dev_attr_role);
> 
> +	reset_control_assert(channel->rstc);
>  	pm_runtime_disable(&pdev->dev);
>  };
> 
> --
> 2.39.2

Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[claudiu beznea]

Hi, Biju,

On 23.08.2024 10:35, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Claudiu <claudiu.beznea@tuxon.dev>
>> Sent: Thursday, August 22, 2024 4:28 PM
>> Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
>>
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware limitation.
>> As the register that need to be touched for this is in the address space of the USB PHY, and the UBS
>> PHY need to be initialized before any other USB drivers handling data transfer, add support to
>> initialize the USB BUS.
>>
>> As the USB PHY is probed before any other USB drivers that enables clocks and de-assert the reset
>> signals and the BUS initialization is done in the probe phase, we need to add code to de-assert reset
>> signal and runtime resume the device (which enables its clocks) before accessing the registers.
>>
>> As the reset signals are not required by the USB PHY driver for the other USB PHY hardware variants,
>> the reset signals and runtime PM was handled only in the function that initialize the USB BUS.
>>
>> The PHY initialization was done right after runtime PM enable to have all in place when the PHYs are
>> registered.
> 
> There is no user for this patch. The first user is RZ/G3S and you should merge this patch with
> next one.

I think this is a matter of taste... This is how I usually format the
patches (for scenarios like this) and got no request for squashing.

Anyway, I can do it your way, too.

Thank you,
Claudiu Beznea

> 
> Cheers,
> Biju
> 
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> ---
>>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50 ++++++++++++++++++++++--
>>  1 file changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> index 7594f64eb737..cf4299cea579 100644
>> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> @@ -19,12 +19,14 @@
>>  #include <linux/platform_device.h>
>>  #include <linux/pm_runtime.h>
>>  #include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>>  #include <linux/string.h>
>>  #include <linux/usb/of.h>
>>  #include <linux/workqueue.h>
>>
>>  /******* USB2.0 Host registers (original offset is +0x200) *******/
>>  #define USB2_INT_ENABLE		0x000
>> +#define USB2_AHB_BUS_CTR	0x008
>>  #define USB2_USBCTR		0x00c
>>  #define USB2_SPD_RSM_TIMSET	0x10c
>>  #define USB2_OC_TIMSET		0x110
>> @@ -40,6 +42,10 @@
>>  #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
>>  #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
>>
>> +/* AHB_BUS_CTR */
>> +#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
>> +#define USB2_AHB_BUS_CTR_MBL_INCR4	2
>> +
>>  /* USBCTR */
>>  #define USB2_USBCTR_DIRPD	BIT(2)
>>  #define USB2_USBCTR_PLL_RST	BIT(1)
>> @@ -111,6 +117,7 @@ struct rcar_gen3_chan {
>>  	struct extcon_dev *extcon;
>>  	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
>>  	struct regulator *vbus;
>> +	struct reset_control *rstc;
>>  	struct work_struct work;
>>  	struct mutex lock;	/* protects rphys[...].powered */
>>  	enum usb_dr_mode dr_mode;
>> @@ -125,6 +132,7 @@ struct rcar_gen3_chan {  struct rcar_gen3_phy_drv_data {
>>  	const struct phy_ops *phy_usb2_ops;
>>  	bool no_adp_ctrl;
>> +	bool init_bus;
>>  };
>>
>>  /*
>> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
>>  	return candidate;
>>  }
>>
>> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
>> +{
>> +	struct device *dev = channel->dev;
>> +	int ret;
>> +	u32 val;
>> +
>> +	channel->rstc = devm_reset_control_array_get_shared(dev);
>> +	if (IS_ERR(channel->rstc))
>> +		return PTR_ERR(channel->rstc);
>> +
>> +	ret = pm_runtime_resume_and_get(dev);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = reset_control_deassert(channel->rstc);
>> +	if (ret)
>> +		goto rpm_put;
>> +
>> +	val = readl(channel->base + USB2_AHB_BUS_CTR);
>> +	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
>> +	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
>> +	writel(val, channel->base + USB2_AHB_BUS_CTR);
>> +
>> +rpm_put:
>> +	pm_runtime_put(dev);
>> +
>> +	return ret;
>> +}
>> +
>>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)  {
>>  	const struct rcar_gen3_phy_drv_data *phy_data; @@ -703,6 +740,15 @@ static int
>> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>  		goto error;
>>  	}
>>
>> +	platform_set_drvdata(pdev, channel);
>> +	channel->dev = dev;
>> +
>> +	if (phy_data->init_bus) {
>> +		ret = rcar_gen3_phy_usb2_init_bus(channel);
>> +		if (ret)
>> +			goto error;
>> +	}
>> +
>>  	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
>>  	if (phy_data->no_adp_ctrl)
>>  		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN; @@ -733,9 +779,6 @@ static int
>> rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>  		channel->vbus = NULL;
>>  	}
>>
>> -	platform_set_drvdata(pdev, channel);
>> -	channel->dev = dev;
>> -
>>  	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
>>  	if (IS_ERR(provider)) {
>>  		dev_err(dev, "Failed to register PHY provider\n"); @@ -762,6 +805,7 @@ static void
>> rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
>>  	if (channel->is_otg_channel)
>>  		device_remove_file(&pdev->dev, &dev_attr_role);
>>
>> +	reset_control_assert(channel->rstc);
>>  	pm_runtime_disable(&pdev->dev);
>>  };
>>
>> --
>> 2.39.2
> 

RE: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Friday, August 23, 2024 9:58 AM
-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> Subject: Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
> 
> Hi, Biju,
> 
> On 23.08.2024 10:35, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea@tuxon.dev>
> >> Sent: Thursday, August 22, 2024 4:28 PM
> >> Subject: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to
> >> initialize the bus
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware
> limitation.
> >> As the register that need to be touched for this is in the address
> >> space of the USB PHY, and the UBS PHY need to be initialized before
> >> any other USB drivers handling data transfer, add support to initialize the USB BUS.
> >>
> >> As the USB PHY is probed before any other USB drivers that enables
> >> clocks and de-assert the reset signals and the BUS initialization is
> >> done in the probe phase, we need to add code to de-assert reset signal and runtime resume the
> device (which enables its clocks) before accessing the registers.
> >>
> >> As the reset signals are not required by the USB PHY driver for the
> >> other USB PHY hardware variants, the reset signals and runtime PM was handled only in the function
> that initialize the USB BUS.
> >>
> >> The PHY initialization was done right after runtime PM enable to have
> >> all in place when the PHYs are registered.
> >
> > There is no user for this patch. The first user is RZ/G3S and you
> > should merge this patch with next one.
> 
> I think this is a matter of taste... This is how I usually format the patches (for scenarios like
> this) and got no request for squashing.

That is strange for trivial patches like this.

Cheers,
Biju



> >
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >> ---
> >>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 50
> >> ++++++++++++++++++++++--
> >>  1 file changed, 47 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> index 7594f64eb737..cf4299cea579 100644
> >> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> >> @@ -19,12 +19,14 @@
> >>  #include <linux/platform_device.h>
> >>  #include <linux/pm_runtime.h>
> >>  #include <linux/regulator/consumer.h>
> >> +#include <linux/reset.h>
> >>  #include <linux/string.h>
> >>  #include <linux/usb/of.h>
> >>  #include <linux/workqueue.h>
> >>
> >>  /******* USB2.0 Host registers (original offset is +0x200) *******/
> >>  #define USB2_INT_ENABLE		0x000
> >> +#define USB2_AHB_BUS_CTR	0x008
> >>  #define USB2_USBCTR		0x00c
> >>  #define USB2_SPD_RSM_TIMSET	0x10c
> >>  #define USB2_OC_TIMSET		0x110
> >> @@ -40,6 +42,10 @@
> >>  #define USB2_INT_ENABLE_USBH_INTB_EN	BIT(2)	/* For EHCI */
> >>  #define USB2_INT_ENABLE_USBH_INTA_EN	BIT(1)	/* For OHCI */
> >>
> >> +/* AHB_BUS_CTR */
> >> +#define USB2_AHB_BUS_CTR_MBL_MASK	GENMASK(1, 0)
> >> +#define USB2_AHB_BUS_CTR_MBL_INCR4	2
> >> +
> >>  /* USBCTR */
> >>  #define USB2_USBCTR_DIRPD	BIT(2)
> >>  #define USB2_USBCTR_PLL_RST	BIT(1)
> >> @@ -111,6 +117,7 @@ struct rcar_gen3_chan {
> >>  	struct extcon_dev *extcon;
> >>  	struct rcar_gen3_phy rphys[NUM_OF_PHYS];
> >>  	struct regulator *vbus;
> >> +	struct reset_control *rstc;
> >>  	struct work_struct work;
> >>  	struct mutex lock;	/* protects rphys[...].powered */
> >>  	enum usb_dr_mode dr_mode;
> >> @@ -125,6 +132,7 @@ struct rcar_gen3_chan {  struct rcar_gen3_phy_drv_data {
> >>  	const struct phy_ops *phy_usb2_ops;
> >>  	bool no_adp_ctrl;
> >> +	bool init_bus;
> >>  };
> >>
> >>  /*
> >> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
> >>  	return candidate;
> >>  }
> >>
> >> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan
> >> +*channel) {
> >> +	struct device *dev = channel->dev;
> >> +	int ret;
> >> +	u32 val;
> >> +
> >> +	channel->rstc = devm_reset_control_array_get_shared(dev);
> >> +	if (IS_ERR(channel->rstc))
> >> +		return PTR_ERR(channel->rstc);
> >> +
> >> +	ret = pm_runtime_resume_and_get(dev);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	ret = reset_control_deassert(channel->rstc);
> >> +	if (ret)
> >> +		goto rpm_put;
> >> +
> >> +	val = readl(channel->base + USB2_AHB_BUS_CTR);
> >> +	val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
> >> +	val |= USB2_AHB_BUS_CTR_MBL_INCR4;
> >> +	writel(val, channel->base + USB2_AHB_BUS_CTR);
> >> +
> >> +rpm_put:
> >> +	pm_runtime_put(dev);
> >> +
> >> +	return ret;
> >> +}
> >> +
> >>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)  {
> >>  	const struct rcar_gen3_phy_drv_data *phy_data; @@ -703,6 +740,15 @@
> >> static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
> >>  		goto error;
> >>  	}
> >>
> >> +	platform_set_drvdata(pdev, channel);
> >> +	channel->dev = dev;
> >> +
> >> +	if (phy_data->init_bus) {
> >> +		ret = rcar_gen3_phy_usb2_init_bus(channel);
> >> +		if (ret)
> >> +			goto error;
> >> +	}
> >> +
> >>  	channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
> >>  	if (phy_data->no_adp_ctrl)
> >>  		channel->obint_enable_bits = USB2_OBINT_IDCHG_EN; @@ -733,9 +779,6
> >> @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
> >>  		channel->vbus = NULL;
> >>  	}
> >>
> >> -	platform_set_drvdata(pdev, channel);
> >> -	channel->dev = dev;
> >> -
> >>  	provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
> >>  	if (IS_ERR(provider)) {
> >>  		dev_err(dev, "Failed to register PHY provider\n"); @@ -762,6
> >> +805,7 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
> >>  	if (channel->is_otg_channel)
> >>  		device_remove_file(&pdev->dev, &dev_attr_role);
> >>
> >> +	reset_control_assert(channel->rstc);
> >>  	pm_runtime_disable(&pdev->dev);
> >>  };
> >>
> >> --
> >> 2.39.2
> >

Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[Vinod Koul]

On 23-08-24, 09:01, Biju Das wrote:
> > >> The Renesas RZ/G3S need to initialize the USB BUS before transferring data due to hardware
> > limitation.
> > >> As the register that need to be touched for this is in the address
> > >> space of the USB PHY, and the UBS PHY need to be initialized before
> > >> any other USB drivers handling data transfer, add support to initialize the USB BUS.
> > >>
> > >> As the USB PHY is probed before any other USB drivers that enables
> > >> clocks and de-assert the reset signals and the BUS initialization is
> > >> done in the probe phase, we need to add code to de-assert reset signal and runtime resume the
> > device (which enables its clocks) before accessing the registers.
> > >>
> > >> As the reset signals are not required by the USB PHY driver for the
> > >> other USB PHY hardware variants, the reset signals and runtime PM was handled only in the function
> > that initialize the USB BUS.
> > >>
> > >> The PHY initialization was done right after runtime PM enable to have
> > >> all in place when the PHYs are registered.
> > >
> > > There is no user for this patch. The first user is RZ/G3S and you
> > > should merge this patch with next one.
> > 
> > I think this is a matter of taste... This is how I usually format the patches (for scenarios like
> > this) and got no request for squashing.
> 
> That is strange for trivial patches like this.

Splitting is better, this patch does one thing whereas the next one uses
it adds in new device, i would say quite a clean approach

NOTE: Don't quote the not required context while replying, it is good
mail list hygiene

-- 
~Vinod

RE: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[Biju Das]

Hi Vinod,

> -----Original Message-----
> From: Vinod Koul <vkoul@kernel.org>
> Sent: Friday, August 30, 2024 9:03 AM
> Subject: Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
> 
> On 23-08-24, 09:01, Biju Das wrote:
> > > >> The Renesas RZ/G3S need to initialize the USB BUS before
> > > >> transferring data due to hardware
> > > limitation.
> > > >> As the register that need to be touched for this is in the
> > > >> address space of the USB PHY, and the UBS PHY need to be
> > > >> initialized before any other USB drivers handling data transfer, add support to initialize the
> USB BUS.
> > > >>
> > > >> As the USB PHY is probed before any other USB drivers that
> > > >> enables clocks and de-assert the reset signals and the BUS
> > > >> initialization is done in the probe phase, we need to add code to
> > > >> de-assert reset signal and runtime resume the
> > > device (which enables its clocks) before accessing the registers.
> > > >>
> > > >> As the reset signals are not required by the USB PHY driver for
> > > >> the other USB PHY hardware variants, the reset signals and
> > > >> runtime PM was handled only in the function
> > > that initialize the USB BUS.
> > > >>
> > > >> The PHY initialization was done right after runtime PM enable to
> > > >> have all in place when the PHYs are registered.
> > > >
> > > > There is no user for this patch. The first user is RZ/G3S and you
> > > > should merge this patch with next one.
> > >
> > > I think this is a matter of taste... This is how I usually format
> > > the patches (for scenarios like
> > > this) and got no request for squashing.
> >
> > That is strange for trivial patches like this.
> 
> Splitting is better, this patch does one thing whereas the next one uses it adds in new device, i
> would say quite a clean approach
> 
> NOTE: Don't quote the not required context while replying, it is good mail list hygiene

Agreed. I was wrong then. To support a new device, bus initialization is required.
So I thought it should go together.

Cheers,
Biju

Re: [PATCH 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The Renesas RZ/G3S need to initialize the USB BUS before transferring data
> due to hardware limitation. As the register that need to be touched for
> this is in the address space of the USB PHY, and the UBS PHY need to be
> initialized before any other USB drivers handling data transfer, add
> support to initialize the USB BUS.
>
> As the USB PHY is probed before any other USB drivers that enables
> clocks and de-assert the reset signals and the BUS initialization is done
> in the probe phase, we need to add code to de-assert reset signal and
> runtime resume the device (which enables its clocks) before accessing
> the registers.
>
> As the reset signals are not required by the USB PHY driver for the other
> USB PHY hardware variants, the reset signals and runtime PM was handled
> only in the function that initialize the USB BUS.
>
> The PHY initialization was done right after runtime PM enable to have
> all in place when the PHYs are registered.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch, which is now commit 4eae16375357a2a7 ("phy:
renesas: rcar-gen3-usb2: Add support to initialize the bus") in
v6.12-rc1.

> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
>         return candidate;
>  }
>
> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
> +{
> +       struct device *dev = channel->dev;
> +       int ret;
> +       u32 val;
> +
> +       channel->rstc = devm_reset_control_array_get_shared(dev);
> +       if (IS_ERR(channel->rstc))
> +               return PTR_ERR(channel->rstc);
> +
> +       ret = pm_runtime_resume_and_get(dev);
> +       if (ret)
> +               return ret;
> +
> +       ret = reset_control_deassert(channel->rstc);
> +       if (ret)
> +               goto rpm_put;
> +
> +       val = readl(channel->base + USB2_AHB_BUS_CTR);
> +       val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
> +       val |= USB2_AHB_BUS_CTR_MBL_INCR4;
> +       writel(val, channel->base + USB2_AHB_BUS_CTR);
> +
> +rpm_put:
> +       pm_runtime_put(dev);
> +
> +       return ret;
> +}
> +
>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>  {
>         const struct rcar_gen3_phy_drv_data *phy_data;
> @@ -703,6 +740,15 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>                 goto error;
>         }
>
> +       platform_set_drvdata(pdev, channel);
> +       channel->dev = dev;

Unrelated change?

> +
> +       if (phy_data->init_bus) {
> +               ret = rcar_gen3_phy_usb2_init_bus(channel);
> +               if (ret)
> +                       goto error;
> +       }
> +
>         channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
>         if (phy_data->no_adp_ctrl)
>                 channel->obint_enable_bits = USB2_OBINT_IDCHG_EN;
> @@ -733,9 +779,6 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>                 channel->vbus = NULL;
>         }
>
> -       platform_set_drvdata(pdev, channel);
> -       channel->dev = dev;
> -
>         provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
>         if (IS_ERR(provider)) {
>                 dev_err(dev, "Failed to register PHY provider\n");

The reset is not asserted in the error path, only in .remove().

Oh, Christophe already sent a fix for that...
"[PATCH v3] phy: renesas: rcar-gen3-usb2: Fix an error handling path
in rcar_gen3_phy_usb2_probe()"
https://lore.kernel.org/all/290b25827e3f0742808940719455ff0c5cb9d01d.1726329925.git.christophe.jaillet@wanadoo.fr

> @@ -762,6 +805,7 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
>         if (channel->is_otg_channel)
>                 device_remove_file(&pdev->dev, &dev_attr_role);
>
> +       reset_control_assert(channel->rstc);
>         pm_runtime_disable(&pdev->dev);
>  };

The rest LGTM.

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 10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus

[claudiu beznea]

Hi, Geert,

On 08.10.2024 17:57, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> The Renesas RZ/G3S need to initialize the USB BUS before transferring data
>> due to hardware limitation. As the register that need to be touched for
>> this is in the address space of the USB PHY, and the UBS PHY need to be
>> initialized before any other USB drivers handling data transfer, add
>> support to initialize the USB BUS.
>>
>> As the USB PHY is probed before any other USB drivers that enables
>> clocks and de-assert the reset signals and the BUS initialization is done
>> in the probe phase, we need to add code to de-assert reset signal and
>> runtime resume the device (which enables its clocks) before accessing
>> the registers.
>>
>> As the reset signals are not required by the USB PHY driver for the other
>> USB PHY hardware variants, the reset signals and runtime PM was handled
>> only in the function that initialize the USB BUS.
>>
>> The PHY initialization was done right after runtime PM enable to have
>> all in place when the PHYs are registered.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Thanks for your patch, which is now commit 4eae16375357a2a7 ("phy:
> renesas: rcar-gen3-usb2: Add support to initialize the bus") in
> v6.12-rc1.
> 
>> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
>> @@ -650,6 +658,35 @@ static enum usb_dr_mode rcar_gen3_get_dr_mode(struct device_node *np)
>>         return candidate;
>>  }
>>
>> +static int rcar_gen3_phy_usb2_init_bus(struct rcar_gen3_chan *channel)
>> +{
>> +       struct device *dev = channel->dev;
>> +       int ret;
>> +       u32 val;
>> +
>> +       channel->rstc = devm_reset_control_array_get_shared(dev);
>> +       if (IS_ERR(channel->rstc))
>> +               return PTR_ERR(channel->rstc);
>> +
>> +       ret = pm_runtime_resume_and_get(dev);
>> +       if (ret)
>> +               return ret;
>> +
>> +       ret = reset_control_deassert(channel->rstc);
>> +       if (ret)
>> +               goto rpm_put;
>> +
>> +       val = readl(channel->base + USB2_AHB_BUS_CTR);
>> +       val &= ~USB2_AHB_BUS_CTR_MBL_MASK;
>> +       val |= USB2_AHB_BUS_CTR_MBL_INCR4;
>> +       writel(val, channel->base + USB2_AHB_BUS_CTR);
>> +
>> +rpm_put:
>> +       pm_runtime_put(dev);
>> +
>> +       return ret;
>> +}
>> +
>>  static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>  {
>>         const struct rcar_gen3_phy_drv_data *phy_data;
>> @@ -703,6 +740,15 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>                 goto error;
>>         }
>>
>> +       platform_set_drvdata(pdev, channel);
>> +       channel->dev = dev;
> 
> Unrelated change?

That's a leftover from the removal of the suspend to RAM support from the
initial work (internal only) of this series. I'll keep it in mid to remove
it on the following patches, if needed.

> 
>> +
>> +       if (phy_data->init_bus) {
>> +               ret = rcar_gen3_phy_usb2_init_bus(channel);
>> +               if (ret)
>> +                       goto error;
>> +       }
>> +
>>         channel->soc_no_adp_ctrl = phy_data->no_adp_ctrl;
>>         if (phy_data->no_adp_ctrl)
>>                 channel->obint_enable_bits = USB2_OBINT_IDCHG_EN;
>> @@ -733,9 +779,6 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
>>                 channel->vbus = NULL;
>>         }
>>
>> -       platform_set_drvdata(pdev, channel);
>> -       channel->dev = dev;
>> -
>>         provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
>>         if (IS_ERR(provider)) {
>>                 dev_err(dev, "Failed to register PHY provider\n");
> 
> The reset is not asserted in the error path, only in .remove().
> 
> Oh, Christophe already sent a fix for that...
> "[PATCH v3] phy: renesas: rcar-gen3-usb2: Fix an error handling path
> in rcar_gen3_phy_usb2_probe()"
> https://lore.kernel.org/all/290b25827e3f0742808940719455ff0c5cb9d01d.1726329925.git.christophe.jaillet@wanadoo.fr

Yes, I messed this when removing the suspend to RAM from my initial work on
this (internal only). Thanks Christophe for handling it.

Thank you,
Claudiu Beznea

> 
>> @@ -762,6 +805,7 @@ static void rcar_gen3_phy_usb2_remove(struct platform_device *pdev)
>>         if (channel->is_otg_channel)
>>                 device_remove_file(&pdev->dev, &dev_attr_role);
>>
>> +       reset_control_assert(channel->rstc);
>>         pm_runtime_disable(&pdev->dev);
>>  };
> 
> The rest LGTM.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

[PATCH 11/16] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Document the RZ/G3S PHY bindings. The RZ/G3S USB PHY is almost identical
with the RZ/G2L USB PHY. The difference is that there is a hardware
limitation on the max burst size used when the BUS master interface
issues a transfer request for RZ/G3S that is configured though PHY
registers.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index f82649a55e91..af275cea3456 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -13,7 +13,9 @@ properties:
   compatible:
     oneOf:
       - items:
-          - const: renesas,usb2-phy-r8a77470 # RZ/G1C
+          - enum:
+              - renesas,usb2-phy-r8a77470  # RZ/G1C
+              - renesas,usb2-phy-r9a08g045 # RZ/G3S
 
       - items:
           - enum:
-- 
2.39.2

Re: [PATCH 11/16] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Thu, Aug 22, 2024 at 06:27:56PM +0300, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Document the RZ/G3S PHY bindings. The RZ/G3S USB PHY is almost identical
> with the RZ/G2L USB PHY. The difference is that there is a hardware
> limitation on the max burst size used when the BUS master interface
> issues a transfer request for RZ/G3S that is configured though PHY
> registers.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 11/16] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Document the RZ/G3S PHY bindings. The RZ/G3S USB PHY is almost identical
> with the RZ/G2L USB PHY. The difference is that there is a hardware
> limitation on the max burst size used when the BUS master interface
> issues a transfer request for RZ/G3S that is configured though PHY
> registers.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 12/16] phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add support for the Renesas RZ/G3S SoC. The support is similar with the
rest of RZ/G2 devices with the except that the RZ/G3S needs bus
initialization due to hardware limitation.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index cf4299cea579..58e123305152 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -583,6 +583,12 @@ static const struct rcar_gen3_phy_drv_data rz_g2l_phy_usb2_data = {
 	.no_adp_ctrl = true,
 };
 
+static const struct rcar_gen3_phy_drv_data rz_g3s_phy_usb2_data = {
+	.phy_usb2_ops = &rcar_gen3_phy_usb2_ops,
+	.no_adp_ctrl = true,
+	.init_bus = true,
+};
+
 static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
 	{
 		.compatible = "renesas,usb2-phy-r8a77470",
@@ -604,6 +610,10 @@ static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
 		.compatible = "renesas,rzg2l-usb2-phy",
 		.data = &rz_g2l_phy_usb2_data,
 	},
+	{
+		.compatible = "renesas,usb2-phy-r9a08g045",
+		.data = &rz_g3s_phy_usb2_data,
+	},
 	{
 		.compatible = "renesas,rcar-gen3-usb2-phy",
 		.data = &rcar_gen3_phy_usb2_data,
-- 
2.39.2

Re: [PATCH 12/16] phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Add support for the Renesas RZ/G3S SoC. The support is similar with the
> rest of RZ/G2 devices with the except that the RZ/G3S needs bus
> initialization due to hardware limitation.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 13/16] arm64: dts: renesas: Add #reset-cells to system controller node

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

System controller on RZ/G3S can act as a reset controller. Add #reset-cells
for it.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
index 0d5c47a65e46..cd7cefdb2bab 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
@@ -91,6 +91,7 @@ sysc: system-controller@11020000 {
 				     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "lpm_int", "ca55stbydone_int",
 					  "cm33stbyr_int", "ca55_deny";
+			#reset-cells = <1>;
 			status = "disabled";
 		};
 
-- 
2.39.2

Re: [PATCH 13/16] arm64: dts: renesas: Add #reset-cells to system controller node

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> System controller on RZ/G3S can act as a reset controller. Add #reset-cells
> for it.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 14/16] arm64: dts: renesas: r9a08g045: Add USB support

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add USB nodes for the Renesas RZ/G3S SoC. This consists of PHY reset,
host and device support.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 119 +++++++++++++++++++++
 1 file changed, 119 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
index cd7cefdb2bab..c6c279dffccf 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
@@ -7,6 +7,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/r9a08g045-cpg.h>
+#include <dt-bindings/reset/renesas,r9a08g045-sysc.h>
 
 / {
 	compatible = "renesas,r9a08g045";
@@ -265,6 +266,124 @@ eth1: ethernet@11c40000 {
 			status = "disabled";
 		};
 
+		phyrst: usbphy-ctrl@11e00000 {
+			compatible = "renesas,r9a08g045-usbphy-ctrl";
+			reg = <0 0x11e00000 0 0x10000>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+			resets = <&cpg R9A08G045_USB_PRESETN>,
+				 <&sysc R9A08G045_SYSC_RESET_USB>;
+			power-domains = <&cpg>;
+			#reset-cells = <1>;
+			status = "disabled";
+
+			usb0_vbus_otg: regulator-vbus {
+				regulator-name = "vbus";
+			};
+		};
+
+		ohci0: usb@11e10000 {
+			compatible = "generic-ohci";
+			reg = <0 0x11e10000 0 0x100>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			phys = <&usb2_phy0 1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci0: usb@11e10100 {
+			compatible = "generic-ehci";
+			reg = <0 0x11e10100 0 0x100>;
+			interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			phys = <&usb2_phy0 2>;
+			phy-names = "usb";
+			companion = <&ohci0>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		usb2_phy0: usb-phy@11e10200 {
+			compatible = "renesas,usb2-phy-r9a08g045";
+			reg = <0 0x11e10200 0 0x700>;
+			interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H0_HCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2H0_HRESETN>;
+			#phy-cells = <1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		hsusb: usb@11e20000 {
+			compatible = "renesas,usbhs-r9a08g045",
+				     "renesas,rzg2l-usbhs";
+			reg = <0 0x11e20000 0 0x10000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2P_EXR_CPUCLK>;
+			resets = <&phyrst 0>,
+				 <&cpg R9A08G045_USB_U2P_EXL_SYSRST>;
+			renesas,buswait = <7>;
+			phys = <&usb2_phy0 3>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ohci1: usb@11e30000 {
+			compatible = "generic-ohci";
+			reg = <0 0x11e30000 0 0x100>;
+			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			phys = <&usb2_phy1 1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci1: usb@11e30100 {
+			compatible = "generic-ehci";
+			reg = <0 0x11e30100 0 0x100>;
+			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			phys = <&usb2_phy1 2>;
+			phy-names = "usb";
+			companion = <&ohci1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		usb2_phy1: usb-phy@11e30200 {
+			compatible = "renesas,usb2-phy-r9a08g045";
+			reg = <0 0x11e30200 0 0x700>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>,
+				 <&cpg CPG_MOD R9A08G045_USB_U2H1_HCLK>;
+			resets = <&phyrst 1>,
+				 <&cpg R9A08G045_USB_U2H1_HRESETN>;
+			#phy-cells = <1>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
 		gic: interrupt-controller@12400000 {
 			compatible = "arm,gic-v3";
 			#interrupt-cells = <3>;
-- 
2.39.2

Re: [PATCH 14/16] arm64: dts: renesas: r9a08g045: Add USB support

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Add USB nodes for the Renesas RZ/G3S SoC. This consists of PHY reset,
> host and device support.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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 15/16] arm64: dts: renesas: rzg3s-smarc: Enable USB support

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Enable USB support (host, device, USB PHYs and sysc).

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi | 61 ++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
index deb2ad37bb2e..fd9355936803 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
@@ -66,6 +66,29 @@ vccq_sdhi1: regulator-vccq-sdhi1 {
 	};
 };
 
+&ehci0 {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&hsusb {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ohci0 {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
 &pinctrl {
 	key-1-gpio-hog {
 		gpio-hog;
@@ -124,6 +147,27 @@ cd {
 			pinmux = <RZG2L_PORT_PINMUX(0, 2, 1)>; /* SD1_CD */
 		};
 	};
+
+	usb0_pins: usb0 {
+		peri {
+			pinmux = <RZG2L_PORT_PINMUX(5, 0, 1)>, /* VBUS */
+				 <RZG2L_PORT_PINMUX(5, 2, 1)>; /* OVC */
+		};
+
+		otg {
+			pinmux = <RZG2L_PORT_PINMUX(5, 3, 1)>; /* OTG_ID */
+			bias-pull-up;
+		};
+	};
+
+	usb1_pins: usb1 {
+		pinmux = <RZG2L_PORT_PINMUX(5, 4, 5)>, /* OVC */
+			 <RZG2L_PORT_PINMUX(6, 0, 1)>; /* VBUS */
+	};
+};
+
+&phyrst {
+	status = "okay";
 };
 
 &scif0 {
@@ -144,3 +188,20 @@ &sdhi1 {
 	max-frequency = <125000000>;
 	status = "okay";
 };
+
+&sysc {
+	status = "okay";
+};
+
+&usb2_phy0 {
+	pinctrl-0 = <&usb0_pins>;
+	pinctrl-names = "default";
+	vbus-supply = <&usb0_vbus_otg>;
+	status = "okay";
+};
+
+&usb2_phy1 {
+	pinctrl-0 = <&usb1_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+};
-- 
2.39.2

Re: [PATCH 15/16] arm64: dts: renesas: rzg3s-smarc: Enable USB support

[Geert Uytterhoeven]

Hi Claudiu,

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Enable USB support (host, device, USB PHYs and sysc).
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Thanks for your patch!

> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
> @@ -144,3 +188,20 @@ &sdhi1 {
>         max-frequency = <125000000>;
>         status = "okay";
>  };
> +
> +&sysc {
> +       status = "okay";
> +};
> +

To avoid regressions (/sys/devices/soc0/ disappearing), enabling sysc
is a dependency for "[PATCH 05/16] soc: renesas: sysc: Move RZ/G3S
SoC detection on SYSC driver", so I think it makes sense to change
its status to "okay" in r9a08g045.dtsi instead, and spin that off into
its own patch.  I am not super-worried, so doing the driver and DTS
changes in separate patches should be fine, as long as they meet each
other in next or upstream.

The rest LGTM.

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 15/16] arm64: dts: renesas: rzg3s-smarc: Enable USB support

[claudiu beznea]

Hi, Geert,

On 08.10.2024 18:16, Geert Uytterhoeven wrote:
> Hi Claudiu,
> 
> On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> Enable USB support (host, device, USB PHYs and sysc).
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> Thanks for your patch!
> 
>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
>> @@ -144,3 +188,20 @@ &sdhi1 {
>>         max-frequency = <125000000>;
>>         status = "okay";
>>  };
>> +
>> +&sysc {
>> +       status = "okay";
>> +};
>> +
> 
> To avoid regressions (/sys/devices/soc0/ disappearing), enabling sysc
> is a dependency for "[PATCH 05/16] soc: renesas: sysc: Move RZ/G3S
> SoC detection on SYSC driver", so I think it makes sense to change
> its status to "okay" in r9a08g045.dtsi instead, and spin that off into
> its own patch. 

Good point! I'll add the dtsi changes into "[PATCH 05/16] soc: renesas:
sysc: Move RZ/G3S SoC detection on SYSC driver".

Thank you,
Claudiu Beznea

 I am not super-worried, so doing the driver and DTS
> changes in separate patches should be fine, as long as they meet each
> other in next or upstream.
> 
> The rest LGTM.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

[PATCH 16/16] arm64: defconfig: Enable RZ/G3S SYSC reset driver

[Claudiu]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Enable RZ/G3S SYSC reset driver. This exports the control to 2 signals
(one for USB, one for PCI).

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7d32fca64996..4720367a41ea 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1510,6 +1510,7 @@ CONFIG_RESET_IMX7=y
 CONFIG_RESET_QCOM_AOSS=y
 CONFIG_RESET_QCOM_PDC=m
 CONFIG_RESET_RZG2L_USBPHY_CTRL=y
+CONFIG_RESET_RZG3S_SYSC=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_PHY_XGENE=y
 CONFIG_PHY_CAN_TRANSCEIVER=m
-- 
2.39.2

Re: [PATCH 16/16] arm64: defconfig: Enable RZ/G3S SYSC reset driver

[Geert Uytterhoeven]

On Thu, Aug 22, 2024 at 5:28 PM Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Enable RZ/G3S SYSC reset driver. This exports the control to 2 signals
> (one for USB, one for PCI).
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.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

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Ulf Hansson]

On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Hi,
>
> Series adds initial USB support for the Renesas RZ/G3S SoC.
>
> Series is split as follows:
>
> - patch 01/16           - add clock reset and power domain support for USB
> - patch 02-04/16        - add reset control support for a USB signal
>                           that need to be controlled before/after
>                           the power to USB area is turned on/off.
>
>                           Philipp, Ulf, Geert, all,
>
>                           I detailed my approach for this in patch
>                           04/16, please have a look and let me know
>                           your input.

I have looked briefly. Your suggested approach may work, but I have a
few thoughts, see below.

If I understand correctly, it is the consumer driver for the device
that is attached to the USB power domain that becomes responsible for
asserting/de-asserting this new signal. Right?

In this regard, please note that the consumer driver doesn't really
know when the power domain really gets powered-on/off. Calling
pm_runtime_get|put*() is dealing with the reference counting. For
example, a call to pm_runtime_get*() just makes sure that the PM
domain gets-or-remains powered-on. Could this be a problem from the
reset-signal point of view?

[...]

Kind regards
Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

Hi, Ulf,

On 29.08.2024 18:26, Ulf Hansson wrote:
> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>
>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>
>> Hi,
>>
>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>
>> Series is split as follows:
>>
>> - patch 01/16           - add clock reset and power domain support for USB
>> - patch 02-04/16        - add reset control support for a USB signal
>>                           that need to be controlled before/after
>>                           the power to USB area is turned on/off.
>>
>>                           Philipp, Ulf, Geert, all,
>>
>>                           I detailed my approach for this in patch
>>                           04/16, please have a look and let me know
>>                           your input.
> 
> I have looked briefly. Your suggested approach may work, but I have a
> few thoughts, see below.
> 
> If I understand correctly, it is the consumer driver for the device
> that is attached to the USB power domain that becomes responsible for
> asserting/de-asserting this new signal. Right?

Right!

> 
> In this regard, please note that the consumer driver doesn't really
> know when the power domain really gets powered-on/off. Calling
> pm_runtime_get|put*() is dealing with the reference counting. For
> example, a call to pm_runtime_get*() just makes sure that the PM
> domain gets-or-remains powered-on. Could this be a problem from the
> reset-signal point of view?

It should be safe. From the HW manual I understand the hardware block is
something like the following:


                  USB area
         +-------------------------+
         |                         |
         | PHY --->USB controller  |
SYSC --> |  ^                      |
         |  |                      |
         | PHY reset               |
         +-------------------------+

Where:
- SYSC is the system controller that controls the new signal for which
  I'm requesting opinions in this series
- PHY reset: is the block controlling the PHYs
- PHY: is the block controlling the USB PHYs
- USB controller: is the USB controller

Currently, I passed the SYSC signal handling to the PHY reset driver; w/o
PHY reset the rest of the USB logic cannot work (neither PHY block nor USB
controller).

Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe
and pm_runtime_put() in remove. The struct reset_control_ops::{assert,
deassert} only set specific bits in registers (no pm_runtime* calls).

The PHY driver is taking its PHY reset in probe and release it in remove().
With this approach the newly introduced SYSC signal will be
de-asserted/asserted only in the PHY reset probe/remove (either if it is
handled though PM domain or reset control signal).

If the SYSC signal would be passed to all the blocks in the USB area (and
it would be handled though PM domains) it should be no problem either,
AFAICT, because of reference counting the pm_runtime_get|put*() is taking
care of. As the PHY reset is the root node the in the devices node tree for
USB the reference counting should work, too (I may miss something though,
please correct me if I'm wrong).

If the SYSC signal would be handled though a reset control driver (as
proposed in this series) and we want to pass this reference to all the
blocks in the USB area then we can request the reset signal as shared and,
AFAIK, this is also reference counted. The devices node tree should help
with the order, too, if I'm not wrong.

Thank you for looking at this,
Claudiu Beznea

> 
> [...]
> 
> Kind regards
> Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Ulf Hansson]

On Fri, 30 Aug 2024 at 10:22, claudiu beznea <claudiu.beznea@tuxon.dev> wrote:
>
> Hi, Ulf,
>
> On 29.08.2024 18:26, Ulf Hansson wrote:
> > On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> Hi,
> >>
> >> Series adds initial USB support for the Renesas RZ/G3S SoC.
> >>
> >> Series is split as follows:
> >>
> >> - patch 01/16           - add clock reset and power domain support for USB
> >> - patch 02-04/16        - add reset control support for a USB signal
> >>                           that need to be controlled before/after
> >>                           the power to USB area is turned on/off.
> >>
> >>                           Philipp, Ulf, Geert, all,
> >>
> >>                           I detailed my approach for this in patch
> >>                           04/16, please have a look and let me know
> >>                           your input.
> >
> > I have looked briefly. Your suggested approach may work, but I have a
> > few thoughts, see below.
> >
> > If I understand correctly, it is the consumer driver for the device
> > that is attached to the USB power domain that becomes responsible for
> > asserting/de-asserting this new signal. Right?
>
> Right!
>
> >
> > In this regard, please note that the consumer driver doesn't really
> > know when the power domain really gets powered-on/off. Calling
> > pm_runtime_get|put*() is dealing with the reference counting. For
> > example, a call to pm_runtime_get*() just makes sure that the PM
> > domain gets-or-remains powered-on. Could this be a problem from the
> > reset-signal point of view?
>
> It should be safe. From the HW manual I understand the hardware block is
> something like the following:
>
>
>                   USB area
>          +-------------------------+
>          |                         |
>          | PHY --->USB controller  |
> SYSC --> |  ^                      |
>          |  |                      |
>          | PHY reset               |
>          +-------------------------+
>
> Where:
> - SYSC is the system controller that controls the new signal for which
>   I'm requesting opinions in this series
> - PHY reset: is the block controlling the PHYs
> - PHY: is the block controlling the USB PHYs
> - USB controller: is the USB controller
>
> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o
> PHY reset the rest of the USB logic cannot work (neither PHY block nor USB
> controller).
>
> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe
> and pm_runtime_put() in remove. The struct reset_control_ops::{assert,
> deassert} only set specific bits in registers (no pm_runtime* calls).

Thanks for clarifying!

For my understanding, in what register range do these bits belong? Is
it the USB logic or in the PM domain logic, or something else.

>
> The PHY driver is taking its PHY reset in probe and release it in remove().
> With this approach the newly introduced SYSC signal will be
> de-asserted/asserted only in the PHY reset probe/remove (either if it is
> handled though PM domain or reset control signal).
>
> If the SYSC signal would be passed to all the blocks in the USB area (and
> it would be handled though PM domains) it should be no problem either,
> AFAICT, because of reference counting the pm_runtime_get|put*() is taking
> care of. As the PHY reset is the root node the in the devices node tree for
> USB the reference counting should work, too (I may miss something though,
> please correct me if I'm wrong).
>
> If the SYSC signal would be handled though a reset control driver (as
> proposed in this series) and we want to pass this reference to all the
> blocks in the USB area then we can request the reset signal as shared and,
> AFAIK, this is also reference counted. The devices node tree should help
> with the order, too, if I'm not wrong.

Reference counting a reset signal sounds a bit weird to me, but I
guess it can work. :-)

To sum up from my side;

As long as it's fine that we may end up asserting/de-asserting the
reset-signal, without actually knowing if the PM domain is getting
turn-on/off, then using a reset-control like what you propose seems
okay to me.

If not, there are two other options that can be considered I think.
*) Using the genpd on/off notifiers, to really allow the consumer
driver of the reset-control to know when the PM domain gets turned
on/off.
**) Move the entire reset handling into the PM domain provider, as it
obviously knows when the domain is getting turned on/off.

Thanks again for your explanations!

Kind regards
Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 30.08.2024 13:14, Ulf Hansson wrote:
> On Fri, 30 Aug 2024 at 10:22, claudiu beznea <claudiu.beznea@tuxon.dev> wrote:
>>
>> Hi, Ulf,
>>
>> On 29.08.2024 18:26, Ulf Hansson wrote:
>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>>>
>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>
>>>> Hi,
>>>>
>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>>>
>>>> Series is split as follows:
>>>>
>>>> - patch 01/16           - add clock reset and power domain support for USB
>>>> - patch 02-04/16        - add reset control support for a USB signal
>>>>                           that need to be controlled before/after
>>>>                           the power to USB area is turned on/off.
>>>>
>>>>                           Philipp, Ulf, Geert, all,
>>>>
>>>>                           I detailed my approach for this in patch
>>>>                           04/16, please have a look and let me know
>>>>                           your input.
>>>
>>> I have looked briefly. Your suggested approach may work, but I have a
>>> few thoughts, see below.
>>>
>>> If I understand correctly, it is the consumer driver for the device
>>> that is attached to the USB power domain that becomes responsible for
>>> asserting/de-asserting this new signal. Right?
>>
>> Right!
>>
>>>
>>> In this regard, please note that the consumer driver doesn't really
>>> know when the power domain really gets powered-on/off. Calling
>>> pm_runtime_get|put*() is dealing with the reference counting. For
>>> example, a call to pm_runtime_get*() just makes sure that the PM
>>> domain gets-or-remains powered-on. Could this be a problem from the
>>> reset-signal point of view?
>>
>> It should be safe. From the HW manual I understand the hardware block is
>> something like the following:
>>
>>
>>                   USB area
>>          +-------------------------+
>>          |                         |
>>          | PHY --->USB controller  |
>> SYSC --> |  ^                      |
>>          |  |                      |
>>          | PHY reset               |
>>          +-------------------------+
>>
>> Where:
>> - SYSC is the system controller that controls the new signal for which
>>   I'm requesting opinions in this series
>> - PHY reset: is the block controlling the PHYs
>> - PHY: is the block controlling the USB PHYs
>> - USB controller: is the USB controller
>>
>> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o
>> PHY reset the rest of the USB logic cannot work (neither PHY block nor USB
>> controller).
>>
>> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe
>> and pm_runtime_put() in remove. The struct reset_control_ops::{assert,
>> deassert} only set specific bits in registers (no pm_runtime* calls).
> 
> Thanks for clarifying!
> 
> For my understanding, in what register range do these bits belong? Is
> it the USB logic or in the PM domain logic, or something else.

The PHY reset block is an individual hardware block with its own address
space, clocks and reset signals.

The PHY block may reside in the same address space with USB controller but
it can provide PHY support for an external USB controller, something like:

+--------------------------+
|  PHY ---> USB controller |
|   |                      |
+---|----------------------+
   \/
+---------------+
| USB controller|
+---------------+

Because of this the PHY block is modeled in Linux as a standalone driver.

And SYSC is an individual HW block with its own address space. This is
where it resides the control of the signal for which I'm asking for directions.

> 
>>
>> The PHY driver is taking its PHY reset in probe and release it in remove().
>> With this approach the newly introduced SYSC signal will be
>> de-asserted/asserted only in the PHY reset probe/remove (either if it is
>> handled though PM domain or reset control signal).
>>
>> If the SYSC signal would be passed to all the blocks in the USB area (and
>> it would be handled though PM domains) it should be no problem either,
>> AFAICT, because of reference counting the pm_runtime_get|put*() is taking
>> care of. As the PHY reset is the root node the in the devices node tree for
>> USB the reference counting should work, too (I may miss something though,
>> please correct me if I'm wrong).
>>
>> If the SYSC signal would be handled though a reset control driver (as
>> proposed in this series) and we want to pass this reference to all the
>> blocks in the USB area then we can request the reset signal as shared and,
>> AFAIK, this is also reference counted. The devices node tree should help
>> with the order, too, if I'm not wrong.
> 
> Reference counting a reset signal sounds a bit weird to me, but I
> guess it can work. :-)
> 
> To sum up from my side;
> 
> As long as it's fine that we may end up asserting/de-asserting the
> reset-signal, without actually knowing if the PM domain is getting
> turn-on/off, 

With my understanding of it, that should not happen, at least not with the
current implementation of the drivers involved in this.

> then using a reset-control like what you propose seems
> okay to me.

I would prefer this option, too.

> 
> If not, there are two other options that can be considered I think.
> *) Using the genpd on/off notifiers, to really allow the consumer
> driver of the reset-control to know when the PM domain gets turned
> on/off.
> **) Move the entire reset handling into the PM domain provider, as it
> obviously knows when the domain is getting turned on/off.

This option is what I've explored, tested on my side.

I explored it in 2 ways:

1/ SYSC modeled as an individual PM domain provider (this is more
   appropriate to how HW manual described the hardware) with this the PHY
   reset DT node would have to get 2 PM domains handlers (one for the
   current PM domain provider and the other one for SYSC):

+               phyrst: usbphy-ctrl@11e00000 {
+                       compatible = "renesas,r9a08g045-usbphy-ctrl";
+                       reg = <0 0x11e00000 0 0x10000>;
+                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+                       resets = <&cpg R9A08G045_USB_PRESETN>;
+                       power-domain-names = "cpg", "sysc";
+                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
R9A08G045_SYSC_PD_USB>;
+                       #reset-cells = <1>;
+                       status = "disabled";
+
+                       usb0_vbus_otg: regulator-vbus {
+                               regulator-name = "vbus";
+                       };
+               };
+

and the PHY reset driver will get bulky with powering on/off both of these,
at least with my current implementation, something like (and the following
code is in probe()):

+       if (priv->set_power) {
+               priv->cpg_genpd_dev = dev_pm_domain_attach_by_name(dev, "cpg");
+               if (IS_ERR(priv->cpg_genpd_dev)) {
+                       dev_err_probe(dev, error, "Failed to attach CPG PM
domain!");
+                       error = PTR_ERR(priv->cpg_genpd_dev);
+                       goto err_pm_runtime_put;
+               }
+
+               priv->sysc_genpd_dev = dev_pm_domain_attach_by_name(dev,
"sysc");
+               if (IS_ERR(priv->sysc_genpd_dev)) {
+                       dev_err_probe(dev, error, "Failed to attach sysc PM
domain!");
+                       error = PTR_ERR(priv->sysc_genpd_dev);
+                       goto err_genpd_cpg_detach;
+               }
+
+               priv->cpg_genpd_dl = device_link_add(dev, priv->cpg_genpd_dev,
+                                                    DL_FLAG_PM_RUNTIME |
+                                                    DL_FLAG_STATELESS);
+               if (!priv->cpg_genpd_dl) {
+                       dev_err_probe(dev, -ENOMEM, "Failed to add CPG
genpd device link!");
+                       goto err_genpd_sysc_detach;
+               }
+
+               priv->sysc_genpd_dl = device_link_add(dev,
priv->sysc_genpd_dev,
+                                                     DL_FLAG_PM_RUNTIME |
+                                                     DL_FLAG_STATELESS);
+               if (!priv->sysc_genpd_dl) {
+                       dev_err_probe(dev, -ENOMEM, "Failed to add sysc
genpd device link!");
+                       goto err_genpd_cpg_dl_del;
+               }
+
+
+               error = pm_runtime_resume_and_get(priv->cpg_genpd_dev);
+               if (error) {
+                       dev_err_probe(dev, error, "Failed to runtime resume
cpg PM domain!");
+                       goto err_genpd_sysc_dl_del;
+               }
+
+               error = pm_runtime_resume_and_get(priv->sysc_genpd_dev);
+               if (error) {
+                       dev_err_probe(dev, error, "Failed to runtime resume
sysc PM domain!");
+                       goto err_genpd_cpg_off;
+               }
+       }
+

2/ SYSC being a PM domain provider parent of the CPG (current PM domain
   provider). With this the phy reset node is like proposed in this series
   (powered by CPG PM domain):

+               phyrst: usbphy-ctrl@11e00000 {
+                       compatible = "renesas,r9a08g045-usbphy-ctrl",
+                                    "renesas,rzg2l-usbphy-ctrl";
+                       reg = <0 0x11e00000 0 0x10000>;
+                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
+                       resets = <&cpg R9A08G045_USB_PRESETN>;
+                       power-domains = <&cpg R9A08G045_PD_USB_PHY>;
+                       #reset-cells = <1>;
+                       status = "disabled";
+
+                       usb0_vbus_otg: regulator-vbus {
+                               regulator-name = "vbus";
+                       };
+               };

And the USB SYSC PM domain is parent for all USB PM domains provided by CPG
(3 in this case). With this there should be some glue code b/w CPG (code in
drivers/clk/renesas/{rzg2l-cpg.c, r9a08g045-cpg.c}) and SYSC drivers (I
have something ugly locally, haven't tried to detach CPG code from SYSC
code at the moment).


> 
> Thanks again for your explanations!

Thank you, also, for looking into this,
Claudiu Beznea

> 
> Kind regards
> Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Ulf Hansson]

[...]

> >
> > If not, there are two other options that can be considered I think.
> > *) Using the genpd on/off notifiers, to really allow the consumer
> > driver of the reset-control to know when the PM domain gets turned
> > on/off.
> > **) Move the entire reset handling into the PM domain provider, as it
> > obviously knows when the domain is getting turned on/off.
>
> This option is what I've explored, tested on my side.
>
> I explored it in 2 ways:
>
> 1/ SYSC modeled as an individual PM domain provider (this is more
>    appropriate to how HW manual described the hardware) with this the PHY
>    reset DT node would have to get 2 PM domains handlers (one for the
>    current PM domain provider and the other one for SYSC):
>
> +               phyrst: usbphy-ctrl@11e00000 {
> +                       compatible = "renesas,r9a08g045-usbphy-ctrl";
> +                       reg = <0 0x11e00000 0 0x10000>;
> +                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
> +                       resets = <&cpg R9A08G045_USB_PRESETN>;
> +                       power-domain-names = "cpg", "sysc";
> +                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
> R9A08G045_SYSC_PD_USB>;
> +                       #reset-cells = <1>;
> +                       status = "disabled";
> +
> +                       usb0_vbus_otg: regulator-vbus {
> +                               regulator-name = "vbus";
> +                       };
> +               };
> +

According to what you have described earlier/above, modelling the SYSC
as a PM domain provider seems like a better description of the HW to
me. Although, as I said earlier, if you prefer the reset approach, I
would not object to that.

>
> and the PHY reset driver will get bulky with powering on/off both of these,
> at least with my current implementation, something like (and the following
> code is in probe()):
>
> +       if (priv->set_power) {
> +               priv->cpg_genpd_dev = dev_pm_domain_attach_by_name(dev, "cpg");
> +               if (IS_ERR(priv->cpg_genpd_dev)) {
> +                       dev_err_probe(dev, error, "Failed to attach CPG PM
> domain!");
> +                       error = PTR_ERR(priv->cpg_genpd_dev);
> +                       goto err_pm_runtime_put;
> +               }
> +
> +               priv->sysc_genpd_dev = dev_pm_domain_attach_by_name(dev,
> "sysc");
> +               if (IS_ERR(priv->sysc_genpd_dev)) {
> +                       dev_err_probe(dev, error, "Failed to attach sysc PM
> domain!");
> +                       error = PTR_ERR(priv->sysc_genpd_dev);
> +                       goto err_genpd_cpg_detach;
> +               }
> +
> +               priv->cpg_genpd_dl = device_link_add(dev, priv->cpg_genpd_dev,
> +                                                    DL_FLAG_PM_RUNTIME |
> +                                                    DL_FLAG_STATELESS);
> +               if (!priv->cpg_genpd_dl) {
> +                       dev_err_probe(dev, -ENOMEM, "Failed to add CPG
> genpd device link!");
> +                       goto err_genpd_sysc_detach;
> +               }
> +
> +               priv->sysc_genpd_dl = device_link_add(dev,
> priv->sysc_genpd_dev,
> +                                                     DL_FLAG_PM_RUNTIME |
> +                                                     DL_FLAG_STATELESS);
> +               if (!priv->sysc_genpd_dl) {
> +                       dev_err_probe(dev, -ENOMEM, "Failed to add sysc
> genpd device link!");
> +                       goto err_genpd_cpg_dl_del;
> +               }
> +
> +
> +               error = pm_runtime_resume_and_get(priv->cpg_genpd_dev);
> +               if (error) {
> +                       dev_err_probe(dev, error, "Failed to runtime resume
> cpg PM domain!");
> +                       goto err_genpd_sysc_dl_del;
> +               }
> +
> +               error = pm_runtime_resume_and_get(priv->sysc_genpd_dev);
> +               if (error) {
> +                       dev_err_probe(dev, error, "Failed to runtime resume
> sysc PM domain!");
> +                       goto err_genpd_cpg_off;
> +               }
> +       }

Indeed, the code above looks bulky.

Fortunately, we now have dev|devm_pm_domain_attach_list(), which
replaces all of the code above.

[...]

Kind regards
Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Ulf Hansson]

On Sat, 31 Aug 2024 at 12:32, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> [...]
>
> > >
> > > If not, there are two other options that can be considered I think.
> > > *) Using the genpd on/off notifiers, to really allow the consumer
> > > driver of the reset-control to know when the PM domain gets turned
> > > on/off.
> > > **) Move the entire reset handling into the PM domain provider, as it
> > > obviously knows when the domain is getting turned on/off.
> >
> > This option is what I've explored, tested on my side.
> >
> > I explored it in 2 ways:
> >
> > 1/ SYSC modeled as an individual PM domain provider (this is more
> >    appropriate to how HW manual described the hardware) with this the PHY
> >    reset DT node would have to get 2 PM domains handlers (one for the
> >    current PM domain provider and the other one for SYSC):
> >
> > +               phyrst: usbphy-ctrl@11e00000 {
> > +                       compatible = "renesas,r9a08g045-usbphy-ctrl";
> > +                       reg = <0 0x11e00000 0 0x10000>;
> > +                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
> > +                       resets = <&cpg R9A08G045_USB_PRESETN>;
> > +                       power-domain-names = "cpg", "sysc";
> > +                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
> > R9A08G045_SYSC_PD_USB>;
> > +                       #reset-cells = <1>;
> > +                       status = "disabled";
> > +
> > +                       usb0_vbus_otg: regulator-vbus {
> > +                               regulator-name = "vbus";
> > +                       };
> > +               };
> > +
>
> According to what you have described earlier/above, modelling the SYSC
> as a PM domain provider seems like a better description of the HW to
> me. Although, as I said earlier, if you prefer the reset approach, I
> would not object to that.

Following the discussion I believe I should take this back. If I
understand correctly, 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.

Did that make sense?

[...]

Kind regards
Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 13:35, Ulf Hansson wrote:
> On Sat, 31 Aug 2024 at 12:32, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> [...]
>>
>>>>
>>>> If not, there are two other options that can be considered I think.
>>>> *) Using the genpd on/off notifiers, to really allow the consumer
>>>> driver of the reset-control to know when the PM domain gets turned
>>>> on/off.
>>>> **) Move the entire reset handling into the PM domain provider, as it
>>>> obviously knows when the domain is getting turned on/off.
>>>
>>> This option is what I've explored, tested on my side.
>>>
>>> I explored it in 2 ways:
>>>
>>> 1/ SYSC modeled as an individual PM domain provider (this is more
>>>    appropriate to how HW manual described the hardware) with this the PHY
>>>    reset DT node would have to get 2 PM domains handlers (one for the
>>>    current PM domain provider and the other one for SYSC):
>>>
>>> +               phyrst: usbphy-ctrl@11e00000 {
>>> +                       compatible = "renesas,r9a08g045-usbphy-ctrl";
>>> +                       reg = <0 0x11e00000 0 0x10000>;
>>> +                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
>>> +                       resets = <&cpg R9A08G045_USB_PRESETN>;
>>> +                       power-domain-names = "cpg", "sysc";
>>> +                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
>>> R9A08G045_SYSC_PD_USB>;
>>> +                       #reset-cells = <1>;
>>> +                       status = "disabled";
>>> +
>>> +                       usb0_vbus_otg: regulator-vbus {
>>> +                               regulator-name = "vbus";
>>> +                       };
>>> +               };
>>> +
>>
>> According to what you have described earlier/above, modelling the SYSC
>> as a PM domain provider seems like a better description of the HW to
>> me. Although, as I said earlier, if you prefer the reset approach, I
>> would not object to that.
> 
> Following the discussion I believe I should take this back. If I
> understand correctly, 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.

The PM domain provider for USB is the provider for the rest of IPs. To work
like this the SYSC these signals should be handled in the USB domains power
on/off function. It's not impossible to have it implemented like this but
it will complicate a bit the code, AFAICT. This will not describe the
hardware, also.

With the information that we had up to yesterday, the connection b/w HW
blocks was something as follows:

                 USB area
              +--------------------------+
      sig     | PHY -> USB controller X  |
SYSC -------->|  ^                       |
              |  |                       |
              | PHY reset                |
              +--------------------------+

In this implementation the SYSC signal was connected to PHY reset block as
it is the root of the devices used in the USB setup and no USB
functionality can exist w/o the PHY reset being setup.

There is a new information arrived just yesterday from hardware team saying
this about SYSC signals: "When turning off USB PHY and PCIe PHY, if they
are not controlled, PHY may break" which may means that it is just
connected to the PHYs not to the USB area/region or PCIe area/region as
initially expressed in HW manual.

With that the HW connection b/w the USB devices and SYSC might become
something like:

                 USB area
              +--------------------------+
     sig   +--->PHY -> USB controller X  |
SYSC ------+  |  ^                       |
              |  |                       |
              | PHY reset                |
              +--------------------------+

I haven't got the chance to test this topology, though.

With this new information would you be OK to still have it as a reset
signal and connected only to the PHY driver ?

Thank you,
Claudiu Beznea

> 
> Did that make sense?
> 
> [...]
> 
> Kind regards
> Uffe

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Ulf Hansson]

On Tue, 3 Sept 2024 at 12:58, claudiu beznea <claudiu.beznea@tuxon.dev> wrote:
>
>
>
> On 03.09.2024 13:35, Ulf Hansson wrote:
> > On Sat, 31 Aug 2024 at 12:32, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >>
> >> [...]
> >>
> >>>>
> >>>> If not, there are two other options that can be considered I think.
> >>>> *) Using the genpd on/off notifiers, to really allow the consumer
> >>>> driver of the reset-control to know when the PM domain gets turned
> >>>> on/off.
> >>>> **) Move the entire reset handling into the PM domain provider, as it
> >>>> obviously knows when the domain is getting turned on/off.
> >>>
> >>> This option is what I've explored, tested on my side.
> >>>
> >>> I explored it in 2 ways:
> >>>
> >>> 1/ SYSC modeled as an individual PM domain provider (this is more
> >>>    appropriate to how HW manual described the hardware) with this the PHY
> >>>    reset DT node would have to get 2 PM domains handlers (one for the
> >>>    current PM domain provider and the other one for SYSC):
> >>>
> >>> +               phyrst: usbphy-ctrl@11e00000 {
> >>> +                       compatible = "renesas,r9a08g045-usbphy-ctrl";
> >>> +                       reg = <0 0x11e00000 0 0x10000>;
> >>> +                       clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>;
> >>> +                       resets = <&cpg R9A08G045_USB_PRESETN>;
> >>> +                       power-domain-names = "cpg", "sysc";
> >>> +                       power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc
> >>> R9A08G045_SYSC_PD_USB>;
> >>> +                       #reset-cells = <1>;
> >>> +                       status = "disabled";
> >>> +
> >>> +                       usb0_vbus_otg: regulator-vbus {
> >>> +                               regulator-name = "vbus";
> >>> +                       };
> >>> +               };
> >>> +
> >>
> >> According to what you have described earlier/above, modelling the SYSC
> >> as a PM domain provider seems like a better description of the HW to
> >> me. Although, as I said earlier, if you prefer the reset approach, I
> >> would not object to that.
> >
> > Following the discussion I believe I should take this back. If I
> > understand correctly, 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.
>
> The PM domain provider for USB is the provider for the rest of IPs. To work
> like this the SYSC these signals should be handled in the USB domains power
> on/off function. It's not impossible to have it implemented like this but
> it will complicate a bit the code, AFAICT. This will not describe the
> hardware, also.
>
> With the information that we had up to yesterday, the connection b/w HW
> blocks was something as follows:
>
>                  USB area
>               +--------------------------+
>       sig     | PHY -> USB controller X  |
> SYSC -------->|  ^                       |
>               |  |                       |
>               | PHY reset                |
>               +--------------------------+
>
> In this implementation the SYSC signal was connected to PHY reset block as
> it is the root of the devices used in the USB setup and no USB
> functionality can exist w/o the PHY reset being setup.
>
> There is a new information arrived just yesterday from hardware team saying
> this about SYSC signals: "When turning off USB PHY and PCIe PHY, if they
> are not controlled, PHY may break" which may means that it is just
> connected to the PHYs not to the USB area/region or PCIe area/region as
> initially expressed in HW manual.
>
> With that the HW connection b/w the USB devices and SYSC might become
> something like:
>
>                  USB area
>               +--------------------------+
>      sig   +--->PHY -> USB controller X  |
> SYSC ------+  |  ^                       |
>               |  |                       |
>               | PHY reset                |
>               +--------------------------+
>
> I haven't got the chance to test this topology, though.
>
> With this new information would you be OK to still have it as a reset
> signal and connected only to the PHY driver ?

As long as it's a better description of the HW, I am fine with that too.

Although, please note that pm_runtime_get|put() doesn't give you full
controll of how the USB PM domain is being powered. So in that case,
it sounds like you need to use the genpd on/off notifiers too.

Kind regards
Uffe

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Friday, August 30, 2024 9:23 AM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> Hi, Ulf,
> 
> On 29.08.2024 18:26, Ulf Hansson wrote:
> > On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>
> >> Hi,
> >>
> >> Series adds initial USB support for the Renesas RZ/G3S SoC.
> >>
> >> Series is split as follows:
> >>
> >> - patch 01/16           - add clock reset and power domain support for USB
> >> - patch 02-04/16        - add reset control support for a USB signal
> >>                           that need to be controlled before/after
> >>                           the power to USB area is turned on/off.
> >>
> >>                           Philipp, Ulf, Geert, all,
> >>
> >>                           I detailed my approach for this in patch
> >>                           04/16, please have a look and let me know
> >>                           your input.
> >
> > I have looked briefly. Your suggested approach may work, but I have a
> > few thoughts, see below.
> >
> > If I understand correctly, it is the consumer driver for the device
> > that is attached to the USB power domain that becomes responsible for
> > asserting/de-asserting this new signal. Right?
> 
> Right!
> 
> >
> > In this regard, please note that the consumer driver doesn't really
> > know when the power domain really gets powered-on/off. Calling
> > pm_runtime_get|put*() is dealing with the reference counting. For
> > example, a call to pm_runtime_get*() just makes sure that the PM
> > domain gets-or-remains powered-on. Could this be a problem from the
> > reset-signal point of view?
> 
> It should be safe. From the HW manual I understand the hardware block is something like the following:
> 
> 
>                   USB area
>          +-------------------------+
>          |                         |
>          | PHY --->USB controller  |
> SYSC --> |  ^                      |
>          |  |                      |
>          | PHY reset               |
>          +-------------------------+

How USB PWRRDY signal is connected to USB? 

USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.

Is it connected to top level block or connected to each IP's for turning off the USB region power?

? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)? 

If the USBPWRRDY signal is connected across modules with this reset signal approach
then you may need to update bindings [1] with that reset signal

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20240822152801.602318-12-claudiu.beznea.uj@bp.renesas.com/
 

Cheers,
Biju

> 
> Where:
> - SYSC is the system controller that controls the new signal for which
>   I'm requesting opinions in this series
> - PHY reset: is the block controlling the PHYs
> - PHY: is the block controlling the USB PHYs
> - USB controller: is the USB controller
> 
> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o PHY reset the rest of the
> USB logic cannot work (neither PHY block nor USB controller).
> 
> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe and pm_runtime_put() in
> remove. The struct reset_control_ops::{assert, deassert} only set specific bits in registers (no
> pm_runtime* calls).
> 
> The PHY driver is taking its PHY reset in probe and release it in remove().
> With this approach the newly introduced SYSC signal will be de-asserted/asserted only in the PHY reset
> probe/remove (either if it is handled though PM domain or reset control signal).
> 
> If the SYSC signal would be passed to all the blocks in the USB area (and it would be handled though
> PM domains) it should be no problem either, AFAICT, because of reference counting the
> pm_runtime_get|put*() is taking care of. As the PHY reset is the root node the in the devices node
> tree for USB the reference counting should work, too (I may miss something though, please correct me
> if I'm wrong).
> 
> If the SYSC signal would be handled though a reset control driver (as proposed in this series) and we
> want to pass this reference to all the blocks in the USB area then we can request the reset signal as
> shared and, AFAIK, this is also reference counted. The devices node tree should help with the order,
> too, if I'm not wrong.
> 
> Thank you for looking at this,
> Claudiu Beznea
> 
> >
> > [...]
> >
> > Kind regards
> > Uffe

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: Biju Das
> Sent: Saturday, August 31, 2024 6:14 AM
> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> Hi Claudiu,
> 
> > -----Original Message-----
> > From: claudiu beznea <claudiu.beznea@tuxon.dev>
> > Sent: Friday, August 30, 2024 9:23 AM
> > Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> > RZ/G3S SoC
> >
> > Hi, Ulf,
> >
> > On 29.08.2024 18:26, Ulf Hansson wrote:
> > > On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> > >>
> > >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > >>
> > >> Hi,
> > >>
> > >> Series adds initial USB support for the Renesas RZ/G3S SoC.
> > >>
> > >> Series is split as follows:
> > >>
> > >> - patch 01/16           - add clock reset and power domain support for USB
> > >> - patch 02-04/16        - add reset control support for a USB signal
> > >>                           that need to be controlled before/after
> > >>                           the power to USB area is turned on/off.
> > >>
> > >>                           Philipp, Ulf, Geert, all,
> > >>
> > >>                           I detailed my approach for this in patch
> > >>                           04/16, please have a look and let me know
> > >>                           your input.
> > >
> > > I have looked briefly. Your suggested approach may work, but I have
> > > a few thoughts, see below.
> > >
> > > If I understand correctly, it is the consumer driver for the device
> > > that is attached to the USB power domain that becomes responsible
> > > for asserting/de-asserting this new signal. Right?
> >
> > Right!
> >
> > >
> > > In this regard, please note that the consumer driver doesn't really
> > > know when the power domain really gets powered-on/off. Calling
> > > pm_runtime_get|put*() is dealing with the reference counting. For
> > > example, a call to pm_runtime_get*() just makes sure that the PM
> > > domain gets-or-remains powered-on. Could this be a problem from the
> > > reset-signal point of view?
> >
> > It should be safe. From the HW manual I understand the hardware block is something like the
> following:
> >
> >
> >                   USB area
> >          +-------------------------+
> >          |                         |
> >          | PHY --->USB controller  |
> > SYSC --> |  ^                      |
> >          |  |                      |
> >          | PHY reset               |
> >          +-------------------------+
> 
> How USB PWRRDY signal is connected to USB?
> 
> USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.
> 
> Is it connected to top level block or connected to each IP's for turning off the USB region power?
> 
> ? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)?

As per the update from HW team,

"SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).

Refer to step 8,9 in Table 41.10 Example Transition Flow Outline from ALL_ON Mode to AWO Mode.
Refer to step 9,10 in Table 41.11 Example Transition Flow Outline from AWO Mode to ALL_ON Mode.

When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break."

Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux? 

Cheers,
Biju
 

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

Hi, Biju,

On 02.09.2024 10:54, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Biju Das
>> Sent: Saturday, August 31, 2024 6:14 AM
>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>> Hi Claudiu,
>>
>>> -----Original Message-----
>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>> Sent: Friday, August 30, 2024 9:23 AM
>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>> RZ/G3S SoC
>>>
>>> Hi, Ulf,
>>>
>>> On 29.08.2024 18:26, Ulf Hansson wrote:
>>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>>>>
>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>>>>
>>>>> Series is split as follows:
>>>>>
>>>>> - patch 01/16           - add clock reset and power domain support for USB
>>>>> - patch 02-04/16        - add reset control support for a USB signal
>>>>>                           that need to be controlled before/after
>>>>>                           the power to USB area is turned on/off.
>>>>>
>>>>>                           Philipp, Ulf, Geert, all,
>>>>>
>>>>>                           I detailed my approach for this in patch
>>>>>                           04/16, please have a look and let me know
>>>>>                           your input.
>>>>
>>>> I have looked briefly. Your suggested approach may work, but I have
>>>> a few thoughts, see below.
>>>>
>>>> If I understand correctly, it is the consumer driver for the device
>>>> that is attached to the USB power domain that becomes responsible
>>>> for asserting/de-asserting this new signal. Right?
>>>
>>> Right!
>>>
>>>>
>>>> In this regard, please note that the consumer driver doesn't really
>>>> know when the power domain really gets powered-on/off. Calling
>>>> pm_runtime_get|put*() is dealing with the reference counting. For
>>>> example, a call to pm_runtime_get*() just makes sure that the PM
>>>> domain gets-or-remains powered-on. Could this be a problem from the
>>>> reset-signal point of view?
>>>
>>> It should be safe. From the HW manual I understand the hardware block is something like the
>> following:
>>>
>>>
>>>                   USB area
>>>          +-------------------------+
>>>          |                         |
>>>          | PHY --->USB controller  |
>>> SYSC --> |  ^                      |
>>>          |  |                      |
>>>          | PHY reset               |
>>>          +-------------------------+
>>
>> How USB PWRRDY signal is connected to USB?
>>
>> USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.
>>
>> Is it connected to top level block or connected to each IP's for turning off the USB region power?
>>
>> ? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)?
> 
> As per the update from HW team,
> 
> "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
> 
> Refer to step 8,9 in Table 41.10 Example Transition Flow Outline from ALL_ON Mode to AWO Mode.
> Refer to step 9,10 in Table 41.11 Example Transition Flow Outline from AWO Mode to ALL_ON Mode.

All this is not new information.

From experiments, we need to control these signals also when booting as
intermediary booting application may control and leave it in improper
state. W/o having SYSC signals configured properly there is no chance for
USB to work (it should be the same for PCIe but I haven't explored it yet).

> 
> When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break."

From experiments, I know this, as this is the reason the SYSC USB PWRRDY
has been implemented in Linux and proposed in this series.

> 
> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux? 

As you know, the RZ/G3S USB PM code is already prepared. This is also
configuring these signals when going to suspend/exiting from resume. W/o
configuring properly these signals the USB is not working after a
suspend/resume cycle.

Thank you,
Claudiu Beznea


> Cheers,
> Biju
>  

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Monday, September 2, 2024 9:47 AM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> Hi, Biju,
> 
> On 02.09.2024 10:54, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Biju Das
> >> Sent: Saturday, August 31, 2024 6:14 AM
> >> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >> Hi Claudiu,
> >>
> >>> -----Original Message-----
> >>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>> Sent: Friday, August 30, 2024 9:23 AM
> >>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>> RZ/G3S SoC
> >>>
> >>> Hi, Ulf,
> >>>
> >>> On 29.08.2024 18:26, Ulf Hansson wrote:
> >>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >>>>>
> >>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
> >>>>>
> >>>>> Series is split as follows:
> >>>>>
> >>>>> - patch 01/16           - add clock reset and power domain support for USB
> >>>>> - patch 02-04/16        - add reset control support for a USB signal
> >>>>>                           that need to be controlled before/after
> >>>>>                           the power to USB area is turned on/off.
> >>>>>
> >>>>>                           Philipp, Ulf, Geert, all,
> >>>>>
> >>>>>                           I detailed my approach for this in patch
> >>>>>                           04/16, please have a look and let me know
> >>>>>                           your input.
> >>>>
> >>>> I have looked briefly. Your suggested approach may work, but I have
> >>>> a few thoughts, see below.
> >>>>
> >>>> If I understand correctly, it is the consumer driver for the device
> >>>> that is attached to the USB power domain that becomes responsible
> >>>> for asserting/de-asserting this new signal. Right?
> >>>
> >>> Right!
> >>>
> >>>>
> >>>> In this regard, please note that the consumer driver doesn't really
> >>>> know when the power domain really gets powered-on/off. Calling
> >>>> pm_runtime_get|put*() is dealing with the reference counting. For
> >>>> example, a call to pm_runtime_get*() just makes sure that the PM
> >>>> domain gets-or-remains powered-on. Could this be a problem from the
> >>>> reset-signal point of view?
> >>>
> >>> It should be safe. From the HW manual I understand the hardware
> >>> block is something like the
> >> following:
> >>>
> >>>
> >>>                   USB area
> >>>          +-------------------------+
> >>>          |                         |
> >>>          | PHY --->USB controller  |
> >>> SYSC --> |  ^                      |
> >>>          |  |                      |
> >>>          | PHY reset               |
> >>>          +-------------------------+
> >>
> >> How USB PWRRDY signal is connected to USB?
> >>
> >> USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.
> >>
> >> Is it connected to top level block or connected to each IP's for turning off the USB region power?
> >>
> >> ? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)?
> >
> > As per the update from HW team,
> >
> > "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to
> ALL_ON).
> >
> > Refer to step 8,9 in Table 41.10 Example Transition Flow Outline from ALL_ON Mode to AWO Mode.
> > Refer to step 9,10 in Table 41.11 Example Transition Flow Outline from AWO Mode to ALL_ON Mode.
> 
> All this is not new information.
> 
> From experiments, we need to control these signals also when booting as intermediary booting
> application may control and leave it in improper state. W/o having SYSC signals configured properly
> there is no chance for USB to work (it should be the same for PCIe but I haven't explored it yet).
> 
> >
> > When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break."
> 
> From experiments, I know this, as this is the reason the SYSC USB PWRRDY has been implemented in Linux
> and proposed in this series.

You mean you call reset assert for USB PWRRDY signal for system transition (AWO Mode to ALL_ON Mode)??


 
> >
> > Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
> 
> As you know, the RZ/G3S USB PM code is already prepared. This is also configuring these signals when
> going to suspend/exiting from resume. W/o configuring properly these signals the USB is not working
> after a suspend/resume cycle.

One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan to handle system transitions there??

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 02.09.2024 11:53, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>> Sent: Monday, September 2, 2024 9:47 AM
>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>> Hi, Biju,
>>
>> On 02.09.2024 10:54, Biju Das wrote:
>>> Hi Claudiu,
>>>
>>>> -----Original Message-----
>>>> From: Biju Das
>>>> Sent: Saturday, August 31, 2024 6:14 AM
>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
>>>> RZ/G3S SoC
>>>>
>>>> Hi Claudiu,
>>>>
>>>>> -----Original Message-----
>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>>> Sent: Friday, August 30, 2024 9:23 AM
>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>>> RZ/G3S SoC
>>>>>
>>>>> Hi, Ulf,
>>>>>
>>>>> On 29.08.2024 18:26, Ulf Hansson wrote:
>>>>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>>>>>>
>>>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>>>>>>
>>>>>>> Series is split as follows:
>>>>>>>
>>>>>>> - patch 01/16           - add clock reset and power domain support for USB
>>>>>>> - patch 02-04/16        - add reset control support for a USB signal
>>>>>>>                           that need to be controlled before/after
>>>>>>>                           the power to USB area is turned on/off.
>>>>>>>
>>>>>>>                           Philipp, Ulf, Geert, all,
>>>>>>>
>>>>>>>                           I detailed my approach for this in patch
>>>>>>>                           04/16, please have a look and let me know
>>>>>>>                           your input.
>>>>>>
>>>>>> I have looked briefly. Your suggested approach may work, but I have
>>>>>> a few thoughts, see below.
>>>>>>
>>>>>> If I understand correctly, it is the consumer driver for the device
>>>>>> that is attached to the USB power domain that becomes responsible
>>>>>> for asserting/de-asserting this new signal. Right?
>>>>>
>>>>> Right!
>>>>>
>>>>>>
>>>>>> In this regard, please note that the consumer driver doesn't really
>>>>>> know when the power domain really gets powered-on/off. Calling
>>>>>> pm_runtime_get|put*() is dealing with the reference counting. For
>>>>>> example, a call to pm_runtime_get*() just makes sure that the PM
>>>>>> domain gets-or-remains powered-on. Could this be a problem from the
>>>>>> reset-signal point of view?
>>>>>
>>>>> It should be safe. From the HW manual I understand the hardware
>>>>> block is something like the
>>>> following:
>>>>>
>>>>>
>>>>>                   USB area
>>>>>          +-------------------------+
>>>>>          |                         |
>>>>>          | PHY --->USB controller  |
>>>>> SYSC --> |  ^                      |
>>>>>          |  |                      |
>>>>>          | PHY reset               |
>>>>>          +-------------------------+
>>>>
>>>> How USB PWRRDY signal is connected to USB?
>>>>
>>>> USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.
>>>>
>>>> Is it connected to top level block or connected to each IP's for turning off the USB region power?
>>>>
>>>> ? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)?
>>>
>>> As per the update from HW team,
>>>
>>> "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to
>> ALL_ON).
>>>
>>> Refer to step 8,9 in Table 41.10 Example Transition Flow Outline from ALL_ON Mode to AWO Mode.
>>> Refer to step 9,10 in Table 41.11 Example Transition Flow Outline from AWO Mode to ALL_ON Mode.
>>
>> All this is not new information.
>>
>> From experiments, we need to control these signals also when booting as intermediary booting
>> application may control and leave it in improper state. W/o having SYSC signals configured properly
>> there is no chance for USB to work (it should be the same for PCIe but I haven't explored it yet).
>>
>>>
>>> When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break."
>>
>> From experiments, I know this, as this is the reason the SYSC USB PWRRDY has been implemented in Linux
>> and proposed in this series.
> 
> You mean you call reset assert for USB PWRRDY signal for system transition (AWO Mode to ALL_ON Mode)??

reset assert on suspend, reset de-assert on resume.

And pm_runtime_put()/pm_runtime_resume_and_get() on the version where USB
PHYRDY is provided by SYSC as a PM domain. As I mentioned in the thread
with Ulf, this is something I explored locally.

All these are internal, not published in this version. This version just
adds initial bring-up support.

> 
> 
>  
>>>
>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
>>
>> As you know, the RZ/G3S USB PM code is already prepared. This is also configuring these signals when
>> going to suspend/exiting from resume. W/o configuring properly these signals the USB is not working
>> after a suspend/resume cycle.
> 
> One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan to handle system transitions there??

As I mentioned, the settings in these registers may be changed by
intermediary booting applications. Depending on that, Linux need to control
it also on probe for USB to work (it should be the same with PCIe, these
signals seems similar from HW manual description).

Thank you,
Claudiu Beznea

> 
> Cheers,
> Biju
> 
> 
> 

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Monday, September 2, 2024 10:14 AM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 02.09.2024 11:53, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >> Sent: Monday, September 2, 2024 9:47 AM
> >> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >> Hi, Biju,
> >>
> >> On 02.09.2024 10:54, Biju Das wrote:
> >>> Hi Claudiu,
> >>>
> >>>> -----Original Message-----
> >>>> From: Biju Das
> >>>> Sent: Saturday, August 31, 2024 6:14 AM
> >>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >>>> RZ/G3S SoC
> >>>>
> >>>> Hi Claudiu,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>>>> Sent: Friday, August 30, 2024 9:23 AM
> >>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>>>> RZ/G3S SoC
> >>>>>
> >>>>> Hi, Ulf,
> >>>>>
> >>>>> On 29.08.2024 18:26, Ulf Hansson wrote:
> >>>>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
> >>>>>>>
> >>>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
> >>>>>>>
> >>>>>>> Series is split as follows:
> >>>>>>>
> >>>>>>> - patch 01/16           - add clock reset and power domain support for USB
> >>>>>>> - patch 02-04/16        - add reset control support for a USB signal
> >>>>>>>                           that need to be controlled before/after
> >>>>>>>                           the power to USB area is turned on/off.
> >>>>>>>
> >>>>>>>                           Philipp, Ulf, Geert, all,
> >>>>>>>
> >>>>>>>                           I detailed my approach for this in patch
> >>>>>>>                           04/16, please have a look and let me know
> >>>>>>>                           your input.
> >>>>>>
> >>>>>> I have looked briefly. Your suggested approach may work, but I
> >>>>>> have a few thoughts, see below.
> >>>>>>
> >>>>>> If I understand correctly, it is the consumer driver for the
> >>>>>> device that is attached to the USB power domain that becomes
> >>>>>> responsible for asserting/de-asserting this new signal. Right?
> >>>>>
> >>>>> Right!
> >>>>>
> >>>>>>
> >>>>>> In this regard, please note that the consumer driver doesn't
> >>>>>> really know when the power domain really gets powered-on/off.
> >>>>>> Calling
> >>>>>> pm_runtime_get|put*() is dealing with the reference counting. For
> >>>>>> example, a call to pm_runtime_get*() just makes sure that the PM
> >>>>>> domain gets-or-remains powered-on. Could this be a problem from
> >>>>>> the reset-signal point of view?
> >>>>>
> >>>>> It should be safe. From the HW manual I understand the hardware
> >>>>> block is something like the
> >>>> following:
> >>>>>
> >>>>>
> >>>>>                   USB area
> >>>>>          +-------------------------+
> >>>>>          |                         |
> >>>>>          | PHY --->USB controller  |
> >>>>> SYSC --> |  ^                      |
> >>>>>          |  |                      |
> >>>>>          | PHY reset               |
> >>>>>          +-------------------------+
> >>>>
> >>>> How USB PWRRDY signal is connected to USB?
> >>>>
> >>>> USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.
> >>>>
> >>>> Is it connected to top level block or connected to each IP's for turning off the USB region
> power?
> >>>>
> >>>> ? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)?
> >>>
> >>> As per the update from HW team,
> >>>
> >>> "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from
> >>> ALL_ON to AWO (or from AWO to
> >> ALL_ON).
> >>>
> >>> Refer to step 8,9 in Table 41.10 Example Transition Flow Outline from ALL_ON Mode to AWO Mode.
> >>> Refer to step 9,10 in Table 41.11 Example Transition Flow Outline from AWO Mode to ALL_ON Mode.
> >>
> >> All this is not new information.
> >>
> >> From experiments, we need to control these signals also when booting
> >> as intermediary booting application may control and leave it in
> >> improper state. W/o having SYSC signals configured properly there is no chance for USB to work (it
> should be the same for PCIe but I haven't explored it yet).
> >>
> >>>
> >>> When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break."
> >>
> >> From experiments, I know this, as this is the reason the SYSC USB
> >> PWRRDY has been implemented in Linux and proposed in this series.
> >
> > You mean you call reset assert for USB PWRRDY signal for system transition (AWO Mode to ALL_ON
> Mode)??
> 
> reset assert on suspend, reset de-assert on resume.
> 
> And pm_runtime_put()/pm_runtime_resume_and_get() on the version where USB PHYRDY is provided by SYSC
> as a PM domain. As I mentioned in the thread with Ulf, this is something I explored locally.
> 
> All these are internal, not published in this version. This version just adds initial bring-up
> support.
> 
> >
> >
> >
> >>>
> >>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
> >>
> >> As you know, the RZ/G3S USB PM code is already prepared. This is also
> >> configuring these signals when going to suspend/exiting from resume.
> >> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
> >
> > One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan to handle system transitions
> there??
> 
> As I mentioned, the settings in these registers may be changed by intermediary booting applications.
> Depending on that, Linux need to control it also on probe for USB to work (it should be the same with
> PCIe, these signals seems similar from HW manual description).

You mean system transition settings will be override by U-boot, so Linux needs to restore it back??

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 02.09.2024 12:18, Biju Das wrote:
>>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
>>>> As you know, the RZ/G3S USB PM code is already prepared. This is also
>>>> configuring these signals when going to suspend/exiting from resume.
>>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
>>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan to handle system transitions
>> there??
>>
>> As I mentioned, the settings in these registers may be changed by intermediary booting applications.
>> Depending on that, Linux need to control it also on probe for USB to work (it should be the same with
>> PCIe, these signals seems similar from HW manual description).
> You mean system transition settings will be override by U-boot, so Linux needs to restore it back??

It was talking about booting...

You proposed to handle SYSC signals from TF-A in a discussion about system
power transitions:

"One option is to handle SYSC USB PWRRDY signal in TF-A,  if you plan to
handle system transitions"

(I was guessing the "system transition" statement there refers to power
states transitions, ALL_ON <-> AWO/VBAT)

and I gave the booting process as a counter example: if we handle it in
TF-A it may not be enough as these signals might be changed by intermediary
booting applications (e.g., U-Boot).

To conclude, there are 3 scenarios I see where these signals need to be
handled:
1/ booting
2/ suspend to RAM
3/ driver unbind/bind

In case of booting: if we have TF-A to set signals there might be
intermediary booting applications (e.g. U-Boot) that set these signals
also. If it leaves it in improper state and Linux wants to use USB then the
USB will not work (if Linux doesn't handle it).

In case of suspend to RAM: as TF-A is the only application in the suspend
to RAM chain, it should work handling it in TF-A.

In case of unbind/bind: currently we don't know if these signals introduces
any kind of power saving so asserting/de-asserting them in Linux may be
useful from this perspective, if any.

Either way, I think Linux should handle all that it can to make the devices
work and not rely on third party applications.

Thank you,
Claudiu Beznea

> 
> Cheers,
> Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Monday, September 2, 2024 11:41 AM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 02.09.2024 12:18, Biju Das wrote:
> >>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
> >>>> As you know, the RZ/G3S USB PM code is already prepared. This is
> >>>> also configuring these signals when going to suspend/exiting from resume.
> >>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
> >>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan
> >>> to handle system transitions
> >> there??
> >>
> >> As I mentioned, the settings in these registers may be changed by intermediary booting
> applications.
> >> Depending on that, Linux need to control it also on probe for USB to
> >> work (it should be the same with PCIe, these signals seems similar from HW manual description).
> > You mean system transition settings will be override by U-boot, so Linux needs to restore it back??
> 
> It was talking about booting...

I am also referring to boot. Boot starts with TF-A and it has a system state.

> 
> You proposed to handle SYSC signals from TF-A in a discussion about system power transitions:
> 
> "One option is to handle SYSC USB PWRRDY signal in TF-A,  if you plan to handle system transitions"
> 
> (I was guessing the "system transition" statement there refers to power states transitions, ALL_ON <->
> AWO/VBAT)

That is correct.

> 
> and I gave the booting process as a counter example: if we handle it in TF-A it may not be enough as
> these signals might be changed by intermediary booting applications (e.g., U-Boot).

Why should U-boot override, system state signals such as USB PWRREADY? Can you please give an example.

> 
> To conclude, there are 3 scenarios I see where these signals need to be
> handled:
> 1/ booting 
> 2/ suspend to RAM
> 3/ driver unbind/bind

--> It should be OK as linux is not handling USB PWRREADY signal.

> 
> In case of booting: if we have TF-A to set signals there might be intermediary booting applications
> (e.g. U-Boot) that set these signals also. If it leaves it in improper state and Linux wants to use
> USB then the USB will not work (if Linux doesn't handle it).

That is the problem of U-boot. U-boot should not override system state signals such as USB PWRREADY.

> 
> In case of suspend to RAM: as TF-A is the only application in the suspend to RAM chain, it should work
> handling it in TF-A.

That is correct, TF-A should handle based on system state.

> 
> In case of unbind/bind: currently we don't know if these signals introduces any kind of power saving
> so asserting/de-asserting them in Linux may be useful from this perspective, if any.

These are system signals, according to me should not be used in unbind/bind.

I may be wrong.

Cheers,
Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: Biju Das
> Sent: Monday, September 2, 2024 11:48 AM
> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> Hi Claudiu,
> 
> > -----Original Message-----
> > From: claudiu beznea <claudiu.beznea@tuxon.dev>
> > Sent: Monday, September 2, 2024 11:41 AM
> > Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> > RZ/G3S SoC
> >
> >
> >
> > On 02.09.2024 12:18, Biju Das wrote:
> > >>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
> > >>>> As you know, the RZ/G3S USB PM code is already prepared. This is
> > >>>> also configuring these signals when going to suspend/exiting from resume.
> > >>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
> > >>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you
> > >>> plan to handle system transitions
> > >> there??
> > >>
> > >> As I mentioned, the settings in these registers may be changed by
> > >> intermediary booting
> > applications.
> > >> Depending on that, Linux need to control it also on probe for USB
> > >> to work (it should be the same with PCIe, these signals seems similar from HW manual
> description).
> > > You mean system transition settings will be override by U-boot, so Linux needs to restore it
> back??
> >
> > It was talking about booting...
> 
> I am also referring to boot. Boot starts with TF-A and it has a system state.
> 
> >
> > You proposed to handle SYSC signals from TF-A in a discussion about system power transitions:
> >
> > "One option is to handle SYSC USB PWRRDY signal in TF-A,  if you plan to handle system transitions"
> >
> > (I was guessing the "system transition" statement there refers to
> > power states transitions, ALL_ON <->
> > AWO/VBAT)
> 
> That is correct.
> 
> >
> > and I gave the booting process as a counter example: if we handle it
> > in TF-A it may not be enough as these signals might be changed by intermediary booting applications
> (e.g., U-Boot).
> 
> Why should U-boot override, system state signals such as USB PWRREADY? Can you please give an example.
> 
> >
> > To conclude, there are 3 scenarios I see where these signals need to
> > be
> > handled:
> > 1/ booting
> > 2/ suspend to RAM
> > 3/ driver unbind/bind
> 
> --> It should be OK as linux is not handling USB PWRREADY signal.
> 
> >
> > In case of booting: if we have TF-A to set signals there might be
> > intermediary booting applications (e.g. U-Boot) that set these signals
> > also. If it leaves it in improper state and Linux wants to use USB then the USB will not work (if
> Linux doesn't handle it).
> 
> That is the problem of U-boot. U-boot should not override system state signals such as USB PWRREADY.
> 
> >
> > In case of suspend to RAM: as TF-A is the only application in the
> > suspend to RAM chain, it should work handling it in TF-A.
> 
> That is correct, TF-A should handle based on system state.
> 
> >
> > In case of unbind/bind: currently we don't know if these signals
> > introduces any kind of power saving so asserting/de-asserting them in Linux may be useful from this
> perspective, if any.
> 
> These are system signals, according to me should not be used in unbind/bind.
> 
> I may be wrong.

Just to add the below are the 4 system states (power mode) for this LSI.

If I understand correctly, we need to configure USB PWRRDY signal
only when there is a transition from ALL_ON to AWO mode and vice versa.
as you see on AWO mode only CM-33 is active.

• ALL_OFF mode: All CPUs and peripheral modules can not be worked.
• ALL_ON mode: All CPUs and peripheral modules can be worked.
• AWO mode: Cortex-M33 and peripheral modules in PD_VCC and PD_VBATT domain can be worked.
• VBATT mode: Only RTC, tamper detection and backup registers can be worked.

System manager which is controlling both CA-55 and CM-33, will set USB PWRRDY signal
based on system state.

Since we don't have system manager for controlling both CA-55 and CM-33
Probably from CA-55 perspective, TF-A should be sufficient.

During boot clr USB PWR READY signal in TF-A.
STR case, suspend set USB PWR READY signal in TF-A.
STR case, resume clr USB PWR READY signal in TF-A.

I am not expert in this area. I may be wrong.

Maybe we need to get an opinion from Power experts in Linux.

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 10:18, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: Biju Das
>> Sent: Monday, September 2, 2024 11:48 AM
>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>> Hi Claudiu,
>>
>>> -----Original Message-----
>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>> Sent: Monday, September 2, 2024 11:41 AM
>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>> RZ/G3S SoC
>>>
>>>
>>>
>>> On 02.09.2024 12:18, Biju Das wrote:
>>>>>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
>>>>>>> As you know, the RZ/G3S USB PM code is already prepared. This is
>>>>>>> also configuring these signals when going to suspend/exiting from resume.
>>>>>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
>>>>>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you
>>>>>> plan to handle system transitions
>>>>> there??
>>>>>
>>>>> As I mentioned, the settings in these registers may be changed by
>>>>> intermediary booting
>>> applications.
>>>>> Depending on that, Linux need to control it also on probe for USB
>>>>> to work (it should be the same with PCIe, these signals seems similar from HW manual
>> description).
>>>> You mean system transition settings will be override by U-boot, so Linux needs to restore it
>> back??
>>>
>>> It was talking about booting...
>>
>> I am also referring to boot. Boot starts with TF-A and it has a system state.
>>
>>>
>>> You proposed to handle SYSC signals from TF-A in a discussion about system power transitions:
>>>
>>> "One option is to handle SYSC USB PWRRDY signal in TF-A,  if you plan to handle system transitions"
>>>
>>> (I was guessing the "system transition" statement there refers to
>>> power states transitions, ALL_ON <->
>>> AWO/VBAT)
>>
>> That is correct.
>>
>>>
>>> and I gave the booting process as a counter example: if we handle it
>>> in TF-A it may not be enough as these signals might be changed by intermediary booting applications
>> (e.g., U-Boot).
>>
>> Why should U-boot override, system state signals such as USB PWRREADY? Can you please give an example.
>>
>>>
>>> To conclude, there are 3 scenarios I see where these signals need to
>>> be
>>> handled:
>>> 1/ booting
>>> 2/ suspend to RAM
>>> 3/ driver unbind/bind
>>
>> --> It should be OK as linux is not handling USB PWRREADY signal.
>>
>>>
>>> In case of booting: if we have TF-A to set signals there might be
>>> intermediary booting applications (e.g. U-Boot) that set these signals
>>> also. If it leaves it in improper state and Linux wants to use USB then the USB will not work (if
>> Linux doesn't handle it).
>>
>> That is the problem of U-boot. U-boot should not override system state signals such as USB PWRREADY.
>>
>>>
>>> In case of suspend to RAM: as TF-A is the only application in the
>>> suspend to RAM chain, it should work handling it in TF-A.
>>
>> That is correct, TF-A should handle based on system state.
>>
>>>
>>> In case of unbind/bind: currently we don't know if these signals
>>> introduces any kind of power saving so asserting/de-asserting them in Linux may be useful from this
>> perspective, if any.
>>
>> These are system signals, according to me should not be used in unbind/bind.
>>
>> I may be wrong.
> 
> Just to add the below are the 4 system states (power mode) for this LSI.
> 
> If I understand correctly, we need to configure USB PWRRDY signal
> only when there is a transition from ALL_ON to AWO mode and vice versa.
> as you see on AWO mode only CM-33 is active.
> 
> • ALL_OFF mode: All CPUs and peripheral modules can not be worked.
> • ALL_ON mode: All CPUs and peripheral modules can be worked.
> • AWO mode: Cortex-M33 and peripheral modules in PD_VCC and PD_VBATT domain can be worked.
> • VBATT mode: Only RTC, tamper detection and backup registers can be worked.
> 
> System manager which is controlling both CA-55 and CM-33, will set USB PWRRDY signal
> based on system state.
> 
> Since we don't have system manager for controlling both CA-55 and CM-33
> Probably from CA-55 perspective, TF-A should be sufficient.
> 
> During boot clr USB PWR READY signal in TF-A.
> STR case, suspend set USB PWR READY signal in TF-A.
> STR case, resume clr USB PWR READY signal in TF-A.

As I said previously, it can be done in different ways. My point was to let
Linux set what it needs for all it's devices to work. I think the way to go
forward is a maintainer decision.

Thank you,
Claudiu Beznea

> 
> I am not expert in this area. I may be wrong.
> 
> Maybe we need to get an opinion from Power experts in Linux.
> 
> Cheers,
> Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Tuesday, September 3, 2024 11:25 AM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 10:18, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Biju Das
> >> Sent: Monday, September 2, 2024 11:48 AM
> >> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >> Hi Claudiu,
> >>
> >>> -----Original Message-----
> >>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>> Sent: Monday, September 2, 2024 11:41 AM
> >>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>> RZ/G3S SoC
> >>>
> >>>
> >>>
> >>> On 02.09.2024 12:18, Biju Das wrote:
> >>>>>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in
> linux?
> >>>>>>> As you know, the RZ/G3S USB PM code is already prepared. This is
> >>>>>>> also configuring these signals when going to suspend/exiting from resume.
> >>>>>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
> >>>>>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you
> >>>>>> plan to handle system transitions
> >>>>> there??
> >>>>>
> >>>>> As I mentioned, the settings in these registers may be changed by
> >>>>> intermediary booting
> >>> applications.
> >>>>> Depending on that, Linux need to control it also on probe for USB
> >>>>> to work (it should be the same with PCIe, these signals seems
> >>>>> similar from HW manual
> >> description).
> >>>> You mean system transition settings will be override by U-boot, so
> >>>> Linux needs to restore it
> >> back??
> >>>
> >>> It was talking about booting...
> >>
> >> I am also referring to boot. Boot starts with TF-A and it has a system state.
> >>
> >>>
> >>> You proposed to handle SYSC signals from TF-A in a discussion about system power transitions:
> >>>
> >>> "One option is to handle SYSC USB PWRRDY signal in TF-A,  if you plan to handle system
> transitions"
> >>>
> >>> (I was guessing the "system transition" statement there refers to
> >>> power states transitions, ALL_ON <->
> >>> AWO/VBAT)
> >>
> >> That is correct.
> >>
> >>>
> >>> and I gave the booting process as a counter example: if we handle it
> >>> in TF-A it may not be enough as these signals might be changed by
> >>> intermediary booting applications
> >> (e.g., U-Boot).
> >>
> >> Why should U-boot override, system state signals such as USB PWRREADY? Can you please give an
> example.
> >>
> >>>
> >>> To conclude, there are 3 scenarios I see where these signals need to
> >>> be
> >>> handled:
> >>> 1/ booting
> >>> 2/ suspend to RAM
> >>> 3/ driver unbind/bind
> >>
> >> --> It should be OK as linux is not handling USB PWRREADY signal.
> >>
> >>>
> >>> In case of booting: if we have TF-A to set signals there might be
> >>> intermediary booting applications (e.g. U-Boot) that set these
> >>> signals also. If it leaves it in improper state and Linux wants to
> >>> use USB then the USB will not work (if
> >> Linux doesn't handle it).
> >>
> >> That is the problem of U-boot. U-boot should not override system state signals such as USB
> PWRREADY.
> >>
> >>>
> >>> In case of suspend to RAM: as TF-A is the only application in the
> >>> suspend to RAM chain, it should work handling it in TF-A.
> >>
> >> That is correct, TF-A should handle based on system state.
> >>
> >>>
> >>> In case of unbind/bind: currently we don't know if these signals
> >>> introduces any kind of power saving so asserting/de-asserting them
> >>> in Linux may be useful from this
> >> perspective, if any.
> >>
> >> These are system signals, according to me should not be used in unbind/bind.
> >>
> >> I may be wrong.
> >
> > Just to add the below are the 4 system states (power mode) for this LSI.
> >
> > If I understand correctly, we need to configure USB PWRRDY signal only
> > when there is a transition from ALL_ON to AWO mode and vice versa.
> > as you see on AWO mode only CM-33 is active.
> >
> > • ALL_OFF mode: All CPUs and peripheral modules can not be worked.
> > • ALL_ON mode: All CPUs and peripheral modules can be worked.
> > • AWO mode: Cortex-M33 and peripheral modules in PD_VCC and PD_VBATT domain can be worked.
> > • VBATT mode: Only RTC, tamper detection and backup registers can be worked.
> >
> > System manager which is controlling both CA-55 and CM-33, will set USB
> > PWRRDY signal based on system state.
> >
> > Since we don't have system manager for controlling both CA-55 and
> > CM-33 Probably from CA-55 perspective, TF-A should be sufficient.
> >
> > During boot clr USB PWR READY signal in TF-A.
> > STR case, suspend set USB PWR READY signal in TF-A.
> > STR case, resume clr USB PWR READY signal in TF-A.
> 
> As I said previously, it can be done in different ways. My point was to let Linux set what it needs
> for all it's devices to work. I think the way to go forward is a maintainer decision.


I agree, there can be n number of solution for a problem.

Since you modelled system state signal (USB PWRRDY) as reset control signal, it is reset/DT maintainer's decision
to say the final word whether this signal fits in reset system framework or not?

Cheers,
biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 13:31, Biju Das wrote:
>>> During boot clr USB PWR READY signal in TF-A.
>>> STR case, suspend set USB PWR READY signal in TF-A.
>>> STR case, resume clr USB PWR READY signal in TF-A.
>> As I said previously, it can be done in different ways. My point was to let Linux set what it needs
>> for all it's devices to work. I think the way to go forward is a maintainer decision.
> 
> I agree, there can be n number of solution for a problem.
> 
> Since you modelled system state signal (USB PWRRDY) as reset control signal, it is reset/DT maintainer's decision
> to say the final word whether this signal fits in reset system framework or not?

I was thinking:
1/ Geert would be the best to say if he considers it OK to handle this
   in Linux
2/ if OK, then we should get approval from Ulf and Philipp on the power
   domain or reset approaches

Thank you,
Claudiu Beznea

> 
> Cheers,
> biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Tuesday, September 3, 2024 12:00 PM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 13:31, Biju Das wrote:
> >>> During boot clr USB PWR READY signal in TF-A.
> >>> STR case, suspend set USB PWR READY signal in TF-A.
> >>> STR case, resume clr USB PWR READY signal in TF-A.
> >> As I said previously, it can be done in different ways. My point was
> >> to let Linux set what it needs for all it's devices to work. I think the way to go forward is a
> maintainer decision.
> >
> > I agree, there can be n number of solution for a problem.
> >
> > Since you modelled system state signal (USB PWRRDY) as reset control
> > signal, it is reset/DT maintainer's decision to say the final word whether this signal fits in reset
> system framework or not?
> 
> I was thinking:
> 1/ Geert would be the best to say if he considers it OK to handle this
>    in Linux

I agree Geert is the right person for taking SYSTEM decisions,
since the signal is used only during state transitions
(Table 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)


> 2/ if OK, then we should get approval from Ulf and Philipp on the power
>    domain or reset approaches

Ok.

Cheers,
Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

> -----Original Message-----
> From: Biju Das <biju.das.jz@bp.renesas.com>
> Sent: Tuesday, September 3, 2024 12:07 PM
> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson <ulf.hansson@linaro.org>
> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; geert+renesas@glider.be; magnus.damm@gmail.com; gregkh@linuxfoundation.org;
> mturquette@baylibre.com; sboyd@kernel.org; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> renesas-soc@vger.kernel.org; linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> Hi Claudiu,
> 
> > -----Original Message-----
> > From: claudiu beznea <claudiu.beznea@tuxon.dev>
> > Sent: Tuesday, September 3, 2024 12:00 PM
> > Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> > RZ/G3S SoC
> >
> >
> >
> > On 03.09.2024 13:31, Biju Das wrote:
> > >>> During boot clr USB PWR READY signal in TF-A.
> > >>> STR case, suspend set USB PWR READY signal in TF-A.
> > >>> STR case, resume clr USB PWR READY signal in TF-A.
> > >> As I said previously, it can be done in different ways. My point
> > >> was to let Linux set what it needs for all it's devices to work. I
> > >> think the way to go forward is a
> > maintainer decision.
> > >
> > > I agree, there can be n number of solution for a problem.
> > >
> > > Since you modelled system state signal (USB PWRRDY) as reset control
> > > signal, it is reset/DT maintainer's decision to say the final word
> > > whether this signal fits in reset
> > system framework or not?
> >
> > I was thinking:
> > 1/ Geert would be the best to say if he considers it OK to handle this
> >    in Linux
> 
> I agree Geert is the right person for taking SYSTEM decisions, since the signal is used only during
> state transitions (Table 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)

One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.

All clocks/reset happens after setting USB PWRRDY signal

https://pasteboard.co/qbz021q7KPyi.png

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 15:00, Biju Das wrote:
> 
> 
>> -----Original Message-----
>> From: Biju Das <biju.das.jz@bp.renesas.com>
>> Sent: Tuesday, September 3, 2024 12:07 PM
>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson <ulf.hansson@linaro.org>
>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
>> p.zabel@pengutronix.de; geert+renesas@glider.be; magnus.damm@gmail.com; gregkh@linuxfoundation.org;
>> mturquette@baylibre.com; sboyd@kernel.org; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>> renesas-soc@vger.kernel.org; linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>> Hi Claudiu,
>>
>>> -----Original Message-----
>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>> Sent: Tuesday, September 3, 2024 12:00 PM
>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>> RZ/G3S SoC
>>>
>>>
>>>
>>> On 03.09.2024 13:31, Biju Das wrote:
>>>>>> During boot clr USB PWR READY signal in TF-A.
>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
>>>>> As I said previously, it can be done in different ways. My point
>>>>> was to let Linux set what it needs for all it's devices to work. I
>>>>> think the way to go forward is a
>>> maintainer decision.
>>>>
>>>> I agree, there can be n number of solution for a problem.
>>>>
>>>> Since you modelled system state signal (USB PWRRDY) as reset control
>>>> signal, it is reset/DT maintainer's decision to say the final word
>>>> whether this signal fits in reset
>>> system framework or not?
>>>
>>> I was thinking:
>>> 1/ Geert would be the best to say if he considers it OK to handle this
>>>    in Linux
>>
>> I agree Geert is the right person for taking SYSTEM decisions, since the signal is used only during
>> state transitions (Table 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> 
> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.

The "controlled by" column mentions CA-55 on PWRRDY signal control line and
it is b/w steps "DDR exits from retention mode" and  "clock start settings
for system bus and peripheral modules". AFAICT, after DDR exists retention
mode Linux is ready to run.

E.g. on resume Linux doesn't sets the clocks of all peripheral in sequence
and then runs the rest of settings for each peripheral, in turn it sets the
clock of one peripheral along with all the other necessary peripheral
settings and then continues with the rest of peripherals (including their
clocks).

> 
> All clocks/reset happens after setting USB PWRRDY signal
> 
> https://pasteboard.co/qbz021q7KPyi.png
> 
> Cheers,
> Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Tuesday, September 3, 2024 1:26 PM
> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson <ulf.hansson@linaro.org>
> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; geert+renesas@glider.be; magnus.damm@gmail.com; gregkh@linuxfoundation.org;
> mturquette@baylibre.com; sboyd@kernel.org; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> renesas-soc@vger.kernel.org; linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 15:00, Biju Das wrote:
> >
> >
> >> -----Original Message-----
> >> From: Biju Das <biju.das.jz@bp.renesas.com>
> >> Sent: Tuesday, September 3, 2024 12:07 PM
> >> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
> >> <ulf.hansson@linaro.org>
> >> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >> geert+renesas@glider.be; magnus.damm@gmail.com;
> >> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >> sboyd@kernel.org; Yoshihiro Shimoda
> >> <yoshihiro.shimoda.uh@renesas.com>;
> >> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
> >> <claudiu.beznea.uj@bp.renesas.com>
> >> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >> Hi Claudiu,
> >>
> >>> -----Original Message-----
> >>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>> Sent: Tuesday, September 3, 2024 12:00 PM
> >>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>> RZ/G3S SoC
> >>>
> >>>
> >>>
> >>> On 03.09.2024 13:31, Biju Das wrote:
> >>>>>> During boot clr USB PWR READY signal in TF-A.
> >>>>>> STR case, suspend set USB PWR READY signal in TF-A.
> >>>>>> STR case, resume clr USB PWR READY signal in TF-A.
> >>>>> As I said previously, it can be done in different ways. My point
> >>>>> was to let Linux set what it needs for all it's devices to work. I
> >>>>> think the way to go forward is a
> >>> maintainer decision.
> >>>>
> >>>> I agree, there can be n number of solution for a problem.
> >>>>
> >>>> Since you modelled system state signal (USB PWRRDY) as reset
> >>>> control signal, it is reset/DT maintainer's decision to say the
> >>>> final word whether this signal fits in reset
> >>> system framework or not?
> >>>
> >>> I was thinking:
> >>> 1/ Geert would be the best to say if he considers it OK to handle this
> >>>    in Linux
> >>
> >> I agree Geert is the right person for taking SYSTEM decisions, since
> >> the signal is used only during state transitions (Table 41.6.4 AWO to
> >> ALL_ON and 41.6.3 ALL_ON to AWO)
> >
> > One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
> 
> The "controlled by" column mentions CA-55 on PWRRDY signal control line and it is b/w steps "DDR exits
> from retention mode" and  "clock start settings for system bus and peripheral modules". AFAICT, after
> DDR exists retention mode Linux is ready to run.

DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2 checks for warm or cold reset.
If it is warm reset, it sets required minimal clocks/resets and pass the control to linux by calling the
SMC callback handler. Which in turn calls resume(step 11-->14) path.

Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting for exiting form DDR retention mode
Step 9, Cortex-A55 USB PHY PWRRDY signal control (if use USB) SYS_USB_PWRRDY
Step 10, Cortex-A55 PCIe RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
Step 11, Cortex-A55 Clock start setting for system bus and desired peripheral modules in PD_ISOVCC CPG_CLKON_***ep 
(***: GIC600, MHU, SDHI, USB, ETH, DDR, PCI,AXI_COM_BUS, PERI_COM, AXI_TZCDDR,
OTFDE_DDR)
Step 12, Cortex-A55 Release reset setting for system bus and desired peripheral modules in PD_ISOVCC CPG_RST_***
(***: GIC600, MHU, SDHI, USB, ETH, DDR, PCI, AXI_COM_BUS, PERI_COM, AXI_TZCDDR,OTFDE_DDR)
Step 13, Cortex-A55 Release MSTOP bit for system bus and desired peripheral modules in PD_ISOVCC CPG_BUS_***_MSTOP
(***: ACPU, PERI_COM, PERI_DDR, TZCDDR),
CPG_MHU_MSTOP.
Step14) Cortex-A55 Clock start setting and reset release setting for Cortex-M33_FPU (if use Cortex-M33_FPU)
CPG_CLKON_CM33, CPG_RST_CM33

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 15:37, Biju Das wrote:
> 
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>> Sent: Tuesday, September 3, 2024 1:26 PM
>> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson <ulf.hansson@linaro.org>
>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
>> p.zabel@pengutronix.de; geert+renesas@glider.be; magnus.damm@gmail.com; gregkh@linuxfoundation.org;
>> mturquette@baylibre.com; sboyd@kernel.org; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>> renesas-soc@vger.kernel.org; linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>>
>>
>> On 03.09.2024 15:00, Biju Das wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
>>>> Sent: Tuesday, September 3, 2024 12:07 PM
>>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
>>>> <ulf.hansson@linaro.org>
>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
>>>> <claudiu.beznea.uj@bp.renesas.com>
>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
>>>> RZ/G3S SoC
>>>>
>>>> Hi Claudiu,
>>>>
>>>>> -----Original Message-----
>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>>> Sent: Tuesday, September 3, 2024 12:00 PM
>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>>> RZ/G3S SoC
>>>>>
>>>>>
>>>>>
>>>>> On 03.09.2024 13:31, Biju Das wrote:
>>>>>>>> During boot clr USB PWR READY signal in TF-A.
>>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
>>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
>>>>>>> As I said previously, it can be done in different ways. My point
>>>>>>> was to let Linux set what it needs for all it's devices to work. I
>>>>>>> think the way to go forward is a
>>>>> maintainer decision.
>>>>>>
>>>>>> I agree, there can be n number of solution for a problem.
>>>>>>
>>>>>> Since you modelled system state signal (USB PWRRDY) as reset
>>>>>> control signal, it is reset/DT maintainer's decision to say the
>>>>>> final word whether this signal fits in reset
>>>>> system framework or not?
>>>>>
>>>>> I was thinking:
>>>>> 1/ Geert would be the best to say if he considers it OK to handle this
>>>>>    in Linux
>>>>
>>>> I agree Geert is the right person for taking SYSTEM decisions, since
>>>> the signal is used only during state transitions (Table 41.6.4 AWO to
>>>> ALL_ON and 41.6.3 ALL_ON to AWO)
>>>
>>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
>>
>> The "controlled by" column mentions CA-55 on PWRRDY signal control line and it is b/w steps "DDR exits
>> from retention mode" and  "clock start settings for system bus and peripheral modules". AFAICT, after
>> DDR exists retention mode Linux is ready to run.
> 
> DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2 checks for warm or cold reset.
> If it is warm reset, it sets required minimal clocks/resets and pass the control to linux by calling the
> SMC callback handler. Which in turn calls resume(step 11-->14) path.

Is this from HW manual or some specific documentation? I'm referring at
"resume" == "steps 11-->14"

> 
> Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting for exiting form DDR retention mode
> Step 9, Cortex-A55 USB PHY PWRRDY signal control (if use USB) SYS_USB_PWRRDY
> Step 10, Cortex-A55 PCIe RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B

Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The
documentation mention to set it *if use*. Same note is on ALL_ON to VBATT
transition documentation (namely "if using USB", "if using PCIe"). If TF-A
will do this it should set this signals unconditionally. It will not be
something wrong though. We don't know at the moment what this involves in
terms of power consumption, if it means something...

> Step 11, Cortex-A55 Clock start setting for system bus and desired peripheral modules in PD_ISOVCC CPG_CLKON_***ep 
> (***: GIC600, MHU, SDHI, USB, ETH, DDR, PCI,AXI_COM_BUS, PERI_COM, AXI_TZCDDR,
> OTFDE_DDR)
> Step 12, Cortex-A55 Release reset setting for system bus and desired peripheral modules in PD_ISOVCC CPG_RST_***
> (***: GIC600, MHU, SDHI, USB, ETH, DDR, PCI, AXI_COM_BUS, PERI_COM, AXI_TZCDDR,OTFDE_DDR)
> Step 13, Cortex-A55 Release MSTOP bit for system bus and desired peripheral modules in PD_ISOVCC CPG_BUS_***_MSTOP
> (***: ACPU, PERI_COM, PERI_DDR, TZCDDR),
> CPG_MHU_MSTOP.
> Step14) Cortex-A55 Clock start setting and reset release setting for Cortex-M33_FPU (if use Cortex-M33_FPU)
> CPG_CLKON_CM33, CPG_RST_CM33
> 
> Cheers,
> Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Tuesday, September 3, 2024 1:57 PM
-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 15:37, Biju Das wrote:
> >
> >
> >> -----Original Message-----
> >> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >> Sent: Tuesday, September 3, 2024 1:26 PM
> >> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
> >> <ulf.hansson@linaro.org>
> >> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >> geert+renesas@glider.be; magnus.damm@gmail.com;
> >> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >> sboyd@kernel.org; Yoshihiro Shimoda
> >> <yoshihiro.shimoda.uh@renesas.com>;
> >> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
> >> <claudiu.beznea.uj@bp.renesas.com>
> >> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >>
> >>
> >> On 03.09.2024 15:00, Biju Das wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Biju Das <biju.das.jz@bp.renesas.com>
> >>>> Sent: Tuesday, September 3, 2024 12:07 PM
> >>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
> >>>> <ulf.hansson@linaro.org>
> >>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >>>> geert+renesas@glider.be; magnus.damm@gmail.com;
> >>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >>>> sboyd@kernel.org; Yoshihiro Shimoda
> >>>> <yoshihiro.shimoda.uh@renesas.com>;
> >>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
> >>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >>>> RZ/G3S SoC
> >>>>
> >>>> Hi Claudiu,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>>>> Sent: Tuesday, September 3, 2024 12:00 PM
> >>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>>>> RZ/G3S SoC
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 03.09.2024 13:31, Biju Das wrote:
> >>>>>>>> During boot clr USB PWR READY signal in TF-A.
> >>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
> >>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
> >>>>>>> As I said previously, it can be done in different ways. My point
> >>>>>>> was to let Linux set what it needs for all it's devices to work.
> >>>>>>> I think the way to go forward is a
> >>>>> maintainer decision.
> >>>>>>
> >>>>>> I agree, there can be n number of solution for a problem.
> >>>>>>
> >>>>>> Since you modelled system state signal (USB PWRRDY) as reset
> >>>>>> control signal, it is reset/DT maintainer's decision to say the
> >>>>>> final word whether this signal fits in reset
> >>>>> system framework or not?
> >>>>>
> >>>>> I was thinking:
> >>>>> 1/ Geert would be the best to say if he considers it OK to handle this
> >>>>>    in Linux
> >>>>
> >>>> I agree Geert is the right person for taking SYSTEM decisions,
> >>>> since the signal is used only during state transitions (Table
> >>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> >>>
> >>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
> >>
> >> The "controlled by" column mentions CA-55 on PWRRDY signal control
> >> line and it is b/w steps "DDR exits from retention mode" and  "clock
> >> start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
> Linux is ready to run.
> >
> > DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
> checks for warm or cold reset.
> > If it is warm reset, it sets required minimal clocks/resets and pass
> > the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
> path.
> 
> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
> 
> >
> > Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
> > for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
> > signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
> > RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
> 
> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
> it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
> using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
> something wrong though. We don't know at the moment what this involves in terms of power consumption,
> if it means something...

You mean, you modelled this as reset signal just to reduce power consumption by calling runtime PM
calls to turn on/off this signal??

Does will it have any system stability issue as hardware manual says to do it at very early stage
before starting any clocks/resets?? Have you checked with hardware team?

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 16:09, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>> Sent: Tuesday, September 3, 2024 1:57 PM
> -
>> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>>
>>
>> On 03.09.2024 15:37, Biju Das wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>> Sent: Tuesday, September 3, 2024 1:26 PM
>>>> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
>>>> <ulf.hansson@linaro.org>
>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
>>>> <claudiu.beznea.uj@bp.renesas.com>
>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>> RZ/G3S SoC
>>>>
>>>>
>>>>
>>>> On 03.09.2024 15:00, Biju Das wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
>>>>>> Sent: Tuesday, September 3, 2024 12:07 PM
>>>>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
>>>>>> <ulf.hansson@linaro.org>
>>>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
>>>>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
>>>>>> RZ/G3S SoC
>>>>>>
>>>>>> Hi Claudiu,
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>>>>> Sent: Tuesday, September 3, 2024 12:00 PM
>>>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>>>>> RZ/G3S SoC
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 03.09.2024 13:31, Biju Das wrote:
>>>>>>>>>> During boot clr USB PWR READY signal in TF-A.
>>>>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
>>>>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
>>>>>>>>> As I said previously, it can be done in different ways. My point
>>>>>>>>> was to let Linux set what it needs for all it's devices to work.
>>>>>>>>> I think the way to go forward is a
>>>>>>> maintainer decision.
>>>>>>>>
>>>>>>>> I agree, there can be n number of solution for a problem.
>>>>>>>>
>>>>>>>> Since you modelled system state signal (USB PWRRDY) as reset
>>>>>>>> control signal, it is reset/DT maintainer's decision to say the
>>>>>>>> final word whether this signal fits in reset
>>>>>>> system framework or not?
>>>>>>>
>>>>>>> I was thinking:
>>>>>>> 1/ Geert would be the best to say if he considers it OK to handle this
>>>>>>>    in Linux
>>>>>>
>>>>>> I agree Geert is the right person for taking SYSTEM decisions,
>>>>>> since the signal is used only during state transitions (Table
>>>>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
>>>>>
>>>>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
>>>>
>>>> The "controlled by" column mentions CA-55 on PWRRDY signal control
>>>> line and it is b/w steps "DDR exits from retention mode" and  "clock
>>>> start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
>> Linux is ready to run.
>>>
>>> DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
>> checks for warm or cold reset.
>>> If it is warm reset, it sets required minimal clocks/resets and pass
>>> the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
>> path.
>>
>> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"

You branched the discussion, there was at least this question that I've
asked you above that interested me.

>>
>>>
>>> Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
>>> for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
>>> signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
>>> RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
>>
>> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
>> it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
>> using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
>> something wrong though. We don't know at the moment what this involves in terms of power consumption,
>> if it means something...
> 
> You mean, you modelled this as reset signal just to reduce power consumption by calling runtime PM
> calls to turn on/off this signal??

In this series it is though a reset control driver.

The internal BSP propose the control of this signal though SMC calls in
each individual USB driver; I think the hardware team was checked for this;
I may be wrong, as I don't have this insight.

As you know, the initial control of these bits in the BSP was though SMC
calls and you propose to have a separate Linux driver to control this after
finding that these registers are accessible in normal world. As a result,
this series, with reset approach, which you were against, but I felt this
was the best way (I know) to describe the hardware and the relation b/w
hardware blocks. To conclude, you initially proposed me internally to have
it in Linux.

To answer your question, the answer is no, I didn't try to just model
something fancy just to be fancy. I did it based on what is proposed in BSP
as this may have been checked with hardware team and I did tests around
this. And considering this best describes the HW and the relation b/w
individual hardware blocks and in this way Linux can have at its hand all
the resources it needs w/o relying on third parties. And from the HW manual
description my understanding was that this is possible. I never said that
this solution is the best. I'm just adding information here as I requested
help from maintainers to guide on the proper direction.

You were adding information to sustain your TF-A idea, too.

> 
> Does will it have any system stability issue as hardware manual says to do it at very early stage
> before starting any clocks/resets?? Have you checked with hardware team?

All the implementation of this is based on what has been proposed on BSP,
the same approach was proposed there, meaning the control of these signals
was done on probe/remove, suspend/resume in Linux.


> 
> Cheers,
> Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Tuesday, September 3, 2024 3:46 PM


> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 16:09, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >> Sent: Tuesday, September 3, 2024 1:57 PM
> > -
> >> clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
> >> <claudiu.beznea.uj@bp.renesas.com>
> >> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >>
> >>
> >> On 03.09.2024 15:37, Biju Das wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>>> Sent: Tuesday, September 3, 2024 1:26 PM
> >>>> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
> >>>> <ulf.hansson@linaro.org>
> >>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >>>> geert+renesas@glider.be; magnus.damm@gmail.com;
> >>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >>>> sboyd@kernel.org; Yoshihiro Shimoda
> >>>> <yoshihiro.shimoda.uh@renesas.com>;
> >>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
> >>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>>> RZ/G3S SoC
> >>>>
> >>>>
> >>>>
> >>>> On 03.09.2024 15:00, Biju Das wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
> >>>>>> Sent: Tuesday, September 3, 2024 12:07 PM
> >>>>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
> >>>>>> <ulf.hansson@linaro.org>
> >>>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >>>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >>>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
> >>>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >>>>>> sboyd@kernel.org; Yoshihiro Shimoda
> >>>>>> <yoshihiro.shimoda.uh@renesas.com>;
> >>>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >>>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >>>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >>>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
> >>>>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the
> >>>>>> Renesas RZ/G3S SoC
> >>>>>>
> >>>>>> Hi Claudiu,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>>>>>> Sent: Tuesday, September 3, 2024 12:00 PM
> >>>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the
> >>>>>>> Renesas RZ/G3S SoC
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 03.09.2024 13:31, Biju Das wrote:
> >>>>>>>>>> During boot clr USB PWR READY signal in TF-A.
> >>>>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
> >>>>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
> >>>>>>>>> As I said previously, it can be done in different ways. My
> >>>>>>>>> point was to let Linux set what it needs for all it's devices to work.
> >>>>>>>>> I think the way to go forward is a
> >>>>>>> maintainer decision.
> >>>>>>>>
> >>>>>>>> I agree, there can be n number of solution for a problem.
> >>>>>>>>
> >>>>>>>> Since you modelled system state signal (USB PWRRDY) as reset
> >>>>>>>> control signal, it is reset/DT maintainer's decision to say the
> >>>>>>>> final word whether this signal fits in reset
> >>>>>>> system framework or not?
> >>>>>>>
> >>>>>>> I was thinking:
> >>>>>>> 1/ Geert would be the best to say if he considers it OK to handle this
> >>>>>>>    in Linux
> >>>>>>
> >>>>>> I agree Geert is the right person for taking SYSTEM decisions,
> >>>>>> since the signal is used only during state transitions (Table
> >>>>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> >>>>>
> >>>>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
> >>>>
> >>>> The "controlled by" column mentions CA-55 on PWRRDY signal control
> >>>> line and it is b/w steps "DDR exits from retention mode" and
> >>>> "clock start settings for system bus and peripheral modules".
> >>>> AFAICT, after DDR exists retention mode
> >> Linux is ready to run.
> >>>
> >>> DDR retention exit happens in TF-A and it jumps into reset code
> >>> where it executes BL2 in TF_A. Bl2
> >> checks for warm or cold reset.
> >>> If it is warm reset, it sets required minimal clocks/resets and pass
> >>> the control to linux by calling the SMC callback handler. Which in
> >>> turn calls resume(step 11-->14)
> >> path.
> >>
> >> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
> 
> You branched the discussion, there was at least this question that I've asked you above that
> interested me.

if there is DDR retention exit involved,
Step 11->14 is just like resume path, for each IP it need clock , reset and restore registers from DDR backup.

> 
> >>
> >>>
> >>> Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
> >>> for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY
> >>> PWRRDY signal control (if use USB) SYS_USB_PWRRDY Step 10,
> >>> Cortex-A55 PCIe RST_RSM_B signal control (if use PCIe)
> >>> SYS_PCIE_RST_RSM_B
> >>
> >> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux?
> >> The documentation mention to set it *if use*. Same note is on ALL_ON
> >> to VBATT transition documentation (namely "if using USB", "if using
> >> PCIe"). If TF-A will do this it should set this signals
> >> unconditionally. It will not be something wrong though. We don't know at the moment what this
> involves in terms of power consumption, if it means something...
> >
> > You mean, you modelled this as reset signal just to reduce power
> > consumption by calling runtime PM calls to turn on/off this signal??
> 
> In this series it is though a reset control driver.
> 
> The internal BSP propose the control of this signal though SMC calls in each individual USB driver; I
> think the hardware team was checked for this; I may be wrong, as I don't have this insight.
> 
> As you know, the initial control of these bits in the BSP was though SMC calls and you propose to have
> a separate Linux driver to control this after finding that these registers are accessible in normal
> world. As a result, this series, with reset approach, which you were against, but I felt this was the
> best way (I know) to describe the hardware and the relation b/w hardware blocks. To conclude, you
> initially proposed me internally to have it in Linux.

I agree, I proposed to have Linux SYSC driver instead of calling SMC calls from PHY control driver(Reset)

Currently we explored 4 approaches to avoid SMC calls from PHY control driver.

1) modelling this as reset signal
2) power domain approach 
3) set this in SYSC driver during early boot.
4) handle this in TF-A.

> 
> To answer your question, the answer is no, I didn't try to just model something fancy just to be
> fancy. I did it based on what is proposed in BSP as this may have been checked with hardware team and
> I did tests around this. And considering this best describes the HW and the relation b/w individual
> hardware blocks and in this way Linux can have at its hand all the resources it needs w/o relying on
> third parties. And from the HW manual description my understanding was that this is possible. I never
> said that this solution is the best. I'm just adding information here as I requested help from
> maintainers to guide on the proper direction.
> 
> You were adding information to sustain your TF-A idea, too.

This is just an option based on the hardware manual tables where SYSC signal is turned on 
just after DDR retention exit and before starting the clocks/resets.

> 
> >
> > Does will it have any system stability issue as hardware manual says
> > to do it at very early stage before starting any clocks/resets?? Have you checked with hardware
> team?
> 
> All the implementation of this is based on what has been proposed on BSP, the same approach was
> proposed there, meaning the control of these signals was done on probe/remove, suspend/resume in
> Linux.

Based on Hardware manual state transition tables, USBPWRRDY signal is set before starting clocks/reset of the IPs.
If there is no stability issue with BSP approach, then there is no harm in what you have implemented.

Cheers,
Biju

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> Sent: Tuesday, September 3, 2024 1:57 PM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 15:37, Biju Das wrote:
> >
> >
> >> -----Original Message-----
> >> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >> Sent: Tuesday, September 3, 2024 1:26 PM
> >> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
> >> <ulf.hansson@linaro.org>
> >> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >> geert+renesas@glider.be; magnus.damm@gmail.com;
> >> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >> sboyd@kernel.org; Yoshihiro Shimoda
> >> <yoshihiro.shimoda.uh@renesas.com>;
> >> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
> >> <claudiu.beznea.uj@bp.renesas.com>
> >> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >>
> >>
> >> On 03.09.2024 15:00, Biju Das wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Biju Das <biju.das.jz@bp.renesas.com>
> >>>> Sent: Tuesday, September 3, 2024 12:07 PM
> >>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
> >>>> <ulf.hansson@linaro.org>
> >>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> >>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> >>>> geert+renesas@glider.be; magnus.damm@gmail.com;
> >>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
> >>>> sboyd@kernel.org; Yoshihiro Shimoda
> >>>> <yoshihiro.shimoda.uh@renesas.com>;
> >>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> >>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> >>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
> >>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
> >>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >>>> RZ/G3S SoC
> >>>>
> >>>> Hi Claudiu,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
> >>>>> Sent: Tuesday, September 3, 2024 12:00 PM
> >>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>>>> RZ/G3S SoC
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 03.09.2024 13:31, Biju Das wrote:
> >>>>>>>> During boot clr USB PWR READY signal in TF-A.
> >>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
> >>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
> >>>>>>> As I said previously, it can be done in different ways. My point
> >>>>>>> was to let Linux set what it needs for all it's devices to work.
> >>>>>>> I think the way to go forward is a
> >>>>> maintainer decision.
> >>>>>>
> >>>>>> I agree, there can be n number of solution for a problem.
> >>>>>>
> >>>>>> Since you modelled system state signal (USB PWRRDY) as reset
> >>>>>> control signal, it is reset/DT maintainer's decision to say the
> >>>>>> final word whether this signal fits in reset
> >>>>> system framework or not?
> >>>>>
> >>>>> I was thinking:
> >>>>> 1/ Geert would be the best to say if he considers it OK to handle this
> >>>>>    in Linux
> >>>>
> >>>> I agree Geert is the right person for taking SYSTEM decisions,
> >>>> since the signal is used only during state transitions (Table
> >>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> >>>
> >>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
> >>
> >> The "controlled by" column mentions CA-55 on PWRRDY signal control
> >> line and it is b/w steps "DDR exits from retention mode" and  "clock
> >> start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
> Linux is ready to run.
> >
> > DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
> checks for warm or cold reset.
> > If it is warm reset, it sets required minimal clocks/resets and pass
> > the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
> path.
> 
> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
> 
> >
> > Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
> > for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
> > signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
> > RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
> 
> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
> it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
> using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
> something wrong though. We don't know at the moment what this involves in terms of power consumption,
> if it means something...

IIUC,
The only information we have is,

"SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
"When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break"

ALL_ON to AWO_MODE state transition: 
USB/PCIe are part of PD_ISOVCC power domain and before turning PD_ISOVCC to off,
we need to set USBPWRRDY signal.

AWO_MODE to ALL_ON state transition:

Turn on PD_ISOVCC first, then clr USBPWRRDY signal for USB usage in linux.

Maybe we need to ask hw team, exact usage of USBPWRRDY signal other than state transition.

Cheers,
Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 03.09.2024 16:45, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>> Sent: Tuesday, September 3, 2024 1:57 PM
>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>>
>>
>> On 03.09.2024 15:37, Biju Das wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>> Sent: Tuesday, September 3, 2024 1:26 PM
>>>> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
>>>> <ulf.hansson@linaro.org>
>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
>>>> <claudiu.beznea.uj@bp.renesas.com>
>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>> RZ/G3S SoC
>>>>
>>>>
>>>>
>>>> On 03.09.2024 15:00, Biju Das wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
>>>>>> Sent: Tuesday, September 3, 2024 12:07 PM
>>>>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
>>>>>> <ulf.hansson@linaro.org>
>>>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
>>>>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
>>>>>> RZ/G3S SoC
>>>>>>
>>>>>> Hi Claudiu,
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>>>>> Sent: Tuesday, September 3, 2024 12:00 PM
>>>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>>>>> RZ/G3S SoC
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 03.09.2024 13:31, Biju Das wrote:
>>>>>>>>>> During boot clr USB PWR READY signal in TF-A.
>>>>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
>>>>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
>>>>>>>>> As I said previously, it can be done in different ways. My point
>>>>>>>>> was to let Linux set what it needs for all it's devices to work.
>>>>>>>>> I think the way to go forward is a
>>>>>>> maintainer decision.
>>>>>>>>
>>>>>>>> I agree, there can be n number of solution for a problem.
>>>>>>>>
>>>>>>>> Since you modelled system state signal (USB PWRRDY) as reset
>>>>>>>> control signal, it is reset/DT maintainer's decision to say the
>>>>>>>> final word whether this signal fits in reset
>>>>>>> system framework or not?
>>>>>>>
>>>>>>> I was thinking:
>>>>>>> 1/ Geert would be the best to say if he considers it OK to handle this
>>>>>>>    in Linux
>>>>>>
>>>>>> I agree Geert is the right person for taking SYSTEM decisions,
>>>>>> since the signal is used only during state transitions (Table
>>>>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
>>>>>
>>>>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
>>>>
>>>> The "controlled by" column mentions CA-55 on PWRRDY signal control
>>>> line and it is b/w steps "DDR exits from retention mode" and  "clock
>>>> start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
>> Linux is ready to run.
>>>
>>> DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
>> checks for warm or cold reset.
>>> If it is warm reset, it sets required minimal clocks/resets and pass
>>> the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
>> path.
>>
>> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
>>
>>>
>>> Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
>>> for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
>>> signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
>>> RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
>>
>> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
>> it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
>> using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
>> something wrong though. We don't know at the moment what this involves in terms of power consumption,
>> if it means something...
> 
> IIUC,
> The only information we have is,
> 
> "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
> "When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break"
> 
> ALL_ON to AWO_MODE state transition: 
> USB/PCIe are part of PD_ISOVCC power domain and before turning PD_ISOVCC to off,
> we need to set USBPWRRDY signal.
> 
> AWO_MODE to ALL_ON state transition:
> 
> Turn on PD_ISOVCC first, then clr USBPWRRDY signal for USB usage in linux.
> 
> Maybe we need to ask hw team, exact usage of USBPWRRDY signal other than state transition.

As you may already know, this is open for quite some time and is ongoing.

> 
> Cheers,
> Biju
> 
> 

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Claudiu Beznea]

Hi, all,

On 03.09.2024 17:48, claudiu beznea wrote:
> 
> 
> On 03.09.2024 16:45, Biju Das wrote:
>> Hi Claudiu,
>>
>>> -----Original Message-----
>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>> Sent: Tuesday, September 3, 2024 1:57 PM
>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>>
>>>
>>>
>>> On 03.09.2024 15:37, Biju Das wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>>> Sent: Tuesday, September 3, 2024 1:26 PM
>>>>> To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
>>>>> <ulf.hansson@linaro.org>
>>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
>>>>> <claudiu.beznea.uj@bp.renesas.com>
>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>>> RZ/G3S SoC
>>>>>
>>>>>
>>>>>
>>>>> On 03.09.2024 15:00, Biju Das wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Biju Das <biju.das.jz@bp.renesas.com>
>>>>>>> Sent: Tuesday, September 3, 2024 12:07 PM
>>>>>>> To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
>>>>>>> <ulf.hansson@linaro.org>
>>>>>>> Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
>>>>>>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
>>>>>>> geert+renesas@glider.be; magnus.damm@gmail.com;
>>>>>>> gregkh@linuxfoundation.org; mturquette@baylibre.com;
>>>>>>> sboyd@kernel.org; Yoshihiro Shimoda
>>>>>>> <yoshihiro.shimoda.uh@renesas.com>;
>>>>>>> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
>>>>>>> linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
>>>>>>> linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>>>>> linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
>>>>>>> Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
>>>>>>> RZ/G3S SoC
>>>>>>>
>>>>>>> Hi Claudiu,
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>>>>>>>> Sent: Tuesday, September 3, 2024 12:00 PM
>>>>>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
>>>>>>>> RZ/G3S SoC
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03.09.2024 13:31, Biju Das wrote:
>>>>>>>>>>> During boot clr USB PWR READY signal in TF-A.
>>>>>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
>>>>>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
>>>>>>>>>> As I said previously, it can be done in different ways. My point
>>>>>>>>>> was to let Linux set what it needs for all it's devices to work.
>>>>>>>>>> I think the way to go forward is a
>>>>>>>> maintainer decision.
>>>>>>>>>
>>>>>>>>> I agree, there can be n number of solution for a problem.
>>>>>>>>>
>>>>>>>>> Since you modelled system state signal (USB PWRRDY) as reset
>>>>>>>>> control signal, it is reset/DT maintainer's decision to say the
>>>>>>>>> final word whether this signal fits in reset
>>>>>>>> system framework or not?
>>>>>>>>
>>>>>>>> I was thinking:
>>>>>>>> 1/ Geert would be the best to say if he considers it OK to handle this
>>>>>>>>    in Linux
>>>>>>>
>>>>>>> I agree Geert is the right person for taking SYSTEM decisions,
>>>>>>> since the signal is used only during state transitions (Table
>>>>>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
>>>>>>
>>>>>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
>>>>>
>>>>> The "controlled by" column mentions CA-55 on PWRRDY signal control
>>>>> line and it is b/w steps "DDR exits from retention mode" and  "clock
>>>>> start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
>>> Linux is ready to run.
>>>>
>>>> DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
>>> checks for warm or cold reset.
>>>> If it is warm reset, it sets required minimal clocks/resets and pass
>>>> the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
>>> path.
>>>
>>> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
>>>
>>>>
>>>> Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
>>>> for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
>>>> signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
>>>> RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
>>>
>>> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
>>> it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
>>> using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
>>> something wrong though. We don't know at the moment what this involves in terms of power consumption,
>>> if it means something...
>>
>> IIUC,
>> The only information we have is,
>>
>> "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
>> "When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break"
>>
>> ALL_ON to AWO_MODE state transition: 
>> USB/PCIe are part of PD_ISOVCC power domain and before turning PD_ISOVCC to off,
>> we need to set USBPWRRDY signal.
>>
>> AWO_MODE to ALL_ON state transition:
>>
>> Turn on PD_ISOVCC first, then clr USBPWRRDY signal for USB usage in linux.
>>
>> Maybe we need to ask hw team, exact usage of USBPWRRDY signal other than state transition.
> 
> As you may already know, this is open for quite some time and is ongoing.

I got more clarification about the USB PWRRDY signal from the HW team.

The conclusion is that the USB PWRRDY is a signal controlled by SYSC
controller that goes to the USB PHY and it tells the USB PHY if the power
supply is ready or not.

In the diagram at [1] the PWRRDY signal need to be asserted/de-asserted
before/after G6, G7, G8, G9, G10 signals.

Philipp,

Can you please confirm that you don't want this signal to be implemented as
a reset signal to know clearly your input on it? I would like to start
looking for another approach in that case.

Thank you,
Claudiu Beznea

[1] https://pasteboard.co/0a1zYBFZXZVb.png

> 
>>
>> Cheers,
>> Biju
>>
>>

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Philipp Zabel]

Hi Claudiu,

On Do, 2024-11-07 at 12:00 +0200, Claudiu Beznea wrote:
> Hi, all,
> 
> On 03.09.2024 17:48, claudiu beznea wrote:
> > 
> > 
> > On 03.09.2024 16:45, Biju Das wrote:
> > > Hi Claudiu,
> > > 
> > > > -----Original Message-----
> > > > From: claudiu beznea <claudiu.beznea@tuxon.dev>
> > > > Sent: Tuesday, September 3, 2024 1:57 PM
> > > > Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> > > > 
> > > > 
> > > > 
> > > > On 03.09.2024 15:37, Biju Das wrote:
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: claudiu beznea <claudiu.beznea@tuxon.dev>
> > > > > > Sent: Tuesday, September 3, 2024 1:26 PM
> > > > > > To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
> > > > > > <ulf.hansson@linaro.org>
> > > > > > Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> > > > > > krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> > > > > > geert+renesas@glider.be; magnus.damm@gmail.com;
> > > > > > gregkh@linuxfoundation.org; mturquette@baylibre.com;
> > > > > > sboyd@kernel.org; Yoshihiro Shimoda
> > > > > > <yoshihiro.shimoda.uh@renesas.com>;
> > > > > > linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> > > > > > linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> > > > > > linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > > > linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
> > > > > > <claudiu.beznea.uj@bp.renesas.com>
> > > > > > Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> > > > > > RZ/G3S SoC
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 03.09.2024 15:00, Biju Das wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Biju Das <biju.das.jz@bp.renesas.com>
> > > > > > > > Sent: Tuesday, September 3, 2024 12:07 PM
> > > > > > > > To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
> > > > > > > > <ulf.hansson@linaro.org>
> > > > > > > > Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
> > > > > > > > krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
> > > > > > > > geert+renesas@glider.be; magnus.damm@gmail.com;
> > > > > > > > gregkh@linuxfoundation.org; mturquette@baylibre.com;
> > > > > > > > sboyd@kernel.org; Yoshihiro Shimoda
> > > > > > > > <yoshihiro.shimoda.uh@renesas.com>;
> > > > > > > > linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> > > > > > > > linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
> > > > > > > > linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > > > > > linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
> > > > > > > > Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > > > > > Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> > > > > > > > RZ/G3S SoC
> > > > > > > > 
> > > > > > > > Hi Claudiu,
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: claudiu beznea <claudiu.beznea@tuxon.dev>
> > > > > > > > > Sent: Tuesday, September 3, 2024 12:00 PM
> > > > > > > > > Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> > > > > > > > > RZ/G3S SoC
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 03.09.2024 13:31, Biju Das wrote:
> > > > > > > > > > > > During boot clr USB PWR READY signal in TF-A.
> > > > > > > > > > > > STR case, suspend set USB PWR READY signal in TF-A.
> > > > > > > > > > > > STR case, resume clr USB PWR READY signal in TF-A.
> > > > > > > > > > > As I said previously, it can be done in different ways. My point
> > > > > > > > > > > was to let Linux set what it needs for all it's devices to work.
> > > > > > > > > > > I think the way to go forward is a
> > > > > > > > > maintainer decision.
> > > > > > > > > > 
> > > > > > > > > > I agree, there can be n number of solution for a problem.
> > > > > > > > > > 
> > > > > > > > > > Since you modelled system state signal (USB PWRRDY) as reset
> > > > > > > > > > control signal, it is reset/DT maintainer's decision to say the
> > > > > > > > > > final word whether this signal fits in reset
> > > > > > > > > system framework or not?
> > > > > > > > > 
> > > > > > > > > I was thinking:
> > > > > > > > > 1/ Geert would be the best to say if he considers it OK to handle this
> > > > > > > > >    in Linux
> > > > > > > > 
> > > > > > > > I agree Geert is the right person for taking SYSTEM decisions,
> > > > > > > > since the signal is used only during state transitions (Table
> > > > > > > > 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> > > > > > > 
> > > > > > > One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
> > > > > > 
> > > > > > The "controlled by" column mentions CA-55 on PWRRDY signal control
> > > > > > line and it is b/w steps "DDR exits from retention mode" and  "clock
> > > > > > start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
> > > > Linux is ready to run.
> > > > > 
> > > > > DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
> > > > checks for warm or cold reset.
> > > > > If it is warm reset, it sets required minimal clocks/resets and pass
> > > > > the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
> > > > path.
> > > > 
> > > > Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
> > > > 
> > > > > 
> > > > > Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
> > > > > for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
> > > > > signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
> > > > > RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
> > > > 
> > > > Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
> > > > it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
> > > > using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
> > > > something wrong though. We don't know at the moment what this involves in terms of power consumption,
> > > > if it means something...
> > > 
> > > IIUC,
> > > The only information we have is,
> > > 
> > > "SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
> > > "When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break"
> > > 
> > > ALL_ON to AWO_MODE state transition: 
> > > USB/PCIe are part of PD_ISOVCC power domain and before turning PD_ISOVCC to off,
> > > we need to set USBPWRRDY signal.
> > > 
> > > AWO_MODE to ALL_ON state transition:
> > > 
> > > Turn on PD_ISOVCC first, then clr USBPWRRDY signal for USB usage in linux.
> > > 
> > > Maybe we need to ask hw team, exact usage of USBPWRRDY signal other than state transition.
> > 
> > As you may already know, this is open for quite some time and is ongoing.
> 
> I got more clarification about the USB PWRRDY signal from the HW team.
> 
> The conclusion is that the USB PWRRDY is a signal controlled by SYSC
> controller that goes to the USB PHY and it tells the USB PHY if the power
> supply is ready or not.
> 
> In the diagram at [1] the PWRRDY signal need to be asserted/de-asserted
> before/after G6, G7, G8, G9, G10 signals.
> 
> Philipp,
> 
> Can you please confirm that you don't want this signal to be implemented as
> a reset signal to know clearly your input on it? I would like to start
> looking for another approach in that case.

If this is not a reset signal I don't want it to be implemented as one.

regards
Philipp

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 02.09.2024 13:47, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>> Sent: Monday, September 2, 2024 11:41 AM
>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>>
>>
>> On 02.09.2024 12:18, Biju Das wrote:
>>>>>>> Do you have any plan to control this power transitions(ALL_ON to AWO and vice versa) in linux?
>>>>>> As you know, the RZ/G3S USB PM code is already prepared. This is
>>>>>> also configuring these signals when going to suspend/exiting from resume.
>>>>>> W/o configuring properly these signals the USB is not working after a suspend/resume cycle.
>>>>> One option is to handle SYSC USB PWRRDY signal in TF-A, if you plan
>>>>> to handle system transitions
>>>> there??
>>>>
>>>> As I mentioned, the settings in these registers may be changed by intermediary booting
>> applications.
>>>> Depending on that, Linux need to control it also on probe for USB to
>>>> work (it should be the same with PCIe, these signals seems similar from HW manual description).
>>> You mean system transition settings will be override by U-boot, so Linux needs to restore it back??
>>
>> It was talking about booting...
> 
> I am also referring to boot. Boot starts with TF-A and it has a system state.
> 
>>
>> You proposed to handle SYSC signals from TF-A in a discussion about system power transitions:
>>
>> "One option is to handle SYSC USB PWRRDY signal in TF-A,  if you plan to handle system transitions"
>>
>> (I was guessing the "system transition" statement there refers to power states transitions, ALL_ON <->
>> AWO/VBAT)
> 
> That is correct.
> 
>>
>> and I gave the booting process as a counter example: if we handle it in TF-A it may not be enough as
>> these signals might be changed by intermediary booting applications (e.g., U-Boot).
> 
> Why should U-boot override, system state signals such as USB PWRREADY? Can you please give an example.

I didn't say *should* but *might* and I was referring to a hypothetical
situation where any used application (bootloader) might trigger this signal
for whatever reason. My point was to let Linux to handle all the settings
that it can do for a particular functionality. The resisters in SYSC
address space controlling these signals are accessible to normal world
compared to others in the SYSC address spaces.

> 
>>
>> To conclude, there are 3 scenarios I see where these signals need to be
>> handled:
>> 1/ booting 
>> 2/ suspend to RAM
>> 3/ driver unbind/bind
> 
> --> It should be OK as linux is not handling USB PWRREADY signal.
> 
>>
>> In case of booting: if we have TF-A to set signals there might be intermediary booting applications
>> (e.g. U-Boot) that set these signals also. If it leaves it in improper state and Linux wants to use
>> USB then the USB will not work (if Linux doesn't handle it).
> 
> That is the problem of U-boot. U-boot should not override system state signals such as USB PWRREADY.

U-Boot can also use USB as well.

> 
>>
>> In case of suspend to RAM: as TF-A is the only application in the suspend to RAM chain, it should work
>> handling it in TF-A.
> 
> That is correct, TF-A should handle based on system state.
> 
>>
>> In case of unbind/bind: currently we don't know if these signals introduces any kind of power saving
>> so asserting/de-asserting them in Linux may be useful from this perspective, if any.
> 
> These are system signals, according to me should not be used in unbind/bind.

It can be done whatever way. I would just prefer to work for all scenarios.

Thank you,
Claudiu Beznea

> 
> I may be wrong.
> 
> Cheers,
> Biju

Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[claudiu beznea]

On 31.08.2024 08:13, Biju Das wrote:
> Hi Claudiu,
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@tuxon.dev>
>> Sent: Friday, August 30, 2024 9:23 AM
>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
>>
>> Hi, Ulf,
>>
>> On 29.08.2024 18:26, Ulf Hansson wrote:
>>> On Thu, 22 Aug 2024 at 17:28, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>>>
>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>
>>>> Hi,
>>>>
>>>> Series adds initial USB support for the Renesas RZ/G3S SoC.
>>>>
>>>> Series is split as follows:
>>>>
>>>> - patch 01/16           - add clock reset and power domain support for USB
>>>> - patch 02-04/16        - add reset control support for a USB signal
>>>>                           that need to be controlled before/after
>>>>                           the power to USB area is turned on/off.
>>>>
>>>>                           Philipp, Ulf, Geert, all,
>>>>
>>>>                           I detailed my approach for this in patch
>>>>                           04/16, please have a look and let me know
>>>>                           your input.
>>>
>>> I have looked briefly. Your suggested approach may work, but I have a
>>> few thoughts, see below.
>>>
>>> If I understand correctly, it is the consumer driver for the device
>>> that is attached to the USB power domain that becomes responsible for
>>> asserting/de-asserting this new signal. Right?
>>
>> Right!
>>
>>>
>>> In this regard, please note that the consumer driver doesn't really
>>> know when the power domain really gets powered-on/off. Calling
>>> pm_runtime_get|put*() is dealing with the reference counting. For
>>> example, a call to pm_runtime_get*() just makes sure that the PM
>>> domain gets-or-remains powered-on. Could this be a problem from the
>>> reset-signal point of view?
>>
>> It should be safe. From the HW manual I understand the hardware block is something like the following:
>>
>>
>>                   USB area
>>          +-------------------------+
>>          |                         |
>>          | PHY --->USB controller  |
>> SYSC --> |  ^                      |
>>          |  |                      |
>>          | PHY reset               |
>>          +-------------------------+
> 
> How USB PWRRDY signal is connected to USB? 

HW manual mentions this in the chapter describing the SYS_USB_PWRRDY register:

Controls PWRRDY terminal of USB

0: PWRRDY

1: PWRRDY down

When turning off the *USB region* power, set this bit to 1.

When turning on the *USB region* power, set this bit to 0

By USB region I get the that it is related to the SoC area where resides
all the USB IPs. I cannot tell more than what is in the hardware manual.


> 
> USB block consists of PHY control, PHY, USB HOST and USB OTG Controller IPs.
> 
> Is it connected to top level block or connected to each IP's for turning off the USB region power?

I cannot tell more than it is in the hardware manual.

> 
> ? Or Just PHY (HW manual mentions for AWO, the USB PWRRDY signal->USB PHY PWRRDY signal control)?
> 
> If the USBPWRRDY signal is connected across modules with this reset signal approach
> then you may need to update bindings [1] with that reset signal
> 
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20240822152801.602318-12-claudiu.beznea.uj@bp.renesas.com/

If that is true, then this signal may need to be routed to the PHY for
better hardware description.

>  
> 
> Cheers,
> Biju
> 
>>
>> Where:
>> - SYSC is the system controller that controls the new signal for which
>>   I'm requesting opinions in this series
>> - PHY reset: is the block controlling the PHYs
>> - PHY: is the block controlling the USB PHYs
>> - USB controller: is the USB controller
>>
>> Currently, I passed the SYSC signal handling to the PHY reset driver; w/o PHY reset the rest of the
>> USB logic cannot work (neither PHY block nor USB controller).
>>
>> Currently, the PHY reset driver call pm_runtime_resume_and_get() in probe and pm_runtime_put() in
>> remove. The struct reset_control_ops::{assert, deassert} only set specific bits in registers (no
>> pm_runtime* calls).
>>
>> The PHY driver is taking its PHY reset in probe and release it in remove().
>> With this approach the newly introduced SYSC signal will be de-asserted/asserted only in the PHY reset
>> probe/remove (either if it is handled though PM domain or reset control signal).
>>
>> If the SYSC signal would be passed to all the blocks in the USB area (and it would be handled though
>> PM domains) it should be no problem either, AFAICT, because of reference counting the
>> pm_runtime_get|put*() is taking care of. As the PHY reset is the root node the in the devices node
>> tree for USB the reference counting should work, too (I may miss something though, please correct me
>> if I'm wrong).
>>
>> If the SYSC signal would be handled though a reset control driver (as proposed in this series) and we
>> want to pass this reference to all the blocks in the USB area then we can request the reset signal as
>> shared and, AFAIK, this is also reference counted. The devices node tree should help with the order,
>> too, if I'm not wrong.
>>
>> Thank you for looking at this,
>> Claudiu Beznea
>>
>>>
>>> [...]
>>>
>>> Kind regards
>>> Uffe

Re: (subset) [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

[Vinod Koul]

On Thu, 22 Aug 2024 18:27:45 +0300, Claudiu wrote:
> Series adds initial USB support for the Renesas RZ/G3S SoC.
> 
> Series is split as follows:
> 
> - patch 01/16		- add clock reset and power domain support for USB
> - patch 02-04/16	- add reset control support for a USB signal
> 			  that need to be controlled before/after
> 			  the power to USB area is turned on/off.
> 
> [...]

Applied, thanks!

[10/16] phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
        commit: 4eae16375357a2a7e8501be5469532f7636064b3
[11/16] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings
        commit: f3c8498551146dfb014be0d85d3a7df98be16aa2
[12/16] phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC
        commit: 3c2ea12a625dbf5a864f4920235fa1c739d06e7d

Best regards,
-- 
~Vinod