On Thu, 19 Sep 2013, Ramneek Mehresh wrote:
> As per USB specification, in Suspend state the status bit does
> not change until the port is suspended. However, there may be a delay
> in suspending a port if there is a transaction currently in progress
> on the bus.
>
> In the USBDR controller, the PORTSCx[SUSP] bit changes immediately when
> the application sets it and not when the port is actually suspended
>
> Workaround for this issue involves waiting for a minimum of 10ms to
> allow the controller to go into SUSPEND state before proceeding ahead
Why is this workaround needed? Does anything go wrong if it isn't
applied?
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -284,6 +284,8 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
> else if ((t1 & PORT_PE) && !(t1 & PORT_SUSPEND)) {
> t2 |= PORT_SUSPEND;
> set_bit(port, &ehci->bus_suspended);
> + if (ehci_has_fsl_susp_errata(ehci))
> + usleep_range(10000, 20000);
> }
Notice that there's no delay here for other controller types. Why does
USBDR need a delay?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
