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,

quoted

-----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:

quoted

Hi Claudiu,

quoted

-----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,

quoted

-----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:

quoted

On Thu, 22 Aug 2024 at 17:28, Claudiu [off-list ref] wrote:

quoted

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!

quoted

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:

quoted

                  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).

quoted

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).

quoted

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.

quoted

quoted

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