On Tue, Jan 27, 2009 at 03:05:34PM +0200, Peter Ujfalusi wrote:
Than if the bypass got disabled it jumped back to 0.01 A. After a bit of debugging I found the reason: We have outputs with dedicated gain controls (PreDriveL/R, HeadsetL/R, CarkitL/R, Earpiece), they have to be put to power-down mode (gain bits to 0). We do have volume controls for these, they are not in DAPM, but they can be modified. But now the problem is that something has to track the bypass states in userspace: if the bypass disabled, than has to mute all outputs, when enabled, it has to remember, what was the original gain for the outputs. So it's going to be a mess.
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.
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 :)
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
Normally all the PLL control is punted to the machine driver since the clocking configuration tends to be system dependant, especially when the codec is the clock master. Then again, the TI codecs seem to be fairly inflexible in this regard so perhaps it doesn't make sense there. If there's only one configuration possible then there's no sense bothering the machine drivers with it.
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.
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.
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.