On Mon, Mar 22, 2010 at 04:04:56PM +0200, Peter Ujfalusi wrote: > bit 4-5: Gain (0x0 - power down, 0x1 - 6dB, 0x2 - 0dB, 0x3 - -6dB) > If there is no audio activity, and user changes the routing, than the gain value > will be also written to the chip, which causes the amp to be enabled. So it's shared power and volume in a single bitfield. > > If it's supposed to be holding the controls at a mute value while the > > PGA is powered down then this is something that ASoC could benefit from > > in general - it'd be much better if we could keep amplifiers muted while > > not in active use and sequence the unmute into the power management at > > the end since this is good for pop/click management in general. I'd > > started to look at this but not yet got enough time to finish off > > implementing it. > Yes, I have been also thinking about that, but I really don't know how it can be > done: > For the DAPM part it is kind of easy, since we can decide in the core when to > write to the chip, and when only to the reg_cache. > But since I have the gain in the same register, when the user changing the > volume, than that control don't have information about the associated DAPM > widget's state. That's why I'm saying you'll need a new control type - it'd need to know how to look at the state of a DAPM widget and decide if it should update the hardware based on that. The PGA handling code that's in current mainline (not for-2.6.35, it got removed) is an example of this. > Well, I think the core could have some basic support for similar cases, but I'm > not sure if it is possible to cover all cases in the core. I don't see any fundamental problem here - mostly this just maps on to "if the widget is powered on write this value, otherwise write the value configured by the control.". > I do think, that at least the TWL codec has to be handled in a custom way. For > now at least. > Should I add more explanation to the commit message to make the intention more > clear? Well, I was rather hoping I could convince you to make this more generic. But if that's not possible then yes, please do make the commit message clearer. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel