Framebuffer Copy SPI issues since kernel update on Jan 4

[makermelissa]

Describe the bug
Since the firmware update on Jan 4 and including the subsequent update on Jan 8, using Framebuffer copy does not work anymore. I get the following messages looping over and over in dmesg:

[    6.051273] fb_st7789v spi0.0: SPI transfer timed out
[    6.051352] spi_master spi0: failed to transfer one message from queue
[    6.051374] fb_st7789v spi0.0: fbtft_update_display: write_vmem failed to update display buffer

The bug appears to only affect the Raspberry Pi Model 4 and not the 3B. We have a bug report filed on Adafruit at adafruit/Raspberry-Pi-Installer-Scripts#138 with some more info/photos.

To reproduce
Follow this guide and setup the display: https://learn.adafruit.com/adafruit-braincraft-hat-easy-machine-learning-for-raspberry-pi focusing particularly on the Display Module Install section, except use the Raspberry Pi OS full version.

Expected behaviour
The display shows a clear image on the display of what would normally be output to the HDMI port and updating is smooth.

Actual behaviour
The display shows a garbled image on the display, and display updates are extremely infrequent.

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
https://pastebin.com/Eu5TZvk2

Logs
If applicable, add the relevant output from dmesg or similar.
https://pastebin.com/sw4Cb4ka

Additional context
Add any other relevant context for the problem.

[makermelissa]

Any word on this?

Also, tagging @ladyada.

[pelwell]

If I'm following your installation instructions correctly you appear to be running a custom st7789v driver. I understand that upstream stripped out some of @notro's Device-Tree-defined driver support, but in September last year I restored support for some boards but in a more conventional fashion. Can we not expand that to cover your other devices?

Can't you lay your hands on a logic analyser to look at the SPI bus traffic? It would make diagnosis a lot easier.

[ladyada]

@pelwell hihi we'd love to have native support for this display. particularly as we're starting to see a lot more vendors use the st7789v - we used to be able to the generic framebuffer but yeah that was ripped out.

that said, we think there was something else going on here that was causing issue, which we're currently working around by pinning to kernel/firmware 5.4
@makermelissa did we see the corrupted data with non-ST7789v displays?

[makermelissa]

I think only the ST7789v displays were affected.

[makermelissa]

I experimented with using the st7789vw driver from (https://github.com/notro/tinydrm) and experienced the same issue with the text. In both cases it appears to work immediately after installing, but after another rebbot or two, it just seems to sporadically draw in various places. I can hook up a logic analyzer to view SPI data, but I'm not exactly sure what I should be expecting to see.

[pelwell]

OK, which is the best display to buy to debug the problem?

[ladyada]

https://www.adafruit.com/product/4484 or https://www.adafruit.com/product/4393
they both use ST7789V
as a bonus, almost all pimoroni devices with screens use the same chipset so they'd probably also be chuffed (that's the right word? :)

[pelwell]

Chuffed is absolutely the right word.

Time to blow half the R&D budget...

[JamesH65]

Been trying to get one of these working on a Pico, got to the point I think the display might be broken....so careful where you get it from, mine was an Ebay special at £5.99. Some of the soldering does look a bit shonky.

[pelwell]

I've ordered a genuine AdaFruit 4484 from Pimoroni, so I'm expecting minimal shonkiness (otherwise I'll be dischuffed).

[ladyada]

takes notes on emergent language of the native Pi People

[leeyunjai82]

The oled using the ssd1306 chip has the same symptoms.
Whenever I boot, there are times when the symptoms appear, and sometimes the symptoms do not appear.

[pelwell]

The 1.3" 4484 display arrived today, and It works for me. Full disclosure: I didn't run the Adafruit installer.

This is what I did:

$ wget https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/overlays/minipitft13-overlay.dts
$ dtc -@ -I dts -O dtb -o minipitft13.dtbo minipitft13-overlay.dts 
$ sudo cp minipitft13.dtbo /boot/overlays/
$ echo dtoverlay=minipitft13 | sudo tee -a /boot/config.txt
$ sudo reboot
$ git clone https://github.com/adafruit/rpi-fbcp
$ cd rpi-fbcp
$ mkdir build
$ cd build
$ sudo apt install -y cmake
$ cmake ..
$ make
$ sudo cp fbcp /usr/bin
$ fbcp

At this point the main display is mirrored onto the 1.3" mini-display.

[pelwell]

In case it wasn't obvious, this is using the off-the-shelf fb_st7789 driver in rpi-5.10.y. If it's lacking some crucial setup, it isn't obvious from the display - contrast looks OK, and colours are correct.

[makermelissa]

Did it still work even with rebooting a couple of times?

[pelwell]

It's at 5 for 5 and counting.

[makermelissa]

Excellent, I will give this a try in the next couple of days and see if I can adapt it. Thank you.

[ladyada]

i thiiiiink one of the things we'd still need to do is add rotation and offset support to that fb_st7789. i dont remember why i didnt use it back then. its been so looong :D

[pelwell]

rotate=270 appears to work perfectly, but 90 and 180 have an offset.

[notro]

One of the lessons I learned after making fbtft is that rotation is display/panel specific and not controller specific. So one set of rotation values may or may not work with a panel of the same resolution using the same controller.

[pelwell]

I'm sure there's just a small amount of configuration required. We can add a specific compatible string for the display if needed.

[pelwell]

raspberrypi/linux#4156 includes the minipitft13 overlay and fbtft driver support with corrected offsets for rotation. It's tested on 4484, but might also work on 4393 (which I don't have).

[ladyada]

@makermelissa wanna try it?

[makermelissa]

Yep

[pelwell]

You can either add and fetch my personal github repo - call it pelwell, then checkout my branch as pelwell/minipiftf13 - or (and this might be simpler) - download my commits as raw patches and apply them with git am <patch-file>:

$ curl https://github.com/raspberrypi/linux/commit/a95a5ba4aeb76514f453434d9d276fa4d85745fa.patch > patch1
$ curl https://github.com/raspberrypi/linux/commit/42097884b80cd75c1aedebef69aed4324b1b227b.patch > patch2
$ git am patch1
$ git am patch2

[pelwell]

[ That second URL got a bit mangled, but it should be OK now ]

[makermelissa]

Ok, so I got to testing and here are some of my findings. I ended up downloading the fbtft folder with the files as well as your .dts file. So it looks like the primary issue in this repo was fixed with the new device tree overlay, but onto my testing of the driver. I wasn't sure of the exact commands to compile, so I made my own Makefile and was able to get it compiled. I replaced the file at /usr/lib/modules/5.10.11-v7l+/kernel/drivers/staging/fbtft/fb_st7789v.ko and it boots fine.

Rotation wasn't working with offsets and I figured out that is because it's not detecting the variant for whatever reason (maybe the way I compiled it). So for testing purposes I forced the variant by adding it to .fbtftops where the display struct is created. Rotation worked fine at that point.

I tested out the 1.14" which has its own set of offsets, so I'm going to work on the init logic tomorrow for a bit so that it'll work with 1.14" (135x240), 1.3" (240x240), and 2.0" (320x240) displays. I was wondering if it would be better to create additional variants since the offsets are pretty weird for the 1.14" display and then we could create another DTS file for the 1.14" display to make swapping in and out easier. You can see how we do it in Arduino here: https://github.com/adafruit/Adafruit-ST7735-Library/blob/master/Adafruit_ST7789.cpp. Another option might be allowing the x and y offsets to be specified in the DTO rather than hard coding so they're easier to override.

[pelwell]

That's great news. I'm happy with the creation of additional variants - there isn't a big overhead in module size, and I think they are more likely to be upstreamable (the rejection of @notro's DT-based approach for "religious" reasons is a shame), not that that's an absolute requirement.