[PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
Felipe Balbi
me at felipebalbi.com
Tue Jan 4 09:06:24 EST 2011
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
More information about the linux-arm-kernel
mailing list