Linux：PREEMPT_RT 和 regmap 子系统

Question

背景：

我正致力于通过

PREEMPT_RT_FULL

为供应商提供的 4.9 Linux 内核实施 RT 抢占。不幸的是，似乎特定供应商在编写驱动程序时并没有真正计划 RT，因此在他们的 pinctrl 驱动程序中大量使用了 regmap 子系统。

这会导致明显的问题，因为完全 RT 抢占导致基本自旋锁可休眠。在我的特殊情况下，pinctrl 驱动程序使用 regmap API（它本身使用可休眠锁）并且首先通过

__setup_irq

在

raw_spin_lock

下调用。在此原子上下文中，不允许休眠并生成内核 oops。

问题：

从概念上讲，我应该如何重构大量使用 regmap 的 pinctrl 驱动程序以与

PREEMPT_RT_FULL

一起使用？

如我所见，我可以通过以下几种方式之一来解决这个问题：

1. 剥离 regmap 以支持原始 I/O 函数和接近 MMIO 访问的原始自旋锁。 这似乎是最直接的方法，但我很难相信内核维护者在设计时没有考虑到这种情况RT 支持。有很多驱动程序使用 regmap，这意味着它们都不能在原子上下文中调用，这正是您想要使用 MMIO 的时候。也就是说，我对所需的原始自旋锁数量并不感到兴奋。转述自我读过的一篇（也许是 LWN？）关于该主题的文章：你的司机并不像你想象的那么重要。

2. Convert regmap to use raw spinlocks. 这将解决所有驱动程序的问题，但它在 RT 面前飞行。就是说，我想不出您不会想要围绕寄存器访问进行某种锁定的情况，尤其是考虑到现在有如此多的内核可以休眠。看起来这真的应该有 some 种锁，虽然也许这最好由个别驱动程序而不是这种全球变化来决定？

3. 别的东西。也许这里有一扇门#3？我无法完全重构驱动程序，因为 MMIO 访问需要在来自上层内核的各种回调的上下文中发生。在 IRQ 系统中转换原始自旋锁似乎是个坏主意。据我所知，没有办法从安全上下文中预加载这些数据，这进一步限制了重构选项。

那么，应该如何最好地解决这个问题，同时尽可能多地保留可预测的延迟行为？

是否有另一个驱动程序以规范可接受的方式处理此问题，我可以用作示例？