Felipe Balbi wrote:
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.
There's another thing I'm experimenting with... Taking musb_gadget.c as
example, I'm setting correct [RT}XCSR registers on musb_gadget_enable()
time, meaning that DMAReqEnab and DMAReqMode would be set there and
never touched again.
It seems to work for gadget side.
It won't work on the host Tx path -- you'll see why RSN.
So I just have to play with [RT]XPKTRDY bit.
I still have some glitches but seems that we don't have to keep
enabling/disabling DMA bits in [RT]XCSR registers.
No, we'll have to.
haha, you were right ;-)
it's really needed that we only write [RT]XCSR before kicking dma and
turn off those bits otherwise
Besides, I've just noticed that when using Inventra DMA the host driver is
unable to send ZLP at end of transfer. It's also unable to continue DMA if
the transfer exceeds channel->max_len (64 KB it seems)
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
