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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel