| Message ID | 1624361096-41282-1-git-send-email-dh10.jung@samsung.com |
|---|---|
| State | New |
| Headers | show |
| Series | usb: host: Reduce xhci_handshake timeout in xhci_reset | expand |
On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote: > It seems 10 secs timeout is too long in general case. A core would wait for > 10 secs without doing other task and it can be happended on every device. Only if the handshake does not come back sooner, right? What is causing your device to timeout here? > It's better to reduce timeout for general case and use new quirk if needed. What new quirk? And why 1 second, where did that number come from? > > Signed-off-by: Daehwan Jung <dh10.jung@samsung.com> > --- > drivers/usb/host/xhci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index 9248ce8..0a1b6be 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -196,7 +196,7 @@ int xhci_reset(struct xhci_hcd *xhci) > udelay(1000); > > ret = xhci_handshake(&xhci->op_regs->command, > - CMD_RESET, 0, 10 * 1000 * 1000); > + CMD_RESET, 0, 1 * 1000 * 1000); > if (ret) > return ret; > > @@ -210,7 +210,7 @@ int xhci_reset(struct xhci_hcd *xhci) > * than status until the "Controller Not Ready" flag is cleared. > */ > ret = xhci_handshake(&xhci->op_regs->status, > - STS_CNR, 0, 10 * 1000 * 1000); > + STS_CNR, 0, 1 * 1000 * 1000); With this change, what "goes faster"? What is currently causing problems with your host controller that this timeout value actually matters? Why is it failing? thanks, greg k-h
On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote: > On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote: > > It seems 10 secs timeout is too long in general case. A core would wait for > > 10 secs without doing other task and it can be happended on every device. > > Only if the handshake does not come back sooner, right? Yes, right. > What is causing your device to timeout here? Host Controller doesn't respond handshake. I don't know why and I ask HW team to debug it. > > It's better to reduce timeout for general case and use new quirk if needed. > > What new quirk? I mean someone can add new quirk if one still needs long timeout. I guess 1 sec seems enough but there're many kinds of devices. > And why 1 second, where did that number come from? It was 250 msecs before changed to 10 secs. There's no required minimum time in xhci specification. 1 second is estimated number and it works well on my device. > > > > Signed-off-by: Daehwan Jung <dh10.jung@samsung.com> > > --- > > drivers/usb/host/xhci.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > index 9248ce8..0a1b6be 100644 > > --- a/drivers/usb/host/xhci.c > > +++ b/drivers/usb/host/xhci.c > > @@ -196,7 +196,7 @@ int xhci_reset(struct xhci_hcd *xhci) > > udelay(1000); > > > > ret = xhci_handshake(&xhci->op_regs->command, > > - CMD_RESET, 0, 10 * 1000 * 1000); > > + CMD_RESET, 0, 1 * 1000 * 1000); > > if (ret) > > return ret; > > > > @@ -210,7 +210,7 @@ int xhci_reset(struct xhci_hcd *xhci) > > * than status until the "Controller Not Ready" flag is cleared. > > */ > > ret = xhci_handshake(&xhci->op_regs->status, > > - STS_CNR, 0, 10 * 1000 * 1000); > > + STS_CNR, 0, 1 * 1000 * 1000); > > With this change, what "goes faster"? What is currently causing > problems with your host controller that this timeout value actually > matters? Why is it failing? I guess the root cause of it is from host controller, which it is HW. Our HW engineer has been debugging it, but I haven't get any clue till now. However, I think 10 secs timeout is too long and it can cause system problem. That's why I want to change timeout value. A CPU core would not do anything but waiting xhci reset for 10 secs with disabling irq like below. usb_remove_hcd -> xhci_stop -> xhci_reset -> xhci_handshake static void xhci_stop(struct usb_hcd *hcd) { u32 temp; struct xhci_hcd *xhci = hcd_to_xhci(hcd); mutex_lock(&xhci->mutex); /* Only halt host and free memory after both hcds are removed */ if (!usb_hcd_is_primary_hcd(hcd)) { mutex_unlock(&xhci->mutex); return; } xhci_dbc_exit(xhci); spin_lock_irq(&xhci->lock); -> disable IRQ xhci->xhc_state |= XHCI_STATE_HALTED; xhci->cmd_ring_state = CMD_RING_STATE_STOPPED; xhci_halt(xhci); xhci_reset(xhci); -> 10 seconds timeout! spin_unlock_irq(&xhci->lock); Best Regards, Jung Daehwan > thanks, > > greg k-h >
On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote: > On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote: > > On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote: > > > It seems 10 secs timeout is too long in general case. A core would wait for > > > 10 secs without doing other task and it can be happended on every device. > > > > Only if the handshake does not come back sooner, right? > > Yes, right. > > > What is causing your device to timeout here? > > Host Controller doesn't respond handshake. I don't know why and I ask HW team > to debug it. Please work to fix your hardware, that feels like the root of the problem here. If you require the timeout for xhci_reset() to happen, then how do you know that the hardware really did reset properly in the reduced amount of time you just provided? thanks, greg k-h
On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote: > On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote: > > On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote: > > > On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote: > > > > It seems 10 secs timeout is too long in general case. A core would wait for > > > > 10 secs without doing other task and it can be happended on every device. > > > > > > Only if the handshake does not come back sooner, right? > > > > Yes, right. > > > > > What is causing your device to timeout here? > > > > Host Controller doesn't respond handshake. I don't know why and I ask HW team > > to debug it. > > Please work to fix your hardware, that feels like the root of the > problem here. If you require the timeout for xhci_reset() to happen, > then how do you know that the hardware really did reset properly in the > reduced amount of time you just provided? > I continue fixing this issue with hardware engineer, but currently just host controller can crash whole system and that's why I want to fix it. How about adding some error logs in this situation for recognizing this issue? We can add error log in xhci_stop as xhci_reset can returns error like below. static void xhci_stop(struct usb_hcd *hcd) { u32 temp; struct xhci_hcd *xhci = hcd_to_xhci(hcd); + int ret; mutex_lock(&xhci->mutex); @@ -733,6 +734,9 @@ static void xhci_stop(struct usb_hcd *hcd) xhci->cmd_ring_state = CMD_RING_STATE_STOPPED; xhci_halt(xhci); xhci_reset(xhci); + if (ret) + xhci_err(xhci, "%s: Error while reset xhci Host controller - ret = %d\n" + , __func__, ret); spin_unlock_irq(&xhci->lock); > thanks, > > greg k-h >
On 28.6.2021 9.55, Jung Daehwan wrote: > On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote: >> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote: >>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote: >>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote: >>>>> It seems 10 secs timeout is too long in general case. A core would wait for >>>>> 10 secs without doing other task and it can be happended on every device. >>>> >>>> Only if the handshake does not come back sooner, right? >>> >>> Yes, right. >>> >>>> What is causing your device to timeout here? >>> >>> Host Controller doesn't respond handshake. I don't know why and I ask HW team >>> to debug it. >> >> Please work to fix your hardware, that feels like the root of the >> problem here. If you require the timeout for xhci_reset() to happen, >> then how do you know that the hardware really did reset properly in the >> reduced amount of time you just provided? >> > > I continue fixing this issue with hardware engineer, but currently just > host controller can crash whole system and that's why I want to fix it. > How about adding some error logs in this situation for recognizing this issue? > We can add error log in xhci_stop as xhci_reset can returns error like below. > > static void xhci_stop(struct usb_hcd *hcd) > { > u32 temp; > struct xhci_hcd *xhci = hcd_to_xhci(hcd); > + int ret; > > mutex_lock(&xhci->mutex); > > @@ -733,6 +734,9 @@ static void xhci_stop(struct usb_hcd *hcd) > xhci->cmd_ring_state = CMD_RING_STATE_STOPPED; > xhci_halt(xhci); > xhci_reset(xhci); > + if (ret) > + xhci_err(xhci, "%s: Error while reset xhci Host controller - ret = %d\n" > + , __func__, ret); > spin_unlock_irq(&xhci->lock); > We can check the xhci_reset() return value here and print a message, makes sense. The original reason for the 10 second timeout was because a host actually took 9 seconds: commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b xhci: Increase reset timeout for Renesas 720201 host. The NEC/Renesas 720201 xHCI host controller does not complete its reset within 250 milliseconds. In fact, it takes about 9 seconds to reset the host controller, and 1 second for the host to be ready for doorbell rings. Extend the reset and CNR polling timeout to 10 seconds each. -Mathias
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 9248ce8..0a1b6be 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -196,7 +196,7 @@ int xhci_reset(struct xhci_hcd *xhci) udelay(1000); ret = xhci_handshake(&xhci->op_regs->command, - CMD_RESET, 0, 10 * 1000 * 1000); + CMD_RESET, 0, 1 * 1000 * 1000); if (ret) return ret; @@ -210,7 +210,7 @@ int xhci_reset(struct xhci_hcd *xhci) * than status until the "Controller Not Ready" flag is cleared. */ ret = xhci_handshake(&xhci->op_regs->status, - STS_CNR, 0, 10 * 1000 * 1000); + STS_CNR, 0, 1 * 1000 * 1000); xhci->usb2_rhub.bus_state.port_c_suspend = 0; xhci->usb2_rhub.bus_state.suspended_ports = 0;
It seems 10 secs timeout is too long in general case. A core would wait for 10 secs without doing other task and it can be happended on every device. It's better to reduce timeout for general case and use new quirk if needed. Signed-off-by: Daehwan Jung <dh10.jung@samsung.com> --- drivers/usb/host/xhci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)