From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars-Peter Clausen Subject: Re: [PATCH 00/13] ASoC: Move IO and kcontrols to the component level Date: Tue, 18 Mar 2014 15:20:22 +0100 Message-ID: <53285626.2090209@metafoo.de> References: <1395129736-11938-1-git-send-email-lars@metafoo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-out-234.synserver.de (smtp-out-234.synserver.de [212.40.185.234]) by alsa0.perex.cz (Postfix) with ESMTP id EB5CA26158B for ; Tue, 18 Mar 2014 15:19:36 +0100 (CET) In-Reply-To: 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: Brian Austin Cc: alsa-devel@alsa-project.org, Takashi Iwai , patches@opensource.wolfsonmicro.com, Liam Girdwood , Paul Handrigan , Peter Ujfalusi , Mark Brown , Charles Keepax , Maxime Ripard , Kuninori Morimoto List-Id: alsa-devel@alsa-project.org On 03/18/2014 03:17 PM, Brian Austin wrote: > On Tue, 18 Mar 2014, Takashi Iwai wrote: > >> At Tue, 18 Mar 2014 09:02:03 +0100, >> Lars-Peter Clausen wrote: >>> >>> Hi, >>> >>> This series is the first step towards full componentisation of the ASoC >>> core. It >>> moves both the IO abstraction layers within ASoC as well as the standard >>> set of >>> kcontrols to the component level. This for example means we can get rid of >>> constructs like >>> >>> if (w->codec) >>> snd_soc_read(....) >>> else if(w->platform) >>> snd_soc_platform_read(...) >>> >>> Moving the kcontrols to the component level means we can use the same >>> implementation also for other non-CODEC components. E.g. there seems to >>> be an >>> increasing amount of CPU components that have basic signal processing and >>> things >>> like volume controls etc. whose register layout is similar to those used in >>> CODECs. Currently each CPU component driver re-implements these controls by >>> hand. >>> >>> The first two patches introduce two new helper functions which hide the >>> actual >>> implementation on how the CODEC or platform struct that register a >>> control can >>> be obtained from the control. This means that when the actual >>> implementation is >>> changed only the two helper functions need to be updated and not every >>> single >>> driver. The patches that follow that are just cleanups removing unused IO >>> stuff >>> and move all IO functions to soc-io.c. The next step is to make platforms >>> also >>> components. And then finally first the IO abstraction layers in ASoC are >>> unified >>> at the component level and then on top of that the kcontrol helpers are >>> moved to >>> the component level. >>> >>> The series depends on quite a few topic branches related to changes to >>> the core >>> and cleanups for individual drivers. It is probably best to place it on >>> top of >>> asoc-v3.15-2. The patch that moves the kcontrols to the component level >>> also has >>> a runtime dependency on the not yet applied patches that move the >>> ams-delta and >>> mfld_machine controls to the card level. >> >> I'd love to have seen this one or two weeks ago, if this is intended >> for 3.15 upstream. But I guess it's still OK if anyone can test the >> stuff well. >> >> >> thanks, >> >> Takashi >> > I don't see a [01/13] patch. It doesn't show up for some reason. I checked > the archives as well and nothing. > > Thanks, > Brian For some reason your mail server bounced the patches. : 207.46.163.247 does not like recipient. Remote host said: 550 5.7.1 Service unavailable; Client host [212.40.185.230] blocked using Blocklist 1; To request removal from this list please forward this message to delist@messaging.microsoft.com Giving up on 207.46.163.247. patch 1 was also caught by the alsa-list spam filter as it was a bit to large. - Lars