[alsa-devel] [PATCH 00/13] ASoC: Move IO and kcontrols to the component level

[Lars-Peter Clausen]

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.

<brian.austin at cirrus.com>:
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 at 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