Re: Configuring a TWL GPIO pin as an interrupt

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.