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

Add UCM for PinePhone
by GitHub pull_request - edited 28 Feb '22

28 Feb '22

alsa-project/alsa-ucm-conf pull request #134 was edited from tomfitzhenry: Fixes https://github.com/alsa-project/alsa-ucm-conf/issues/124. The device-tree configuration has had a unique audio card name since 5.14: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… This UCM config is copied from https://gitlab.com/pine64-org/pine64-alsa-ucm/, which was developed by many developers ( https://gitlab.com/pine64-org/pine64-alsa-ucm/-/merge_requests/1 ) and is BSD-3-Clause licensed. I have tested that with this PR, the PinePhone has the expected HiFi and VoiceCall profiles.This testing found that the `File` directive in `SectionUseCase` needs to be absolute (for the symlink to work). I've fixed this in this PR: https://github.com/alsa-project/alsa-ucm-conf/pull/134/commits/5059e57a2197…. See also: * `alsa-info`: https://alsa-project.org/db/?f=5e331f5ef10bd167b3bd7640bfcf0e879100f80d * `pa-info`: [pa-info.txt](https://github.com/alsa-project/alsa-ucm-conf/files/8015083/pa… * https://gitlab.com/pine64-org/pine64-alsa-ucm/-/issues/3 Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/134 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/134.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v2 0/3] soundwire: qcom: add pm runtime support
by Srinivas Kandagatla 28 Feb '22

28 Feb '22

This patchset adds pm runtime support to Qualcomm SounWire Controller using SoundWire Clock Stop and Wake up using Headset events on supported instances and instances like WSA which do not support clock stop a soft reset of controller along with full rest of slaves is done to resume from a low power state. Tested it on SM8250 MTP and Dragon Board DB845c --srini Changes since v1: - updated wake irq to not deal with slave pm runtime directly. - added delay after soft reset of SoundWire controller where clock stop is not supported Srinivas Kandagatla (3): soundwire: qcom: add runtime pm support dt-bindings: soundwire: qcom: document optional wake irq soundwire: qcom: add in-band wake up interrupt support .../bindings/soundwire/qcom,sdw.txt | 2 +- drivers/soundwire/qcom.c | 202 +++++++++++++++++- 2 files changed, 202 insertions(+), 2 deletions(-) -- 2.21.0

3 8

ucm2: add additional symlink for Pinebook Pro
by GitHub pull_request - opened 28 Feb '22

28 Feb '22

alsa-project/alsa-ucm-conf pull request #140 was opened from kmcopper: since 907f0a305186 ASoC: simple-card: Fill in driver name of the linux kernel, the base name is simple-card instead of rockchip_es8316 Fixes: 85eea19783cf ("ucm2: Add UCM support for rockchip_es8316 on Pinebook Pro") Signed-off-by: Kyle Copperfield <kmcopper(a)danwin1210.me> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/140 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/140.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v3 1/2] ALSA: core: remove initialise static variables to 0
by Meng Tang 28 Feb '22

28 Feb '22

Initializing the static variable to 0 causes the following error when exec checkpatch: ERROR: do not initialise statics to 0 FILE: sound/sound_core.c:142: static int preclaim_oss = 0; In addition, considering the following way of writing 139: #ifdef config_sound_oss_core_preclaim 140: Static int preclaim_oss = 1; 141: #ELSE 142: Static int preclaim_oss = 0; 143: #ENDIF We can optimize it by IS_ENABLED(CONFIG_SOUND_OSS_CORE_PRECLAIM), so modified it to static int preclaim_oss = IS_ENABLED(CONFIG_SOUND_OSS_CORE_PRECLAIM); Signed-off-by: Meng Tang <tangmeng(a)uniontech.com> Signed-off-by: JOE Perches <joe(a)perches.com> --- sound/sound_core.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/sound/sound_core.c b/sound/sound_core.c index 90d118cd9164..aa4a57e488e5 100644 --- a/sound/sound_core.c +++ b/sound/sound_core.c @@ -136,11 +136,7 @@ struct sound_unit * All these clutters are scheduled to be removed along with * sound-slot/service-* module aliases. */ -#ifdef CONFIG_SOUND_OSS_CORE_PRECLAIM -static int preclaim_oss = 1; -#else -static int preclaim_oss = 0; -#endif +static int preclaim_oss = IS_ENABLED(CONFIG_SOUND_OSS_CORE_PRECLAIM); module_param(preclaim_oss, int, 0444); -- 2.20.1

2 2

[PATCH v2 1/2] ALSA: core: remove initialise static variables to 0
by Meng Tang 28 Feb '22

28 Feb '22

Initializing the static variable to 0 causes the following error when exec checkpatch: ERROR: do not initialise statics to 0 FILE: sound/sound_core.c:142: static int preclaim_oss = 0; In addition, considering the following way of writing 139: #ifdef config_sound_oss_core_preclaim 140: Static int preclaim_oss = 1; 141: #ELSE 142: Static int preclaim_oss = 0; 143: #ENDIF We can optimize it by IS_ENABLED(CONFIG_SOUND_OSS_CORE_PRECLAIM), so modified it to static int preclaim_oss = IS_ENABLED(CONFIG_SOUND_OSS_CORE_PRECLAIM); Signed-off-by: Meng Tang <tangmeng(a)uniontech.com> --- sound/sound_core.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/sound/sound_core.c b/sound/sound_core.c index 90d118cd9164..aa4a57e488e5 100644 --- a/sound/sound_core.c +++ b/sound/sound_core.c @@ -136,11 +136,7 @@ struct sound_unit * All these clutters are scheduled to be removed along with * sound-slot/service-* module aliases. */ -#ifdef CONFIG_SOUND_OSS_CORE_PRECLAIM -static int preclaim_oss = 1; -#else -static int preclaim_oss = 0; -#endif +static int preclaim_oss = IS_ENABLED(CONFIG_SOUND_OSS_CORE_PRECLAIM); module_param(preclaim_oss, int, 0444); -- 2.20.1

3 3

[PATCH 1/2] ALSA: core: remove initialise static variables to 0
by Meng Tang 27 Feb '22

27 Feb '22

Initializing the static variable to 0 causes the following error when exec checkpatch: ERROR: do not initialise statics to 0 FILE: sound/sound_core.c:142: static int preclaim_oss = 0; Static variable does not need to be initialised to 0, because compiler will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Signed-off-by: Meng Tang <tangmeng(a)uniontech.com> --- sound/sound_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/sound_core.c b/sound/sound_core.c index 90d118cd9164..2ee54070b2b5 100644 --- a/sound/sound_core.c +++ b/sound/sound_core.c @@ -139,7 +139,7 @@ struct sound_unit #ifdef CONFIG_SOUND_OSS_CORE_PRECLAIM static int preclaim_oss = 1; #else -static int preclaim_oss = 0; +static int preclaim_oss; #endif module_param(preclaim_oss, int, 0444); -- 2.20.1

2 2

[PATCH v2] soundwire: qcom: remove redundant wait for completion
by Srinivasa Rao Mandadapu 26 Feb '22

26 Feb '22

Remove wait_for_completion_timeout from soundwire probe as it seems unnecessary and device enumeration is anyway not happening here, hence this api is blocking till it completes max wait time. Also, as device enumeration event is dependent on wcd938x probe to be completed, its of no use waiting here. Waiting here increasing the boot time almost 4 seconds and impacting other modules like touch screen. Fixes: 06dd96738d618 ("soundwire: qcom: wait for enumeration to be complete in probe") Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> Co-developed-by: Venkata Prasad Potturu <quic_potturu(a)quicinc.com> Signed-off-by: Venkata Prasad Potturu <quic_potturu(a)quicinc.com> --- drivers/soundwire/qcom.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index 5481341..9a32a24 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1309,8 +1309,6 @@ static int qcom_swrm_probe(struct platform_device *pdev) } qcom_swrm_init(ctrl); - wait_for_completion_timeout(&ctrl->enumeration, - msecs_to_jiffies(TIMEOUT_MS)); ret = qcom_swrm_register_dais(ctrl); if (ret) goto err_master_add; -- 2.7.4

3 5

[PATCH] "soundwire: qcom: revert wait for enumeration to be complete in probe"
by Srinivasa Rao Mandadapu 26 Feb '22

26 Feb '22

Revert wait for enumeration from soundwire probe as it seems unnecessary and device enumeration is anyway not happening here, hence this api is blocking till it completes max wait time. Also, as device enumeration event is dependent on wcd938x probe to be completed, its of no use waiting here. Waiting here increasing the boot time almost 4 seconds and impacting other modules like touch screen. Revert: commit 06dd96738d618 ("soundwire: qcom: wait for enumeration to be complete in probe") Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> Co-developed-by: Venkata Prasad Potturu <quic_potturu(a)quicinc.com> Signed-off-by: Venkata Prasad Potturu <quic_potturu(a)quicinc.com> --- drivers/soundwire/qcom.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index 5481341..9eb31ba 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -133,7 +133,6 @@ struct qcom_swrm_ctrl { struct dentry *debugfs; #endif struct completion broadcast; - struct completion enumeration; struct work_struct slave_work; /* Port alloc/free lock */ struct mutex port_lock; @@ -486,7 +485,6 @@ static int qcom_swrm_enumerate(struct sdw_bus *bus) } } - complete(&ctrl->enumeration); return 0; } @@ -1262,7 +1260,6 @@ static int qcom_swrm_probe(struct platform_device *pdev) dev_set_drvdata(&pdev->dev, ctrl); mutex_init(&ctrl->port_lock); init_completion(&ctrl->broadcast); - init_completion(&ctrl->enumeration); ctrl->bus.ops = &qcom_swrm_ops; ctrl->bus.port_ops = &qcom_swrm_port_ops; @@ -1309,8 +1306,6 @@ static int qcom_swrm_probe(struct platform_device *pdev) } qcom_swrm_init(ctrl); - wait_for_completion_timeout(&ctrl->enumeration, - msecs_to_jiffies(TIMEOUT_MS)); ret = qcom_swrm_register_dais(ctrl); if (ret) goto err_master_add; -- 2.7.4

1 0

[RESEND v4 0/2] Add power domains support for digital macro codecs
by Srinivasa Rao Mandadapu 26 Feb '22

26 Feb '22

This patch set is to add power domains support for RX, TX and VA macros. Changes since v3: -- Add dt-bindings support. Changes since v2: -- Remove redundant local variable. -- Update pds error handling sequence. -- Update module description. -- Clean up pds init function. -- Remove redundant arguments. Changes since v1: -- Add missing macros in Kconfig. Srinivasa Rao Mandadapu (2): ASoC: codecs: Add power domains support in digital macro codecs ASoC: qcom: dt-bindings: Add bindings for power domains in lpass digital codecs .../bindings/sound/qcom,lpass-rx-macro.yaml | 8 +++ .../bindings/sound/qcom,lpass-tx-macro.yaml | 8 +++ .../bindings/sound/qcom,lpass-va-macro.yaml | 8 +++ sound/soc/codecs/Kconfig | 7 +++ sound/soc/codecs/Makefile | 2 + sound/soc/codecs/lpass-macro-common.c | 67 ++++++++++++++++++++++ sound/soc/codecs/lpass-macro-common.h | 17 ++++++ sound/soc/codecs/lpass-rx-macro.c | 12 +++- sound/soc/codecs/lpass-tx-macro.c | 10 ++++ sound/soc/codecs/lpass-va-macro.c | 12 ++++ sound/soc/qcom/Kconfig | 1 + 11 files changed, 151 insertions(+), 1 deletion(-) create mode 100644 sound/soc/codecs/lpass-macro-common.c create mode 100644 sound/soc/codecs/lpass-macro-common.h -- 2.7.4

1 2

Need help understanding DPCM
by Aidan MacDonald 25 Feb '22

25 Feb '22

Hi all. I want to extend an existing ASoC driver (jz4740-i2s) so it can be used with an external (discrete) codec; currently it is hardcoded to use a SoC internal codec. I'd like to be able to switch between the two codecs at runtime. Switching between the internal and external codecs is done by toggling a bit in a register. The switch determines where the I2S signals get routed: to the internal codec or the external one. Because of this only one of the codecs can be used at a time. It sounds like I need DPCM to handle this sort of thing - I have a single FIFO on the CPU for audio data (an FE DAI?) and it can connect to one of two codecs (the BE DAIs?) via a switch. But most of the drivers I see using DPCM look way more complicated: big DSP chips, and CPUs with a lot of DAIs. I am having a hard time separating out the essential bits from the overall "mess." The documentation is not very helpful either. Could someone helpfully explain what a (presumably) very basic DPCM setup for this situation would look like? Or is DPCM overkill - should I be doing something else entirely? I want to do this the "right" way so I can send patches upstream. If possible, I'd like to use one of the 'generic' audio card drivers like simple-audio-card. BTW, what is the difference between simple-audio-card, audio-graph-card, and audio-graph-card2? They all seem to do very similar things and share a lot of code. Thanks! Best regards, Aidan

1 0