On Fri, 20 Sep 2013, Mehresh Ramneek-B31383 wrote:
> From: Alan Stern [mailto:[email protected]]
> Sent: Thursday, September 19, 2013 7:03 PM
> To: Mehresh Ramneek-B31383
> Cc: [email protected]
> 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.
Which subroutine in which source file sends the HNP notification?
> > --- 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);
> > }
This is the wrong place to add a delay. For one thing, this isn't
where the port gets put into suspend -- that occurs about 17 lines
later.
For another, ehci_bus_suspend() gets called when the root hub is
suspended. But you want to implement this delay when the port gets
suspended, which is in ehci_hub_control().
Also, you shouldn't use usleep_range(). Call ehci_handshake() instead.
And be certain to drop ehci->lock while you are waiting for the port to
go into suspend. 10 ms is too long to hold a spinlock.
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
