Build failure with DMA_OMAP=m and a caller built-in

Build failure with DMA_OMAP=m and a caller built-in

[Tony Lindgren]

* Ben Hutchings <ben@decadent.org.uk> [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?

For the short term fix, how about ifdef out the DMA usage in the
client drivers:

#if defined(CONFIG_DMA_OMAP_MODULE) && defined(CONFIG_MMC_OMAP_MODULE)
	...
#endif

Regards,

Tony

Build failure with DMA_OMAP=m and a caller built-in

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [130107 12:24]:
> * Ben Hutchings <ben@decadent.org.uk> [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?
> 
> For the short term fix, how about ifdef out the DMA usage in the
> client drivers:
> 
> #if defined(CONFIG_DMA_OMAP_MODULE) && defined(CONFIG_MMC_OMAP_MODULE)
> 	...
> #endif

Sorry this should have been:

#if defined(CONFIG_DMA_OMAP_MODULE) && defined(CONFIG_MMC_OMAP)
	...
#endif

Regards,

Tony

Build failure with DMA_OMAP=m and a caller built-in

[Russell King - ARM Linux]

On Mon, Jan 07, 2013 at 12:21:06PM -0800, Tony Lindgren wrote:
> * Ben Hutchings <ben@decadent.org.uk> [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).

Build failure with DMA_OMAP=m and a caller built-in

[Vinod Koul]

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@decadent.org.uk> [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).

Build failure with DMA_OMAP=m and a caller built-in

[Arnd Bergmann]

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