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

Audio mem2mem devices aka asymmetric sample rate converters
by Sascha Hauer 09 Jun '22

09 Jun '22

Hi All, I am currently looking into getting the asymmetric sample rate converters (ASRC) found on some i.MX SoCs to do something useful. The ASRC units are completely independent units, i.e. independent of the rest of the audio subsystem. They can read from memory using the SDMA engine, convert sample rates and/or audio formats and write back to memory also using the SDMA engine. The ASRC on the i.MX8MN has four contexts to convert up to four streams simultanously. I am not aware of any other non i.MX SoCs having such a unit, but I am pretty sure they exist on other SoCs as well. There are likely two usecases for such a unit. First would be to offload sample rate and format conversions to hardware. The other would be to synchronize different audio sources/sinks with different master clocks to each other when the master clocks drift away. How would such units be integrated into ASoC? I can think of two ways. First would be to create an separate audio card from them which records on one end and plays back with a different sample rate / format on the other end, in the v4l2 world that would be a classical mem2mem device. Is Alsa/ASoc prepared for something like this? Would it be feasible to go into such a direction? I haven't found any examples for this in the tree. The other way is to attach the ASRC to an existing audio card. That is done with the existing in-tree sound/soc/fsl/fsl_asrc.c and sound/soc/fsl/fsl_easrc.c drivers. This approach feels somehow limited as it's not possible to just do conversions without playing/recording something. OTOH userspace is unaffected which might be an advantage. What nags me with that approach is that it's currently not integrated into the simple-audio-card or audio-graph-card bindings. Currently the driver can only be used in conjunction with the fsl,imx-audio-* card driver. It seems backward to integrate such a generic ASRC unit into a special purpose audio card driver. The ASoC core is fully unaware of the ASRC with this approach currently which also doesn't look very appealing. OTOH I don't know if ASoC could handle this. Can ASoC handle for example a chain of DAIs when there are different sample rates and formats in that chain? Currently I don't really know how to proceed. It would be great if you could share some thoughts to this topic. Thanks, Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 3

[PATCH 0/4] ALSA: input validation for control element writes
by Takashi Iwai 09 Jun '22

09 Jun '22

Hi, this is a patch set to add a new feature to ALSA control interface, a validation for the write to control elements. So far we rely fully on the driver implementation to deal with the user inputs with invalid values (e.g. a value outside the defined range). This patch set allows ALSA core to verify the input values beforehand and returns the error immediately if the validation fails. The feature is enabled with a new Kconfig for now, as it brings a slight performance overhead, although this could be turned on as default in most cases, IMO. The patch set contains a few preliminary cleanup patches. The essential change is only the last one. Takashi === Takashi Iwai (4): ASoC: topology: Drop superfluous check of CONFIG_SND_CTL_VALIDATION ALSA: control: Rename CONFIG_SND_CTL_VALIDATION to CONFIG_SND_CTL_DEBUG ALSA: control: Drop superfluous ifdef CONFIG_SND_CTL_DEBUG ALSA: control: Add input validation include/sound/control.h | 2 +- sound/core/Kconfig | 27 ++++++++++--- sound/core/control.c | 87 +++++++++++++++++++++++----------------- sound/soc/soc-topology.c | 2 +- 4 files changed, 73 insertions(+), 45 deletions(-) -- 2.35.3

1 4

[PATCH v3 0/2] Add software clock gating requirement check
by Srinivasa Rao Mandadapu 09 Jun '22

09 Jun '22

This patch set is to add software clock gating requirement check Changes Since V1: -- Use boolean flag for bool variable initialization instead of hard coding. Changes Since V1: -- Fix if check before reset control call Srinivasa Rao Mandadapu (2): soundwire: qcom: Add flag for software clock gating check ASoC: qcom: soundwire: Add software clock gating requirement check drivers/soundwire/qcom.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) -- 2.7.4

3 6

[PATCH v6 0/8] ASoC: mediatek: Add support for MT8186 SoC
by Jiaxin Yu 09 Jun '22

09 Jun '22

This series of patches adds support for Mediatek AFE of MT8186 Soc. Patches are based on broonie tree "for-next" branch. Changes since v5: - fix build error about function snd_soc_card_jack_new that modified by: Link: https://lore.kernel.org/r/20220408041114.6024-1-akihiko.odaki@gmail.com - some have been accepted, details are in the link below: Link: https://lore.kernel.org/all/165459931885.399031.2621579592368573898.b4-ty@k… Changes since v4: - [v5 07/20] - remove unsusd controls - [v5 09/20] - correct indent error - [v5 10/20] - [v5 13/20] - [v5 14/20] - fix the return value if the value is different from the previous value in mixer controls - [v5 17/20] - [v5 19/20] - correct the compatible name with '_' instead of '-' - [v5 18/20] - [v5 20/20] - correct the yaml after 'pip3 install dtschema --upgrade' Changes since v3: - [v4 09/18] - remove DEBUG_COEFF debugging code - [v4 10/18] - simplify the logic of the code - [v4 13/18] - split out the MT6366 bits into mt8186-mt6366-commom.c - fix build error of "error: 'struct dev_pm_info' has no member named 'runtime_error'" - fix bug of adda dai driver - add route for pcm interface channel 2. - [v4 15/18] - [v4 17/18] - commonize the configuration of the codec - move MT6366 common bits into mt8186-mt6366-common.c Changes since v2: - add a new compatible string "mediatek,mt6366-sound" - modify the log level for simplicity - use dev_err_probe(...) instead of dev_err(...) in dev probe() - optimized the logic of some code - use BIT() and GENMASK() macros to descript the registers Thanks for AngeloGioacchino's careful reviews. Changes since v1: [v2 01/17] - add a new ID to the existing mt6358 codec driver [v2 03/17] - modify log level in DAPM events - use standard numeric control with name ending in Switch - return 1 when the value changed in mixer control's .get callback [v2 05/17] - ending in Switch to the standard on/off controls - change to "HW Gain 1 Volume" and "HW Gain 2 Volume" [v2 09/17] - return an error in the default case rather than just picking one of the behaviours when do .set_fmt - use the new defines that are _PROVIDER_MASK, _DAIFMT_CBP_CFP and _DAIFMT_CBC_CFC [v2 10/17] [v2 11/17] - the clock and gpio are aplit out into separate patches The source file's GPL comment use c++ style, and the header fils's GPL comment use c style. We have added "Switch" after the names of all the controls that just are simple on/off. Jiaxin Yu (8): dt-bindings: mediatek: mt6358: add new compatible for using mt6366 ASoC: mediatek: mt8186: add platform driver ASoC: mediatek: mt8186: add mt8186-mt6366 common driver dt-bindings: mediatek: mt8186: add audio afe document ASoC: mediatek: mt8186: add machine driver with mt6366, da7219 and max98357 dt-bindings: mediatek: mt8186: add mt8186-mt6366-da7219-max98357 document ASoC: mediatek: mt8186: add machine driver with mt6366, rt1019 and rt5682s dt-bindings: mediatek: mt8186: add mt8186-mt6366-rt1019-rt5682s document .../devicetree/bindings/sound/mt6358.txt | 4 +- .../bindings/sound/mt8186-afe-pcm.yaml | 175 + .../sound/mt8186-mt6366-da7219-max98357.yaml | 75 + .../sound/mt8186-mt6366-rt1019-rt5682s.yaml | 75 + sound/soc/mediatek/Kconfig | 44 + sound/soc/mediatek/Makefile | 1 + sound/soc/mediatek/mt8186/Makefile | 22 + sound/soc/mediatek/mt8186/mt8186-afe-common.h | 235 ++ .../soc/mediatek/mt8186/mt8186-afe-control.c | 261 ++ sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 3009 +++++++++++++++++ .../mediatek/mt8186/mt8186-mt6366-common.c | 59 + .../mediatek/mt8186/mt8186-mt6366-common.h | 17 + .../mt8186/mt8186-mt6366-da7219-max98357.c | 1002 ++++++ .../mt8186/mt8186-mt6366-rt1019-rt5682s.c | 978 ++++++ 14 files changed, 5956 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml create mode 100644 sound/soc/mediatek/mt8186/Makefile create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-common.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-control.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-pcm.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-common.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-common.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-da7219-max98357.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-rt1019-rt5682s.c -- 2.25.1

2 10

About Cleanup ASoC
by Kuninori Morimoto 09 Jun '22

09 Jun '22

Hi ASoC Cc Mark, Pierre-Louis, Cezary I have very interesting to clean up ASoC. I think it is still very complex, thus, non flexible. I'm thinking that we want to cleanup... - Component with multi Card connection - fixed playback vs capture - fixed CPU vs Codec - DPCM connection vs normal connection About first topic, I guess the biggest reason why we have limitation is its connections. Text based image is a little bit difficult, but if my understanding was correct, current connections are... card <-> rtd <-> rtd <-> rtd <-> ... | | +--------|-----+---------------+-----------+ (A) | | | | +-> component -> component -> component -> ... | (CPU) (Codec) (Platform) | | | | | +-> dai -> dai -> dai -> dai -> ... Card has "component list", and Component has pointer to Card (A). This makes the limitation which blocking multiple Card connections, I think. One note here is that "Platform" doesn't have "DAI". So if rtd have something other connector list, let's say "ep" list here for now, instead of "dai", and remove Card <-> Component connection, I think the connection can be simple, and the issue can be gone, but what do you think ? card <-> rtd <-> rtd <-> rtd <-> ... | | dai dai dai dai | | | | | +--> ep --> ep --> ep -> ep -> ep -> ... | | | | | component component component (CPU) (Codec) (Platform) Here, ep is like this struct rtd_entry_point { struct list_head list; // list for rtd struct struct snd_soc_pcm_runtime *rtd; struct snd_soc_component *component; struct snd_soc_dai *dai; }; Current for_each_xxx() can be like this for_each_rtd_components() = for_each_rtd_ep() + ep_to_component() for_each_rtd_dais() = for_each_rtd_ep() + ep_to_dai() for_each_card_components() = for_each_card_rtds() + for_each_rtd_components() I guess Component can have multiple Card connection on this idea, but what do you think ? Maybe I'm misunderstanding and/or missing something, because ASoC is complex enough :) Please let me know if I was misunderstanding or missing. Thank you for your help !! Best regards --- Kuninori Morimoto

5 23

[syzbot] general protection fault in snd_virmidi_output_trigger
by syzbot 09 Jun '22

09 Jun '22

Hello, syzbot found the following issue on: HEAD commit: 952923ddc011 Merge tag 'pull-18-rc1-work.namei' of git://g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10b95d0bf00000 kernel config: https://syzkaller.appspot.com/x/.config?x=3096247591885bfa dashboard link: https://syzkaller.appspot.com/bug?extid=8e407e6b1dba0a275884 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+8e407e6b1dba0a275884(a)syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 18021 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-13842-g952923ddc011 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:snd_virmidi_output_trigger+0x82/0x130 sound/core/seq/seq_virmidi.c:169 Code: 8b ad 30 01 00 00 31 ff 89 de e8 d9 8b 4f fa 85 db 48 b8 00 00 00 00 00 fc ff df 41 0f 95 c4 48 8d 7d 1c 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 60 31 ff 44 88 RSP: 0018:ffffc9000c6e7c48 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff872af747 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 000000000000001c RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888078d6c801 R13: 000000007f012000 R14: ffff88814ab3c400 R15: 0000000000001000 FS: 00007fc5b5868700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020fec000 CR3: 0000000046903000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> snd_rawmidi_output_trigger sound/core/rawmidi.c:186 [inline] snd_rawmidi_output_trigger sound/core/rawmidi.c:182 [inline] snd_rawmidi_kernel_write1+0x548/0x870 sound/core/rawmidi.c:1502 snd_rawmidi_write+0x273/0xb90 sound/core/rawmidi.c:1555 vfs_write+0x269/0xac0 fs/read_write.c:589 ksys_write+0x1e8/0x250 fs/read_write.c:644 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fc5b4689109 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc5b5868168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fc5b479bf60 RCX: 00007fc5b4689109 RDX: 00000000fffffd2c RSI: 0000000020000000 RDI: 0000000000000004 RBP: 00007fc5b46e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fc5b4ccfb1f R14: 00007fc5b5868300 R15: 0000000000022000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:snd_virmidi_output_trigger+0x82/0x130 sound/core/seq/seq_virmidi.c:169 Code: 8b ad 30 01 00 00 31 ff 89 de e8 d9 8b 4f fa 85 db 48 b8 00 00 00 00 00 fc ff df 41 0f 95 c4 48 8d 7d 1c 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 60 31 ff 44 88 RSP: 0018:ffffc9000c6e7c48 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff872af747 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 000000000000001c RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888078d6c801 R13: 000000007f012000 R14: ffff88814ab3c400 R15: 0000000000001000 FS: 00007fc5b5868700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2bc27000 CR3: 0000000046903000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess): 0: 8b ad 30 01 00 00 mov 0x130(%rbp),%ebp 6: 31 ff xor %edi,%edi 8: 89 de mov %ebx,%esi a: e8 d9 8b 4f fa callq 0xfa4f8be8 f: 85 db test %ebx,%ebx 11: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 18: fc ff df 1b: 41 0f 95 c4 setne %r12b 1f: 48 8d 7d 1c lea 0x1c(%rbp),%rdi 23: 48 89 fa mov %rdi,%rdx 26: 48 c1 ea 03 shr $0x3,%rdx * 2a: 0f b6 04 02 movzbl (%rdx,%rax,1),%eax <-- trapping instruction 2e: 48 89 fa mov %rdi,%rdx 31: 83 e2 07 and $0x7,%edx 34: 38 d0 cmp %dl,%al 36: 7f 04 jg 0x3c 38: 84 c0 test %al,%al 3a: 75 60 jne 0x9c 3c: 31 ff xor %edi,%edi 3e: 44 rex.R 3f: 88 .byte 0x88 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

1 0

[PATCH v2 1/2] ASoC: dt-bindings: nxp,tfa989x: Add tfa9890 support
by Alexander Martinz 08 Jun '22

08 Jun '22

Document TFA9890 binding for tfa989x. Signed-off-by: Alexander Martinz <amartinz(a)shiftphones.com> Reviewed-by: Stephan Gerhold <stephan(a)gerhold.net> Acked-by: Rob Herring <robh(a)kernel.org> --- Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index b9b1dba40856..7f2e68ff6d34 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -15,6 +15,7 @@ allOf: properties: compatible: enum: + - nxp,tfa9890 - nxp,tfa9895 - nxp,tfa9897 -- 2.36.1

2 2

no input from razer headset microphone when using RAZER BASE STATION V2 CHROMA
by GitHub issues - opened 08 Jun '22

08 Jun '22

alsa-project/alsa-lib issue #236 was opened from fiercebrake: Greetings everyone! So I currently have a razer "blacksharck v2 pro" headset that i connect to a razer "base station v2 chroma" The razer base station is properly detected/listed by (arch) linux. Problem is though the card and mic are detected and listed, the mic has no actual input at all. For the mic to start showing/taking any input I need to manually unplug and replug the headset from the base station. The jack in the base station is a 4-pin 3.5mm (TRRS) jack This article/fix below seems to alleviate the problem, say 50% of the times. So I am wondering if there is anything else I can do via ALSA to completely fix the problem "https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture#Correctl…" Issue URL : https://github.com/alsa-project/alsa-lib/issues/236 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ALSA: hda/realtek: Add quirk for HP Dev One
by Tim Crawford 08 Jun '22

08 Jun '22

From: Jeremy Soller <jeremy(a)system76.com> Enables the audio mute LEDs and limits the mic boost to avoid picking up noise. Signed-off-by: Jeremy Soller <jeremy(a)system76.com> Signed-off-by: Tim Crawford <tcrawford(a)system76.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 7170e086f166..b0f954118e72 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9071,6 +9071,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x89c3, "Zbook Studio G9", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89c6, "Zbook Fury 17 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89ca, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8a78, "HP Dev One", ALC285_FIXUP_HP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300), SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), -- 2.35.3

2 1

[PATCH][next] ASoC: mediatek: mt8186: Fix a handful of spelling mistakes
by Colin Ian King 08 Jun '22

08 Jun '22

There are several spelling mistakes in dev_err messages. Fix them. Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 8 ++++---- sound/soc/mediatek/mt8186/mt8186-dai-adda.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c index 5ba28095b7da..255ffba637d3 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c @@ -137,25 +137,25 @@ static int mt8186_afe_gpio_adda_dl(struct device *dev, bool enable) if (enable) { ret = mt8186_afe_gpio_select(dev, MT8186_AFE_GPIO_CLK_MOSI_ON); if (ret) { - dev_err(dev, "%s(), MOSI CLK ON slect fail!\n", __func__); + dev_err(dev, "%s(), MOSI CLK ON select fail!\n", __func__); return ret; } ret = mt8186_afe_gpio_select(dev, MT8186_AFE_GPIO_DAT_MOSI_ON); if (ret) { - dev_err(dev, "%s(), MOSI DAT ON slect fail!\n", __func__); + dev_err(dev, "%s(), MOSI DAT ON select fail!\n", __func__); return ret; } } else { ret = mt8186_afe_gpio_select(dev, MT8186_AFE_GPIO_DAT_MOSI_OFF); if (ret) { - dev_err(dev, "%s(), MOSI DAT OFF slect fail!\n", __func__); + dev_err(dev, "%s(), MOSI DAT OFF select fail!\n", __func__); return ret; } ret = mt8186_afe_gpio_select(dev, MT8186_AFE_GPIO_CLK_MOSI_OFF); if (ret) { - dev_err(dev, "%s(), MOSI CLK ON slect fail!\n", __func__); + dev_err(dev, "%s(), MOSI CLK ON select fail!\n", __func__); return ret; } } diff --git a/sound/soc/mediatek/mt8186/mt8186-dai-adda.c b/sound/soc/mediatek/mt8186/mt8186-dai-adda.c index c66861fd197d..db71b032770d 100644 --- a/sound/soc/mediatek/mt8186/mt8186-dai-adda.c +++ b/sound/soc/mediatek/mt8186/mt8186-dai-adda.c @@ -341,7 +341,7 @@ static int mtk_adda_mtkaif_cfg_event(struct snd_soc_dapm_widget *w, if (afe_priv->mtkaif_chosen_phase[0] < 0 || afe_priv->mtkaif_chosen_phase[1] < 0) { dev_err(afe->dev, - "%s(), skip dealy setting mtkaif_chosen_phase[0/1]:%d/%d\n", + "%s(), skip delay setting mtkaif_chosen_phase[0/1]:%d/%d\n", __func__, afe_priv->mtkaif_chosen_phase[0], afe_priv->mtkaif_chosen_phase[1]); -- 2.35.3

2 1