On Sat, Apr 19, 2008 at 4:50 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
