Hello, I wrote:
... but that implies a substantial cleanup of the DMA paths, and I'll be content to defer such only-one-place cleanup until that happens.
for sure today's code is really messy. All those ifs and ifdefery to check which dma we're using look awful...
To summarize, musb_hdrc has four basic DMA paths today, the cross product of {RX, TX} and {host, gadget}, each of which looks more or less like
if (cppi/davinci) do this else if (omap native/TUSB) do that else if (mentor's DMA) do something else
... I'm trying to move that to something like:
if (use_dma) do_this(); else do_pio();
I'm also not sure it's a good idea to handle DMA compeltion by calling musb_host_[rt]x() -- IMHO, having a separate DMA completion handling functions would lead to a cleaner code...
And clearer too. :-)
So that it would be, on musb side, all be running the same code and the dma-specific code should handle the peculiarities of itself. It's been a hard work clean up all that code and so far I'm testing only on mentor graphics dma, when I get mentor fully working with mode i'll check tusb6010 and later davinci with cppi.
CPPI basically fails now with the bulk transfers, at least under the high load -- the patch is coming... I don't feel sure but looking at the Inventra DMA code it seems that it might have the same issue when using DMA mode 1 -- I don't see where it clears TXCSR.DMAReqMode bit if it decides to set TxPktRdy instead of calling musb_dma_completion(), so it should never be getting another interrupt on TxPktRdy = 0...
Ah, it implicitly clears DMA bits by writing only MUSB_TXCSR_TXPKTDRY... but that violates the programming guide then which says that DMAReq{Enab|Mode} can't be cleared at once -- DMAReqMode must always be cleared after DMAReqEnab.
WBR, Sergei -- 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
