On Mon, Feb 02, 2009 at 05:04:22PM +0100, Sergei Shtylyov wrote:
> Hello.
>
> 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
--
balbi
--
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
