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

[alsa-devel] [PATCH v1 0/2] Huawei WMI laptop extras driver
by Ayman Bagabas 15 May '19

15 May '19

Using the WMI BIOS management interface found on Huawei laptops, extra features such as micmute LED, charging thresholds, and fn-lock can be controlled. A platform driver has been implemented along with the existing WMI driver. The platform driver controls the LED, battery charging thresholds, and fn-lock. We enable sound micmute hooks to platform driver on Huawei laptops to get the LED to work. Ayman Bagabas (2): platform/x86: Huawei WMI laptop extras driver update sound: Enable micmute led for Huawei laptops drivers/platform/x86/Kconfig | 8 +- drivers/platform/x86/huawei-wmi.c | 578 +++++++++++++++++++++++++----- sound/pci/hda/patch_realtek.c | 9 +- 3 files changed, 504 insertions(+), 91 deletions(-) -- 2.20.1

2 4

[alsa-devel] WARNING in snd_info_free_entry
by syzbot 15 May '19

15 May '19

Hello, syzbot found the following crash on: HEAD commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=16ae9974a00000 kernel config: https://syzkaller.appspot.com/x/.config?x=95aff7278e7ff25e dashboard link: https://syzkaller.appspot.com/bug?extid=131dee8780c719bc6afb compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173f3574a00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+131dee8780c719bc6afb(a)syzkaller.appspotmail.com snd_usb_toneport 6-1:0.0: set_interface failed snd_usb_toneport 6-1:0.0: Line 6 POD Studio UX2 now disconnected ------------[ cut here ]------------ list_del corruption. prev->next should be ffff8881d13fa728, but was ffff8881d82ebd68 WARNING: CPU: 1 PID: 1477 at lib/list_debug.c:51 __list_del_entry_valid+0x101/0x170 lib/list_debug.c:51 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 1477 Comm: kworker/1:2 Not tainted 5.1.0-rc3+ #8 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 panic+0x292/0x5e1 kernel/panic.c:214 __warn.cold+0x20/0x53 kernel/panic.c:571 report_bug+0x262/0x2a0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:__list_del_entry_valid+0x101/0x170 lib/list_debug.c:51 Code: c4 08 31 c0 41 5c 41 5d c3 4c 89 e2 48 c7 c7 20 f7 d8 85 e8 1c 2a 35 ff 0f 0b 31 c0 eb c6 48 c7 c7 80 f7 d8 85 e8 0a 2a 35 ff <0f> 0b 31 c0 eb b4 48 c7 c7 e0 f7 d8 85 e8 f8 29 35 ff 0f 0b 31 c0 RSP: 0018:ffff8881d7a1f078 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881d13fa630 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8127bbcd RDI: ffffed103af43e01 RBP: ffff8881d13fa640 R08: ffff8881d7a10000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881d13fad68 R13: ffff8881d7f1d858 R14: ffff8881d13fa630 R15: ffff8881d13fa718 __list_del_entry include/linux/list.h:117 [inline] list_del include/linux/list.h:125 [inline] snd_info_free_entry+0x132/0x340 sound/core/info.c:795 snd_info_card_free+0x3e/0x80 sound/core/info.c:606 snd_card_do_free sound/core/init.c:469 [inline] release_card_device+0x63/0xd0 sound/core/init.c:156 device_release+0x78/0x210 drivers/base/core.c:1064 kobject_cleanup lib/kobject.c:662 [inline] kobject_release lib/kobject.c:691 [inline] kref_put include/linux/kref.h:67 [inline] kobject_put+0x17d/0x270 lib/kobject.c:708 put_device+0x1c/0x30 drivers/base/core.c:2205 snd_card_free_when_closed+0x35/0x50 sound/core/init.c:493 line6_disconnect.cold+0xa3/0xbc sound/usb/line6/driver.c:833 line6_probe+0xb1e/0x1140 sound/usb/line6/driver.c:799 usb_probe_interface+0x30d/0x7b0 drivers/usb/core/driver.c:361 really_probe+0x296/0x680 drivers/base/dd.c:509 driver_probe_device+0xf9/0x200 drivers/base/dd.c:671 __device_attach_driver+0x1c4/0x230 drivers/base/dd.c:778 bus_for_each_drv+0x15e/0x1e0 drivers/base/bus.c:454 __device_attach+0x21e/0x360 drivers/base/dd.c:844 bus_probe_device+0x1ec/0x2a0 drivers/base/bus.c:514 device_add+0xaf4/0x1700 drivers/base/core.c:2106 usb_set_configuration+0xdf2/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0xa8/0x110 drivers/usb/core/driver.c:266 really_probe+0x296/0x680 drivers/base/dd.c:509 driver_probe_device+0xf9/0x200 drivers/base/dd.c:671 __device_attach_driver+0x1c4/0x230 drivers/base/dd.c:778 bus_for_each_drv+0x15e/0x1e0 drivers/base/bus.c:454 __device_attach+0x21e/0x360 drivers/base/dd.c:844 bus_probe_device+0x1ec/0x2a0 drivers/base/bus.c:514 device_add+0xaf4/0x1700 drivers/base/core.c:2106 usb_new_device.cold+0x8b8/0x1030 drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x1ac9/0x35a0 drivers/usb/core/hub.c:5432 process_one_work+0x90a/0x1580 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 kthread+0x30e/0x420 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug 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 bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

2 1

[alsa-devel] [PATCH v2] ACPI / device_sysfs: change _ADR representation to 64 bits
by Pierre-Louis Bossart 14 May '19

14 May '19

Standards such as the MIPI DisCo for SoundWire 1.0 specification assume the _ADR field is 64 bits. _ADR is defined as an "Integer" represented as 64 bits since ACPI 2.0 released in 2002. The low levels already use _ADR as 64 bits, e.g. in struct acpi_device_info. This patch bumps the representation used for sysfs to 64 bits. To avoid any compatibility/ABI issues, the printf format is only extended to 16 characters when the actual _ADR value exceeds the 32 bit maximum. Example with a SoundWire device, the results show the complete vendorID and linkID which were omitted before: Before: $ more /sys/bus/acpi/devices/device\:38/adr 0x5d070000 After: $ more /sys/bus/acpi/devices/device\:38/adr 0x000010025d070000 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- v2: only use 64 bits when required to avoid compatibility issues (feedback from Vinod and Rafael) drivers/acpi/device_sysfs.c | 6 ++++-- include/acpi/acpi_bus.h | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c index 8940054d6250..7dda0ee05cd1 100644 --- a/drivers/acpi/device_sysfs.c +++ b/drivers/acpi/device_sysfs.c @@ -428,8 +428,10 @@ static ssize_t acpi_device_adr_show(struct device *dev, { struct acpi_device *acpi_dev = to_acpi_device(dev); - return sprintf(buf, "0x%08x\n", - (unsigned int)(acpi_dev->pnp.bus_address)); + if (acpi_dev->pnp.bus_address > 0xFFFFFFFF) + return sprintf(buf, "0x%016llx\n", acpi_dev->pnp.bus_address); + else + return sprintf(buf, "0x%08llx\n", acpi_dev->pnp.bus_address); } static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL); diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index f7981751ac77..9075e28ea60a 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -230,7 +230,7 @@ struct acpi_device_dir { /* Plug and Play */ typedef char acpi_bus_id[8]; -typedef unsigned long acpi_bus_address; +typedef u64 acpi_bus_address; typedef char acpi_device_name[40]; typedef char acpi_device_class[20]; -- 2.17.1

5 5

[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