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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 May 2012 14:38:30 +0900
From:	Tomoya MORINAGA <tomoya.rohm@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Vinod Koul <vinod.koul@...ux.intel.com>,
	alsa-devel@...a-project.org, lars@...afoo.de,
	Takashi Iwai <tiwai@...e.de>, linux-kernel@...r.kernel.org,
	Liam Girdwood <lrg@...com>
Subject: Re: [alsa-devel] [PATCH v5] sound/soc/lapis: add platform driver for ML7213

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