[alsa-devel] [RFC_i/iv 1/3] ASoC: Decouple DAPM from CODECs. Part core (will be squashed)

[Jarkko Nikula]

On Sat, 30 Oct 2010 19:01:54 +0100
Liam Girdwood <lrg at slimlogic.co.uk> wrote:

> On Fri, 2010-10-29 at 13:04 -0700, Mark Brown wrote:
> > On Fri, Oct 29, 2010 at 03:00:16PM +0300, Jarkko Nikula wrote:
> > 
> > >  	codec->debugfs_pop_time = debugfs_create_u32("dapm_pop_time", 0644,
> > >  						     codec->debugfs_codec_root,
> > > -						     &codec->pop_time);
> > > +						     &codec->dapm->pop_time);
> > 
> > The pop time feels like it should have an effect over the full card
> > rather than over individual CODECs - the power sequencing is obviously
> > going to be done over the entire card rather than individual devices so
> > it's a little unclear how competing values for different devices would
> > be applied.  This is a simple code motion patch and this is only debugfs
> > but perhaps it's worth first doing this as a split which moves the pop
> > time onto the card.
> > 
True. Looks like worth to add a patch doing pop decoupling in this set.

> Ah, I think we may be missing a later patch here that did add a DAPM
> context to card and platform.
> 
Yeah, I simplified a bit Liam's code and not added DAPM to other than
codecs since there is no yet use for it in these series.

> > >  	/* If we're changing to all on or all off then prepare */
> > > -	if ((sys_power && codec->bias_level == SND_SOC_BIAS_STANDBY) ||
> > > -	    (!sys_power && codec->bias_level == SND_SOC_BIAS_ON)) {
> > > -		ret = snd_soc_dapm_set_bias_level(card, codec, SND_SOC_BIAS_PREPARE);
> > > +	if ((sys_power && dapm->bias_level == SND_SOC_BIAS_STANDBY) ||
> > > +	    (!sys_power && dapm->bias_level == SND_SOC_BIAS_ON)) {
> > > +		ret = snd_soc_dapm_set_bias_level(card, dapm, SND_SOC_BIAS_PREPARE);
> > 
> > So, this is all going to be run per DAPM object from the looks of
> > things.  That's really not what we want - we want to be doing the
> > sequencing over all DAPM objects in the card, rather than per DAPM
> > object.  It'll need to be fixed at some point later in the series...
> 
Reason is that here is no need to touch other DAPM contexts until
RFC_ii/iv 3/3 since DAPM decoupling doesn't change yet how things work
currently.


-- 
Jarkko