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

Sergei Shtylyov sshtylyov at mvista.com
Tue Jan 4 08:06:39 EST 2011


Hello.

On 03-01-2011 23:44, Felipe Balbi wrote:

>>> > Moreover, even Felipe also seems to move other musb
>>> > DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma.

>>> Frankly speaking, I doubt that drivers/dma/ will have place for the
>>> purely MUSB specific DMA engines such as the named ones (there's no TUSB
>>> DMA BTW it uses OMAP DMA).

>> 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).

WBR, Sergei



More information about the linux-arm-kernel mailing list