[alsa-devel] [PATCH 2/2] ASoC: dapm: Add a helper to get the platform for DAPM kcontrol
Lars-Peter Clausen
lars at metafoo.de
Mon May 26 18:52:28 CEST 2014
On 05/26/2014 06:23 PM, Vinod Koul wrote:
> On Mon, May 26, 2014 at 03:29:03PM +0200, Lars-Peter Clausen wrote:
>> On 05/26/2014 02:08 PM, Vinod Koul wrote:
>> [...]
>>> + * snd_soc_dapm_kcontrol_platform() - Returns the platform associated to a kcontrol
>>> + * @kcontrol: The kcontrol
>>> + */
>>> +struct snd_soc_platform *snd_soc_dapm_kcontrol_platform(
>>> + struct snd_kcontrol *kcontrol)
>>> +{
>>> + return dapm_kcontrol_get_wlist(kcontrol)->widgets[0]->platform;
>>> +}
>>> +EXPORT_SYMBOL_GPL(snd_soc_dapm_kcontrol_platform);
>>
>> This conflicts with the series that moves DAPM support to the
>> component level [1].
>
> Thanks for the pointer, has this series been merged?
> Dont see it in topic/core in Mark's tree.
It hasn't been merged yet.
>
> I will take a look but fwiw this statement is not entirely true in the cover
> letter of patch:
>
> "This will allow any component to have DAPM widgets and routes, which was
> previously only possible for CODECs, and will allow any component to have DAPM
> widgets with controls (i.e. Mixers and MUXs), which was previously only possible
> for CODECs"
>
> I am already running a system which models platform and has Mixers,
> Muxes and works fine (tested on 3.10 and 3.14).
It works if you use custom controls. But it does not work with the standard
SOC_DAPM_* controls.
>
> Few bits of code is in RFC I sent earlier and will post these in detail over
> next few weeks
Do you think it is necessary that these two patches get merged before you
send the other patches? It would be good to see things in context. That will
make it easier to properly review patch 1 of this series.
- Lars
More information about the Alsa-devel
mailing list