[alsa-devel] [PATCH] ASoC: Fix dapm_is_shared_kcontrol so everything isn't shared

Stephen Warren swarren at nvidia.com
Thu May 26 17:38:32 CEST 2011


Jarkko Nikula wrote at Thursday, May 26, 2011 12:58 AM:
> On Wed, 25 May 2011 08:24:59 -0700 Stephen Warren <swarren at nvidia.com> wrote:
> > > Then we must skip test for widgets that are in different dapm context,
> > > i.e. we don't want to share mux controls if they are in different device
> > > instance. Does it work for you if you add the dapm test below to your
> > > patch?
> >
> > I suppose that's technically correct, and I'm fine adding this to the
> > patch. However, I'm surprised that change is needed; do we actually have
> > a situation where two widgets in different DAPM contexts point at the
> > same control definition? It seems like that'd be a bug; why would there
> > be two controls pointing at the same register field, yet in different
> > DAPM contexts?
>
> Yes, I noticed this can happen when you have multiple same codecs in a
> system. Let's assume we have multiple wm8903 codecs and we have these
> in the driver:

Yes, of course, that makes perfect sense. I'll rev the patch as you suggested.

> static const struct snd_kcontrol_new adcinput_mux =
> 	SOC_DAPM_ENUM("ADC Input", adcinput_enum);
> 
> static const struct snd_soc_dapm_widget wm8903_dapm_widgets[] = {
>   SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux),
> };
> 
> Even the core duplicates widgets for each codec instance in this
> example, they still point to same adcinput_mux and thus
> dapm_is_shared_kcontrol() miss detects them as shared if we don't skip
> different dapm context.

-- 
nvpublic



More information about the Alsa-devel mailing list