On 6/26/2013 2:32 PM, Felipe Balbi wrote:
Hi,
On Wed, Jun 26, 2013 at 02:28:57PM +0530, George Cherian wrote:
Synopsis xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
Signed-off-by: George Cherian<george.cherian@xxxxxx>
---
drivers/usb/host/xhci-plat.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 93ad67e..e63c6d3 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -25,6 +25,16 @@ static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
* dev struct in order to setup MSI
*/
xhci->quirks |= XHCI_BROKEN_MSI;
+
+ /*
+ * In some xhci controllers which follows xhci 1.0 spec gives a spurious
+ * success event after a short transfer. This quirk will ignore such
+ * spurious event. Hit this issue in synopsis xhci controllers with
+ * hci_version > 0.96
+ */
+
+ if (xhci->hci_version > 0x96)
+ xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
}
doesn't look like the correct way to do this. What if enabling that
quirk on hosts which don't have the quirk cause problems ?
For a controller which does not have this issue will never get a
spurious success for short packet ( and that too for only ISOCH).
per this commit ad808333d Intel xhci: Ignore spurious successful event.
This spurious successful event behavior isn't technically disallowed by
the xHCI specification, so make the xHCI driver just ignore the spurious
completion event.
I would suggest adding a platform_data which (in our case) dwc3 will
pass to xhci-plat. Then you can do proper revision detection of the
synopsys controller and set the quirk only on the failing hosts.
BTW, do you have the STARS number for this errata ?
No STARS number yet.
Regards
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
