notro / fbtft

Linux Framebuffer drivers for small TFT LCD display modules. Development has moved to https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
1.85k stars 496 forks source link

Touch hangs after some use. #430

Closed Ferite closed 6 years ago

Ferite commented 7 years ago

Hi.

I want to use a WaveShare 3.2 display (fb_ili9340 + XPT2046) on an Up! board (Intel Atom x5-Z8350, 40 pin RPi compatible GPIO) running Ubilinux. Its kernel includes fbtft drivers, and I have built ads7846_device from source.

Despite there is no problem with the display, the touch hangs after some use, and won't work until the board is restarted. As the display keeps working and refreshing picture, I think it is not a SPI driver related problem.

I am loading the driver this way:

sudo modprobe ads7846_device model=7846 cs=1 gpio_pendown=17 speed=1000000 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900 busnum=2 verbose=2 When I do dmesg, there are not messges refered to ads7846_device besides the generated when it is loaded. So I was wondering if there is a way I could get more clues about what could be happening.

Thanks. Kind regards.

notro commented 7 years ago

You can look at /proc/interrupts to see if the counter increases on touch (generates interrupts).

Ferite commented 7 years ago

Hi.

Indeed the counter stop incresing:

 123:       6499          0          0          0  chv-gpio    8  up-pinctrl
 326:       6499          0          0          0   up-gpio   17  ads7846

I tested the pen down pin (GPIO17), and it stucks in 3.3V when the touch quit responding. So i tested another display and it was the same. Both displays are working well with an Odroid C1+. I think I'm more confused now.

notro commented 7 years ago

I haven't tried it, but it appears to be a way to reset the controller by writing 1 and then 0 to: /sys/bus/spi/devices/spiX.X/disable

Ref: http://lxr.free-electrons.com/source/drivers/input/touchscreen/ads7846.c#L594

Ferite commented 7 years ago

I have done some tests with the same WaveShare32, and found out an interesting thing. When I press the the touchscreen, I draw a line and then release it, with my Odroid C1 the interrupt count increases by 2:

Before press:

96: 145 0 1 0 GIC ads7846

After release:

96: 147 0 1 0 GIC ads7846

If I do the same in Up board, It increases by 1681:

Before: 326: 0 0 0 0 up-gpio 17 ads7846

After: 326: 1681 0 0 0 up-gpio 17 ads7846

Further more, I could verify that in Odroid there is a single increment for each press and release, no matter how long I let my finger pressed. In Up board if I let my finger pressed, the counter increment by thousands.

Could be that the cause of the touch hang?. That would be a driver or platform related Issue?.

By the way, the disable by /sys/bus/spi/devices/spiX.X/disable seems not to take efect once the touch has hang.

Thanks.

notro commented 7 years ago

In Up board if I let my finger pressed, the counter increment by thousands

Clearly something wrong here. The datasheet has this to say about the interrupt:

The PENIRQ output goes low due to the current path through the touch screen to ground, which initiates an interrupt to the processor.

So, one interrupt per "touch".

Ferite commented 7 years ago

So I must search for a bug in the GPIO driver, maybe?.

notro commented 7 years ago

I suggest asking someone with knowledge about the board.

Ferite commented 7 years ago

Some time has past since my report of IRQ counter incrementing by thousands when the pen is left down with Intel based Up! board. Since then, they have updated the board's kernel, so I made mi tests again. Good news is the IRQ counter does not increment wildly any more. Now, a single IRQ is generated by each release/press. But sadly, no click event is geneated anymore (no output in cat /dev/input/event3 or evtest), despite with the former kernel, the clicks worked until the interrup hanged.

As I know it is hard to give an efective guidance with this info, I was wonder if you could advice me on what things should I compare with the previous system (the one before the kernel update) in order to diagnose what is hapenning.

Thanks a lot.

For the record this is the kernel messages:

$dmesg | grep -i ADS7846

               ads7846_device: ads7846_device_init()
[    8.091222] ads7846_device: SPI devices registered:
[    8.091227] ads7846_device:    flexfb spi2.0 16000kHz 8 bits mode=0x00
[    8.091229] ads7846_device:
[    8.091231] ads7846_device: Settings:
[    8.091233] ads7846_device:   model = 7846
[    8.091234] ads7846_device:   gpio_pendown = 17
[    8.091236] ads7846_device:   swap_xy = 1
[    8.091237] ads7846_device:   x_min = 300
[    8.091238] ads7846_device:   x_max = 3800
[    8.091239] ads7846_device:   y_min = 700
[    8.091241] ads7846_device:   y_max = 3400
[    8.091242] ads7846_device:   x_plate_ohms = 60
[    8.091243] ads7846_device:   pressure_min = 0
[    8.091244] ads7846_device:   pressure_max = 255
[    8.091246] ads7846_device:   keep_vref_on = 1
[    8.091247] ads7846_device:   vref_delay_usecs = 0
[    8.091248] ads7846_device:   vref_mv = 0
[    8.091249] ads7846_device:   settle_delay_usecs = 0
[    8.091251] ads7846_device:   penirq_recheck_delay_usecs = 0
[    8.091252] ads7846_device:   y_plate_ohms = 0
[    8.091253] ads7846_device:   debounce_max = 0
[    8.091254] ads7846_device:   debounce_tol = 0
[    8.091255] ads7846_device:   debounce_rep = 0
[    8.092944] ads7846 spi2.1: spi2.1 supply vcc not found, using dummy regulator
[    8.094159] ads7846 spi2.1: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
[    8.094238] ads7846 spi2.1: touchscreen, irq 224
[    8.095495] input: ADS7846 Touchscreen as /devices/pci0000:00/8086228E:01/spi_master/spi2/spi2.1/input/input2
[    8.096115] ads7846_device: SPI devices registered:
[    8.096121] ads7846_device:    flexfb spi2.0 16000kHz 8 bits mode=0x00
[    8.096123] ads7846_device:    ads7846 spi2.1 2000kHz 8 bits mode=0x00
[    8.096125] ads7846_device:
notro commented 7 years ago

I would have tried to check gpio interrupts by other means, like this: http://elinux.org/GPIO#GPIO_interrupts_from_user_space

notro commented 6 years ago

Closing issue since there has been no activity for more than 2 months. Reopen if needed.