Hi,
On 11-12-17 14:40, Takashi Iwai wrote:
On Mon, 11 Dec 2017 13:30:35 +0100,
Hans de Goede wrote:
Hi All,
This weekend I've created a modified ucm config based on:
https://github.com/plbossart/UCM/tree/master/chtrt5645
For a board which has a single speaker connected to the
left channel (standard mono speaker setup) and a stereo
headphone jack with working jack detection.
I've been unable to come up with a ucm file which allows
selecting between a "Stereo Speaker + Headphone" vs
"Mono Speaker + Headphone" output profile.
https://github.com/plbossart/UCM/tree/master/byt-rt5640
has "Mono Speaker", "Stereo Speaker" and "Headphone"
profiles but does not auto-switch between Headphone
and speaker based on jack detection, I've been unable to
allow selecting either stereo or mono speaker while
keeping auto-switching to/from the headphones.
But thinking more about this I don't think that having
"Stereo Speaker + Headphone" and "Mono Speaker + Headphone"
profiles is the answer. Profiles make sense on machines with
a bunch of outputs where we don't no what the user is going
to plug in, but in this case the stereo vs mono speaker
distinction is a clear property of the device, which we
should IMHO autodetect based on the device-model.
So I think we need a way to have different ucm files per board,
so instead of loading /usr/share/ucm/chtrt5645/*.conf on my
device, alsa should try to load /usr/share/ucm/chtrt5645-<boardname>/*.conf
Specifically I'm thinking about using udev + hwdb (dmi string)
matching to set an ALSA_UCM_NAME udev property.
If the consensus is that this is a good idea I can take a shot
at writing patches for this (in my spare time mostly), the
downside of this approach is it would cause a dependency on
libudev for the alsa ucm code.
You don't need to patch, I guess. The recent code should set a string
generated from DMI as the longname of the card, and alsa-lib UCM
parser prefers the longname to the driver name field. That is,
/usr/share/ucm/$LONGNAME/$LONGNAME.conf would be read at first, then
/usr/share/ucm/$DRIVER/$DRIVER.conf is used as fallback.
Interesting unfortunately the DMI data on the GPD win / pocket
is too generic for snd_soc_set_dmi_name() to work, but we
already have a machine specific dmi-match in the codec driver,
so would something like this be acceptable to set a unique
longname ? :
diff --git a/include/sound/rt5645.h b/include/sound/rt5645.h
index d0c33a9972b9..f218c742f08e 100644
--- a/include/sound/rt5645.h
+++ b/include/sound/rt5645.h
@@ -25,6 +25,9 @@ struct rt5645_platform_data {
bool level_trigger_irq;
/* Invert JD1_1 status polarity */
bool inv_jd1_1;
+
+ /* Value to asign to snd_soc_card.long_name */
+ const char *long_name;
};
#endif
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index f020d2d1eef4..60e5f4cda18c 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3394,6 +3394,9 @@ static int rt5645_probe(struct snd_soc_codec *codec)
snd_soc_dapm_sync(dapm);
}
+ if (rt5645->pdata.long_name)
+ codec->component.card->long_name = rt5645->pdata.long_name;
+
rt5645->eq_param = devm_kzalloc(codec->dev,
RT5645_HWEQ_NUM * sizeof(struct rt5645_eq_param_s), GFP_KERNEL);
@@ -3624,6 +3627,7 @@ static const struct dmi_system_id dmi_platform_intel_broadwell[] = {
static const struct rt5645_platform_data gpd_win_platform_data = {
.jd_mode = 3,
.inv_jd1_1 = true,
+ .long_name = "gpd-win-pocket-rt5645",
};
static const struct dmi_system_id dmi_platform_gpd_win[] = {
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
