| Message ID | 20191025123038.19728-1-perex@perex.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ASoC: change 'HDMI/DP, pcm=' to 'HDMI/DP, pcm=' Jack control names | expand |
On Fri, 25 Oct 2019 14:30:38 +0200, Jaroslav Kysela wrote: > > There is an inconsistency in the names for the HDMI/DP Jack control > names between some ASoC drivers and the HDA HDMI driver which > introduced this naming in 2011. > > There might be an impact for the user space (UCM). I will fix > the UCM configurations when this patch is applied. > > Signed-off-by: Jaroslav Kysela <perex@perex.cz> > Cc: Mark Brown <broonie@kernel.org> > Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Yes, that's a known problem, and I left them so far just for keeping the already existing stuff working. Won't this break the current Chromebooks user-space? thanks, Takashi > --- > Documentation/sound/designs/control-names.rst | 5 +++-- > sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- > sound/soc/intel/boards/bxt_rt298.c | 2 +- > sound/soc/intel/boards/glk_rt5682_max98357a.c | 2 +- > sound/soc/intel/boards/kbl_da7219_max98357a.c | 2 +- > sound/soc/intel/boards/kbl_da7219_max98927.c | 2 +- > sound/soc/intel/boards/kbl_rt5660.c | 2 +- > sound/soc/intel/boards/kbl_rt5663_max98927.c | 2 +- > sound/soc/intel/boards/skl_hda_dsp_common.c | 2 +- > sound/soc/intel/boards/skl_nau88l25_max98357a.c | 2 +- > sound/soc/intel/boards/skl_nau88l25_ssm4567.c | 2 +- > sound/soc/intel/boards/skl_rt286.c | 2 +- > sound/soc/intel/boards/sof_rt5682.c | 2 +- > 13 files changed, 15 insertions(+), 14 deletions(-) > > diff --git a/Documentation/sound/designs/control-names.rst b/Documentation/sound/designs/control-names.rst > index 7fedd0f33cd9..a5f6e3842df8 100644 > --- a/Documentation/sound/designs/control-names.rst > +++ b/Documentation/sound/designs/control-names.rst > @@ -50,7 +50,7 @@ Internal internal > > SOURCE > ~~~~~~ > -=================== ================================================= > +=================== =================================================== > Master > Master Mono > Hardware Master > @@ -92,7 +92,8 @@ SPDIF output only > SPDIF In > Digital In > HDMI/DP either HDMI or DisplayPort > -=================== ================================================= > +HDMI/DP,pcm=<num> either HDMI or DisplayPort with the PCM device link > +=================== =================================================== > > Exceptions (deprecated) > ----------------------- > diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c > index ac1dea5f9d11..b49028c6fd10 100644 > --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c > +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c > @@ -618,7 +618,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &broxton_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/bxt_rt298.c b/sound/soc/intel/boards/bxt_rt298.c > index adf416a49b48..caaf2f2af287 100644 > --- a/sound/soc/intel/boards/bxt_rt298.c > +++ b/sound/soc/intel/boards/bxt_rt298.c > @@ -530,7 +530,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &broxton_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/glk_rt5682_max98357a.c b/sound/soc/intel/boards/glk_rt5682_max98357a.c > index bd2d371f2acd..5474f28e0c31 100644 > --- a/sound/soc/intel/boards/glk_rt5682_max98357a.c > +++ b/sound/soc/intel/boards/glk_rt5682_max98357a.c > @@ -548,7 +548,7 @@ static int glk_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &geminilake_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c b/sound/soc/intel/boards/kbl_da7219_max98357a.c > index 537a88932bb6..367415efed9b 100644 > --- a/sound/soc/intel/boards/kbl_da7219_max98357a.c > +++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c > @@ -548,7 +548,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &skylake_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c > index 829f95fc4179..b30c2148d1f4 100644 > --- a/sound/soc/intel/boards/kbl_da7219_max98927.c > +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c > @@ -977,7 +977,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &kabylake_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/kbl_rt5660.c b/sound/soc/intel/boards/kbl_rt5660.c > index 74fe1f3a5479..0965d1f02b2c 100644 > --- a/sound/soc/intel/boards/kbl_rt5660.c > +++ b/sound/soc/intel/boards/kbl_rt5660.c > @@ -470,7 +470,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &skylake_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/kbl_rt5663_max98927.c b/sound/soc/intel/boards/kbl_rt5663_max98927.c > index 7cefda341fbf..9f420e978459 100644 > --- a/sound/soc/intel/boards/kbl_rt5663_max98927.c > +++ b/sound/soc/intel/boards/kbl_rt5663_max98927.c > @@ -888,7 +888,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &skylake_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.c b/sound/soc/intel/boards/skl_hda_dsp_common.c > index 58409b6e476e..f717b1d179bd 100644 > --- a/sound/soc/intel/boards/skl_hda_dsp_common.c > +++ b/sound/soc/intel/boards/skl_hda_dsp_common.c > @@ -139,7 +139,7 @@ int skl_hda_hdmi_jack_init(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &pcm->hdmi_jack, > NULL, 0); > diff --git a/sound/soc/intel/boards/skl_nau88l25_max98357a.c b/sound/soc/intel/boards/skl_nau88l25_max98357a.c > index 3ce8efbeed12..b009e2df25d3 100644 > --- a/sound/soc/intel/boards/skl_nau88l25_max98357a.c > +++ b/sound/soc/intel/boards/skl_nau88l25_max98357a.c > @@ -607,7 +607,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, > &skylake_hdmi[i], > diff --git a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c > index 1a7ac8bdf543..0a6e650dc698 100644 > --- a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c > +++ b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c > @@ -648,7 +648,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, > &skylake_hdmi[i], > diff --git a/sound/soc/intel/boards/skl_rt286.c b/sound/soc/intel/boards/skl_rt286.c > index 231349a47cc9..56ee4b55dce9 100644 > --- a/sound/soc/intel/boards/skl_rt286.c > +++ b/sound/soc/intel/boards/skl_rt286.c > @@ -489,7 +489,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &skylake_hdmi[i], > NULL, 0); > diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c > index 4f6e58c3954a..862a7e35cb5c 100644 > --- a/sound/soc/intel/boards/sof_rt5682.c > +++ b/sound/soc/intel/boards/sof_rt5682.c > @@ -277,7 +277,7 @@ static int sof_card_late_probe(struct snd_soc_card *card) > list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > component = pcm->codec_dai->component; > snprintf(jack_name, sizeof(jack_name), > - "HDMI/DP, pcm=%d Jack", pcm->device); > + "HDMI/DP,pcm=%d Jack", pcm->device); > err = snd_soc_card_jack_new(card, jack_name, > SND_JACK_AVOUT, &sof_hdmi[i], > NULL, 0); > -- > 2.20.1 >
Hi, On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > There is an inconsistency in the names for the HDMI/DP Jack control > names between some ASoC drivers and the HDA HDMI driver which > introduced this naming in 2011. this will break a lot of existing devices that are using out-of-tree UCM files, so I'm not sure this is worth the effort. When the common-hdmi patches go in (v7 sent earlier this week), SOF will switch to common-hdmi and the also the naming will be aligned. Br, Kai
Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): > On Fri, 25 Oct 2019 14:30:38 +0200, > Jaroslav Kysela wrote: >> >> There is an inconsistency in the names for the HDMI/DP Jack control >> names between some ASoC drivers and the HDA HDMI driver which >> introduced this naming in 2011. >> >> There might be an impact for the user space (UCM). I will fix >> the UCM configurations when this patch is applied. >> >> Signed-off-by: Jaroslav Kysela <perex@perex.cz> >> Cc: Mark Brown <broonie@kernel.org> >> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > > Yes, that's a known problem, and I left them so far just for keeping > the already existing stuff working. > > Won't this break the current Chromebooks user-space? I would really expect to upgrade UCM configs for the recent kernels in this case. I believe, those sort of issues are better to fix early than lately. I know, the transition might cause a little issues, but usually "do upgrade answer" will help. I don't think that we speak about a large group of users here. Jaroslav > > > thanks, > > Takashi > >> --- >> Documentation/sound/designs/control-names.rst | 5 +++-- >> sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- >> sound/soc/intel/boards/bxt_rt298.c | 2 +- >> sound/soc/intel/boards/glk_rt5682_max98357a.c | 2 +- >> sound/soc/intel/boards/kbl_da7219_max98357a.c | 2 +- >> sound/soc/intel/boards/kbl_da7219_max98927.c | 2 +- >> sound/soc/intel/boards/kbl_rt5660.c | 2 +- >> sound/soc/intel/boards/kbl_rt5663_max98927.c | 2 +- >> sound/soc/intel/boards/skl_hda_dsp_common.c | 2 +- >> sound/soc/intel/boards/skl_nau88l25_max98357a.c | 2 +- >> sound/soc/intel/boards/skl_nau88l25_ssm4567.c | 2 +- >> sound/soc/intel/boards/skl_rt286.c | 2 +- >> sound/soc/intel/boards/sof_rt5682.c | 2 +- >> 13 files changed, 15 insertions(+), 14 deletions(-) >> >> diff --git a/Documentation/sound/designs/control-names.rst b/Documentation/sound/designs/control-names.rst >> index 7fedd0f33cd9..a5f6e3842df8 100644 >> --- a/Documentation/sound/designs/control-names.rst >> +++ b/Documentation/sound/designs/control-names.rst >> @@ -50,7 +50,7 @@ Internal internal >> >> SOURCE >> ~~~~~~ >> -=================== ================================================= >> +=================== =================================================== >> Master >> Master Mono >> Hardware Master >> @@ -92,7 +92,8 @@ SPDIF output only >> SPDIF In >> Digital In >> HDMI/DP either HDMI or DisplayPort >> -=================== ================================================= >> +HDMI/DP,pcm=<num> either HDMI or DisplayPort with the PCM device link >> +=================== =================================================== >> >> Exceptions (deprecated) >> ----------------------- >> diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c >> index ac1dea5f9d11..b49028c6fd10 100644 >> --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c >> +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c >> @@ -618,7 +618,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &broxton_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/bxt_rt298.c b/sound/soc/intel/boards/bxt_rt298.c >> index adf416a49b48..caaf2f2af287 100644 >> --- a/sound/soc/intel/boards/bxt_rt298.c >> +++ b/sound/soc/intel/boards/bxt_rt298.c >> @@ -530,7 +530,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &broxton_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/glk_rt5682_max98357a.c b/sound/soc/intel/boards/glk_rt5682_max98357a.c >> index bd2d371f2acd..5474f28e0c31 100644 >> --- a/sound/soc/intel/boards/glk_rt5682_max98357a.c >> +++ b/sound/soc/intel/boards/glk_rt5682_max98357a.c >> @@ -548,7 +548,7 @@ static int glk_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &geminilake_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c b/sound/soc/intel/boards/kbl_da7219_max98357a.c >> index 537a88932bb6..367415efed9b 100644 >> --- a/sound/soc/intel/boards/kbl_da7219_max98357a.c >> +++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c >> @@ -548,7 +548,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &skylake_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c >> index 829f95fc4179..b30c2148d1f4 100644 >> --- a/sound/soc/intel/boards/kbl_da7219_max98927.c >> +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c >> @@ -977,7 +977,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &kabylake_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/kbl_rt5660.c b/sound/soc/intel/boards/kbl_rt5660.c >> index 74fe1f3a5479..0965d1f02b2c 100644 >> --- a/sound/soc/intel/boards/kbl_rt5660.c >> +++ b/sound/soc/intel/boards/kbl_rt5660.c >> @@ -470,7 +470,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &skylake_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/kbl_rt5663_max98927.c b/sound/soc/intel/boards/kbl_rt5663_max98927.c >> index 7cefda341fbf..9f420e978459 100644 >> --- a/sound/soc/intel/boards/kbl_rt5663_max98927.c >> +++ b/sound/soc/intel/boards/kbl_rt5663_max98927.c >> @@ -888,7 +888,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &skylake_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.c b/sound/soc/intel/boards/skl_hda_dsp_common.c >> index 58409b6e476e..f717b1d179bd 100644 >> --- a/sound/soc/intel/boards/skl_hda_dsp_common.c >> +++ b/sound/soc/intel/boards/skl_hda_dsp_common.c >> @@ -139,7 +139,7 @@ int skl_hda_hdmi_jack_init(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &pcm->hdmi_jack, >> NULL, 0); >> diff --git a/sound/soc/intel/boards/skl_nau88l25_max98357a.c b/sound/soc/intel/boards/skl_nau88l25_max98357a.c >> index 3ce8efbeed12..b009e2df25d3 100644 >> --- a/sound/soc/intel/boards/skl_nau88l25_max98357a.c >> +++ b/sound/soc/intel/boards/skl_nau88l25_max98357a.c >> @@ -607,7 +607,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, >> &skylake_hdmi[i], >> diff --git a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c >> index 1a7ac8bdf543..0a6e650dc698 100644 >> --- a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c >> +++ b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c >> @@ -648,7 +648,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, >> &skylake_hdmi[i], >> diff --git a/sound/soc/intel/boards/skl_rt286.c b/sound/soc/intel/boards/skl_rt286.c >> index 231349a47cc9..56ee4b55dce9 100644 >> --- a/sound/soc/intel/boards/skl_rt286.c >> +++ b/sound/soc/intel/boards/skl_rt286.c >> @@ -489,7 +489,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &skylake_hdmi[i], >> NULL, 0); >> diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c >> index 4f6e58c3954a..862a7e35cb5c 100644 >> --- a/sound/soc/intel/boards/sof_rt5682.c >> +++ b/sound/soc/intel/boards/sof_rt5682.c >> @@ -277,7 +277,7 @@ static int sof_card_late_probe(struct snd_soc_card *card) >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> - "HDMI/DP, pcm=%d Jack", pcm->device); >> + "HDMI/DP,pcm=%d Jack", pcm->device); >> err = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, &sof_hdmi[i], >> NULL, 0); >> -- >> 2.20.1 >>
Dne 25. 10. 19 v 14:44 Kai Vehmanen napsal(a): > Hi, > > On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > >> There is an inconsistency in the names for the HDMI/DP Jack control >> names between some ASoC drivers and the HDA HDMI driver which >> introduced this naming in 2011. > > this will break a lot of existing devices that are using out-of-tree UCM > files, so I'm not sure this is worth the effort. I don't agree. The out-of-tree UCMs should go to upstream anyway, except that they are unusable for the standard users. Jaroslav
On Fri, 25 Oct 2019 15:57:50 +0200, Jaroslav Kysela wrote: > > Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): > > On Fri, 25 Oct 2019 14:30:38 +0200, > > Jaroslav Kysela wrote: > >> > >> There is an inconsistency in the names for the HDMI/DP Jack control > >> names between some ASoC drivers and the HDA HDMI driver which > >> introduced this naming in 2011. > >> > >> There might be an impact for the user space (UCM). I will fix > >> the UCM configurations when this patch is applied. > >> > >> Signed-off-by: Jaroslav Kysela <perex@perex.cz> > >> Cc: Mark Brown <broonie@kernel.org> > >> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > > > > Yes, that's a known problem, and I left them so far just for keeping > > the already existing stuff working. > > > > Won't this break the current Chromebooks user-space? > > I would really expect to upgrade UCM configs for the recent kernels in > this case. I believe, those sort of issues are better to fix early > than lately. I know, the transition might cause a little issues, but > usually "do upgrade answer" will help. I don't think that we speak > about a large group of users here. Well, that's obviously against our dont-breaking-user-space rule. The UCM profiles have been widely used on Chromebooks, and they can't upgrade easily. So, I believe this is a case where we have to live with messes. thanks, Takashi > > Jaroslav > > > > > > > thanks, > > > > Takashi > > > >> --- > >> Documentation/sound/designs/control-names.rst | 5 +++-- > >> sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- > >> sound/soc/intel/boards/bxt_rt298.c | 2 +- > >> sound/soc/intel/boards/glk_rt5682_max98357a.c | 2 +- > >> sound/soc/intel/boards/kbl_da7219_max98357a.c | 2 +- > >> sound/soc/intel/boards/kbl_da7219_max98927.c | 2 +- > >> sound/soc/intel/boards/kbl_rt5660.c | 2 +- > >> sound/soc/intel/boards/kbl_rt5663_max98927.c | 2 +- > >> sound/soc/intel/boards/skl_hda_dsp_common.c | 2 +- > >> sound/soc/intel/boards/skl_nau88l25_max98357a.c | 2 +- > >> sound/soc/intel/boards/skl_nau88l25_ssm4567.c | 2 +- > >> sound/soc/intel/boards/skl_rt286.c | 2 +- > >> sound/soc/intel/boards/sof_rt5682.c | 2 +- > >> 13 files changed, 15 insertions(+), 14 deletions(-) > >> > >> diff --git a/Documentation/sound/designs/control-names.rst b/Documentation/sound/designs/control-names.rst > >> index 7fedd0f33cd9..a5f6e3842df8 100644 > >> --- a/Documentation/sound/designs/control-names.rst > >> +++ b/Documentation/sound/designs/control-names.rst > >> @@ -50,7 +50,7 @@ Internal internal > >> SOURCE > >> ~~~~~~ > >> -=================== ================================================= > >> +=================== =================================================== > >> Master > >> Master Mono > >> Hardware Master > >> @@ -92,7 +92,8 @@ SPDIF output only > >> SPDIF In > >> Digital In > >> HDMI/DP either HDMI or DisplayPort > >> -=================== ================================================= > >> +HDMI/DP,pcm=<num> either HDMI or DisplayPort with the PCM device link > >> +=================== =================================================== > >> Exceptions (deprecated) > >> ----------------------- > >> diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c > >> index ac1dea5f9d11..b49028c6fd10 100644 > >> --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c > >> +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c > >> @@ -618,7 +618,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &broxton_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/bxt_rt298.c b/sound/soc/intel/boards/bxt_rt298.c > >> index adf416a49b48..caaf2f2af287 100644 > >> --- a/sound/soc/intel/boards/bxt_rt298.c > >> +++ b/sound/soc/intel/boards/bxt_rt298.c > >> @@ -530,7 +530,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &broxton_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/glk_rt5682_max98357a.c b/sound/soc/intel/boards/glk_rt5682_max98357a.c > >> index bd2d371f2acd..5474f28e0c31 100644 > >> --- a/sound/soc/intel/boards/glk_rt5682_max98357a.c > >> +++ b/sound/soc/intel/boards/glk_rt5682_max98357a.c > >> @@ -548,7 +548,7 @@ static int glk_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &geminilake_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c b/sound/soc/intel/boards/kbl_da7219_max98357a.c > >> index 537a88932bb6..367415efed9b 100644 > >> --- a/sound/soc/intel/boards/kbl_da7219_max98357a.c > >> +++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c > >> @@ -548,7 +548,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &skylake_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c > >> index 829f95fc4179..b30c2148d1f4 100644 > >> --- a/sound/soc/intel/boards/kbl_da7219_max98927.c > >> +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c > >> @@ -977,7 +977,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &kabylake_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/kbl_rt5660.c b/sound/soc/intel/boards/kbl_rt5660.c > >> index 74fe1f3a5479..0965d1f02b2c 100644 > >> --- a/sound/soc/intel/boards/kbl_rt5660.c > >> +++ b/sound/soc/intel/boards/kbl_rt5660.c > >> @@ -470,7 +470,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &skylake_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/kbl_rt5663_max98927.c b/sound/soc/intel/boards/kbl_rt5663_max98927.c > >> index 7cefda341fbf..9f420e978459 100644 > >> --- a/sound/soc/intel/boards/kbl_rt5663_max98927.c > >> +++ b/sound/soc/intel/boards/kbl_rt5663_max98927.c > >> @@ -888,7 +888,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &skylake_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.c b/sound/soc/intel/boards/skl_hda_dsp_common.c > >> index 58409b6e476e..f717b1d179bd 100644 > >> --- a/sound/soc/intel/boards/skl_hda_dsp_common.c > >> +++ b/sound/soc/intel/boards/skl_hda_dsp_common.c > >> @@ -139,7 +139,7 @@ int skl_hda_hdmi_jack_init(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &pcm->hdmi_jack, > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/skl_nau88l25_max98357a.c b/sound/soc/intel/boards/skl_nau88l25_max98357a.c > >> index 3ce8efbeed12..b009e2df25d3 100644 > >> --- a/sound/soc/intel/boards/skl_nau88l25_max98357a.c > >> +++ b/sound/soc/intel/boards/skl_nau88l25_max98357a.c > >> @@ -607,7 +607,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, > >> &skylake_hdmi[i], > >> diff --git a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c > >> index 1a7ac8bdf543..0a6e650dc698 100644 > >> --- a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c > >> +++ b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c > >> @@ -648,7 +648,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, > >> &skylake_hdmi[i], > >> diff --git a/sound/soc/intel/boards/skl_rt286.c b/sound/soc/intel/boards/skl_rt286.c > >> index 231349a47cc9..56ee4b55dce9 100644 > >> --- a/sound/soc/intel/boards/skl_rt286.c > >> +++ b/sound/soc/intel/boards/skl_rt286.c > >> @@ -489,7 +489,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &skylake_hdmi[i], > >> NULL, 0); > >> diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c > >> index 4f6e58c3954a..862a7e35cb5c 100644 > >> --- a/sound/soc/intel/boards/sof_rt5682.c > >> +++ b/sound/soc/intel/boards/sof_rt5682.c > >> @@ -277,7 +277,7 @@ static int sof_card_late_probe(struct snd_soc_card *card) > >> list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { > >> component = pcm->codec_dai->component; > >> snprintf(jack_name, sizeof(jack_name), > >> - "HDMI/DP, pcm=%d Jack", pcm->device); > >> + "HDMI/DP,pcm=%d Jack", pcm->device); > >> err = snd_soc_card_jack_new(card, jack_name, > >> SND_JACK_AVOUT, &sof_hdmi[i], > >> NULL, 0); > >> -- > >> 2.20.1 > >> > > > -- > Jaroslav Kysela <perex@perex.cz> > Linux Sound Maintainer; ALSA Project; Red Hat, Inc. >
Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a): > On Fri, 25 Oct 2019 15:57:50 +0200, > Jaroslav Kysela wrote: >> >> Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): >>> On Fri, 25 Oct 2019 14:30:38 +0200, >>> Jaroslav Kysela wrote: >>>> >>>> There is an inconsistency in the names for the HDMI/DP Jack control >>>> names between some ASoC drivers and the HDA HDMI driver which >>>> introduced this naming in 2011. >>>> >>>> There might be an impact for the user space (UCM). I will fix >>>> the UCM configurations when this patch is applied. >>>> >>>> Signed-off-by: Jaroslav Kysela <perex@perex.cz> >>>> Cc: Mark Brown <broonie@kernel.org> >>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> >>> >>> Yes, that's a known problem, and I left them so far just for keeping >>> the already existing stuff working. >>> >>> Won't this break the current Chromebooks user-space? >> >> I would really expect to upgrade UCM configs for the recent kernels in >> this case. I believe, those sort of issues are better to fix early >> than lately. I know, the transition might cause a little issues, but >> usually "do upgrade answer" will help. I don't think that we speak >> about a large group of users here. > > Well, that's obviously against our dont-breaking-user-space rule. > The UCM profiles have been widely used on Chromebooks, and they can't > upgrade easily. > > So, I believe this is a case where we have to live with messes. If we speak about Google's kernels, they can apply a revert (depends on their upgrade/maintenance policy). If users use the standard Linux distributions, then we are fine, don't we? I would make an exception for the dont-breaking-user-space policy in this case. I am sure that the UCM configs will stabilize quickly. And this bad jack name is against our control name policy. It's just a bug. Jaroslav
On Fri, 25 Oct 2019 16:18:20 +0200, Jaroslav Kysela wrote: > > Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a): > > On Fri, 25 Oct 2019 15:57:50 +0200, > > Jaroslav Kysela wrote: > >> > >> Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): > >>> On Fri, 25 Oct 2019 14:30:38 +0200, > >>> Jaroslav Kysela wrote: > >>>> > >>>> There is an inconsistency in the names for the HDMI/DP Jack control > >>>> names between some ASoC drivers and the HDA HDMI driver which > >>>> introduced this naming in 2011. > >>>> > >>>> There might be an impact for the user space (UCM). I will fix > >>>> the UCM configurations when this patch is applied. > >>>> > >>>> Signed-off-by: Jaroslav Kysela <perex@perex.cz> > >>>> Cc: Mark Brown <broonie@kernel.org> > >>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > >>> > >>> Yes, that's a known problem, and I left them so far just for keeping > >>> the already existing stuff working. > >>> > >>> Won't this break the current Chromebooks user-space? > >> > >> I would really expect to upgrade UCM configs for the recent kernels in > >> this case. I believe, those sort of issues are better to fix early > >> than lately. I know, the transition might cause a little issues, but > >> usually "do upgrade answer" will help. I don't think that we speak > >> about a large group of users here. > > > > Well, that's obviously against our dont-breaking-user-space rule. > > The UCM profiles have been widely used on Chromebooks, and they can't > > upgrade easily. > > > > So, I believe this is a case where we have to live with messes. > > If we speak about Google's kernels, they can apply a revert (depends > on their upgrade/maintenance policy). If users use the standard Linux > distributions, then we are fine, don't we? No, we can't break the already existing user-space. That's what Linus suggested repeatedly over years, too. > I would make an exception for the dont-breaking-user-space policy in > this case. I am sure that the UCM configs will stabilize quickly. And > this bad jack name is against our control name policy. It's just a > bug. There is no exception for that, it's a so simple rule. If something gets *practically* broken by the kernel, it's no-go. User-space is user-space, and it doesn't matter whether it's upstream or not. And, even if everything is upstream, imagine that user installs two different kernels, and switches with each other occasionally for whatever reason. The UCM upgrade solution won't work, either. thanks, Takashi
On 10/25/19 9:04 AM, Jaroslav Kysela wrote: > Dne 25. 10. 19 v 14:44 Kai Vehmanen napsal(a): >> Hi, >> >> On Fri, 25 Oct 2019, Jaroslav Kysela wrote: >> >>> There is an inconsistency in the names for the HDMI/DP Jack control >>> names between some ASoC drivers and the HDA HDMI driver which >>> introduced this naming in 2011. >> >> this will break a lot of existing devices that are using out-of-tree UCM >> files, so I'm not sure this is worth the effort. > > I don't agree. The out-of-tree UCMs should go to upstream anyway, except > that they are unusable for the standard users. Isn't there a problem due to UCM extensions as well? I vaguely recall having to modify the Cherrytrail UCMs I took from the Chrome adhd repository since the parsing wouldn't work with the standard alsa-lib.
Dne 25. 10. 19 v 16:28 Takashi Iwai napsal(a): > On Fri, 25 Oct 2019 16:18:20 +0200, > Jaroslav Kysela wrote: >> >> Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a): >>> On Fri, 25 Oct 2019 15:57:50 +0200, >>> Jaroslav Kysela wrote: >>>> >>>> Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): >>>>> On Fri, 25 Oct 2019 14:30:38 +0200, >>>>> Jaroslav Kysela wrote: >>>>>> >>>>>> There is an inconsistency in the names for the HDMI/DP Jack control >>>>>> names between some ASoC drivers and the HDA HDMI driver which >>>>>> introduced this naming in 2011. >>>>>> >>>>>> There might be an impact for the user space (UCM). I will fix >>>>>> the UCM configurations when this patch is applied. >>>>>> >>>>>> Signed-off-by: Jaroslav Kysela <perex@perex.cz> >>>>>> Cc: Mark Brown <broonie@kernel.org> >>>>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> >>>>> >>>>> Yes, that's a known problem, and I left them so far just for keeping >>>>> the already existing stuff working. >>>>> >>>>> Won't this break the current Chromebooks user-space? >>>> >>>> I would really expect to upgrade UCM configs for the recent kernels in >>>> this case. I believe, those sort of issues are better to fix early >>>> than lately. I know, the transition might cause a little issues, but >>>> usually "do upgrade answer" will help. I don't think that we speak >>>> about a large group of users here. >>> >>> Well, that's obviously against our dont-breaking-user-space rule. >>> The UCM profiles have been widely used on Chromebooks, and they can't >>> upgrade easily. >>> >>> So, I believe this is a case where we have to live with messes. >> >> If we speak about Google's kernels, they can apply a revert (depends >> on their upgrade/maintenance policy). If users use the standard Linux >> distributions, then we are fine, don't we? > > No, we can't break the already existing user-space. That's what Linus > suggested repeatedly over years, too. > >> I would make an exception for the dont-breaking-user-space policy in >> this case. I am sure that the UCM configs will stabilize quickly. And >> this bad jack name is against our control name policy. It's just a >> bug. > > There is no exception for that, it's a so simple rule. If something > gets *practically* broken by the kernel, it's no-go. User-space is > user-space, and it doesn't matter whether it's upstream or not. > > And, even if everything is upstream, imagine that user installs two > different kernels, and switches with each other occasionally for > whatever reason. The UCM upgrade solution won't work, either. It's the corner case with the really low impact. Users do not do this usually. Ok, I will be silent again. It seems that we cannot get an agreement on this simple thing. I just prefer the fix rather than nothing. Jaroslav > > > thanks, > > Takashi >
Dne 25. 10. 19 v 16:35 Pierre-Louis Bossart napsal(a): > > > On 10/25/19 9:04 AM, Jaroslav Kysela wrote: >> Dne 25. 10. 19 v 14:44 Kai Vehmanen napsal(a): >>> Hi, >>> >>> On Fri, 25 Oct 2019, Jaroslav Kysela wrote: >>> >>>> There is an inconsistency in the names for the HDMI/DP Jack control >>>> names between some ASoC drivers and the HDA HDMI driver which >>>> introduced this naming in 2011. >>> >>> this will break a lot of existing devices that are using out-of-tree UCM >>> files, so I'm not sure this is worth the effort. >> >> I don't agree. The out-of-tree UCMs should go to upstream anyway, except >> that they are unusable for the standard users. > > Isn't there a problem due to UCM extensions as well? I vaguely recall > having to modify the Cherrytrail UCMs I took from the Chrome adhd > repository since the parsing wouldn't work with the standard alsa-lib. If they add something extra without the community agreement, it may break the alsa-lib UCM parser, of course. I meant UCM configs for the Linux users. Jaroslav
On Fri, Oct 25, 2019 at 04:28:26PM +0200, Takashi Iwai wrote: > Jaroslav Kysela wrote: > > Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a): > > > Well, that's obviously against our dont-breaking-user-space rule. > > > The UCM profiles have been widely used on Chromebooks, and they can't > > > upgrade easily. > > > So, I believe this is a case where we have to live with messes. > > If we speak about Google's kernels, they can apply a revert (depends > > on their upgrade/maintenance policy). If users use the standard Linux > > distributions, then we are fine, don't we? > No, we can't break the already existing user-space. That's what Linus > suggested repeatedly over years, too. I agree. There's some systems where we can get away with incompatible changes as realistically the users are doing full system upgrades and don't care but the Chromebooks definitely aren't one of them, we've had issues reported with breakages on them due to changes with the x86 DSP firmwares. It's mainly people sideloading a regular Linux userspace along with the ChromeOS kernel AIUI.
On Fri, 25 Oct 2019 16:39:44 +0200, Jaroslav Kysela wrote: > > Dne 25. 10. 19 v 16:28 Takashi Iwai napsal(a): > > On Fri, 25 Oct 2019 16:18:20 +0200, > > Jaroslav Kysela wrote: > >> > >> Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a): > >>> On Fri, 25 Oct 2019 15:57:50 +0200, > >>> Jaroslav Kysela wrote: > >>>> > >>>> Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): > >>>>> On Fri, 25 Oct 2019 14:30:38 +0200, > >>>>> Jaroslav Kysela wrote: > >>>>>> > >>>>>> There is an inconsistency in the names for the HDMI/DP Jack control > >>>>>> names between some ASoC drivers and the HDA HDMI driver which > >>>>>> introduced this naming in 2011. > >>>>>> > >>>>>> There might be an impact for the user space (UCM). I will fix > >>>>>> the UCM configurations when this patch is applied. > >>>>>> > >>>>>> Signed-off-by: Jaroslav Kysela <perex@perex.cz> > >>>>>> Cc: Mark Brown <broonie@kernel.org> > >>>>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > >>>>> > >>>>> Yes, that's a known problem, and I left them so far just for keeping > >>>>> the already existing stuff working. > >>>>> > >>>>> Won't this break the current Chromebooks user-space? > >>>> > >>>> I would really expect to upgrade UCM configs for the recent kernels in > >>>> this case. I believe, those sort of issues are better to fix early > >>>> than lately. I know, the transition might cause a little issues, but > >>>> usually "do upgrade answer" will help. I don't think that we speak > >>>> about a large group of users here. > >>> > >>> Well, that's obviously against our dont-breaking-user-space rule. > >>> The UCM profiles have been widely used on Chromebooks, and they can't > >>> upgrade easily. > >>> > >>> So, I believe this is a case where we have to live with messes. > >> > >> If we speak about Google's kernels, they can apply a revert (depends > >> on their upgrade/maintenance policy). If users use the standard Linux > >> distributions, then we are fine, don't we? > > > > No, we can't break the already existing user-space. That's what Linus > > suggested repeatedly over years, too. > > > >> I would make an exception for the dont-breaking-user-space policy in > >> this case. I am sure that the UCM configs will stabilize quickly. And > >> this bad jack name is against our control name policy. It's just a > >> bug. > > > > There is no exception for that, it's a so simple rule. If something > > gets *practically* broken by the kernel, it's no-go. User-space is > > user-space, and it doesn't matter whether it's upstream or not. > > > > And, even if everything is upstream, imagine that user installs two > > different kernels, and switches with each other occasionally for > > whatever reason. The UCM upgrade solution won't work, either. > > It's the corner case with the really low impact. Users do not do this > usually. Ok, I will be silent again. It seems that we cannot get an > agreement on this simple thing. I just prefer the fix rather than > nothing. I'd love to fix things, too, of course. But we need changing our mindset: what we - the kernel devs - can control is only inside the kernel. Even the upstream alsa-lib and UCM profiles are merely reference implementations. thanks, Takashi
Hi Kai, On 10/25/19 3:44 PM, Kai Vehmanen wrote: > Hi, > > On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > >> There is an inconsistency in the names for the HDMI/DP Jack control >> names between some ASoC drivers and the HDA HDMI driver which >> introduced this naming in 2011. > > this will break a lot of existing devices that are using out-of-tree UCM > files, so I'm not sure this is worth the effort. > > When the common-hdmi patches go in (v7 sent earlier this week), SOF will > switch to common-hdmi and the also the naming will be aligned. Which is going to break existing users, if any ;) > > Br, Kai > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > https://mailman.alsa-project.org/mailman/listinfo/alsa-devel > - Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Dne 25. 10. 19 v 18:11 Takashi Iwai napsal(a): > On Fri, 25 Oct 2019 16:39:44 +0200, > Jaroslav Kysela wrote: >> >> Dne 25. 10. 19 v 16:28 Takashi Iwai napsal(a): >>> On Fri, 25 Oct 2019 16:18:20 +0200, >>> Jaroslav Kysela wrote: >>>> >>>> Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a): >>>>> On Fri, 25 Oct 2019 15:57:50 +0200, >>>>> Jaroslav Kysela wrote: >>>>>> >>>>>> Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a): >>>>>>> On Fri, 25 Oct 2019 14:30:38 +0200, >>>>>>> Jaroslav Kysela wrote: >>>>>>>> >>>>>>>> There is an inconsistency in the names for the HDMI/DP Jack control >>>>>>>> names between some ASoC drivers and the HDA HDMI driver which >>>>>>>> introduced this naming in 2011. >>>>>>>> >>>>>>>> There might be an impact for the user space (UCM). I will fix >>>>>>>> the UCM configurations when this patch is applied. >>>>>>>> >>>>>>>> Signed-off-by: Jaroslav Kysela <perex@perex.cz> >>>>>>>> Cc: Mark Brown <broonie@kernel.org> >>>>>>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> >>>>>>> >>>>>>> Yes, that's a known problem, and I left them so far just for keeping >>>>>>> the already existing stuff working. >>>>>>> >>>>>>> Won't this break the current Chromebooks user-space? >>>>>> >>>>>> I would really expect to upgrade UCM configs for the recent kernels in >>>>>> this case. I believe, those sort of issues are better to fix early >>>>>> than lately. I know, the transition might cause a little issues, but >>>>>> usually "do upgrade answer" will help. I don't think that we speak >>>>>> about a large group of users here. >>>>> >>>>> Well, that's obviously against our dont-breaking-user-space rule. >>>>> The UCM profiles have been widely used on Chromebooks, and they can't >>>>> upgrade easily. >>>>> >>>>> So, I believe this is a case where we have to live with messes. >>>> >>>> If we speak about Google's kernels, they can apply a revert (depends >>>> on their upgrade/maintenance policy). If users use the standard Linux >>>> distributions, then we are fine, don't we? >>> >>> No, we can't break the already existing user-space. That's what Linus >>> suggested repeatedly over years, too. >>> >>>> I would make an exception for the dont-breaking-user-space policy in >>>> this case. I am sure that the UCM configs will stabilize quickly. And >>>> this bad jack name is against our control name policy. It's just a >>>> bug. >>> >>> There is no exception for that, it's a so simple rule. If something >>> gets *practically* broken by the kernel, it's no-go. User-space is >>> user-space, and it doesn't matter whether it's upstream or not. >>> >>> And, even if everything is upstream, imagine that user installs two >>> different kernels, and switches with each other occasionally for >>> whatever reason. The UCM upgrade solution won't work, either. >> >> It's the corner case with the really low impact. Users do not do this >> usually. Ok, I will be silent again. It seems that we cannot get an >> agreement on this simple thing. I just prefer the fix rather than >> nothing. > > I'd love to fix things, too, of course. But we need changing our > mindset: what we - the kernel devs - can control is only inside the > kernel. Even the upstream alsa-lib and UCM profiles are merely > reference implementations. You speak about ChromeOS not Linux here.. Anyway, I wanted to cleanup the driver names like 'sof-skl_hda_card' (mixed - and _). It seems that it's just waste of time, because you'll argue that the user-space is incompatible, too. So every time when we have wrong string in the kernel, we cannot change it, because the user-space. Okay, that's imperfect world. We're being driven with the single user. Another problem is that we are not able to review all those mistakes at the merge time. It is not a complain but a true fact. I would be really curious what will happen when we change those strings ;-) Nice weekend to all, Jaroslav
Hi Peter, On Fri, 25 Oct 2019, Peter Ujfalusi wrote: > On 10/25/19 3:44 PM, Kai Vehmanen wrote: > > When the common-hdmi patches go in (v7 sent earlier this week), SOF will > > switch to common-hdmi and the also the naming will be aligned. > > Which is going to break existing users, if any ;) valid point :) but I have actually gone to great lengths to not break existing user-space. I did consider the same approach as Jaroslav (especially as there is still limited number of SOF clients in the wild still), but dropped the idea based on userspace feedback. So in the end, backward compatibility is kept in the patchset just for this reason. The common-hdmi patch adds ability to use SOF with both codec drivers and I even added a module parameter to allow distros to compile both drivers in, and select the driver to use, at runtime from user-space. Slowly as user-space migrates to the new driver (more features), we can at some point drop the old and get rid of "'HDMI/DP, pcm=' notation. Of course, proving there is no one left is not easy, so we likely need to maintain both for a looong time. Br, Kai
Hi Jaroslav and all, On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > the single user. Another problem is that we are not able to review all those > mistakes at the merge time. It is not a complain but a true fact. but the strings are in kernel patches, so even if all UCM files don't go through the list, we can always review when the strings are added in kernel, right? > I would be really curious what will happen when we change those strings ;-) I can share some experiences that happen on Linux distros with Pulseaudio: - if mixer control name is changed/missing that us used in a UCM enable sequence, the enable sequence will fail and PA will not choose that device -> e.g. when wrong HDMI control names are in the UCM file, HDMI output stops working - if mixer control for a Jack is changed, PA will not listen for ALSA kctl events -> HDMI connection is silently missed and HDMI is not listed as a possible output .. i.e. in both cases HDMI is essentially broken if you update to a kernel that updates the strings but don't update user-space in sync. I wonder if one option would be to expose "legacy string" aliases, allowing to make changes but keep existing user-space happy. With my HDMI codec change, the controls are simply different, so this was not an option and I had to opt for keeping the whole driver around. Br, Kai
Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a): > Hi Jaroslav and all, > > On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > >> the single user. Another problem is that we are not able to review all those >> mistakes at the merge time. It is not a complain but a true fact. > > but the strings are in kernel patches, so even if all UCM files don't > go through the list, we can always review when the strings are added > in kernel, right? My point is that we already did this incomplete review (the wrong strings are in the current kernel). We cannot prevent to avoid those code merges, we are just human. I just don't think that the driver / control names should be part of the don't-break-the-userspace policy. >> I would be really curious what will happen when we change those strings ;-) > > I can share some experiences that happen on Linux distros with Pulseaudio: > > - if mixer control name is changed/missing that us used in > a UCM enable sequence, the enable sequence will fail and PA will > not choose that device > -> e.g. when wrong HDMI control names are in the UCM file, HDMI > output stops working > - if mixer control for a Jack is changed, PA will not listen > for ALSA kctl events > -> HDMI connection is silently missed and HDMI is not listed > as a possible output > > .. i.e. in both cases HDMI is essentially broken if you update to > a kernel that updates the strings but don't update user-space in sync. Yes, it's true. But usually, users do only upgrade. If we resolve the UCM configs before the kernel change, the impact is just very low. > I wonder if one option would be to expose "legacy string" aliases, > allowing to make changes but keep existing user-space happy. With my HDMI > codec change, the controls are simply different, so this was not an > option and I had to opt for keeping the whole driver around. It seems that we may need to add conditions to the UCM syntax. There are several ways to do it. For your specific purpose it may look like "if the control exist, use this config" or so. Another approach might be to add something to the decision code which top UCM config file should be loaded. Actually, we rely on the card name / long_name only. It seems that the probe might be extended here. Jaroslav
On Fri, 25 Oct 2019 23:03:26 +0200, Jaroslav Kysela wrote: > > Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a): > > Hi Jaroslav and all, > > > > On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > > > >> the single user. Another problem is that we are not able to review all those > >> mistakes at the merge time. It is not a complain but a true fact. > > > > but the strings are in kernel patches, so even if all UCM files don't > > go through the list, we can always review when the strings are added > > in kernel, right? > > My point is that we already did this incomplete review (the wrong > strings are in the current kernel). We cannot prevent to avoid those > code merges, we are just human. I just don't think that the driver / > control names should be part of the don't-break-the-userspace policy. It's a similar situation like the long-time discussion of tracing: when the kernel broke latencytop by changing the tracing format, we had to revert it in the end although the tracing format itself isn't strictly a "standard kernel ABI". The consensus is: if upgrading the kernel breaks anything *significant*, it's a regression and no-go. It's not about whether it's a part of ABI or not. In our particular case, the strings you wanted to fix are the ones that are actually hard-coded by the UCM profiles that are known to be really used on major systems. That's the only reason of NAK. If it were for some other minor kcontrol elements, it would have been OK. Kai's work to integrate SOF to the legacy HDMI driver would be also OK because it provides the compatibility mode. That is, we have some excuse that it's not us but users (distros) who actually breaks by choosing the kernel configuration explicitly (and even there can be a workaround with a module option). Or, in general, if a fix is mandatory due to any critical problem (leading to a system crash or such) and there is no other way, we'll have to adapt it. But our case is, again, not that category. It was merely a cleanup work. > >> I would be really curious what will happen when we change those strings ;-) > > > > I can share some experiences that happen on Linux distros with Pulseaudio: > > > > - if mixer control name is changed/missing that us used in > > a UCM enable sequence, the enable sequence will fail and PA will > > not choose that device > > -> e.g. when wrong HDMI control names are in the UCM file, HDMI > > output stops working > > - if mixer control for a Jack is changed, PA will not listen > > for ALSA kctl events > > -> HDMI connection is silently missed and HDMI is not listed > > as a possible output > > > > .. i.e. in both cases HDMI is essentially broken if you update to > > a kernel that updates the strings but don't update user-space in sync. > > Yes, it's true. But usually, users do only upgrade. If we resolve the > UCM configs before the kernel change, the impact is just very low. Well, we can't define users' behavior at all. Upgrading only the kernel while keeping the old user-space is a very common practice on openSUSE Leap systems, for example. (Or imagine centos user who wants to try a newer kernel.) > > I wonder if one option would be to expose "legacy string" aliases, > > allowing to make changes but keep existing user-space happy. With my HDMI > > codec change, the controls are simply different, so this was not an > > option and I had to opt for keeping the whole driver around. > > It seems that we may need to add conditions to the UCM syntax. There > are several ways to do it. For your specific purpose it may look like > "if the control exist, use this config" or so. > > Another approach might be to add something to the decision code which > top UCM config file should be loaded. Actually, we rely on the card > name / long_name only. It seems that the probe might be extended here. Yes, currently a UCM profile is very hard-coded, hence it's quite tightly coupled with the kernel driver implementation details. It makes the UCM parser code implementation easier, while it induces this kind of incompatibility if we want to change something in the kernel side... Another (rather tangential) improvement would be to introduce some validator in the kernel or in the UCM side to check whether the given string names are OK or not. A generic kcontrol element validator might be worth not only for UCM but in general, because lots of ASoC drivers tend to use any funky string names, and currently we accept them without strict checks. thanks, Takashi
Dne 26. 10. 19 v 9:37 Takashi Iwai napsal(a): > On Fri, 25 Oct 2019 23:03:26 +0200, > Jaroslav Kysela wrote: >> >> Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a): >>> Hi Jaroslav and all, >>> >>> On Fri, 25 Oct 2019, Jaroslav Kysela wrote: >>> >>>> the single user. Another problem is that we are not able to review all those >>>> mistakes at the merge time. It is not a complain but a true fact. >>> >>> but the strings are in kernel patches, so even if all UCM files don't >>> go through the list, we can always review when the strings are added >>> in kernel, right? >> >> My point is that we already did this incomplete review (the wrong >> strings are in the current kernel). We cannot prevent to avoid those >> code merges, we are just human. I just don't think that the driver / >> control names should be part of the don't-break-the-userspace policy. > > It's a similar situation like the long-time discussion of tracing: > when the kernel broke latencytop by changing the tracing format, we > had to revert it in the end although the tracing format itself isn't > strictly a "standard kernel ABI". The consensus is: if upgrading the > kernel breaks anything *significant*, it's a regression and no-go. > It's not about whether it's a part of ABI or not. > > In our particular case, the strings you wanted to fix are the ones > that are actually hard-coded by the UCM profiles that are known to be > really used on major systems. That's the only reason of NAK. If it > were for some other minor kcontrol elements, it would have been OK. > > Kai's work to integrate SOF to the legacy HDMI driver would be also OK > because it provides the compatibility mode. That is, we have some > excuse that it's not us but users (distros) who actually breaks by > choosing the kernel configuration explicitly (and even there can be a > workaround with a module option). We can add another kernel option for this fix, too. If you like to move in this direction, I'll modify my patch. The question is, if the kernel should provide a hint to the user space (UCM), that something *significant* changed. Perhaps, the component field in the control API might be used for this purpose as I already proposed. In this way, we can support both kernels (with old and new control names). > Or, in general, if a fix is mandatory due to any critical problem > (leading to a system crash or such) and there is no other way, we'll > have to adapt it. But our case is, again, not that category. It was > merely a cleanup work. > >>>> I would be really curious what will happen when we change those strings ;-) >>> >>> I can share some experiences that happen on Linux distros with Pulseaudio: >>> >>> - if mixer control name is changed/missing that us used in >>> a UCM enable sequence, the enable sequence will fail and PA will >>> not choose that device >>> -> e.g. when wrong HDMI control names are in the UCM file, HDMI >>> output stops working >>> - if mixer control for a Jack is changed, PA will not listen >>> for ALSA kctl events >>> -> HDMI connection is silently missed and HDMI is not listed >>> as a possible output >>> >>> .. i.e. in both cases HDMI is essentially broken if you update to >>> a kernel that updates the strings but don't update user-space in sync. >> >> Yes, it's true. But usually, users do only upgrade. If we resolve the >> UCM configs before the kernel change, the impact is just very low. > > Well, we can't define users' behavior at all. Upgrading only the > kernel while keeping the old user-space is a very common practice on > openSUSE Leap systems, for example. (Or imagine centos user who wants > to try a newer kernel.) > >>> I wonder if one option would be to expose "legacy string" aliases, >>> allowing to make changes but keep existing user-space happy. With my HDMI >>> codec change, the controls are simply different, so this was not an >>> option and I had to opt for keeping the whole driver around. >> >> It seems that we may need to add conditions to the UCM syntax. There >> are several ways to do it. For your specific purpose it may look like >> "if the control exist, use this config" or so. >> >> Another approach might be to add something to the decision code which >> top UCM config file should be loaded. Actually, we rely on the card >> name / long_name only. It seems that the probe might be extended here. > > Yes, currently a UCM profile is very hard-coded, hence it's quite > tightly coupled with the kernel driver implementation details. It > makes the UCM parser code implementation easier, while it induces this > kind of incompatibility if we want to change something in the kernel > side... > > Another (rather tangential) improvement would be to introduce some > validator in the kernel or in the UCM side to check whether the given > string names are OK or not. A generic kcontrol element validator > might be worth not only for UCM but in general, because lots of ASoC > drivers tend to use any funky string names, and currently we accept > them without strict checks. Yes, we need another conformance tool for the control interface and do more checking when the patches are accepted. I agree that the ASoC tree is too much benevolent in this area. Jaroslav
On Sat, 26 Oct 2019 19:11:27 +0200, Jaroslav Kysela wrote: > > Dne 26. 10. 19 v 9:37 Takashi Iwai napsal(a): > > On Fri, 25 Oct 2019 23:03:26 +0200, > > Jaroslav Kysela wrote: > >> > >> Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a): > >>> Hi Jaroslav and all, > >>> > >>> On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > >>> > >>>> the single user. Another problem is that we are not able to review all those > >>>> mistakes at the merge time. It is not a complain but a true fact. > >>> > >>> but the strings are in kernel patches, so even if all UCM files don't > >>> go through the list, we can always review when the strings are added > >>> in kernel, right? > >> > >> My point is that we already did this incomplete review (the wrong > >> strings are in the current kernel). We cannot prevent to avoid those > >> code merges, we are just human. I just don't think that the driver / > >> control names should be part of the don't-break-the-userspace policy. > > > > It's a similar situation like the long-time discussion of tracing: > > when the kernel broke latencytop by changing the tracing format, we > > had to revert it in the end although the tracing format itself isn't > > strictly a "standard kernel ABI". The consensus is: if upgrading the > > kernel breaks anything *significant*, it's a regression and no-go. > > It's not about whether it's a part of ABI or not. > > > > In our particular case, the strings you wanted to fix are the ones > > that are actually hard-coded by the UCM profiles that are known to be > > really used on major systems. That's the only reason of NAK. If it > > were for some other minor kcontrol elements, it would have been OK. > > > > Kai's work to integrate SOF to the legacy HDMI driver would be also OK > > because it provides the compatibility mode. That is, we have some > > excuse that it's not us but users (distros) who actually breaks by > > choosing the kernel configuration explicitly (and even there can be a > > workaround with a module option). > > We can add another kernel option for this fix, too. If you like to move > in this direction, I'll modify my patch. I don't think it's worth for that. With Kai's patch set, we're going to move (back) to the legacy HDMI codec driver in most cases, so these strings will be specifically to the SST driver -- which are used by only limited number of devices like Chromebook or such. That said, if the reason for the change is just about consistency, the best recipe is to forget it. > The question is, if the kernel should provide a hint to the user space > (UCM), that something *significant* changed. Perhaps, the component > field in the control API might be used for this purpose as I already > proposed. In this way, we can support both kernels (with old and new > control names). I'm afraid that the current UCM profile cannot handle any extension as of now. We may need to introduce some incompatible extensibility at first to UCM profile syntax. This can be a good topic for the next meeting. thanks, Takashi
diff --git a/Documentation/sound/designs/control-names.rst b/Documentation/sound/designs/control-names.rst index 7fedd0f33cd9..a5f6e3842df8 100644 --- a/Documentation/sound/designs/control-names.rst +++ b/Documentation/sound/designs/control-names.rst @@ -50,7 +50,7 @@ Internal internal SOURCE ~~~~~~ -=================== ================================================= +=================== =================================================== Master Master Mono Hardware Master @@ -92,7 +92,8 @@ SPDIF output only SPDIF In Digital In HDMI/DP either HDMI or DisplayPort -=================== ================================================= +HDMI/DP,pcm=<num> either HDMI or DisplayPort with the PCM device link +=================== =================================================== Exceptions (deprecated) ----------------------- diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c index ac1dea5f9d11..b49028c6fd10 100644 --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c @@ -618,7 +618,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &broxton_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/bxt_rt298.c b/sound/soc/intel/boards/bxt_rt298.c index adf416a49b48..caaf2f2af287 100644 --- a/sound/soc/intel/boards/bxt_rt298.c +++ b/sound/soc/intel/boards/bxt_rt298.c @@ -530,7 +530,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &broxton_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/glk_rt5682_max98357a.c b/sound/soc/intel/boards/glk_rt5682_max98357a.c index bd2d371f2acd..5474f28e0c31 100644 --- a/sound/soc/intel/boards/glk_rt5682_max98357a.c +++ b/sound/soc/intel/boards/glk_rt5682_max98357a.c @@ -548,7 +548,7 @@ static int glk_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &geminilake_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c b/sound/soc/intel/boards/kbl_da7219_max98357a.c index 537a88932bb6..367415efed9b 100644 --- a/sound/soc/intel/boards/kbl_da7219_max98357a.c +++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c @@ -548,7 +548,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &skylake_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c index 829f95fc4179..b30c2148d1f4 100644 --- a/sound/soc/intel/boards/kbl_da7219_max98927.c +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c @@ -977,7 +977,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &kabylake_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/kbl_rt5660.c b/sound/soc/intel/boards/kbl_rt5660.c index 74fe1f3a5479..0965d1f02b2c 100644 --- a/sound/soc/intel/boards/kbl_rt5660.c +++ b/sound/soc/intel/boards/kbl_rt5660.c @@ -470,7 +470,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &skylake_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/kbl_rt5663_max98927.c b/sound/soc/intel/boards/kbl_rt5663_max98927.c index 7cefda341fbf..9f420e978459 100644 --- a/sound/soc/intel/boards/kbl_rt5663_max98927.c +++ b/sound/soc/intel/boards/kbl_rt5663_max98927.c @@ -888,7 +888,7 @@ static int kabylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &skylake_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.c b/sound/soc/intel/boards/skl_hda_dsp_common.c index 58409b6e476e..f717b1d179bd 100644 --- a/sound/soc/intel/boards/skl_hda_dsp_common.c +++ b/sound/soc/intel/boards/skl_hda_dsp_common.c @@ -139,7 +139,7 @@ int skl_hda_hdmi_jack_init(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &pcm->hdmi_jack, NULL, 0); diff --git a/sound/soc/intel/boards/skl_nau88l25_max98357a.c b/sound/soc/intel/boards/skl_nau88l25_max98357a.c index 3ce8efbeed12..b009e2df25d3 100644 --- a/sound/soc/intel/boards/skl_nau88l25_max98357a.c +++ b/sound/soc/intel/boards/skl_nau88l25_max98357a.c @@ -607,7 +607,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &skylake_hdmi[i], diff --git a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c index 1a7ac8bdf543..0a6e650dc698 100644 --- a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c +++ b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c @@ -648,7 +648,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &skylake_hdmi[i], diff --git a/sound/soc/intel/boards/skl_rt286.c b/sound/soc/intel/boards/skl_rt286.c index 231349a47cc9..56ee4b55dce9 100644 --- a/sound/soc/intel/boards/skl_rt286.c +++ b/sound/soc/intel/boards/skl_rt286.c @@ -489,7 +489,7 @@ static int skylake_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &skylake_hdmi[i], NULL, 0); diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c index 4f6e58c3954a..862a7e35cb5c 100644 --- a/sound/soc/intel/boards/sof_rt5682.c +++ b/sound/soc/intel/boards/sof_rt5682.c @@ -277,7 +277,7 @@ static int sof_card_late_probe(struct snd_soc_card *card) list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { component = pcm->codec_dai->component; snprintf(jack_name, sizeof(jack_name), - "HDMI/DP, pcm=%d Jack", pcm->device); + "HDMI/DP,pcm=%d Jack", pcm->device); err = snd_soc_card_jack_new(card, jack_name, SND_JACK_AVOUT, &sof_hdmi[i], NULL, 0);
There is an inconsistency in the names for the HDMI/DP Jack control names between some ASoC drivers and the HDA HDMI driver which introduced this naming in 2011. There might be an impact for the user space (UCM). I will fix the UCM configurations when this patch is applied. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Cc: Mark Brown <broonie@kernel.org> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> --- Documentation/sound/designs/control-names.rst | 5 +++-- sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- sound/soc/intel/boards/bxt_rt298.c | 2 +- sound/soc/intel/boards/glk_rt5682_max98357a.c | 2 +- sound/soc/intel/boards/kbl_da7219_max98357a.c | 2 +- sound/soc/intel/boards/kbl_da7219_max98927.c | 2 +- sound/soc/intel/boards/kbl_rt5660.c | 2 +- sound/soc/intel/boards/kbl_rt5663_max98927.c | 2 +- sound/soc/intel/boards/skl_hda_dsp_common.c | 2 +- sound/soc/intel/boards/skl_nau88l25_max98357a.c | 2 +- sound/soc/intel/boards/skl_nau88l25_ssm4567.c | 2 +- sound/soc/intel/boards/skl_rt286.c | 2 +- sound/soc/intel/boards/sof_rt5682.c | 2 +- 13 files changed, 15 insertions(+), 14 deletions(-)