On Wed, May 30, 2012 at 9:14 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
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.
Please re-read what I wrote.
Let me clarify. Do you say native DMA driver API like dmaengine_prep_slave_sg(), dmaengine_submit() shouldn't be used from ASoC driver, right ?
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.
No, all current mainline drivers using the library use cyclic DMA.
I can't see any driver uses cyclic DMA. (I saw linux-next's tree from kernel.org.) Where is your saying "current mainline" ?
I don't want to do this. Because I can't understand the merit. In plain words, to me, this looks insignificant things.
The purpose of this change is to factor code out of individual drivers into generic code rather than having lots of people writing exactly the same code. Code duplication at this level is pointless and makes more work for everyone who will have to maintain the code going forward.
I understand your saying "merit".
However I think it seems difficult for supporting all devices. Because hardware dependency control code can't be added. For example, for ML7213, needs interrupt control both before/after DMA transfer. However, in case of using soc-dmaengine, the control can't be done. Because the processing is in soc-dmaengine.
Having looked at Russell's out of tree code I'm even more convinced that the amount of new code needed for non-cyclic DMA should be pretty trivial.
I don't know what you are talking about.
thanks.