文档介绍：Linux USB 驱动框架分析(一)
初次接触和 OS 相关的设备驱动编写,感觉还挺有意思的,为了不至于忘掉看过的东西,
笔记跟总结当然不可缺,更何况我决定为嵌入式卖命了。好,言归正传,我说一说这段时间
的收获,跟大家分享一下 Linux 的驱动研发。但这次只先针对 Linux 的 USB 子系统作分析,
因为周五研讨老板催货。当然,还会顺带提一下其他的驱动程式写法。
事实上,Linux 的设备驱动都遵循一个惯例??表征驱动程式(用 driver 更贴切一些,
应该称为驱动器比较好吧)的结构体,结构体里面应该包含了驱动程式所需要的所有资源。
用术语来说,就是这个驱动器对象所拥有的属性及成员。由于 Linux 的内核用 c 来编写,所
以我们也按照这种结构化的思想来分析代码,但我还是希望从 OO 的角度来阐述这些细节。
这个结构体的名字有驱动研发人员决定,比如说,鼠标可能有一个叫做mouse_dev 的 struct,
键盘可能由一个 keyboard_dev 的 struct(dev for device,我们做的只是设备驱动)。而这次我
们来分析一下 Linux 内核源码中的一个 usb-skeleton(就是 usb 驱动的骨架咯),自然,他定
义的设备结构体就叫做 usb-skel:
struct usb_skel {
struct usb_device * udev; /* the usb device for this device */
struct usb_interface * interface; /* the interface for this device */
struct semaphore limit_sem; /* limiting the number of writes in progress
*/
unsigned char * bulk_in_buffer; /* the buffer to receive data */
size_t bulk_in_size; /* the size of the receive buffer */
__u8 bulk_in_endpointAddr; /* the address of the bulk in endpoint */
__u8 bulk_out_endpointAddr; /* the address of the bulk out endpoint */
struct kref kref;
};
这里我们得补充说明一下一些 USB 的协议规范细节。 USB 能够自动监测设备,并
调用相应得驱动程式处理设备,所以其规范实际上是相当复杂的,幸好,我们不必理会大部
分细节问题,因为 Linux 已提供相应的解决方案。就我目前的理解来说, USB 的驱动分为
两块,一块是 USB 的 bus 驱动,这个东西,Linux 内核已做好了,我们能不管,但我们至少
要了解他的功能。形象得说, USB 的 bus 驱动相当于铺出一条路来,让所有的信息都能通
过这条 USB 通道到达该到的地方,这部分工作由 usb_core 来完成。当 USB 设备接到 USB
控制器接口时,usb_core 就检测该设备的一些信息,例如生产厂商 ID 和产品的 ID,或是设
备所属的 class、subclass 跟 protocol,以便确定应该调用哪一个驱动处理该设备。里面复杂
细节我们不用管,我们要做的是另一块工作??usb 的设备驱动。也就是说,我们就等着
usb_core 告诉我们要工作了,我们才工作。
从研发人员的角度看,每一个 usb 设备有若干个设置(configuration)组成,每个设置
又能有多个接口(interface),每个接口又有多个设置(setting 图中没有给出),而接口本身可能
没有端点或多个端点(end point)。 USB 的数据交换通过端点来进行,主机和各个端点之间
建立起单向的管道来传输数据。而这些接口能分为四类:
控制(control)
用于设置设备、获取设备信息、发送命令或获取设备的状态报告
中断(interrupt)
当 USB 宿主需求设备传输数据时,中断端点会以一个固定的速率传送少量数据,还
用于发送数据到 USB 设备以控制设备,一般不用于传送大量数据。
批量(bulk)
用于大量数据的可靠传输,如果总线上的空间不足以发送整个批量包,他会被分割
成多个包传输。
等时(isochronous)
大量数据的不可靠传输,不确保数据的到达,但确保恒定的数据流,多用于数据采
集。
L