On Monday 07 January 2013, Russell King - ARM Linux wrote: > The problem we have is that the way peripheral devices are connected to > their DMA engines can involve additional complexity, which if not handled > correctly results in some platforms being crippled by the API. > > I think Vinod was working on something, however I've not heard anything on > that for a while now. > > How we avoid this problem outside of OMAP is that the DMA filter function > gets passed from platform code, and we only ever allow the DMA engine > driver to be configured into the kernel (iow, non-modular). This means > that the DMA users never directly reference the DMA engine driver itself. > However, as OMAP headed down the DT path, many drivers no longer make use > of platform data, which makes that approach impractical. Hmm, it seems the generic DT binding for dmaengine missed the merge window again, Vinod's pull request came a bit too late for this[1]. Anyway, once the binding and code from Jon Hunter is there, and the omap-dma converted over to use it, the problem should be gone, unless you see any other issues with it. Drivers no longer need to reference a filter function directly, since the dma channel can get described completely in the DT. Arnd [1] http://lkml.org/lkml/2012/12/21/466 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
