Note
此文件的目的是为让中文读者更容易阅读和理解,而不是作为一个分支。 因此, 如果您对此文件有任何意见或更新,请先尝试更新原始英文文件。 如果您发现本文档与原始文件有任何不同或者有翻译问题,请发建议或者补丁给 该文件的译者,或者请求中文文档维护者和审阅者的帮助。
- Original:
- 翻译:
白钶凡 Kefan Bai <baikefan@leap-io-kernel.com>
- 校译:
DWC3 驱动¶
待办¶
如果你愿意接手其中一项任务,可以从下面选择:
将中断处理程序改为每个端点各自使用线程化 IRQ
实践表明,某些 DWC3 命令大约需要
~1 ms才能完成。当前代码会一直自旋 等待命令完成,这并不是好办法。实现思路:
DWC 核心实现了一个按端点分发中断的 IRQ 控制器。中断号在探测 (
probe)阶段分配,并归属于该设备。如果硬件通过MSI为每个 端点提供独立中断,那么这个“虚拟”IRQ 控制器就可以被真实的端点中断 取代。在调用
usb_ep_enable()时请求并分配中断资源,在调用usb_ep_disable()时释放中断资源。最坏情况下需要 32 个中断,最少是ep0/1的两个中断。dwc3_send_gadget_ep_cmd()将在wait_for_completion_timeout()中休眠,直到命令完成。中断处理程序分为以下几个部分:
设备级主中断处理程序 遍历每个事件,并调用
generic_handle_irq()处理。返回后再确认 事件计数器,让中断最终消失。设备级线程化处理程序 无。
端点中断的主处理程序 读取事件并尽量处理;凡是需要睡眠的操作都交给线程处理。事件保存在 每个端点的数据结构中。一旦某项工作已经交给线程处理,主处理程序里就 不要再碰它,以免出现优先级反转之类的问题。
端点中断的线程化处理程序 处理剩余的端点工作,这些工作可能会睡眠,例如等待命令完成。
延迟:
不应增加额外延迟,因为中断线程优先级较高,会在普通用户任务之前运行 (除非用户更改了调度优先级)。