根据 SDIO 规范，操作序列（用于写事务）发生如下：
Command53 -- CommandLatency -- Command53Response -- ResponseLatency -- startbit -- write-number-of-bytes -- CRC -- endbit -- WriteLatency -- startbit -- CRC -- endbit -- busybit。
在对 SDIO UART 驱动程序进行基准测试时，我得到的时间值超出了预期。发现很多延迟，尤其是在写事务期间。
延迟的原因可能是调度程序将处理器时间分配给其他进程、工作队列延迟等。
我想分析和了解延迟。了解设备驱动程序代码和逻辑分析仪波形之间的映射可能会导致一些提示。
有人可以对此有所了解吗？
谢谢你。
编辑1：对不起！我假设了一些事情。
在sdio_uart_transmit_chars()中有一个调用sdio_out()，依次调用sdio_writeb()并且该调用将逐字节（一次一个字节）写入 SDIO UART 设备。我修改了驱动程序以使用sdio_writesb()即多字节模式。这相对减少了写入 X 个字节的时间。有趣的是，随着写入数据大小的增加，WriteLatency 呈指数增长（如上所述）。
这种延迟可能是由于许多原因。我想了解这些原因。
设置：我正在使用 Linux (v 2.6.32) 笔记本电脑和可加载内核模块（已修改sdio_uart.c）
编辑2：
可能在这个问题中添加“SDIO”会产生误导......（目前不确定）。在与硬件交互时，延迟的原因可能对任何设备驱动程序都是通用的，并且可能与 SDIO 写入过程无关。
如果有人可以将我指向相关的在线资源，我很乐意在这里探索和更新结果。
希望这次我增加了更多的清晰度。如果我的问题仍然不清楚，请发表评论。
感谢您的时间。
编辑 3：
是的，我正在查看逻辑分析仪 (LA) 上的信号，写入期间和写入之间的延迟比我预期的要长。
给出关于时间值的概念：
对于 512 字节传输：在硬件级别上，理论上写入应该需要 50 微秒（我们），但实际上我得到了 200 微秒。
这个150我们的差距是我想了解的。
注意：
1）我正在四舍五入时间值以简化案例。
2）所有时间值都是在内核级别计算的，这里不涉及用户空间问题。