[alsa-devel] [PATCH 04/10] include: platform_data: Platform data header for OMAP4 ASoC audio

[Peter Ujfalusi]

Hi Mark, Tony,

On 12/17/2011 11:36 AM, Mark Brown wrote:
>> Yes this is planed for the Dtree support, but the aim here is to get working 
>> audio on PandaBoard as well with upstream kernel.
> 
> Just do it right to start off with, the device tree bindings should
> normally map closely onto the platform data where platform data exists
> already and you're going to have to have the code structured by feature
> anyway.

I do not want to 'bloat' the board files under mach-omap2 for sdp4430,
Panda with string arrays to pass the DAPM routing from there to the ASoC
machine driver to construct the board specific routing.
All of this sort of thing will go away with DT in the future (including
the platform_data).

I planed to do this similar way as it is done for the tegra_wm8903.c
machine driver:
- without DT blob we support only sdp4430, Panda boards
- with DT we will have similar mapping as tegra is planning to have.

If Tony is fine to add text array constructed under mach-omap2 which
describes the ASoC DAPM mapping, I can do it, but AFAIK we should
minimize the code size in that part of the kernel.

To pass the routing from the board files I need to modify the platform_data:

struct omap-abe-twl6040-connection {
	const char *sink;
	const char *source;
};

struct omap_abe_twl6040_data {
	char *card_name;
	enum board_type board;
	struct omap-abe-twl6040-connection *route;
	int num_of_routes;
};

In board files:
struct omap-abe-twl6040-connection sdp4430_asoc_route[] = {
	{"MAINMIC", "Main Mic Bias"},
	{"SUBMIC", "Main Mic Bias"},
	{"Main Mic Bias", "Ext Mic"},
	...
	16 string pair.
}

If this is acceptable by Tony, I can do this.

To describe the routing via feature flags is not really practical due to
the possible variation I can think of.

Tony: what do you think? Is this something that is allowed to do under
plat-omap2?

-- 
Péter