We had our hardware engineer add in a usb3380 chip to our board in place of the usb2380 (with some small wiring adjustments, and utilizing the usb 2.0 pins only). It has the EXACT same issue as the 2280, which leads me to the following:
1) I have probably implemented the usb2380 device correctly (or at least in line with the usb3380 as a usb 2.0 device) 2) That paranoia loop is being triggered/entered erroneously, or the usb3380 driver does not properly set itself up for usb 2.0 connections. 3) The CDC ACM driver may be issuing short reads/writes, while the other gadget drivers do not, meaning that all short read/write operations can be problematic Does anyone have any ideas on this issue? On Wed, Jan 20, 2016 at 2:43 PM, Justin DeFields <justindefie...@gmail.com> wrote: > System: Custom Xilinx Zynq based system > Kernel: Xilinx linux v2015.1 (linux 3.18) > > I was attempting to add support for the PLX usb2380 chip to the > net2280.c driver. As far as I can tell, this chip is the same as the > 3380, but does not support USB3.0 (2.0 only). > > I have changed all checks for the quirk PLX_SUPERSPEED to a new quirk > called PLX_PCIE_MSI, except for where PLX_SUPERSPEED was used to set > USB_SPEED_SUPER. > > This implementation seemed to work fine, except for when I attached > the 'g_serial' gadget with ACM. The issue I have is that any data > transfer that is not a multiple of the endpoint maxpacket size (512 > bytes), results in the '/* paranoia */' block of code in > 'scan_dma_completions (struct net2280_ep *ep)' function to be called 8 > times, and then the transfer goes off the rails at that point. The > data all got to it's destination, but much more data was processed > than expected (it seems like the last DMA transaction is being > processed more than once). > > I noticed that the chip has some errata, which specifically called out > DMA issues when the transfer size is unaligned, but I am using the > 'AB' revision, and that errata seemed to be listed for 'AA' only. > > As a side note, if I remove the '/* paranoia */' block of code in > scan_dma_completions, the transfer actually completes as expected with > no extra data, but it takes a VERY long time for it to complete > (roughly 10 seconds after the first paranoia loop is entered). > > If I use PIO instead of DMA, the transfer sometimes completes, > sometimes it doesn't, and sometimes it doesn't even start. > > I suspect there could be some differences in FIFO sizes, or endpoint > configuration between the 2380 and 3380, but I've tried many > permutations and combinations of the various quirk flags in this > driver, and most didn't change driver operation at all surprisingly > (or at least not to any degree that I could measure). I'm looking for > some assistance or tips in debugging this issue. > > Thanks, > > Justin DeFields > Embedded Software Engineer -- Justin DeFields Embedded Software Engineer -- 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
