procount
Bad IRQ on specific Pi4 models
I am trying to resurrect my Pimoroni Hyperpixel4 drivers for PINN and compile for the 5.10 kernel. This driver is based on the Goodix touchscreen driver. I've just added a conversion of Pimoroni's original python code to detect and initialise the display, and modified the dts overlay so that the touchscreen orientation is correct. You can find the source code here -> https://github.com/procount/pinn/blob/master/cypress3/pimhyp4.c
This driver seems to work fine on:
- PiZero rev 1.2
- Pi 3B+ rev
- Pi4 8GB rev 1.4 B0
- Pi400 4GB rev 1.0 C?
However, when I try to use it on:
- Pi4 4GB B0 rev 1.2
- Pi4 4GB B0 rev 1.4 it has a problem.
It starts off working fine, but after dragging my finger around the bottom right of the screen in little circles for a few seconds, the cursor suddenly freezes, although use of a normal mouse will continue to work. Looking at dmesg output, it suddenly decides that an IRQ has somehow become bad with no handler and therefore it gets disabled, hence the cursor freeze.
This is only happening on specific (earlier) Pi4 models, so I wonder if there is anything specific to these models that is different and needs to be accounted for? It seems odd that it works on the 8GB version that has the same rev 1.4 and B0 stepping as the 4GB version that doesn't work.
Google is not very forthcoming as to the possible causes of this "nobody cared" (about an interrupt) problem or how to avoid it, apart from saying it could be buggy firmware or a shared interrupt between drivers, which is not very helpful.
@XECDesign , @pelwell - Any ideas?
I also posted a forum post about it with error logs here -> https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=315804&p=1889483#p1889483
Are you able to reproduce this problem on Raspberry Pi OS too, or is it exclusive to PINN?
It would help to know what grep 62: /proc/interrupts return on that system.
@lurch - It's a built in driver at the moment. I suppose I could try building it as a module and trying it out in Raspios.
@pelwell - On the systems that fail? OK. I'll test.
grep 62: /proc/interrupts 62: 1200001 0 0 0 pinctrl-bcm2835 27 Edge ft6236
2nd attempt: 62: 1000001 0 0 0 pinctrl-bcm2835 27 Edge ft6236 3rd attempt: 62: 500001 0 0 0 pinctrl-bcm2835 27 Edge ft6236
(I started touching the screen later from the start).
If it is of any relevance, this is how I cause it to fail: (same basic procedure as NOOBS follows, if you're not familiar with PINN):
- Boot PINN
- Wait for screen to come up
- start tracing little circles in bottom right of screen, cursor follows finger.
- Network is established, List of OSes is downloaded. 5.Invariably, once all the OSes have downloaded and been displayed, that is the point at which the cursor stops following.
Now I tried a different test:
- as above, but wait until all OSes have been displayed.
- Start to trace little circles.
- Cursor stops after a few seconds
62: 200001 0 0 0 pinctrl-bcm2835 27 Edge ft6236
So the number of interrupts always ends in a '1'. Is there some buffer overflow going on here?
@pelwell - Do those number of interrupts help in any way?
I'm trying to setup to build it as a module for Raspios.
Do those number of interrupts help in any way?
Not really - they are just artifacts of the way that spurious interrupts are checked for every 100000 interrupts to reduce the overhead.
The purpose of the grep was to ascertain which interrupt was being classed as spurious, and it looks like it's GPIO 27, configured for rising-edge interrupts.
Have you tried with the standard ft6236 driver, as used by the pitft28-capacitative overlay and another upstream DTS file (both of which configure for falling-edge interrupts)?
I can certainly give them a try. I'll need to separate out the display initialisation code into a separate driver first. I'll try those and the original Goodix driver to see if the different Pi4 models are affected in the same way. Maybe try the falling edge interrupt as well. It will be a while, but I'll report back when I have some results. Thanks.
I'm struggling to build my driver as a module for Raspios on PI4 4GB. What am I doing wrong? Here is what I did (mostly from rpf instructions):
1. sudo apt update
2. sudo apt full-upgrade
3. sudo apt install git bc bison flex libssl-dev make
4. git clone --depth=1 https://github.com/raspberrypi/linux
5. sudo apt install raspberrypi-linux-headers
6. # copy pimhyp4.c into drivers/input/touchscreen
7. # Update drivers/input/touchscreen/Kconfig & Makefile for pimhyp4
8. make menuconfig # to add pimhyp4
9. cd linux
10. KERNEL=kernel7l
11. make bcm2711_defconfig
12. make -j4 zImage modules dtbs
13. # copy pimhyp4.ko to /lib/modules/$(uname -r)/kernel/drivers/input/touchscreen
14. sudo depmod
15. sudo modprobe pimhyp4
16. # modprobe: ERROR: could not insert 'pimhyp4': Exec format error
17. sudo imsmod pimhyp4.ko
18. # insmod: ERROR: could not insert module pimhyp4.ko: Invalid module format
19. dmesg
20. # pimhyp4: disagrees about version of symbol module_layout
I don't want to create a whole new kernel - I just want to build the driver in a compatible manner and install it into my current kernel.
# modinfo pimhyp4.ko
filename: /lib/modules/5.10.17-v7l+/kernel/drivers/input/touchscreen/pimhyp4.ko
license: GPL v2
description: pimhyp4 touchscreen driver
author: Bastien Nocera <[email protected]>
author: Benjamin Tissoires <[email protected]>
author: procount <[email protected]>
srcversion: 0C7047006273809E0296705
alias: i2c:GDIX1001:00
alias: of:N*T*Cpimoroni,ft6236C*
alias: of:N*T*Cpimoroni,ft6236
depends:
intree: Y
name: pimhyp4
vermagic: 5.10.50-v7l+ SMP mod_unload modversions ARMv7 p2v8
I have even tried:
make -C /lib/modules/`uname -r`/build M=$PWD
sudo make -C /lib/modules/`uname -r`/build M=$PWD modules_install
Which builds it but skips depmod due to a missing system.map file and still results in the same errors.
Are you running the arm64 kernel? The native compiler is building for arm/32-bit.