On Mon, Jan 07, 2013 at 08:38:34PM +0000, Russell King - ARM Linux wrote: > 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. My work was stalled due to other stuff at my workplace. I plan to spend some time on this pretty soon. > > 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
