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. Cheers, Biju
