Pisound on Pi 5

[gtrainavicius]

Describe the bug

Pisound is the I²S master, the default eeprom dt overlay we shipped it with is not working on Pi 5.

I've noticed issue #5724, and based on it I found that doing this procedure manages to load the driver and register the card successfully, the card then is usable:

1. Add dtoverlay=pisound,master in /boot/config.txt.
2. Power up Pi 5 without Pisound attached, to skip loading its hat eeprom.
3. Run sudo modprobe -r snd_soc_pisound to unload the Pisound's driver (as it obviously failed to load without Pisound attached).
4. Carefully attach Pisound on powered on Pi 5.
5. Run sudo modprobe snd_soc_pisound to load the Pisound's driver, it loads ok this time.
6. Check amidi -l, aplay -l, arecord -l - it's listed as expected.

Quick tests indicate that Pisound is fully operational once the driver manages to register the card.

Powering on the Pi 5 without Pisound attached, but with the dtoverlay line in config.txt, is necessary, otherwise the system does not boot at all when the hat eeprom is available, and the dtoverlay line for the same hat is there.

What should be done to make Pisound working on Pi 5 right out of the box?

Steps to reproduce the behaviour

Have Pisound attached as normal, the driver fails to register the card:

[    3.200062] pisound: Detected Pisound card:
[    3.200072] pisound:         Serial:           PS-3...
[    3.200075] pisound:         Firmware Version: 1.03
[    3.200078] pisound:         Hardware Version: 1.1
[    3.200081] pisound:         Id:               ...
[    3.200622] designware-i2s 1f000a0000.i2s: ASoC: error at snd_soc_dai_set_fmt on 1f000a0000.i2s: -22
[    3.203481] pisound: snd_soc_register_card() failed: -22

Device (s)

Other

System

Raspberry Pi reference 2023-10-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 962bf483c8f326405794827cce8c0313fd5880a8, stage4

2023/10/30 16:45:10
Copyright (c) 2012 Broadcom
version 30de0ba5 (release) (embedded)

Linux raspberrypi 6.1.0-rpi4-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.54-1+rpt2 (2023-10-05) aarch64 GNU/Linux

Logs

No response

Additional context

p.s. when reporting the issue I didn't find Pi 5 option in the devices list. :)

[pelwell]

1. To avoid the need to hot-plug your card, put dtoverlay= in config.txt before any other dt settings. This disables the loading of the overlay from the HAT EEPROM. You are then free to put your dtoverlay=pisound,master anywhere after that.
2. The current pisound.dtbo uses i2s_clk_consumer (i.e. the I2S block that expects an external clock source), so it should work out of the box. It has no master property (this is just a placebo)
3. If the EEPROM image in each card uses the same UUID then we can make use of the new hat_map file, which allows a named overlay to be automatically loaded for cards with a given UUID, overriding the overlay built into the EEPROM.

[gtrainavicius]

1. Works as a workaround for now, thank you.

2. The built-in blob is based on this: https://github.com/BlokasLabs/pisound/blob/master/pisound-module/pisound-overlay.dts - the i2s_clock_consumer must have happened in your kernel tree without us being aware of it. But yes, turns out it is enough to use the pisound.dtb provided with the kernel, without 'master' parameter, instead of the dt blob built-in in the eeprom.

   Is there something that can be done to make existing Pisound devices work, without rewriting their eeprom?

3. The product id for Pisound in hat eeprom is always a7ee5d28-da03-41f5-bbd7-20438a4bec5d.

[pelwell]

Is there something that can be done to make existing Pisound devices work, without rewriting their eeprom?

See your answer to 3, and https://github.com/raspberrypi/linux/pull/5742. Can you confirm that installing the compiled hat_map.dtb into the overlays directory solves the problem?

[gtrainavicius]

Where can I find the compiled hat_map.dtb?

[pelwell]

1. Wait an hour and run sudo rpi-update pulls/5742.
2. Download the source file and run dtc -I dts -O dtb -o hat_map.dtb hat_map.dts.

[pelwell]

I just opened https://github.com/raspberrypi/linux/issues/5743 to cover this and related Pi 5 soundcard problems.

[gtrainavicius]

@pelwell, the new hat_map.dtb fixes the issue for Pisound.

How should we release this fix to our users? Tell them to upgrade their kernel to some higher version than X using rpi-update? Or is there a planned raspberrypi-kernel release that might contain the fix?

[pelwell]

I'm afraid that this hat_map update has just missed the next stable rpi-update kernel, which will end up in an apt package soon. However, there are going to be some other soundcard patches soon, so I can push for another update once they are ready. It should be in the next (non-stable) rpi-update release in the next few days, or provide it for them in some other way.

[gtrainavicius]

Hey, we found that Pi 5 keeps a constant SPI speed, regardless of current CPU scaling, we must use a different speed for Pi 5 based models for our MIDI ports to work perfectly - what are the options to detect that a kernel module is running on the Pi 5 processor?

I could provide different Device Tree overlays, one for Pi 5, and another for the rest of the Pi models. This would be similar to having [Pi5] in the config.txt and loading the particular dt overlay, but we'd like to use the hat_map for this - I suspect model specific dt overlay selection is not possible yet.

(or is there any built-in dtparam that could be used for value lookup based on current Pi model, so there can be a single dtoverlay for Pisound?)

[pelwell]

what are the options to detect that a kernel module is running on the Pi 5 processor?

Can you expand on this a bit? What bit of code would you want to know that is on a Pi 5, and what is it doing with the information?

The obvious implementation is a Pi 5-specific version of the overlay (located using overlay_map so the user doesn't need to care), which would allow different parameters to be passed to existing, standard device drivers, based on the model. This could be made to work today. See https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/overlays/overlay_map.dts.

[gtrainavicius]

In particular, I need to set speed_hz of spi_transfer to 100kHz for Pi5, and 150kHz for the rest of the Pi's - I may accept this value from a dt overlay.

Another option I just found is parsing the value of /system/linux,revision within the module, but the dt way is probably better.

What is the syntax for overlay_map.dts to tell it to use the original overlay by default, but use a different one for Pi 5 only?

[pelwell]

Like this: https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/overlays/overlay_map.dts#L27-L31