Re: NET2280: Adding PLX usb2380 support (issues encountered)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux