RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697

From	Jerry Huang <jerry.huang@nxp.com>
Newsgroups	linux.kernel
Subject	RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697
Date	2016-11-25 14:40 +0100
Message-ID	<sHoTo-18u-19@gated-at.bofh.it> (permalink)
References	<sH0el-1UP-9@gated-at.bofh.it> <sH5xo-5lp-23@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Hi, Alan,
Maybe other USB controller does not need this delay. 
However, our silicon errata point out,  in the USBDR controller, the PORTCx[SUSP] bit changes immediately when the application sets it and not when the port is actually suspended, so the application must wait for at least 10 milliseconds after a port indicates that it is suspended to ensure the port has entered SUSPEND status before initiating this port resume using the Force Port Resume (which is one bit for NXP silicon, not-EHCI compatible).
I will add more comment to understand why we need this delay in next version.

Best Regards
Jerry Huang

-----Original Message-----
From: Alan Stern [mailto:stern@rowland.harvard.edu] 
Sent: Friday, November 25, 2016 12:54 AM
To: Sriram Dash <sriram.dash@nxp.com>
Cc: Jerry Huang <jerry.huang@nxp.com>; gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; julia.lawall@lip6.fr; Ramneek Mehresh <ramneek.mehresh@nxp.com>; Suresh Gupta <suresh.gupta@nxp.com>
Subject: RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697

On Thu, 24 Nov 2016, Sriram Dash wrote:

> >From: Changming Huang [mailto:jerry.huang@nxp.com] As per USB 
> >specification, in the 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

The USB core guarantees that there won't be any data transactions in progress when a root hub is suspended.  There might possibly be an SOF transaction, but that doesn't take more than a few microseconds at most.  Certainly nowhere near 10 ms!

Given that we already perform a 150-us delay, is this change really needed?

Alan Stern

Thread

RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697 Sriram Dash <sriram.dash@nxp.com> - 2016-11-24 12:20 +0100
  RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697 Alan Stern <stern@rowland.harvard.edu> - 2016-11-24 18:00 +0100
    RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697 Jerry Huang <jerry.huang@nxp.com> - 2016-11-25 14:40 +0100
  RE: [PATCH] fsl/usb: Workarourd for USB erratum-A005697 Jerry Huang <jerry.huang@nxp.com> - 2016-11-25 09:30 +0100

csiph-web