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

[PATCH] ASoC: codes: Add support for ES8316 producer mode
by Zhu Ning 01 Jul '22

01 Jul '22

The AMD acp-es8336 machine driver requires ES8316 run in producer mode, which is not supported previously. Signed-off-by: David Yang <yangxiaohua(a)everest-semi.com> Signed-off-by: Zhu Ning <zhuning0077(a)gmail.com> --- sound/soc/codecs/es8316.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c index 4407166bb338..34176dc8af8b 100644 --- a/sound/soc/codecs/es8316.c +++ b/sound/soc/codecs/es8316.c @@ -401,9 +401,8 @@ static int es8316_set_dai_fmt(struct snd_soc_dai *codec_dai, u8 clksw; u8 mask; - if ((fmt & SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK) != SND_SOC_DAIFMT_CBC_CFC) { - dev_err(component->dev, "Codec driver only supports consumer mode\n"); - return -EINVAL; + if ((fmt & SND_SOC_DAIFMT_MASTER_MASK) == SND_SOC_DAIFMT_CBP_CFP) { + serdata1|=ES8316_SERDATA1_MASTER; } if ((fmt & SND_SOC_DAIFMT_FORMAT_MASK) != SND_SOC_DAIFMT_I2S) { @@ -464,6 +463,8 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream, struct snd_soc_component *component = dai->component; struct es8316_priv *es8316 = snd_soc_component_get_drvdata(component); u8 wordlen = 0; + u8 bclk_divider; + u16 lrck_divider; int i; /* Validate supported sample rates that are autodetected from MCLK */ @@ -477,19 +478,24 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream, } if (i == NR_SUPPORTED_MCLK_LRCK_RATIOS) return -EINVAL; - + lrck_divider = es8316->sysclk/params_rate(params); + bclk_divider = lrck_divider/4; switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: wordlen = ES8316_SERDATA2_LEN_16; + bclk_divider/=16; break; case SNDRV_PCM_FORMAT_S20_3LE: wordlen = ES8316_SERDATA2_LEN_20; + bclk_divider/=32; break; case SNDRV_PCM_FORMAT_S24_LE: wordlen = ES8316_SERDATA2_LEN_24; + bclk_divider/=24; break; case SNDRV_PCM_FORMAT_S32_LE: wordlen = ES8316_SERDATA2_LEN_32; + bclk_divider/=32; break; default: return -EINVAL; @@ -499,6 +505,11 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream, ES8316_SERDATA2_LEN_MASK, wordlen); snd_soc_component_update_bits(component, ES8316_SERDATA_ADC, ES8316_SERDATA2_LEN_MASK, wordlen); + snd_soc_component_update_bits(component, ES8316_SERDATA1, 0x1f, bclk_divider); + snd_soc_component_update_bits(component, ES8316_CLKMGR_ADCDIV1, 0x0f, lrck_divider >> 8); + snd_soc_component_update_bits(component, ES8316_CLKMGR_ADCDIV2, 0xff, lrck_divider & 0xff); + snd_soc_component_update_bits(component, ES8316_CLKMGR_DACDIV1, 0x0f, lrck_divider >> 8); + snd_soc_component_update_bits(component, ES8316_CLKMGR_DACDIV2, 0xff, lrck_divider & 0xff); return 0; } @@ -510,7 +521,7 @@ static int es8316_mute(struct snd_soc_dai *dai, int mute, int direction) } #define ES8316_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE | \ - SNDRV_PCM_FMTBIT_S24_LE) + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE) static const struct snd_soc_dai_ops es8316_ops = { .startup = es8316_pcm_startup, -- 2.36.1

3 2

Re: [PATCH v3 00/15] Canaan devicetree fixes
by Niklas Cassel 01 Jul '22

01 Jul '22

On Wed, Jun 29, 2022 at 07:43:29PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley(a)microchip.com> > > Hey all, > This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > based boards. To make keeping it that way a little easier, I changed the > Canaan devicetree Makefile so that it would build all of the devicetrees > in the directory if SOC_CANAAN. > > I *DO NOT* have any Canaan hardware so I have not tested any of this in > action. Since I sent v1, I tried to buy some since it's cheap - but could > out of the limited stockists none seemed to want to deliver to Ireland :( > I based the series on next-20220617. > I first tried to apply your series on top of next-20220630, but was greeted by a bunch of different warnings on boot, including endless RCU stall warnings. However, even when booting next-20220630 without your patches, I got the same warnings and RCU stall. So I tested your series on top of v5.19-rc4 + commit 0397d50f4cad ("spi: dt-bindings: Move 'rx-sample-delay-ns' to spi-peripheral-props.yaml") cherry-picked, (in order to avoid conflicts when applying your series,) and the board was working as intended, no warnings or RCU stalls. I tried both booting both via u-boot (with u-boots DTB) and booting the kernel (with an initrd) directly. I could successfully read data from the MMC in both cases. Therefore: Tested-by: Niklas Cassel <niklas.cassel(a)wdc.com>

4 7

Re: (subset) [PATCH v3 00/15] Canaan devicetree fixes
by Mark Brown 01 Jul '22

01 Jul '22

On Wed, 29 Jun 2022 19:43:29 +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley(a)microchip.com> > > Hey all, > This series should rid us of dtbs_check errors for the RISC-V Canaan k210 > based boards. To make keeping it that way a little easier, I changed the > Canaan devicetree Makefile so that it would build all of the devicetrees > in the directory if SOC_CANAAN. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [04/15] spi: dt-bindings: dw-apb-ssi: update spi-{r,t}x-bus-width commit: 8b037cabc4966b010c44a76e05a43d276318bc49 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH v3 08/15] riscv: dts: canaan: fix the k210's timer nodes
by Serge Semin 01 Jul '22

01 Jul '22

On Wed, Jun 29, 2022 at 07:43:37PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley(a)microchip.com> > > The timers on the k210 have non standard interrupt configurations, > which leads to dtbs_check warnings: > > k210_generic.dtb: timer@502d0000: interrupts: [[14], [15]] is too long > From schema: Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml > > Split the timer nodes in two, so that the second timer in the IP block > can actually be accessed & in the process solve the dtbs_check warning. Reviewed-by: Serge Semin <fancer.lancer(a)gmail.com> Just to note. IMO the DW APB Timer driver has been incorrectly designed in the first place. The dts-node is supposed to describe the whole IP-core timers set as the original Canaan k210 DT-file expected, since there are common CSRs in the registers range, which currently get to be unreachable. But since the DT-bindings has already been defined that way in the framework of DW APB Timer driver alas there is nothing we can do to fix it. -Sergey > > Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> > --- > arch/riscv/boot/dts/canaan/k210.dtsi | 46 +++++++++++++++++++++++----- > 1 file changed, 38 insertions(+), 8 deletions(-) > > diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi > index cd4eae82d8b2..72f70128d751 100644 > --- a/arch/riscv/boot/dts/canaan/k210.dtsi > +++ b/arch/riscv/boot/dts/canaan/k210.dtsi > @@ -319,28 +319,58 @@ fpioa: pinmux@502b0000 { > > timer0: timer@502d0000 { > compatible = "snps,dw-apb-timer"; > - reg = <0x502D0000 0x100>; > - interrupts = <14>, <15>; > + reg = <0x502D0000 0x14>; > + interrupts = <14>; > clocks = <&sysclk K210_CLK_TIMER0>, > <&sysclk K210_CLK_APB0>; > clock-names = "timer", "pclk"; > resets = <&sysrst K210_RST_TIMER0>; > }; > > - timer1: timer@502e0000 { > + timer1: timer@502d0014 { > compatible = "snps,dw-apb-timer"; > - reg = <0x502E0000 0x100>; > - interrupts = <16>, <17>; > + reg = <0x502D0014 0x14>; > + interrupts = <15>; > + clocks = <&sysclk K210_CLK_TIMER0>, > + <&sysclk K210_CLK_APB0>; > + clock-names = "timer", "pclk"; > + resets = <&sysrst K210_RST_TIMER0>; > + }; > + > + timer2: timer@502e0000 { > + compatible = "snps,dw-apb-timer"; > + reg = <0x502E0000 0x14>; > + interrupts = <16>; > clocks = <&sysclk K210_CLK_TIMER1>, > <&sysclk K210_CLK_APB0>; > clock-names = "timer", "pclk"; > resets = <&sysrst K210_RST_TIMER1>; > }; > > - timer2: timer@502f0000 { > + timer3: timer@502e0014 { > + compatible = "snps,dw-apb-timer"; > + reg = <0x502E0014 0x114>; > + interrupts = <17>; > + clocks = <&sysclk K210_CLK_TIMER1>, > + <&sysclk K210_CLK_APB0>; > + clock-names = "timer", "pclk"; > + resets = <&sysrst K210_RST_TIMER1>; > + }; > + > + timer4: timer@502f0000 { > + compatible = "snps,dw-apb-timer"; > + reg = <0x502F0000 0x14>; > + interrupts = <18>; > + clocks = <&sysclk K210_CLK_TIMER2>, > + <&sysclk K210_CLK_APB0>; > + clock-names = "timer", "pclk"; > + resets = <&sysrst K210_RST_TIMER2>; > + }; > + > + timer5: timer@502f0014 { > compatible = "snps,dw-apb-timer"; > - reg = <0x502F0000 0x100>; > - interrupts = <18>, <19>; > + reg = <0x502F0014 0x14>; > + interrupts = <19>; > clocks = <&sysclk K210_CLK_TIMER2>, > <&sysclk K210_CLK_APB0>; > clock-names = "timer", "pclk"; > -- > 2.36.1 >

1 0

Re: [PATCH v3 04/15] spi: dt-bindings: dw-apb-ssi: update spi-{r,t}x-bus-width
by Serge Semin 01 Jul '22

01 Jul '22

On Wed, Jun 29, 2022 at 07:43:33PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley(a)microchip.com> > > Most users of dw-apb-ssi use spi-{r,t}x-bus-width of 1, however the > Canaan k210 is wired up for a width of 4. > Quoting Serge: > The modern DW APB SSI controllers of v.4.* and newer also support the > enhanced SPI Modes too (Dual, Quad and Octal). Since the IP-core > version is auto-detected at run-time there is no way to create a > DT-schema correctly constraining the Rx/Tx SPI bus widths. > /endquote > > As such, drop the restriction on only supporting a bus width of 1. Reviewed-by: Serge Semin <fancer.lancer(a)gmail.com> -Sergey > > Link: https://lore.kernel.org/all/20220620205654.g7fyipwytbww5757@mobilestation/ > Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> > --- > Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml > index e25d44c218f2..0a43d6e0ef91 100644 > --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml > +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml > @@ -143,12 +143,6 @@ patternProperties: > minimum: 0 > maximum: 3 > > - spi-rx-bus-width: > - const: 1 > - > - spi-tx-bus-width: > - const: 1 > - > unevaluatedProperties: false > > required: > -- > 2.36.1 >

1 0

Re: [PATCH v3 13/15] riscv: dts: canaan: fix bus {ranges,reg} warnings
by Niklas Cassel 30 Jun '22

30 Jun '22

On Wed, Jun 29, 2022 at 07:43:42PM +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley(a)microchip.com> > > The k210 devicetrees warn about missing/empty reg and/or ranges > properties: > arch/riscv/boot/dts/canaan/k210.dtsi:408.22-460.5: Warning (unit_address_vs_reg): /soc/bus@52000000: node has a unit name, but no reg or ranges property > arch/riscv/boot/dts/canaan/k210.dtsi:352.22-406.5: Warning (simple_bus_reg): /soc/bus@50400000: missing or empty reg/ranges property > > Add reg and ranges properties that naively cap the buses after the > allocation of their last devices. > > Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> > --- > arch/riscv/boot/dts/canaan/k210.dtsi | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi > index 948dc235e39d..6a34dc4f3e51 100644 > --- a/arch/riscv/boot/dts/canaan/k210.dtsi > +++ b/arch/riscv/boot/dts/canaan/k210.dtsi > @@ -163,7 +163,8 @@ apb0: bus@50200000 { > #address-cells = <1>; > #size-cells = <1>; > compatible = "simple-pm-bus"; > - ranges; > + regs = <0x50200000 0x200000>; > + ranges = <0x50200000 0x50200000 0x200000>; This looks wrong. The property is called "reg" not "regs". And I don't think that you should provide "reg" at all, simply supplying "ranges" should be sufficient, no? Kind regards, Niklas > clocks = <&sysclk K210_CLK_APB0>; > > gpio1: gpio@50200000 { > @@ -382,7 +383,8 @@ apb1: bus@50400000 { > #address-cells = <1>; > #size-cells = <1>; > compatible = "simple-pm-bus"; > - ranges; > + regs = <0x50400000 0x40100>; > + ranges = <0x50400000 0x50400000 0x40100>; > clocks = <&sysclk K210_CLK_APB1>; > > wdt0: watchdog@50400000 { > @@ -437,7 +439,8 @@ apb2: bus@52000000 { > #address-cells = <1>; > #size-cells = <1>; > compatible = "simple-pm-bus"; > - ranges; > + regs = <0x52000000 0x2000200>; > + ranges = <0x52000000 0x52000000 0x2000200>; > clocks = <&sysclk K210_CLK_APB2>; > > spi0: spi@52000000 { > -- > 2.36.1 >

2 2

[PATCH 0/5] I2S driver changes for Jadeite platform
by Vijendar Mukunda 30 Jun '22

30 Jun '22

Jadeite(JD) platform is Stoney APU varaint which uses I2S MICSP instance and ES8336 Codec. This patch series creates I2S platform devices for JD platform, adds I2S MICSP instance support and Machine driver support This patch set depends on: --checkpatch warnings patch --https://patchwork.kernel.org/project/alsa-devel/patch/20220627125834.481731-1-Vijendar.Mukunda@amd.com/ Vijendar Mukunda (5): drm/amdgpu: add dmi check for jadeite platform drm/amdgpu: create I2S platform devices for Jadeite platform ASoC: amd: add I2S MICSP instance support ASoC: amd: add Machine driver for Jadeite platform ASoC: amd: enable machine driver build for Jadeite platform drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 329 +++++++++++++++-------- sound/soc/amd/Kconfig | 11 + sound/soc/amd/Makefile | 2 + sound/soc/amd/acp-es8336.c | 333 ++++++++++++++++++++++++ sound/soc/amd/acp-pcm-dma.c | 50 +++- sound/soc/amd/acp.h | 13 + 6 files changed, 627 insertions(+), 111 deletions(-) create mode 100644 sound/soc/amd/acp-es8336.c -- 2.25.1

3 9

Re: [PATCH v3 04/15] spi: dt-bindings: dw-apb-ssi: update spi-{r,t}x-bus-width
by Rob Herring 30 Jun '22

30 Jun '22

On Wed, 29 Jun 2022 19:43:33 +0100, Conor Dooley wrote: > From: Conor Dooley <conor.dooley(a)microchip.com> > > Most users of dw-apb-ssi use spi-{r,t}x-bus-width of 1, however the > Canaan k210 is wired up for a width of 4. > Quoting Serge: > The modern DW APB SSI controllers of v.4.* and newer also support the > enhanced SPI Modes too (Dual, Quad and Octal). Since the IP-core > version is auto-detected at run-time there is no way to create a > DT-schema correctly constraining the Rx/Tx SPI bus widths. > /endquote > > As such, drop the restriction on only supporting a bus width of 1. > > Link: https://lore.kernel.org/all/20220620205654.g7fyipwytbww5757@mobilestation/ > Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> > --- > Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 6 ------ > 1 file changed, 6 deletions(-) > Reviewed-by: Rob Herring <robh(a)kernel.org>

1 0

[PATCH] ASoC: ak4613: cares Simple-Audio-Card case for TDM
by Kuninori Morimoto 30 Jun '22

30 Jun '22

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Renesas is the only user of ak4613 on upstream for now, and commit f28dbaa958fbd8 ("ASoC: ak4613: add TDM256 support") added TDM256 support. Renesas tested part of it, because of board connection. It was assuming ak4613 is probed via Audio-Graph-Card, but it might be probed via Simple-Audio-Card either. It will indicates WARNING in such case. This patch fixup it. Reported-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/codecs/ak4613.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/ak4613.c b/sound/soc/codecs/ak4613.c index 03b829930769..dbdd421f832e 100644 --- a/sound/soc/codecs/ak4613.c +++ b/sound/soc/codecs/ak4613.c @@ -868,10 +868,12 @@ static void ak4613_parse_of(struct ak4613_priv *priv, /* * connected STDI + * TDM support is assuming it is probed via Audio-Graph-Card style here. + * Default is SDTIx1 if it was probed via Simple-Audio-Card for now. */ sdti_num = of_graph_get_endpoint_count(np); - if (WARN_ON((sdti_num > 3) || (sdti_num < 1))) - return; + if ((sdti_num >= SDTx_MAX) || (sdti_num < 1)) + sdti_num = 1; AK4613_CONFIG_SDTI_set(priv, sdti_num); } -- 2.25.1

4 7

[PATCH 1/2] ASoC: codecs: wsa881x: handle timeouts in resume path
by Srinivas Kandagatla 30 Jun '22

30 Jun '22

Currently we do not check if SoundWire slave initialization timeout expired before continuing to access its registers. Its possible that the registers are not accessible if timeout is expired. Handle this by returning timeout in resume path. Reported-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Fixes: 8dd552458361 ("ASoC: codecs: wsa881x: add runtime pm support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- sound/soc/codecs/wsa881x.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wsa881x.c b/sound/soc/codecs/wsa881x.c index dc954b85a988..6c8b1db649b8 100644 --- a/sound/soc/codecs/wsa881x.c +++ b/sound/soc/codecs/wsa881x.c @@ -1173,11 +1173,17 @@ static int __maybe_unused wsa881x_runtime_resume(struct device *dev) struct sdw_slave *slave = dev_to_sdw_dev(dev); struct regmap *regmap = dev_get_regmap(dev, NULL); struct wsa881x_priv *wsa881x = dev_get_drvdata(dev); + unsigned long time; gpiod_direction_output(wsa881x->sd_n, 1); - wait_for_completion_timeout(&slave->initialization_complete, - msecs_to_jiffies(WSA881X_PROBE_TIMEOUT)); + time = wait_for_completion_timeout(&slave->initialization_complete, + msecs_to_jiffies(WSA881X_PROBE_TIMEOUT)); + if (!time) { + dev_err(dev, "Initialization not complete, timed out\n"); + gpiod_direction_output(wsa881x->sd_n, 0); + return -ETIMEDOUT; + } regcache_cache_only(regmap, false); regcache_sync(regmap); -- 2.25.1

3 3