Linux USB架构浅谈-guolele

Linux USB架构浅谈-guolele
2011年05月18日
　　Linux USB架构浅谈-guolele
　　我要注册-主控制器与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_msg、usb_bulk_msg 和 usb_interrupt_msg 这三个函数里，不同的是
　　它们的实现是同步的，会去等待传输的完全结束。"引用自《Linux那些事儿之我是USB Core》
　　然后对应的urb就会传输到对应主控制器里，主控制器就会跟设备进行交流。具体的话是跟主控制器类型有关的，像uhci就是采用了frame list机制，就会有QH TD这样的概念。
　　还要说明一点，一般UHCI主机控制器本身通常是 PCI设备,即通常它会插在 PCI插槽里,或者直接就集成在主板上，不同的控制器会有不同的要求，这就要看控制器的类型了。
　　还有一点要说明的就是这个usb设备驱动，一般我们编写就只是编写usb interface driver即一个接口对应一个驱动。但是在接口驱动里面，又会用到其他内核子系统，例如usb触摸屏就会用到输入子系统驱动框架，所以说具体还是要具体分析接口驱动，这里的usb主框架基本是定了的，只是内容可能有点不一样。