-----Original Message-----
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Thursday, September 19, 2013 7:03 PM
To: Mehresh Ramneek-B31383
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH]fsl/usb: Workarourd for USB erratum-A005697
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?
[Ramneek]: This workaround is needed because we have this issue with the
controller.
In some protocols like HNP, a notification needs to be sent to another OTG
device
as soon as current controller port goes into SUSPEND state. However, this
notification could be false if the port is still transmitting some data and the
controller informs system s/w that the port is already in suspend state.
> --- 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?
[Ramneek] USBDR has this issue where it sets SUSPEND status bit even before it
is in SUSPEND state.
It has been guaranteed that the port will definitely go into SUSPEND state in
10ms.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
