[alsa-devel] [PATCH] asoc tlv320aic3x: add GPIO support

[Mark Brown]

On Sat, Apr 19, 2008 at 02:18:38PM +0200, Daniel Mack wrote:
> On Sat, Apr 19, 2008 at 12:24:26PM +0100, Mark Brown wrote:

> > The usual approach is to have multi-function pins on CODECs are
> > controlled by the ASoC codec driver based on configuration supplied by
> > the machine driver. 

> I was looking for a mechanism to pass such information around but didn't
> manage to find any. Which way would you suggest? The approach in my
> patch causes as less overhead as possible at it simply reuses the asoc's
> widgets, I though.

The usual thing would be to have your CODEC driver provide its own API
which users can call directly.

> > Their use tends to be heavily constrained by the
> > board design so it usually makes more sense to let the machine driver
> > set things up and deal with exposing controls for any configurability
> > that user space can exercise.

> Ok, but why not let the codec driver expose all the functionality it can
> offer for setting up a certain GPIO and use this alsa control either
> from user space or from the asoc machine part? I think that's the most
> flexible way at all, no?

The CODEC driver can't safely give user space control of multi-function
pins in general, including GPIOs, since their usage depends very
strongly on how they have been connected to the system.  At best much of
the functionality won't be useful on a given board due to a lack of
appropriate connections.  At worst the consequences of misusing them can
include things like causing one or more chips in the system to fall
over, perhaps even the entire system.  For example, if you've got two
chips each trying to drive a signal to different voltages then it is
possible that one or both of them will do something like attempt to
consume too much power and cause supplies to collapse.

It's OK for the kernel to be able to misconfigure things and control of
these features is very useful so it's good to provide it.  The issue is
letting user space get involved unless the machine driver has said that
it's safe to do so.

> And when it comes to setting or getting a GPIO's state I see no way to
> access such special purpose functions of the codec driver. At least,
> 'struct snd_soc_codec' doesn't give me any hints how to achive that.

Like I say, export a CODEC specific API for it.  The machine driver
already needs to know which CODEC and SoC it is working with and how
they are connected in a given system in order to set up the audio
connections.  In some cases the API calls can be avoided - for example,
if there is an I2S port on multi-function pins then configuring that I2S
port could implicitly configure the multi-function pins to enable that
port.

> > Most of the time when GPIO lines on CODECs are used they tend to be
> > controlling other bits of the audio subsystem anyway (eg, power for
> > simple amplifiers) - most SoCs have plenty of GPIOs on-board and they're
> > usually much easier to work with due to being memory mapped on the CPU.

> Well, I didn't implement that just because it wasn't done yet ;) In the
> setup I'm working on, one GPIO is needed to control peripherals next to
> it in the board layout where routing constraints become part of the
> game. And the other one is connected to one of the processor's GPIO to
> catch an interrupt from the AIC3x when a headset is plugged in. Thus, we
> really need to support them both. Others may have different use for
> them, just have a look at the possible functions of those GPIOs.

Those sound like exactly the sort of audio subsystem usages that I was
talking about - things that have fixed functions on a given board and
which the machine driver should be able to know how to set up in a way
that makes sense for the system.

In the case of jack detect I'm actually currently working on a
generalisation of that since it's such a common feature.  I hope to have
something in the next week or two but it depends on my other work.