[5.4.y] [arm64] spi cs seems to be broken

[asavah]

Describe the bug
SPI (possibly CS) is broken on 5.4.y

To reproduce
Attach an sh1106 or ssd1306 spi (4wire) display like in https://luma-oled.readthedocs.io/en/latest/hardware.html
Install luma.core and luma.oled python modules.
Try drawing something on the display the via a python script,
for example something from https://github.com/rm-hull/luma.examples/tree/master/examples
like this:

python3 clock.py --display sh1106 --interface spi --spi-device 0 --spi-port 0

Expected behaviour
There should be image or text on the screen.

Actual behaviour
Screen is black.
Wire CS pin of the display to ground instead of CE0 (BCM8) pin - works.

System
Own OS

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
  pi 4b
• Which OS and version (cat /etc/rpi-issue)?
  Own pet project
• Which firmware version (vcgencmd version)?

Nov 19 2019 16:42:26
Copyright (c) 2012 Broadcom
version aeebba4c03968ede49097db077673eadc2888a22 (clean) (release) (start_x)

• Which kernel version (uname -a)?
  Linux rpi4 5.4.0-k6 #1 SMP Thu Nov 28 00:43:25 EET 2019 aarch64 GNU/Linux
dtparam=spi=on in config.txt
  Logs
  No mentions of spi or any other scary errors in dmesg, can provide additional info if requested.

Additional context
The clue may be that if I wire display CS pin to ground it starts working like a champ.
This setup (scripts, wiring) have been working like a champ since pi2 days.
Tried using spi 0 device 1 with CS pin swapped - same behavior.
Disconnected everything from the pi except the display - same behavior.
Checked and redid display wiring - same behavior.
Checked with a smaller ssd1306 spi display - same behavior.
Checked python-smbus, luma.oled and luma.core versions - nothing changed for months.
Tried reverting a bunch of bcm-spi2835.c related commits to the state said file was in 5.3.y - same ...
Tried playing with spi0-cs and spi0-hw-cs overlays - more of the same.

Sadly I don't own a scope so I can't properly peek at what's happening with CS.
My crappy multimeter shows constantly and quickly floating voltage on active CS pin in range 0.005v - 0.07v (this measurement is not to be trusted) , it's never 0, inactive CS pin is stable 3,3v

Kernel 5.3.y with same firmware version worked fine earlier today.
However I can't test with 5.3 ATM because I rebuilt the whole thing and glibc was foolishly built with --enable-kernel=5.4.0.
If needed I can rebuild for testing, takes a bit of time tho.

Edit: if needed I can easily and quickly rebuild the kernel to test any patches on the fly.
Edit2: all other peripherals I have (i2c rtc, temperature sensor, buttons, leds, etc) work properly, this was tested with everything but the display physically disconnected.

[pelwell]

Yes, it's definitely broken. Out with the logic analyser...

[pelwell]

The CS line is inverted on 5.4. An spi_set_cs(1) results in the GPIO driver being asked to set GPIO 8 to 0 (correct - it's active low) on 4.19 and 1 (incorrect) on 5.4. I'm pretty sure it's triggered by 3bd158c, but I haven't yet worked out whether the error is in the code or the device tree CS declarations.

[pelwell]

It turns out to indeed be a side effect of 3bd158c, but the fault actually lies in the SPI-Py library. See my PR (lthiery/SPI-Py#25) for an explanation of the problem.

Download the patch (https://github.com/lthiery/SPI-Py/pull/25/commits/298c90d007ab740fbdbc6872d47b26011c25c554.patch), apply it to your tree (git am 298c90d*.patch), rebuild (sudo python setup.py install) and reboot - you should find it works again.

[asavah]

Thanks but the library I use https://github.com/rm-hull/luma.core uses https://github.com/doceme/py-spidev under the hood.

[pelwell]

Try setting the spi_cs_high option when you instantiate the luma.core instance. I'm not saying that ought to be required, but if that works then at least you have a workaround for now and we'll know that it is a different aspect of the same issue.

[asavah]

Thanks, will do and report back once I get home so I can see the actual output on display =)

[asavah]

Confirmed - with cs_high=True the display works OK.

A stripped down example of how I initialize luma device for anyone with the same problem led here by google:

from luma.core.interface.serial import spi
from luma.oled.device import sh1106

serial = spi(port=0, device=0, cs_high=True)
device = sh1106(serial, width=128, height=64, rotate=2)

[pelwell]

That's good news. One way forward would be to modify the library so that an absent cs_high value means "don't change it". I can also raise the question with the GPIO and SPI maintainers to see whether the current behaviour is expected.

[HiassofT]

Not 100% sure if that's related but I noticed that on 5.4.1 GPIOs 7/8 are claimed according to pinmux-pins (with dtparam=spi=on on RPi4)

pin 7 (gpio7): fe204000.spi pinctrl-bcm2835:7 function gpio_out group gpio7
pin 8 (gpio8): fe204000.spi pinctrl-bcm2835:8 function gpio_out group gpio8

On 5.3.12 only the HW CS pins were configured, GPIOs were unclaimed

pin 7 (gpio7): fe204000.spi (GPIO UNCLAIMED) function gpio_out group gpio7
pin 8 (gpio8): fe204000.spi (GPIO UNCLAIMED) function gpio_out group gpio8

Did SPI switch to GPIO CS instead of HW CS?

[HiassofT]

scratch my last comment, only difference in pinctrl between 5.4 and before is that the GPIOs are now properly claimed. function selection of the CS pins (gpio_out) is the same

[asavah]

I see that this commit has landed into stable tree https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.4.y&id=39552e0e71c0109fd83284e28aaa5e8691a36fc9
39552e0#diff-3db5dfeeff40a7afb4339663ae674301

From the looks of it this should fix the issue, will report back once I'm able to get to my pi and test it at runtime.

[pelwell]

It's odd that Mark Brown didn't mention that patch when I raised the issue upstream, but I'm happy the issue might have been fixed. I notice that somebody was complaining about a regression, and they were pointed to a followup patch (https://patchwork.kernel.org/patch/11209839/ - the link is down for me at the moment).

[asavah]

Nope, works only with cs_high, sorry for the noise.
Right now for me kernel.org (except git) is down too.
I'll take a look and try building with the followup patch once its up again.

[asavah]

The followup patch was merged too, so I already had it.

[l1k]

Fixed in v5.6-rc5 with torvalds/linux@138c9c3, now also queued for v5.4-stable.