Messages in this thread |  | | | Date | Thu, 31 May 2012 14:38:30 +0900 | | Subject | Re: [alsa-devel] [PATCH v5] sound/soc/lapis: add platform driver for ML7213 | | From | Tomoya MORINAGA <> |
| |
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. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |