usb: host: Reduce xhci_handshake timeout in xhci_reset

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
Related show

Commit Message

Jung Daehwan June 22, 2021, 11:24 a.m.
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(-)

Comments

Greg Kroah-Hartman June 22, 2021, 7:56 p.m. | #1
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
Jung Daehwan June 28, 2021, 2:25 a.m. | #2
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

>
Greg Kroah-Hartman June 28, 2021, 6:53 a.m. | #3
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
Jung Daehwan June 28, 2021, 6:55 a.m. | #4
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

>
Mathias Nyman June 28, 2021, 7:49 a.m. | #5
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

Patch

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;