On 14.11.2017 21:16, Curt Meyers wrote:
...
Hi Mathias,
The manufacture hired a Linux developer to solve the problem with this isochronous camera device and it turns out to be related to LPM that only shows up in newer Intel hardware, according to the developer. He says that there is something wrong with the MEL (Max Exit Latency) and skipping it in the call to xhci_configure_endpoint() fixes the problem, or works around it.
...
I just received this updated patch, it adds a call to spin_unlock_irqrestore() and a comment for the code.
The comment says that LPM with isochronous endpoints causes config_EP to fail.
---
diff -Naur host.ori/xhci.c host/xhci.c
--- host.ori/xhci.c 2017-11-02 01:50:04.544937000 +0800
+++ host/xhci.c 2017-11-08 01:40:38.929681000 +0800
@@ -4001,6 +4001,20 @@
return 0;
}
+ // Workaround: Enable LPM when a SS ISOC EP is opened will cause all subsequent config_EP fail
+ if ((xhci->quirks & XHCI_SET_MEL_STUCK) && (USB_SPEED_SUPER == udev->speed) && (max_exit_latency > 0))
+ {
+ int i;
+ for (i = 0; i < 31; i++) {
+ struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->out_ctx, i);
+ int ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx->ep_info2));
+ if ((ISOC_IN_EP == ep_type) || (ISOC_OUT_EP == ep_type)) {
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ return 0;
+ }
+ }
+ }
+
/* Attempt to issue an Evaluate Context command to change the MEL. */
command = xhci->lpm_command;
ctrl_ctx = xhci_get_input_control_ctx(command->in_ctx);
diff -Naur host.ori/xhci.h host/xhci.h
--- host.ori/xhci.h 2017-11-02 01:50:04.544937000 +0800
+++ host/xhci.h 2017-11-02 23:41:17.000000000 +0800
@@ -1650,6 +1650,8 @@
#define XHCI_SSIC_PORT_UNUSED (1 << 22)
#define XHCI_NO_64BIT_SUPPORT (1 << 23)
#define XHCI_MISSING_CAS (1 << 24)
+#define XHCI_SET_MEL_STUCK (1 << 31)
+
unsigned int num_active_eps;
unsigned int limit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
diff -Naur host.ori/xhci-pci.c host/xhci-pci.c
--- host.ori/xhci-pci.c 2017-11-02 01:50:04.536937000 +0800
+++ host/xhci-pci.c 2017-11-08 01:40:38.929681000 +0800
@@ -168,6 +168,7 @@
pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI ||
pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI)) {
xhci->quirks |= XHCI_PME_STUCK_QUIRK;
+ xhci->quirks |= XHCI_SET_MEL_STUCK;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) {
---
~
--
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
Hi Mathias,
Not sure if you saw my second diff, it is slightly different than the first. Since I am going between the developer and the maintainers is there something I can do to move this investigation along?
This patch provides a fix for the serious problem we have found with USB3 isochronous devices running on newer Intel hardware.
Perhaps you or someone else at Intel that is very familiar with the USB hardware can better understand the implications of this patch.
Thanks,
Curt
Hi,
This code basically prevents the "evaluate context" from setting any MEL value (other than 0).
But it still enables LPM for these devices, which increases the "wakeup" latency time for the link.
Now the code just doesn't tell the xHC controller that the Maximum Exit Latency (MEL) is increased
Any chance I could get a direct contact to this developer?
Thanks
Mathias
--
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
