There is an extra amount of overhead being adding to XHCI HCD removal
cases when the HCD needs to undergo a runtime resume. The xhc_reinit
logic will attempt to restart the HC if there is a HCE observed during
resume. However, in the removal case, this is not required as the
XHCI stop/halt will execute the same operations. In addition, it isn't
needed that the HC be placed back into the running state if it is being
removed.
Changes in v3:
- Update xhci-plat to set the removal flag before issuing the runtime PM
get
Changes in v2:
- Fixed spacing issue
Wesley Cheng (2):
usb: host: xhci: Do not re-initialize the XHCI HC if being removed
usb: host: xhci-plat: Set XHCI_STATE_REMOVING before resuming XHCI HC
drivers/usb/host/xhci-plat.c | 2 +-
drivers/usb/host/xhci.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
There are situations during the xhci_resume() sequence, which allows for
re-initializing of the XHCI HC. However, in case the HCD is being removed,
these operations may not be needed. Set the removal state before issuing
the runtime PM get on the XHCI device, so that the XHCI resume routine will
know when to bypass the re-init logic.
Signed-off-by: Wesley Cheng <[email protected]>
---
drivers/usb/host/xhci-plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index a666b21c21bb..a1e552d9da09 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -403,8 +403,8 @@ int xhci_plat_remove(struct platform_device *dev)
struct clk *reg_clk = xhci->reg_clk;
struct usb_hcd *shared_hcd = xhci->shared_hcd;
- pm_runtime_get_sync(&dev->dev);
xhci->xhc_state |= XHCI_STATE_REMOVING;
+ pm_runtime_get_sync(&dev->dev);
if (shared_hcd) {
usb_remove_hcd(shared_hcd);
During XHCI resume, if there was a host controller error detected the
routine will attempt to re-initialize the XHCI HC, so that it can return
back to an operational state. If the XHCI host controller is being
removed, this sequence would be already handled within the XHCI halt path,
leading to a duplicate set of reg ops/calls. In addition, since the XHCI
bus is being removed, the overhead added in restarting the HCD is
unnecessary. Check for the XHC state before setting the reinit_xhc
parameter, which is responsible for triggering the restart.
Signed-off-by: Wesley Cheng <[email protected]>
---
drivers/usb/host/xhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b81313ffeb76..02a30b883bde 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1028,7 +1028,8 @@ int xhci_resume(struct xhci_hcd *xhci, pm_message_t msg)
temp = readl(&xhci->op_regs->status);
/* re-initialize the HC on Restore Error, or Host Controller Error */
- if (temp & (STS_SRE | STS_HCE)) {
+ if ((temp & (STS_SRE | STS_HCE)) &&
+ !(xhci->xhc_state & XHCI_STATE_REMOVING)) {
reinit_xhc = true;
if (!xhci->broken_suspend)
xhci_warn(xhci, "xHC error in resume, USBSTS 0x%x, Reinit\n", temp);
Friendly ping to see if there are any review feedback/concerns with this
series?
Thanks
Wesley Cheng
On 5/31/2023 3:27 PM, Wesley Cheng wrote:
> There is an extra amount of overhead being adding to XHCI HCD removal
> cases when the HCD needs to undergo a runtime resume. The xhc_reinit
> logic will attempt to restart the HC if there is a HCE observed during
> resume. However, in the removal case, this is not required as the
> XHCI stop/halt will execute the same operations. In addition, it isn't
> needed that the HC be placed back into the running state if it is being
> removed.
>
> Changes in v3:
> - Update xhci-plat to set the removal flag before issuing the runtime PM
> get
>
> Changes in v2:
> - Fixed spacing issue
>
> Wesley Cheng (2):
> usb: host: xhci: Do not re-initialize the XHCI HC if being removed
> usb: host: xhci-plat: Set XHCI_STATE_REMOVING before resuming XHCI HC
>
> drivers/usb/host/xhci-plat.c | 2 +-
> drivers/usb/host/xhci.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
On 21.6.2023 22.46, Wesley Cheng wrote:
> Friendly ping to see if there are any review feedback/concerns with this series?
>
Looks good to me.
Seems that Greg already applied these
-Mathias