[alsa-devel] [PATCH] ASoC: TWL4030: PM fix for output amplifiers
broonie at opensource.wolfsonmicro.com
Mon Mar 22 15:15:44 CET 2010
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
> 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
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
More information about the Alsa-devel