Enabling I2S Breaks SPI0 on Kernel 5.10.Y

[engnfrc]

On an RPi 4 running Raspbian Buster and Kernel 5.10.44-v7l+ I'm finding that if I enable I2S that it's breaking SPI0, this is apparent through trying to setup can0 (MCP251XFD driver) using ip link commands which respond with RTNETLINK answers: Connection timed out and using dmesg I see:

mcp251xfd spi0.1 can0: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz r:17.00MHz e:16.66MHz) successfully initialized.
mcp251xfd spi0.0 can1: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz r:17.00MHz e:16.66MHz) successfully initialized.
mcp251xfd spi0.1 rename4: renamed from can0
mcp251xfd spi0.0 can0: renamed from can1
mcp251xfd spi0.1 can1: renamed from rename4
mcp251xfd spi0.0: SPI transfer timed out
spi_master spi0: failed to transfer one message from queue
mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000).
mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000).
A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check.
mcp251xfd spi0.1: SPI transfer timed out
spi_master spi0: failed to transfer one message from queue
mcp251xfd spi0.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000).
mcp251xfd spi0.1 can1: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.1 can1: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.1 can1: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
mcp251xfd spi0.1 can1: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000).
A link change request failed with some changes committed already. Interface can1 may have been left with an inconsistent configuration, please check.

To date the only thing I've been able to do that gives me working CAN all the time is to remove from /boot/config.txt the line dtparam=i2s=on. The original MCP25XXFD (predecessor to MCP251XFD) and I2S worked OK together on Kernel 4.19.73, it's only since moving to 5.10.Y that I see this conflict. My original forum post is located here: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=314191&p=1885817#p1879426 but I don't think the right people are seeing it. I've also been in communication with the developers on linux-can@vger.kernel.org who were helping me troubleshoot the possibility of the MCP251XFD driver having an issue, but I'm stuck with where to go next, especially if it's a problem with either the I2S or SPI subsystems.

My current /boot/config.txt with I2S and a custom WM8782 driver that requires I2S removed:

dtdebug=1

disable_splash=1
boot_delay=0

hdmi_force_mode=1

hdmi_group=1
hdmi_mode=3 # 480p 60Hz H

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
## dtparam=i2s=on
dtparam=spi=off
enable_uart=0

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# I2S WM8782 Driver
## dtoverlay=hel-wm8782,alsaname=mic

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
start_x=1
gpu_mem=512

# GPS
dtoverlay=uart3

# Reserved for HAT IDs
dtoverlay=i2c0
dtparam=pins_0_1=on
dtparam=combine=off

# Power Supervisor, IMU, RPi I2C Bus
dtoverlay=i2c1

# CAN 0/1
dtoverlay=spi0-cs
dtparam=cs0_pin=8
dtparam=cs1_pin=7

# Reserved
dtoverlay=spi5-2cs
dtparam=cs0_pin=12
dtparam=cs0_spidev=disabled
dtparam=cs1_pin=26
dtparam=cs1_spidev=disabled

# CAN 0
dtoverlay=mcp251xfd,spi0-0,interrupt=24,oscillator=40000000,speed=20000000

# CAN 1
dtoverlay=mcp251xfd,spi0-1,interrupt=25,oscillator=40000000,speed=20000000

Anyone have any ideas where to go from here? Was there a major change in I2S from 4.19.Y to 5.10.Y that could be a factor? Or could there be something misconfigured in the CAN driver that's causing it to be adversely affected by changes to I2S?

[engnfrc]

Is anyone able to investigate further into this issue?

[pelwell]

Your setup is too specialised to expect others to reproduce it, but there are a few things you could try to narrow down the problem:

1. Disable all features except I2S and SPI0.
2. Try enabling one or both of those interfaces at runtime, perhaps with only one CAN interface at a time:

   $ sudo dtoverlay hel-wm8782 alsaname=mic
   $ sudo dtoverlay mcp251xfd spi0-0 interrupt=24 oscillator=40000000 speed=20000000

   e.g. start with a working CAN bus, then load the wm8782 overlay.