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

[Patch v5 00/12] Add audio support for LPC32XX CPUs
by Piotr Wojtaszczyk 11 Sep '24

11 Sep '24

This pach set is to bring back audio to machines with a LPC32XX CPU. The legacy LPC32XX SoC used to have audio spport in linux 2.6.27. The support was dropped due to lack of interest from mainaeners. Piotr Wojtaszczyk (12): dt-bindings: dma: pl08x: Add dma-cells description dt-bindings: dma: Add lpc32xx DMA mux binding ASoC: dt-bindings: lpc32xx: Add lpc32xx i2s DT binding ARM: dts: lpc32xx: Use simple-mfd for clock control block ARM: dts: lpc32xx: Add missing dma properties ARM: dts: lpc32xx: Add missing i2s properties clk: lpc32xx: initialize regmap using parent syscon dmaengine: Add dma router for pl08x in LPC32XX SoC ARM: lpc32xx: Remove pl08x platform data in favor for device tree mtd: rawnand: lpx32xx: Request DMA channels using DT entries ASoC: fsl: Add i2s and pcm drivers for LPC32xx CPUs i2x: pnx: Fix potential deadlock warning from del_timer_sync() call in isr .../devicetree/bindings/dma/arm-pl08x.yaml | 7 + .../bindings/dma/nxp,lpc3220-dmamux.yaml | 49 +++ .../bindings/sound/nxp,lpc3220-i2s.yaml | 73 ++++ MAINTAINERS | 20 + arch/arm/boot/dts/nxp/lpc/lpc32xx.dtsi | 53 ++- arch/arm/mach-lpc32xx/phy3250.c | 54 --- drivers/clk/Kconfig | 1 + drivers/clk/nxp/clk-lpc32xx.c | 26 +- drivers/dma/Kconfig | 9 + drivers/dma/Makefile | 1 + drivers/dma/lpc32xx-dmamux.c | 195 +++++++++ drivers/i2c/busses/i2c-pnx.c | 48 +-- drivers/mtd/nand/raw/lpc32xx_mlc.c | 26 +- drivers/mtd/nand/raw/lpc32xx_slc.c | 26 +- sound/soc/fsl/Kconfig | 7 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/lpc3xxx-i2s.c | 375 ++++++++++++++++++ sound/soc/fsl/lpc3xxx-i2s.h | 79 ++++ sound/soc/fsl/lpc3xxx-pcm.c | 72 ++++ 19 files changed, 993 insertions(+), 130 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/nxp,lpc3220-dmamux.yaml create mode 100644 Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml create mode 100644 drivers/dma/lpc32xx-dmamux.c create mode 100644 sound/soc/fsl/lpc3xxx-i2s.c create mode 100644 sound/soc/fsl/lpc3xxx-i2s.h create mode 100644 sound/soc/fsl/lpc3xxx-pcm.c -- 2.25.1

7 19

[PATCH] soundwire: stream: fix programming slave ports for non-continous port maps
by Krzysztof Kozlowski 09 Sep '24

09 Sep '24

Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and 'sink_ports' - define which ports to program in sdw_program_slave_port_params(). The masks are used to get the appropriate data port properties ('struct sdw_get_slave_dpn_prop') from an array. Bitmasks can be non-continuous or can start from index different than 0, thus when looking for matching port property for given port, we must iterate over mask bits, not from 0 up to number of ports. This fixes allocation and programming slave ports, when a source or sink masks start from further index. Fixes: f8101c74aa54 ("soundwire: Add Master and Slave port programming") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- drivers/soundwire/stream.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 7aa4900dcf31..f275143d7b18 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1291,18 +1291,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, unsigned int port_num) { struct sdw_dpn_prop *dpn_prop; - u8 num_ports; + unsigned long mask; int i; if (direction == SDW_DATA_DIR_TX) { - num_ports = hweight32(slave->prop.source_ports); + mask = slave->prop.source_ports; dpn_prop = slave->prop.src_dpn_prop; } else { - num_ports = hweight32(slave->prop.sink_ports); + mask = slave->prop.sink_ports; dpn_prop = slave->prop.sink_dpn_prop; } - for (i = 0; i < num_ports; i++) { + for_each_set_bit(i, &mask, 32) { if (dpn_prop[i].num == port_num) return &dpn_prop[i]; } -- 2.43.0

6 15

ASoC: soc-pcm: makes snd_soc_dpcm_can_be_xxx() local function
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark No driver is calling snd_soc_dpcm_can_be_xxx() functions. We don't need to have EXPORT_SYMBOL_GPL() for them. This patch-set makes it static function. Thank you for your help !! Best regards --- Kuninori Morimoto

2 4

[PATCH 00/18] ASoC: Intel: boards: updates for 6.11
by Pierre-Louis Bossart 28 Aug '24

28 Aug '24

More simplifications from Brent Lu for Chromebooks, Bard Liao for SoundWire, and support for new Dell SKUs w/ Cirrus Logic codecs added by Charles Keepax. Bard Liao (7): ASoC: Intel: sof_sdw_cs42l42: use dai parameter ASoC: Intel: sof_sdw_rt711: use dai parameter ASoC: Intel: sof_sdw_rt5682: use dai parameter ASoC: Intel: sof_sdw_rt700: use dai parameter ASoC: Intel: sof_sdw_rt_dmic: use from dai parameter ASoC: Intel: sof_sdw_rt_sdca_jack_common: use dai parameter ASoC: Intel: sof_sdw: remove get_codec_dai_by_name Brent Lu (7): ASoC: SOF: sof-audio: rename dai clock setting query function ASoC: SOF: sof-audio: add sof_dai_get_tdm_slots function ASoC: SOF: ipc3-topology: support tdm slot number query ASoC: SOF: ipc4-topology: support tdm slot number query ASoC: Intel: maxim-common: rewrite max_98373_hw_params function ASoC: Intel: sof_da7219: remove local max98373 ops ASoC: Intel: sof_da7219: disable max98373 speaker pins in late_probe Charles Keepax (4): ASoC: Intel: sof_sdw: Add missing controls for cs42l43/cs35l56 ASoC: Intel: soc-acpi: Add match entries for some cs42l43 laptops ASoC: Intel: sof_sdw: Add quirks for some new Dell laptops ASoC: Intel: sof_sdw: Add quirks from some new Dell laptops include/sound/sof.h | 1 + sound/soc/intel/boards/sof_board_helpers.h | 2 - sound/soc/intel/boards/sof_da7219.c | 57 ++------ sound/soc/intel/boards/sof_maxim_common.c | 84 ++++++++++-- sound/soc/intel/boards/sof_sdw.c | 128 +++++++++++++++--- sound/soc/intel/boards/sof_sdw_common.h | 4 - sound/soc/intel/boards/sof_sdw_cs42l42.c | 11 +- sound/soc/intel/boards/sof_sdw_rt5682.c | 11 +- sound/soc/intel/boards/sof_sdw_rt700.c | 11 +- sound/soc/intel/boards/sof_sdw_rt711.c | 11 +- sound/soc/intel/boards/sof_sdw_rt_dmic.c | 14 +- .../boards/sof_sdw_rt_sdca_jack_common.c | 11 +- .../intel/common/soc-acpi-intel-arl-match.c | 50 +++++++ .../intel/common/soc-acpi-intel-rpl-match.c | 50 +++++++ sound/soc/sof/ipc3-topology.c | 14 +- sound/soc/sof/ipc4-topology.c | 14 +- sound/soc/sof/sof-audio.c | 20 ++- sound/soc/sof/sof-audio.h | 9 +- 18 files changed, 338 insertions(+), 164 deletions(-) -- 2.43.0

4 21

[PATCH v7 0/4] ASoC: grace time for DPCM cleanup
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark, Pierre-Louis, Jerome Cc each ASoC driver maintainer This is v7 of DPCM cleanup As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.12 or v6.13 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.inte… Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87bk4oqerx.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/8734pctmte.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87r0ctwzr4.wl-kuninori.morimoto.gx@renesas.com v6 -> v7 - based on latest ASoC branch (for-6.12) v5 -> v6 - based on latest ASoC branch v4 -> v5 - typo fix: limition -> limitation - typo fix: catpure -> capture - include Intel patch v3 -> v4 - don't check Codec on DPCM - include Jerome's dpcm_xxx update patch v2 -> v3 - tidyup typo (reuqsts -> requests) - add Tested-by on git-log v1 -> v2 - tidyup Codec check warning output condition Jerome Brunet (1): ASoC: amlogic: do not use dpcm_playback/capture flags Kuninori Morimoto (2): ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition ASoC: remove snd_soc_dai_link_set_capabilities() Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: use playback/capture_only flags include/sound/soc-dai.h | 1 - include/sound/soc.h | 1 + sound/soc/fsl/imx-card.c | 3 -- sound/soc/generic/audio-graph-card.c | 2 - sound/soc/generic/audio-graph-card2.c | 2 - sound/soc/generic/simple-card.c | 2 - sound/soc/intel/boards/sof_sdw.c | 4 +- sound/soc/meson/axg-card.c | 11 +++-- sound/soc/meson/gx-card.c | 1 - sound/soc/meson/meson-card-utils.c | 4 +- sound/soc/qcom/common.c | 1 - sound/soc/soc-dai.c | 38 ---------------- sound/soc/soc-pcm.c | 65 +++++++++++++++------------ 13 files changed, 47 insertions(+), 88 deletions(-) -- 2.43.0

2 7

[PATCH v6 0/4] ASoC: grace time for DPCM cleanup
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark, Pierre-Louis, Jerome Cc each ASoC driver maintainer This is resend of v6 of DPCM cleanup As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.12 or v6.13 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.inte… Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87bk4oqerx.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/8734pctmte.wl-kuninori.morimoto.gx@renesas.com v5 -> v6 - based on latest ASoC branch v4 -> v5 - typo fix: limition -> limitation - typo fix: catpure -> capture - include Intel patch v3 -> v4 - don't check Codec on DPCM - include Jerome's dpcm_xxx update patch v2 -> v3 - tidyup typo (reuqsts -> requests) - add Tested-by on git-log v1 -> v2 - tidyup Codec check warning output condition Jerome Brunet (1): ASoC: amlogic: do not use dpcm_playback/capture flags Kuninori Morimoto (2): ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition ASoC: remove snd_soc_dai_link_set_capabilities() Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: use playback/capture_only flags include/sound/soc-dai.h | 1 - include/sound/soc.h | 1 + sound/soc/fsl/imx-card.c | 3 -- sound/soc/generic/audio-graph-card.c | 2 - sound/soc/generic/audio-graph-card2.c | 2 - sound/soc/generic/simple-card.c | 2 - sound/soc/intel/boards/sof_sdw.c | 4 +- sound/soc/meson/axg-card.c | 11 +++-- sound/soc/meson/gx-card.c | 1 - sound/soc/meson/meson-card-utils.c | 4 +- sound/soc/qcom/common.c | 1 - sound/soc/soc-dai.c | 38 ---------------- sound/soc/soc-pcm.c | 65 +++++++++++++++------------ 13 files changed, 47 insertions(+), 88 deletions(-) -- 2.43.0

2 5

[PATCH v5 0/4] ASoC: grace time for DPCM cleanup
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark, Pierre-Louis, Jerome Cc each ASoC driver maintainer This is v5 of DPCM cleanup As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.11 or v6.12 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.inte… Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com v4 -> v5 - typo fix: limition -> limitation - typo fix: catpure -> capture - include Intel patch v3 -> v4 - don't check Codec on DPCM - include Jerome's dpcm_xxx update patch v2 -> v3 - tidyup typo (reuqsts -> requests) - add Tested-by on git-log v1 -> v2 - tidyup Codec check warning output condition Jerome Brunet (1): ASoC: amlogic: do not use dpcm_playback/capture flags Kuninori Morimoto (2): ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition ASoC: remove snd_soc_dai_link_set_capabilities() Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: use playback/capture_only flags include/sound/soc-dai.h | 1 - include/sound/soc.h | 1 + sound/soc/fsl/imx-card.c | 3 -- sound/soc/generic/audio-graph-card.c | 2 - sound/soc/generic/audio-graph-card2.c | 2 - sound/soc/generic/simple-card.c | 2 - sound/soc/intel/boards/sof_sdw.c | 4 +- sound/soc/meson/axg-card.c | 11 +++-- sound/soc/meson/gx-card.c | 1 - sound/soc/meson/meson-card-utils.c | 4 +- sound/soc/qcom/common.c | 1 - sound/soc/soc-dai.c | 38 ---------------- sound/soc/soc-pcm.c | 65 +++++++++++++++------------ 13 files changed, 47 insertions(+), 88 deletions(-) -- 2.43.0

2 9

[PATCH] ASoC: soc-pcm: remove snd_soc_dpcm_stream_lock_irqsave_nested()
by Kuninori Morimoto 21 Aug '24

21 Aug '24

soc-pcm.c has snd_soc_dpcm_stream_lock_irqsave_nested() / snd_soc_dpcm_stream_unlock_irqrestore() helper function, but it is almost nothing help. It just makes a code complex. Let's remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/soc-pcm.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 58381801e41d4..4571785736f76 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -49,12 +49,6 @@ static inline int _soc_pcm_ret(struct snd_soc_pcm_runtime *rtd, return ret; } -#define snd_soc_dpcm_stream_lock_irqsave_nested(rtd, stream, flags) \ - snd_pcm_stream_lock_irqsave_nested(snd_soc_dpcm_get_substream(rtd, stream), flags) - -#define snd_soc_dpcm_stream_unlock_irqrestore(rtd, stream, flags) \ - snd_pcm_stream_unlock_irqrestore(snd_soc_dpcm_get_substream(rtd, stream), flags) - #define DPCM_MAX_BE_USERS 8 static inline const char *soc_cpu_dai_name(struct snd_soc_pcm_runtime *rtd) @@ -2144,7 +2138,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, be = dpcm->be; be_substream = snd_soc_dpcm_get_substream(be, stream); - snd_soc_dpcm_stream_lock_irqsave_nested(be, stream, flags); + snd_pcm_stream_lock_irqsave_nested(be_substream, flags); /* is this op for this BE ? */ if (!snd_soc_dpcm_be_can_update(fe, be, stream)) @@ -2291,7 +2285,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, break; } next: - snd_soc_dpcm_stream_unlock_irqrestore(be, stream, flags); + snd_pcm_stream_unlock_irqrestore(be_substream, flags); if (ret) break; } -- 2.43.0

2 2

[RFC PATCH 00/16] soundwire/ASoC: speed-up downloads with BTP/BRA protocol
by Pierre-Louis Bossart 20 Aug '24

20 Aug '24

This RFC patchset suggests a new API for ASoC codec drivers to use for firmware/table downloads. Problem statement: All existing transfers initiated by codec drivers rely on SoundWire read/write commands, which can only support ONE byte per frame. With the typical 48kHz frame rate, this means 384 kbits/s. In addition, the command/control is typically handled with a FIFO and interrupts which adds more software overhead. To give a practical reference, sending 32Kb takes 2.5s on Intel platforms, which means about 105kbit/s only. Additional non-audio activity is likely to adversely impact interrupt scheduling and further decrease the transfer speeds. New SDCA-based codecs have a need to download tables and DSP firmware which are typically between 20 and 256 Kb. The slow bus operation has a direct impact on boot/resume times, and clearly having to wait more than 300ms is a showstopper in terms of latency requirements and user-experience. Suggested solution: The MIPI specification and most of the new codecs support the Bulk Transfer Protocol (BTP) and specifically the Bulk Register Access (BRA) configuration. This mode reclaims the 'audio' data space of the SoundWire frame to send firmware/coefficients over the DataPort 0 (DP0). The API suggested is rather simple, with the following sequence expected: open(): reserve resources and prepare hardware send_async(): trigger DMAs and perform SoundWire bank switch wait(): wait for DMA completion and disable DMAs close(): release resources Benefits: Even after accounting for the protocol overhead, the data can be sent 8x or 16x faster on the link than with the regular commands. With the use of DMAs, the software overhead becomes limited to the initialization. Measured results show that transferring the same 32Kb takes about 100ms, a 25x improvement on the baseline write() commands with an actual bitrate of 2.6 Mbits/s. These results are a measure of bus/hardware performance mainly, and will typically not be too modified by the CPU activity and scheduling. The performance for reads is similar, with a 25x speedup measured. Limitations: Setting up the transfers over DP0 takes time, and the reliance on DMAs on the host side brings alignment restrictions. The BTP/BRA protocol is really only relevant for "large" transfers done during boot/resume *before* audio transfers take place. Mixing BTP/BRA and audio is a nightmare, this patchset suggests a mutual-exclusion between two usages. Scope: This patchset only exposes the API and a debugfs interface to initiate commands, validate results and measure performance. The actual use of the API is left as an exercise for codec driver developers. This patchset depends on a number of pre-requisite patches and will not build on top of any for-next branches. The main intent of this RFC is to gather comments on the usage, API, benefits and restrictions. The code and functionality was tested on an Intel LunarLake RVP platform connected to a Realtek RT711-SDCA device. Acknowledgements: Thanks to Zeek Tsai at Realtek for providing test sequences that helped reconcile the data formatted by the host driver with the expected results on the code side. Pierre-Louis Bossart (16): Documentation: driver: add SoundWire BRA description soundwire: cadence: add BTP support for DP0 soundwire: stream: extend sdw_alloc_stream() to take 'type' parameter soundwire: extend sdw_stream_type to BPT soundwire: stream: special-case the bus compute_params() routine soundwire: stream: reuse existing code for BPT stream soundwire: bus: add API for BPT protocol soundwire: bus: add bpt_stream pointer soundwire: crc8: add constant table soundwire: cadence: add BTP/BRA helpers to format data soundwire: intel_auxdevice: add indirection for BPT open/close/send_async/wait ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA soundwire: intel: add BPT context definition soundwire: intel_ace2x: add BPT open/close/send_async/wait soundwire: debugfs: add interface for BPT/BRA transfers ASoC: rt711-sdca: add DP0 support Documentation/driver-api/soundwire/bra.rst | 478 +++++++++++++ Documentation/driver-api/soundwire/index.rst | 1 + Documentation/driver-api/soundwire/stream.rst | 2 +- .../driver-api/soundwire/summary.rst | 5 +- drivers/soundwire/Kconfig | 1 + drivers/soundwire/Makefile | 4 +- drivers/soundwire/amd_manager.c | 2 +- drivers/soundwire/bus.c | 77 +++ drivers/soundwire/bus.h | 18 + drivers/soundwire/cadence_master.c | 646 +++++++++++++++++- drivers/soundwire/cadence_master.h | 30 + drivers/soundwire/crc8.c | 277 ++++++++ drivers/soundwire/crc8.h | 11 + drivers/soundwire/debugfs.c | 122 +++- .../soundwire/generic_bandwidth_allocation.c | 84 ++- drivers/soundwire/intel.h | 12 + drivers/soundwire/intel_ace2x.c | 377 ++++++++++ drivers/soundwire/intel_auxdevice.c | 55 ++ drivers/soundwire/qcom.c | 2 +- drivers/soundwire/stream.c | 137 +++- include/linux/soundwire/sdw.h | 91 ++- include/linux/soundwire/sdw_intel.h | 16 + include/sound/hda-sdw-bpt.h | 76 +++ sound/soc/codecs/rt711-sdca-sdw.c | 8 + sound/soc/qcom/sdw.c | 2 +- sound/soc/sof/intel/Kconfig | 8 +- sound/soc/sof/intel/Makefile | 4 + sound/soc/sof/intel/hda-sdw-bpt.c | 328 +++++++++ 28 files changed, 2810 insertions(+), 64 deletions(-) create mode 100644 Documentation/driver-api/soundwire/bra.rst create mode 100644 drivers/soundwire/crc8.c create mode 100644 drivers/soundwire/crc8.h create mode 100644 include/sound/hda-sdw-bpt.h create mode 100644 sound/soc/sof/intel/hda-sdw-bpt.c -- 2.39.2

4 60

[REGRESSION] ALSA: firewire-lib: heavy digital distortion with Fireface 800
by edmund.raile 20 Aug '24

20 Aug '24

Between the kernel releases 6.9.9 and 6.10.0, something changed that causes heavy digital distortion on playback from at least ALSA and PipeWire. The rhythm of the music is discernable in the output, so it isn't just random noise. It sounds a bit like bitcrushing, but not quite. The generated overtones appear to be dependet on the sample rate. I am sorry I can not be more specific, there are no kernel messages this time. As Mr. Sakamoto recently committed all these changes to firewire he might be able to identify the issue easily, which is why I'd like to ask him to look into it. Kind regards, Edmund Raile. #regzbot introduced: v6.9.9..v6.10

2 1