Below are the 11 most recent journal entries recorded in usblog's LiveJournal:

Friday, May 20th, 2005
7:11 am	USB on OLS2005 Hello, Pete Zaitcev from Red Hat, Inc., will talk about "The usbmon: USB monitoring framework" in OLS 2005 see http://www.linuxsymposium.org/2005/speakers.php?types=TALK Cheers, RRX (Comment on this)
Thursday, March 17th, 2005
4:58 pm	A change in Linux Kernel USB api - 2.6.12 kernel Hello, Haven't post a blog here for a while; Sorry ; there was some pressure at work. There is a little change in Linux Kernel USB api from 2.6.12 kernel. In 2 USB methods: usb_bulk_msg() and usb_control_msg(), The timeout parameter value is changed to milliseconds. (It was in jiffies in prior kernels). Notice that the timeout is in both cases an int, so the compiler will not shout if you are using usb drivers which were not fixed according to this change. What will happen if you **DO** try to use such an unpatched drivers ? well , maybe you can tell me? Cheers, USBLOG (Comment on this)
Thursday, February 10th, 2005
4:19 pm	LDD3 is out ! (a sample chapter on USB is available from Oreilly) LDD3 is out ! Hello, LDD3 is out ! A big day is today ; the LDD3 (Linux Device Drivers , 3r edition) is publised and can be bought at Amazon and other online stores. I had ordered it from Amazon; see http://www.amazon.com/exec/obidos/ASIN/0596005903/ref%3Dnosim/oreillycom-20/002-8086181-9156864 I cannot wait till this 636 pages book will come ; there is a free sample chapter (chapter 13) about USB which can be downloaded from http://www.oreilly.com/catalog/linuxdrive3 I am reading it now; interesting (I assume Greg KH wrote it ? ) Cheers, USBLOG (Comment on this)
Sunday, December 26th, 2004
6:24 pm	Pete Zaitcev's blog Hello, You might find the follwoing blog (of Pete Zaitcev) interesting ; many posts deals with USB: http://www.livejournal.com/users/zaitcev/ Special interest I found in a posting from December 20th, 2004 about a usbmon utility he wrote see also: http://lkml.org/lkml/2004/12/20/40 Cheers, USBLOG (2 Comments |Comment on this)
Thursday, December 23rd, 2004
9:32 am	USB subsystem 6 USB subsystem 6 - USB Mass Storage Driver for Linux Hello, I had some pressure in work so it had been a while since last post. Sorry about this. I will try to post more often in the near future. This driver is for mass storage usb devices, like USB disks and USB DiskOnKeys, with which I will dill here.All what is below is relevant to DiskOnKey (but I assume also USB disks behave more or less the same). First , for mounting diskonkey you should run (after creating a mounting point, let's say /mnt/dok): mount /dev/sda /mnt/dok (Note that when we mount an IDE disk it is ususally /dev/hda1 or /dev/hda2 and so on; there are /dev/sda1 till /dev/sda15 special device files; but this is not so impotant). The code for USB Mass Storage Driver resides, naturally, under drivers/usb/storage . The module name is usb-storage.ko ; it uses SCSI emulation ; we will deal SCSI emulation in the future. The us_data structure (from storage/usb.h) is probably the most important struct in storage mass storage. The protocol we use is Transparent SCSI The transport layer is : Bulk (corresponds to US_PR_BULK in usb/transport.h). The use of SCSI emulation appears also in ATAPI devices like CD-RW devices. It is a good question why we use this emulation at all. Why not use IDE interface ? I wonder what is the reason (It does not seems to me related to the fact that IDE disks are not hot plugged while USB disk can be hot plugged. ) The usb_stor_control_thread() is a daemon thread which controls the usb device. It adds the PF_NOFREEZE flag to the current process. Aside from in this module, use of PF_NOFREEZE is only in 2 other places under drivers: in block/loop.c: loop_thread(void *data) in scsi/scsi_error.c: scsi_error_handler(void *data) The use of PF_NOFREEZE flag is for Swsusp : Software Suspend for Linux (the Linux equivalent of Windows' hibernate). see http://softwaresuspend.berlios.de/ You can see a little on USB Mass Storage Driver for Linux in http://www2.one-eyed-alien.net/~mdharm/linux-usb/ but take in account that this site was last updated in July 2002. Cheers, USBLOG (Comment on this)
Monday, December 6th, 2004
10:01 am	Video4linux Hello, As duke_igthorn noted in his blog, in http://www.livejournal.com/users/usblog/506.html, "With all due respect, combining USB and V4L into one blog does not seem reasonable." I agree with him. In any case, I had posted some introductory blog on Video4Linux and Video Apps ; it is in http://www.livejournal.com/users/rrx/15216.html in case anyone is interested. I decided not to post it (and subsequent Video4Linux blogs) here. I will only mention it in this blog when some vide4linux is posted in RRX blog (which will not be often), since it may be of interest to some of you. Cheers, USBLOG (Comment on this)
Tuesday, November 30th, 2004
4:56 pm	Usb (5): miscallnous USB topics Usb (5): miscallnous USB topics Hello, 1) I got an answer, in usb-devel-group, to my question regarding the benefits in hardware of OHCI against UHCI (Intel Host Controller) The question was . to remind you: "In drivers/usb/host/Kconfig, (linux 2.6.7) they say: "The Open Host Controller Interface (OHCI) is a standard for accessing USB 1.1 host controller hardware. It does more in hardware than Intel's UHCI specification." What does ot do more in hardware than Intel's UHCI specification ?" And the answe I got from David Brownell was: "One example: sending a 4 KB buffer takes one TD with OHCI, covering 64+ packets; with UHCI, each packet takes one TD. Another: OHCI has separate schedules for control, bulk, and periodic transfers. UHCI has just one." 2) USB tools: While working with USB subsystem, I found the following tools helpful: 1) USBVIEW: A GTK+ 1.2-based tool written by Greg Kroach Hartman. see http://www.kroah.com/linux-usb/ Enables you to see the cahracteristics of the USB devices. This tool displays the topography of the devices that are plugged into the USB bus on a Linux machine. while plugging and unplugging the USB device, this display is updated and refreshed in real time. The source code is available. 2) http://usbsnoop.sourceforge.net This is somekind of a USB sniffer; runs only on Windows. I also encountered a Project of some student from Scotland who began developinh a Java based USB sniffer , but it seem to me that he abondoned it. 3) Interesting USB links: The GNU/Linux "usbnet" Driver - David Brownell on http://www.linux-usb.org/usbnet libusb on http://libusb.sourceforge.net The libusb project aim is to create a library for use by user level applications to access USB devices regardless of OS. There is an article in linuxjournal by Greg Kroach Hartman (02/11/2004) in which he demonstrates use of the libusb: see http://www.linuxjournal.com/article/7795 Cheers, RRX (Comment on this)
Monday, November 29th, 2004
4:12 pm	khubd thread and plugging/unplugging a usb device. Hello, Usb (4): khubd thread and plugging/unplugging a usb device. The following text will describe, in short, what happens in the khubd thread when we plug and unplug a usb device. Khubd is a daemon thread. After its creation we call daemonize(), and the daemonize() blocks all signals (see daemonize implementation in /kernel/exit.c) . We want to be able to send a kill signal (SIGKILL) when cleaning up, so we enable this by calling allow_signal(SIGKILL) immediately after it creation. In fact, the only place where we send this signal is usb_hub_cleanup() (in hub.c) ; and there are only 2 places where there are calls to this methods in the kernel : one is in usb_init() , which is called when we load usbcore, and when we do not succeed in hub initialization ; and the second is in usb_exit() , when we unload the usbcore module. (Both are in core/usb.c). (More on what is usbcore is at the end of this post). Usually , when you'll run ps -aux and look at the khubd process, you will see that it is in a state of sleeping (denoted by the letter 'S'). drivers/usb/core/hub.c is part of usbcore. Until recently there was a (little) bug (and maybe there still is?) in http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg30070.html Andrew Morton says: "I made the mistake of forgetting to unmount the fat filesystem before unplugging the USB cable from the digital camera. I then tried to unmount the old mountpoint. khubd is sitting there chewing 100% CPU and I have a reboot in my near future." And James Bottomley says Mike Christie had fixed it and the fix will soon be integrated. see: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110061842631005&w=2 Plugging a USB device: When we plug in a usb device (like a USB webcam) into the USB port, the hardware initiates an interrupt; we reach the hub_irq() method. the hub data (struct usb_hub) is passed to the hub_irq() method as part of the urb (the context member of struct urb). There is a global list of hub events(called hub_event_list); if this list is empty we add event to this list, so that the khubd thread will handle it. We also call wake_up(&khubd_wait); since the khubd is in a waiting status. Waking up causes us to call hub_events(). We also reach the host controller irq (for example, I am working with ohci and I reach ohci_irq() ) (More on it in the future). We delete the hub from the event list in hub_events(). (The hub driver writers admit that restarting the list every time to avoid a deadlock with deleting hubs downstream from this current hub is bot the most efficient , but it's safe). Unplugging a USB device: When we unplug a USB device (like a webcam) out from it USB port, the process described earlier is repeated until we reach hub_events(); there we call hub_port_connect_change() method (implemented in hub.c). The second parameter of this method is the port number, So this method disconnect any existing devices under this port, by calling usb_disconnect(); usb_disconnect(struct usb_device **pdev) is also a usbcore method ,implementation usb.c. The usb_disconnect() calls usb_disable_device() which disable all the endpoints for a USB device. It also removes that USB device endpoints from under /proc/bus/usb/devices by calling usbfs_remove_device(dev); NOTE: hub_disconnect() is NOT called in this process !! hub_disconnect() is called when we perform rmmod ohci_hcd , when working with ohci, for example. It is also called in the probing process (in boot); more specifically,hub_probe() calls hub_disconnect() as it's last step,before returning. And finally,in short, what is usbcore composed of? The 9 mandatory ingredients of the USBCORE are: usb.c,hub.c,hcd.c, urb.c, message.c ,config.c, file.c, buffer.c and sysfs.c. If , when configuring th kernel , you set CONFIG_USB_DEVICEFS to y, add 3 to it: devio.c inode.c and devices.c. (the inode.c implements the usbfs ; it has a call to register_filesystem of the usbfs file system). Note: The entries under /sys/usb/usb/drivers/hub are NOT removed when REMOVED after unplugging a device. They are removed , for example , after rmmod ohci_hcd. ( assuming that you work with ohci_hcd .) More on it in the future. This text is based on 2.67 kernel. Cheers, USBLOG (3 Comments |Comment on this)
Sunday, November 21st, 2004
12:54 pm	USB (3) : Tasklets and deferred work in a video driver Hello, I came to know today with a new driver,SPCA. SPCA driver is a LINUX USB webcam driver. see http://spca50x.sourceforge.net/spca50x.php According to the web site, it supports 77 types of WebCams see http://spca50x.sourceforge.net/spca50x.php?page=cams I had tested it on a camera not from the list, and it was OK. This is the *FIRST* Linux USB webcam driver I know which uses tasklets (deferred execution,bottom handlers). It's interesting why a use of tasklets was done here. Grepping the "media" subtree of USB in the kernel for tasklets gives 0 results. (that media subtree is where the video drivers reside) For more info on takslets and deferring work see : 1) Tasklets and Bottom-Half Processing in Chapter 9 (Interrupt Handling of Linux Device Drivers) of Linux Device Drivers book. also online: http://www.xml.com/ldd/chapter/book/ch09.html 2) "Introduction to linux device drivers" (a lecture given by Mulix): http://www.mulix.org/lectures/intro_to_linux_device_drivers/intro_linux_device_drivers.pdf Tasklets or not, It still also uses completion handlers for urb messages. As you can see , this driver was based on Omnivision OV511 driver see http://mxhaard.free.fr/sview.html. However, ov5111.c does not contain tasklets. There are also tools for this driver (including a grabber and an SDL player) see SpcaView & SpcaTools Howto by Michel Xhaard in http://mxhaard.free.fr/sview.html. Cheers, USBLOG (1 Comment |Comment on this)
Wednesday, November 17th, 2004
10:37 am	Linux USB SubSystem (2) Hello, Linux USB SubSystem (2) -------------------------- The following text is based on 2.67 kernel. I assume that the current posting was better to be the first in the USB SubSystem series since it is better as an introduction. I apologize on that. The most important header files which define the USB interface are include/linux/usb.h and include/linux/usb_ch9.h. The header file called usb_ch9.h hold constants and structures for usb. The name came from chapter 9 of the USB 2.0 specification. There are 2 specs for USB: 2.0 and 1.1. We have USB 2.0 , which operates at "High Speed" : 60 Mbyte/sec (480 Mbit/sec) (40 times faster than USB full speed), and USB 1.1 ,which operates at "Full Speed" 12 Mbit/sec (1.5 MByte/sec) or - "Low Speed" 1.5 Mbit/sec The USB_SPEED_LOW,USB_SPEED_FULL, and USB_SPEED_HIGH (usb 2.0) are defined in usb_ch9.h. You'll encounter them in the USB sources (but not to much). When you connect High speed devices to USB 1.1 systems , they slow down to USB 1.1 speeds. The USB subsystem is based on message passing transactions. The messages are called URB. URB stands for USB Request Block. you send URBS by calling usb_submit_urb(struct urb *urb, int mem_flags); This is ans asynchronous calls; it returns immediately. The URB is put in a queue; later, it reaches a completion handler; the completion handler is a member of the URB structure , called complete (a pointer to a function). In the completion handler, you can check the urb->status for errors. You can cancel pending requests by using usb_unlink_urb(). URBs are allocated by calling usb_alloc_urb() ; they are freed with a call to usb_free_urb(). There are 3 helper method which help to fill URBs: usb_fill_control_urb() (control_urb) usb_fill_bulk_urb (bulk urb) usb_fill_int_urb (interrupt urb) More on completion handlers and submitting URBs in the future. There are 4 types of transfers: Control transfers , bulk transfers, interrupt transfers transfers, and High Speed Isochronous (ISO) transfer. Usually USB WebCams use ISO transfer. You can rarely find use of bulk transfers in USB WebCams. The URB struct resides in usb.h. Links: Maybe this link should be termed : the USB portal: http://www.linux-usb.org USeful Information about linux decvice drivers: http://www.qbik.ch/usb/devices http://www.usb.org mailing lists: linux-usb-users archive : http://marc.theaimsgroup.com/?l=linux-usb-users&r=1&w=2 linux-usb-develepoer archive: http://marc.theaimsgroup.com/?l=linux-usb-devel&r=1&w=2 USB Host Controlleres: ======================== In the kernel source tree (under /drivers/usb/host) , you will find 5 types of USB Host Controlleres: 1) ehci - for USB2.0. ehci stands for : Enhanced Host Controller Interface. 2) ohci - implements OpenHCI -- Open Host Controller Interface According to /usb/host/Kconfig ,"It does more in hardware than Intel's UHCI specification." TODO: find out more details (what exactly it does more). 3) uhci - Universal Host Controller Interface The Linux kernel maintainer of usb-uhci is Alan Stern It is originated from Intel: see http://developer.intel.com/technology/usb/uhci11d.htm Usually boards with Intel PCI chipsets use this standard. 4) sl811 host controller: manufactured by cypress. http://www.cypress.com/products/datasheet.cfm?partnum=SL811HS (has 256 bytes Internal SRAM buffer). 5)SA-1111 host controller: http://www.intel.com/design/pca/applicationsprocessors/1111_brf.htm You can find the drivers for theses controllers under /drivers/usb/host (sometimes they are referred to HCD = Host Controller Driver). You are welocamed to question/ask/remark eahtecer you think. Cheers, RRX (Comment on this)
Tuesday, November 16th, 2004
4:02 pm	Linux USB SubSystem (1) Hello, This blog is soleley dedicated for USB susbsystem and Video4Linux applications and drivers. The posting in this blog are taken from http://www.livejournal.com/users/rrx. (I am rrx and I an researching the Linux USB susbsystem with empasis on Video4Linux). I intend to add postings here regarding this issues quite soon. Stay tuned. These postings will appear here and also in http://www.livejournal.com/users/rrx. However , http://www.livejournal.com/users/rrx is a general blog , and it d deals also with other matters (mainly Linux programming,kernel,gcc, and other goodies). There are 2 reasons for that: 1) To dedicate one blog for this issue. 2) To ease finding it using search engines. I hope linux community will find this blog helpful and enjoy it. You are invited to comment / question / remark. the following post is from Sunday, November 14th, 2004: Linux USB SubSystem (1) : usb_init() The following text is based on 2.67 kernel. So what do we have in the usb initialization? Let's have a look at usb_init() in inode.c (/drivers/usb/core/usb.c): We call 6 initialization routines: only 3 of them are part of the sub subsystem. 1) bus_register(&usb_bus_type); The bus_register() method is not a part of the USB subsystem. It's a general bus method ; it's implementation is in /drivers/base/bus.c. 2)usb_host_init(); calls class_register(); again ,this is not a part of the USB subsystem. It's implementation is in /drivers/base/class.c 3)usb_major_init(); This calls register_chre_dev(); The MAJOR number of USB is 180. and also devfs_mk_dir("usb") and class_register(). All entries under /dev/usb have major number 180 (except /dev/ttyUSB* , which have major number 188). the call to class_register() is relatively new (It did not exist in 2.4 kernel). We should not be surprised; Greg Kroach Hartman, which is the maintainer of usb subsystem, is also deeply involved in the new device model (see for example his talk in OLS2004 kobjects and krefs - Lockless Reference Counting for Kernel Structure (http://www.kroah.com/linux/talks/ols_2004_kref_talk) 4) usbfs_init(); usually, in most distros , the usbfs (which is also called usbdevfs) , is mounted under /proc/bus. (Needless to say: This of course can be changed by issuing umount and then mount on a different mounting point,or changing /etc/fstab). This is a filesystem which resembles in some ways ordinary file systems like etxt3 or xfs; what I mean is that you call register_filesystem() (in /drivers/usb/core/inode.c) in order to register the filesystem. And you pass a pointer to file_system_type. The usbfs is responsible for creating and updating the devices file (/proc/bus/usb/devices). The devices file is updated dynamically; if you insert a webcam , (or any other USB device), and run cat /proc/bus/usb/devices , you will find that some configuration entries were added to the devices file.If you will remove the webcam and run cat /proc/bus/usb/devices, you will find that these devices were removed from the devices file. Creating the devices file is done, eventually,by calling regular filesystem methods (like d_instantiate() and dget () from dcache.c). More on it in the future. 5) usb_hub_init(): creates a kernel daemon thread named khubd. (implenentation in /drivers/usb/core/hub.c). The khubd thread is responsible for configuring devices. More on it in the future. 6) driver_register(); This method is again not a part of the USB subsystem. It's implementation is in /drivers/base/driver.c Cheers, USBLOG (2 Comments |Comment on this)