设备树 - 探测驱动程序并避免竞争条件答案

【问题标题】：Device tree - Probing a driver and avoiding race conditions设备树 - 探测驱动程序并避免竞争条件
【发布时间】：2017-10-26 15:33:25
【问题描述】：

我有一个连接到 Linux 开发板的触摸屏设备。它是一个基于 SPI 的设备。显示器运行良好，但触摸屏（使用 STMPE610 控制器）非常不可靠 - 它适用于不同的板和系统，但不适用于其他板和系统。发现的是设备探测期间屏幕出现故障（错误-22）。驱动程序探测失败。

SPI 可以在各种模式下进行电气配置/驱动（有 4 个），并且触摸控制器似乎处于某种未知状态。

此外，计算机还尝试配置其驱动屏幕的 SPI 引脚（根据具体情况将它们拉上或拉下）。

问题 - 我需要知道 Linux 设备驱动程序延迟探测的做法是什么，或者如何解决竞争条件，以便对麻烦的 SPI 从设备进行驱动程序探测。 Linux DeviceTree 是否提供诸如 wait 或 delay 功能之类的功能？

我基本上需要延迟驱动程序探测，直到系统成功配置自己的电气（计算机）并且从设备（触摸屏）最终决定它是什么 SPI 模式。

【问题讨论】：

有没有试过在触摸屏初始化完成后手动加载驱动？
我真的不想做 insmod ......但不，我没有尝试过。
“Linux DeviceTree 是否提供诸如等待或延迟功能之类的功能？” -- 没有。但是设备驱动程序可以（大致）指定它的 init 例程何时启动调用。请参阅stackoverflow.com/questions/15541290/… 和 init.h 的链接。也许您希望您的驱动程序使用 late_initcall()。
@Xofo：听起来像被困在你的方式中已经花费了你几个月的时间。即使没有插入键盘或鼠标，X 也可以启动。它为什么要关心您的触摸屏是否准备就绪？将驱动程序构建为可加载模块的原因之一是为了在加载时获得更多控制。我自己使用过易碎的硬件，唯一的解决方案是在启动过程的后期加载驱动程序。至少，这是一个可以提供有用信息的实验。充其量，它可以解决您的问题。
@DavidCullen，没有only 解决方案，最好的方法是修复驱动程序以避免这种行为。模块加载延迟只是隐藏了真正的问题。

标签： linux linux-device-driver spi device-tree

【解决方案1】：

我之前也遇到过类似的问题，那就是两个车手之间的比赛情况。我所做的是将usleep_range(1000000, 12000000); 添加到驱动程序内的 probe 函数中。这会给您大约 10 秒的延迟。

在您的情况下，您可以尝试将usleep_range(1000000, 12000000); 放入您的触摸屏 驱动程序的probe 函数中，这样驱动程序将在10 - 12 秒后加载。您可以对其进行调整，以便首先加载 SPI，并分配 touchscreen 驱动程序所需的所有资源并准备好使用。

这不是解决问题的好方法，只能节省时间，因为它可能会失败，例如由于某些原因 SPI 驱动程序在 10 秒后加载。

【讨论】：