1

I have a touchscreen device that is connected to a Linux board. It is an SPI based device. The display works well, but the touch screen (using an STMPE610 controller) is very unreliable - It works on different boards and systems and does not work on others. What has been discovered is that the screen fails during the device probe (Error -22). The driver probe fails.

SPI can be electrically configured/driven in various modes (there are 4), and touch controller seems to come up in a somewhat unknown state.

Furthermore the computer is also trying to configure its SPI pins that are driving the screen (either pulling them up or pulling them down, as the case may be).

The question - I need to know WHAT the practice is for Linux device drivers to delay the probing or HOW to work around race conditions so that a driver probe on a troublesome SPI slave device can work. Does the Linux DeviceTree provide any such features such as wait or delay function?

I basically need to delay the driver probe UNTIL the system has successfully configured itself electrically (the computer) and the slave device (the touch screen) has finally decided what SPI mode it is.

Kara
  • 6,115
  • 16
  • 50
  • 57
Xofo
  • 1,256
  • 4
  • 18
  • 33
  • 1
    Have you tried manually loading the driver after the touchscreen is finished initializing? –  May 25 '17 at 21:11
  • I really do not want to do a insmod ... but NO I have not tried that. – Xofo May 25 '17 at 21:15
  • I am also reading this - https://lwn.net/Articles/662820/ ... Which has me a bit agape :D – Xofo May 25 '17 at 21:48
  • Why don't you want to do an insmod? –  May 25 '17 at 21:59
  • @DavidCullen In short - Because I am stuck in my ways. I have compiled all the drivers into the Kernel and I want to use the device tree. I would like to keep things like this. If I insmod this driver, it would be the only driver plus I am unsure how to configure X11 if I insmod such a UI driver after everything has started up. Maybe I need to try it. – Xofo May 25 '17 at 22:15
  • 1
    *"Does the Linux DeviceTree provide any such features such as wait or delay function?"* -- No. But the device driver can (roughly) specify when its init routine is invoked. See https://stackoverflow.com/questions/15541290/what-is-the-difference-between-module-init-and-subsys-initcall-while-initializin/15542788#15542788 and the link to **init.h**. Maybe you want your driver to use **late_initcall()**. – sawdust May 25 '17 at 23:14
  • 1
    @Xofo: Sounds like being stuck in your ways has already cost you several months. X can start even when there is no keyboard or mouse plugged in. Why should it care if your touchscreen is ready? One of the reasons to build a driver as a loadable module is to obtain more control over when it is loaded. I've worked with flakey hardware myself where the only solution was to load the driver late in the boot process. At the least, it's an experiment that may provide useful information. At the best, it's the solution to your problem. –  May 26 '17 at 00:03
  • @DavidCullen - Your are correct. But isolating the problem has taken some time. A software developer can sometimes get stuck in the digging of a hole to the other side of the world. I am working with an embedded device and Device Trees are touted as the normative way of handling devices. What I am seeing is that they do not seem to provide mechanisms for flakey devices. The device initialization sequence and the STATE of the pins are things to try to match. – Xofo May 26 '17 at 03:00
  • 1
    @DavidCullen, there is no *only* solution, the best one is to fix the driver to avoid this behaviour. Module load delaying is just hiding the real issue. – 0andriy May 27 '17 at 21:33
  • @sawdust, this is not how it's resolved in modern kernel, there are mechanisms for that and late_initcall() is the last resort (usually it's applied to very specific code, apparently not the case here). – 0andriy May 27 '17 at 21:34

1 Answers1

1

I had a similar problem before, that is having racing condition between two drivers. What I did is adding usleep_range(1000000, 12000000); into the probe function inside the driver. This will give you roughly 10s of delay.

In your case, you can try to put usleep_range(1000000, 12000000); into the probe function in your touchscreen driver such that the driver will be loaded 10 - 12 seconds later. You can adjust it in order to have SPI get loaded first and all resources that the touchscreen driver needs are allocated and ready to be used.

This is not a good way to solve the problem only save time because there is possibility it would fail such as for some reasons the SPI driver get loaded later than 10 seconds.

Jason Liu
  • 749
  • 4
  • 16
  • 34