On Fri, 23 May 2008 00:34:15 +0100
"ext Mark Brown" <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
