Re: [alsa-devel] Configuring a TWL GPIO pin as an interrupt
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.
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 :)
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
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.
participants (2)
-
Lopez Cruz, Misael -
Mark Brown