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

[Sergei Shtylyov <sshtylyov@mvista.com>]

Hello.

Felipe Balbi 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 ?

    Yes, I'm dense. :-)
    Especially after Ajay claiming that Mentor and CPPI 3.0 DMA will be moved to 
drivers/dma/...

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

    Yes, that's what I've already noted in this thread.

> Where it makes sense to move the code under drivers/dma, it will be

    Surely OMAP DMA needs to be moved under drivers/dma/, not the TUSB code
interfacing it.

> done, where it doesn't, it won't be done, but it will use the same API.
> That's all.

    I don't quite see how DMA engine API is beneficial to what we currently have...

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

    The "ad-hoc" API is well suited for use with MUSB, while DMA engine API is 
more abstract, I think. The "ad-hoc" API takes into account some things that the 
DMA engine API just can't -- like the transfer mode and packet size...

WBR, Sergei