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
