Hello.

Felipe Balbi wrote:

quoted

quoted

quoted

I think we will get more clarity once we start on this activity.

quoted

quoted

I agree, but I personally don't see that many limiting factors.
dmaengine is just a generic API for doing DMA transfers. If it's not
enough for us currently, we extend it.

quoted

    Putting MUSB DMA enignes into drivers/dma/ is the same as taking *any* 
chip capable of bus-mastering DMA, "separating" its bus mastering related code 
from its driver and putting this code into drivers/dma/. This doesn't make 
sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which 
can *optionally* serve the slave devices).

Do I really have to spell it out ? Really ?

    Yes, I'm dense. :-)
    Especially after Ajay claiming that Mentor and CPPI 3.0 DMA will be moved to 
drivers/dma/...

You don't need to physically move the part of the code to drivers/dma,
but it has to use the API. The mentor DMA is internal to MUSB.
tusb6010_omap.c isn't.

    Yes, that's what I've already noted in this thread.

Where it makes sense to move the code under drivers/dma, it will be

    Surely OMAP DMA needs to be moved under drivers/dma/, not the TUSB code
interfacing it.

done, where it doesn't, it won't be done, but it will use the same API.
That's all.

    I don't quite see how DMA engine API is beneficial to what we currently have...

The end goal is just to drop all these ad-hoc "APIs" for accessing DMA
on musb code.

    The "ad-hoc" API is well suited for use with MUSB, while DMA engine API is 
more abstract, I think. The "ad-hoc" API takes into account some things that the 
DMA engine API just can't -- like the transfer mode and packet size...

WBR, Sergei