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