Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Felipe Balbi <me@felipebalbi.com>]

Hi,

(using personal email, left the office)

On Tue, 2011-01-04 at 16:06 +0300, Sergei Shtylyov wrote:
> >> I think we will get more clarity once we start on this activity.
> 
> > 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