On Tue, Jan 04, 2011 at 04:06:39PM +0300, Sergei Shtylyov wrote: > 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). Then why is it already separated into its own self-contained driver? If it's because the DMA engine is used for different peripherals (possibly re-used for different peripherals), then it does seem to make sense to have it separated via some API. And if possible that API might should be something generic instead of specific. Even more reason to do this is if the device being fed by the DMA has been re-used with different DMA hardware (which I believe is the case with MUSB.) What if this different DMA hardware then gets re-used for other devices? Should they all implement the same custom API or try for a generic API? -- 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
