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-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
