Hi, all, On 03.09.2024 17:48, claudiu beznea wrote: > > > On 03.09.2024 16:45, Biju Das wrote: >> Hi Claudiu, >> >>> -----Original Message----- >>> From: claudiu beznea <claudiu.beznea@xxxxxxxxx> >>> 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: >>>> >>>> >>>>> -----Original Message----- >>>>> From: claudiu beznea <claudiu.beznea@xxxxxxxxx> >>>>> Sent: Tuesday, September 3, 2024 1:26 PM >>>>> To: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>; Ulf Hansson >>>>> <ulf.hansson@xxxxxxxxxx> >>>>> Cc: vkoul@xxxxxxxxxx; kishon@xxxxxxxxxx; robh@xxxxxxxxxx; >>>>> krzk+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; >>>>> geert+renesas@xxxxxxxxx; magnus.damm@xxxxxxxxx; >>>>> gregkh@xxxxxxxxxxxxxxxxxxx; mturquette@xxxxxxxxxxxx; >>>>> sboyd@xxxxxxxxxx; Yoshihiro Shimoda >>>>> <yoshihiro.shimoda.uh@xxxxxxxxxxx>; >>>>> linux-phy@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; >>>>> linux-kernel@xxxxxxxxxxxxxxx; linux- renesas-soc@xxxxxxxxxxxxxxx; >>>>> linux-usb@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; >>>>> linux- clk@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; Claudiu Beznea >>>>> <claudiu.beznea.uj@xxxxxxxxxxxxxx> >>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas >>>>> RZ/G3S SoC >>>>> >>>>> >>>>> >>>>> On 03.09.2024 15:00, Biju Das wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> >>>>>>> Sent: Tuesday, September 3, 2024 12:07 PM >>>>>>> To: Claudiu.Beznea <claudiu.beznea@xxxxxxxxx>; Ulf Hansson >>>>>>> <ulf.hansson@xxxxxxxxxx> >>>>>>> Cc: vkoul@xxxxxxxxxx; kishon@xxxxxxxxxx; robh@xxxxxxxxxx; >>>>>>> krzk+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; >>>>>>> geert+renesas@xxxxxxxxx; magnus.damm@xxxxxxxxx; >>>>>>> gregkh@xxxxxxxxxxxxxxxxxxx; mturquette@xxxxxxxxxxxx; >>>>>>> sboyd@xxxxxxxxxx; Yoshihiro Shimoda >>>>>>> <yoshihiro.shimoda.uh@xxxxxxxxxxx>; >>>>>>> linux-phy@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; >>>>>>> linux-kernel@xxxxxxxxxxxxxxx; linux- renesas-soc@xxxxxxxxxxxxxxx; >>>>>>> linux-usb@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; >>>>>>> linux- clk@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; Claudiu >>>>>>> Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> >>>>>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas >>>>>>> RZ/G3S SoC >>>>>>> >>>>>>> Hi Claudiu, >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: claudiu beznea <claudiu.beznea@xxxxxxxxx> >>>>>>>> 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: >>>>>>>>>>> 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? >>>>>>>> >>>>>>>> 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. >>>> >>>> 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. >>>> 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" >>> >>>> >>>> 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. > > As you may already know, this is open for quite some time and is ongoing. I got more clarification about the USB PWRRDY signal from the HW team. The conclusion is that the USB PWRRDY is a signal controlled by SYSC controller that goes to the USB PHY and it tells the USB PHY if the power supply is ready or not. In the diagram at [1] the PWRRDY signal need to be asserted/de-asserted before/after G6, G7, G8, G9, G10 signals. Philipp, Can you please confirm that you don't want this signal to be implemented as a reset signal to know clearly your input on it? I would like to start looking for another approach in that case. Thank you, Claudiu Beznea [1] https://pasteboard.co/0a1zYBFZXZVb.png > >> >> Cheers, >> Biju >> >>
