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

[PATCH] ASoC: Intel: bytcr_rt5640: Add quirk for the Advantech MICA-071 tablet
by Hans de Goede 14 Dec '22

14 Dec '22

The Advantech MICA-071 tablet deviates from the defaults for a non CR Bay Trail based tablet in several ways: 1. It uses an analog MIC on IN3 rather then using DMIC1 2. It only has 1 speaker 3. It needs the OVCD current threshold to be set to 1500uA instead of the default 2000uA to reliable differentiate between headphones vs headsets Add a quirk with these settings for this tablet. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/boards/bytcr_rt5640.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index fb9d9e271845..ddd2625bed90 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -570,6 +570,21 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { BYT_RT5640_SSP0_AIF1 | BYT_RT5640_MCLK_EN), }, + { + /* Advantech MICA-071 */ + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Advantech"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MICA-071"), + }, + /* OVCD Th = 1500uA to reliable detect head-phones vs -set */ + .driver_data = (void *)(BYT_RT5640_IN3_MAP | + BYT_RT5640_JD_SRC_JD2_IN4N | + BYT_RT5640_OVCD_TH_1500UA | + BYT_RT5640_OVCD_SF_0P75 | + BYT_RT5640_MONO_SPEAKER | + BYT_RT5640_DIFF_MIC | + BYT_RT5640_MCLK_EN), + }, { .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ARCHOS"), -- 2.38.1

3 2

Re: [PATCH 2/2] ASoC: da7213: Add support for mono, set frame width to 32 when possible
by Mark Brown 14 Dec '22

14 Dec '22

On Wed, Dec 14, 2022 at 04:40:58AM +0000, David Rau wrote: > This adds the DAI mono mode support and set the frame width to 32 > > Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk(a)timesys.com> > Tested-by: David Rau <David.Rau.opensource(a)dm.renesas.com> > Signed-off-by: David Rau <David.Rau.opensource(a)dm.renesas.com> I only have patch 2 here, what's the story with dependencies?

1 0

[PATCH] ASoC: Intel: soc-acpi: update codec addr on 0C11/0C4F product
by Bard Liao 14 Dec '22

14 Dec '22

From: Gongjun Song <gongjun.song(a)intel.com> The unique ID is determined by the ADR pin level of rt1318. ODM changed design, update codec addr to match new design. Fixes: 0050e3d3d43d ("ASoC: Intel: soc-acpi: add SKU 0C11 SoundWire configuration") Signed-off-by: Gongjun Song <gongjun.song(a)intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/intel/common/soc-acpi-intel-rpl-match.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/common/soc-acpi-intel-rpl-match.c b/sound/soc/intel/common/soc-acpi-intel-rpl-match.c index 3c5229f41bb0..31b43116e3d8 100644 --- a/sound/soc/intel/common/soc-acpi-intel-rpl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-rpl-match.c @@ -112,7 +112,7 @@ static const struct snd_soc_acpi_adr_device rt1316_1_group2_adr[] = { static const struct snd_soc_acpi_adr_device rt1318_1_group1_adr[] = { { - .adr = 0x000131025D131801ull, + .adr = 0x000132025D131801ull, .num_endpoints = 1, .endpoints = &spk_l_endpoint, .name_prefix = "rt1318-1" -- 2.25.1

2 1

[PATCH] ASoC: mediatek: mt8195: add sof be ops to check audio active
by YC Hung 14 Dec '22

14 Dec '22

In MT8195 SOF design, both DSP and audio driver would access audio registers. Before DSP accesses audio registers, audio power and clock should be enabled. DSP will hang up if DSP access audio register but audio power and clock are disabled. Therefore, we add audio pm runtime active checking before accessing audio registers in SOF BE's callback hw_params function to avoid this situation. Signed-off-by: YC Hung <yc.hung(a)mediatek.com> --- sound/soc/mediatek/mt8195/mt8195-mt6359.c | 30 +++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/sound/soc/mediatek/mt8195/mt8195-mt6359.c b/sound/soc/mediatek/mt8195/mt8195-mt6359.c index 61be66f47723..4682748d82be 100644 --- a/sound/soc/mediatek/mt8195/mt8195-mt6359.c +++ b/sound/soc/mediatek/mt8195/mt8195-mt6359.c @@ -633,6 +633,32 @@ static const struct snd_soc_ops mt8195_rt1011_etdm_ops = { .hw_params = mt8195_rt1011_etdm_hw_params, }; +static int mt8195_sof_be_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = asoc_substream_to_rtd(substream); + struct snd_soc_component *cmpnt_afe = NULL; + struct snd_soc_pcm_runtime *runtime; + + /* find afe component */ + for_each_card_rtds(rtd->card, runtime) { + cmpnt_afe = snd_soc_rtdcom_lookup(runtime, AFE_PCM_NAME); + if (cmpnt_afe) + break; + } + + if (cmpnt_afe && !pm_runtime_active(cmpnt_afe->dev)) { + dev_err(rtd->dev, "afe pm runtime is not active!!\n"); + return -EINVAL; + } + + return 0; +} + +static const struct snd_soc_ops mt8195_sof_be_ops = { + .hw_params = mt8195_sof_be_hw_params, +}; + static int mt8195_rt1011_init(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_card *card = rtd->card; @@ -1272,24 +1298,28 @@ static struct snd_soc_dai_link mt8195_mt6359_dai_links[] = { .name = "AFE_SOF_DL2", .no_pcm = 1, .dpcm_playback = 1, + .ops = &mt8195_sof_be_ops, SND_SOC_DAILINK_REG(AFE_SOF_DL2), }, [DAI_LINK_SOF_DL3_BE] = { .name = "AFE_SOF_DL3", .no_pcm = 1, .dpcm_playback = 1, + .ops = &mt8195_sof_be_ops, SND_SOC_DAILINK_REG(AFE_SOF_DL3), }, [DAI_LINK_SOF_UL4_BE] = { .name = "AFE_SOF_UL4", .no_pcm = 1, .dpcm_capture = 1, + .ops = &mt8195_sof_be_ops, SND_SOC_DAILINK_REG(AFE_SOF_UL4), }, [DAI_LINK_SOF_UL5_BE] = { .name = "AFE_SOF_UL5", .no_pcm = 1, .dpcm_capture = 1, + .ops = &mt8195_sof_be_ops, SND_SOC_DAILINK_REG(AFE_SOF_UL5), }, }; -- 2.18.0

4 3

[PATCH] ASoC: wm8994: Fix potential deadlock
by Marek Szyprowski 14 Dec '22

14 Dec '22

Commit c0feea594e05 ("workqueue: don't skip lockdep work dependency in cancel_work_sync()") revealed the following locking issue in the wm8994 codec: ====================================================== WARNING: possible circular locking dependency detected 6.0.0-rc1-00001-gc0feea594e05-dirty #13097 Not tainted ------------------------------------------------------ kworker/1:1/32 is trying to acquire lock: c2bd4300 (&wm8994->accdet_lock){+.+.}-{3:3}, at: wm1811_mic_work+0x38/0xdc but task is already holding lock: f08f5f28 ((work_completion)(&(&wm8994->mic_work)->work)){+.+.}-{0:0}, at: process_one_work+0x1e4/0x778 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((work_completion)(&(&wm8994->mic_work)->work)){+.+.}-{0:0}: __cancel_work_timer+0x198/0x22c wm1811_jackdet_irq+0x124/0x238 process_one_work+0x288/0x778 worker_thread+0x44/0x504 kthread+0xf0/0x124 ret_from_fork+0x14/0x2c 0x0 -> #0 (&wm8994->accdet_lock){+.+.}-{3:3}: lock_acquire+0x124/0x3e4 __mutex_lock+0x90/0x948 mutex_lock_nested+0x1c/0x24 wm1811_mic_work+0x38/0xdc process_one_work+0x288/0x778 worker_thread+0x44/0x504 kthread+0xf0/0x124 ret_from_fork+0x14/0x2c 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&wm8994->mic_work)->work)); lock(&wm8994->accdet_lock); lock((work_completion)(&(&wm8994->mic_work)->work)); lock(&wm8994->accdet_lock); *** DEADLOCK *** 2 locks held by kworker/1:1/32: #0: c1c072a8 ((wq_completion)events_power_efficient){+.+.}-{0:0}, at: process_one_work+0x1e4/0x778 #1: f08f5f28 ((work_completion)(&(&wm8994->mic_work)->work)){+.+.}-{0:0}, at: process_one_work+0x1e4/0x778 stack backtrace: CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 6.0.0-rc1-00001-gc0feea594e05-dirty #13097 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_power_efficient wm1811_mic_work unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from check_noncircular+0xf0/0x158 check_noncircular from __lock_acquire+0x15e8/0x2a7c __lock_acquire from lock_acquire+0x124/0x3e4 lock_acquire from __mutex_lock+0x90/0x948 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from wm1811_mic_work+0x38/0xdc wm1811_mic_work from process_one_work+0x288/0x778 process_one_work from worker_thread+0x44/0x504 worker_thread from kthread+0xf0/0x124 kthread from ret_from_fork+0x14/0x2c Exception stack(0xf08f5fb0 to 0xf08f5ff8) ... --->8--- Fix this by dropping wm8994->accdet_lock while calling cancel_delayed_work_sync(&wm8994->mic_work) in wm1811_jackdet_irq(). Fixes: c0cc3f166525 ("ASoC: wm8994: Allow a delay between jack insertion and microphone detect") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- sound/soc/codecs/wm8994.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index d3cfd3788f2a..f810135e28d0 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3853,7 +3853,12 @@ static irqreturn_t wm1811_jackdet_irq(int irq, void *data) } else { dev_dbg(component->dev, "Jack not detected\n"); + /* Release wm8994->accdet_lock to avoid deadlock: + * cancel_delayed_work_sync() takes wm8994->mic_work internal + * lock and wm1811_mic_work takes wm8994->accdet_lock */ + mutex_unlock(&wm8994->accdet_lock); cancel_delayed_work_sync(&wm8994->mic_work); + mutex_lock(&wm8994->accdet_lock); snd_soc_component_update_bits(component, WM8958_MICBIAS2, WM8958_MICB2_DISCH, WM8958_MICB2_DISCH); -- 2.38.1

3 2

[PATCH v2] ASoC: rockchip: spdif: Add missing clk_disable_unprepare() in rk_spdif_runtime_resume()
by Wang Jingjin 14 Dec '22

14 Dec '22

rk_spdif_runtime_resume() may have called clk_prepare_enable() before return from failed branches, add missing clk_disable_unprepare() in this case. Fixes: f874b80e1571 ("ASoC: rockchip: Add rockchip SPDIF transceiver driver") Signed-off-by: Wang Jingjin <wangjingjin1(a)huawei.com> --- changes in v2: - Match the subject to the content --- sound/soc/rockchip/rockchip_spdif.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/rockchip/rockchip_spdif.c b/sound/soc/rockchip/rockchip_spdif.c index 8bef572d3cbc..5b4f00457587 100644 --- a/sound/soc/rockchip/rockchip_spdif.c +++ b/sound/soc/rockchip/rockchip_spdif.c @@ -88,6 +88,7 @@ static int __maybe_unused rk_spdif_runtime_resume(struct device *dev) ret = clk_prepare_enable(spdif->hclk); if (ret) { + clk_disable_unprepare(spdif->mclk); dev_err(spdif->dev, "hclk clock enable failed %d\n", ret); return ret; } -- 2.25.1

2 1

ucm2: add profile for the Samsung Galaxy Note II (Midas)
by GitHub pull_request - opened 14 Dec '22

14 Dec '22

alsa-project/alsa-ucm-conf pull request #250 was opened from FrostI7Alex: Might need few changes in the future, but for now - it works. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/250 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/250.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Re: [PATCH] Add HP Stream 8 to bytcr_rt5640.c
by Hans de Goede 14 Dec '22

14 Dec '22

Hello Moises, On 12/13/22 18:35, Moises Cardona wrote: > The HP Stream 8 tablet is identical to the HP Stream 7 in terms of the PCB, > with the exception of the added SIM Card Slot. > Therefore, I'm submitting this patch which properly initializes the audio > and enables the headphone jack to work, just like it does in the > HP Stream 7. > > Signed-off-by: Moises Cardona <moisesmcardona(a)gmail.com> Thank you for your patch. According to this review: http://techlife101.com/hp-stream-8-review/ The Stream 8 has 2 speakers, so you should drop the BYT_RT5640_MONO_SPEAKER part so that both speakers will be used. Regards, Hans > --- > sound/soc/intel/boards/bytcr_rt5640.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c > index fb9d9e271845..1d964b1ceff4 100644 > --- a/sound/soc/intel/boards/bytcr_rt5640.c > +++ b/sound/soc/intel/boards/bytcr_rt5640.c > @@ -796,6 +796,17 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { > BYT_RT5640_SSP0_AIF1 | > BYT_RT5640_MCLK_EN), > }, > + { /* HP Stream 8 */ > + .matches = { > + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), > + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "HP Stream 8 Tablet"), > + }, > + .driver_data = (void *)(BYTCR_INPUT_DEFAULTS | > + BYT_RT5640_MONO_SPEAKER | > + BYT_RT5640_JD_NOT_INV | > + BYT_RT5640_SSP0_AIF1 | > + BYT_RT5640_MCLK_EN), > + }, > { /* I.T.Works TW891 */ > .matches = { > DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),

1 0

[PATCH 0/2] dt-bindings: sound: ti, pcm3168a: json-schema conversion and fixes
by Geert Uytterhoeven 14 Dec '22

14 Dec '22

Hi all, This patch series is an attempt to convert the existing DT binding documentation for the Texas Instruments PCM3168A Audio Codec to json-schema ("another one bites the dust" ;-). It consists of two parts: 1. The actual DT binding conversion, 2. An RFC patch to fix the impedance mismatch between the bindings and the description in the Shimafuji Kingfisher board DTS. I'm not super-familiar with the audio details, so I would be very grateful to receive your comments. Thanks! Geert Uytterhoeven (2): dt-bindings: sound: ti,pcm3168a: Convert to json-schema [RFC] arm64: dts: renesas: ulcb-kf: Fix pcm3168a audio codec node .../devicetree/bindings/sound/ti,pcm3168a.txt | 56 ---------- .../bindings/sound/ti,pcm3168a.yaml | 105 ++++++++++++++++++ arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 5 +- 3 files changed, 107 insertions(+), 59 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/ti,pcm3168a.txt create mode 100644 Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml -- 2.25.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

4 9

Re: ASoC: soc-pcm: Don't zero TDM masks in __soc_pcm_open() breaks SOF Audio in Lenovo laptops
by Richard Fitzgerald 13 Dec '22

13 Dec '22

On 9/12/22 16:18, Mark Brown wrote: > On Fri, Dec 09, 2022 at 05:38:54PM +0200, Péter Ujfalusi wrote: >> On 09/12/2022 16:42, Pierre-Louis Bossart wrote: > >>> Agree with the analysis, so what would be the least bad recommendation? >>> a) revert the "don't zero TDM masks" patch >>> b) backport the change to use set_stream()? > >> I would vote for b) unless other platforms report regressions. > > I don't really care either way given the backport policy. Neither do I. If you want to minimize risk, revert the patch in older backports. Lessons learned: Don't hijack a data member to pass something different from what it is intended to hold. Don't depend on a bug. Don't assume all code is using a data member for what is supposed to be in that member.

3 2