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:

quoted

Hi Claudiu,

quoted

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

quoted

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

quoted

quoted

quoted

quoted

quoted

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

linux?

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

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

quoted

quoted

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

back??

quoted

It was talking about booting...

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

quoted

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"

quoted

quoted

quoted

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

That is correct.

quoted

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.

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

quoted

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.

quoted

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