[PATCH 1/2] ARM: shmobile: sdhi: pass DMA filter from platform code

Guennadi Liakhovetski g.liakhovetski at gmx.de
Wed Jun 5 04:28:35 EDT 2013


Hi Arnd

On Fri, 31 May 2013, Arnd Bergmann wrote:

> On Friday 31 May 2013 17:30:01 Guennadi Liakhovetski wrote:
> > On Fri, 31 May 2013, Arnd Bergmann wrote:
> > > On Friday 31 May 2013 16:52:13 Guennadi Liakhovetski wrote:
> 
> > > 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/



More information about the linux-arm-kernel mailing list