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

[PATCH] Make top/rear speaker, mute and micmute leds work on HP x360 14-ea000 laptops that use Realtek 245 codec
by Jonathan Clarke 02 Nov '21

02 Nov '21

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210633 Signed-off-by: Jonathan Clarke <jonathan.a.clarke(a)gmail.com> --- sound/pci/hda/patch_realtek.c | 46 +++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 22d27b12c..e3c6d17ea 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4409,6 +4409,13 @@ static void alc245_fixup_hp_x360_amp(struct hda_codec *codec, case HDA_FIXUP_ACT_PRE_PROBE: spec->gpio_mask |= 0x01; spec->gpio_dir |= 0x01; + + /* use only amp at 0x02 for bottom(front) speaker, + * otherwise it is set to use 0x02,0x03,0x06 and when used in conjunction + * with top(rear) speaker 0x14, gets locked at full volume */ + static const hda_nid_t conn1[] = { 0x02 }; + snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn1), conn1); + break; case HDA_FIXUP_ACT_INIT: /* need to toggle GPIO to enable the amp */ @@ -4503,6 +4510,26 @@ static void alc236_fixup_hp_mute_led_coefbit(struct hda_codec *codec, } } +static void alc245_fixup_hp_x360_mute_leds(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + /* mic mute is set via gpio 0x04 */ + spec->micmute_led_polarity = 1; + codec->power_filter = led_power_filter; + alc_fixup_hp_gpio_led(codec, action, 0x00, 0x04); + + /* output mute is set via SET_COEF_INDEX,SET_PROC_COEF */ + spec->mute_led_polarity = 0; + spec->mute_led_coef.idx = 0x0b; + spec->mute_led_coef.mask = 0xffff; + spec->mute_led_coef.on = 0xa02f; + spec->mute_led_coef.off = 0x7774; + snd_hda_gen_add_mute_led_cdev(codec, coef_mute_led_set); + } +} + /* turn on/off mic-mute LED per capture hook by coef bit */ static int coef_micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) @@ -6557,6 +6584,8 @@ enum { ALC269_FIXUP_HP_DOCK_GPIO_MIC1_LED, ALC280_FIXUP_HP_9480M, ALC245_FIXUP_HP_X360_AMP, + ALC245_FIXUP_HP_X360_MUTE_LEDS, + ALC245_FIXUP_HP_X360_GPIO_TOP_SPEAKER, ALC288_FIXUP_DELL_HEADSET_MODE, ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13, @@ -7293,6 +7322,21 @@ static const struct hda_fixup alc269_fixups[] = { [ALC245_FIXUP_HP_X360_AMP] = { .type = HDA_FIXUP_FUNC, .v.func = alc245_fixup_hp_x360_amp, + .chained = true, + .chain_id = ALC245_FIXUP_HP_X360_MUTE_LEDS + }, + [ALC245_FIXUP_HP_X360_MUTE_LEDS] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc245_fixup_hp_x360_mute_leds, + .chained = true, + .chain_id = ALC245_FIXUP_HP_X360_GPIO_TOP_SPEAKER + }, + [ALC245_FIXUP_HP_X360_GPIO_TOP_SPEAKER] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x14, 0x90170110 }, /* enable top(back) speaker in addition to bottom(front) speaker at 0x17 */ + { }, + } }, [ALC288_FIXUP_DELL_HEADSET_MODE] = { .type = HDA_FIXUP_FUNC, @@ -9003,6 +9047,8 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"}, {.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"}, {.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"}, + {.id = ALC245_FIXUP_HP_X360_MUTE_LEDS, .name = "alc245-hp-x360-mute-leds"}, + {.id = ALC245_FIXUP_HP_X360_GPIO_TOP_SPEAKER, .name = "alc245-hp-x360-gpio-top-speaker"}, {.id = ALC295_FIXUP_HP_OMEN, .name = "alc295-hp-omen"}, {.id = ALC285_FIXUP_HP_SPECTRE_X360, .name = "alc285-hp-spectre-x360"}, {.id = ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP, .name = "alc287-ideapad-bass-spk-amp"}, -- 2.25.1

3 6

[PATCH] ALSA: usb-audio: Line6 HX-Stomp XL USB_ID
by Jason Ormes 01 Nov '21

01 Nov '21

Adding the Line6 HX-Stomp XL USB_ID as it needs this fixed frequency quirk as well. The device is basically just the HX-Stomp with some more buttons on the face. I've Done some recording with it after adding it, and it seems to function properly with this fix. The Midi features appear to be working as well. Signed-off-by: Jason Ormes <skryking(a)gmail.com> --- sound/usb/format.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/format.c b/sound/usb/format.c index 50efccbffb8a..e8fc2c350a9f 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -414,6 +414,7 @@ static int line6_parse_audio_format_rates_quirk(struct snd_usb_audio *chip, case USB_ID(0x0e41, 0x4242): /* Line6 Helix Rack */ case USB_ID(0x0e41, 0x4244): /* Line6 Helix LT */ case USB_ID(0x0e41, 0x4246): /* Line6 HX-Stomp */ + case USB_ID(0x0e41, 0x4253): /* Line6 HX-Stomp XL*/ case USB_ID(0x0e41, 0x4247): /* Line6 Pod Go */ case USB_ID(0x0e41, 0x4248): /* Line6 Helix >= fw 2.82 */ case USB_ID(0x0e41, 0x4249): /* Line6 Helix Rack >= fw 2.82 */ -- 2.25.1

2 1

[PATCH] ALSA: usb-audio: Add registration quirk for JBL Quantum 400
by Alexander Tsoy 01 Nov '21

01 Nov '21

Add another device ID for JBL Quantum 400. It requires the same quirk as other JBL Quantum devices. Signed-off-by: Alexander Tsoy <alexander(a)tsoy.me> --- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 8929d9abe8aa..1d418c3fc598 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1749,6 +1749,7 @@ static const struct registration_quirk registration_quirks[] = { REG_QUIRK_ENTRY(0x0951, 0x16ea, 2), /* Kingston HyperX Cloud Flight S */ REG_QUIRK_ENTRY(0x0ecb, 0x1f46, 2), /* JBL Quantum 600 */ REG_QUIRK_ENTRY(0x0ecb, 0x1f47, 2), /* JBL Quantum 800 */ + REG_QUIRK_ENTRY(0x0ecb, 0x1f4c, 2), /* JBL Quantum 400 */ REG_QUIRK_ENTRY(0x0ecb, 0x2039, 2), /* JBL Quantum 400 */ REG_QUIRK_ENTRY(0x0ecb, 0x203c, 2), /* JBL Quantum 600 */ REG_QUIRK_ENTRY(0x0ecb, 0x203e, 2), /* JBL Quantum 800 */ -- 2.32.0

2 1

[PATCH v1 0/4] Add tfa9897 speaker/receiver modes switching
by Vincent Knecht 31 Oct '21

31 Oct '21

Two tfa9897 are used in tandem on some devices (eg. alcatel-idol347) to drive two speakers, for both receiver (earpiece) and speaker modes. This series: 1. adds a control to allow enabling only one tfa9897/speaker (for the typical phone-call usecase) 2. adds a control to switch between speaker and receiver modes 3. adds support for an optional gpio also used to switch modes Stephan Gerhold (1): ASoC: codecs: tfa989x: Add switch to allow disabling amplifier Vincent Knecht (3): ASoC: codecs: tfa989x: Add support for tfa9897 RCV bit ASoC: dt-bindings: nxp, tfa989x: Add rcv-gpios property for tfa9897 ASoC: codecs: tfa989x: Add support for tfa9897 optional rcv-gpios .../bindings/sound/nxp,tfa989x.yaml | 10 ++++ sound/soc/codecs/tfa989x.c | 47 ++++++++++++++++++- 2 files changed, 55 insertions(+), 2 deletions(-) -- 2.31.1

4 9

RFT: implementation for MOTU FireWire series including CueMix DSP and CueMix FX
by Takashi Sakamoto 31 Oct '21

31 Oct '21

RFT: implementation of MOTU FireWire series CueMix DSP and CueMix FX Hi all, After investigation for protocols of MOTU FireWire series including features of CueMix DSP and CueMix FX, I've written implementation corresponding to the features in snd-firewire-ctl-services project[1]. If you are enough interested in it, would you please test the implementation? The first aim of this test request is to check whether the protocol implementation works as well out of my development environment. # Disclaimer * The aim of the work is to reveal relevant protocols so adequately and write the implementation. It is out of my scope to produce user-friendly applications such as GUI with cool user-delighted look and feel. (This is also the reason that the message is so long for general users.) # Acknowledgment When I made investigation plan for the protocols and evaluated the result of investigation, documents included in ffado source code[13] is helpful. The documentation includes a part of the result, while some parts are newly revealed in this time. I appreciate for document writers. # Current status * Below models are supported and I tested * 828 * 896 * 828mk2 * 896hd * 8 pre * Ultralite * 4 pre * Audio Express * 828mk3 (FireWire only/Hybrid) * Ultralite mk3 (FireWire only/Hybrid) * The most of control functions are available via ALSA control interface * Hardware metering support * Interaction support between on-board control component such as knob, utilizing notification mechanism of ALSA control interface # Requirements For the test, you need to solve long list of requirements since the protocol implementation is new and lays down user space as well as kernel space. I'm sorry for testers to discourage your motivation, but they are required... * Linux kernel v5.13 or later * a commit 66c6d1ef86ff ('ALSA: control: Add memory consumption limit to user controls')[2] is required since many user-defined control element sets are used. * Installation of backport codes for ALSA firewire stack * They comes from Linux kernel v5.16 prepatch (not released yet). * Please follow to instructions in my remote repository[3] * Installation of alsa-gobject v0.2.1 or later. * alsa-gobject project[4] provides libraries which perform as glue for several kind of language bindings to use UAPI of Linux sound subsystem. For detail, please refer to release announcement[5]. * Installation of libhinawa topic branch * libhinawa project[6] also provides library as glue for UAPI of ALSA firewire stack. * The topic branch (topic/motu-mixer-ioctl)[7] includes new APIs to use functions added in the kernel v5.16 prepatch. * Rust v1.51 or later * I use Rust programming language for the protocol implementation in user space side. * Build topic branch of snd-firewire-ctl-services * snd-firewire-ctl-services project[8] includes the series of implementation for protocols specific to ASICs/Vendors/Models. Additionally, as reference of service programs, it includes runtime implementation based on ALSA control interface and ALSA Sequencer interface. * The topic branch ('topic/motu-mixer-ioctl') includes implementation for the test. # Test procedure When the above requirements are satisfied, the service program can be build by below command line. It takes a bit long than compiling with C language since Rust compiler does more work than C (mainly due to type inference and lifetime check for safe runtime). $ cargo build -p snd-firewire-ctl-services The service program for MOTU FireWire series runs by below command line: $ cargo run --bin snd-firewire-motu-ctl-service CARD_ID The CARD_ID is the numeric ID of sound card corresponding to your device. You need to load ALSA firewire-motu driver in advance: $ sudo modprobe snd-firewire-motu $ cat /proc/asound/cards ... 2 [UltraLiteMk3 ]: FW-MOTU - UltraLiteMk3 MOTU UltraLiteMk3 (version:100800), GUID ... In the above example, CARD_ID should be 2. When the service program runs, you can see control elements via ALSA control interface. You can operate them by usual tools of ALSA control application, but I prefer 'qashctl' in 'qastools' project[11]. Due to specification of protocols defined by MOTU, notifications from the device for some controls are firstly available when isochronous packets are transmitted by the device. Please run any of ALSA PCM applications when testing. The aim of the request is whether the service program can be built and run out of my development environment. So I don't expect you so much. However, If you are interested, please check the other parts about which I concern: * The range of value for each control is valid or not. * Inverse evaluation of each control with boolean value. * The lack of control which should be produced by the service program. # Filing issues * Please use issue service in github.com[10]. * Preferable issues * The service program aborts when I operate control A. * The service program doesn't interact with on-board operation B. * The service program looks to be frozen when I operate C. * The behaviour of control element D is odd. * Unexpected issues * Why device A is not supported * It's preferable for you to take your time to cooperate with me if you wish. It might take a long time since the implementation lays down user space and kernel space. * If so, please file the issue to my remote repository for kernel prepatch[12]. * Why we have no GUI with cool look and feel * It's your work. The GUI application might be an ALSA control application which interacts with the service program. * I can not get which control value corresponds to actual ports * It is restriction under current design of ALSA control interface. We need to work for any extension to the design. * The name of control B is not user-friendly. * The name of controls are not fixed yet since we have few name convention for controls in studio-use equipments. It might corresponds to discussion in ALSA upstream. In my opinion, Linux audio developers have been enough lazy to the issue for recent decade. [1] https://github.com/alsa-project/snd-firewire-ctl-services/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [3] https://github.com/takaswie/snd-firewire-improve [4] https://github.com/alsa-project/alsa-gobject/ [5] https://lore.kernel.org/alsa-devel/20200623093239.GA68404@workstation/ [6[ https://github.com/alsa-project/libhinawa [7] https://github.com/alsa-project/libhinawa/tree/topic/motu-mixer-ioctl [8] https://github.com/alsa-project/snd-firewire-ctl-services/ [9] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/motu-m… [10] https://github.com/alsa-project/snd-firewire-ctl-services/issues [11] https://gitlab.com/sebholt/qastools [12] https://github.com/takaswie/snd-firewire-improve/issues [13] https://web.archive.org/web/20110704073441/http://subversion.ffado.org/brow… Cheers Takashi Sakamoto

1 0

[PATCH] HX-Stomp XL USB_ID.
by Jason Ormes 30 Oct '21

30 Oct '21

Signed-off-by: Jason Ormes <skryking(a)gmail.com> --- sound/usb/format.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/usb/format.c b/sound/usb/format.c index 50efccbffb8a..e8fc2c350a9f 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -414,6 +414,7 @@ static int line6_parse_audio_format_rates_quirk(struct snd_usb_audio *chip, case USB_ID(0x0e41, 0x4242): /* Line6 Helix Rack */ case USB_ID(0x0e41, 0x4244): /* Line6 Helix LT */ case USB_ID(0x0e41, 0x4246): /* Line6 HX-Stomp */ + case USB_ID(0x0e41, 0x4253): /* Line6 HX-Stomp XL*/ case USB_ID(0x0e41, 0x4247): /* Line6 Pod Go */ case USB_ID(0x0e41, 0x4248): /* Line6 Helix >= fw 2.82 */ case USB_ID(0x0e41, 0x4249): /* Line6 Helix Rack >= fw 2.82 */ -- 2.25.1

2 3

[PATCH] dt-bindings: sound: gtm601: convert to YAML
by David Heidelberg 29 Oct '21

29 Oct '21

Convert GTM601 binding to the YAML format. Signed-off-by: David Heidelberg <david(a)ixit.cz> --- .../devicetree/bindings/sound/gtm601.txt | 19 ----------- .../devicetree/bindings/sound/gtm601.yaml | 33 +++++++++++++++++++ 2 files changed, 33 insertions(+), 19 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/gtm601.txt create mode 100644 Documentation/devicetree/bindings/sound/gtm601.yaml diff --git a/Documentation/devicetree/bindings/sound/gtm601.txt b/Documentation/devicetree/bindings/sound/gtm601.txt deleted file mode 100644 index efa32a486c4a..000000000000 --- a/Documentation/devicetree/bindings/sound/gtm601.txt +++ /dev/null @@ -1,19 +0,0 @@ -GTM601 UMTS modem audio interface CODEC - -This device has no configuration interface. The sample rate and channels are -based on the compatible string - "option,gtm601" = 8kHz mono - "broadmobi,bm818" = 48KHz stereo - -Required properties: - - - compatible : one of - "option,gtm601" - "broadmobi,bm818" - - -Example: - -codec: gtm601_codec { - compatible = "option,gtm601"; -}; diff --git a/Documentation/devicetree/bindings/sound/gtm601.yaml b/Documentation/devicetree/bindings/sound/gtm601.yaml new file mode 100644 index 000000000000..804402c72798 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/gtm601.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/gtm601.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GTM601 UMTS modem audio interface CODEC + +maintainers: + - Angus Ainslie (Purism) <angus(a)akkea.ca> + +description: > + This device has no configuration interface. The sample rate and channels are + based on the compatible string + +properties: + compatible: + oneOf: + - items: + - const: broadmobi,bm818 + - const: option,gtm601 + - items: + - enum: + - broadmobi,bm818 # 48 kHz stereo + - option,gtm601 # 8 kHz mono + +additionalProperties: false + +examples: + - | + gtm601_codec { + compatible = "option,gtm601"; + }; -- 2.33.0

2 1

[PATCH v4 0/6] Multiple headphone codec driver support
by Brent Lu 29 Oct '21

29 Oct '21

Support multiple headphone drivers in same machine driver. In this case, both rt5682 and rt5682s are supported and enumerated by different ACPI HID "10EC5682" and "RTL5682". V2 Changes: - remove useless 'NULL', 'false' in if-condition - can use 'comp_ids' field alone to enumerate driver - add comma to the end of entry in structure initialization - keep the table of byt/cht/cml/icl untouched V3 Changes: - upstreamd from SOF github, PR#3200 - use new compatiable IDs to shrink the enumerate table of BYT and CHT - add 'const' to snd_soc_acpi_codecs structures V4 Changes: - add signoff to patch 4~6 Brent Lu (3): ASoC: soc-acpi: add comp_ids field for machine driver matching ASoC: Intel: sof_rt5682: detect codec variant in probe function ASoC: Intel: sof_rt5682: use comp_ids to enumerate rt5682s Pierre-Louis Bossart (3): ASoC: Intel: soc-acpi-byt: shrink tables using compatible IDs ASoC: Intel: soc-acpi-cht: shrink tables using compatible IDs ASoC: Intel: soc-acpi: use const for all uses of snd_soc_acpi_codecs include/sound/soc-acpi.h | 3 + sound/soc/intel/boards/sof_rt5682.c | 34 ++------- .../intel/common/soc-acpi-intel-adl-match.c | 11 ++- .../intel/common/soc-acpi-intel-bxt-match.c | 2 +- .../intel/common/soc-acpi-intel-byt-match.c | 68 +++++++----------- .../intel/common/soc-acpi-intel-cht-match.c | 69 +++++++------------ .../intel/common/soc-acpi-intel-cml-match.c | 8 +-- .../intel/common/soc-acpi-intel-glk-match.c | 2 +- .../intel/common/soc-acpi-intel-jsl-match.c | 43 ++++-------- .../intel/common/soc-acpi-intel-kbl-match.c | 12 ++-- .../intel/common/soc-acpi-intel-skl-match.c | 2 +- .../intel/common/soc-acpi-intel-tgl-match.c | 11 ++- sound/soc/soc-acpi.c | 24 ++++++- 13 files changed, 119 insertions(+), 170 deletions(-) -- 2.25.1

2 8

[PATCH 0/6] ASoC: Sanity checks and soc-topology updates
by Cezary Rojewski 29 Oct '21

29 Oct '21

Couple of soc-topology related changes and a use-after-free fix. Said fix and two sanity checks for soc-topology lead the way. While the use-after-free is quite obvious, the sanity checks are here to cover for cases where user malformed the topology file -or- access to filesystem somehow got interrupted during copy operation. We shouldn't be reading outside the file boundary. Afterward a change to soc_tplg_add_kcontrol(): device being passed to soc_tplg_add_dcontrol() from comp->dev to tplg->dev which corrects dev_xxx() invoked later on. Also, device used for topology memory allocations from component->dev to component->card->dev so memory gets freed each time card device (usually platform device) is removed rather than the component device what may happen less frequently. Dummy component gets smarter and no longer overrides hw_params if there are other components accociated with related struct snd_soc_pcm_runtime instance. Amadeusz Sławiński (5): ASoC: core: Remove invalid snd_soc_component_set_jack call ASoC: topology: Check for dapm widget completeness ASoC: topology: Use correct device for prints ASoC: topology: Change topology device to card device ASoC: Stop dummy from overriding hwparams Cezary Rojewski (1): ASoC: topology: Add header payload_size verification sound/soc/soc-core.c | 3 --- sound/soc/soc-topology.c | 34 ++++++++++++++++++++++++++++++---- sound/soc/soc-utils.c | 13 +++++++++++++ 3 files changed, 43 insertions(+), 7 deletions(-) -- 2.25.1

2 7

[RESEND, v2 0/2] ASoC: mediatek: Add support for MT8195 sound card with rt1011 and rt5682
by Trevor Wu 29 Oct '21

29 Oct '21

This series of patches adds support for mt8195 board with mt6359, rt1011 and rt5682. Patches are based on broonie tree "for-next" branch. Changes since v1: - refined code based on Pierre-Louis's suggestions - added missing of_node_put - fixed wrong fixup assignment on HDMITX Trevor Wu (2): ASoC: mediatek: mt8195: add machine driver with mt6359, rt1011 and rt5682 dt-bindings: mediatek: mt8195: add mt8195-mt6359-rt1011-rt5682 document .../sound/mt8195-mt6359-rt1011-rt5682.yaml | 47 + sound/soc/mediatek/Kconfig | 15 + sound/soc/mediatek/mt8195/Makefile | 1 + .../mt8195/mt8195-mt6359-rt1011-rt5682.c | 1155 +++++++++++++++++ 4 files changed, 1218 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml create mode 100644 sound/soc/mediatek/mt8195/mt8195-mt6359-rt1011-rt5682.c -- 2.18.0

2 3