Closed naleo closed 10 years ago
notro
commented
10 years ago I received the display yesterday, so I have started to work on it: https://github.com/notro/fbtft/commit/247d0832f867956073a6447e18db4fabe36d660b Yes it will be built into the kernel proper.
naleo
commented
10 years ago Thanks!! I look forward to that
notro
commented
10 years ago The prebuilt kernel is ready.
Install
sudo wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo REPO_URI=https://github.com/notro/rpi-firmware BRANCH=builtin rpi-updateAdd to /boot/cmdline.txt
fbtft_device.name=pitft fbtft_device.rotate=90 fbtft_device.debug=0 fbtft_device.verbose=0 fbcon=map:10 fbcon=font:ProFont6x11 logo.nologoAdd to /etc/modules
stmpe_device cs=1 chip=stmpe610 blocks=gpio,ts irq-pullup irq-gpio=24 irq-base=330 sample-time=4 mod-12b=1 ref-sel=0 adc-freq=2 ave-ctrl=3 touch-det-delay=4 settling=2 fraction-z=7 i-drive=0
gpio_backlight_device gpio=252The image can take a bit longer to do, since I will be automating the image build process.
AndO3131
commented
10 years ago I've compiled kernel for Raspberry Pi with fbtft support and patches described here https://github.com/notro/rpi-firmware. @Notro, setup from your previous post works, however after a few minutes touchscreen stops responding (other input devices work fine). Have you experienced similar behaviour? How can I find the cause of this problem (can I run some debug, display logs, etc)?
notro
commented
10 years ago however after a few minutes touchscreen stops responding (other input devices work fine).
I had that problem when I first tested the display with my kernel. Then I had to work on another display, and when I switched back to PiTFT, it worked as it should. I concluded that it had to be a bad connection or something. If you look at /proc/interrupts, you will probably see that the touch controller stops generating interrupts. Reloading the driver solved the problem for a short time.
Do you have this problem with both my kernel and yours?
There is one difference between the Adafruit patches and mine: tapping as mouseclick. The 3.10 kernel already had this, but in a slightly different way than the Adafruit patch.
notro
commented
10 years ago Can you try the new DMA capable kernel in the Adafruit tutorial and see if that works? Please report back the kernel version if you do so.
AndO3131
commented
10 years ago I flashed my SD card with http://tronnes.org/fbtft/download.html kernel, then installed your prebuilt kernel with instructions above, also updated '/boot/cmdline.txt' and '/etc/modules'. After reboot touchscreen works well - sometimes seems to stutter, but a second later it comes back to normal (tried it out for about 15 minutes of heavy tapping - I think it's good enough). Clearly, I've done something wrong or didn't do something while compiling.
Here is what I've done:
What did I miss?
notro
commented
10 years ago applied 7 patches from https://github.com/notro/rpi-firmware
I assume you meant: https://github.com/notro/rpi-build/tree/master/patches/builtin
Is it correct that you have no interrupts from the touch controller?
$ cat /proc/interrupts
CPU0
331: 0 stmpe stmpe-tsCan you control backlight? The 252 gpio is on the touch controller
# Turn off backlight
echo 1 | sudo tee /sys/class/backlight/*/bl_power
# Turn on backlight
echo 0 | sudo tee /sys/class/backlight/*/bl_powerAfter touchscreen freeze, i have for example
194: 448 GPIO stmpe
331: 448 stmpe stmpe-ts
337: 0 stmpe stmpe-gpioI can't reload 'stmpe_device' with standard command. This lockup seems to happen when I constantly touch the screen.
Turning backlight on and off works using above commands.
notro
commented
10 years ago I can't reload 'stmpe_device' with standard command.
No, you get a IRQ domain error. Does it help to reload stmpe-ts?
Turning backlight on and off works using above commands.
This means that some part of the controller is alive. The next step would be to use a scope to see if there is actually an interrupt on the pin. This would discern between Linux interrupt problem and stmpe problem.
Does it freeze with the Adafruit kernel as well?
Related forum post: http://forums.adafruit.com/viewtopic.php?f=50&t=51288&sid=62c08e0d3e9c1ef1a67fc0d81179481e
AndO3131
commented
10 years ago Does it help to reload stmpe-ts?
Reloading stmpe-ts indeed helps until next freeze.
Does it freeze with the Adafruit kernel as well?
I haven't tested it with Adafruit kernel, but I did check yours with
sudo wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo REPO_URI=https://github.com/notro/rpi-firmware BRANCH=builtin rpi-updateAnd haven't encountered this problem.
If it's really necessary to check Adafruit kernel, can you give me some advice (as I understand from http://forums.adafruit.com/viewtopic.php?f=50&t=51293, simple 'wget' and 'dpkg' won't do any good)?
P.S. In order to use 'cmdline.txt', I had to compile kernel with
CONFIG_FB_TFT=y
CONFIG_FB_TFT_FBTFT_DEVICE=yCan it have an impact on this behaviour?
notro
commented
10 years ago If it's really necessary to check Adafruit kernel
No, if my kernel works fine, it doesn't matter.
I really don't know what to suggest. I assume you don't have a scope since you didn't comment on that.
I build my kernel on Ubuntu 12.04 using: https://github.com/notro/rpi-build You could of course try that.
cd
git clone https://github.com/notro/rpi-build
./rpi-build/release.sh builtinBy default it builds in the home directory, There is a WORKDIR variable, but I have never tried it. The update_repo task will fail, but that doesn't matter. Kernel is: linux-rpi-3.10.y/arch/arm/boot/zImage Modules is in: modules/
Created by the script
$ ls -l ~
-rw-rw-r-- 1 pi pi 287244 Mar 8 18:53 build.log
-rw-rw-r-- 1 pi pi 24177 Mar 8 18:21 config.log
-rw-rw-r-- 1 pi pi 96534 Mar 8 18:54 extra.log
drwxr-xr-x 8 pi pi 4096 Feb 24 16:43 fbtft_tools
drwxrwxr-x 8 pi pi 4096 Mar 8 14:14 firmware
-rw-rw-r-- 1 pi pi 4620 Mar 8 18:20 init.log
drwxr-xr-x 25 pi pi 4096 Mar 8 18:53 linux-rpi-3.10.y
drwxrwxr-x 3 pi pi 4096 Mar 8 18:53 modules
-rw-rw-r-- 1 pi pi 53744 Mar 8 18:53 modules_install.log
drwxr-xr-x 7 pi pi 4096 Nov 19 19:26 PiBits
-rw-rw-r-- 1 pi pi 3840 Mar 8 18:54 README.md
drwxr-xr-x 4 pi pi 4096 Mar 18 18:40 rpi-build
drwxr-xr-x 4 pi pi 4096 Mar 8 18:54 spi-config
drwxr-xr-x 7 pi pi 4096 Nov 19 18:37 toolsI've double checked patches at https://github.com/notro/rpi-build/tree/master/patches/builtin and compared them to those I've initially found https://github.com/notro/rpi-firmware.
'builtin' folder has one more patch file https://github.com/notro/rpi-build/blob/master/patches/builtin/020-bcm2708.c.patch. I've compiled kernel with all this patches, recompiled 'fbtft_tools' and looks like touchscreen works much more reliable, but lockups may still happen. I'll use Raspberry and Pitft for a few days and check it's performance.
notro
commented
10 years ago See this: PiTFT: Does Linux 3.10 break touch?
tz1
commented
10 years ago I take it the fbtft_tools plus the additions in the "Prebuilt kernel is ready" are what is needed to add the other device support (touchscreen, buttons, backlight) to the PiTFT?
If so, I'd like to add them to my pikernomatic scripts here. I'm close to having most things working with the current binary update (3.10.33+, with the raspicam enhancements), yet still working with modules built for the stock kernel.
But a README with those "add to /etc/..." entries, and documenting the params in general in the fbtft_tools repo would be helpful, if they are not somewhere else (besides the code itself).
tz1
commented
10 years ago Yes, with the minor fix (see the issue I posted in fbtft_tools), the touchscreen works, and apparently the rest, but the tutorial on how to actually use the key-switches and backlight (and mouse?) don't seem to work. But they load.
notro
commented
10 years ago I you look at https://github.com/notro/rpi-build, you can see how I build my kernels. release.sh calls task.py which in this case imports builtin.py. builtin.py inherits from master.py which inherits from _common.py master, builtin etc. refers to the branches on https://github.com/notro/rpi-firmware which rpi-update is directed to use.
See here for some docs on fbtft_tools: https://github.com/notro/fbtft_tools/wiki/_pages modinfo will give much the same info.
See my image build script for /boot/cmdline.txt and /etc/modules for the PiTFT: https://github.com/notro/fbtft-spindle/blob/master/fbtft-stage5#L142 I haven't written about this in the wiki yet as long as my touch problems exist and not much feedback from others about this issue. You say that touch works, my problem is that sometimes it stops working after light use, but only in X windows. And it always fails after heavy use for under a minute. The same happens with the Adafruit 3.10 beta kernel. This doesn't happen on the Adafruit 3.6 kernel. So it points toward a software problem.
fbtft_devce is documented here: https://github.com/notro/fbtft/wiki/fbtft_device
but the tutorial on how to actually use the key-switches and backlight (and mouse?) don't seem to work.
Don't you get a device /dev/input/eventX?
tz1
commented
10 years ago I didn't add the parameters for the key switches. The backlight requires the backported platform dev. The keys load, but there isn't a new event in /dev (there is one for stmpe), but I'm not patching the kernel as much (only increasing the irqs and gpios and adding in your fbtft tree with Kconfig and Makefile)
I am trying to accomplish something different. I want to use the existing kernel.img binary as much as possible. And its corresponding binary ko modules. Since I'm swapping hardware - CAN interface, PiTFT, and others, I don't want to change /boot/config.txt to point to a new kernel, nor can I have it discover what's there and select a kernel to load. And as others will be building add-on modules for the current binary release, I want those to work too especially since few are pointing to the "corresponding sources" to the binaries.
The ideal for me is to have a small tarball of add-on binary modules for the various extra hardware instead of a big one with kernel+everymod. I have to do the kernel for fbtft, beyond adding gpios and interrupts, you enable FB_DEFERREDIO and FB_BACKLIGHT, but that doesn't propagate very far - few stock modules if any fail, and my CAN set works with either stock or the fbtft version (stmpe might load on stock as well - I'm not sure if it does the interrupt).
The more I alter the existing kernel tree, the more the module symbols change, and the more I have disjoint sets of kernels/modules.
But I will try at least to help with X on the framebuffer and see if it works.
notro
commented
10 years ago Image is released for testing: http://forums.adafruit.com/viewtopic.php?f=50&t=51468
AndO3131
commented
10 years ago I've got promising news. Kernel from the main branch on Github (3.10.33) doesn't work good enough with Pitft, but I've compiled 3.13.6 (https://github.com/raspberrypi/linux/tree/rpi-3.13.y) with aforementioned patches and I haven't seen touchscreen lockup for half an hour.
False hope: 3.13 also produces touchscreen lockups on heavy use.
tz1
commented
10 years ago Did the smpte-ts change by 3.13.6? (The touch screen goes about 2 seconds on mine before going away, rmmod/insmod stmpe-ts restores it for another few seconds) There is this patch: http://www.spinics.net/lists/linux-input/msg25584.html
notro
commented
10 years ago Did the smpte-ts change by 3.13.6?
No changes since Dec 17, 2012: https://github.com/raspberrypi/linux/commits/rpi-3.13.y/drivers/input/touchscreen/stmpe-ts.c
There is this patch: http://www.spinics.net/lists/linux-input/msg25584.html
That one looks very interesting. Have you tried it?
I made this list of commits between 3.6 and 3.10: http://forums.adafruit.com/viewtopic.php?f=50&t=51432&p=259977#p259977
stmpe.c has had 2 more commits in 3.13: https://github.com/raspberrypi/linux/commits/rpi-3.13.y/drivers/mfd/stmpe.c
tz1
commented
10 years ago It doesn't apply cleanly, but it is near the top of my "todo" list. (Fix my broken GPS antenna, do real wire for the CAN interface, and a few other things are ahead). I first wanted to check if it was the thing that fixed the problem. The comments do mention the silicon has a hiccup.
When I get a chance I will try to manually apply the patch, and reverse a working patch and report back. (and put it in my pikernomatic repo as a default)
notro
commented
10 years ago [PATCH] input: stmpe: Fix the touchscreen interrupt handling http://www.spinics.net/lists/linux-input/msg25584.html
This is my results form using that patch. I skipped: 050-stmpe-ts-Don-t-report-empty-packets.patch
Changes:
Before use
$ cat /sys/devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.1/stmpe-ts.0/debug
SYS_CTRL1 : 0x00
SYS_CTRL2 : 0x00
INT_CTRL : 0x03
INT_EN : 0x81
INT_STA : 0x10
STMPE_REG_TSC_CTRL : 0x11
STMPE_REG_TSC_CFG : 0xE2
STMPE_REG_FIFO_TH : 16
STMPE_REG_FIFO_STA : 0x20
STMPE_REG_FIFO_SIZE : 0After touch stops working
$ cat /sys/devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.1/stmpe-ts.0/debug
SYS_CTRL1 : 0x00
SYS_CTRL2 : 0x00
INT_CTRL : 0x03
INT_EN : 0x81
INT_STA : 0x1F
STMPE_REG_TSC_CTRL : 0x11
STMPE_REG_TSC_CFG : 0xE2
STMPE_REG_FIFO_TH : 16
STMPE_REG_FIFO_STA : 0xD0
STMPE_REG_FIFO_SIZE : 128INT_STA meaning: 0x10 = FIFO_EMPTY 0x1F = FIFO_EMPTY | FIFO_FULL | FIFO_OFLOW | FIFO_TH | TOUCH_DET
How can the FIFO be full and empty at the same time?
STMPE_REG_FIFO_STA meaning: 0x20 = FIFO_EMPTY 0xD0 = FIFO_OFLOW | FIFO_FULL | FIFO_TH_TRIG
Datasheet: http://www.st.com/web/en/resource/technical/document/datasheet/CD00226473.pdf
I need a break. Next task is to use my sysfs debug file with the unpatched stmpe-ts.
tz1
commented
10 years ago the patch didn't work on my tree either
tz1
commented
10 years ago It also doesn't fail on the tft test programs or on gpm (cut-paste for text console).
I wonder if the problem might be more related to the Xserver.
notro
commented
10 years ago Looks like I have a workaround.
The FIFO_TH interrupt flag is not cleared when touch stops working.
Can you try this?
@@ -119,6 +119,13 @@ static void stmpe_work(struct work_struct *work)
/* reset the FIFO before we report release event */
__stmpe_reset_fifo(ts->stmpe);
+ /* make sure interrupt flag FIFO_TH is cleared */
+ if (int_sta & 0b00000010) {
+ stmpe_set_bits(ts->stmpe, STMPE_REG_INT_STA, 0b11111101, 1);
+ int_sta = stmpe_reg_read(ts->stmpe, STMPE_REG_INT_STA);
+ printk(" clear interrupt flag FIFO_TH, int_sta=0x%02X\n", int_sta);
+ }
+
input_report_abs(ts->idev, ABS_PRESSURE, 0);
input_report_key(ts->idev, BTN_TOUCH, 0);
input_sync(ts->idev);When I now look at that code, it doesn't do what I thought it did.
The datasheet has this to say about the INT_STA register: Writing '1' to this register clears the corresponding bits. Writing '0' has no effect.
I mask out FIFO_TH and set TOUCH_DET. So I'm actually clearing TOUCH_DET (and others) and not FIFO_TH. This is probably more correct:
stmpe_set_bits(ts->stmpe, STMPE_REG_INT_STA, 0x00, 2);
# or just
stmpe_reg_write(ts->stmpe, STMPE_REG_INT_STA, 0b00000010);The reason this got away unnoticed, is because FIFO_TH is really cleared afterwards.
This is from a version with more printk's:
[ 119.858599] stmpe_work
[ 119.858813] timeout=40, int_sta=0x1D
[ 119.888770] timeout=0, int_sta=0x1D
[ 131.508986] stmpe_work
[ 131.509187] timeout=40, int_sta=0x1F
[ 131.518718] timeout=0, int_sta=0x1F
[ 131.520249] clear interrupt flag, int_sta=0x1C
[ 132.939030] stmpe_work
[ 132.939224] timeout=40, int_sta=0x1D
[ 132.948715] timeout=0, int_sta=0x1D
INT_STA values decoded
0x1D
1: FIFO_EMPTY
1: FIFO_FULL
1: FIFO_OFLOW
0: FIFO_TH
1: TOUCH_DET
0x1F
1: FIFO_EMPTY
1: FIFO_FULL
1: FIFO_OFLOW
1: FIFO_TH
1: TOUCH_DET
0x1C
1: FIFO_EMPTY
1: FIFO_FULL
1: FIFO_OFLOW
0: FIFO_TH
0: TOUCH_DETJust clearing the flag didn't work today. I had to re-enable the touch controller as well.
@@ -122,6 +122,27 @@ static void stmpe_work(struct work_struct *work)
input_report_abs(ts->idev, ABS_PRESSURE, 0);
input_report_key(ts->idev, BTN_TOUCH, 0);
input_sync(ts->idev);
+
+ /*
+ * Sometimes the FIFO_TH interrupt flag is not cleared.
+ * This prevents the controller from generating a new interrupt.
+ * It's not enough to clear the flag, re-enabling the touchscreen
+ * controller is also necessary.
+ * If an IRQ happens while in this function, FIFO_TH is set, but it
+ * doesn't indicate a hang. We reset anyway since the consequence is
+ * loosing one data point.
+ */
+ if (int_sta & 0b00000010) {
+ stmpe_set_bits(ts->stmpe, STMPE_REG_TSC_CTRL,
+ STMPE_TSC_CTRL_TSC_EN, 0);
+ stmpe_reg_write(ts->stmpe, STMPE_REG_INT_STA, 0b00000010);
+ __stmpe_reset_fifo(ts->stmpe);
+ stmpe_set_bits(ts->stmpe, STMPE_REG_TSC_CTRL,
+ STMPE_TSC_CTRL_TSC_EN, STMPE_TSC_CTRL_TSC_EN);
+ dev_info(ts->dev,
+ "cleared interrupt flag FIFO_TH, INT_STA: 0x%02X -> 0x%02X\n",
+ int_sta, stmpe_reg_read(ts->stmpe, STMPE_REG_INT_STA));
+ }
}
static irqreturn_t stmpe_ts_handler(int irq, void *data)That dev_info should be a dev_dbg
dmesg
[ 51.815085] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 53.627978] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 70.802444] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 89.528042] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 105.929748] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 110.444807] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 113.183154] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 114.952799] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 136.775257] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
[ 140.226109] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA: 0x13 -> 0x11
It's been working fine with the short patch above for me so far, but it has only been a about 20 minutes.
I did change various LDE X settings (popup menu, really small icons and sizes), and can run dual head: http://forums.adafruit.com/viewtopic.php?f=50&t=49856, so I can use it as more than just buttons.
notro
commented
10 years ago I did some testing to try and find out why FIFO_TH is not cleared. To do this I added some printk's:
I found that in some cases FIFO_TH is still set at the end of stmpe_irq. In others stmpe_irq reports the correct value, but when stmpe_work is run, FIFO_TH is set. (And in some cases stmpe_work is running when stmpe_irq fires).
Call chain:
stmpe_irq is called when IRQ line is asserted
stmpe_irq calls stmpe_ts_handler when FIFO_TH is set
stmpe_ts_handler waits if stmpe_work is running
stmpe_ts_handler schedules stmpe_work to run 2 ticks (20ms) into the future
stmpe_irq clears FIFO_TH
stmpe_work runs as scheduled
it waits for TOUCH_DET to clear, which it never does, as stmpe_irq acts on FIFO_TH
this causes a 4ms delaysample dmesg output
FIFO_TH is set while leaving stmpe_irq
[ 6450.321149] stmpe_irq()
[ 6450.321992] stmpe_ts_handler()
[ 6450.344123] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6450.344326] INT_STA(0x0B)=0x1F
[ 6450.354111] stmpe_work()
[ 6450.378126] timeout=0, int_sta=0x1F
[ 6450.397101] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA(0x0B): 0x1F -> 0x1D
[ 6450.401170] stmpe_irq()
[ 6450.401340] stmpe_ts_handler()
[ 6450.402935] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6450.403092] INT_STA(0x0B)=0x1DFIFO_TH is cleared while leaving stmpe_irq, but set in stmpe_work
[ 6493.179627] stmpe_irq()
[ 6493.180353] stmpe_ts_handler()
[ 6493.197431] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6493.203687] INT_STA(0x0B)=0x1D
[ 6493.215201] stmpe_work()
[ 6493.239095] timeout=0, int_sta=0x1F
[ 6493.257854] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA(0x0B): 0x1F -> 0x1D
[ 6493.261899] stmpe_irq()
[ 6493.262495] stmpe_ts_handler()
[ 6493.264263] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6493.264416] INT_STA(0x0B)=0x1DTouch interrupt happens while in stmpe_work
[ 6500.861811] stmpe_irq()
[ 6500.862600] stmpe_ts_handler()
[ 6500.883054] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6500.883217] INT_STA(0x0B)=0x1D
[ 6500.895563] stmpe_work()
[ 6500.915287] stmpe_irq()
[ 6500.916346] stmpe_ts_handler()
[ 6500.920191] timeout=0, int_sta=0x1F
[ 6500.939118] stmpe-ts stmpe-ts.0: cleared interrupt flag FIFO_TH, INT_STA(0x0B): 0x1F -> 0x1D
[ 6500.955273] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6500.956615] INT_STA(0x0B)=0x1D
[ 6500.959422] stmpe_irq()
[ 6500.960177] stmpe_ts_handler()
[ 6500.965132] stmpe_reg_write(stmpe, 0x0B, 0x02);
[ 6500.965302] INT_STA(0x0B)=0x1DI've compiled new kernel with patch
@@ -119,6 +119,13 @@ static void stmpe_work(struct work_struct *work)
/* reset the FIFO before we report release event */
__stmpe_reset_fifo(ts->stmpe);
+ /* make sure interrupt flag FIFO_TH is cleared */
+ if (int_sta & 0b00000010) {
+ stmpe_set_bits(ts->stmpe, STMPE_REG_INT_STA, 0x00, 2);
+ int_sta = stmpe_reg_read(ts->stmpe, STMPE_REG_INT_STA);
+ printk(" clear interrupt flag FIFO_TH, int_sta=0x%02X\n", int_sta);
+ }
+
input_report_abs(ts->idev, ABS_PRESSURE, 0);
input_report_key(ts->idev, BTN_TOUCH, 0);
input_sync(ts->idev);Tested it for a few hours and it works without lockups (although excessive heavy touching hasn't been done).
notro
commented
10 years ago I have settled with this patch: https://github.com/notro/rpi-build/blob/master/patches/builtin/050-stmpe-ts-Various-fixes.patch
PiTFT: Does Linux 3.10 break touch? has been updated with a short stress test I did.
notro
commented
10 years ago Closing issue since there has been no activity for more than 2 months. Reopen if needed.
fjrojas
commented
10 years ago Hello Notro. First of all, congratulations for mantaining support to TFT devices on the RPi.
Second, my PiTFT screen works with your pre-loaded image and Adafruit's .deb packages. The problem is that I require to use different kernel versions (3.14.2 and 3.12.24, to be precise) with the PiTFT screen. I have both RPi linux kernel sources backed up, and also have compiled and ran them successfully without the PiTFT support.
To add the support, I have done the following:
BACKLIGHT_GPIO=m CAN=y CAN_BCM=m CAN_CALC_BITTIMING=y CAN_DEV=y CAN_GW=y CAN_MCP251X=m CAN_RAW=m CAN_SLCAN=m CAN_VCAN=m DYNAMIC_DEBUG=y FB_BACKLIGHT=y FB_DEFERRED_IO=y FB_FLEX=m FB_SYS_COPYAREA=m FB_SYS_FILLRECT=m FB_SYS_FOPS=m FB_SYS_IMAGEBLIT=m FB_TFT=m FB_TFT_BD663474=m FB_TFT_FBTFT_DEVICE=m FB_TFT_HX8340BN=m FB_TFT_HX8347D=m FB_TFT_HX8353D=m FB_TFT_ILI9320=m FB_TFT_ILI9325=m FB_TFT_ILI9340=m FB_TFT_ILI9341=m FB_TFT_ILI9486=m FB_TFT_PCD8544=m FB_TFT_RA8875=m FB_TFT_S6D02A1=m FB_TFT_S6D1121=m FB_TFT_SSD1289=m FB_TFT_SSD1306=m FB_TFT_SSD1331=m FB_TFT_SSD1351=m FB_TFT_ST7735R=m FB_TFT_TINYLCD=m FB_TFT_UPD161704=m FB_TFT_WATTEROTT=m FONTS=y FONT_10x18=y FONT_6x11=y FONT_7x14=y FONT_ACORN_8x8=y FONT_MINI_4x6=y FONT_PEARL_8x8=y FONT_SUN12x22=y FONT_SUN8x16=y FRAMEBUFFER_CONSOLE_ROTATION=y GPIO_MCP23S08=m GPIO_STMPE=y INPUT_KEYBOARD=y INPUT_MOUSE=y INPUT_TOUCHSCREEN=y KEYBOARD_GPIO=m MFD_STMPE=y MOUSE_GPIO=m SPI_BITBANG=m SPI_GPIO=m STMPE_I2C=y STMPE_SPI=y TOUCHSCREEN_ADS7846=m TOUCHSCREEN_STMPE=m
And also changed the following:
BACKLIGHT_CLASS_DEVICE m -> y MFD_CORE m -> y
/* make sure interrupt flag FIFO_TH is cleared */ if (int_sta & 0b00000010) { stmpe_set_bits(ts->stmpe, STMPE_REG_INT_STA, 0x00, 2); int_sta = stmpe_reg_read(ts->stmpe, STMPE_REG_INT_STA); printk(" clear interrupt flag FIFO_TH, int_sta=0x%02X\n", int_sta); }
When I load the kernel to RPi SD card, and then run the board, it boots with no errors, but the screen does not even turn on.
Could you help me find out what am I missing to do?
Observations:
Additional Questions:
Thanks a lot for your time. Have a nice day.
notro
commented
10 years ago You set the FBTFT drivers to built as loadable modules and not built into the kernel proper. Do you load fbtft_device?
# the arguments are already given on the kernel commandline
sudo modprobe fbtft_deviceThis file exists no more: https://github.com/notro/rpi-build/blob/master/patches/builtin/050-stmpe-ts-Various-fixes.patch
I have redone my build system: https://github.com/notro/rpi-build/wiki The patch is here now: https://github.com/notro/fbtft-build/blob/master/patches/stmpe-ts-Various-fixes.patch/3.10
Using the raspberry cross compiler, I cannot compile (with the make command) the following modules stmpe_device and gpio_backlight_device from here: https://github.com/notro/fbtft_tools
This is the log of my latest build: https://github.com/notro/rpi-firmware/blob/master/extra/build.log#L9556
Does the fbtft driver have support for the Pitft yet? also the custom image you are going to make for it, will it have it compiled into the kernel so it can be specified in cmdline.txt??