UHCI/OHCI driver and device driver

[tonytian]

Newbie's questions.

I am looking at USB implementations. After reading some articles/documents, I found myself confused in understanding the interaction between host controller driver and device driver. How do these drivers actually work? I know how to find host controllers and control them through mapped IOmem using PCI configuration space. But what about the device? How does a device driver talk to the device and communicate with host controller's driver?

[tonytian]

It looks like host controller is the one that talks to an actual device by sending/receiving packets to/from the device. A device driver is the one that knows how to control a device or interpret the data a device sends. Can somebody confirm this? Thanks.

Newbie's questions.

I am looking at USB implementations. After reading some articles/documents, I found myself confused in understanding the interaction between host controller driver and device driver. How do these drivers actually work? I know how to find host controllers and control them through mapped IOmem using PCI configuration space. But what about the device? How does a device driver talk to the device and communicate with host controller's driver?

[bewing]

To use just about any packetizing system, you need to set up your OS so that you can create special things called "driver stacks". This usually applies to TCP/IP, USB, Firewire, etc. A driver stack basically means that you are able to pipleline drivers together. So the output from one driver is used as input to the next driver ... then that output goes into a third driver, etc. A USB stack has a device driver for a device (for example, a floppy). It creates SCSI commands for the drive, and then sends those commands to a host driver. The host driver encapsulates those SCSI commands into a packet, and then sends the packet out on the USB bus. The drive on the bus receives the packet, unpacketizes it, performs the SCSI command inside, and generates a return info packet. The host driver unpacketizes the return info, and passes it back to the floppy driver.

There are many ways to create a driver stack, and how you do it will make a big difference in your overall OS design.

[tonytian]

I see. It is much clearer to me now. That means the interrupt handler should be implemented in my host driver, right?

To use just about any packetizing system, you need to set up your OS so that you can create special things called "driver stacks". This usually applies to TCP/IP, USB, Firewire, etc. A driver stack basically means that you are able to pipleline drivers together. So the output from one driver is used as input to the next driver ... then that output goes into a third driver, etc. A USB stack has a device driver for a device (for example, a floppy). It creates SCSI commands for the drive, and then sends those commands to a host driver. The host driver encapsulates those SCSI commands into a packet, and then sends the packet out on the USB bus. The drive on the bus receives the packet, unpacketizes it, performs the SCSI command inside, and generates a return info packet. The host driver unpacketizes the return info, and passes it back to the floppy driver.

There are many ways to create a driver stack, and how you do it will make a big difference in your overall OS design.

[TomT]

I have a simple usb driver for the flash drive, UHCI and EHCI.
It does not use interrupts but polls for the controller to do its thing.
The code does not really use a stack.
A more advanced driver would implement both of these concepts.

My usb controller runs like a wild horse contantly checking its registers.

To begin a transaction with UHCI or EHCI I do a write like this:

;to begin transaction for uhci attach td to 2nd dword of queue head
mov dword [0x1005100+4],0xd60000

;to begin transaction for ehci attach td to 5th dword of queue head
mov dword [0x1005300+16],0xd60000


The controller holds the address of the starting queue head.
When it sees a valid TD address it starts doing its thing.
Read up on the usb docs for an understanding of a queue head and transfer descriptor.
These are structures in memory that your usb controller will read and act on.
You will first build a single link list of transfer descriptors (TD's) in memory that instruct the controller to give or receive bytes of data.
These TD's hold pointers to memory buffers and other instructions.

TomT
http://code.google.com/p/tatos/
source code is included
see /docs for a list of downloadable usb reference info

[tonytian]

Thank you for the info. I will look into it.

I have a simple usb driver for the flash drive, UHCI and EHCI.
It does not use interrupts but polls for the controller to do its thing.
The code does not really use a stack.
A more advanced driver would implement both of these concepts.

My usb controller runs like a wild horse contantly checking its registers.

To begin a transaction with UHCI or EHCI I do a write like this:

;to begin transaction for uhci attach td to 2nd dword of queue head
mov dword [0x1005100+4],0xd60000

;to begin transaction for ehci attach td to 5th dword of queue head
mov dword [0x1005300+16],0xd60000


The controller holds the address of the starting queue head.
When it sees a valid TD address it starts doing its thing.
Read up on the usb docs for an understanding of a queue head and transfer descriptor.
These are structures in memory that your usb controller will read and act on.
You will first build a single link list of transfer descriptors (TD's) in memory that instruct the controller to give or receive bytes of data.
These TD's hold pointers to memory buffers and other instructions.

TomT
http://code.google.com/p/tatos/
source code is included
see /docs for a list of downloadable usb reference info