On 1.9.2023 3.15, Wesley Cheng wrote:
There is a 120ms delay implemented for allowing the XHCI host controller to
detect a U3 wakeup pulse. The intention is to wait for the device to retry
the wakeup event if the USB3 PORTSC doesn't reflect the RESUME link status
by the time it is checked. As per the USB3 specification:
tU3WakeupRetryDelay ("Table 7-12. LTSSM State Transition Timeouts")
This would allow the XHCI resume sequence to determine if the root hub
needs to be also resumed. However, in case there is no device connected,
or if there is only a HSUSB device connected, this delay would still affect
the overall resume timing.
Since this delay is solely for detecting U3 wake events (USB3 specific)
then ignore this delay for the disconnected case and the HSUSB connected
only case.
Thanks, makes sense
Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
---
drivers/usb/host/xhci.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e1b1b64a0723..640db6a4e686 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -805,6 +805,24 @@ static void xhci_disable_hub_port_wake(struct xhci_hcd *xhci,
spin_unlock_irqrestore(&xhci->lock, flags);
}
+static bool xhci_usb3_dev_connected(struct xhci_hcd *xhci)
+{
+ struct xhci_port **ports;
+ int port_index;
+ u32 portsc;
+
+ port_index = xhci->usb3_rhub.num_ports;
+ ports = xhci->usb3_rhub.ports;
+
+ while (port_index--) {
+ portsc = readl(ports[port_index]->addr);
+ if (portsc & (portsc & PORT_CONNECT))
+ return true;
+ }
+
+ return false;
+}
+
This is one way, but we can probably avoid re-reading all the usb3 portsc registers
by checking if any bit is set in either:
// bitfield, set if xhci usb3 port neatly set to U3 with a hub request
xhci->usb3_rhub.bus_state.suspended_ports
// bitfield, set if xhci usb3 port is forced to U3 during xhci suspend.
xhci->usb3_rhub.bus_state.bus_suspended
But haven't checked this works in all corner cases.
Thanks
Mathias
