Simplifying the mixer

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


On Thu, Jun 12, 2008 at 04:08:02PM +0200, Joerg Reisenweber wrote:
> Am Do  12. Juni 2008 schrieb Mark Brown:
> > On Thu, Jun 12, 2008 at 01:09:24PM +0200, Joerg Reisenweber wrote:

> > > experienced in telecommunication electronics). My objection was there are 
> > > several mixer-controlls named "*sidetone*" that do not show up in 
> mixer-spec 
> > > in any way. 

> > I don't follow here, sorry - what's "mixer-spec"?

> Sorry, just meant the chip-spec WM8753 papers, especially 
> WM8753_control_diag.pdf

The sidetone paths are in the WM8753 datasheet, though they're not
specifically labelled in the routing diagram with that name.  See:

   http://www.wolfsonmicro.com/uploads/documents/en/WM8753.pdf

for the full datasheet.  Everything should be in there, as text if
nothing else.  Unfortunately there are so many paths that trying to put
all the names on the diagram makes the diagram illegible.

> My approach was to use the existing WM8753-driver code and just modify the 
> names of controls, add any GTA01/2 specific stuff like switching the external 
> amp hp<->spk via cpu-GPIO (clearly *NO* WM8753-domain), and rename the whole 
> thing to reflect it's a driver that's not to be used by any other hardware 
> than GTA01/2. This could easily be done by a patch, a branch or whatever way 
> you guys usually do things like this, thus any development would still happen 
> on WM8753, and the changes are included to gta0x-alsa-driver automatically.
> Dunno whether there is any SOP for things like this, no kernel-devel 
> speaking ;-)

Ah, right - see my previous mail on the subject of how the driver is
organised.  There are already GTA0x specific drivers in the OpenMoko
kernel, it's just that they're working within a framework which allows
them to reuse the code which controls the codec and CPU.  The codec and
CPU parts aren't able to function without at least some machine-specific
code specifying how they are connected together.

Like I say, I think renaming the voice and speaker controls in the codec
driver to correspond to the pin names rather than an ALSA control output
would deal with a lot of the issues you are seeing.

There's no need to copy the entire codec driver for control renames -
it's straightforward to maintian a change like that as an OpenMoko
change if you want to do it.



More information about the openmoko-devel mailing list