RPI 5 I2S master overlay

[BohdanBuinich]

Describe the bug

I'm trying to apply this overlay on RPI 5

https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master/blob/master/i2smaster.dts

Here my overlay for RPI 5

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835";

	fragment@0 {
		target = <&i2s_clk_consumer>;
		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
		target = <&sound>;
		__overlay__ {
			compatible = "simple-audio-card";
			simple-audio-card,name = "sj201";
			status = "okay";

			capture_link: simple-audio-card,dai-link@0 {
				format = "i2s";

				r_cpu_dai: cpu {
					sound-dai = <&i2s_clk_consumer>;

					dai-tdm-slot-num = <2>;
					dai-tdm-slot-width = <32>;
				};

				r_codec_dai: codec {
					sound-dai = <&codec_in>;
				};
			};
		};
	};

	fragment@3 {
		target-path = "/";
		__overlay__ {
			codec_in: spdif-receiver {
				#address-cells = <0>;
				#size-cells = <0>;
				#sound-dai-cells = <0>;
				compatible = "linux,spdif-dir";
				status = "okay";
			};
		};
	};
};

after running this overlay I have an error:

[    5.815800] designware-i2s 1f000a4000.i2s: ASoC: error at snd_soc_dai_set_fmt on 1f000a4000.i2s: -22
[    5.815868] asoc-simple-card: probe of soc:sound failed with error -22

Steps to reproduce the behaviour

1. build overlay: dtc -@ -H epapr -O dtb -o xvf3510.dtbo -Wno-unit_address_vs_reg xvf3510.dts
2. Add overlay to /boot/firmware/config.txt
3. Reboot

Device (s)

Raspberry Pi 5

System

cat /etc/rpi-issue
Raspberry Pi reference 2023-12-05
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 70cd6f2a1e34d07f5cba7047aea5b92457372e05, stage

vcgencmd version
2024/02/16 15:28:41
Copyright (c) 2012 Broadcom
version 4c845bd3 (release) (embedded)

uname -a
Linux raspberrypi 6.6.21-v8-16k+ #1741 SMP PREEMPT Fri Mar 8 13:44:12 GMT 2024 aarch64 GNU/Linux

Logs

No response

Additional context

No response

[pelwell]

What is the I2S clock master in your system?

[BohdanBuinich]

What is the I2S clock master in your system?

RPI 5 (I2S BCLK from pin 12 (BCM 18)) - master
audio board - slave

[pelwell]

In which case, your overlay needs to refer to i2s_clk_producer, not i2s_clk_consumer.

[BohdanBuinich]

when I changed to i2s_clk_producer I had this error:

[   16.862882] designware-i2s 1f000a0000.i2s: channel not supported
[   16.862884] designware-i2s 1f000a0000.i2s: ASoC: error at snd_soc_dai_hw_params on 1f000a0000.i2s: -22
[   16.862922] designware-i2s 1f000a0000.i2s: channel not supported
[   16.862924] designware-i2s 1f000a0000.i2s: ASoC: error at snd_soc_dai_hw_params on 1f000a0000.i2s: -22
[   16.862962] designware-i2s 1f000a0000.i2s: channel not supported
[   16.862963] designware-i2s 1f000a0000.i2s: ASoC: error at snd_soc_dai_hw_params on 1f000a0000.i2s: -22
[   16.863001] designware-i2s 1f000a0000.i2s: channel not supported
[   16.863002] designware-i2s 1f000a0000.i2s: ASoC: error at snd_soc_dai_hw_params on 1f000a0000.i2s: -22

Is there anything else I need to change?

[pelwell]

i2s_clk_producer is correct, despite the error messages.

The I2S driver is complaining because it it being asked to accept 16 channels, and 8 channels is the most it can handle. A process called wireplumber (probably part of pipewire) is requesting that format, but it's not clear if it has good reason to. Removing the channel count check does not make it work - I think there may be some wider systems issue at work here.

[pelwell]

It turns out there was an error in the I2S driver - it was interpreting some register values as powers of two when they actually represent multiples of two. This works for 2 and 4, but goes wrong when 6 and 8 are misinterpreted as 8 and 16.

Pull request #6023 contains the fix. After roughly 45 minutes you'll be able to install a trial 6.6 kernel by running sudo rpi-update pulls/6023.

[BohdanBuinich]

@pelwell after your fix overlay was applied correctly, thank you!

but one more issue that I cannot resolve:
By default, after applying the overlay on pin 12 (BCM 18), should the frequency be 3072 kHz or do I need to do something extra? The pin is always in the low state
pinctrl 18
18: a2 pn | lo // GPIO18 = I2S0_SCLK
pinctrl poll 18
18: lo // GPIO18

cat /sys/kernel/debug/clk/clk_summary

                                 enable  prepare  protect                                duty  hardware
   clock                          count    count    count        rate   accuracy phase  cycle    enable
-------------------------------------------------------------------------------------------------------
 xosc                                 6        6        0    50000000          0     0  50000         Y
    pll_audio_core                    4        4        0   801791999          0     0  50000         Y
       pll_audio_tern                 1        1        0    42199579          0     0  50000         Y
       pll_audio_sec                  1        1        0   100224000          0     0  50000         Y
       pll_audio                      2        2        0   267264000          0     0  50000         Y
          clk_i2s                     1        1        0     3072000          0     0  50000         Y

[pelwell]

The I2S clock only runs when there is data to transmit (or receive). Try using arecord to capture something.

[BohdanBuinich]

You're right, thanks, the problem is solved

[MKSounds]

@pelwell

The I2S clock only runs when there is data to transmit (or receive). Try using arecord to capture something.

Is there a possibility to always enable the clocks when the raspberry is the clockmaster on the bus?
Do I remember right, that the clocks where always on back on kernel version 4?

[pelwell]

Are you talking about Pi 5 (which is what this issue was created for)? Pi 5 has never run on kernel version 4.

I don't know if other Pis left the I2 clock running continuously on older kernels, but a quick look at the 4.4 version of bcm2835-i2s.c suggests that it was enabled by the ALSA .trigger method, just as it is now.

[MKSounds]

The question was more general, independent of the actually used hardware.
Is there any possibility to force the i2s clocks to always be running?
I mean, to disable the clocks only because currently there is no audio transmitted, is really non-sense. Attached devices will need to rerun their init sequence just because there was a pause in the audio transmission...

[pelwell]

The Linux maintainers don't think it's nonsense, and neither do I.

For your use case, you might consider prevent pipewire (or pulseaudio on an older system) from pausing the stream. Here's one guide I found: https://davejansen.com/disable-wireplumber-pipewire-suspend-on-idle-pops-delays-noise/

[pelwell]

And one for PulseAudio: https://wiki.archlinux.org/title/PulseAudio/Troubleshooting#Pops_when_starting_and_stopping_playback