On Sat, Apr 19, 2008 at 4:50 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
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.
This is interesting, what is the generic jack detect feature supposed to do exactly? I ask because I just export the jack detect interrupt to userspace via input subsystem (SW_HEADPHONE_INSERT). Will it replace this switch in functionality?
regards Philipp