Reputation: 1288
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.
Upvotes: 1
Views: 1917
Reputation: 818
I had a similar problem before, that is having racing condition between two drivers. What I did is adding usleep_range(10000000, 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(10000000, 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.
Upvotes: 2