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

[PATCH v6 00/10] Add support for CS35L41 in HDA systems
by Lucas Tanure 31 Oct '22

31 Oct '22

Add support for laptops that have CS35L41 connected to an HDA codec by I2S and direct I2C connection to the CPU. Laptops that use CS35L41 and are SPI will be added in the future, after the support for it is resolved at i2c-multi-instantiate driver. i2c-multi-instantiate thread: https://lkml.org/lkml/2021/12/10/557 Hardware: - Some laptops have two CS35L41 amplifiers, connected to Realtek ALC287 by an I2S bus and by and direct I2C to the CPU. - The ALC287 codec is connected to the CPU by an HDA bus. - The CS35L41 has a DSP which will require firmware to be loaded. Architecture: - Creation of a library of shared functions for CS35L41 ASoC and HDA - HDA codec driver (RealTek) and CS35L41 HDA driver are combined by using component binding, where it uses device names to find the components and bind to the master - The HDA CS35L41 driver applies pre-defined registers sequences for each action in playback for HDA Sound card Changes from V5: - Fix build issues reported by Intel Test Bot - Check devm_kasprintf return - Add ACPI dependency to HDA drivers V5: https://lkml.org/lkml/2021/12/16/430 Changes from V4: - Save index received from ACPI for latter use in DSP Support - Move CS35L41_DSP1_CCM_CORE_CTRL to regmap_write so doesn't affect DSP hibernation feature V4: https://lkml.org/lkml/2021/12/14/487 Changes from V3: - SPI bus driver starter added - Use separate modules approach instead of liking library - Add CSC3551 ACPI _HID for more I2C laptops - Removed regulators from HDA driver - Add note about Non-conforming _HID V3: https://lkml.org/lkml/2021/11/23/723 Changes from V2: - Not an RFC - Create a new HDA driver for CS35L41 instead of using the ASoC one - Use component binding and device names to find the CS35L41 driver - Create a shared library for ASoC and HDA CS35L41 drivers v2: https://lkml.org/lkml/2021/10/8/344 Lucas Tanure (9): ASoC: cs35l41: Convert tables to shared source code ASoC: cs35l41: Move cs35l41_otp_unpack to shared code ASoC: cs35l41: Move power initializations to reg_sequence ASoC: cs35l41: Create shared function for errata patches ASoC: cs35l41: Create shared function for setting channels ASoC: cs35l41: Create shared function for boost configuration hda: cs35l41: Add support for CS35L41 in HDA systems ACPI / scan: Create platform device for CLSA0100 and CSC3551 ACPI nodes ALSA: hda/realtek: Add support for Legion 7 16ACHg6 laptop Stefan Binding (1): ALSA: hda/realtek: Add CS35L41 support for Thinkpad laptops MAINTAINERS | 2 + drivers/acpi/scan.c | 3 + drivers/platform/x86/i2c-multi-instantiate.c | 11 + include/sound/cs35l41.h | 739 ++++++++++++++++++ sound/pci/hda/Kconfig | 29 + sound/pci/hda/Makefile | 10 + sound/pci/hda/cs35l41_hda.c | 527 +++++++++++++ sound/pci/hda/cs35l41_hda.h | 69 ++ sound/pci/hda/cs35l41_hda_i2c.c | 66 ++ sound/pci/hda/cs35l41_hda_spi.c | 63 ++ sound/pci/hda/hda_component.h | 20 + sound/pci/hda/patch_realtek.c | 146 ++++ sound/soc/codecs/Kconfig | 11 +- sound/soc/codecs/Makefile | 4 +- sound/soc/codecs/cs35l41-i2c.c | 1 - .../{cs35l41-tables.c => cs35l41-lib.c} | 355 ++++++++- sound/soc/codecs/cs35l41-spi.c | 1 - sound/soc/codecs/cs35l41.c | 360 +-------- sound/soc/codecs/cs35l41.h | 734 ----------------- 19 files changed, 2055 insertions(+), 1096 deletions(-) create mode 100644 sound/pci/hda/cs35l41_hda.c create mode 100644 sound/pci/hda/cs35l41_hda.h create mode 100644 sound/pci/hda/cs35l41_hda_i2c.c create mode 100644 sound/pci/hda/cs35l41_hda_spi.c create mode 100644 sound/pci/hda/hda_component.h rename sound/soc/codecs/{cs35l41-tables.c => cs35l41-lib.c} (71%) -- 2.34.1

11 28

[PATCH 1/2] ALSA: hda: Add Intel DG2 PCI ID and HDMI codec vid
by Kai Vehmanen 14 Oct '22

14 Oct '22

Add HD Audio PCI ID and HDMI codec vendor ID for Intel DG2. Reviewed-by: Uma Shankar <uma.shankar(a)intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/hda_intel.c | 12 +++++++++++- sound/pci/hda/patch_hdmi.c | 1 + 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 221afacbc7fd..b98d7975adea 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -335,7 +335,10 @@ enum { ((pci)->device == 0x0c0c) || \ ((pci)->device == 0x0d0c) || \ ((pci)->device == 0x160c) || \ - ((pci)->device == 0x490d)) + ((pci)->device == 0x490d) || \ + ((pci)->device == 0x4f90) || \ + ((pci)->device == 0x4f91) || \ + ((pci)->device == 0x4f92)) #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98) @@ -2477,6 +2480,13 @@ static const struct pci_device_id azx_ids[] = { /* DG1 */ { PCI_DEVICE(0x8086, 0x490d), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + /* DG2 */ + { PCI_DEVICE(0x8086, 0x4f90), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + { PCI_DEVICE(0x8086, 0x4f91), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + { PCI_DEVICE(0x8086, 0x4f92), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, /* Alderlake-S */ { PCI_DEVICE(0x8086, 0x7ad0), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 65d2c5539919..98633d2684de 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -4382,6 +4382,7 @@ HDA_CODEC_ENTRY(0x80862814, "DG1 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862815, "Alderlake HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI", patch_i915_tgl_hdmi), +HDA_CODEC_ENTRY(0x80862819, "DG2 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi), base-commit: d7aca8d8f548570f650d9b1dfedf6902f56f2bce -- 2.34.1

3 3

[PATCH][next] ASoC: q6asm: use kcalloc() instead of kzalloc()
by Gustavo A. R. Silva 28 Jul '22

28 Jul '22

Use 2-factor multiplication argument form kcalloc() instead of kzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> --- sound/soc/qcom/qdsp6/q6asm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/qcom/qdsp6/q6asm.c b/sound/soc/qcom/qdsp6/q6asm.c index 9251d8548965..195780f75d05 100644 --- a/sound/soc/qcom/qdsp6/q6asm.c +++ b/sound/soc/qcom/qdsp6/q6asm.c @@ -513,7 +513,7 @@ int q6asm_map_memory_regions(unsigned int dir, struct audio_client *ac, return 0; } - buf = kzalloc(((sizeof(struct audio_buffer)) * periods), GFP_ATOMIC); + buf = kcalloc(periods, sizeof(*buf), GFP_ATOMIC); if (!buf) { spin_unlock_irqrestore(&ac->lock, flags); return -ENOMEM; -- 2.27.0

3 2

[PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support
by Alifer Moraes 21 Jun '22

21 Jun '22

From: Pierluigi Passaro <pierluigi.p(a)variscite.com> The codec WM8904 can use internal FLL as PLL source. Whenever the PLL source is not an external MCLK, this source must be setup during hw_params callback otherwise the BCLK could be wrongly evaluated. The SND_SOC_BIAS_PREPARE event is raised after the hw_params callback, so there is no need to set again PLL and SYSCLK and actually there's no need at all the set_bias_level function. Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot call is required. Signed-off-by: Pierluigi Passaro <pierluigi.p(a)variscite.com> Signed-off by: Alifer Moraes <alifer.m(a)variscite.com> --- sound/soc/fsl/fsl-asoc-card.c | 47 +++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c index 5ee945505281..817dbc1ec635 100644 --- a/sound/soc/fsl/fsl-asoc-card.c +++ b/sound/soc/fsl/fsl-asoc-card.c @@ -23,6 +23,7 @@ #include "imx-audmux.h" #include "../codecs/sgtl5000.h" +#include "../codecs/wm8904.h" #include "../codecs/wm8962.h" #include "../codecs/wm8960.h" #include "../codecs/wm8994.h" @@ -257,6 +258,38 @@ static int fsl_asoc_card_hw_free(struct snd_pcm_substream *substream) } } + if (of_device_is_compatible(dev->of_node, "fsl,imx-audio-wm8904")) { + struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0); + unsigned int pll_out; + + ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2, + params_physical_width(params)); + if (ret) { + dev_err(dev, "failed to set TDM slot for cpu dai\n"); + return ret; + } + + if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE) + pll_out = priv->sample_rate * 384; + else + pll_out = priv->sample_rate * 256; + + ret = snd_soc_dai_set_pll(codec_dai, codec_priv->pll_id, + codec_priv->pll_id, + codec_priv->mclk_freq, pll_out); + if (ret) { + dev_err(dev, "failed to start FLL: %d\n", ret); + return ret; + } + + ret = snd_soc_dai_set_sysclk(codec_dai, codec_priv->fll_id, + pll_out, SND_SOC_CLOCK_IN); + if (ret) { + dev_err(dev, "failed to set SYSCLK: %d\n", ret); + return ret; + } + } + return 0; } @@ -651,6 +684,19 @@ static int fsl_asoc_card_probe(struct platform_device *pdev) priv->codec_priv.fll_id = WM8960_SYSCLK_AUTO; priv->codec_priv.pll_id = WM8960_SYSCLK_AUTO; priv->dai_fmt |= SND_SOC_DAIFMT_CBP_CFP; + } else if (of_device_is_compatible(np, "fsl,imx-audio-wm8904")) { + codec_dai_name = "wm8904-hifi"; + priv->card.set_bias_level = NULL; + priv->codec_priv.mclk_id = WM8904_CLK_FLL; + priv->codec_priv.fll_id = WM8904_CLK_FLL; + priv->codec_priv.pll_id = WM8904_FLL_MCLK; + priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM; + if (strstr(cpu_np->name, "esai")) { + priv->cpu_priv.sysclk_freq[TX] = priv->codec_priv.mclk_freq; + priv->cpu_priv.sysclk_freq[RX] = priv->codec_priv.mclk_freq; + priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT; + priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT; + } } else if (of_device_is_compatible(np, "fsl,imx-audio-ac97")) { codec_dai_name = "ac97-hifi"; priv->dai_fmt = SND_SOC_DAIFMT_AC97; @@ -900,6 +946,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = { { .compatible = "fsl,imx-audio-tlv320aic32x4", }, { .compatible = "fsl,imx-audio-tlv320aic31xx", }, { .compatible = "fsl,imx-audio-sgtl5000", }, + { .compatible = "fsl,imx-audio-wm8904", }, { .compatible = "fsl,imx-audio-wm8962", }, { .compatible = "fsl,imx-audio-wm8960", }, { .compatible = "fsl,imx-audio-mqs", }, -- 2.25.1

4 10

[PATCH v2 00/14] ASoC: Intel: avs: Topology and path management
by Cezary Rojewski 10 Jun '22

10 Jun '22

A continuation of avs-driver initial series [1]. This chapter covers path management and topology parsing part which was ealier path of the main series. The two patches that represented these two subjects in the initial series, have been split into many to allow for easier review and discussion. AVS topology is split into two major parts: dictionaries - found within ASoC topology manifest - and path templates. Dictionaries job is to reduce the total amount of memory occupied by topology elements. Rather than having every pipeline and module carry its own information, each refers to specific entry in specific dictionary by provided (from topology file) indexes. In consequence, most struct avs_tplg_xxx are made out of pointers. Path templates are similar to path descriptions found in skylake-driver and they describe how given path shall look like in runtime - number of modules and pipelines that shape it and how they are laid out. A single path template is tied either to FE or BE and thus at most to a single, user-visible endpoint when speaking of FE. Path is a software representation of its ADSP firmware equivalent. It's a logical container for pipelines which are themselves containers - this time for modules i.e. processing units. Depending on the number of audio formats supported, each path template may carry one or more descriptions of given path. During runtime, when audio format is known, description matching said format is selected and used when instantiating path on ADSP firmware side through IPCs. Changes v1 -> v2: - fixed 'set but not used' warning in patch 10/14 as mentioned by ikp builder Changes RFC -> v1: - Plenty of rewordings and spelling fixes as requested by Pierre - any sysfs-functionality-related left in RFC dropped, will be part of separate subject in the future - separated parsing of formatted strings into: "Support link_mask formatted string" patch, increasing series size to 14 patches [1]: https://lore.kernel.org/alsa-devel/20220207122108.3780926-1-cezary.rojewski… Cezary Rojewski (14): ASoC: Intel: avs: Declare vendor tokens ASoC: Intel: avs: Add topology parsing infrastructure ASoC: Intel: avs: Parse module-extension tuples ASoC: Intel: avs: Parse pplcfg and binding tuples ASoC: Intel: avs: Parse pipeline and module tuples ASoC: Intel: avs: Parse path and path templates tuples ASoC: Intel: avs: Add topology loading operations ASoC: Intel: avs: Support link_mask formatted string ASoC: Intel: avs: Declare path and its components ASoC: Intel: avs: Path creation and freeing ASoC: Intel: avs: Path state management ASoC: Intel: avs: Arm paths after creating them ASoC: Intel: avs: Prepare modules before bindings them ASoC: Intel: avs: Configure modules according to their type include/uapi/sound/intel/avs/tokens.h | 126 ++ sound/soc/intel/Kconfig | 2 + sound/soc/intel/avs/Makefile | 3 +- sound/soc/intel/avs/avs.h | 23 + sound/soc/intel/avs/path.c | 1005 ++++++++++++++++ sound/soc/intel/avs/path.h | 72 ++ sound/soc/intel/avs/topology.c | 1600 +++++++++++++++++++++++++ sound/soc/intel/avs/topology.h | 194 +++ 8 files changed, 3024 insertions(+), 1 deletion(-) create mode 100644 include/uapi/sound/intel/avs/tokens.h create mode 100644 sound/soc/intel/avs/path.c create mode 100644 sound/soc/intel/avs/path.h create mode 100644 sound/soc/intel/avs/topology.c create mode 100644 sound/soc/intel/avs/topology.h base-commit: bc55cfd5718c7c23e5524582e9fa70b4d10f2433 -- 2.25.1

3 19

[PATCH] ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min
by Marek Vasut 19 May '22

19 May '22

While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first. Fixes: 817f7c9335ec0 ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()") Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/soc-ops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index f24f7354f46fe..6389a512c4dc6 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -317,7 +317,7 @@ int snd_soc_put_volsw(struct snd_kcontrol *kcontrol, mask = BIT(sign_bit + 1) - 1; val = ucontrol->value.integer.value[0]; - if (mc->platform_max && val > mc->platform_max) + if (mc->platform_max && ((int)val + min) > mc->platform_max) return -EINVAL; if (val > max - min) return -EINVAL; @@ -330,7 +330,7 @@ int snd_soc_put_volsw(struct snd_kcontrol *kcontrol, val = val << shift; if (snd_soc_volsw_is_stereo(mc)) { val2 = ucontrol->value.integer.value[1]; - if (mc->platform_max && val2 > mc->platform_max) + if (mc->platform_max && ((int)val2 + min) > mc->platform_max) return -EINVAL; if (val2 > max - min) return -EINVAL; -- 2.34.1

6 14

[PATCH v3 0/6] Add driver for SAMA7G5's PDMC
by Codrin Ciubotariu 05 May '22

05 May '22

This patch series adds support for Pulse Density Microphone Controller (PDMC), present on Microchip's SAMA7G5. The PDMC interfaces up to 4 digital microphones having Pulse Density Modulated (PDM) outputs. It generates a single clock line and samples 1 or 2 data lines. The signal path includes an audio grade programmable decimation filter and outputs 24-bit audio words. The source of each channel can be independently defined as PDMC_DS0 or PDMC_DS1, sampled at the rising or falling edge of PDMC_CLK. The patch series starts with a fix on the ASoC DMA engine support. Then continues with the bindings and the driver of PDMC. It is followed by the DT nodes for SAMA7G5 and SAMA7G5-EK. In the end, the drivers for PDMC and PDM microphones are enabled in sama7_defconfig. Changes in v3: - addressed new DT bindings comments from Krzysztof Kozlowski Changes in v2: - addressed DT bindings comments from Krzysztof Kozlowski Codrin Ciubotariu (6): ASoC: dmaengine: do not use a NULL prepare_slave_config() callback ASoC: dt-bindings: Document Microchip's PDMC ASoC: atmel: mchp-pdmc: add PDMC driver ARM: dts: at91: sama7g5: add nodes for PDMC ARM: dts: at91: sama7g5ek: add node for PDMC0 ARM: configs: at91: sama7_defconfig: add MCHP PDMC and DMIC drivers .../bindings/sound/microchip,pdmc.yaml | 100 ++ arch/arm/boot/dts/at91-sama7g5ek.dts | 21 +- arch/arm/boot/dts/sama7g5.dtsi | 24 + arch/arm/configs/sama7_defconfig | 2 + include/dt-bindings/sound/microchip,pdmc.h | 13 + sound/soc/atmel/Kconfig | 16 + sound/soc/atmel/Makefile | 2 + sound/soc/atmel/mchp-pdmc.c | 1084 +++++++++++++++++ sound/soc/soc-generic-dmaengine-pcm.c | 6 +- 9 files changed, 1264 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/microchip,pdmc.yaml create mode 100644 include/dt-bindings/sound/microchip,pdmc.h create mode 100644 sound/soc/atmel/mchp-pdmc.c -- 2.32.0

6 16

[PATCH v4] dt-bindings: dsp: mediatek: add mt8195 dsp document
by YC Hung 29 Apr '22

29 Apr '22

From: "YC Hung" <yc.hung(a)mediatek.com> This patch adds mt8195 dsp document. The dsp is used for Sound Open Firmware driver node. It includes registers, clocks, memory regions, and mailbox for dsp. Signed-off-by: yc.hung <yc.hung(a)mediatek.com> --- Changes since v3: Fix patch v3 error : v3 only provide difference between v3 and v2. Changes since v2: Remove useless watchdog interrupt. Add commit message more detail description. Changes since v1: Rename yaml file name as mediatek,mt8195-dsp.yaml Refine descriptions for mailbox, memory-region and drop unused labels in examples. --- .../bindings/dsp/mediatek,mt8195-dsp.yaml | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml new file mode 100644 index 000000000000..b7e68b0dfa13 --- /dev/null +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dsp/mediatek,mt8195-dsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek mt8195 DSP core + +maintainers: + - YC Hung <yc.hung(a)mediatek.com> + +description: | + Some boards from mt8195 contain a DSP core used for + advanced pre- and post- audio processing. + +properties: + compatible: + const: mediatek,mt8195-dsp + + reg: + items: + - description: Address and size of the DSP Cfg registers + - description: Address and size of the DSP SRAM + + reg-names: + items: + - const: cfg + - const: sram + + clocks: + items: + - description: mux for audio dsp clock + - description: 26M clock + - description: mux for audio dsp local bus + - description: default audio dsp local bus clock source + - description: clock gate for audio dsp clock + - description: mux for audio dsp access external bus + + clock-names: + items: + - const: adsp_sel + - const: clk26m_ck + - const: audio_local_bus + - const: mainpll_d7_d2 + - const: scp_adsp_audiodsp + - const: audio_h + + power-domains: + maxItems: 1 + + mboxes: + items: + - description: ipc reply between host and audio DSP. + - description: ipc request between host and audio DSP. + + mbox-names: + items: + - const: mbox0 + - const: mbox1 + + memory-region: + items: + - description: dma buffer between host and DSP. + - description: DSP system memory. + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - memory-region + - power-domains + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + dsp@10803000 { + compatible = "mediatek,mt8195-dsp"; + reg = <0x10803000 0x1000>, + <0x10840000 0x40000>; + reg-names = "cfg", "sram"; + clocks = <&topckgen 10>, //CLK_TOP_ADSP + <&clk26m>, + <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS + <&topckgen 136>, //CLK_TOP_MAINPLL_D7_D2 + <&scp_adsp 0>, //CLK_SCP_ADSP_AUDIODSP + <&topckgen 34>; //CLK_TOP_AUDIO_H + clock-names = "adsp_sel", + "clk26m_ck", + "audio_local_bus", + "mainpll_d7_d2", + "scp_adsp_audiodsp", + "audio_h"; + memory-region = <&adsp_dma_mem_reserved>, + <&adsp_mem_reserved>; + power-domains = <&spm 6>; //MT8195_POWER_DOMAIN_ADSP + mbox-names = "mbox0", "mbox1"; + mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>; + }; -- 2.18.0

4 6

[RFC PATCH 0/5] Apple Macs machine-level ASoC driver
by Martin Povišer 25 Apr '22

25 Apr '22

Hi, I put together a machine-level ASoC driver for recent Apple Macs (the ones with ARM64 SoCs) and want to gauge opinions. Commit 1 is the binding. It is some subset of simple-audio-card with the extra distinction of allowing multiple CPU/CODEC DAIs per a DAI link. I want to draw special attention to the issue of describing speaker topologies. The way it now works is that the driver expects the speakers to be declared in a fixed order in the sound-dai= list. This populates a topology the driver expects on a particular machine model. Mark (in CC) has made the suggestion of keeping the topology descriptions with the codec nodes themselves in some generic manner, akin to how sound-name-prefix= already helps identify codecs to the user. Commit 2 adds a new ASoC card method (filter_controls) to let the card prevent some codec kcontrols from being visible to userspace. For example the TAS2770 speaker amp driver would be happy to expose TDM slot selection and ISENSE/VSENSE enables which is ridiculous. I am all ears on how to make the patch acceptable to upstream. Commit 3 makes ASoC tolerate N-to-M DAI links, not sure what the right (simple) approach should be there. Commit 4 adds some utility function and commit 5 is the driver itself. Let me know what you think. Martin Martin Povišer (5): dt-bindings: sound: Add Apple Macs sound system HACK: ASoC: Add card->filter_controls hook HACK: ASoC: Tolerate N-cpus-to-M-codecs links ASoC: Introduce snd_soc_of_get_dai_link_cpus ASoC: Add macaudio machine driver .../bindings/sound/apple,macaudio.yaml | 103 +++ include/sound/soc.h | 7 + sound/soc/apple/Kconfig | 10 + sound/soc/apple/Makefile | 3 + sound/soc/apple/macaudio.c | 597 ++++++++++++++++++ sound/soc/soc-core.c | 125 +++- sound/soc/soc-dapm.c | 34 +- sound/soc/soc-pcm.c | 3 + 8 files changed, 860 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/apple,macaudio.yaml create mode 100644 sound/soc/apple/Kconfig create mode 100644 sound/soc/apple/Makefile create mode 100644 sound/soc/apple/macaudio.c -- 2.33.0

4 19

Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver
by Mark Brown 22 Apr '22

22 Apr '22

On Thu, Mar 31, 2022 at 05:04:32PM +0200, Martin Povišer wrote: > > On 31. 3. 2022, at 16:18, Mark Brown <broonie(a)kernel.org> wrote: > > Yes, having two devices driving the bus at the same time wouldn't be > > great. How is the TDM slot selection for the signals done in the > > hardware, I'm not seeing anything immediately obvious in the driver? > > I'd have thought that things would be implemented such that you could > > implement speaker protection on all speakers simultaneously but perhaps > > not. > I don’t know. I would have to go study the details of this. Should I see > if I can find a combination of ‘ASI1 Sel’ ‘VSENSE’ ‘ISENSE’ settings > that would lead to driver conflict on one of the models, or is there > a chance we could hide those controls just on the basis of ‘it doesn’t > do anything usable and is possibly dangerous’? If ISENSE and VSENSE output are controlled by the same mux as routing then we should lock one of the controls out for at least stereo devices (it might be a good idea to check if the output is actually high Z when ISENSE and VSENSE are off rather than just driving zeros, if not it definitely has to be the routing control). My instinct is that it's better to preserve the ability to implement speaker protection in future since that is something that'd be broadly useful, especially if someone comes up with a generic speaker protection implementation in which case there should be an awful lot of systems out there which could benefit. > >> That’s the reasoning anyway. To reiterate, seems to me the controls > >> are useless/confusing at best and dangerous at worst. > > I'm just not seeing an issue for the slot selection. > Yeah, agreed there’s no (damage) issue as we should to proper volume > caps anyway. Though see above about how ISENSE/VSENSE output slot is controlled I guess :/

2 11