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) 大量數據的不可靠傳輸,不保證數據的到達,但保證恆定的數據流,多用於數據採集。 Linux中用struct usb_host_endpoint來描述USB端點,每個usb_host_endpoint中包含一個struct usb_endpoint_descriptor結構體,當中包含該端點的信息以及設備自定義的各種信息,這些信息包括: bEndpointAddress(b for byte) 8位端點地址,其地址還隱藏了端點方向的信息(之前說過,端點是單向的),可以用掩碼USB_DIR_OUT和USB_DIR_IN來確定。 bmAttributes 端點的類型,結合USB_ENDPOINT_XFERTYPE_MASK可以確定端點是USB_ENDPOINT_XFER_ISOC(等時)、USB_ENDPOINT_XFER_BULK(批量)還是USB_ENDPOINT_XFER_INT(中斷)。 wMaxPacketSize 端點一次處理的最大字節數。發送的BULK包可以大於這個數值,但會被分割傳送。 bInterval 如果端點是中斷類型,該值是端點的間隔設置,以毫秒爲單位。 在邏輯上,一個USB設備的功能劃分是通過接口來完成的。比如說一個USB揚聲器,可能會包括有兩個接口:一個用於鍵盤控制,另外一個用於音頻流傳輸。而事實上,這種設備需要用到不同的兩個驅動程序來操作,一個控制鍵盤,一個控制音頻流。但也有例外,比如藍牙設備,要求有兩個接口,第一用於ACL跟EVENT的傳輸,另外一個用於SCO鏈路,但兩者通過一個驅動控制。在Linux上,接口使用struct usb_interface來描述,以下是該結構體中比較重要的字段: struct usb_host_interface *altsetting(注意不是usb_interface) 其實據我理解,他應該是每個接口的設置,雖然名字上有點奇怪。該字段是一個設置的數組(一個接口可以有多個設置),每個usb_host_interface都包含一套由struct usb_host_endpoint定義的端點配置。但這些配置次序是不定的。 unsigned num_altstting 可選設置的數量,即altsetting所指數組的元素個數。 struct usb_host_interface *cur_altsetting 當前活動的設置,指向altsetting數組中的一個。 int minor 當捆綁到該接口的USB驅動程序使用USB主設備號時,USB core分配的次設備號。僅在成功調用usb_register_dev之後纔有效。 除了它可以用struct usb_host_config來描述之外,到現在爲止,我對配置的瞭解不多。而整個USB設備則可以用struct usb_device來描述,但基本上只會用它來初始化函數的接口,真正用到的應該是我們之前所提到的自定義的一個結構體。 Linux USB驅動框架分析(二) 好,瞭解過USB一些規範細節之後,我們現在來看看Linux的驅動框架。事實上,Linux的設備驅動,特別是這種hotplug的USB設備驅動,會被編譯成模塊,然後在需要時掛在到內核。要寫一個Linux的模塊並不複雜,以一個helloworld爲例: #include <linux/init.h> #include <linux/module.h> MODULE_LICENSE(“GPL”); static int hello_init(void) { printk(KERN_ALERT “Hello World!\n”); return 0; } static int hello_exit(void) { printk(KERN_ALERT “GOODBYE!\n”); } module_init(hello_init); module_exit(hello_exit); 這個簡單的程序告訴大家應該怎麼寫一個模塊,MODULE_LICENSE告訴內核該模塊的版權信息,很多情況下,用GPL或者BSD,或者兩個,因爲一個私有模塊一般很難得到社區的幫助。module_init和module_exit用於向內核註冊模塊的初始化函數和模塊推出函數。如程序所示,初始化函數是hello_init,而退出函數是hello_exit。 另外,要編譯一個模塊通常還需要用到內核源碼樹中的makefile,所以模塊的Makefile可以寫成: ifneq ($(KERNELRELEASE),) obj-m:= hello.o#usb-dongle.o else KDIR:= /usr/src/linux-headers-$(shell uname -r) BDIR:= $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules .PHONY: clean clean: make -C $(KDIR) M=$(BDIR) clean endif 可以用insmod跟rmmod來驗證模塊的掛在跟卸載,但必須用root的身份登陸命令行,用普通用戶加su或者sudo在Ubuntu上的測試是不行的。 Linux USB驅動框架分析(三) 下面分析一下usb-skeleton的源碼。這個範例程序可以在linux-2.6.17/drivers/usb下找到,其他版本的內核程序源碼可能有所不同,但相差不大。大家可以先找到源碼看一看,先有個整體印象。 之前已經提到,模塊先要向內核註冊初始化跟銷燬函數: static int __init usb_skel_init(void) { int result; /* register this driver with the USB subsystem */ result = usb_register(&skel_driver); if (result) err("usb_register failed. Error number %d", result); return result; } static void __exit usb_skel_exit(void) { /* deregister this driver with the USB subsystem */ usb_deregister(&skel_driver); } module_init (usb_skel_init); module_exit (usb_skel_exit); MODULE_LICENSE("GPL"); 從代碼開來,這個init跟exit函數的作用只是用來註冊驅動程序,這個描述驅動程序的結構體是系統定義的標準結構struct usb_driver,註冊和註銷的方法很簡單,usb_register(struct *usb_driver), usb_deregister(struct *usb_driver)。那這個結構體需要做些什麼呢?他要向系統提供幾個函數入口,跟驅動的名字: static struct usb_driver skel_driver = { .name = "skeleton", .probe = skel_probe, .disconnect = skel_disconnect, .id_table = skel_table, }; 從代碼看來,usb_driver需要初始化四個東西:模塊的名字skeleton,probe函數skel_probe,disconnect函數skel_disconnect,以及id_table。 在解釋skel_driver各個成員之前,我們先來看看另外一個結構體。這個結構體的名字有開發人員自定義,它描述的是該驅動擁有的所有資源及狀態: 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_skel作個簡單分析,他擁有一個描述usb設備的結構體udev,一個接口interface,用於併發訪問控制的semaphore(信號量) limit_sem,用於接收數據的緩衝bulk_in_buffer及其尺寸bulk_in_size,然後是批量輸入輸出端口地址bulk_in_endpointAddr、bulk_out_endpointAddr,最後是一個內核使用的引用計數器。他們的作用我們將在後面的代碼中看到。 我們再回過頭來看看skel_driver。 name用來告訴內核模塊的名字是什麼,這個註冊之後有系統來使用,跟我們關係不大。 id_table用來告訴內核該模塊支持的設備。usb子系統通過設備的production ID和vendor ID的組合或者設備的class、subclass跟protocol的組合來識別設備,並調用相關的驅動程序作處理。我們可以看看這個id_table到底是什麼東西: /* Define these values to match your devices */ #define USB_SKEL_VENDOR_ID 0xfff0 #define USB_SKEL_PRODUCT_ID 0xfff0 /* table of devices that work with this driver */ static struct usb_device_id skel_table [] = { { USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID) }, { } /* Terminating entry */ }; MODULE_DEVICE_TABLE (usb, skel_table); MODULE_DEVICE_TABLE的第一個參數是設備的類型,如果是USB設備,那自然是usb(如果是PCI設備,那將是pci,這兩個子系統用同一個宏來註冊所支持的設備。這涉及PCI設備的驅動了,在此先不深究)。後面一個參數是設備表,這個設備表的最後一個元素是空的,用於標識結束。代碼定義了USB_SKEL_VENDOR_ID是0xfff0,USB_SKEL_PRODUCT_ID是0xfff0,也就是說,當有一個設備接到集線器時,usb子系統就會檢查這個設備的vendor ID和product ID,如果它們的值是0xfff0時,那麼子系統就會調用這個skeleton模塊作爲設備的驅動。 Linux USB驅動框架分析(四) probe是usb子系統自動調用的一個函數,有USB設備接到硬件集線器時,usb子系統會根據production ID和vendor ID的組合或者設備的class、subclass跟protocol的組合來識別設備調用相應驅動程序的probe(探測)函數,對於skeleton來說,就是skel_probe。系統會傳遞給探測函數一個usb_interface *跟一個struct usb_device_id *作爲參數。他們分別是該USB設備的接口描述(一般會是該設備的第0號接口,該接口的默認設置也是第0號設置)跟它的設備ID描述(包括Vendor ID、Production ID等)。probe函數比較長,我們分段來分析這個函數: dev->udev = usb_get_dev(interface_to_usbdev(interface)); dev->interface = interface; 在初始化了一些資源之後,可以看到第一個關鍵的函數調用——interface_to_usbdev。他同uo一個usb_interface來得到該接口所在設備的設備描述結構。本來,要得到一個usb_device只要用interface_to_usbdev就夠了,但因爲要增加對該usb_device的引用計數,我們應該在做一個usb_get_dev的操作,來增加引用計數,並在釋放設備時用usb_put_dev來減少引用計數。這裏要解釋的是,該引用計數值是對該usb_device的計數,並不是對本模塊的計數,本模塊的計數要由kref來維護。所以,probe一開始就有初始化kref。事實上,kref_init操作不單隻初始化kref,還將其置設成1。所以在出錯處理代碼中有kref_put,它把kref的計數減1,如果kref計數已經爲0,那麼kref會被釋放。kref_put的第二個參數是一個函數指針,指向一個清理函數。注意,該指針不能爲空,或者kfree。該函數會在最後一個對kref的引用釋放時被調用(如果我的理解不準確,請指正)。下面是內核源碼中的一段註釋及代碼: /** * kref_put - decrement refcount for object. * @kref: object. * @release: pointer to the function that will clean up the object when the * last reference to the object is released. * This pointer is required, and it is not acceptable to pass kfree * in as this function. * * Decrement the refcount, and if 0, call release(). * Return 1 if the object was removed, otherwise return 0. Beware, if this * function returns 0, you still can not count on the kref from remaining in * memory. Only use the return value if you want to see if the kref is now * gone, not present. */ int kref_put(struct kref *kref, void (*release)(struct kref *kref)) { WARN_ON(release == NULL); WARN_ON(release == (void (*)(struct kref *))kfree); /* * if current count is one, we are the last user and can release object * right now, avoiding an atomic operation on 'refcount' */ if ((atomic_read(&kref->refcount) == 1) || (atomic_dec_and_test(&kref->refcount))) { release(kref); return 1; } return 0; } 當我們執行打開操作時,我們要增加kref的計數,我們可以用kref_get,來完成。所有對struct kref的操作都有內核代碼確保其原子性。 得到了該usb_device之後,我們要對我們自定義的usb_skel各個狀態跟資源作初始化。這部分工作的任務主要是向usb_skel註冊該usb設備的端點。這裏可能要補充以下一些關於usb_interface_descriptor的知識,但因爲內核源碼對該結構體的註釋不多,所以只能靠個人猜測。在一個usb_host_interface結構裏面有一個usb_interface_descriptor叫做desc的成員,他應該是用於描述該interface的一些屬性,其中bNumEndpoints是一個8位(b for byte)的數字,他代表了該接口的端點數。probe然後遍歷所有的端點,檢查他們的類型跟方向,註冊到usb_skel中。 /* set up the endpoint information */ /* use only the first bulk-in and bulk-out endpoints */ iface_desc = interface->cur_altsetting; for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; if ( !dev->bulk_in_endpointAddr && ((endpoint->bEndpointAddress & USB_ENDPOINT_DIR_MASK) = = USB_DIR_IN) && ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) = = USB_ENDPOINT_XFER_BULK)) { /* we found a bulk in endpoint */ buffer_size = le16_to_cpu(endpoint->wMaxPacketSize); dev->bulk_in_size = buffer_size; dev->bulk_in_endpointAddr = endpoint->bEndpointAddress; dev->bulk_in_buffer = kmalloc(buffer_size, GFP_KERNEL); if (!dev->bulk_in_buffer) { err("Could not allocate bulk_in_buffer"); goto error; } } if (!dev->bulk_out_endpointAddr && ((endpoint->bEndpointAddress & USB_ENDPOINT_DIR_MASK)= =USB_DIR_OUT) && ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK)= = USB_ENDPOINT_XFER_BULK)) { /* we found a bulk out endpoint */ dev->bulk_out_endpointAddr = endpoint->bEndpointAddress; } } if (!(dev->bulk_in_endpointAddr && dev->bulk_out_endpointAddr)) { err("Could not find both bulk-in and bulk-out endpoints"); goto error; } Linux USB驅動框架分析(五) 接下來的工作是向系統註冊一些以後會用的的信息。首先我們來說明一下usb_set_intfdata(),他向內核註冊一個data,這個data的結構可以是任意的,這段程序向內核註冊了一個usb_skel結構,就是我們剛剛看到的被初始化的那個,這個data可以在以後用usb_get_intfdata來得到。 usb_set_intfdata(interface, dev); retval = usb_register_dev(interface, &skel_class); 然後我們向這個interface註冊一個skel_class結構。這個結構又是什麼?我們就來看看這到底是個什麼東西: static struct usb_class_driver skel_class = { .name = "skel%d", .fops = &skel_fops, .minor_base = USB_SKEL_MINOR_BASE, }; 它其實是一個系統定義的結構,裏面包含了一名字、一個文件操作結構體還有一個次設備號的基準值。事實上它纔是定義 真正完成對設備IO操作的函數。所以他的核心內容應該是skel_fops。這裏補充一些我個人的估計:因爲usb設備可以有多個interface,每個interface所定義的IO操作可能不一樣,所以向系統註冊的usb_class_driver要求註冊到某一個interface,而不是device,因此,usb_register_dev的第一個參數纔是interface,而第二個參數就是某一個usb_class_driver。通常情況下,linux系統用主設備號來識別某類設備的驅動程序,用次設備號管理識別具體的設備,驅動程序可以依照次設備號來區分不同的設備,所以,這裏的次設備好其實是用來管理不同的interface的,但由於這個範例只有一個interface,在代碼上無法求證這個猜想。 static struct file_operations skel_fops = { .owner = THIS_MODULE, .read = skel_read, .write = skel_write, .open = skel_open, .release = skel_release, }; 這個文件操作結構中定義了對設備的讀寫、打開、釋放(USB設備通常使用這個術語release)。他們都是函數指針,分別指向skel_read、skel_write、skel_open、skel_release這四個函數,這四個函數應該有開發人員自己實現。 當設備被拔出集線器時,usb子系統會自動地調用disconnect,他做的事情不多,最重要的是註銷class_driver(交還次設備號)和interface的data: dev = usb_get_intfdata(interface); usb_set_intfdata(interface, NULL); /* give back our minor */ usb_deregister_dev(interface, &skel_class); 然後他會用kref_put(&dev->kref, skel_delete)進行清理,kref_put的細節參見前文。 到目前爲止,我們已經分析完usb子系統要求的各個主要操作,下一部分我們在討論一下對USB設備的IO操作。 Linux USB驅動框架分析(六) 說到usb子系統的IO操作,不得不說usb request block,簡稱urb。事實上,可以打一個這樣的比喻,usb總線就像一條高速公路,貨物、人流之類的可以看成是系統與設備交互的數據,而urb就可以看成是汽車。在一開始對USB規範細節的介紹,我們就說過USB的endpoint有4種不同類型,也就是說能在這條高速公路上流動的數據就有四種。但是這對汽車是沒有要求的,所以urb可以運載四種數據,不過你要先告訴司機你要運什麼,目的地是什麼。我們現在就看看struct urb的具體內容。它的內容很多,爲了不讓我的理解誤導各位,大家最好還是看一看內核源碼的註釋,具體內容參見源碼樹下include/linux/usb.h。 在這裏我們重點介紹程序中出現的幾個關鍵字段: struct usb_device *dev urb所發送的目標設備。 unsigned int pipe 一個管道號碼,該管道記錄了目標設備的端點以及管道的類型。每個管道只有一種類型和一個方向,它與他的目標設備的端點相對應,我們可以通過以下幾個函數來獲得管道號並設置管道類型: unsigned int usb_sndctrlpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一個控制OUT端點。 unsigned int usb_rcvctrlpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一個控制IN端點。 unsigned int usb_sndbulkpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一個批量OUT端點。 unsigned int usb_rcvbulkpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一個批量OUT端點。 unsigned int usb_sndintpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一箇中斷OUT端點。 unsigned int usb_rcvintpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一箇中斷OUT端點。 unsigned int usb_sndisocpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一個等時OUT端點。 unsigned int usb_rcvisocpipe(struct usb_device *dev, unsigned int endpoint) 把指定USB設備的指定端點設置爲一個等時OUT端點。 unsigned int transfer_flags 當不使用DMA時,應該transfer_flags |= URB_NO_TRANSFER_DMA_MAP(按照代碼的理解,希望沒有錯)。 int status 當一個urb把數據送到設備時,這個urb會由系統返回給驅動程序,並調用驅動程序的urb完成回調函數處理。這時,status記錄了這次數據傳輸的有關狀態,例如傳送成功與否。成功的話會是0。 要能夠運貨當然首先要有車,所以第一步當然要創建urb: struct urb *usb_alloc_urb(int isoc_packets, int mem_flags); 第一個參數是等時包的數量,如果不是乘載等時包,應該爲0,第二個參數與kmalloc的標誌相同。 要釋放一個urb可以用: void usb_free_urb(struct urb *urb); 要承載數據,還要告訴司機目的地信息跟要運的貨物,對於不同的數據,系統提供了不同的函數,對於中斷urb,我們用 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, void *context, int interval); 這裏要解釋一下,transfer_buffer是一個要送/收的數據的緩衝,buffer_length是它的長度,complete是urb完成回調函數的入口,context由用戶定義,可能會在回調函數中使用的數據,interval就是urb被調度的間隔。 對於批量urb和控制urb,我們用: 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, void *context); void usb_fill_bulk_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,void *context); 控制包有一個特殊參數setup_packet,它指向即將被髮送到端點的設置數據報的數據。 對於等時urb,系統沒有專門的fill函數,只能對各urb字段顯示賦值。 有了汽車,有了司機,下一步就是要開始運貨了,我們可以用下面的函數來提交urb int usb_submit_urb(struct urb *urb, int mem_flags); mem_flags有幾種:GFP_ATOMIC、GFP_NOIO、GFP_KERNEL,通常在中斷上下文環境我們會用GFP_ATOMIC。 當我們的卡車運貨之後,系統會把它調回來,並調用urb完成回調函數,並把這輛車作爲函數傳遞給驅動程序。我們應該在回調函數裏面檢查status字段,以確定數據的成功傳輸與否。下面是用urb來傳送數據的細節。 /* initialize the urb properly */ usb_fill_bulk_urb(urb, dev->udev, usb_sndbulkpipe(dev->udev, dev->bulk_out_endpointAddr), buf, writesize, skel_write_bulk_callback, dev); urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP; /* send the data out the bulk port */ retval = usb_submit_urb(urb, GFP_KERNEL); 這裏skel_write_bulk_callback就是一個完成回調函數,而他做的主要事情就是檢查數據傳輸狀態和釋放urb: dev = (struct usb_skel *)urb->context; /* sync/async unlink faults aren't errors */ if (urb->status && !(urb->status = = -ENOENT || urb->status == -ECONNRESET || urb->status = = -ESHUTDOWN)) { dbg("%s - nonzero write bulk status received: %d", __FUNCTION__, urb->status); } /* free up our allocated buffer */ usb_buffer_free(urb->dev, urb->transfer_buffer_length, urb->transfer_buffer, urb->transfer_dma); 事實上,如果數據的量不大,那麼可以不一定用卡車來運貨,系統還提供了一種不用urb的傳輸方式,而usb-skeleton的讀操作正是採用這種方式實現: /* do a blocking bulk read to get data from the device */ retval = usb_bulk_msg(dev->udev, usb_rcvbulkpipe(dev->udev, dev->bulk_in_endpointAddr), dev->bulk_in_buffer, min(dev->bulk_in_size, count), &bytes_read, 10000); /* if the read was successful, copy the data to userspace */ if (!retval) { if (copy_to_user(buffer, dev->bulk_in_buffer, bytes_read)) retval = -EFAULT; else retval = bytes_read; } 程序使用了usb_bulk_msg來傳送數據,它的原型如下: int usb_bulk_msg(struct usb_device *usb_dev, unsigned int pipe,void *data, int len, int *actual length, int timeout) 這個函數會阻塞等待數據傳輸完成或者等到超時,data是輸入/輸出緩衝,len是它的大小,actual length是實際傳送的數據大小,timeout是阻塞超時。 對於控制數據,系統提供了另外一個函數,他的原型是: Int usb_contrl_msg(struct usb_device *dev, unsigned int pipe, __u8 request, __u8 requesttype, __u16 value, __u16 index, void *data, __u16 size, int timeout); request是控制消息的USB請求值、requesttype是控制消息的USB請求類型,value是控制消息的USB消息值,index是控制消息的USB消息索引。具體是什麼,暫時不是很清楚,希望大家提供說明。 至此,Linux下的USB驅動框架分析基本完成了。 總結USB設備的驅動過程爲: USB設備連接到主機時,usb子系統會根據production ID和vendor ID的組合或者設備的class、subclass跟protocol的組合(也就是根據id_table)來識別設備,並調用相應驅動程序的probe(探測)函數。 usb_skeleton程序正是採用PID與VID來識別對應的USB設備,當有設備連接時,系統識別其PID與VID找出符合id_table的USB驅動模塊,而USB驅動模塊中定義了次設備號#define USB_SKEL_MINOR_BASE 192 主設備號爲180 然後根據其主次設備號尋找對應的設備文件,這就將設備文件與USB設備連接起來。 由於skeleton程序中定義了 #define USB_SKEL_VENDOR_ID 0xfff0 //製造商ID 而我使用的USB設備的PID VID不同所以修改其值爲 #define USB_SKEL_VENDOR_ID 0xabcd //製造商ID 重新編譯加載,插入USB設備。 ./test write ok!code = 0; read ok!code = 0; 能夠進行正常讀寫,當然skeleton只是骨架程序,並沒有其他操作,所以接上USB設備無反映是正常的. 驅動架構: |
Linux USB驅動框架分析
2009-05-21 16:47
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.