On Mon, May 28, 2012 at 7:19 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
I'm not so familiar with Linux's DMA idea. So we don't know whether non-cyclic dmaengine has problem or not.
Nobody has written the code, this is the problem! If the code is not there, you should try to write it. If there is some great problem writing the code then you should t
The latter of the above seems dropped...
First you should not be writing your own dma driver, it *needs* to use dmaenegine. We already have bunch of driver supported, so there may be a
He's already done that, their current code is all open coded dmaengine stuff.
I don't understand why you say so ? I don't use any own dma driver, right ? I use only dmaengine's. If there is own, let me show.
As you said, common code for DMA code can be best solution. However, currently, the code is nothing. So, I want you to accept our driver as first step. Because I think supporting new device is more important for linux than dmaengine common.
The existing code is far from nothing, there is a fairly substantial dmaengine library there already which should share a big chunk of code with any cyclic support. If you were saying "this is too hard for $REASON" that'd be one thing but that's not what you're saying here.
If our ASoC supports cyclic dma mode, we must modify both pch_dma driver and our ASoC driver. I don't want to do this. Because I can't understand the merit. In plain words, to me, this looks insignificant things. In fact, current all applied ASoC drivers use dmaengine don't use cyclic mode, right ?
It's possible that there is actually some substantial difficult but my first instinct would be that it should be relatively straightforward.
Let me clarify your saying again. Which do you want ? 1) pch_dma must support cyclic dma mode and our ASoC driver must use the cyclic dma function. 2) Non-cyclic dma engine should be added to alsa-dmaengine by myself. 3) Other
Thanks