Hello.
Felipe Balbi 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...
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...
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
