[PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
sshtylyov at mvista.com
Tue Jan 4 08:06:39 EST 2011
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).
More information about the linux-arm-kernel