I spoke with the Avago/PLX FAE, and they said that the PLX software team that worked on this driver is no longer with the company, so they cannot offer support :( I'm not sure there is going to be a good answer for this issue. Hopefully someone here can help me evaluate the "/* paranoia */" code to determine if/why/when it's necessary? On Fri, Jan 22, 2016 at 10:46 AM, Justin DeFields <justindefields@xxxxxxxxx> wrote: > > It turns out that I had a filesystem issue on my target when testing > my removal of the /* paranoia */ block. I thought I was writing the > file to NAND, when in fact it was being written over NFS to my Virtual > Machine!!! After resolving this issue, and with the removal of the > paranoia logic, the transfer completes as expected very quickly and > reliably (20/20 transfers completed successfully). > > Can anyone here help me determine if that paranoia loop is still > necessary for the PCIE cards, or what the purpose of it was in the > first place? > > Thanks, > > Justin D. > > On Wed, Jan 20, 2016 at 2:43 PM, Justin DeFields > <justindefields@xxxxxxxxx> 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 -- Justin DeFields Embedded Software Engineer -- 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
