Hi,

(using personal email, left the office)

On Tue, 2011-01-04 at 16:06 +0300, Sergei Shtylyov wrote:

quoted

quoted

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

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.

    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 ?

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.

Where it makes sense to move the code under drivers/dma, it will be
done, where it doesn't, it won't be done, but it will use the same API.
That's all.

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

-- 
balbi