根据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）所有时间值都是在内核级别计算的，此处不涉及用户空间问题。
答案 0 :(得分：0)
值得注意的一件事是，如果您的sd接口通过DMA运行，这样驱动程序可以对状态机进行编程，然后它只是自行运行，或者如果获取消息需要驱动程序重复服务，这可能是被其他内核义务推迟。
您还可以看到是否存在I / O瓶颈，例如SD接口或它挂起的任何总线还用于其他东西？
最后，您可以搜索增加优先级的方法。在极端情况下，您可以切换到实时SD驱动程序而不是正常的SD驱动程序。