May 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/5] ASoC: mediatek: Add basic PCM driver for MT8516
by Fabien Parent 14 May '19

14 May '19

This patch series add a basic PCM driver for MediaTek MT8516 with only support for ADDA Playback & Recording for now. Fabien Parent (5): ASoC: mediatek: make agent_disable, msb & hd fields optional dt-bindings: sound: Add MT8516 AFE PCM bindings ASoC: mediatek: Add MT8516 PCM driver ASoC: mediatek: mt8516: Add ADDA DAI driver ASoC: mediatek: mt8516: register ADDA DAI .../bindings/sound/mt8516-afe-pcm.txt | 28 + sound/soc/mediatek/Kconfig | 10 + sound/soc/mediatek/Makefile | 1 + sound/soc/mediatek/common/mtk-afe-fe-dai.c | 23 +- sound/soc/mediatek/mt8516/Makefile | 7 + sound/soc/mediatek/mt8516/mt8516-afe-common.h | 18 + sound/soc/mediatek/mt8516/mt8516-afe-pcm.c | 794 ++++++++++++++++++ sound/soc/mediatek/mt8516/mt8516-afe-regs.h | 218 +++++ sound/soc/mediatek/mt8516/mt8516-dai-adda.c | 316 +++++++ 9 files changed, 1406 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/mt8516-afe-pcm.txt create mode 100644 sound/soc/mediatek/mt8516/Makefile create mode 100644 sound/soc/mediatek/mt8516/mt8516-afe-common.h create mode 100644 sound/soc/mediatek/mt8516/mt8516-afe-pcm.c create mode 100644 sound/soc/mediatek/mt8516/mt8516-afe-regs.h create mode 100644 sound/soc/mediatek/mt8516/mt8516-dai-adda.c -- 2.20.1

3 7

[alsa-devel] [PATCH] Fix for Lenovo B50-70 inverted internal microphone bug.
by Michał Wadowski 14 May '19

14 May '19

Add patch for realtek codec in Lenovo B50-70. Bugzilla: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1524215 Signed-off-by: Michał Wadowski <wadosm(a)gmail.com> --- sound/pci/hda/patch_realtek.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 42cd3945e0de..36c18a5ba288 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5676,6 +5676,7 @@ enum { ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE, ALC233_FIXUP_LENOVO_MULTI_CODECS, ALC233_FIXUP_ACER_HEADSET_MIC, + ALC233_FIXUP_INV_DMIC, ALC294_FIXUP_LENOVO_MIC_LOCATION, ALC225_FIXUP_DELL_WYSE_MIC_NO_PRESENCE, ALC700_FIXUP_INTEL_REFERENCE, @@ -6384,6 +6385,10 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc233_fixup_lenovo_line2_mic_hotkey, }, + [ALC233_FIXUP_INV_DMIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_inv_dmic, + }, [ALC255_FIXUP_DELL_SPK_NOISE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_disable_aamix, @@ -6975,6 +6980,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x313c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION), SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI), SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC), + SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo B50-70", ALC233_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x17aa, 0x3978, "IdeaPad Y410P", ALC269_FIXUP_NO_SHUTUP), SND_PCI_QUIRK(0x17aa, 0x5013, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x17aa, 0x501a, "Thinkpad", ALC283_FIXUP_INT_MIC), @@ -7157,6 +7163,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC256_FIXUP_ASUS_AIO_GPIO2, .name = "alc256-asus-aio"}, {.id = ALC233_FIXUP_ASUS_MIC_NO_PRESENCE, .name = "alc233-asus"}, {.id = ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE, .name = "alc233-eapd"}, + {.id = ALC233_FIXUP_INV_DMIC, .name = "acl233-inv-dmic"}, {.id = ALC294_FIXUP_LENOVO_MIC_LOCATION, .name = "alc294-lenovo-mic"}, {.id = ALC225_FIXUP_DELL_WYSE_MIC_NO_PRESENCE, .name = "alc225-wyse"}, {.id = ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, .name = "alc274-dell-aio"}, -- 2.7.4

2 5

[alsa-devel] [PATCH v4][RFC] ASoC: modern style CPU
by Kuninori Morimoto 14 May '19

14 May '19

Hi Mark, Pierre-Louis I posted v3 refactoring modern style macro 2 weeks ago, and there is no response yet. I repost it, then, fixup a little bit. These are v4 of RFC of modern style CPU support. v3 -> v4 - rename xxx_CPU to xxx_FE rename xxx_Codec to xxx_BE rename xxx_PLATFORM to xxx_DMA v2 -> v3 - use __VA_ARGS__ We can use same macro for both With / Without Platform v1 -> v2 - Macro naming fixup - no more _CC, _CCP - has manual CPU/Codec/Platform setup

2 6

[alsa-devel] [PATCH V2 0/2] ASoC: ak4458: fail on probe if codec is not present
by Viorel Suman 13 May '19

13 May '19

AK4458 is probed successfully even if AK4458 is not present - this is caused by probe function returning no error on i2c access failure. The patchset fixes this. Changes since V1: Conditional statement rewritten as suggested by Mark. Viorel Suman (2): ASoC: ak4458: rstn_control - return a non-zero on error only ASoC: ak4458: add return value for ak4458_probe sound/soc/codecs/ak4458.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.7.4

3 5

[alsa-devel] Fix for Lenovo B50-70 inverted internal microphone bug
by Michał Wadowski 13 May '19

13 May '19

Hi. I prepared patch for this bug: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1524215 I tested this patch on Linux 5.1.0 and it fixes problem on my Lenovo B50-70 laptop.

2 1

Re: [alsa-devel] Boot procudure on HDA driver
by Takashi Iwai 13 May '19

13 May '19

On Mon, 13 May 2019 15:26:12 +0200, Kailang wrote: > > >That is, the step 2 and 3 are already out of the initialization phase, > >and they are normal runtime PM procedure. If the runtime depop code > >is superfluous for the runtime PM, you can skip it by checking the > >power_state, for example. But, again, it has nothing to do with the > >boot or not. It's just the normal runtime suspend and resume. > > Sorry! runtime suspend also need to run depop procedure. > It's not need to run depop procedure which was system power up during boot on alc225_shutup(). Hrm, it's still not clear to me. The alc255_shutup() is called during the boot up because the codec goes to the runtime suspend/resume. There should be no difference between this call during the boot time and the normal runtime PM behavior. Takashi > So, I think I can put checking runtime PM and Power_state and shutdown code in alc225_shutup(). > > for example: (put below code in alc225_shutup) > > If ( !pm_runtime_suspended(hda_codec_dev(codec)) || !codec->bus->shutdown || > codec->core.dev.power.power_state.event != PM_EVENT_SUSPEND || > codec->core.dev.power.power_state.event != PM_EVENT_HIBERNATE) > return; > But I don't know which runtime_suspend state was pm_runtime_suspended(hda_codec_dev(codec)). > ________________________________________ > 從: Takashi Iwai [tiwai(a)suse.de] > 寄件日期: 2019年5月13日下午 08:01 > 至: Kailang > 副本: (alsa-devel(a)alsa-project.org) > 主旨: Re: Boot procudure on HDA driver > > On Mon, 13 May 2019 13:52:32 +0200, > Kailang wrote: > > > > > > > > >Well, it's not clear to me whether you'd like to reduce the depop > > >procedure above or to add it somewhere else. Could you clarify? > > > > This depop procedure in alc225_shutup. it doesn't need to run in system boot up. > > > > If system boot up, it will run alc225_init() already. alc225_init() include power up depop procedure. > > So, if system boot up, it only need to run depop procedure in alc225_init(). > > This is the runtime suspend and resume. That is: > > > > The current boot up procedure was below. > > 1. alc225_init() > > ... which is called at the driver probe time, from > snd_hda_codec_build_controls(). > > Then the codec driver initialization finishes at this point, hence it > goes to runtime suspend. > > > 2. alc225_shutup() ==> this include power off and suspend depop procedure. some codec run this field will have pop noise at boot up. > > ... which is a part of the codec runtime suspend. > > Then, the codec gets woken up for some access, and it performs the > runtime resume. > > > 3. alc225_init() > > ... which is a part of the codec runtime resume. > > That is, the step 2 and 3 are already out of the initialization phase, > and they are normal runtime PM procedure. If the runtime depop code > is superfluous for the runtime PM, you can skip it by checking the > power_state, for example. But, again, it has nothing to do with the > boot or not. It's just the normal runtime suspend and resume. > > > thanks, > > Takashi > > > > > > > > ________________________________________ > > 從: Takashi Iwai [tiwai(a)suse.de] > > 寄件日期: 2019年5月13日下午 07:30 > > 至: Kailang > > 副本: (alsa-devel(a)alsa-project.org) > > 主旨: Re: Boot procudure on HDA driver > > > > On Mon, 13 May 2019 12:36:36 +0200, > > Kailang wrote: > > > > > > > > > Maybe I confuse and I also confuse you. Sorry!! > > > > > > When system suspend, it will run alc_suspend(). alc_suspend() was include alc_shutup(). > > > > Right. > > > > > When system shutdown(power off), will it run alc_shutup()? > > > > Yes, it's called via alc_reboot_notify(). > > If spec->reboot_notify is defined, this supersedes the call, so you > > may define the callback if you'd need to avoid alc_shutup() call from > > there. > > > > > > > in our patch_realtek.c. > > > spec->shutup = alc225_shutup; > > > Some codec didn't run the depop procudure during boot up. > > > > > > Maybe disable EAPD and shutup PIN will cause pop noise. > > > But this procudure need to run in SUSPEND and HIBERNATE and Power off. > > > It also need to run it at runtime suspend. > > > > > > static void alc225_shutup(struct hda_codec *codec) > > > { > > > struct alc_spec *spec = codec->spec; > > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > > bool hp1_pin_sense, hp2_pin_sense; > > > > > > *********** depop procudure ****************************************** > > > if (!hp_pin) > > > hp_pin = 0x21; > > > > > > /* 3k pull low control for Headset jack. */ > > > alc_update_coef_idx(codec, 0x4a, 0, 3 << 10); > > > > > > hp1_pin_sense = snd_hda_jack_detect(codec, hp_pin); > > > hp2_pin_sense = snd_hda_jack_detect(codec, 0x16); > > > > > > if (hp1_pin_sense || hp2_pin_sense) > > > msleep(2); > > > > > > if (hp1_pin_sense) > > > snd_hda_codec_write(codec, hp_pin, 0, > > > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE); > > > if (hp2_pin_sense) > > > snd_hda_codec_write(codec, 0x16, 0, > > > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE); > > > > > > if (hp1_pin_sense || hp2_pin_sense) > > > msleep(85); > > > > > > if (hp1_pin_sense) > > > snd_hda_codec_write(codec, hp_pin, 0, > > > AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0); > > > if (hp2_pin_sense) > > > snd_hda_codec_write(codec, 0x16, 0, > > > AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0); > > > > > > if (hp1_pin_sense || hp2_pin_sense) > > > msleep(100); > > > > > > alc_auto_setup_eapd(codec, false); > > > snd_hda_shutup_pins(codec); > > > ************** depop procudure ************************************* > > > } > > > > Well, it's not clear to me whether you'd like to reduce the depop > > procedure above or to add it somewhere else. Could you clarify? > > > > > > thanks, > > > > Takashi > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > 從: Takashi Iwai [tiwai(a)suse.de] > > > 寄件日期: 2019年5月13日下午 05:42 > > > 至: Kailang > > > 副本: (alsa-devel(a)alsa-project.org) > > > 主旨: Re: Boot procudure on HDA driver > > > > > > On Mon, 13 May 2019 11:30:56 +0200, > > > Kailang wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Takashi Iwai <tiwai(a)suse.de> > > > > > Sent: Monday, May 13, 2019 5:11 PM > > > > > To: Kailang <kailang(a)realtek.com> > > > > > Cc: (alsa-devel(a)alsa-project.org) <alsa-devel(a)alsa-project.org> > > > > > Subject: Re: Boot procudure on HDA driver > > > > > > > > > > On Mon, 13 May 2019 11:00:18 +0200, > > > > > Kailang wrote: > > > > > > > > > > > > Hi Takashi, > > > > > > > > > > > > When System Boot up. > > > > > > The Hda Driver running step was as below. > > > > > > > > > > > > alc_init(); > > > > > > alc_shutup(); > > > > > > alc_init(); > > > > > > > > > > > > The depop procedure was put in spec->init_hook and spec->shutup. > > > > > > > > > > > > But I find more codec which run spec->shutup at boot up. It will occur pop > > > > > noise. > > > > > > If it doesn't run spec->shutup, it will not occur pop noise or reduce pop noise. > > > > > > > > > > > > How could the spec->shutup not run at boot up? > > > > > > > > > > > > I ever test to put the check in spec->shutup() for PM_EVENT_SUSPEND and > > > > > PM_EVENT_HIBERNATE and shutdown. > > > > > > But if power_save=1, it was have issue for this. > > > > > > Codec was idle already in power_save=1 state. If system go suspend, it will > > > > > not run spec->shutup() again. > > > > > > > > > > I guess it's a runtime PM, hence it's neither PM_EVENT_SUSPEND nor > > > > > PM_EVENT_HIBERNATE. > > > > > > > > > runtime PM and suspend and hibernate and shutdown need to run > > > > spec->shutup(). > > > > > > Is the call really mandatory? > > > > > > > It's no problem. > > > > But spec->shutup() doesn't need to run in boot up. > > > > > > The call of spec->shutup() at boot up *is* the runtime PM. > > > Or any other call path I overlooked? > > > > > > > And it will set power_save=1 on all dell machine. > > > > > > > > If (codec->auto_runtime_pm || codec->bus->shutdown || > > > > codec->core.dev.power.power_state.event == PM_EVENT_SUSPEND || > > > > codec->core.dev.power.power_state.event == PM_EVENT_HIBERNATE) > > > > > > > > So, I need to put upper check code in spec->shutup(). Right? > > > > Thanks. > > > > > > No, the auto_runtime_pm is for a completely different purpose. > > > > > > At the boot up, the runtime PM can be kicked in at any time. So if > > > you disable the shutup during the runtime PM, it means you'd need to > > > call the shutup at runtime PM completely. > > > > > > > > > Takashi > > > > > > > > > > > > Actually, if the shutup procedure makes the problem on a certain platform, just > > > > > skip it. It's an optional behavior and would be fine without it (of course only if > > > > > it's confirmed to work :) > > > > > > > > > > > > > > > Takashi > > > > > > > > > > ------Please consider the environment before printing this e-mail. > > > >

1 0

[alsa-devel] [PATCH] ASoC: max98090: remove 24-bit format support
by Yu-Hsuan Hsu 13 May '19

13 May '19

Remove 24-bit format support because it doesn't work now. We can revert this change after it really supports. (https://patchwork.kernel.org/patch/10783561/) Signed-off-by: Yu-Hsuan Hsu <yuhsuan(a)chromium.org> --- sound/soc/codecs/max98090.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 7619ea31ab50..b25b7efa9118 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2313,7 +2313,7 @@ int max98090_mic_detect(struct snd_soc_component *component, EXPORT_SYMBOL_GPL(max98090_mic_detect); #define MAX98090_RATES SNDRV_PCM_RATE_8000_96000 -#define MAX98090_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE) +#define MAX98090_FORMATS SNDRV_PCM_FMTBIT_S16_LE static const struct snd_soc_dai_ops max98090_dai_ops = { .set_sysclk = max98090_dai_set_sysclk, -- 2.21.0.1020.gf2820cf01a-goog

2 1

[alsa-devel] [PATCH v2] ALSA: hda: Fix race between creating and refreshing sysfs entries
by Amadeusz Sławiński 13 May '19

13 May '19

hda_widget_sysfs_reinit() can free underlying codec->widgets structure on which widget_tree_create() operates. Add locking to prevent such issues from happening. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110382 Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski(a)linux.intel.com> --- Changes since v1: - Moved mutexes around the callers - Added comments noting that functions should be called with mutex held --- include/sound/hdaudio.h | 1 + sound/hda/hdac_device.c | 7 +++++++ sound/hda/hdac_sysfs.c | 3 +++ 3 files changed, 11 insertions(+) diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h index 45f944d57982..85835d0c33cc 100644 --- a/include/sound/hdaudio.h +++ b/include/sound/hdaudio.h @@ -81,6 +81,7 @@ struct hdac_device { atomic_t in_pm; /* suspend/resume being performed */ /* sysfs */ + struct mutex widget_lock; struct hdac_widget_tree *widgets; /* regmap */ diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index 95b073ee4b32..4769f4c03e14 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -55,6 +55,7 @@ int snd_hdac_device_init(struct hdac_device *codec, struct hdac_bus *bus, codec->bus = bus; codec->addr = addr; codec->type = HDA_DEV_CORE; + mutex_init(&codec->widget_lock); pm_runtime_set_active(&codec->dev); pm_runtime_get_noresume(&codec->dev); atomic_set(&codec->in_pm, 0); @@ -141,7 +142,9 @@ int snd_hdac_device_register(struct hdac_device *codec) err = device_add(&codec->dev); if (err < 0) return err; + mutex_lock(&codec->widget_lock); err = hda_widget_sysfs_init(codec); + mutex_unlock(&codec->widget_lock); if (err < 0) { device_del(&codec->dev); return err; @@ -158,7 +161,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_register); void snd_hdac_device_unregister(struct hdac_device *codec) { if (device_is_registered(&codec->dev)) { + mutex_lock(&codec->widget_lock); hda_widget_sysfs_exit(codec); + mutex_unlock(&codec->widget_lock); device_del(&codec->dev); snd_hdac_bus_remove_device(codec->bus, codec); } @@ -404,7 +409,9 @@ int snd_hdac_refresh_widgets(struct hdac_device *codec, bool sysfs) } if (sysfs) { + mutex_lock(&codec->widget_lock); err = hda_widget_sysfs_reinit(codec, start_nid, nums); + mutex_unlock(&codec->widget_lock); if (err < 0) return err; } diff --git a/sound/hda/hdac_sysfs.c b/sound/hda/hdac_sysfs.c index fb2aa344981e..909d5ef1179c 100644 --- a/sound/hda/hdac_sysfs.c +++ b/sound/hda/hdac_sysfs.c @@ -395,6 +395,7 @@ static int widget_tree_create(struct hdac_device *codec) return 0; } +/* call with codec->widget_lock held */ int hda_widget_sysfs_init(struct hdac_device *codec) { int err; @@ -411,11 +412,13 @@ int hda_widget_sysfs_init(struct hdac_device *codec) return 0; } +/* call with codec->widget_lock held */ void hda_widget_sysfs_exit(struct hdac_device *codec) { widget_tree_free(codec); } +/* call with codec->widget_lock held */ int hda_widget_sysfs_reinit(struct hdac_device *codec, hda_nid_t start_nid, int num_nodes) { -- 2.17.1

2 1

[alsa-devel] [PATCH] ASoC: Intel: kbl: fix wrong number of channels
by Tzung-Bi Shih 13 May '19

13 May '19

Fix wrong setting on number of channels. The context wants to set constraint to 2 channels instead of 4. Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c index 7044d8c2b187..879f14257a3e 100644 --- a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c +++ b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c @@ -405,7 +405,7 @@ static const struct snd_pcm_hw_constraint_list constraints_dmic_channels = { }; static const unsigned int dmic_2ch[] = { - 4, + 2, }; static const struct snd_pcm_hw_constraint_list constraints_dmic_2ch = { -- 2.21.0.392.gf8f6787159e-goog

3 3

[alsa-devel] [PATCH] ASoC: SOF: nocodec: fix undefined reference
by Pierre-Louis Bossart 13 May '19

13 May '19

The nocodec option can be selected individually, leading to the following issue: sound/soc/sof/core.o: In function `snd_sof_device_probe': core.c:(.text+0x4af): undefined reference to `sof_nocodec_setup' Fix by selecting the SND_SOF_NOCODEC option as needed. Reported-by: Hulk Robot <hulkci(a)huawei.com> Reported-by: YueHaibing <yuehaibing(a)huawei.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/sof/Kconfig | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig index b204c65698f9..a9a1d502daae 100644 --- a/sound/soc/sof/Kconfig +++ b/sound/soc/sof/Kconfig @@ -44,7 +44,10 @@ config SND_SOC_SOF_OPTIONS if SND_SOC_SOF_OPTIONS config SND_SOC_SOF_NOCODEC - tristate "SOF nocodec mode Support" + tristate + +config SND_SOC_SOF_NOCODEC_SUPPORT + bool "SOF nocodec mode support" help This adds support for a dummy/nocodec machine driver fallback option if no known codec is detected. This is typically only @@ -80,7 +83,7 @@ if SND_SOC_SOF_DEBUG config SND_SOC_SOF_FORCE_NOCODEC_MODE bool "SOF force nocodec Mode" - depends on SND_SOC_SOF_NOCODEC + depends on SND_SOC_SOF_NOCODEC_SUPPORT help This forces SOF to use dummy/nocodec as machine driver, even though there is a codec detected on the real platform. This is @@ -135,6 +138,7 @@ endif ## SND_SOC_SOF_OPTIONS config SND_SOC_SOF tristate select SND_SOC_TOPOLOGY + select SND_SOC_SOF_NOCODEC if SND_SOC_SOF_NOCODEC_SUPPORT help This option is not user-selectable but automagically handled by 'select' statements at a higher level -- 2.17.1

2 1