Mark,
I'm thinking of upstreaming ASoC support for some of the other Tegra boards
that got added later in 2.6.39; Seaboard, Kaen, and Aebl.
[Ventana could also be supported, but it's identical to Harmony. I imagine
people will want Toshiba AC100 and Trimslice support in the not-too-
distant future, but I don't have schematics for those boards at present]
This raises a couple questions:
1)
Currently, the Harmony machine driver gets all its GPIO information from
platform data defined in arch/arch/mach-tegra/include/mach/harmony_audio.h.
Supporting new machines would entail one of:
a) Creating a new header for each new machine (or set of similar machines).
This could mean many headers pretty quickly.
b) Expanding that structure to include extra fields, thus making it generic
enough to support any Tegra machine, which would probably also entail renaming
the file to not be Harmony-specific. Some GPIO fields would be optional (i.e.
initialized to -1) if a feature wasn't available on a given board.
c) Perhaps switch to using platform_get_resource() to retrieve the data rather
than custom per-machine/SoC structures, although that'd require adding new
resource types for GPIOs etc.
That said, I noticed that all(?) the other machine drivers simply use
hard-coded GPIO numbers (sometimes defined locally, probably sometimes from
machine header files), rather than having the values passed in through
platform_data. This eliminates the need for platform_data structures etc.
Is this simply a legacy because ASoC machine drivers weren't able to be
first-class platform_devices, or is this still an acceptable style?
I'm tempted to convert the Tegra Harmony driver to this style (but including
headers to define the GPIO names instead of duplicating definitions in the
machine file), and also use it for new machines.
2)
Seaboard has a couple of derivatives which are very similar, but do have
some differences in the audio path and elsewhere. In the ChromeOS kernel,
we have a single ASoC machine driver covering Seaboard and two derivatives,
with conditional code. I've placed an example at the end of this mail. Do
you have a preference for having separate files for each machine without the
conditional code v.s. a single machine driver with a lot of conditional code?
If we go the conditional route, it might even be possible to merge the
Harmony and Seaboard machine drivers into one.
Thanks for any feedback.
Example from static int seaboard_asoc_init():
ret = gpio_request(pdata->gpio_spkr_en, "spkr_en");
if (ret) {
dev_err(card->dev, "cannot get spkr_en gpio\n");
return ret;
}
seaboard->gpio_requested |= GPIO_SPKR_EN;
gpio_direction_output(pdata->gpio_spkr_en, 0);
if (pdata->gpio_hp_mute != -1) {
ret = gpio_request(pdata->gpio_hp_mute, "hp_mute");
if (ret) {
dev_err(card->dev, "cannot get hp_mute gpio\n");
return ret;
}
seaboard->gpio_requested |= GPIO_HP_MUTE;
gpio_direction_output(pdata->gpio_hp_mute, 0);
}
...
if (machine_is_seaboard()) {
snd_soc_dapm_add_routes(dapm, seaboard_audio_map,
ARRAY_SIZE(seaboard_audio_map));
} else if (machine_is_kaen()) {
snd_soc_dapm_add_routes(dapm, kaen_audio_map,
ARRAY_SIZE(kaen_audio_map));
} else {
snd_soc_dapm_add_routes(dapm, aebl_audio_map,
ARRAY_SIZE(aebl_audio_map));
}
...
snd_soc_dapm_nc_pin(dapm, "IN1L");
if (machine_is_kaen())
snd_soc_dapm_nc_pin(dapm, "IN1R");
snd_soc_dapm_nc_pin(dapm, "IN2L");
if (!machine_is_kaen())
snd_soc_dapm_nc_pin(dapm, "IN2R");
snd_soc_dapm_nc_pin(dapm, "IN2L");
snd_soc_dapm_nc_pin(dapm, "IN3R");
snd_soc_dapm_nc_pin(dapm, "IN3L");
if (machine_is_aebl()) {
snd_soc_dapm_nc_pin(dapm, "LON");
snd_soc_dapm_nc_pin(dapm, "RON");
snd_soc_dapm_nc_pin(dapm, "ROP");
snd_soc_dapm_nc_pin(dapm, "LOP");
} else {
snd_soc_dapm_nc_pin(dapm, "LINEOUTR");
snd_soc_dapm_nc_pin(dapm, "LINEOUTL");
}
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
