[alsa-devel] [PATCH 6/6] ASoC: TWL4030: Add analog loopback support
peter.ujfalusi at nokia.com
Tue Jan 27 15:28:35 CET 2009
On Tuesday 27 January 2009 16:03:16 ext Mark Brown wrote:
> This one should be dealable with in-kernel without any work by
> applications - WM8350 does a similar dance (for different reasons),
> providing a shadow volume control while some of the amplifiers are
> powered off.
I'm going to check the code. But I think the driver still needs to keep on
track of the bypass switch states in order to do the right thing.
> > But than I played a bit with the registers, enabled the bypass (while the
> > PLL was off) and the readings were: 0.020 A, in short:
> > bypass on + PLL on = 0.016 A
> > bypass on + PLL off = 0.020 A
> I suspect the increased power consumption here is due to the PLL being
> required to clock the DAC properly. Or you've transposed the figures :)
I have checked it several times, the numbers are correct. Probably the DAC
clocking, but how it is working without the PLL on - because the bypass was
> > bypass off + PLL on = 0.006 A
> > bypass off + PLL off = 0.002 A
> > Grrr, and I gave up. Oh, and we don't have control for the PLL (it is
> > enabled
> > all the time at the moment). I was thinking to use the SND_SOC_DAPM_PRE
> > and SND_SOC_DAPM_POST for it but I don't know how to use those.
> Just declare them as widgets - the event function you supply will be
> called back when the state changes. The event function interface is the
> same as for the _E versions of normal DAPM controls, see WM8900 for one
> example of how to use them.
I'll take a look.
> > So I thought that I will write it in a way I have sent it and revisit
> > later, when I (or someone else) have better idea to handle this.
> I suspect that if the core were able to automatically push the codec
> down into BIAS_OFF as well as BIAS_STANDBY that'd probably be enough to
> deal with the issue? Probably in concert with fixing the core to bring
> the codec up to BIAS_ON when bypass paths are active. It looks like
> what you're implementing here is a combination of the fixes for those
> two issues.
> My main concern is that it feels like this is breaking the model that
> the core has of what the codec driver should be doing - I think some
> (much?) of this is a case of the core needing more functionality and
> that if that is the case then we'd be better off not carrying driver
> specific workarounds in case they get broken when things are fixed in
> the core.
Right, I agree. I'll send this last patch back to the drawing board ;)
> > Sorry for the long and most probably boring details...
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > I can wait till it gets there and send the series on top of it.
> Like I said, I've already applied all your other patches.
I missunderstand that, sorry, I'll focus on the analog bypass redesign than...
More information about the Alsa-devel