Simplifying the mixer

Mark Brown broonie at opensource.wolfsonmicro.com
Thu Jun 12 16:59:55 CEST 2008


On Thu, Jun 12, 2008 at 04:24:36PM +0200, Joerg Reisenweber wrote:

> So this split into different parts assumes the functions/symbols/*names* 
> exported by the codec driver are valid for all sorts of hw-implementation. To 
> me it's evident this is not the case. Looks like a design flaw. Names of alsa 

The approach most ASoC drivers take is to use pin-specific names rather
than names that make assumptions about the configuration of the system
here - most embedded systems have tailored user space stacks which mean
that control names are rarely seen in a user interface by anyone except
developers so the actual names aren't such a big deal.

The generic solution to this is the scenario API[1]; as I said in a
previous mail it supports respecifying the functions of controls at run
time depending on the current use case.

> controls should be defined at a higher abstraction level that's obviously 
> specific to the actual hw, this means machine driver (which by the way should 
> know about the names of the pins as well as about whether they are connected. 

It does know about the pin names (indeed, the connections are specified
in terms of the pin names) - what it doesn't do is rename the controls.
Support for that would be an interesting addition, though doing it in
user space allows for more flexibility for systems where the functions
of controls mean they need to be renamed dynamically at runtime.

[1] http://opensource.wolfsonmicro.com/node/14



More information about the openmoko-devel mailing list