> 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.-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
