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

[Jarkko Nikula]

On Fri, 23 May 2008 00:34:15 +0100
"ext Mark Brown" <broonie at opensource.wolfsonmicro.com> wrote:

> > 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 :-)
> 
> Hrm, depends - I can see people viewing it as an alternative to DAPM.
> Which, of course, you can do but it's not the Right Way.
> 
> This API really is intended for configuring biases and things like
> them. Maintaining biases is both power and output quality sensitive
> so it's beneficial for the core to be able to control them
> specifically.  Other things are expected to be managed via either
> DAPM, feature-specific APIs (eg, the PLLs) or the regular power
> management interface.  From that point of view it would be good to
> keep the bias name in at least the constants. 
> 
Ok, now I see. That would also clarify what's expected from this
callback and what not.

Now snd_soc_dapm_device_event calling codec->dapm_event seems to be
stream centric only. How about the case if only bypass path is active?
Also then biases should be managed?

> > 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.
> 
> Is the codec able to run entirely from the clocks on the audio bus,
> perhaps?
> 
Yes it can but it requires to reconfigure input clock pin. Actually I
found a hack below from my early development tree :-)

-		if (aic3x->master) {
+		if (1/*aic3x->master*/) {
 			/* enable pll */

This needs to be fixed and also move PLL control out of dapm_event
callback.


Jarkko