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

[Mark Brown]

On Tue, May 20, 2008 at 12:53:25PM +0300, Jarkko Nikula wrote:
> "ext Mark Brown" <broonie at opensource.wolfsonmicro.com> wrote:

> > 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 :-)

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. 

> 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?

> > 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.

Yeah, some of these chips would benefit from the clock API being easier
to use for things outside the SoC, at least for the non-codec features.