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?