On 04/20/2016 10:51 AM, Petr Kulhavy wrote:

On 20.04.2016 10:33, Lars-Peter Clausen wrote:

...

On 04/20/2016 10:03 AM, Petr Kulhavy wrote:

...

Hello,

I'm writing a driver for ASoC "sound card" hardware which uses CPU GPIO to mute/unmute an analogue amplifier and another GPIO to control an analogue switch for line/mic switching. Is there an abstraction in ALSA to model this kind of hardware?

There is no abstraction. Use controls and/or DAPM and the standard GPIO API, if you grep the sources you'll find a few examples of drivers using GPIOs to mute amplifiers and similar (e.g. qi_lb60).

• Lars

Thanks, Lars, for the good pointers! I will check that out.

Is there also a way to map GPIO to a control which then appears e.g. in alsamixer? That would be useful for the mic/line selection.

Rather than exposing the GPIO itself you'd expose the logical function of the GPIO. E.g. in your case a ENUM control that allows to switch between microphone and capture and in the background this sets the GPIO according to the selection.

- Lars

On 04/20/2016 11:47 AM, Petr Kulhavy wrote:

On 20.04.2016 11:06, Lars-Peter Clausen wrote:

...

On 04/20/2016 10:51 AM, Petr Kulhavy wrote:

...

Thanks, Lars, for the good pointers! I will check that out.

Is there also a way to map GPIO to a control which then appears e.g. in alsamixer? That would be useful for the mic/line selection.

Rather than exposing the GPIO itself you'd expose the logical function of the GPIO. E.g. in your case a ENUM control that allows to switch between microphone and capture and in the background this sets the GPIO according to the selection.

I understand that, my question was more how to hook the enum to a function rather to a codec register?

You can use SOC_ENUM_EXT() to create the control. This macro takes a get and a put callback where you can manipulate the state of the GPIO. And then just register the control with the card.