: usb 流程

 

 

：uhci

 

 

: usb热插拔实现机制(hub probe或者中断)

 

: 这个讲了usb_device_driver和usb_driver。usbhub发现新设备的插入时， 先用device来进行dvice_add(见usb_alloc_dev， 其中dev->dev.type = &usb_device_type; 这个表示是整个usb device)， 然后usb_register_device_driver注册的driver的generic_probe会被usb_probe_device调用， 这个函数会调用usb_set_configuration。如此接口类型的device_add会被调用(intf->dev.type = &usb_if_device_type; 这个表示是usb interface设备（当时理解了半天， 这么着都找不到interface probe中的dev是怎么能转变成interface的。多亏了这篇文档）)。这样设备接口的probe函数就在usb_probe_interface中被调用，usb_probe_interface是在usb_register_driver（usb_register）中注册的。这样usb设备的枚举过程就容易读了。

：这个文章介绍了linux device和driver匹配的过程。

 

 

 

: usb协议

 : usb hub协议

 

 

: hub request

 

 

: ohci寄存器描述:ed, td

 

: ehci:软件简化

 

：usb3.0：多了4根超速线， 分离的2个hub（超速， 2.0）， 设备可以发ready的异步请求， 不同于2.0的由主机发起的轮询请求。流式管道用于3.0的流控（bulk扩展）。支持突发模式传输. 网上基本没有linux usb3.0驱动的讲解文章， 也没有特别公开的usb3.0芯片的资料和讲解(20140122)。

 

 

: 无线usb带宽分析

 

：usb masstorage

: 描述linux scsi驱动的， 包括跟linux块层的接口，跟底层host的接口， 以及一些sequence。至此明白usb mass storage设备是如何挂接scsi, 再挂接到块设备， 由此挂接到文件系统的（不好意思， 这个花了偶近5年的时间， 因为是靠平常的时间， 悲催啊）。

 ：scsi io回调

 

 

usb gadget:

 

 

：讲述不用composite framework的逆势.

usb device侧的gadget驱动框架总体上比较薄。协议层(masstorage/cdc等)调用gadget api, gadget api调用gadget的端点ep的ops， 这个ops来自具体硬件平台的注册的ep的操作函数。udc_core主要负责udc 添加usb_add_gadget_udc， 设备层的usb_gadget_probe_driver等。

file_storage与mass_storage的区别是前者未使用composite抽象， 后者使用composite抽象。composite抽象层同时供其他协议（串口/网络等）使用（config/function管理）。

mass storage都是经过vfs访问具体的存储设备， 其路径是模块加载时的file参数确定的（在内核态可通过vfs api访问文件）。scsi命令在sorage层被解析。

.c中的mass_storage也是走的composite. 这个文件整合了很多的usb device功能， 包含adb等。通过sysfs的store函数enable不同的功能。

具体udc驱动负责queue/传输管理(dma? fifo?)/设备管理/中断等。可参考omap等， platform_driver_probe注册这个driver。dma调用platform层提供的dma功能操作。 不同的platform的dma函数不同。

 

 

: usb gadget串口

：linux tty驱动

 : linux console

 : linux伪终端

usb串口主要是将usb转换成tty设备， device侧和host侧都是这样。cdc acm模拟modem

audio device使用linux sound core接口

video：v4l2接口

ether: cdc eem/ecm/subset,实现net_device_ops接口：

 android mtp:文件传送 ptp：still image类：

rndis:微软协议， 代替cdc ether协议