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

[PATCH v7 00/22] ASoC: qcom: Add AudioReach support
by Srinivas Kandagatla 22 Sep '21

22 Sep '21

Many thanks for reviewing v6 This version addresses all the comments raised as part of v7 review. This patchset adds ASoC driver support to configure signal processing framework ("AudioReach") which is integral part of Qualcomm next generation audio SDK and will be deployed on upcoming Qualcomm chipsets. It makes use of ASoC Topology to load graphs on to the DSP which is then managed by APM (Audio Processing Manager) service to prepare/start/stop. Here is simplified high-level block diagram of AudioReach: ___________________________________________________________ | CPU (Application Processor) | | +---------+ +---------+ +----------+ | | | q6apm | | q6apm | | q6apm | | | | dais | <------> | | <-----> |lpass-dais| | | +---------+ +---------+ +----------+ | | ^ ^ | | | | +---------+ | | +---------+ v +---------->|topology | | | | q6prm | +---------+ | | | | | |<-------->| GPR | +---------+ | | +---------+ +---------+ | | ^ ^ | | | | | | +----------+ | | | | q6prm | | | | |lpass-clks| | | | +----------+ | | |____________________________|______________________________| | | RPMSG (IPC over GLINK) ____________________________|______________________________ | | | | +-----------------------+ | | | | | | v v q6 (Audio DSP) | |+-----+ +----------------------------------+ | || PRM | | APM (Audio Processing Manager) | | |+-----+ | . Graph Management | | | | . Command Handing | | | | . Event Management | | | | ... | | | +----------------------------------+ | | ^ | |____________________________|______________________________| | | LPASS AIF ____________________________|______________________________ | | Audio I/O | | v | | +--------------------------------------------------+ | | | Audio devices | | | | CODEC | HDMI-TX | PCM | SLIMBUS | I2S |MI2S |...| | | | | | | +--------------------------------------------------+ | |___________________________________________________________| AudioReach has constructs of sub-graph, container and modules. Each sub-graph can have N containers and each Container can have N Modules and connections between them can be linear or non-linear. An audio function can be realized with one or many connected sub-graphs. There are also control/event paths between modules that can be wired up while building graph to achieve various control mechanism between modules. These concepts of Sub-Graph, Containers and Modules are represented in ASoC topology. Here is simple I2S graph with a Write Shared Memory and a Volume control module within a single Subgraph (1) with one Container (1) and 5 modules. ____________________________________________________________ | Sub-Graph [1] | | _______________________________________________________ | | | Container [1] | | | | [WR_SH] -> [PCM DEC] -> [PCM CONV] -> [VOL]-> [I2S-EP]| | | |_______________________________________________________| | |____________________________________________________________| For now this graph is split into two subgraphs to achieve dpcm like below: ________________________________________________ _________________ | Sub-Graph [1] | | Sub-Graph [2] | | ____________________________________________ | | _____________ | | | Container [1] | | | |Container [2]| | | | [WR_SH] -> [PCM DEC] -> [PCM CONV] -> [VOL]| | | | [I2S-EP] | | | |____________________________________________| | | |_____________| | |________________________________________________| |_________________| _________________ | Sub-Graph [3] | | _____________ | | |Container [3]| | | | [DMA-EP] | | | |_____________| | |_________________| This patchset adds very minimal support for AudioReach which includes supporting sub-graphs containing CODEC DMA ports and simple PCM Decoder/Encoder and Logger Modules. Additional capabilities will be built over time to expose features offered by AudioReach. This patchset is Tested on SM8250 SoC based Qualcomm Robotics Platform RB5 and SM9250 MTP with WSA881X Smart Speaker Amplifiers, DMICs connected via VA Macro and WCD938x Codec connected via TX and RX Macro and HDMI audio via I2S. First 10 Patches are mostly reorganization existing Old QDSP Audio Framework code and bindings so that we could reuse them on AudioReach. ASoC topology graphs for DragonBoard RB5 and SM8250 MTP are available at https://git.linaro.org/people/srinivas.kandagatla/audioreach-topology.git/ and Qualcomm AudioReach DSP headers are available at: https://source.codeaurora.org/quic/la/platform/vendor/opensource/arspf-head… Note: There is one false positive warning in this patchset: audioreach.c:80:45: warning: array of flexible structures Thanks, srini Changes since v6: - fixed last usage of flexible array in apr - removed leftover comments - added support to derive topology firmware name from soundcard to support different variants, as suggested by Pierre. Srinivas Kandagatla (22): soc: dt-bindings: qcom: apr: convert to yaml soc: dt-bindings: qcom: apr: deprecate qcom,apr-domain property soc: qcom: apr: make code more reuseable soc: dt-bindings: qcom: add gpr bindings soc: qcom: apr: Add GPR support ASoC: dt-bindings: move LPASS dai related bindings out of q6afe ASoC: dt-bindings: move LPASS clocks related bindings out of q6afe ASoC: dt-bindings: rename q6afe.h to q6dsp-lpass-ports.h ASoC: qdsp6: q6afe-dai: move lpass audio ports to common file ASoC: qdsp6: q6afe-clocks: move audio-clocks to common file ASoC: dt-bindings: q6dsp: add q6apm-lpass-dai compatible ASoC: dt-bindings: lpass-clocks: add q6prm clocks compatible ASoC: dt-bindings: add q6apm digital audio stream bindings ASoC: qdsp6: audioreach: add basic pkt alloc support ASoC: qdsp6: audioreach: add q6apm support ASoC: qdsp6: audioreach: add module configuration command helpers ASoC: qdsp6: audioreach: add Kconfig and Makefile ASoC: qdsp6: audioreach: add topology support ASoC: qdsp6: audioreach: add q6apm-dai support ASoC: qdsp6: audioreach: add q6apm lpass dai support ASoC: qdsp6: audioreach: add q6prm support ASoC: qdsp6: audioreach: add support for q6prm-clocks .../devicetree/bindings/soc/qcom/qcom,apr.txt | 134 -- .../bindings/soc/qcom/qcom,apr.yaml | 177 +++ .../devicetree/bindings/sound/qcom,q6afe.txt | 181 --- .../bindings/sound/qcom,q6apm-dai.yaml | 53 + .../sound/qcom,q6dsp-lpass-clocks.yaml | 77 ++ .../sound/qcom,q6dsp-lpass-ports.yaml | 205 +++ drivers/soc/qcom/Kconfig | 2 +- drivers/soc/qcom/apr.c | 287 ++++- include/dt-bindings/soc/qcom,gpr.h | 19 + include/dt-bindings/sound/qcom,q6afe.h | 203 +-- .../sound/qcom,q6dsp-lpass-ports.h | 208 +++ include/linux/soc/qcom/apr.h | 70 +- include/uapi/sound/snd_ar_tokens.h | 208 +++ sound/soc/qcom/Kconfig | 22 + sound/soc/qcom/qdsp6/Makefile | 11 +- sound/soc/qcom/qdsp6/audioreach.c | 1135 +++++++++++++++++ sound/soc/qcom/qdsp6/audioreach.h | 726 +++++++++++ sound/soc/qcom/qdsp6/q6afe-clocks.c | 187 +-- sound/soc/qcom/qdsp6/q6afe-dai.c | 687 +--------- sound/soc/qcom/qdsp6/q6apm-dai.c | 415 ++++++ sound/soc/qcom/qdsp6/q6apm-lpass-dais.c | 260 ++++ sound/soc/qcom/qdsp6/q6apm.c | 836 ++++++++++++ sound/soc/qcom/qdsp6/q6apm.h | 152 +++ sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c | 186 +++ sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.h | 30 + sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c | 627 +++++++++ sound/soc/qcom/qdsp6/q6dsp-lpass-ports.h | 22 + sound/soc/qcom/qdsp6/q6prm-clocks.c | 85 ++ sound/soc/qcom/qdsp6/q6prm.c | 202 +++ sound/soc/qcom/qdsp6/q6prm.h | 78 ++ sound/soc/qcom/qdsp6/topology.c | 1133 ++++++++++++++++ 31 files changed, 7203 insertions(+), 1415 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml create mode 100644 include/dt-bindings/soc/qcom,gpr.h create mode 100644 include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h create mode 100644 include/uapi/sound/snd_ar_tokens.h create mode 100644 sound/soc/qcom/qdsp6/audioreach.c create mode 100644 sound/soc/qcom/qdsp6/audioreach.h create mode 100644 sound/soc/qcom/qdsp6/q6apm-dai.c create mode 100644 sound/soc/qcom/qdsp6/q6apm-lpass-dais.c create mode 100644 sound/soc/qcom/qdsp6/q6apm.c create mode 100644 sound/soc/qcom/qdsp6/q6apm.h create mode 100644 sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.c create mode 100644 sound/soc/qcom/qdsp6/q6dsp-lpass-clocks.h create mode 100644 sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c create mode 100644 sound/soc/qcom/qdsp6/q6dsp-lpass-ports.h create mode 100644 sound/soc/qcom/qdsp6/q6prm-clocks.c create mode 100644 sound/soc/qcom/qdsp6/q6prm.c create mode 100644 sound/soc/qcom/qdsp6/q6prm.h create mode 100644 sound/soc/qcom/qdsp6/topology.c -- 2.21.0

2 31

[PATCH 01/16] ASoC: eureka-tlv320: Update to modern clocking terminology
by Mark Brown 22 Sep '21

22 Sep '21

As part of moving to remove the old style defines for the bus clocks update the eureka-tlv320 driver to use more modern terminology for clocking. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/fsl/eukrea-tlv320.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c index e13271ea84de..8b61582753c8 100644 --- a/sound/soc/fsl/eukrea-tlv320.c +++ b/sound/soc/fsl/eukrea-tlv320.c @@ -70,7 +70,7 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = { .name = "tlv320aic23", .stream_name = "TLV320AIC23", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM, + SND_SOC_DAIFMT_CBP_CFP, .ops = &eukrea_tlv320_snd_ops, SND_SOC_DAILINK_REG(hifi), }; -- 2.20.1

2 18

[PATCH] ASoC: cros_ec_codec: Use modern ASoC DAI format terminology
by Mark Brown 22 Sep '21

22 Sep '21

As part of moving to remove the old style defines for the bus clocks update the cros_ec_codec driver to use more modern terminology for clocking. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/cros_ec_codec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c index a201d652aca2..9b92e1a0d1a3 100644 --- a/sound/soc/codecs/cros_ec_codec.c +++ b/sound/soc/codecs/cros_ec_codec.c @@ -283,8 +283,8 @@ static int i2s_rx_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) struct ec_param_ec_codec_i2s_rx p; enum ec_codec_i2s_rx_daifmt daifmt; - switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { - case SND_SOC_DAIFMT_CBS_CFS: + switch (fmt & SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK) { + case SND_SOC_DAIFMT_CBC_CFC: break; default: return -EINVAL; -- 2.20.1

2 2

[PATCH v2 01/16] ASoC: eureka-tlv320: Update to modern clocking terminology
by Mark Brown 22 Sep '21

22 Sep '21

As part of moving to remove the old style defines for the bus clocks update the eureka-tlv320 driver to use more modern terminology for clocking. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/fsl/eukrea-tlv320.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c index e13271ea84de..8b61582753c8 100644 --- a/sound/soc/fsl/eukrea-tlv320.c +++ b/sound/soc/fsl/eukrea-tlv320.c @@ -70,7 +70,7 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = { .name = "tlv320aic23", .stream_name = "TLV320AIC23", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM, + SND_SOC_DAIFMT_CBP_CFP, .ops = &eukrea_tlv320_snd_ops, SND_SOC_DAILINK_REG(hifi), }; -- 2.20.1

2 17

Redesign the rawmidi midi read with timestamping API
by GitHub pull_request - opened 22 Sep '21

22 Sep '21

alsa-project/alsa-lib pull request #179 was opened from perexg: It's follow-up for https://github.com/alsa-project/alsa-lib/pull/173 and https://github.com/alsa-project/alsa-lib/issues/172 . I am confident, that the direct framing mechanism for the transfer of the midi stream with the timestamping should be hidden and abstracted in the alsa-lib's API. This version uses a new read function (`snd_rawmidi_tread()`) which decodes and merges the data from the kernel frames. The framing mechanism is very specific to the kernel API and the cost of added data copy is negligible in this case (the kernel code basically does similar thing). I kept the `snd_rawmidi_read()` functionality to read raw frames), but the structure for the parsing must be defined on it's own. This mechanism is unsupported. This version seems more abstract and easy to use for apps than the separate decoder function for `snd_rawmidi_read()`. Request URL : https://github.com/alsa-project/alsa-lib/pull/179 Patch URL : https://github.com/alsa-project/alsa-lib/pull/179.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[RFC PATCH] component: do not leave master devres group open after bind
by Kai Vehmanen 21 Sep '21

21 Sep '21

In current code, the devres group for aggregate master is left open after call to component_master_add_*(). This leads to problems when the master does further managed allocations on its own. When any participating driver calls component_del(), this leads to immediate release of resources. This came up when investigating a page fault occurring with i915 DRM driver unbind with 5.15-rc1 kernel. The following sequence occurs: i915_pci_remove() -> intel_display_driver_unregister() -> i915_audio_component_cleanup() -> component_del() -> component.c:take_down_master() -> hdac_component_master_unbind() [via master->ops->unbind()] -> devres_release_group(master->parent, NULL) With older kernels this has not caused issues, but with audio driver moving to use managed interfaces for more of its allocations, this no longer works. Devres log shows following to occur: component_master_add_with_match() [ 126.886032] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000323ccdc5 devm_component_match_release (24 bytes) [ 126.886045] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000865cdb29 grp< (0 bytes) [ 126.886049] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 grp< (0 bytes) audio driver completes its PCI probe() [ 126.892238] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 pcim_iomap_release (48 bytes) component_del() called() at DRM/i915 unbind() [ 137.579422] i915 0000:00:02.0: DEVRES REL 00000000ef44c293 grp< (0 bytes) [ 137.579445] snd_hda_intel 0000:00:1f.3: DEVRES REL 00000000865cdb29 grp< (0 bytes) [ 137.579458] snd_hda_intel 0000:00:1f.3: DEVRES REL 000000001b480725 pcim_iomap_release (48 bytes) So the "devres_release_group(master->parent, NULL)" ends up freeing the pcim_iomap allocation. Upon next runtime resume, the audio driver will cause a page fault as the iomap alloc was released without the driver knowing about it. Fix this issue by using the "struct master" pointer as identifier for the devres group, and by closing the devres group after the master->ops->bind() call is done. This allows devres allocations done by the driver acting as master to be isolated from the binding state of the aggregate driver. This modifies the logic originally introduced in commit 9e1ccb4a7700 ("drivers/base: fix devres handling for master device"). BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/4136 Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- drivers/base/component.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Hi, I'm sending this as RFC as I'm not sure of the implications of not leaving the devres group open might have to other users of the component framework. For audio, the current behaviour seems very problematic. The display codec is usually just one of many audio codecs attached to the controller, and unbind of the display codec (and the aggregate driver created with DRM), should not bring down the whole audio card. However, now all allocations audio driver does after call to component_master_add_with_match(), will be freed when display driver calls component_del(). Closing the devres group at end of component_master_add_*() would seem the cleanest option. Looking for feedback whether this approach is feasible. One alternative would be for the audio driver to close the "last opened" group after its call to component_master_add(), but this seems messy (audio would make assumptions on component.c internals). diff --git a/drivers/base/component.c b/drivers/base/component.c index 5e79299f6c3f..870485cbbb87 100644 --- a/drivers/base/component.c +++ b/drivers/base/component.c @@ -246,7 +246,7 @@ static int try_to_bring_up_master(struct master *master, return 0; } - if (!devres_open_group(master->parent, NULL, GFP_KERNEL)) + if (!devres_open_group(master->parent, master, GFP_KERNEL)) return -ENOMEM; /* Found all components */ @@ -258,6 +258,7 @@ static int try_to_bring_up_master(struct master *master, return ret; } + devres_close_group(master->parent, NULL); master->bound = true; return 1; } @@ -282,7 +283,7 @@ static void take_down_master(struct master *master) { if (master->bound) { master->ops->unbind(master->parent); - devres_release_group(master->parent, NULL); + devres_release_group(master->parent, master); master->bound = false; } } base-commit: 930e99a51fcc8b1254e0a45fbe0cd5a5b8a704a5 -- 2.32.0

3 2

Re: [LAD] Mackie Onyx 1640i: Long run playback results in xrun and hang.
by AreYouLoco? 21 Sep '21

21 Sep '21

I am going to recompile the kernel with options mentioned here: https://www.alsa-project.org/main/index.php/XRUN_Debug And try to debug why the xrun appears. I also checked with buffer size 1024 and exaclty one xrun and then hang repeats. On 9/13/21 12:23 PM, AreYouLoco? wrote: > Hi, > > I am using custom build real-time kernel 5.12.2-rt3-fw. JACK with ALSA > backend on Mackie Onyx 1640i. > Lenovo Thinkpad T420 with FireWire. Debian Bullseye (11.0 - stable) > JACKD version 1.9.17. > I am using 512 samples 3 periods @48kHz. > > The problem is that long run playback only around 1h (but the time > differs), result in > XRUN detected by JACK logs and the whole audio stops. So I have to > restart JACK in order to make it work. > DMESG is silent about that issue. But sometimes I get: > > snd_oxfw fw1.0: Detect discontinuity of CIP: E8 00 > And different hex values there. > > Here is interesting part from the log: > > Sun Sep 12 22:10:12 2021: Jack: JackRequest::Notification > Sun Sep 12 22:10:12 2021: Jack: **** alsa_pcm: xrun of at least 0.027 msecs > Sun Sep 12 22:10:12 2021: Jack: Repreparing capture > Sun Sep 12 22:10:12 2021: Jack: Repreparing playback > Sun Sep 12 22:10:12 2021: Jack: ALSA XRun wait_status = 0 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackClient::ClientNotify ref = 2 name = > dbusapi notify = 3 > Sun Sep 12 22:10:12 2021: Jack: JackClient::kXRunCallback > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:12 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 22:10:28 2021: ERROR: ALSA: poll time out, polled for > 15998655 usecs, Retrying with a recovery, retry cnt = 1 > Sun Sep 12 22:10:44 2021: ERROR: ALSA: poll time out, polled for > 15998654 usecs, Retrying with a recovery, retry cnt = 2 > Sun Sep 12 22:11:00 2021: ERROR: ALSA: poll time out, polled for > 15998659 usecs, Retrying with a recovery, retry cnt = 3 > Sun Sep 12 22:11:16 2021: ERROR: ALSA: poll time out, polled for > 15998649 usecs, Retrying with a recovery, retry cnt = 4 > > Anyone have idea what might be the cause of this XRUN? Or how to debug that? > > Its reproducible on my setup. Another log catched the same issue: > > Sun Sep 12 16:50:44 2021: Jack: **** alsa_pcm: xrun of at least 0.030 msecs > Sun Sep 12 16:50:44 2021: Jack: Repreparing capture > Sun Sep 12 16:50:44 2021: Jack: Repreparing playback > Sun Sep 12 16:50:44 2021: Jack: ALSA XRun wait_status = 0 > Sun Sep 12 16:50:44 2021: Jack: JackRequest::Notification > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackClient::ClientNotify ref = 2 name = > dbusapi notify = 3 > Sun Sep 12 16:50:44 2021: Jack: JackClient::kXRunCallback > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:50:44 2021: Jack: JackEngine::ClientNotify: no callback > for notification = 3 > Sun Sep 12 16:51:00 2021: ERROR: ALSA: poll time out, polled for > 15998366 usecs, Retrying with a recovery, retry cnt = 1 > Sun Sep 12 16:51:16 2021: ERROR: ALSA: poll time out, polled for > 15998353 usecs, Retrying with a recovery, retry cnt = 2 > Sun Sep 12 16:51:32 2021: ERROR: ALSA: poll time out, polled for > 15998352 usecs, Retrying with a recovery, retry cnt = 3 > Sun Sep 12 16:51:48 2021: ERROR: ALSA: poll time out, polled for > 15998367 usecs, Retrying with a recovery, retry cnt = 4 > Sun Sep 12 16:52:04 2021: ERROR: ALSA: poll time out, polled for > 15998353 usecs, Retrying with a recovery, retry cnt = 5 > Sun Sep 12 16:52:20 2021: ERROR: ALSA: poll time out, polled for > 15998371 usecs, Reached max retry cnt = 5, Exiting > Sun Sep 12 16:52:20 2021: ERROR: JackAudioDriver::ProcessAsync: read > error, stopping... > Sun Sep 12 16:52:20 2021: Jack: JackPosixThread::ThreadHandler : exit > > I am willing to provide additional info. > > Thank you in advance, > > AreYouLoco? > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev

1 1

[PATCH] ASoC: Fix warning related to 'sound-name-prefix' binding
by Sameer Pujar 21 Sep '21

21 Sep '21

commit 82d3ec1d89fa ("ASoC: Use schema reference for sound-name-prefix") added name-prefix.yaml schema and the same reference was used in couple of other schemas. But this is causing following warning and the same is fixed in current patch. Documentation/devicetree/bindings/sound/nxp,tfa989x.example.dt.yaml: audio-codec@34: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml Documentation/devicetree/bindings/sound/nxp,tfa989x.example.dt.yaml: audio-codec@36: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml Fixes: 82d3ec1d89fa ("ASoC: Use schema reference for sound-name-prefix") Reported-by: Rob Herring <robh+dt(a)kernel.org> Suggested-by: Rob Herring <robh+dt(a)kernel.org> Signed-off-by: Sameer Pujar <spujar(a)nvidia.com> --- Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml | 2 ++ Documentation/devicetree/bindings/sound/simple-audio-mux.yaml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index 68e5ad2..7667471 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -24,6 +24,8 @@ properties: '#sound-dai-cells': const: 0 + sound-name-prefix: true + vddd-supply: description: regulator phandle for the VDDD power supply. diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml index c597d9d..b5fc35e 100644 --- a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml +++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml @@ -24,6 +24,8 @@ properties: description: | GPIOs used to select the input line. + sound-name-prefix: true + required: - compatible - mux-gpios -- 2.7.4

2 1

[PATCH] ASoC: pcm512x: Mend accesses to the I2S_1 and I2S_2 registers
by Peter Rosin 21 Sep '21

21 Sep '21

>From 625f858894af2b7e547cc723b97361081438b123 Mon Sep 17 00:00:00 2001 From: Peter Rosin <peda(a)axentia.se> Commit 25d27c4f68d2 ("ASoC: pcm512x: Add support for more data formats") breaks the TSE-850 device, which is using a pcm5142 in I2S and CBM_CFS mode (maybe not relevant). Without this fix, the result is: pcm512x 0-004c: Failed to set data format: -16 And after that, no sound. This fix is not 100% correct. The datasheet of at least the pcm5142 states that four bits (0xcc) in the I2S_1 register are "RSV" ("Reserved. Do not access.") and no hint is given as to what the initial values are supposed to be. So, specifying defaults for these bits is wrong. But perhaps better than a broken driver? Fixes: 25d27c4f68d2 ("ASoC: pcm512x: Add support for more data formats") Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Kirill Marinushkin <kmarinushkin(a)birdec.com> Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Cc: alsa-devel(a)alsa-project.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Peter Rosin <peda(a)axentia.se> --- sound/soc/codecs/pcm512x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c index 4dc844f3c1fc..60dee41816dc 100644 --- a/sound/soc/codecs/pcm512x.c +++ b/sound/soc/codecs/pcm512x.c @@ -116,6 +116,8 @@ static const struct reg_default pcm512x_reg_defaults[] = { { PCM512x_FS_SPEED_MODE, 0x00 }, { PCM512x_IDAC_1, 0x01 }, { PCM512x_IDAC_2, 0x00 }, + { PCM512x_I2S_1, 0x02 }, + { PCM512x_I2S_2, 0x00 }, }; static bool pcm512x_readable(struct device *dev, unsigned int reg) -- 2.20.1

3 13

[PATCH 0/7] add internal channels support
by Olivier Moysan 21 Sep '21

21 Sep '21

This patchset adds support of ADC2 internal channels VDDCORE, VREFINT and VBAT on STM32MP15x SoCs. The generic IIO channel bindings is also introduced here to provide this feature. The legacy channel binding is kept for backward compatibility. Olivier Moysan (7): dt-bindings: iio: adc: add generic channel binding dt-bindings: iio: adc: add nvmem support for vrefint internal channel iio: adc stm32-adc: split channel init into several routines iio: adc: stm32-adc: add support of generic channels binding iio: adc: stm32-adc: add support of internal channels iio: adc: stm32-adc: add vrefint calibration support iio: adc: stm32-adc: use generic binding for sample-time .../bindings/iio/adc/st,stm32-adc.yaml | 108 ++++- drivers/iio/adc/stm32-adc-core.h | 8 + drivers/iio/adc/stm32-adc.c | 418 ++++++++++++++++-- 3 files changed, 482 insertions(+), 52 deletions(-) -- 2.17.1

3 14