GPIO驱动禁用sleepable API的疑问与用户态GPIO性能优化咨询

• 目前处于摸索阶段，对相关内容理解尚不清晰，将提出一些基础问题。
• 正在通过GPIO V2 API在用户态开发GPIO位操作程序，当前运行速度尚可，但希望进一步提升性能。研究gpiod接口后，发现自己在用户态实现的逻辑与其十分相似。
• 正在研究是否需要将GPIO配置为IRQ来设计设备驱动，但具体实现方式尚不明确——由于spi、i2c等标准设备类均不适用，需要为该设备创建新的类。
• 当前用户态代码的最大问题是等待特定引脚状态：最初尝试使用epoll，但延迟极高。目前采用平衡方案：对就绪时间未知的等待使用epoll，对可预测事件使用主动轮询，结果显示主动轮询的速度远快于epoll。
• 因此，epoll/轮询是当前的痛点，其他调用均通过ioctl直接与内核中的gpiod/GPIO子系统交互。

阅读内核GPIO驱动文档时，发现驱动也存在同样的非实时性问题：

ensure that sleepable APIs are not used as part irq_chip implementation If sleepable APIs have to be used, these can be done from the .irq_bus_lock() and .irq_bus_unlock() callbacks

在网上未找到关于“sleepable API”的现成定义，推测其字面意思即可理解，怀疑epoll/usleep属于此类API。

疑问点：

• 若不建议使用sleepable API，应采用何种替代API？
• 是否像在用户态中那样使用主动轮询？但这会占用大量CPU时间，那从用户态转向内核态开发的意义何在？

所使用的平台为4核ARM处理器，将进程/线程绑定到某一核心后，即使用户态程序的性能也大幅提升。

内容的提问来源于stack exchange，提问作者Anonymous