Message-ID: <fbfa9179-2f52-429f-8b69-f7f4064e796b@tuxon.dev>
Date: Tue, 3 Sep 2024 13:25:21 +0300
From: claudiu beznea <claudiu.beznea@...on.dev>
To: Biju Das <biju.das.jz@...renesas.com>,
 Ulf Hansson <ulf.hansson@...aro.org>
Cc: "vkoul@...nel.org" <vkoul@...nel.org>,
 "kishon@...nel.org" <kishon@...nel.org>, "robh@...nel.org"
 <robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,
 "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
 "geert+renesas@...der.be" <geert+renesas@...der.be>,
 "magnus.damm@...il.com" <magnus.damm@...il.com>,
 "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
 "mturquette@...libre.com" <mturquette@...libre.com>,
 "sboyd@...nel.org" <sboyd@...nel.org>,
 Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
 "linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
 "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
 "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
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@...on.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

Powered by blists - more mailing lists