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.