usblog

USB on OLS2005

Fri, 20 May 2005 04:05:43 GMT

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

A change in Linux Kernel USB api - 2.6.12 kernel

Thu, 17 Mar 2005 14:55:45 GMT

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

LDD3 is out ! (a sample chapter on USB is available from Oreilly)

Thu, 10 Feb 2005 14:20:12 GMT

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

Pete Zaitcev's blog

Sun, 26 Dec 2004 16:27:02 GMT

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

USB subsystem 6

Thu, 23 Dec 2004 07:33:20 GMT

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

Video4linux

Mon, 06 Dec 2004 08:01:15 GMT

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

Usb (5): miscallnous USB topics

Tue, 30 Nov 2004 14:58:01 GMT

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

khubd thread and plugging/unplugging a usb device.

Mon, 29 Nov 2004 14:12:36 GMT

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

USB (3) : Tasklets and deferred work in a video driver

Sun, 21 Nov 2004 10:54:55 GMT

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

Linux USB SubSystem (2)

Wed, 17 Nov 2004 08:38:28 GMT

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

Linux USB SubSystem (1)

Tue, 16 Nov 2004 14:12:53 GMT

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