From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kuninori Morimoto Subject: Re: About snd_dmaengine_pcm_trigger() Date: Wed, 05 Mar 2014 00:32:32 -0800 (PST) Message-ID: <874n3dqc4j.wl%kuninori.morimoto.gx@gmail.com> References: <87eh2hql03.wl%kuninori.morimoto.gx@gmail.com> <5316D562.3010901@metafoo.de> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by alsa0.perex.cz (Postfix) with ESMTP id 0F8E826500A for ; Wed, 5 Mar 2014 09:32:34 +0100 (CET) Received: by mail-pb0-f45.google.com with SMTP id uo5so775081pbc.32 for ; Wed, 05 Mar 2014 00:32:33 -0800 (PST) In-Reply-To: <5316D562.3010901@metafoo.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Lars-Peter Clausen Cc: Simon , Linux-ALSA , Mark Brown , Liam Girdwood , Kuninori Morimoto List-Id: alsa-devel@alsa-project.org Hi Lars Thank you for your feedback > > 3rd, our device needs special method on snd_pcm_ops > > int the future. > > > > What kind of special ops? It would like to use snd_soc_dapm_widget, but we can update snd_soc_component instead of platform ? > I don't think using the snd_dmaengine_pcm helpers should be difficult, > since, as I said, each of them perform one very specific task. If you'd > directly call the dmaengine API you'd end up with pretty much the same code > as the dmaengine PCM helpers. What's more of a challenge would be to use the > generic dmaengine PCM driver. > > I think the issue with the sound/soc/sh/ code is that there never was a > clean separation between the DMA/PIO and the DAI configuration code. And > especially with rcar you seem to be reimplementing a ASoC-like framework > on-top of ASoC. Which makes it rather hard to reused generic code, since the > generic code doesn't know about all the custom hooks and callbacks. The ASoC > framework is not set in stone, if there is something missing to properly > support your hardware you should try to extend the framework to support this > rather than working around it in your drivers. I see... I need investigate more about this, but, before that, can I confirm ? basically... platform : for PIO or DMA transfer method component : for DAI configuration = CPU side HW settings etc Is this correct ? And about ASoC-like framework, rcar driver needs to control many kind of devices, and it depends on platform which device is used. (each devices have different feature) So, I used ASoC-like framework, but in this case, what should I do ?