Re: [alsa-devel] [PATCH v5] sound/soc/lapis: add platform driver for ML7213

[Tomoya MORINAGA]

On Wed, May 30, 2012 at 9:14 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/