In the start_dma function, I added the following lines at the start of
the function:
if (req->req.length % ep->ep.maxpacket)
{
printk("%s packet is short(%d)...\n", (ep->is_in) ? "IN" : "OUT",
req->req.length);
}
The packet is never listed as short via my method above during this
erroneous data transfer, and yet the logic right below "/* previous
OUT packet might have been short */", is triggered, and
req->td->dmadesc = 0 is set, causing the 'paranoia' logic to get
triggered. Is my logic above a correct method of determining if a
packet was short, or is there another way for a short OUT packet to be
triggered that I'm not accounting for (i.e. start_dma is not the
source of the packet)?
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
