On Mon, Jan 07, 2013 at 12:21:06PM -0800, Tony Lindgren wrote: > * Ben Hutchings <ben@xxxxxxxxxxxxxxx> [130105 21:29]: > > Various drivers use omap_dma_filter_fn() but don't depend on DMA_OMAP. > > This is fine because there is a trivial inline definition in case > > DMA_OMAP is disabled... until the caller is built-in and DMA_OMAP=m. > > > > I tried adding the rather weird 'select DMA_OMAP if DMA_OMAP!=n' to > > these drivers' kconfig symbols to promote it to built-in if necessary. > > This sort of works but kconfig complains about the circular dependency > > and it becomes impossible to disable DMA_OMAP in the 'make nconfig' > > menu. So that's not the right thing to do. > > > > Any ideas? > > Hmm let's ask Russell and Vinod what they are envisioning. I believe > there was some talk about removing the filter functions? The right thing is to nobble down and try and resolve the age old, much talked about, common way to tie peripheral devices and their DMA engine channels together by some means. Unfortunately, it seems everyone has different views, and as yet it's not reached any kind of concensus. This has now been going on for a couple of years in various forms. 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. So, I'm afraid that OMAP's rather boxed into a corner over the various different competing factions about how ARM should do X, Y and Z vs the state of various subsystems. So much for DT sorting out world hunger and it never failing to solve any problem... I'm sure it'll eventually get sorted, but how long that takes depends on how long it takes to come up with a working API for connecting peripheral devices with their DMA agent(s). -- 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
