Configuring a TWL GPIO pin as an interrupt

Configuring a TWL GPIO pin as an interrupt

[Lopez Cruz, Misael]

Hi,

I'm interested in bringing headset detection feature for audio. The detection is done through TWL GPIO_2. How can I configure a GPIO pin to generate an interrupt? Is there any API? Could you please point out another driver using that functionality so I can use as reference?

-Misa

Re: Configuring a TWL GPIO pin as an interrupt

[Felipe Balbi]

On Fri, Feb 20, 2009 at 08:27:54PM -0600, Lopez Cruz, Misael wrote:
> Hi,
> 
> I'm interested in bringing headset detection feature for audio. The detection is done through TWL GPIO_2. How can I configure a GPIO pin to generate an interrupt? Is there any API? Could you please point out another driver using that functionality so I can use as reference?

gpio_request(GPIO_NUMBER, "Headset IRQ");
gpio_direction_input(GPIO_NUMBER);
request_irq(client->irq, lm8323_irq, flags | IRQF_SHARED, DRIVER_NAME, dev);

that should do it :-)

see that GPIO_NUMBER will be gpio_base + 2, base is board-specific

-- 
balbi

Re: Configuring a TWL GPIO pin as an interrupt

[David Brownell]

On Friday 20 February 2009, Felipe Balbi wrote:
> On Fri, Feb 20, 2009 at 08:27:54PM -0600, Lopez Cruz, Misael wrote:
> > Hi,
> > 
> > I'm interested in bringing headset detection feature for audio. The
> > detection is done through TWL GPIO_2. How can I configure a GPIO pin
> > to generate an interrupt? Is there any API? Could you please point
> > out another driver using that functionality so I can use as reference?   

I don't think there is one.  I hacked my Beagleboard to test
those ... Rev B boards don't have EHCI, so GPIO-1 is easily
available.

In the setup() callback for the TWL4030 GPIOs:

{
  int GPIO_NUMBER = gpio_base + 2;

> gpio_request(GPIO_NUMBER, "Headset IRQ");
> gpio_direction_input(GPIO_NUMBER);

  lm8323_board_info.irq = gpio_to_irq(GPIO_NUMBER);
  ... something registers this board_info ...

  ...
  return 0;
}

and then later the lm8323 driver will use that IRQ:

> request_irq(client->irq, lm8323_irq, flags | IRQF_SHARED, DRIVER_NAME, dev);
> 
> that should do it :-)
> 
> see that GPIO_NUMBER will be gpio_base + 2, base is board-specific

..... and hence client->irq is also board-specific,
which is why it needs to be set up

RE: Configuring a TWL GPIO pin as an interrupt

[Lopez Cruz, Misael]

> > I'm interested in bringing headset detection feature for audio. The
> > detection is done through TWL GPIO_2. How can I configure a GPIO pin
> > to generate an interrupt? Is there any API? Could you please point
> > out another driver using that functionality so I can use as reference?

>In the setup() callback for the TWL4030 GPIOs:
> {
>  int GPIO_NUMBER = gpio_base + 2;
> gpio_request(GPIO_NUMBER, "Headset IRQ");
> gpio_direction_input(GPIO_NUMBER);
>  lm8323_board_info.irq = gpio_to_irq(GPIO_NUMBER);
>  ... something registers this board_info ...
>  return 0;
> }
>
> and then later the lm8323 driver will use that IRQ:
>
> request_irq(client->irq, lm8323_irq, flags | IRQF_SHARED, DRIVER_NAME, dev);
>
> that should do it :-)
>
> see that GPIO_NUMBER will be gpio_base + 2, base is board-specific
>
> .... and hence client->irq is also board-specific,
> which is why it needs to be set up

In the particular case of ALSA SoC, could the machine/board driver be a better place to handle all GPIO/IRQ configuration? That driver also contains only board specific code.

Re: Configuring a TWL GPIO pin as an interrupt

[David Brownell]

On Sunday 22 February 2009, Lopez Cruz, Misael wrote:
> In the particular case of ALSA SoC, could the machine/board driver
> be a better place to handle all GPIO/IRQ configuration? That driver
> also contains only board specific code.  

It'd be best of the ASoC stuff could sit with all the other
board-specfic init code, in arch/*/mach-*/board-*.c files,
but I understand those interfaces are not yet stable enough
to support that ... that's why they're in sound/soc/*/*.c
files instead.

In any case ... everything I said still stands.  If you're
doing this for ASoC, you'll need some way to pass data
to the ASoC board-specific code from normal board-specific
code, since some of the relevant config data is not static.

The current ASoC model seems to be biased towards static
configurations.  Notice how it's got to create its own
platform_device nodes ... it can't easily use the standard
mechanisms for associating platform_data or archdata with
those nodes, ditto clocks.

- dave

Re: Configuring a TWL GPIO pin as an interrupt

[Lopez Cruz, Misael]

> On Sunday 22 February 2009, Lopez Cruz, Misael wrote:
> > In the particular case of ALSA SoC, could the machine/board 
> > driver be a better place to handle all GPIO/IRQ configuration?
> > That driver also contains only board specific code.
> 
> It'd be best of the ASoC stuff could sit with all the other 
> board-specfic init code, in arch/*/mach-*/board-*.c files, 
> but I understand those interfaces are not yet stable enough 
> to support that ... that's why they're in sound/soc/*/*.c 
> files instead.
> 
> In any case ... everything I said still stands.  If you're 
> doing this for ASoC, you'll need some way to pass data to the 
> ASoC board-specific code from normal board-specific code, 
> since some of the relevant config data is not static.

I think that if I move the platform_device registration from machine driver to board file I can append jack detection information (gpio pin, irq) through "platform_data" of "dev" field in platform_device structure. And then in the "probe" part in ASoC machine driver I can receive it.

Could that be correct? Any other better/standard option?

> The current ASoC model seems to be biased towards static 
> configurations.  Notice how it's got to create its own 
> platform_device nodes ... it can't easily use the standard 
> mechanisms for associating platform_data or archdata with 
> those nodes, ditto clocks.

Re: Configuring a TWL GPIO pin as an interrupt

[Mark Brown]

On Mon, Feb 23, 2009 at 04:11:04PM -0600, Lopez Cruz, Misael wrote:

[Please fix your mail client to wrap lines at ~80 characters, it makes
your mails much easier to work with.]

> I think that if I move the platform_device registration from machine
> driver to board file I can append jack detection information (gpio
> pin, irq) through "platform_data" of "dev" field in platform_device
> structure. And then in the "probe" part in ASoC machine driver I can
> receive it.

Yes, though unless you actually have a generic ASoC machine driver that
works over multiple boards it's as well just skipping the platform data.
Look at s3c24xx_uda134x for an example of doing this.

If these are CPU side GPIOs that you're talking about you'll also want
to write the standard utility for using gpiolib for jack detection that
I've not got round to doing yet :)

Re: Configuring a TWL GPIO pin as an interrupt

[Lopez Cruz, Misael]

> If these are CPU side GPIOs that you're talking about you'll 
> also want to write the standard utility for using gpiolib for 
> jack detection that I've not got round to doing yet :)

The GPIOs belong to a submodule of TWL4030, but they are configured
using standard gpiolib.

About adding GPIO functionality to jack detection, if the right
place to request GPIOs and set its data direction is in board files
(arch/*/mach-*/board-*.c), then there won't be much to do in jack
code, only the irq request. Unless we move request and data direction
setting to jack detection layer.

-Misa

Re: Configuring a TWL GPIO pin as an interrupt

[Mark Brown]

On Tue, Feb 24, 2009 at 11:37:47AM -0600, Lopez Cruz, Misael wrote:

> About adding GPIO functionality to jack detection, if the right
> place to request GPIOs and set its data direction is in board files
> (arch/*/mach-*/board-*.c), then there won't be much to do in jack
> code, only the irq request. Unless we move request and data direction
> setting to jack detection layer.

No, do that in the jack code.  The board code should only be doing
things like putting the pins into GPIO mode (if that's not the default)
and any other steps required to ensure that they don't do anything like
consume a lot of power without the audio driver loaded.

Re: Configuring a TWL GPIO pin as an interrupt

[Mark Brown]

On Mon, Feb 23, 2009 at 12:07:25AM -0600, Lopez Cruz, Misael wrote:

> In the particular case of ALSA SoC, could the machine/board driver be a better place to handle all GPIO/IRQ configuration? That driver also contains only board specific code.--
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Normally the arch/arm code would configure any multi-function pins (this
is normally required for lowest power consumption) and the actual IRQ
requesting and so on would be done by the machine and/or codec drivers
(depending on how exactly the hardware implements this).

Re: Configuring a TWL GPIO pin as an interrupt

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]


Op 21 feb 2009, om 03:39 heeft Felipe Balbi het volgende geschreven:

> On Fri, Feb 20, 2009 at 08:27:54PM -0600, Lopez Cruz, Misael wrote:
>> Hi,
>>
>> I'm interested in bringing headset detection feature for audio. The  
>> detection is done through TWL GPIO_2. How can I configure a GPIO  
>> pin to generate an interrupt? Is there any API? Could you please  
>> point out another driver using that functionality so I can use as  
>> reference?
>
> gpio_request(GPIO_NUMBER, "Headset IRQ");
> gpio_direction_input(GPIO_NUMBER);
> request_irq(client->irq, lm8323_irq, flags | IRQF_SHARED,  
> DRIVER_NAME, dev);
>
> that should do it :-)

Don't forget to use the proper API for it: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/sound/jack.h;hb=master

regards,

Koen

[-- Attachment #2: Dit deel van het bericht is digitaal ondertekend --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: Configuring a TWL GPIO pin as an interrupt

[Mark Brown]

On Sat, Feb 21, 2009 at 11:33:43AM +0100, Koen Kooi wrote:

> Don't forget to use the proper API for it: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/sound/jack.h;hb=master

Yes, please, but note that there's an ASoC wrapper for that in sound/soc
in -next which should be used instead of the raw jack reporting API.  It
separates the definition of the jack from the detection mechanisms since
the wiring is always going to be board specific - eg, headphone and
microphone may be exposed on one physical jack or as separate jacks.