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

[PATCH] ASoC: tlv320aic31xx: Add support for loading filter coefficients
by Romain Gantois 09 Sep '24

09 Sep '24

The TLV320DAC3100 Audio DAC has 25 built-in digital audio processing blocks (PRBs). Each of these PRBs has a static filter structure with programmable coefficients. Once a PRB is selected for use by the DAC, its filter coefficients can be configured via a dedicated set of registers. Define a new optional firmware which can be loaded by the TLV320DAC driver. This firmware describes a full set of filter coefficients for all blocks used by the various PRBs. The firmware's binary format is heavily inspired by the one used in the peb2466 driver. It includes a version marker to allow for potential evolutions of the format. Note that adaptive filtering is not supported i.e. filter coefficients are loaded once before power-on and then cannot be changed while the DAC is powered. This is why only page A coefficients are modified. Page B coefficients are only used for adaptive filtering. Signed-off-by: Romain Gantois <romain.gantois(a)bootlin.com> --- sound/soc/codecs/tlv320aic31xx.c | 100 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c index 2f94cfda0e33..7e624c4b77b6 100644 --- a/sound/soc/codecs/tlv320aic31xx.c +++ b/sound/soc/codecs/tlv320aic31xx.c @@ -12,6 +12,7 @@ * and mono/stereo Class-D speaker driver. */ +#include <asm/unaligned.h> #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/init.h> @@ -22,6 +23,7 @@ #include <linux/gpio/consumer.h> #include <linux/regulator/consumer.h> #include <linux/acpi.h> +#include <linux/firmware.h> #include <linux/of.h> #include <linux/slab.h> #include <sound/core.h> @@ -1638,6 +1640,98 @@ static const struct i2c_device_id aic31xx_i2c_id[] = { }; MODULE_DEVICE_TABLE(i2c, aic31xx_i2c_id); +static int tlv320dac3100_fw_load(struct aic31xx_priv *aic31xx, + const u8 *data, size_t size) +{ + int ret, reg; + u16 val16; + + /* + * Coefficients firmware binary structure. Multi-byte values are big-endian. + * + * @0, 16bits: Magic (0xB30C) + * @2, 16bits: Version (0x0100 for version 1.0) + * @4, 8bits: DAC Processing Block Selection + * @5, 62 16-bit values: Page 8 buffer A DAC programmable filter coefficients + * @129, 12 16-bit values: Page 9 Buffer A DAC programmable filter coefficients + * + * Filter coefficients are interpreted as two's complement values + * ranging from -32 768 to 32 767. For more details on filter coefficients, + * please refer to the TLV320DAC3100 datasheet, tables 6-120 and 6-123. + */ + + if (size != 153) { + dev_err(aic31xx->dev, "firmware size is %zu, expected 153 bytes\n", size); + return -EINVAL; + } + + /* Check magic */ + val16 = get_unaligned_be16(data); + if (val16 != 0xb30c) { + dev_err(aic31xx->dev, "fw magic is 0x%04x expected 0xb30c\n", val16); + return -EINVAL; + } + data += 2; + + /* Check version */ + val16 = get_unaligned_be16(data); + if (val16 != 0x0100) { + dev_err(aic31xx->dev, "invalid firmware version 0x%04x! expected 1", val16); + return -EINVAL; + } + data += 2; + + ret = regmap_write(aic31xx->regmap, AIC31XX_DACPRB, *data); + if (ret) { + dev_err(aic31xx->dev, "failed to write PRB index: err %d\n", ret); + return ret; + } + data += 1; + + /* Page 8 Buffer A coefficients */ + for (reg = 2; reg < 126; reg++) { + ret = regmap_write(aic31xx->regmap, AIC31XX_REG(8, reg), *data); + if (ret) { + dev_err(aic31xx->dev, + "failed to write page 8 filter coefficient %d: err %d\n", reg, ret); + return ret; + } + data++; + } + + /* Page 9 Buffer A coefficients */ + for (reg = 2; reg < 26; reg++) { + ret = regmap_write(aic31xx->regmap, AIC31XX_REG(9, reg), *data); + if (ret) { + dev_err(aic31xx->dev, + "failed to write page 9 filter coefficient %d: err %d\n", reg, ret); + return ret; + } + data++; + } + + dev_info(aic31xx->dev, "done loading DAC filter coefficients\n"); + + return ret; +} + +static int tlv320dac3100_load_coeffs(struct aic31xx_priv *aic31xx, + const char *fw_name) +{ + const struct firmware *fw; + int ret; + + ret = request_firmware(&fw, fw_name, aic31xx->dev); + if (ret) + return ret; + + ret = tlv320dac3100_fw_load(aic31xx, fw->data, fw->size); + + release_firmware(fw); + + return ret; +} + static int aic31xx_i2c_probe(struct i2c_client *i2c) { struct aic31xx_priv *aic31xx; @@ -1727,6 +1821,12 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c) } } + if (aic31xx->codec_type == DAC3100) { + ret = tlv320dac3100_load_coeffs(aic31xx, "tlv320dac3100-coeffs.bin"); + if (ret) + dev_warn(aic31xx->dev, "Did not load any filter coefficients\n"); + } + if (aic31xx->codec_type & DAC31XX_BIT) return devm_snd_soc_register_component(&i2c->dev, &soc_codec_driver_aic31xx, --- base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b change-id: 20240806-tlv320-filter-189edd66496c Best regards, -- Romain Gantois <romain.gantois(a)bootlin.com>

2 1

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

09 Sep '24

This reverts commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 because it breaks codecs using non-continuous masks in source and sink ports. The commit missed the point that port numbers are not used as indices for iterating over prop.sink_ports or prop.source_ports. Soundwire core and existing codecs expect that the array passed as prop.sink_ports and prop.source_ports is continuous. The port mask still might be non-continuous, but that's unrelated. Reported-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Closes: https://lore.kernel.org/all/b6c75eee-761d-44c8-8413-2a5b34ee2f98@linux.inte… Fixes: ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- I will need to fix my codec drivers, but that's independent. --- 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 f275143d7b18..7aa4900dcf31 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; - unsigned long mask; + u8 num_ports; int i; if (direction == SDW_DATA_DIR_TX) { - mask = slave->prop.source_ports; + num_ports = hweight32(slave->prop.source_ports); dpn_prop = slave->prop.src_dpn_prop; } else { - mask = slave->prop.sink_ports; + num_ports = hweight32(slave->prop.sink_ports); dpn_prop = slave->prop.sink_dpn_prop; } - for_each_set_bit(i, &mask, 32) { + for (i = 0; i < num_ports; i++) { if (dpn_prop[i].num == port_num) return &dpn_prop[i]; } -- 2.43.0

5 6

[PATCH] ASoC: tas2781: fix to save the dsp bin file name into the correct array in case name_prefix is not NULL
by Shenghao Ding 09 Sep '24

09 Sep '24

fix to save the dsp bin file name into the correct array, coef_binaryname, instead of rca_binaryname, in case name_prefix is not NULL. Fixes: 55f0a1fa6ea4 ("ASoC: tas2781: Add name_prefix as the prefix name of DSP firmwares and calibrated data files") Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- sound/soc/codecs/tas2781-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c index 59fcce7fef7b..3bc10d615fd3 100644 --- a/sound/soc/codecs/tas2781-i2c.c +++ b/sound/soc/codecs/tas2781-i2c.c @@ -498,7 +498,7 @@ static void tasdevice_fw_ready(const struct firmware *fmw, */ tas_priv->fw_state = TASDEVICE_RCA_FW_OK; if (tas_priv->name_prefix) - scnprintf(tas_priv->rca_binaryname, 64, "%s-%s_coef.bin", + scnprintf(tas_priv->coef_binaryname, 64, "%s-%s_coef.bin", tas_priv->name_prefix, tas_priv->dev_name); else scnprintf(tas_priv->coef_binaryname, 64, "%s_coef.bin", -- 2.34.1

3 3

[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

[PATCH v2] ASoC: dt-bindings: renesas,rsnd: add post-init-providers property
by Kuninori Morimoto 09 Sep '24

09 Sep '24

At least if rsnd is using DPCM connection with Audio-Graph-Card2, fw_devlink might doesn't have enough information to break the cycle (Same problem might occur with Multi-CPU/Codec or Codec2Codec). In such case, rsnd driver will not be probed. Add post-init-providers support to break the link cycle. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- v1 -> v2 - remove basic description/type - add detail description - update git-log Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 07ec6247d9def..458877ce4aa42 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -112,6 +112,13 @@ properties: description: List of necessary clock names. # details are defined below + post-init-providers: + description: | + At least if rsnd is using DPCM connection with Audio-Graph-Card2, fw_devlink might doesn't + have enough information to break the cycle. rsnd driver will not be probed in such case. + Add post-init-providers property to indicate which link in the cycle to break. + Same problem might occur with Multi-CPU/Codec or Codec2Codec. + # ports is below port: $ref: audio-graph-port.yaml#/definitions/port-base -- 2.43.0

2 1

Add stacked and parallel memories support in spi-nor
by Mahapatra, Amit Kumar 09 Sep '24

09 Sep '24

Hello Everyone, As https://lore.kernel.org/all/20231125092137.2948-8-amit.kumar-mahapatra@amd.… thread discussing the addition of stacked and parallel mode support in SPI-NOR has become too long and difficult to follow. Therefore, I'm starting a new email thread to focus on the DT binding changes and the overall implementation architecture for adding stacked and parallel (multi-CS) support in the Kernel. Please share your input on this approach. Background: The AMD QSPI controller supports two advanced connection modes(Stacked and Dual Parallel) which allow the controller to treat two different flashes as one storage. Stacked: Flashes share the same SPI bus, but different CS line, controller driver asserts the CS of the flash to which it needs to communicate. Stacked mode is a software abstraction rather than a controller feature or capability. At any given time, the controller communicates with one of the two connected flash devices, as determined by the requested address and data length. If an operation starts on one flash and ends on the other, the core needs to split it into two separate operations and adjust the data length accordingly. Dual Parallel: Both the flashes have their separate SPI bus, CS of both the flashes will be asserted/de-asserted at the same time. In this mode data will be split across both the flashes by enabling the STRIPE setting in the controller. Parallel mode is a controller feature where if the STRIPE bit is set then the controller internally handles the data split during data write to the flashes and while reading data from the flash the controller internally merges data from both the flashes before writing to the controller FIFO. If STRIPE is not enabled, then same data will be sent to both the devices. In parallel mode both the flashes should be identical. For more information on the modes please feel free to go through the controller flash interface below https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Interf… Mirochip QSPI controller also supports "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode". https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDoc… Initially in [1] [2] [3] Miquel had tried to extend MTD-CONCAT driver to support Stacked mode, but the bindings were not accepted. [1] https://lore.kernel.org/all/20191113171505.26128-4-miquel.raynal@bootlin.co… [2] https://lore.kernel.org/all/20191127105522.31445-5-miquel.raynal@bootlin.co… [3]https://lore.kernel.org/all/20211112152411.818321-1-miquel.raynal@bootlin… So, the MTD-CONCAT approach was dropped and the DT bindings that got accepted [4] [5] [6] describe the two flash devices as being one. [4] https://github.com/torvalds/linux/commit/f89504300e94524d5d5846ff8b728592ac… [5] https://github.com/torvalds/linux/commit/eba5368503b4291db7819512600fa014ea… [6] https://github.com/torvalds/linux/commit/e2edd1b64f1c79e8abda365149ed62a2a9… SPI core changes to support the above bindings were added through the following commit: https://github.com/torvalds/linux/commit/4d8ff6b0991d5e86b17b235fc46ec62e91… While adding the support in SPI-NOR we received some inputs/suggestions from Tudor, based on that I am planning to add a new layer between the SPI-NOR and MTD layers to support stacked and parallel configurations. This new layer will be part of the spi-nor and located in mtd/spi-nor/. This layer would perform the following tasks: - During probing, store information from all the connected flashes, whether in stacked or parallel mode, and present it as a single device to the MTD layer. - Register callbacks and manage MTD device registration within the new layer instead of in spi-nor/core.c - There will very minimal change in spinor/core.c as the stacked & parallel handling will be managed by the new layer on top of SPI-NOR. - In stacked mode, the new layer will select the appropriate spi-nor flash based on the address provided by the MTD layer during flash operations. - Manage flash crossover operations in stacked mode. - Handle odd byte count requests from the MTD layer during flash operations in parallel mode. For implementing this the current DT binding[1] [2] [3] need to be updated as follows. stacked-memories DT changes: - Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding. - Each stacked flash will have its own flash node. This approach allows flashes of different makes and sizes to be stacked together, as each flash will be probed individually. - Each of the flash node will have its own "reg" property that will contain its physical CS. - The stacked-memories DT bindings will contain the phandles of the flash nodes connected in stacked mode. - The first flash node will contain the mtd partition that would have the cross over memory staring at a memory location in the first flash and ending at some memory location of the 2nd flash - The new layer will update the mtd->size and other mtd_info parameters after both the flashes are probed and will call mtd_device_register with the combined information. spi@0 { flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; stacked-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; }; } flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } } parallel-memories DT changes: - Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding. - Each flash connected in parallel mode should be identical and will have one flash node for both the flash devices. - The "reg" prop will contain the physical CS number for both the connected flashes. - The new layer will double the mtd-> size and register it with the mtd layer. spi@0 { flash@0 { compatible = "jedec,spi-nor" reg = <0x00 0x01>; parallel-memories; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; } }; } Regards, Amit

1 1

How to handle complex Codec2Codec
by Kuninori Morimoto 09 Sep '24

09 Sep '24

Hi ALSA ML ALSA SoC is supporting Codec2Codec connection, and Audio Graph Card2 is supporting it. I think its image is... +------+ +--- |Codec1| <-- | +------+ | +------+ +--> |Codec2| --> +------+ This is OK, but how to handle below ? +----------------------+ |CPU | +------+ | +--[rate convert]<--| <-- |Codec1| <-- | | | +------+ | | | +------+ | +------------------>| --> |Codec2| --> +----------------------+ +------+ I think there are 2 issues. (1) How to handle [CPU] part on Codec2Codec ? (2) How to handle [rate convert] on Codec2Codec ? I guess (1) can be handled if [CPU] was worked as platform, but do you have any other idea/solution for it ? I think (2) [rate convert] needs DPCM connection, but how to use it with Codec2Codec ? Or, can we handle Codec2Codec via DPCM somehow ?? FE BE +------+ +------+ --> |Codec1| -> |Codec2| -> +------+ +------+ If we can do this, both (1) and (2) can be solved, like below ? In such case, [Codec1] need to work as [capture] when playback. But I'm not sure how to implement it... FE BE +------+ +-----------------+ +-----+ +------+ --> |Codec1|-|CPU[rate convert]| -> |dummy|-|Codec2| -> +------+ +-----------------+ +-----+ +------+ Thank you for your help !! Best regards --- Kuninori Morimoto

2 8

Re: [PATCH] ALSA: Add logitech Audio profile quirk
by Joshua Pius 06 Sep '24

06 Sep '24

1 3

[PATCH] ASoC: codecs: Use devm_clk_get_enabled() helpers
by ying zuxin 06 Sep '24

06 Sep '24

From: ying zuxin <11154159(a)vivo.com> The devm_clk_get_enabled() helpers: - call devm_clk_get() - call clk_prepare_enable() and register what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the calls to clk_disable_unprepare(). Signed-off-by: ying zuxin <11154159(a)vivo.com> --- sound/soc/codecs/peb2466.c | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/sound/soc/codecs/peb2466.c b/sound/soc/codecs/peb2466.c index 76ee7e3f4d9b..b67cfad4fc32 100644 --- a/sound/soc/codecs/peb2466.c +++ b/sound/soc/codecs/peb2466.c @@ -1975,12 +1975,9 @@ static int peb2466_spi_probe(struct spi_device *spi) if (IS_ERR(peb2466->reset_gpio)) return PTR_ERR(peb2466->reset_gpio); - peb2466->mclk = devm_clk_get(&peb2466->spi->dev, "mclk"); + peb2466->mclk = devm_clk_get_enabled(&peb2466->spi->dev, "mclk"); if (IS_ERR(peb2466->mclk)) return PTR_ERR(peb2466->mclk); - ret = clk_prepare_enable(peb2466->mclk); - if (ret) - return ret; if (peb2466->reset_gpio) { gpiod_set_value_cansleep(peb2466->reset_gpio, 1); @@ -2031,17 +2028,9 @@ static int peb2466_spi_probe(struct spi_device *spi) return 0; failed: - clk_disable_unprepare(peb2466->mclk); return ret; } -static void peb2466_spi_remove(struct spi_device *spi) -{ - struct peb2466 *peb2466 = spi_get_drvdata(spi); - - clk_disable_unprepare(peb2466->mclk); -} - static const struct of_device_id peb2466_of_match[] = { { .compatible = "infineon,peb2466", }, { } @@ -2061,7 +2050,6 @@ static struct spi_driver peb2466_spi_driver = { }, .id_table = peb2466_id_table, .probe = peb2466_spi_probe, - .remove = peb2466_spi_remove, }; module_spi_driver(peb2466_spi_driver); -- 2.39.0

3 2

[PATCH] ASoC: makes rtd->initialized bit field
by Kuninori Morimoto 06 Sep '24

06 Sep '24

rtd->initialized is used to know whether soc_init_pcm_runtime() was correctly fined, and used to call snd_soc_link_exit(). We don't need to have it as bool, let's make it bit-field same as other flags. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Cc: Amadeusz Sławiński <amadeuszx.slawinski(a)linux.intel.com> Cc: Cezary Rojewski <cezary.rojewski(a)intel.com> --- include/sound/soc.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 81ef380b2e06..e6e359c1a2ac 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1207,8 +1207,7 @@ struct snd_soc_pcm_runtime { /* bit field */ unsigned int pop_wait:1; unsigned int fe_compr:1; /* for Dynamic PCM */ - - bool initialized; + unsigned int initialized:1; /* CPU/Codec/Platform */ int num_components; -- 2.43.0

2 1