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