On 11/28/2014 12:51 PM, Arnd Bergmann wrote:

On Friday 28 November 2014 09:16:24 Peter Ujfalusi wrote:

quoted

On 11/27/2014 11:52 PM, Arnd Bergmann wrote:

quoted

On Thursday 27 November 2014 20:46:12 Peter Ujfalusi wrote:

quoted

I see. With this series I did not planed to fix all edma related issues, just
as a start clean up the related header files. I would rather not add fixes to
mmc, spi, etc drivers since while you have valid point it is not in the scope
of this series.
Can we do the changes you are suggesting in an incremental manner?

Sure, but I'd leave the existing filter function declaration alone then
and not move it, since we wouldn't want to keep it in the long run.

but if you want to reference the filter function (which is in
drivers/dma/edma.c) in arch/arm/mach-davinci/ directory, we will need it.
Don't we?

Yes, unless you move the definition of the filter function into
arch/arm/common/edma.c or arch/arm/mach-davinci/devices.c, but that
would require other changes.

At the end the aim is to get rid of the edma code form arch/arm and have only
dmaengine API towards eDMA. The ASoC davinci-pcm is the only user of the
legacy API AFAIK. It has a mode called ping-pong which is not possible with
the dmaeingine at all. This is to overcome underflow situations on parts where
the audio IP does not have FIFO.
My edma-pcm (which is using dmaengine) should be able to handle this
situation, but I need to verify it before I can remove the davinci-pcm and
then we can get rid of the direct eDMA API and code.

quoted

If I leave the header as it is, then how would we clean up the edma headers? I
would not put the API definitions for the arch code into the same file as we
have the filter definition.

Ok, just go ahead with your current patch then, we can always follow up.
The most important cleanup for edma is elsewhere anyway, so once the asoc
drivers can use the dmaengine interface, this should be easier.

	Arnd

-- 
P?ter