我要注册-主控制器与ROOT HUB难分难舍
这里要说明几点,这里只是说明一下框架,对于一些错误处理都没说到,而且一些细节也没说,只是有个认识,具体可参考《linux那些事儿系列从书》。
我要插拔
在讲插拔时,我们先了解一下设备插入到hub里面,会有什么结果。“USB主机是如何检测到设备的插入的呢?首先,在USB集线器的每个下游端口的D+和D-上,分别接了一个15K欧姆的下拉电阻到地。这样,在集线器的端口悬空时,就被这两个下拉电阻拉到了低电平。而在USB设备端,在D+或者D-上接了1.5K欧姆上拉电阻。对于全速和高速设备,上拉电阻是接在D+上;而低速设备则是上拉电阻接在D-上。这样,当设备插入到集线器时,由1.5K的上拉电阻和15K的下拉电阻分压,结果就将差分数据线中的一条拉高了。集线器检测到这个状态后,它就报告给USB主控制器(或者通过它上一层的集线器报告给USB主控制器),这样就检测到设备的插入了。USB高速设备先是被识别为全速设备,然后通过HOST和DEVICE两者之间的确认,再切换到高速模式的。在高速模式下,是电流传输模式,这时将D+上的上拉电阻断开。”引用自《USB入门系列之五》。对于轮循的话,在usb_create_hcd里有初始化一个内核定时器,设定每隔一段时间就会调用rh_timer_func
/* timer callback */
static void rh_timer_func (unsigned long _hcd)
{
usb_hcd_poll_rh_status((struct usb_hcd *) _hcd);
}
即调用hcd_poll_rh_status这个函数就会调用主控制器的驱动程序里的hcd->driver->hub_status_data(hcd, buffer);这里假设是uhci就会调用uhci_hub_status_data
uhci_hub_status_data
- static int uhci_hub_status_data(struct usb_hcd *hcd, char *buf)//buf里保存的是端口状态
- {
- struct uhci_hcd *uhci = hcd_to_uhci(hcd);
- unsigned long flags;
- int status = 0;
- spin_lock_irqsave(&uhci->lock, flags);
- uhci_scan_schedule(uhci);
- if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags) || uhci->dead)
- goto done;
- uhci_check_ports(uhci);
- status = get_hub_status_data(uhci, buf);
- switch (uhci->rh_state) {
- case UHCI_RH_SUSPENDING:
- case UHCI_RH_SUSPENDED:
- /* if port change, ask to be resumed */
- if (status)
- usb_hcd_resume_root_hub(hcd);
- break;
- case UHCI_RH_AUTO_STOPPED:
- /* if port change, auto start */
- if (status)
- wakeup_rh(uhci);
- break;
- case UHCI_RH_RUNNING:
- /* are any devices attached? */
- if (!any_ports_active(uhci)) {
- uhci->rh_state = UHCI_RH_RUNNING_NODEVS;
- uhci->auto_stop_time = jiffies + HZ;
- }
- break;
- case UHCI_RH_RUNNING_NODEVS:
- /* auto-stop if nothing connected for 1 second */
- if (any_ports_active(uhci))
- uhci->rh_state = UHCI_RH_RUNNING;
- else if (time_after_eq(jiffies, uhci->auto_stop_time))
- suspend_rh(uhci, UHCI_RH_AUTO_STOPPED);
- break;
- default:
- break;
- }
- done:
- spin_unlock_irqrestore(&uhci->lock, flags);
- return status;
- }
主要是执行get_hub_status_data获得hub的状态,然后根据uhci即主控制器状态来分别执行,if (!any_ports_active(uhci)) 判断是否端口有变化,有就返回>0的值,就会填充中断urb,然后调用usb_hcd_giveback_urb返回到hub_irq
Hub_irq里就调用kick_khubd(hub);然后就唤醒hub_thread,就调用hub_event
在hub_event里就会看是哪一种唤醒,如果是设备插拔就会调用hub_port_connect_change
hub_port_connect_change太长就不表了,大家可以去看源码
大概是hub_port_debounce去抖动后,就会进行设备枚举,下面分析下设备枚举的过程。
设备枚举:
对于linux的策略是很符合usb协议的,但是发现厂家很多不符合,所以这些产品在linux下用不了,但是奇怪的事是在windows下能用,后来发现是windows策略不一样,它是一次性收64字节,而linux只收8字节(可参考《Linux那些事儿之我是HUB》)
一般先是采用新策略再用旧策略
先收一次设备描述符得到bMaxPacketSize(新旧策略),然后复位一次设备,设置地址hub_set_address,再重新获得一次设备描述符usb_get_device_descriptor,
然后调用usb_new_device,再调用usb_configure_device
注意一点:
struct usb_host_interface,事实上这个interface描述符,就是设置描述符,这个描述符的其中一项叫做bInterfaceNumber,指的就是这个设置是属于哪个接口。比如一个接口包含2个设置,那么就会有2个interface描述符,两个描述符里的bInterfaceNumber设置都为0,但是第一个设置的bAlternateSetting为0, 第二个设置的bAlternateSetting为1。这样就区分开来了。
设备的字符描述符,是采用unicode里的UTF-16表示的,而且是little-endpoint,两个字节表示一个字符。获得的字符串是NULL-terminated的字符串,即没有结束符的
主控制器获得配置描述符时,设备是将配置、接口、端点和一些特殊描述符一起返回,所以要先发一次,然后在配置描述符里找到wTotalLength,再申请一个大的缓冲区来保存所有接回来的数据
usb_configure_device这个函数是很长的,因为发送USB_DT_CONFIG命令,设备会一次性把设备将返回的是除了配置描述符以外,与这种配置相关的接口描述符,以及与这些接口相关的端点描述符,还有一些class的描述符,都会一次性返回,所以拿到后还要解码,就是一些usb_parse_configuration之类的,就不分析了,假设也成功获得所有描述符,就会返回usb_new_device调用device_add就会进入usb_devcie_match的设备那个分支。就会调用generic_probe就会调用usb_choose_configuration选择配置,usb_set_configuration设备配置,然后usb_set_configuration又会注册接口设备,又会再进入usb_device_match,但这次走的是接口的分支,就会先匹配ID table然后调用对应的接口驱动的probe函数,到此就完成了设备的插入初始化以及关联接口驱动的过程。
下面弄个图理一理:
这里,大家看得好像理所当然,但是有一个问题,就是初始化后怎么工作?
我要传输
四大传输:
控制传输(control)
中断传输(int)
等时传输(ISO)
批量传输(bulk)
其中usb spec里说的四种传输就是所说的,但是要注意hub只有两种,一种是中断传输,一种是控制传输(这个好像有点废,因为所以的usb设备都是要支持控制传输的)。
而一般的设备会支持控制传输跟其他三种里的一种或者更多。
对于设备通信的话,linux主要是用了urb的传输,其地位非常高,相当于网卡驱动里的socket。
首先是先struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)
然后是static inline void usb_fill_xxx_urb, 这里的xxx是表示不同类型的传输有不同的函数调用,但是等时传输是没有对应接口函数的,所以要手动一个个元素去赋值。
管道的创建也有对应函数
这几个函数参数都有点不一样,主要是处理的流程不同。其中相同的urb就是要传的urb,pipe是对应端点的管道,transfer_buffer就是传输的缓冲区,setup_packet是控制传输里传输的数据,usb_complete_t complete_fn就是回调函数,context是上下文变量的保存,有时用来保存completion。
批量传输
static inline void usb_fill_bulk_urb(struct urb *urb,
struct usb_device *dev,
unsigned int pipe,
void *transfer_buffer,
int buffer_length,
usb_complete_t complete_fn,
void *context)
usb_sndbulkpipe(dev,endpoint)
usb_rcvbulkpipe(dev,endpoint)
控制传输
static inline void usb_fill_control_urb(struct urb *urb,
struct usb_device *dev,
unsigned int pipe,
unsigned char *setup_packet,
void *transfer_buffer,
int buffer_length,
usb_complete_t complete_fn,
void *context)
usb_sndctrlpipe(dev,endpoint)
usb_rcvctrlpipe(dev,endpoint)
中断传输
static inline void usb_fill_int_urb(struct urb *urb,
struct usb_device *dev,
unsigned int pipe,
void *transfer_buffer,
int buffer_length,
usb_complete_t complete_fn,
void *context,
int interval)
usb_sndintpipe(dev,endpoint)
usb_rcvintpipe(dev,endpoint)
对于上面几种传输,内核还提供了别一种接口“于控制/批量/中断传输,实际上很多时候你可以不用创建 urb,不用对它初始化,不用调用 usb_submit_urb 来提交,core 将这个过程分别封装了usb_control_msgusb_bulk_msg 和 usb_interrupt_msg 这三个函数里,不同的是它们的实现是同步的,会去等待传输的完全结束。”引用自《Linux那些事儿之我是USB Core》然后对应的urb就会传输到对应主控制器里,主控制器就会跟设备进行交流。具体的话是跟主控制器类型有关的,像uhci就是采用了frame list机制,就会有QH TD这样的概念。还要说明一点,一般UHCI主机控制器本身通常是 PCI设备,即通常它会插在 PCI插槽里,或者直接就集成在主板上,不同的控制器会有不同的要求,这就要看控制器的类型了。
还有一点要说明的就是这个usb设备驱动,一般我们编写就只是编写usb interface driver即一个接口对应一个驱动。但是在接口驱动里面,又会用到其他内核子系统,例如usb触摸屏就会用到输入子系统驱动框架,所以说具体还是要具体分析接口驱动,这里的usb主框架基本是定了的,只是内容可能有点不一样。