ASoC: Hiding unused CODEC mixer widgets in the machine driver

ASoC: Hiding unused CODEC mixer widgets in the machine driver

[Stuart Longland]

Hi all,

Work has continued on the TLV320AIC3204 CODEC driver, and there have
been a number of fixes since the last patch was published.  However,
this CODEC is a rather complicated beast to drive, some may find the
controls a little unweildy, and as such, I was wondering if the machine
driver could be used to abstract this for a given target?

It's no use abstracting this in the CODEC, because some may want to
access the functionality I'm trying to hide.

The CODEC we're using has three line inputs; which may be treated as
either three mono differential inputs, or three stereo single-ended
inputs.  There are also a couple of common-mode sources that may be
connected.  The resistances connecting these is selectable; 10k, 20k or
40k... and as such, it's possible to do some hardware mixing of the
sources inside the CODEC.

At the moment I have each of the inputs to the ADC's PGA ("MICPGA"),
with one control for each possible path... There are two ADCs, so two
PGAs... and the inputs can be connected to either the negative or
positive terminal of the PGA in many cases.  That leads to a large
number of controls (the following is from amixer):

Simple mixer control 'Left MICPGA+ Output Mixer IN1L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Left MICPGA+ Output Mixer IN1R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Left MICPGA+ Output Mixer IN2L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Left MICPGA+ Output Mixer IN3L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: '10k'
Simple mixer control 'Left MICPGA- Output Mixer CM1L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Left MICPGA- Output Mixer CM2L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Left MICPGA- Output Mixer IN2R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Left MICPGA- Output Mixer IN3R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: '10k'
[...]
Simple mixer control 'Right MICPGA+ Output Mixer IN1R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: '10k'
Simple mixer control 'Right MICPGA+ Output Mixer IN2L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Right MICPGA+ Output Mixer IN2R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Right MICPGA+ Output Mixer IN3R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: '10k'
Simple mixer control 'Right MICPGA- Output Mixer CM1R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Right MICPGA- Output Mixer CM2R',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: 'not-connected'
Simple mixer control 'Right MICPGA- Output Mixer IN1L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: '10k'
Simple mixer control 'Right MICPGA- Output Mixer IN3L',0
  Capabilities: enum
  Items: 'not-connected' '10k' '20k' '40k'
  Item0: '10k'

These controls are useful to a machine driver for implementing controls,
but they're not that friendly to an end user.  I was wondering if it was
possible to hide these controls from the userland, but expose them to
the machine driver to be presented to the user in a more meaningful
manner.  (i.e. we can have just simple mute switches for IN1 and IN3,
labelling them "handset" and "internal mic" in our device).

Or would I be better defining these controls in the machine driver?

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: ASoC: Hiding unused CODEC mixer widgets in the machine driver

[Mark Brown]

On Fri, Aug 06, 2010 at 10:18:45AM +1000, Stuart Longland wrote:

> Work has continued on the TLV320AIC3204 CODEC driver, and there have
> been a number of fixes since the last patch was published.  However,
> this CODEC is a rather complicated beast to drive, some may find the
> controls a little unweildy, and as such, I was wondering if the machine
> driver could be used to abstract this for a given target?

The machine driver shouldn't be doing this - it's too fragile in the
face of any changes in the drivers and means hard coding use cases into
the kernel which is really bad practice since it's much slower than
doing things from user space and much harder to change as new needs
arise.

Much of this should be being handled by use case management anyway, even
the controls that actually exist usefully on a given system are normally
way more detail than end applications should ever be seeing.  See

	http://www.slimlogic.co.uk/?p=40

for the API which should deal with that.  

We should still do the limiting in kernel for controls that are on paths
that can not connected be at all (since it makes life easier developing
use cases) but the major thing is the use case management.  Takashi has
a patch for hiding controls which could be built on to do this but
unfortunately it's been sitting in his sound-unstable tree rather than
included in mainline.

Re: ASoC: Hiding unused CODEC mixer widgets in the machine driver

[Liam Girdwood]

On Fri, 2010-08-06 at 12:19 +0100, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 10:18:45AM +1000, Stuart Longland wrote:
> 
> > Work has continued on the TLV320AIC3204 CODEC driver, and there have
> > been a number of fixes since the last patch was published.  However,
> > this CODEC is a rather complicated beast to drive, some may find the
> > controls a little unweildy, and as such, I was wondering if the machine
> > driver could be used to abstract this for a given target?
> 
> The machine driver shouldn't be doing this - it's too fragile in the
> face of any changes in the drivers and means hard coding use cases into
> the kernel which is really bad practice since it's much slower than
> doing things from user space and much harder to change as new needs
> arise.
> 
> Much of this should be being handled by use case management anyway, even
> the controls that actually exist usefully on a given system are normally
> way more detail than end applications should ever be seeing.  See
> 
> 	http://www.slimlogic.co.uk/?p=40
> 
> for the API which should deal with that.  
> 

Please do give UCM (Use Case Manager) a test drive. We are in the late
development / early testing phase before upstreaming (still one or two
things todo).

You will need to checkout the use-case-verb branches of :-

git://git.slimlogic.co.uk/alsa-lib.git

git://git.slimlogic.co.uk/alsa-utils.git

There is a tool called alsaucm that allows changing the use case from
the command line. Best to use it's interactive (-i) mode atm.

There is also an initial repository for UCM use case configuration files
here :-

git://git.slimlogic.co.uk/alsa-ucm-conf.git

This will show the format required to describe use cases.

Thanks

Liam 
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Use Case Manager Test Drive [Was: Re: ASoC: Hiding unused CODEC mixer widgets in the machine driver]

[Liam Girdwood]

On Fri, 2010-08-06 at 12:34 +0100, Liam Girdwood wrote:
> On Fri, 2010-08-06 at 12:19 +0100, Mark Brown wrote:
> > On Fri, Aug 06, 2010 at 10:18:45AM +1000, Stuart Longland wrote:
> > 
> > > Work has continued on the TLV320AIC3204 CODEC driver, and there have
> > > been a number of fixes since the last patch was published.  However,
> > > this CODEC is a rather complicated beast to drive, some may find the
> > > controls a little unweildy, and as such, I was wondering if the machine
> > > driver could be used to abstract this for a given target?
> > 
> > The machine driver shouldn't be doing this - it's too fragile in the
> > face of any changes in the drivers and means hard coding use cases into
> > the kernel which is really bad practice since it's much slower than
> > doing things from user space and much harder to change as new needs
> > arise.
> > 
> > Much of this should be being handled by use case management anyway, even
> > the controls that actually exist usefully on a given system are normally
> > way more detail than end applications should ever be seeing.  See
> > 
> > 	http://www.slimlogic.co.uk/?p=40
> > 
> > for the API which should deal with that.  
> > 
> 
> Please do give UCM (Use Case Manager) a test drive. We are in the late
> development / early testing phase before upstreaming (still one or two
> things todo).
> 
> You will need to checkout the use-case-verb branches of :-
> 
> git://git.slimlogic.co.uk/alsa-lib.git
> 
> git://git.slimlogic.co.uk/alsa-utils.git
> 
> There is a tool called alsaucm that allows changing the use case from
> the command line. Best to use it's interactive (-i) mode atm.
> 
> There is also an initial repository for UCM use case configuration files
> here :-
> 
> git://git.slimlogic.co.uk/alsa-ucm-conf.git
> 
> This will show the format required to describe use cases.
> 

Forgot to add that patches are most welcome.

Thanks

Liam
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: Use Case Manager Test Drive [Was: Re: ASoC: Hiding unused CODEC mixer widgets in the machine driver]

[Stuart Longland]

Hi Mark, Liam...
On 08/06/10 21:42, Liam Girdwood wrote:
> On Fri, 2010-08-06 at 12:34 +0100, Liam Girdwood wrote:
>> On Fri, 2010-08-06 at 12:19 +0100, Mark Brown wrote:
>>> The machine driver shouldn't be doing this - it's too fragile in the
>>> face of any changes in the drivers and means hard coding use cases into
>>> the kernel which is really bad practice since it's much slower than
>>> doing things from user space and much harder to change as new needs
>>> arise.
>>
>> Please do give UCM (Use Case Manager) a test drive. We are in the late
>> development / early testing phase before upstreaming (still one or two
>> things todo).
>>
>> You will need to checkout the use-case-verb branches of :-
>>
>> git://git.slimlogic.co.uk/alsa-lib.git
>>
>> git://git.slimlogic.co.uk/alsa-utils.git
>>
>> There is a tool called alsaucm that allows changing the use case from
>> the command line. Best to use it's interactive (-i) mode atm.
>>
>> There is also an initial repository for UCM use case configuration files
>> here :-
>>
>> git://git.slimlogic.co.uk/alsa-ucm-conf.git
>>
>> This will show the format required to describe use cases.
>>
> 
> Forgot to add that patches are most welcome.

No worries... I can see there being possible issues with the machine
driver being highly sensitive to changes to the CODEC driver, I was just
curious if there was some mechanism for abstracting this.

However, a userspace solution will probably work well... I'll have a
look and report back any findings.  How close is this to being merged
into the main alsa-lib and alsa-utils trees?

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: Use Case Manager Test Drive [Was: Re: ASoC: Hiding unused CODEC mixer widgets in the machine driver]

[Liam Girdwood]

On Sun, 2010-08-08 at 09:07 +1000, Stuart Longland wrote:
> Hi Mark, Liam...
> On 08/06/10 21:42, Liam Girdwood wrote:
> > On Fri, 2010-08-06 at 12:34 +0100, Liam Girdwood wrote:
> >> On Fri, 2010-08-06 at 12:19 +0100, Mark Brown wrote:
> >>> The machine driver shouldn't be doing this - it's too fragile in the
> >>> face of any changes in the drivers and means hard coding use cases into
> >>> the kernel which is really bad practice since it's much slower than
> >>> doing things from user space and much harder to change as new needs
> >>> arise.
> >>
> >> Please do give UCM (Use Case Manager) a test drive. We are in the late
> >> development / early testing phase before upstreaming (still one or two
> >> things todo).
> >>
> >> You will need to checkout the use-case-verb branches of :-
> >>
> >> git://git.slimlogic.co.uk/alsa-lib.git
> >>
> >> git://git.slimlogic.co.uk/alsa-utils.git
> >>
> >> There is a tool called alsaucm that allows changing the use case from
> >> the command line. Best to use it's interactive (-i) mode atm.
> >>
> >> There is also an initial repository for UCM use case configuration files
> >> here :-
> >>
> >> git://git.slimlogic.co.uk/alsa-ucm-conf.git
> >>
> >> This will show the format required to describe use cases.
> >>
> > 
> > Forgot to add that patches are most welcome.
> 
> No worries... I can see there being possible issues with the machine
> driver being highly sensitive to changes to the CODEC driver, I was just
> curious if there was some mechanism for abstracting this.
> 
> However, a userspace solution will probably work well... I'll have a
> look and report back any findings.  How close is this to being merged
> into the main alsa-lib and alsa-utils trees?
> 

We are aiming for sometime in the next two weeks. There are still
roughly two things that need fixing:-

1) Drop the control ID from the use case configuration files. i.e.

In order to enable the 'DL1 Mixer Multimedia' path we have a config like

73:'DL1 Mixer Multimedia':1:1

this would just become

'DL1 Mixer Multimedia':1:1

This way we are not reliant on ID numbers that can easily change when
driver updates occur (something that is catching me atm with a new
driver). The control names are always very constant and unique though.

2) Add a small shared memory segment to store state information for
multiple client access.

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk