Hi Arnd

On Fri, 31 May 2013, Arnd Bergmann wrote:

On Friday 31 May 2013 17:30:01 Guennadi Liakhovetski wrote:

quoted

On Fri, 31 May 2013, Arnd Bergmann wrote:

quoted

On Friday 31 May 2013 16:52:13 Guennadi Liakhovetski wrote:

quoted

quoted

I think it's more a matter of using the API correctly. The dmaengine
API is an abstraction to separate the slave driver from the master
through well-defined calls. If you make additional assumptions
in the slave driver about the master, that is a layering violation.

I think it is a common practice, see e.g.

drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/davinci_mmc.c

Yes, those should be fixed as well.

Then we'll have to fix quite a few of those - I only looked under 
drivers/mmc for now.

But isn't that a separate issue? The problem we have to address now is 
broken compilation, for which, I think, my patch is the simplest solution. 
DMA slave drivers being DMAC implementation agnostic is good, no doubt 
about that, even though many of them will ever only use one DMAC type, but 
isn't that a separate issue? Fixing it would require patching 3 locations: 
a header to add a callback field, arches to add filters and drivers to 
actually call them instead of hard-coded functions. In the worst case 
those changes would go via 3 different git-trees, so, might take 3 kernel 
releases... Ok, at least two if we puch the header change together with 
arch updates via the same tree with suitable acks, still, that's too long, 
IMHO.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/