From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Wesley Cheng <quic_wcheng@quicinc.com>,
mathias.nyman@intel.com, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH] usb: host: xhci: Avoid XHCI resume delay if SSUSB device is not present
Date: Fri, 28 Apr 2023 13:17:10 +0300 [thread overview]
Message-ID: <c22e7751-0367-a7e6-1fa5-c5afe5df7808@linux.intel.com> (raw)
In-Reply-To: <20230427190145.4623-1-quic_wcheng@quicinc.com>
On 27.4.2023 22.01, 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.
>
> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
> ---
> drivers/usb/host/xhci.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 78790dc13c5f..7a86cd683502 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -834,7 +834,8 @@ static bool xhci_pending_portevent(struct xhci_hcd *xhci)
> while (port_index--) {
> portsc = readl(ports[port_index]->addr);
> if (portsc & PORT_CHANGE_MASK ||
> - (portsc & PORT_PLS_MASK) == XDEV_RESUME)
> + (portsc & PORT_PLS_MASK) == XDEV_RESUME ||
> + !(portsc & PORT_CONNECT))
> return true;
This change will report a pending port event at the first empty roothub port.
I think we are looking for something like this instead (pseudo):
@@ -1116,7 +1116,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
* the first wake signalling failed, give it that chance.
*/
pending_portevent = xhci_pending_portevent(xhci);
- if (!pending_portevent) {
+ if (!pending_portevent && usb3_devices_connected && runtime_resume) {
msleep(120);
pending_portevent = xhci_pending_portevent(xhci);
}
Thanks
Mathias
prev parent reply other threads:[~2023-04-28 10:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 19:01 Wesley Cheng
2023-04-28 10:17 ` Mathias Nyman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c22e7751-0367-a7e6-1fa5-c5afe5df7808@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=quic_wcheng@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®