[alsa-devel] [PATCH 6/6] ASoC: TWL4030: Add analog loopback support

[Peter Ujfalusi]

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 
working...

>
> > 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...

Thanks,
Péter