Advice on ASoC support for series of boards

Advice on ASoC support for series of boards

[Ben Dooks]

I would like some advice before I start on a project to move our
series of boards to the ASoC framework.

All the boards shared the same I2S wiring and all but one have
the same TI CODEC wired in similar configuration. The differences
are in the presence and connection of a speaker AMP (GPIO controlled).

Is there a standard method for binding an AMP to an driver, or is it
necessary to have the AMPs in the driver itself? If not, what would
people recommend to be the best example of this?

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: Advice on ASoC support for series of boards

[Mark Brown]

On Fri, May 15, 2009 at 08:34:06PM +0100, Ben Dooks wrote:

> Is there a standard method for binding an AMP to an driver, or is it
> necessary to have the AMPs in the driver itself? If not, what would
> people recommend to be the best example of this?

There's several drivers involved in an ASoC system - these things are
generally handled in the machine driver.

For power control for things like amplifiers this is done by providing
an event callback for one of the widgets for an output (eg, a
SND_SOC_DAPM_SPK()) and doing whatever is required to enable or disalbe
the device (usually updating a GPIO) in the callback.  This ensures that
the power control is integrated with DAPM power sequencing.  See the Mic
Jack handling in spitz.c for a mainline example of this.

For non-power control (eg, a mute controlled by a GPIO) a regular
control would be registered by the machine driver - the _EXT() controls
ASoC provides are designed for use here, allowing callbacks to be
registered to update GPIOs or do whatever other changes are required.
Of course, it's also possible to register normal ALSA controls as normal
without any ASoC specific stuff if desired.  Spitz also has some
examples of this.

I'm not sure if that answers your question?