[pulseaudio-discuss] [alsa-devel] Per board ucm files on x86?

[Takashi Iwai]

On Mon, 11 Dec 2017 15:18:37 +0100,
Hans de Goede wrote:
> 
> 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,

Argh, that beast...

> 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 ?   :

Yes, it would work.


Takashi

> 
> 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
>