Re: [PATCH 2/3] ASoC: Add support for sequencing within

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

On 01/18/11 18:20, ext Mark Brown wrote:
> With larger devices there may be many widgets of the same type in series
> in an audio path. Allow drivers to specify an additional level of ordering
> within each widget type by adding a subsequence number to widgets and then
> splitting operations on widgets so that widgets of the same type but
> different sequence numbers are processed separately.  A typical example
> would be a supply widget which requires that another widget be enabled
> to provide power or clocking.
> 
> SND_SOC_DAPM_PGA_S() and SND_SOC_DAPM_SUPPLY_S() macros are provided
> allowing this to be used with PGAs and supplies as these are the most
> commonly affected widgets.

Not really for this series...
I have been also wondering on the power up/down sequence ordering in a
complex setup.
I might be totally wrong, but never the less:
I have been wondering, if we just go, and follow the sequence of the
DAPM widgets in on the path on powerup, and follow the reverse sequence
on powerdown.

Take something like this:
DAC->PGA1->MIXER1->PGA2->MUX->PGA3->MIXER2->OUTPUT->SPEAKER
 ^      ^                       ^
SUPPLY1 SUPPLY2                 SUPPLY3

The sequence now:
SUPPLY1->SUPPLY2->SUPPLY3->MUX->DAC->MIXER1->MIXER2->PGA1->PGA2->PGA3->SPEAKER

Now we are going to be able to change the order of PGA, and SUPPLY.
We were able to do that earlier by changing the order of the PGA/SUPPLY
within the snd_soc_dapm_widget struct (I know... it is not really explicit).

But if we actually follow the route we could have sequence of:
SUPPLY1->DAC->SUPPLY2->PGA1->MIXER1->PGA2->MUX->SUPPLY3->PGA3->MIXER2->SPEAKER

When we build up the DAPM tree, we usually follow the spec, basically
modeling the HW, so we can take care of the recommended sequences.

IMHO in this way we would have better control over the sequences, and we
might be in better position to combat pop noises, since we have more
explicit control over the sequence of events.

I have not looked how hard it would be to change the DAPM to do this.
Anyways I would not started to do this without asking... I know there
are really good reasons to have the current DAPM sequence handling, but
I do wonder, if it make sense to do this.

What do you think?

-- 
Péter