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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
