+Vibhore & Vishal On 05/08/2024 11:58, Théo Lebrun wrote: > Hello Roger, > > On Sat Aug 3, 2024 at 5:14 PM CEST, Roger Quadros wrote: >> On 26/07/2024 21:17, Théo Lebrun wrote: >>> Currently, system-wide suspend is broken on J7200 because of a >>> controller reset. The TI wrapper does not get re-initialised at resume >>> and the first register access from cdns core fails. >>> >>> We address that in a few ways: >>> - In cdns3-ti, if a reset has occured at resume, we reconfigure the HW. >>> - We pass the XHCI_RESET_ON_RESUME quirk, meaning the XHCI core expects >>> a resume. >> >> OK. >>> - We add a xhci->lost_power flag. >> >> Why? >> >>> >>> The previous revision had one big issue: we had to know if >>> reset-on-resume was true, at probe-time. This is where the main >> >> Don't we already know this at probe-time? why not just rely on the existing >> XHCI_RESET_ON_RESUME qurik, than add a new mechanism? > > Some TI platforms cannot tell, before going to suspend, if their USB > controller will reset. Suspend behavior is defined by (at least) two > features: > > - Power domains. See arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: > > usbss0: cdns-usb@4104000 { > compatible = "ti,j7200-usb", "ti,j721e-usb"; > // ... > power-domains = <&k3_pds 288 TI_SCI_PD_EXCLUSIVE>; > // ... > }; > > This `power-domains` property implies that even s2idle will reset > the controller. I'm not so sure. All K3 platforms have the power-domains property for the USB wrapper nodes. > > - Deep suspend. The type of suspend defines what will happen to various > controllers. Currently deep suspend is suspend-to-RAM, with the SoC > being turned off. > > This might evolve over time with more complex rules: the chosen > suspend behavior could depend on wakeup source and/or wakeup target > latencies. That information might not be available to Linux, being > decided upon by firmwares. We need to be able to resume successfully > without being surprised by a reset. > Got it. Might be worth to mention this in the patch description. > I am sorry the precise usecase wasn't clear from the get-go. > > Thanks, > > -- > Théo Lebrun, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > -- cheers, -roger