April 2021 - Alsa-devel - mailman.alsa-project.org

[RESEND PATCH v2] ASoC: core: Don't set platform name when of_node is set
by Daniel Baluta 16 Apr '21

16 Apr '21

From: Daniel Baluta <daniel.baluta(a)nxp.com> A DAI link has 3 components: * CPU * platform * codec(s) A component is specified via: * name * of_node * dai_name In order to avoid confusion when building a sound card we disallow matching by both name and of_node (1). soc_check_tplg_fes allows overriding certain BE links by overriding BE link name. This doesn't work well if BE link was specified via DT, because we end up with a link with both name and of_node specified which is conflicting with (1). In order to fix this we need to: * override of_node if component was specified via DT * override name, otherwise. Signed-off-by: Daniel Baluta <daniel.baluta(a)nxp.com> --- sound/soc/soc-core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 522bae73640a..7a1c011a7fe0 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1648,7 +1648,11 @@ static void soc_check_tplg_fes(struct snd_soc_card *card) dev_err(card->dev, "init platform error"); continue; } - dai_link->platforms->name = component->name; + + if (component->dev->of_node) + dai_link->platforms->of_node = component->dev->of_node; + else + dai_link->platforms->name = component->name; /* convert non BE into BE */ if (!dai_link->no_pcm) { -- 2.27.0

2 1

[PATCH v2] ALSA: hda/hdmi: fix race in handling acomp ELD notification at resume
by Kai Vehmanen 16 Apr '21

16 Apr '21

When snd-hda-codec-hdmi is used with ASoC HDA controller like SOF (acomp used for ELD notifications), display connection change done during suspend, can be lost due to following sequence of events: 1. system in S3 suspend 2. DP/HDMI receiver connected 3. system resumed 4. HDA controller resumed, but card->deferred_resume_work not complete 5. acomp eld_notify callback 6. eld_notify ignored as power state is not CTL_POWER_D0 7. HDA resume deferred work completed, power state set to CTL_POWER_D0 This results in losing the notification, and the jack state reported to user-space is not correct. The check on step 6 was added in commit 8ae743e82f0b ("ALSA: hda - Skip ELD notification during system suspend"). It would seem with the deferred resume logic in ASoC core, this check is not safe. Fix the issue by modifying the check to use "dev.power.power_state.event" instead of ALSA specific card power state variable. BugLink: https://github.com/thesofproject/linux/issues/2825 Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/patch_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Changes for V2: - use codec->core.dev.power.power_state.event instead of card state - verified on multiple systems and confirmed that checking for PM_EVENT_ON is not sufficient -- when resuming from S3, state can be PM_EVENT_RESUME at eld_notify, and if notification is ignored in this case, the original bugis hit (monitor state upon resume is lost) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 5de3666a7101..4b2cc8cb55c4 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2654,7 +2654,7 @@ static void generic_acomp_pin_eld_notify(void *audio_ptr, int port, int dev_id) /* skip notification during system suspend (but not in runtime PM); * the state will be updated at resume */ - if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0) + if (codec->core.dev.power.power_state.event == PM_EVENT_SUSPEND) return; /* ditto during suspend/resume process itself */ if (snd_hdac_is_in_pm(&codec->core)) @@ -2840,7 +2840,7 @@ static void intel_pin_eld_notify(void *audio_ptr, int port, int pipe) /* skip notification during system suspend (but not in runtime PM); * the state will be updated at resume */ - if (snd_power_get_state(codec->card) != SNDRV_CTL_POWER_D0) + if (codec->core.dev.power.power_state.event == PM_EVENT_SUSPEND) return; /* ditto during suspend/resume process itself */ if (snd_hdac_is_in_pm(&codec->core)) base-commit: 1867068c322ea7a627fde8d947a9e40db32816a4 -- 2.31.0

2 1

[PATCH] ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 445 G7
by Jonas Witschel 16 Apr '21

16 Apr '21

The HP ProBook 445 G7 (17T32ES) uses ALC236. Like ALC236_FIXUP_HP_GPIO_LED, COEF index 0x34 bit 5 is used to control the playback mute LED, but the microphone mute LED is controlled using pin VREF instead of a COEF index. AlsaInfo: https://alsa-project.org/db/?f=0d3f4d1af39cc359f9fea9b550727ee87e5cf45a Signed-off-by: Jonas Witschel <diabonas(a)archlinux.org> --- sound/pci/hda/patch_realtek.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 00a15e7cfdb9..c4372d143051 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4445,6 +4445,25 @@ static void alc236_fixup_hp_mute_led(struct hda_codec *codec, alc236_fixup_hp_coef_micmute_led(codec, fix, action); } +static void alc236_fixup_hp_micmute_led_vref(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + spec->cap_mute_led_nid = 0x1a; + snd_hda_gen_add_micmute_led_cdev(codec, vref_micmute_led_set); + codec->power_filter = led_power_filter; + } +} + +static void alc236_fixup_hp_mute_led_micmute_vref(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + alc236_fixup_hp_mute_led_coefbit(codec, fix, action); + alc236_fixup_hp_micmute_led_vref(codec, fix, action); +} + #if IS_REACHABLE(CONFIG_INPUT) static void gpio2_mic_hotkey_event(struct hda_codec *codec, struct hda_jack_callback *event) @@ -6407,6 +6426,7 @@ enum { ALC285_FIXUP_HP_MUTE_LED, ALC236_FIXUP_HP_GPIO_LED, ALC236_FIXUP_HP_MUTE_LED, + ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF, ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, ALC295_FIXUP_ASUS_MIC_NO_PRESENCE, ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS, @@ -7653,6 +7673,10 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc236_fixup_hp_mute_led, }, + [ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc236_fixup_hp_mute_led_micmute_vref, + }, [ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET] = { .type = HDA_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { @@ -8070,6 +8094,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x8724, "HP EliteBook 850 G7", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8730, "HP ProBook 445 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT), SND_PCI_QUIRK(0x103c, 0x8760, "HP", ALC285_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED), -- 2.31.1

2 2

[PATCH] ALSA: isa: Fix inconsistent indenting
by Yang Li 16 Apr '21

16 Apr '21

Kernel test robot throws below warning -> smatch warnings: sound/isa/opti9xx/opti92x-ad1848.c:191 snd_opti9xx_init() warn: inconsistent indenting sound/isa/opti9xx/opti92x-ad1848.c:488 snd_opti9xx_init() warn: inconsistent indenting Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Yang Li <yang.lee(a)linux.alibaba.com> --- sound/isa/opti9xx/opti92x-ad1848.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/isa/opti9xx/opti92x-ad1848.c b/sound/isa/opti9xx/opti92x-ad1848.c index 08e61d9..234f023 100644 --- a/sound/isa/opti9xx/opti92x-ad1848.c +++ b/sound/isa/opti9xx/opti92x-ad1848.c @@ -188,7 +188,7 @@ static int snd_opti9xx_init(struct snd_opti9xx *chip, chip->mc_base_size = opti9xx_mc_size[hardware]; } #else - chip->mc_base_size = opti9xx_mc_size[hardware]; + chip->mc_base_size = opti9xx_mc_size[hardware]; #endif switch (hardware) { @@ -485,7 +485,7 @@ static int snd_opti9xx_configure(struct snd_opti9xx *chip, #endif /* CS4231 || OPTi93X */ #ifndef OPTi93X - outb(irq_bits << 3 | dma_bits, chip->wss_base); + outb(irq_bits << 3 | dma_bits, chip->wss_base); #else /* OPTi93X */ snd_opti9xx_write(chip, OPTi9XX_MC_REG(3), (irq_bits << 3 | dma_bits)); #endif /* OPTi93X */ -- 1.8.3.1

2 1

[PATCH 1/1] ALSA: hda/realtek: fix mic boost on Intel NUC 8
by Phil Calvin 16 Apr '21

16 Apr '21

Fix two bugs with the Intel HDA Realtek ALC233 sound codec present in Intel NUC NUC8i7BEH and probably a few other similar NUC models. These codecs advertise a 4-level microphone input boost amplifier on pin 0x19, but the highest two boost settings do not work correctly, and produce only low analog noise that does not seem to contain any discernible signal. There is an existing fixup for this exact problem but for a different PCI subsystem ID, so we re-use that logic. Changing the boost level also triggers a DC spike in the input signal that bleeds off over about a second and overwhelms any input during that time. Thankfully, the existing fixup has the side effect of making the boost control show up in userspace as a mute/unmute switch, and this keeps (e.g.) PulseAudio from fiddling with it during normal input volume adjustments. Finally, the NUC hardware has built-in inverted stereo mics. This patch also enables the usual fixup for this so the two channels cancel noise instead of the actual signal. Signed-off-by: Phil Calvin <phil(a)philcalvin.com> --- sound/pci/hda/patch_realtek.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 58946d069ee5..e1fd4c81965a 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6405,6 +6405,8 @@ enum { ALC269_FIXUP_LEMOTE_A1802, ALC269_FIXUP_LEMOTE_A190X, ALC256_FIXUP_INTEL_NUC8_RUGGED, + ALC233_FIXUP_INTEL_NUC8_DMIC, + ALC233_FIXUP_INTEL_NUC8_BOOST, ALC256_FIXUP_INTEL_NUC10, ALC255_FIXUP_XIAOMI_HEADSET_MIC, ALC274_FIXUP_HP_MIC, @@ -7122,6 +7124,16 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc233_fixup_lenovo_line2_mic_hotkey, }, + [ALC233_FIXUP_INTEL_NUC8_DMIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_inv_dmic, + .chained = true, + .chain_id = ALC233_FIXUP_INTEL_NUC8_BOOST, + }, + [ALC233_FIXUP_INTEL_NUC8_BOOST] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_limit_int_mic_boost + }, [ALC255_FIXUP_DELL_SPK_NOISE] = { .type = HDA_FIXUP_FUNC, .v.func = alc_fixup_disable_aamix, @@ -8265,6 +8277,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1c06, 0x2013, "Lemote A1802", ALC269_FIXUP_LEMOTE_A1802), SND_PCI_QUIRK(0x1c06, 0x2015, "Lemote A190X", ALC269_FIXUP_LEMOTE_A190X), SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED), + SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC), SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10), #if 0 -- 2.30.2

2 1

[PATCH] ASoC: soc-pcm: fixup soc_pcm_params_symmetry()
by Kuninori Morimoto 16 Apr '21

16 Apr '21

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 3a9067211122 ("ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()") cleanups soc_pcm_params_symmetry() by addig new __soc_pcm_params_symmetry() macro. It checks symmetry first, and checks each DAI settings if symmetry was true. But original code checked symmetric_rate : DAI_Link / CPU (A) symmetric_channels : DAI_Link / CPU / Codec (B) symmetric_sample_bits : DAI_Link / CPU / Codec (B) (A) was using for_each_rtd_cpu_dais() (B) was using for_each_rtd_dais() Current code is using (B) for all symmetric_xxx. This is bug. One note is that we can use .be_hw_params_fixup in DPCM case. This means, BE settings might be fixuped/updated by FE. It can be happen not only for rate, but for channels/sample_bits too. And also, DPCM uses dummy-DAI which will be used for all DPCM connectoin. ALSA SoC will clean DAI params (a) if it was last user (b). But dummy-DAI is used from many place, it might not be cleaned. static int soc_pcm_hw_clean(...) { ... for_each_rtd_dais(rtd, i, dai) { ... (b) if (snd_soc_dai_active(dai) == 1) (a) soc_pcm_set_dai_params(dai, NULL); ... } ... } The solution maybe (A1) Symmetric checks CPU only (A2) Symmetric checks both CPU / Codec, but ignores dummy-DAI This patch selects A1. For example, if Sound Card is exchanging all rate to 48kHz by using .be_hw_params_fixup() on DPCM, below can be happen. It is using 44100 Hz, but has mismatch between dummy-DAI which is keeping 48kHz from 1st aplay. # aplay 44100.wav # aplay 44100.wav => [kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: 44100 - 48000 [kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22 [kernel] fe.rsnd-dai.0: ASoC: hw_params BE failed -22 aplay: set_params:1407: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (23219 23220) PERIOD_SIZE: 1024 PERIOD_BYTES: 4096 PERIODS: 4 BUFFER_TIME: (92879 92880) BUFFER_SIZE: 4096 BUFFER_BYTES: 16384 TICK_TIME: 0 Fixes: 3a9067211122 ("ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- Hi Mark This patch is needed for latest linus tree (= for v5.12). Please let me know if you want (A2). sound/soc/soc-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 02968a4e52b4..92e95e4aef9f 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -388,7 +388,7 @@ static int soc_pcm_params_symmetry(struct snd_pcm_substream *substream, #define __soc_pcm_params_symmetry(name) \ symmetry = rtd->dai_link->symmetric_##name; \ - for_each_rtd_dais(rtd, i, dai) \ + for_each_rtd_cpu_dais(rtd, i, dai) \ symmetry |= dai->driver->symmetric_##name; \ \ if (symmetry) \ -- 2.25.1

2 3

[PATCH 0/1] ALSA: hda/realtek: fix mic boost on Intel NUC 8
by Phil Calvin 16 Apr '21

16 Apr '21

I realized that I mistakenly sent this patch only to the listserv, and not directly to the relevant maintainers as I should have. I'm sorry for my error and the resulting list noise! A big thank you to everybody that helps maintain the Intel HDA subsystem. It is a well-documented and clear codebase to enter as a first-time kernel hacker. Thanks also to Dr. Iwai for `hda-emu`, which saved me a lot of rebooting while testing. I have tested the patch on this hardware both by recompiling the relevant modules and running them with the 5.10 kernel distributed in Debian `testing`, and atop the 5.12-rc6 kernel built with `make deb-pkg`. I could not decipher the ordering of the fixup tables, so I am of course happy to move these around to fit the organizational scheme as needed. I'm not an EE, but I am inclined to think the upper two boost values can probably be made to work by some kind of software workaround, given that they do produce analog noise coming from something. If you have any hunches about a possible workaround based on experience with other similar codecs, please point me to those fixups on- or off-list and I can try them out on my hardware. Phil Phil Calvin (1): ALSA: hda/realtek: fix mic boost on Intel NUC 8 sound/pci/hda/patch_realtek.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) -- 2.30.2

1 0

[PATCH v3 0/2] clean up dt_binding_check and dtbs_check warnings of renesas, rsnd.yaml
by Zhen Lei 15 Apr '21

15 Apr '21

v2 --> v3: Modified based on Rob's review comments. For example, "ports" and "port" are not allowed at the same time. For the details, please refer: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2539753.html v1 --> v2: The analysis was not clear in the previous version, "$ref: audio-graph.yaml#" is not required. It was then adjusted based on the following patch series: [1] https://lore.kernel.org/r/20210323163634.877511-1-robh@kernel.org/ v1: When I do dt_binding_check for all YAML files, below warning is reported: /root/mainline/Documentation/devicetree/bindings/sound/renesas,rsnd.example.dt.yaml: sound@ec500000: 'dais' is a required property From schema: /root/mainline/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml make dt_binding_check -j24 2>err.txt Before: cat err.txt | wc -l 2 After: cat err.txt | wc -l 0 make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/sound/renesas,rsnd.yaml -j24 2>err.txt Before: cat err.txt | wc -l 130 After: cat err.txt | wc -l 0 Zhen Lei (2): ASoC: dt-bindings: renesas, rsnd: Clear warning 'dais' is a required property ASoC: dt-bindings: renesas, rsnd: Clear warning 'ports' does not match any of the regexes .../devicetree/bindings/sound/renesas,rsnd.yaml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) -- 2.26.0.106.g9fadedd

2 4

[PATCH v2] ASoC: SOF: use current DAI config during resume
by Pierre-Louis Bossart 15 Apr '21

15 Apr '21

From: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Recently, the sof_pcm_dai_link_fixup() function was updated to match SSP config with the PCM hw_params and set the current_config for the DAI widget. But the sof_restore_pipelines() function still chooses the default config for the DAI widget upon resuming. Fix this to use the last used config when setting up the DAI widget during resume. Fixes: c943a586f6e49 ("ASoC: SOF: match SSP config with pcm hw params") Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- v2: used SHA1 from Mark's tree, not the SOF one. Resending on behalf of Ranjani -> added Signed-off-by sound/soc/sof/sof-audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/sof-audio.c b/sound/soc/sof/sof-audio.c index 0d0d47dc0246..510883cd9107 100644 --- a/sound/soc/sof/sof-audio.c +++ b/sound/soc/sof/sof-audio.c @@ -267,7 +267,7 @@ int sof_restore_pipelines(struct device *dev) /* restore dai links */ list_for_each_entry_reverse(dai, &sdev->dai_list, list) { struct sof_ipc_reply reply; - struct sof_ipc_dai_config *config = dai->dai_config; + struct sof_ipc_dai_config *config = &dai->dai_config[dai->current_config]; if (!config) { dev_err(dev, "error: no config for DAI %s\n", -- 2.25.1

2 1

[PATCH v1] ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function
by Lukasz Majczak 15 Apr '21

15 Apr '21

kabylake_ssp_fixup function uses snd_soc_dpcm to identify the codecs DAIs. The HW parameters are changed based on the codec DAI of the stream. The earlier approach to get snd_soc_dpcm was using container_of() macro on snd_pcm_hw_params. The structures have been modified over time and snd_soc_dpcm does not have snd_pcm_hw_params as a reference but as a copy. This causes the current driver to crash when used. This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime holds 2 dpcm instances (one for playback and one for capture). 2 codecs on the SSP are dmic (capture) and speakers (playback). Based on the stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime. Tested for all use cases of the driver. Based on similar fix in kbl_rt5663_rt5514_max98927.c from Harsha Priya <harshapriya.n(a)intel.com> and Vamshi Krishna Gopal <vamshi.krishna.gopal(a)intel.com> Cc: <stable(a)vger.kernel.org> # 5.4+ Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> --- Hi, This is basically a cherry-pick of this change: https://patchwork.kernel.org/project/alsa-devel/patch/1595432147-11166-1-gi… just applied to the kbl_da7219_max98927. Best regards, Lukasz sound/soc/intel/boards/kbl_da7219_max98927.c | 38 +++++++++++++++----- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/sound/soc/intel/boards/kbl_da7219_max98927.c b/sound/soc/intel/boards/kbl_da7219_max98927.c index 9dfe5bd9180d..4b7b4a044f81 100644 --- a/sound/soc/intel/boards/kbl_da7219_max98927.c +++ b/sound/soc/intel/boards/kbl_da7219_max98927.c @@ -284,11 +284,33 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime *rtd, struct snd_interval *chan = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS); struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); - struct snd_soc_dpcm *dpcm = container_of( - params, struct snd_soc_dpcm, hw_params); - struct snd_soc_dai_link *fe_dai_link = dpcm->fe->dai_link; - struct snd_soc_dai_link *be_dai_link = dpcm->be->dai_link; + struct snd_soc_dpcm *dpcm, *rtd_dpcm = NULL; + /* + * The following loop will be called only for playback stream + * In this platform, there is only one playback device on every SSP + */ + for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_PLAYBACK, dpcm) { + rtd_dpcm = dpcm; + break; + } + + /* + * This following loop will be called only for capture stream + * In this platform, there is only one capture device on every SSP + */ + for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_CAPTURE, dpcm) { + rtd_dpcm = dpcm; + break; + } + + if (!rtd_dpcm) + return -EINVAL; + + /* + * The above 2 loops are mutually exclusive based on the stream direction, + * thus rtd_dpcm variable will never be overwritten + */ /* * Topology for kblda7219m98373 & kblmax98373 supports only S24_LE, * where as kblda7219m98927 & kblmax98927 supports S16_LE by default. @@ -311,9 +333,9 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime *rtd, /* * The ADSP will convert the FE rate to 48k, stereo, 24 bit */ - if (!strcmp(fe_dai_link->name, "Kbl Audio Port") || - !strcmp(fe_dai_link->name, "Kbl Audio Headset Playback") || - !strcmp(fe_dai_link->name, "Kbl Audio Capture Port")) { + if (!strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Port") || + !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Headset Playback") || + !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Capture Port")) { rate->min = rate->max = 48000; chan->min = chan->max = 2; snd_mask_none(fmt); @@ -324,7 +346,7 @@ static int kabylake_ssp_fixup(struct snd_soc_pcm_runtime *rtd, * The speaker on the SSP0 supports S16_LE and not S24_LE. * thus changing the mask here */ - if (!strcmp(be_dai_link->name, "SSP0-Codec")) + if (!strcmp(rtd_dpcm->be->dai_link->name, "SSP0-Codec")) snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE); return 0; -- 2.25.1

3 2