On Mon, 19 May 2008 19:36:55 +0100 "ext Mark Brown" <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Bias here is being used to refer to general DC offset levels on the AC > inputs and outputs of the chip - microphone bias is just one of these > levels. For a lot of codecs there's no or limited control of the > baises but some do provide fine grained control. > It came to my mind only afterwards but probably usual set_power convention fits here well, doesn't confuse with DAPM and doesn't limit to thinking only mic bias :-) > The tlv320aicx driver is fairly unusual in controlling the PLL here, > though it shouldn't cause any problems either. Incidentally, it looks > like this needs updating to reflect the support that was added for > bypassing the PLL - presumably if the PLL is bypassed then enabling it > during playback and record will consume power needlessly? > Ah, you are right. There seems to be needless PLL power-up between dapm_event and aic3x_hw_params in case of PLL bypass even the aic3x_hw_parms disables it. Also how on earth I was able to test my ASoC drivers for OMAP in case of codec slave since driver is enabling PLL only for master case. Hmm... what a hack I was using then. Seems that some fixes are needed there. > Most drivers expose clocking configuration like the PLL to machine > drivers in order to allow use of clocks generated on the codec > independently of the audio stream - if it's not needed outside of > Some integrated chips might require it as well if there is some (undocumented) interdependencies inside the integrated chip. IRCC e.g. TSC2301 keypad and touchscreen were using audio clock in some occasions. Jarkko _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
