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
