Thread (98 messages) 98 messages, 7 authors, 2024-11-07

RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

From: Biju Das <biju.das.jz@bp.renesas.com>
Date: 2024-09-03 13:45:06
Also in: linux-clk, linux-devicetree, linux-phy, linux-pm, linux-renesas-soc, linux-usb, lkml

Hi Claudiu,
-----Original Message-----
From: claudiu beznea <claudiu.beznea@tuxon.dev>
Sent: Tuesday, September 3, 2024 1:57 PM
Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC



On 03.09.2024 15:37, Biju Das wrote:
quoted
quoted
-----Original Message-----
From: claudiu beznea <claudiu.beznea@tuxon.dev>
Sent: Tuesday, September 3, 2024 1:26 PM
To: Biju Das <biju.das.jz@bp.renesas.com>; Ulf Hansson
[off-list ref]
Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
geert+renesas@glider.be; magnus.damm@gmail.com;
gregkh@linuxfoundation.org; mturquette@baylibre.com;
sboyd@kernel.org; Yoshihiro Shimoda
[off-list ref];
linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu Beznea
[off-list ref]
Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
RZ/G3S SoC



On 03.09.2024 15:00, Biju Das wrote:
quoted
quoted
-----Original Message-----
From: Biju Das <biju.das.jz@bp.renesas.com>
Sent: Tuesday, September 3, 2024 12:07 PM
To: Claudiu.Beznea <claudiu.beznea@tuxon.dev>; Ulf Hansson
[off-list ref]
Cc: vkoul@kernel.org; kishon@kernel.org; robh@kernel.org;
krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de;
geert+renesas@glider.be; magnus.damm@gmail.com;
gregkh@linuxfoundation.org; mturquette@baylibre.com;
sboyd@kernel.org; Yoshihiro Shimoda
[off-list ref];
linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
linux-kernel@vger.kernel.org; linux- renesas-soc@vger.kernel.org;
linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux- clk@vger.kernel.org; linux-pm@vger.kernel.org; Claudiu
Beznea [off-list ref]
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: Tuesday, September 3, 2024 12:00 PM
Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
RZ/G3S SoC



On 03.09.2024 13:31, Biju Das wrote:
quoted
quoted
quoted
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.
quoted
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?

I was thinking:
1/ Geert would be the best to say if he considers it OK to handle this
   in Linux
I agree Geert is the right person for taking SYSTEM decisions,
since the signal is used only during state transitions (Table
41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
The "controlled by" column mentions CA-55 on PWRRDY signal control
line and it is b/w steps "DDR exits from retention mode" and  "clock
start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
Linux is ready to run.
quoted
DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
checks for warm or cold reset.
quoted
If it is warm reset, it sets required minimal clocks/resets and pass
the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
path.

Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
quoted
Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
something wrong though. We don't know at the moment what this involves in terms of power consumption,
if it means something...
IIUC,
The only information we have is,

"SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
"When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break"

ALL_ON to AWO_MODE state transition: 
USB/PCIe are part of PD_ISOVCC power domain and before turning PD_ISOVCC to off,
we need to set USBPWRRDY signal.

AWO_MODE to ALL_ON state transition:

Turn on PD_ISOVCC first, then clr USBPWRRDY signal for USB usage in linux.

Maybe we need to ask hw team, exact usage of USBPWRRDY signal other than state transition.

Cheers,
Biju

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help