[alsa-devel] [PATCH] ASoC: Clarify API for bias configuration

Jarkko Nikula jarkko.nikula at nokia.com
Tue May 20 11:53:25 CEST 2008

On Mon, 19 May 2008 19:36:55 +0100
"ext Mark Brown" <broonie at opensource.wolfsonmicro.com> 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.


More information about the Alsa-devel mailing list