On Thu, Dec 15, 2016 at 09:05:52PM -0800, Ben Zhang wrote: > On Wed, Dec 14, 2016 at 6:57 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > This doesn't affect audio routing so why is it being done with a DAPM > > mux? > When user wants the switching voltages, the Class G register bit needs > to be toggled at a specific time in the widget power up/down sequences > on the playback route. It helps reduce pop and is consistent with > existing behavior. DAPM_MUX achieves this by taking DAPM_PGA_S in and Sure, but a more normal way of doing that would be to use an event on the widget for the amplifier that looks at the value a regular control has set in a variable rather than having a mux... > John has sent me a patch which uses a separate SOC_ENUM_EXT kcontrol > in snd_soc_codec_driver.controls to set a flag, then has DAPM_PGA_S PM > event callbacks selectively setting the register bit based on the > flag. But it feels cleaner to implement this with a DAPM_MUX: The > DAPM_PGA_S widget power status correctly reflects the actual register > bit. User can experiment with the setting during playback. ...which is what it sounds like John's patch did. It is more idiomatic, it ensures that the DAPM routing represents the actual audio routing in the chip which means we keep everything in the abstractions that the system is using and avoid the potential for breakage resulting from things getting confused later on (eg, if we start exporting the routing to userspace).
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
