On 02.09.2024 13:47, Biju Das wrote:

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?

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

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.

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"

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

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.

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.

U-Boot can also use USB as well.

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.

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