06:48 <wadim_> I tested a few more combinations when having USB1 & M4 enabled/disabled. Also with suspending into s2idle.

06:48 <wadim_> USB1 and M4 having direct influence on how the system behaves when it wants to go into suspend.

06:48 <wadim_> I can also see that the wakeup reason reported by TISCI is always USB1 even if the WKUP_RTC is hitting.

06:48 <wadim_> By suspending into idle, DWC3 attempts to disable a clock which is already disabled and I end up with a Kernel warning.

06:48 <wadim_> https://pastebin.ubuntu.com/p/p2wQHhHrC9

07:50 <dhruvag2000> Yeah s2idle is not really expected to work, atleast from what little I understand about that flow is it ends up in k3_validate_power_state which is a "TODO" at this point, so I think it doesn't proceed further into deep sleep sequence. I am not too sure about why the dwc3 issue comes up in s2idle and not in deepsleep because that just seems totally kernel side sequence to me.

07:57 <dhruvag2000> Does the wakeup source come up as usb1 even if you disabled it and did a rtcwake?

08:09 <wadim_> Disabling USB1 breaks the suspend/resume process. It hangs and I have to restart my system. It will never wakeup.

08:35 <dhruvag2000> Trying to gather few more data points, when you do rtcwake does the device resume instantly or does it actually wait for 5 seconds before resume sequence?

08:36 <dhruvag2000> If 5 is too fast to catch, try with 10 seconds perhaps and ensure that device stays suspended for around 10 seconds

08:36 <dhruvag2000> What I am suspecting is that USB is still triggering a wakeup before the rtc and hence you're seeing it as the wakeup source

08:38 <dhruvag2000> Also, does the USB1 have any peripheral connected?

09:01 <wadim_> With rtcwake and if M4 is running, the wakeup happens after the wakealarm timeout of the rtc. Without M4, the rtcwake happens instantly.

09:03 <wadim_> I tested also longer timeouts of 10 seconds and it behaves identically.

09:04 <wadim_> Our board has a USB Hub connected to USB1. But I do not see any interrupts from USB, only if I enter the suspend state it generates a lot of interrupts.

09:13 <dhruvag2000> @wadim_ /////can you please disconnect the usb hub and try once?

09:14 <dhruvag2000> We have seen issues in the past as well where some USB hubs if connected , they cause issue with suspend resume. I don't have the exact root cause yet on this, maybe try e2e.ti.com for a deep dive with why USB hub may fail. There maybe hardware related stuff that I may not be aware of

09:16 <wadim_> It is a Microchip USB2514 hub. I can not just disconnect it on my hardware. I will try to find a way to test it without the hub, thanks!

09:16 <dhruvag2000> Another data point, when you disable usb and you say it locks up the system, I want to ensure that in your entire boot process no body is touching usb1 including u-boot. Best way to check is using `k3conf dump device 162` (ref. https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/devices.html ) and see before suspending if it's actually disabled/ OFF state. If not then it maybe in some unclean state

09:18 <dhruvag2000> > I will try to find a way to test it without the hub

09:18 <dhruvag2000> Quick hack maybe to just hack the drivers/usb/dwc3/dwc3-am62.c driver to disable device wakeup stuff, but I am no USB expert so I can't comment more on what exactly needs to be done to achieve wakeup disable.

09:21 <wadim_> Uh, interesting the k3conf device dump returns DEVICE_STATE_ON even after disabling USB1 via device tree

09:25 <dhruvag2000> try https://gist.github.com/DhruvaG2000/0d0bcd9fcf3ef9530ae730b002642cde maybe?

09:25 <wadim_> Got it disabled, and rtcwake works and TISCI reports 0x50 as the wakeup source

09:26 <dhruvag2000> Great!

09:27 <wadim_> I will check with hardware guys if the USB hub is the actual issue

09:27 <wadim_> Thank you for the help so far :)

09:27 <dhruvag2000> For the MCU, there maybe an update needed on the suspend sequence, please refer https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c

09:28 <dhruvag2000> There is a new LPM ARCH that is being shipped with 10.00 hence you maybe missing some steps in the firmware.

09:28 <dhruvag2000> The linux side docs are updated now: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components/Power_Management/pm_sw_arch.html