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. - 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. 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