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

Re: [PATCH 2/4] reset: add GPIO-based reset controller
by Krzysztof Kozlowski 09 Jan '24

09 Jan '24

On 28/12/2023 17:05, Sean Anderson wrote: > On 12/22/23 10:01, Krzysztof Kozlowski wrote: >> Add simple driver to control GPIO-based resets using the reset >> controller API for the cases when the GPIOs are shared and reset should >> be coordinated. The driver is expected to be used by reset core >> framework for ad-hoc reset controllers. > > How do we handle power sequencing? Often GPIOs need some pre/post delay in > order to ensure proper power sequencing. For regular reset drivers, this is > internal to the driver. It's not part of this patchset. Power sequencing is an old topic and generic solutions were failing, rejected, did not solve the problems, etc (choose your reason). Delays are device specific, so they go to drivers (depending on the compatible). Complex power sequencing is way too much for simplified reset-framework handling, so anyway it is expected you do it in your driver. > > Maybe something like > > my-device { > reset-gpios = <&gpio 555 GPIO_ACTIVE_LOW>; > reset-gpios-post-deassert-us = <100>; Feel free to add it later. This patchset, and actually all patches should, solves one problem while allowing you to extend it later. If there is a architectural problem in my approach not allowing you to extend it later, then we should discuss it. > }; > > Of course, this is a bit ambiguous if you have multiple devices using the same > GPIO with different delays. Maybe we take the max? But the driver below seems > to only have access to one device. Which I suppose begs the question: how do > we know when it's safe to deassert the reset (e.g. we've gotten to the point > where all devices using this reset gpio have gotten far enough to detect that > they use it)? The driver (reset consumer) knows when it is safe or not. You must implement proper reset handling in your driver. Best regards, Krzysztof

4 10

[PATCH] ALSA: hda/tas2781: annotate calibration data endianness
by Gergo Koteles 09 Jan '24

09 Jan '24

Sparse reports an endian mismatch. The amplifier expects the calibration data as big-endian. Use the __be32 type to express endianness better. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202401072137.Oc7pQgRW-lkp@intel.com/ Signed-off-by: Gergo Koteles <soyer(a)irl.hu> --- sound/pci/hda/tas2781_hda_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/tas2781_hda_i2c.c b/sound/pci/hda/tas2781_hda_i2c.c index 4805cf0b6480..2dd809de62e5 100644 --- a/sound/pci/hda/tas2781_hda_i2c.c +++ b/sound/pci/hda/tas2781_hda_i2c.c @@ -424,8 +424,8 @@ static const struct snd_kcontrol_new tas2781_dsp_conf_ctrl = { static void tas2563_apply_calib(struct tasdevice_priv *tas_priv) { - unsigned int data; int offset = 0; + __be32 data; int ret; for (int i = 0; i < tas_priv->ndev; i++) { base-commit: 736c40609d31481b3b2fffe8c239f2c86fb2b54c -- 2.43.0

2 1

[PATCH 00/12] soundwire/SOF: add SoundWire Interface support for AMD SOF stack
by Vijendar Mukunda 09 Jan '24

09 Jan '24

This patch series is to redesign existing platform device creation logic for SoundWire managers and Implement generic functions for SoundWire manager probe, start and exit sequence which are common for both Legacy(NO DSP enabled) and SOF stack, and add SoundWire Interface support for AMD SOF stack (ACP 6.3 based platforms). Vijendar Mukunda (12): ASoC/soundwire: implement generic api for scanning amd soundwire controller drivers: soundwire: refactor amd soundwire manager device node creation drivers: soundwire: implement function to extract slave information drivers: soundwire: refactor soundwire pads enable drivers: soundwire: refactor register mask structure ASoC: SOF: amd: add code for invoking soundwire manager helper functions ASoC: SOF: amd: add interrupt handling for SoundWire manager devices ASoC: SOF: amd: Add Soundwire DAI configuration support for AMD platforms ASoC: SOF: amd: add machine select logic for soundwire based platforms ASoC: SOF: amd: update descriptor fields for acp6.3 based platform ASoC: SOF: amd: select soundwire dependency flag for acp6.3 based platform ASoC: SOF: amd: refactor acp driver pm ops drivers/soundwire/Makefile | 2 +- drivers/soundwire/amd_init.c | 235 +++++++++++++++++++++++++++++ drivers/soundwire/amd_init.h | 13 ++ drivers/soundwire/amd_manager.c | 41 +---- drivers/soundwire/amd_manager.h | 12 +- include/linux/soundwire/sdw_amd.h | 79 ++++++++-- include/sound/sof/dai-amd.h | 7 + include/sound/sof/dai.h | 2 + include/uapi/sound/sof/tokens.h | 4 + sound/soc/amd/acp/Kconfig | 7 + sound/soc/amd/acp/Makefile | 2 + sound/soc/amd/acp/amd-sdw-acpi.c | 62 ++++++++ sound/soc/sof/amd/Kconfig | 18 +++ sound/soc/sof/amd/acp-common.c | 65 +++++++- sound/soc/sof/amd/acp-dsp-offset.h | 10 ++ sound/soc/sof/amd/acp.c | 202 ++++++++++++++++++++++++- sound/soc/sof/amd/acp.h | 26 +++- sound/soc/sof/amd/pci-acp63.c | 7 + sound/soc/sof/ipc3-pcm.c | 25 +++ sound/soc/sof/ipc3-topology.c | 40 +++++ sound/soc/sof/sof-audio.h | 1 + sound/soc/sof/topology.c | 5 + 22 files changed, 798 insertions(+), 67 deletions(-) create mode 100644 drivers/soundwire/amd_init.c create mode 100644 drivers/soundwire/amd_init.h create mode 100644 sound/soc/amd/acp/amd-sdw-acpi.c -- 2.34.1

5 23

External I/O-Plugin API is missing precise timestamp control
by GitHub issues - opened 09 Jan '24

09 Jan '24

alsa-project/alsa-lib issue #377 was opened from z-s-e: Unless I overlooked something, it seems not possible for an ioplug plugin to influence the timestamps reported by `snd_pcm_status_get_htstamp()` - I suppose those are rather autogenerated by the lib and thus of fairly low precision. Also, at the moment it is possible that a status update contains newer timestamps than a previous update, but without an increased `snd_pcm_status_get_avail()` value, which makes these autogenerated timestamps not very well behaved. It would be much better if there was a way for a plugin to tell the alsa-lib which timestamps it should forward to the user. Issue URL : https://github.com/alsa-project/alsa-lib/issues/377 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ASoC: mediatek: mt8192: Check existence of dai_name before dereferencing
by Nícolas F. R. A. Prado 09 Jan '24

09 Jan '24

Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()"), the dai_name field is only populated for dummy components after the card is registered. This causes a null pointer dereference in the mt8192-mt6359 sound card driver's probe function when searching for a dai_name among all the card's dai links. Verify that the dai_name is non-null before passing it to strcmp. While at it, also check that there's at least one codec. Reported-by: "kernelci.org bot" <bot(a)kernelci.org> Closes: https://linux.kernelci.org/test/case/id/6582cd6d992645c680e13478/ Fixes: 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") Signed-off-by: Nícolas F. R. A. Prado <nfraprado(a)collabora.com> --- sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c b/sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c index 5bd6addd1450..bfcb2c486c39 100644 --- a/sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c +++ b/sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c @@ -1208,7 +1208,8 @@ static int mt8192_mt6359_dev_probe(struct platform_device *pdev) dai_link->ignore = 0; } - if (strcmp(dai_link->codecs[0].dai_name, RT1015_CODEC_DAI) == 0) + if (dai_link->num_codecs && dai_link->codecs[0].dai_name && + strcmp(dai_link->codecs[0].dai_name, RT1015_CODEC_DAI) == 0) dai_link->ops = &mt8192_rt1015_i2s_ops; if (!dai_link->platforms->name) -- 2.43.0

3 2

Update USB-Audio.conf
by GitHub pull_request - edited 09 Jan '24

09 Jan '24

alsa-project/alsa-ucm-conf pull request #376 was edited from MiroslavGubenko: added MPG Z590M GAMING EDGE WIFI Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/376 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/376.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 13-ay0xxx
by Tom Jason Schwanke 08 Jan '24

08 Jan '24

This enables the mute and mic-mute LEDs on the HP Envy X360 13-ay0xxx convertibles. The quirk 'ALC245_FIXUP_HP_X360_MUTE_LEDS' already exists and is now enabled for this device. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=216197 Signed-off-by: Tom Jason Schwanke <tom(a)catboys.cloud> --- 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 1dcfba27e075..475d7e843ed3 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9875,6 +9875,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8870, "HP ZBook Fury 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), SND_PCI_QUIRK(0x103c, 0x8873, "HP ZBook Studio 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT), SND_PCI_QUIRK(0x103c, 0x887a, "HP Laptop 15s-eq2xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), + SND_PCI_QUIRK(0x103c, 0x876E, "HP ENVY x360 Convertible 13-ay0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS), SND_PCI_QUIRK(0x103c, 0x888a, "HP ENVY x360 Convertible 15-eu0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS), SND_PCI_QUIRK(0x103c, 0x888d, "HP ZBook Power 15.6 inch G8 Mobile Workstation PC", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8895, "HP EliteBook 855 G8 Notebook PC", ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED), ---

1 0

Update USB-Audio.conf
by GitHub pull_request - opened 08 Jan '24

08 Jan '24

alsa-project/alsa-ucm-conf pull request #376 was opened from MiroslavGubenko: add MPG Z590M GAMING EDGE WIFI Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/376 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/376.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[bug report] ASoC: Intel: avs: Path creation and freeing
by Dan Carpenter 08 Jan '24

08 Jan '24

Hello Cezary Rojewski, This is a semi-automatic email about new static checker warnings. sound/soc/intel/avs/path.c:110 avs_path_find_variant() warn: variable dereferenced before check 'variant->be_fmt' (see line 105) sound/soc/intel/avs/path.c 104 variant->fe_fmt->valid_bit_depth, variant->fe_fmt->bit_depth); 105 dev_dbg(adev->dev, "check BE rate %d chn %d vbd %d bd %d\n", 106 variant->be_fmt->sampling_freq, variant->be_fmt->num_channels, 107 variant->be_fmt->valid_bit_depth, variant->be_fmt->bit_depth); ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ Unchecked dereferences 108 109 if (variant->fe_fmt && avs_test_hw_params(fe_params, variant->fe_fmt) && 110 variant->be_fmt && avs_test_hw_params(be_params, variant->be_fmt)) ^^^^^^^^^^^^^^^ Checked too late 111 return variant; 112 } regards, dan carpenter

1 0

[PATCH] ASoC: ti: Use devm_kcalloc() instead of devm_kzalloc()
by Erick Archer 08 Jan '24

08 Jan '24

Use 2-factor multiplication argument form devm_kcalloc() instead of devm_kzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Erick Archer <erick.archer(a)gmx.com> --- sound/soc/ti/j721e-evm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/ti/j721e-evm.c b/sound/soc/ti/j721e-evm.c index b4b158dc736e..d9d1e021f5b2 100644 --- a/sound/soc/ti/j721e-evm.c +++ b/sound/soc/ti/j721e-evm.c @@ -649,7 +649,7 @@ static int j721e_soc_probe_cpb(struct j721e_priv *priv, int *link_idx, * Link 2: McASP10 <- pcm3168a_1 ADC */ comp_count = 6; - compnent = devm_kzalloc(priv->dev, comp_count * sizeof(*compnent), + compnent = devm_kcalloc(priv->dev, comp_count, sizeof(*compnent), GFP_KERNEL); if (!compnent) { ret = -ENOMEM; @@ -763,7 +763,7 @@ static int j721e_soc_probe_ivi(struct j721e_priv *priv, int *link_idx, * \ pcm3168a_b ADC */ comp_count = 8; - compnent = devm_kzalloc(priv->dev, comp_count * sizeof(*compnent), + compnent = devm_kcalloc(priv->dev, comp_count, sizeof(*compnent), GFP_KERNEL); if (!compnent) { ret = -ENOMEM; -- 2.25.1

3 2