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

[PATCH v3 0/2] ASoC/SoundWire: Intel: add sdw BE dai trigger
by Bard Liao 24 Jun '22

24 Jun '22

For SOF IPC4, we need to set pipeline state in BE DAI trigger. @Vinod, Could you ack if the soundwire patch looks good to you? And we can go through the ASoC tree since the change is mainly on ASoC. v2: - Change "#if IS_ENABLED(CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE)" to "if (IS_ENABLED(CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE))" v3: - Change the multi-line comment style in "soundwire: Intel: add trigger callback" patch and take Vinod's Ack. Bard Liao (2): soundwire: Intel: add trigger callback ASoC: SOF: Intel: add trigger callback into sdw_callback drivers/soundwire/intel.c | 9 +++++++++ include/linux/soundwire/sdw_intel.h | 1 + sound/soc/sof/intel/hda-dai.c | 14 +++++++++++--- sound/soc/sof/intel/hda.c | 2 +- sound/soc/sof/intel/hda.h | 1 + 5 files changed, 23 insertions(+), 4 deletions(-) -- 2.17.1

1 2

UCM for Behringer UMC204HD broken
by GitHub issues - edited 24 Jun '22

24 Jun '22

alsa-project/alsa-ucm-conf issue #177 was edited from gregory112: This is related: [https://github.com/alsa-project/alsa-ucm-conf/pull/128](https://github.com/…. I came from this issue I filed in Pipewire: [https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2471](https://git…. So previously a while back, Behringer UMC204HD was detected as a single stereo input channel. This sound card has two inputs. However, just recently, the channel was separated into two mono channels, which was perfect. However, with the most recent update (I don't know if it's pipewire, pipewire-alsa, alsa-card-profiles, or alsa-ucm), it reverted back into the stereo single input (left/right) mode. What can I do to bring back the previous correct settings (apart from the bugs I filed in Pipewire)? I did not modify any ALSA UCM files. Previously, a while back: it is detected as UMC204HD 192k (stereo input). Then: UMC204HD 192k Line 1 (mono) and UMC204HD 192k Line 2 (mono) (this is how it's supposed to be, I think it's from the pull request above). Now: Back to UMC204HD 192k (stereo input). Might also be helpful but I am using pipewire. This is the output of `alsaucm listcards`: ``` ALSA lib ucm_subs.c:799:(uc_mgr_get_substituted_value) variable '${var:DirectCardName}' is not defined in this context! ALSA lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -22 ALSA lib parser.c:2957:(uc_mgr_scan_master_configs) Unable to open '-hw:2': Invalid argument alsaucm: error failed to get card list: Invalid argument ``` There is an error for hw:2, which I assume is the Behringer. Here is the result of `alsaucm -chw:2 dump text`. ``` ALSA lib ucm_subs.c:799:(uc_mgr_get_substituted_value) variable '${var:DirectCardName}' is not defined in this context! ALSA lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -22 alsaucm: error failed to open sound card hw:2: Invalid argument ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/177 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

UCM for Behringer UMC204HD broken
by GitHub issues - edited 24 Jun '22

24 Jun '22

alsa-project/alsa-ucm-conf issue #177 was edited from gregory112: This is related: [https://github.com/alsa-project/alsa-ucm-conf/pull/128](https://github.com/…. I came from this issue I filed in Pipewire: [https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2471](https://git…. So previously a while back, Behringer UMC204HD was detected as a single stereo input channel. This sound card has two inputs. However, just recently, the channel was separated into two mono channels, which was perfect. However, with the most recent update (I don't know if it's pipewire, pipewire-alsa, alsa-card-profiles, or alsa-ucm), it reverted back into the stereo single input (left/right) mode. What can I do to bring back the previous correct settings (apart from the bugs I filed in Pipewire)? I did not modify any ALSA UCM files. Previously, a while back: it is detected as UMC204HD 192k (stereo input). Then: UMC204HD 192k Line 1 (mono) and UMC204HD 192k Line 2 (mono) (this is how it's supposed to be, I think it's from the pull request above). Now: Back to UMC204HD 192k (stereo input). Might also be helpful but I am using pipewire. This is the output of `alsaucm listcards`: ``` ALSA lib ucm_subs.c:799:(uc_mgr_get_substituted_value) variable '${var:DirectCardName}' is not defined in this context! ALSA lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -22 ALSA lib parser.c:2957:(uc_mgr_scan_master_configs) Unable to open '-hw:2': Invalid argument alsaucm: error failed to get card list: Invalid argument ``` There is an error for hw:2, which I assume is the Behringer. Here is the result of `alsaucm -chw:2 dump text`. ``` ALSA lib ucm_subs.c:799:(uc_mgr_get_substituted_value) variable '${var:DirectCardName}' is not defined in this context! ALSA lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -22 ALSA lib parser.c:2957:(uc_mgr_scan_master_configs) Unable to open '-hw:2': Invalid argument alsaucm: error failed to get card list: Invalid argument ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/177 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v2 0/2] ASoC/SoundWire: Intel: add sdw BE dai trigger
by Bard Liao 24 Jun '22

24 Jun '22

For SOF IPC4, we need to set pipeline state in BE DAI trigger. @Vinod, Could you ack if the soundwire patch looks good to you? And we can go through the ASoC tree since the change is mainly on ASoC. v2: - Change "#if IS_ENABLED(CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE)" to "if (IS_ENABLED(CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE))" Bard Liao (2): soundwire: Intel: add trigger callback ASoC: SOF: Intel: add trigger callback into sdw_callback drivers/soundwire/intel.c | 8 ++++++++ include/linux/soundwire/sdw_intel.h | 1 + sound/soc/sof/intel/hda-dai.c | 14 +++++++++++--- sound/soc/sof/intel/hda.c | 2 +- sound/soc/sof/intel/hda.h | 1 + 5 files changed, 22 insertions(+), 4 deletions(-) -- 2.17.1

2 3

UCM for Behringer UMC204HD broken
by GitHub issues - edited 24 Jun '22

24 Jun '22

alsa-project/alsa-ucm-conf issue #177 was edited from gregory112: This is related: [https://github.com/alsa-project/alsa-ucm-conf/pull/128](https://github.com/…. I came from this issue I filed in Pipewire: [https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2471](https://git…. So previously a while back, Behringer UMC204HD was detected as a single stereo input channel. This sound card has two inputs. However, just recently, the channel was separated into two mono channels, which was perfect. However, with the most recent update (I don't know if it's pipewire, pipewire-alsa, alsa-card-profiles, or alsa-ucm), it reverted back into the stereo single input (left/right) mode. What can I do to bring back the previous correct settings (apart from the bugs I filed in Pipewire)? I did not modify any ALSA UCM files. Previously, a while back: it is detected as UMC204HD 192k (stereo input). Then: UMC204HD 192k Line 1 (mono) and UMC204HD 192k Line 2 (mono) (this is how it's supposed to be, I think it's from the pull request above). Now: Back to UMC204HD 192k (stereo input) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/177 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

UCM for Behringer UMC204HD broken
by GitHub issues - opened 24 Jun '22

24 Jun '22

alsa-project/alsa-ucm-conf issue #177 was opened from gregory112: This is related: [https://github.com/alsa-project/alsa-ucm-conf/pull/128](https://github.com/…. I came from this issue I filed in Pipewire: [https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2471](https://git…. So previously a while back, Behringer UMC204HD was detected as a single stereo input channel. This sound card has two inputs. However, just recently, the channel was separated into two mono channels, which was perfect. However, with the most recent update (I don't know if it's pipewire, pipewire-alsa, alsa-card-profiles, or alsa-ucm), it reverted back into the stereo single input (left/right) mode. What can I do to bring back the previous correct settings (apart from the bugs I filed in Pipewire)? I did not modify any ALSA UCM files. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/177 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH 00/11] ASoC: codecs: Series of fixes for realtek codecs used on RVPs
by Amadeusz Sławiński 23 Jun '22

23 Jun '22

Our tests platforms do use realtek codecs, while implementing avs driver and machine boards for it, we identified quite a lot of problems with those codec drivers. This series aims to fix those issues. Amadeusz Sławiński (8): ASoC: codecs: rt274: Move irq registration and cleanup ASoC: codecs: rt286: Move irq registration and cleanup ASoC: codecs: rt298: Move irq registration and cleanup ASoC: codecs: rt274: Enable irq only when needed ASoC: codecs: rt286: Enable irq only when needed ASoC: codecs: rt298: Enable irq only when needed ASoC: codecs: rt298: Fix NULL jack in interrupt ASoC: codecs: rt298: Fix jack detection Cezary Rojewski (3): ASoC: codecs: rt274: Always init jack_detect_work ASoC: codecs: rt286: Reorganize jack detect handling ASoC: codecs: rt298: Reorganize jack detect handling sound/soc/codecs/rt274.c | 67 +++++++++++---------- sound/soc/codecs/rt286.c | 56 ++++++++---------- sound/soc/codecs/rt286.h | 2 - sound/soc/codecs/rt298.c | 93 +++++++++++++----------------- sound/soc/codecs/rt298.h | 2 - sound/soc/intel/boards/broadwell.c | 6 +- sound/soc/intel/boards/bxt_rt298.c | 2 +- sound/soc/intel/boards/skl_rt286.c | 2 +- 8 files changed, 108 insertions(+), 122 deletions(-) -- 2.25.1

2 22

[PATCH 1/6] ASoC: dapm: Initialise kcontrol data for mux/demux controls
by Charles Keepax 23 Jun '22

23 Jun '22

DAPM keeps a copy of the current value of mux/demux controls, however this value is only initialised in the case of autodisable controls. This leads to false notification events when first modifying a DAPM kcontrol that has a non-zero default. Autodisable controls are left as they are, since they already initialise the value, and there would be more work required to support autodisable muxes where the first option isn't disabled and/or that isn't the default. Technically this issue could affect mixer/switch elements as well, although not on any of the devices I am currently running. There is also a little more work to do to address the issue there due to that side supporting stereo controls, so that has not been tackled in this patch. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- sound/soc/soc-dapm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 869c76506b669..a8e842e02cdc2 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -62,6 +62,8 @@ struct snd_soc_dapm_widget * snd_soc_dapm_new_control_unlocked(struct snd_soc_dapm_context *dapm, const struct snd_soc_dapm_widget *widget); +static unsigned int soc_dapm_read(struct snd_soc_dapm_context *dapm, int reg); + /* dapm power sequences - make this per codec in the future */ static int dapm_up_seq[] = { [snd_soc_dapm_pre] = 1, @@ -442,6 +444,9 @@ static int dapm_kcontrol_data_alloc(struct snd_soc_dapm_widget *widget, snd_soc_dapm_add_path(widget->dapm, data->widget, widget, NULL, NULL); + } else if (e->reg != SND_SOC_NOPM) { + data->value = soc_dapm_read(widget->dapm, e->reg) & + (e->mask << e->shift_l); } break; default: -- 2.30.2

2 6

[PATCH] ASoC: topology: KUnit: Followup prototype change of snd_soc_unregister_card()
by Uwe Kleine-König 23 Jun '22

23 Jun '22

snd_soc_unregister_card() was recently converted to return void. Only the first instance was adapted, so convert the remaining ones now to fix building the topology test. Reported-by: kernel test robot <lkp(a)intel.com> Fixes: 1892a991886a ("ASoC: core: Make snd_soc_unregister_card() return void") Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- Hello Mark, this fixes the issue the kernel test robot has reported in reply to the patch that became 1892a991886a. Up to you to apply on top of 1892a991886a or squash them together. I'm a bit surprised that sound/soc/soc-topology-test.c isn't built for ARCH=arm allmodconfig (that was my build test and that's the reason I didn't notice the issue before submission of my change). I didn't look into that though. Best regards Uwe sound/soc/soc-topology-test.c | 30 ++++++++++-------------------- 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/sound/soc/soc-topology-test.c b/sound/soc/soc-topology-test.c index 225d74355974..51d650bb05b7 100644 --- a/sound/soc/soc-topology-test.c +++ b/sound/soc/soc-topology-test.c @@ -313,8 +313,7 @@ static void snd_soc_tplg_test_load_with_null_ops(struct kunit *test) KUNIT_EXPECT_EQ(test, 0, ret); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); snd_soc_unregister_component(test_dev); } @@ -377,8 +376,7 @@ static void snd_soc_tplg_test_load_with_null_fw(struct kunit *test) KUNIT_EXPECT_EQ(test, 0, ret); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); snd_soc_unregister_component(test_dev); } @@ -426,8 +424,7 @@ static void snd_soc_tplg_test_load_empty_tplg(struct kunit *test) KUNIT_EXPECT_EQ(test, 0, ret); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); snd_soc_unregister_component(test_dev); } @@ -482,8 +479,7 @@ static void snd_soc_tplg_test_load_empty_tplg_bad_magic(struct kunit *test) KUNIT_EXPECT_EQ(test, 0, ret); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); snd_soc_unregister_component(test_dev); } @@ -538,8 +534,7 @@ static void snd_soc_tplg_test_load_empty_tplg_bad_abi(struct kunit *test) KUNIT_EXPECT_EQ(test, 0, ret); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); snd_soc_unregister_component(test_dev); } @@ -594,8 +589,7 @@ static void snd_soc_tplg_test_load_empty_tplg_bad_size(struct kunit *test) KUNIT_EXPECT_EQ(test, 0, ret); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); snd_soc_unregister_component(test_dev); } @@ -653,8 +647,7 @@ static void snd_soc_tplg_test_load_empty_tplg_bad_payload_size(struct kunit *tes /* cleanup */ snd_soc_unregister_component(test_dev); - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); } // TEST CASE @@ -702,8 +695,7 @@ static void snd_soc_tplg_test_load_pcm_tplg(struct kunit *test) snd_soc_unregister_component(test_dev); /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); } // TEST CASE @@ -755,8 +747,7 @@ static void snd_soc_tplg_test_load_pcm_tplg_reload_comp(struct kunit *test) } /* cleanup */ - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); } // TEST CASE @@ -804,8 +795,7 @@ static void snd_soc_tplg_test_load_pcm_tplg_reload_card(struct kunit *test) if (ret != 0 && ret != -EPROBE_DEFER) KUNIT_FAIL(test, "Failed to register card"); - ret = snd_soc_unregister_card(&kunit_comp->card); - KUNIT_EXPECT_EQ(test, 0, ret); + snd_soc_unregister_card(&kunit_comp->card); } /* cleanup */ base-commit: 1892a991886ace2c3450bec801df2cf4028a803a -- 2.36.1

2 2

[PATCH v2 14/16] soundwire: Use acpi_dev_for_each_child()
by Rafael J. Wysocki 23 Jun '22

23 Jun '22

From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Instead of walking the list of children of an ACPI device directly, use acpi_dev_for_each_child() to carry out an action for all of the given ACPI device's children. This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- v1 -> v2: * Make sure errors are not lost (Pierre-Louis). * Add R-by and T-by from Pierre-Louis. --- drivers/soundwire/slave.c | 117 ++++++++++++++++++++++++++-------------------- 1 file changed, 67 insertions(+), 50 deletions(-) Index: linux-pm/drivers/soundwire/slave.c =================================================================== --- linux-pm.orig/drivers/soundwire/slave.c +++ linux-pm/drivers/soundwire/slave.c @@ -127,6 +127,71 @@ static bool find_slave(struct sdw_bus *b return true; } +struct sdw_acpi_child_walk_data { + struct sdw_bus *bus; + struct acpi_device *adev; + struct sdw_slave_id id; + bool ignore_unique_id; +}; + +static int sdw_acpi_check_duplicate(struct acpi_device *adev, void *data) +{ + struct sdw_acpi_child_walk_data *cwd = data; + struct sdw_bus *bus = cwd->bus; + struct sdw_slave_id id; + + if (adev == cwd->adev) + return 0; + + if (!find_slave(bus, adev, &id)) + return 0; + + if (cwd->id.sdw_version != id.sdw_version || cwd->id.mfg_id != id.mfg_id || + cwd->id.part_id != id.part_id || cwd->id.class_id != id.class_id) + return 0; + + if (cwd->id.unique_id != id.unique_id) { + dev_dbg(bus->dev, + "Valid unique IDs 0x%x 0x%x for Slave mfg_id 0x%04x, part_id 0x%04x\n", + cwd->id.unique_id, id.unique_id, cwd->id.mfg_id, + cwd->id.part_id); + cwd->ignore_unique_id = false; + return 0; + } + + dev_err(bus->dev, + "Invalid unique IDs 0x%x 0x%x for Slave mfg_id 0x%04x, part_id 0x%04x\n", + cwd->id.unique_id, id.unique_id, cwd->id.mfg_id, cwd->id.part_id); + return -ENODEV; +} + +static int sdw_acpi_find_one(struct acpi_device *adev, void *data) +{ + struct sdw_bus *bus = data; + struct sdw_acpi_child_walk_data cwd = { + .bus = bus, + .adev = adev, + .ignore_unique_id = true, + }; + int ret; + + if (!find_slave(bus, adev, &cwd.id)) + return 0; + + /* Brute-force O(N^2) search for duplicates. */ + ret = acpi_dev_for_each_child(ACPI_COMPANION(bus->dev), + sdw_acpi_check_duplicate, &cwd); + if (ret) + return ret; + + if (cwd.ignore_unique_id) + cwd.id.unique_id = SDW_IGNORED_UNIQUE_ID; + + /* Ignore errors and continue. */ + sdw_slave_add(bus, &cwd.id, acpi_fwnode_handle(adev)); + return 0; +} + /* * sdw_acpi_find_slaves() - Find Slave devices in Master ACPI node * @bus: SDW bus instance @@ -135,8 +200,7 @@ static bool find_slave(struct sdw_bus *b */ int sdw_acpi_find_slaves(struct sdw_bus *bus) { - struct acpi_device *adev, *parent; - struct acpi_device *adev2, *parent2; + struct acpi_device *parent; parent = ACPI_COMPANION(bus->dev); if (!parent) { @@ -144,54 +208,7 @@ int sdw_acpi_find_slaves(struct sdw_bus return -ENODEV; } - list_for_each_entry(adev, &parent->children, node) { - struct sdw_slave_id id; - struct sdw_slave_id id2; - bool ignore_unique_id = true; - - if (!find_slave(bus, adev, &id)) - continue; - - /* brute-force O(N^2) search for duplicates */ - parent2 = parent; - list_for_each_entry(adev2, &parent2->children, node) { - - if (adev == adev2) - continue; - - if (!find_slave(bus, adev2, &id2)) - continue; - - if (id.sdw_version != id2.sdw_version || - id.mfg_id != id2.mfg_id || - id.part_id != id2.part_id || - id.class_id != id2.class_id) - continue; - - if (id.unique_id != id2.unique_id) { - dev_dbg(bus->dev, - "Valid unique IDs 0x%x 0x%x for Slave mfg_id 0x%04x, part_id 0x%04x\n", - id.unique_id, id2.unique_id, id.mfg_id, id.part_id); - ignore_unique_id = false; - } else { - dev_err(bus->dev, - "Invalid unique IDs 0x%x 0x%x for Slave mfg_id 0x%04x, part_id 0x%04x\n", - id.unique_id, id2.unique_id, id.mfg_id, id.part_id); - return -ENODEV; - } - } - - if (ignore_unique_id) - id.unique_id = SDW_IGNORED_UNIQUE_ID; - - /* - * don't error check for sdw_slave_add as we want to continue - * adding Slaves - */ - sdw_slave_add(bus, &id, acpi_fwnode_handle(adev)); - } - - return 0; + return acpi_dev_for_each_child(parent, sdw_acpi_find_one, bus); } #endif

3 4