[alsa-devel] [PATCH 00/13] ASoC: Move IO and kcontrols to the component level
lars at metafoo.de
Tue Mar 18 15:20:22 CET 2014
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:
>>> 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)
>>> else if(w->platform)
>>> 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
>>> like volume controls etc. whose register layout is similar to those used in
>>> CODECs. Currently each CPU component driver re-implements these controls by
>>> The first two patches introduce two new helper functions which hide the
>>> 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
>>> driver. The patches that follow that are just cleanups removing unused IO
>>> and move all IO functions to soc-io.c. The next step is to make platforms
>>> components. And then finally first the IO abstraction layers in ASoC are
>>> 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.
> I don't see a [01/13] patch. It doesn't show up for some reason. I checked
> the archives as well and nothing.
For some reason your mail server bounced the patches.
<brian.austin at cirrus.com>:
22.214.171.124 does not like recipient.
Remote host said: 550 5.7.1 Service unavailable; Client host
[126.96.36.199] blocked using Blocklist 1; To request removal from this
list please forward this message to delist at messaging.microsoft.com
Giving up on 188.8.131.52.
patch 1 was also caught by the alsa-list spam filter as it was a bit to large.
More information about the Alsa-devel