Hi,
I currently work on suspend to idle support for Raspberry Pi (BCM2835)
[1]. Unfortunately properly powering down USB (dwc2) is currently not
supported for this platform. As soon as the USB power domain is powered
down and up (triggered by suspend to idle), the USB interface is
functionally dead (no devices available, no enumeration) and resume take
a lot of time:
Apr 24 16:14:08 raspberrypi kernel: [ 271.494472] PM: suspend entry
(s2idle)
Apr 24 16:14:09 raspberrypi kernel: [ 272.009042] Filesystems sync:
0.514 seconds
Apr 24 16:15:23 raspberrypi kernel: [ 272.054081] Freezing user space
processes
Apr 24 16:15:23 raspberrypi kernel: [ 272.058478] Freezing user space
processes completed (elapsed 0.004 seconds)
Apr 24 16:15:23 raspberrypi kernel: [ 272.058574] OOM killer disabled.
Apr 24 16:15:23 raspberrypi kernel: [ 272.058594] Freezing remaining
freezable tasks
Apr 24 16:15:23 raspberrypi kernel: [ 272.060095] Freezing remaining
freezable tasks completed (elapsed 0.001 seconds)
Apr 24 16:15:23 raspberrypi kernel: [ 272.068302] smsc95xx 1-1.1:1.0
eth0: entering SUSPEND2 mode
Apr 24 16:15:23 raspberrypi kernel: [ 272.123910] dwc2 20980000.usb:
dwc2_suspend
Apr 24 16:15:23 raspberrypi kernel: [ 272.123973] dwc2 20980000.usb:
__dwc2_lowlevel_hw_disable()
Apr 24 16:15:23 raspberrypi kernel: [ 272.126143] PM: suspend of
devices complete after 65.371 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 272.126221] PM: start suspend of
devices complete after 66.043 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 272.127886] PM: late suspend of
devices complete after 1.625 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 272.129312] USB domain off
Apr 24 16:15:23 raspberrypi kernel: [ 272.130636] PM: noirq suspend of
devices complete after 2.547 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 272.130714] PM: suspend debug:
Waiting for 5 second(s).
Apr 24 16:15:23 raspberrypi kernel: [ 277.141198] USB domain on
Apr 24 16:15:23 raspberrypi kernel: [ 277.669113] PM: noirq resume of
devices complete after 533.149 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 277.670324] PM: early resume of
devices complete after 0.994 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 277.672005] dwc2 20980000.usb:
dwc2_resume
Apr 24 16:15:23 raspberrypi kernel: [ 277.672061] dwc2 20980000.usb:
__dwc2_lowlevel_hw_enable()
Apr 24 16:15:23 raspberrypi kernel: [ 282.943909] usb 1-1: reset
high-speed USB device number 2 using dwc2
Apr 24 16:15:23 raspberrypi kernel: [ 288.223658] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:15:23 raspberrypi kernel: [ 303.663648] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:15:23 raspberrypi kernel: [ 304.003656] usb 1-1: reset
high-speed USB device number 2 using dwc2
Apr 24 16:15:23 raspberrypi kernel: [ 309.263662] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:15:23 raspberrypi kernel: [ 324.703663] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:15:23 raspberrypi kernel: [ 325.043664] usb 1-1: reset
high-speed USB device number 2 using dwc2
Apr 24 16:15:23 raspberrypi kernel: [ 335.583640] usb 1-1: device not
accepting address 2, error -110
Apr 24 16:15:23 raspberrypi kernel: [ 335.803642] usb 1-1: reset
high-speed USB device number 2 using dwc2
Apr 24 16:15:23 raspberrypi kernel: [ 346.383608] usb 1-1: device not
accepting address 2, error -110
Apr 24 16:15:23 raspberrypi kernel: [ 346.463987] PM: resume of devices
complete after 68793.584 msecs
Apr 24 16:15:23 raspberrypi kernel: [ 346.464352] smsc95xx 1-1.1:1.0
eth0: Link is Down
Apr 24 16:15:23 raspberrypi kernel: [ 346.465369] OOM killer enabled.
Apr 24 16:15:23 raspberrypi kernel: [ 346.465417] Restarting tasks ...
done.
Apr 24 16:15:23 raspberrypi kernel: [ 346.500347] random: crng reseeded
on system resumption
Apr 24 16:15:23 raspberrypi kernel: [ 346.500928] usb 1-1: USB
disconnect, device number 2
Apr 24 16:15:23 raspberrypi kernel: [ 346.500993] usb 1-1.1: USB
disconnect, device number 3
Apr 24 16:15:23 raspberrypi kernel: [ 346.501599] smsc95xx 1-1.1:1.0
eth0: unregister 'smsc95xx' usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet
Apr 24 16:15:23 raspberrypi kernel: [ 346.501808] smsc95xx 1-1.1:1.0
eth0: hardware isn't capable of remote wakeup
Apr 24 16:15:23 raspberrypi kernel: [ 346.508950] usb 1-1.2: USB
disconnect, device number 4
Apr 24 16:15:24 raspberrypi kernel: [ 346.535846] PM: suspend exit
Apr 24 16:15:24 raspberrypi kernel: [ 346.783703] usb 1-1: new
high-speed USB device number 5 using dwc2
Apr 24 16:15:29 raspberrypi kernel: [ 352.063614] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:15:44 raspberrypi kernel: [ 367.503622] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:15:45 raspberrypi kernel: [ 367.843649] usb 1-1: new
high-speed USB device number 6 using dwc2
Apr 24 16:15:50 raspberrypi kernel: [ 373.103627] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:16:06 raspberrypi kernel: [ 388.543616] usb 1-1: device
descriptor read/64, error -110
Apr 24 16:16:06 raspberrypi kernel: [ 388.663808] usb usb1-port1:
attempt power cycle
So I investigated a little bit about the current DWC2 implementation of
BCM2835:
- no real PHY driver, just NOP PHY
- fixed USB clock
- params.power_down = DWC2_POWER_DOWN_PARAM_NONE
- no clock gating [2]
As a result from DWC2 point of view there is no power down possible by
this driver and it doesn't support pm_runtime. But commit 5ec6f2cd8e
("ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.")
added a power domain to the DWC2 DT node on BCM2835.
domain status
children performance
/device runtime status
----------------------------------------------------------------------------------------------
...
USB on 0
/devices/platform/soc/20980000.usb unsupported 0
This allows the system to power down the USB domain without
involving/notifying DWC2.
At least Rockchip PX30 did something similiar with commit bb5981333f
("arm64: dts: rockchip: add dwc2 otg controller on px30"). Not sure if
the power domain is actually powered down on that platform.
So my questions are:
How should we deal with it?
Should the DWC2 driver take control of this power domain?
How should we achieve this in the right way (tm)?
Best regards
[1] -
https://lore.kernel.org/linux-arm-kernel/20240630153652.318882-1-wahrenst@xxxxxxx/
[2] -
https://lore.kernel.org/linux-arm-kernel/20240630153652.318882-10-wahrenst@xxxxxxx/
