usb

Just to keep those of you interested updated, after discussing it with both my mentor and Michael Lotz, and after a very quick chat with Francois Revol, I am going to add isochronous support to both the USBKit and usb_raw driver. Meanwhile Francois, if time is on his side, should add isochronous support to his user space quickcam driver (see src/add-ons/media/media-add-ons/usb_webcam/). This way I can test my previous patches and perhaps everyone can start using his logitech quickcam with Haiku by using codycam. I don't know though for sure, what product id are supported.

As many of you know, I've started working even before the SoC started officially. I've already sent two patches to both my mentor (Oliver R. Dorantes) and Michael Lotz for review. One of them has already been commited by mmu_man (thanks). The second one is under review. With this latest one, the usb stack manager should be complete, as the QueueIsochronous method has been implemented, along with the CalculateBandwidth. My next move is to implement the UHCI isochronous method. Once I've done that, testing can be made. As for now, there seem to be a lack of drivers with which I can test the code. Oliver has offered himself to write some simple bluetooth driver just to test the code. Isochronous UHCI Tester are obviously welcome.

Mainly in the second half of the last year the Haiku USB stack has matured a great deal. Not only has it stabilized a bit, it has also seen the addition of an EHCI driver to support USB 2.0 devices. A rewritten UHCI driver and a new implementation of the USBKit library are other steps to a complete stack.

I've been reading some more code and I'm getting more confident with it.

Basically data transfer is done with memcpy.

In the ehci controller, registers are mapped every time a controller is found. This is done in the controller constructor.

As the ehci specs says:
Register Space. Implementation-specific parameters and capabilities, plus operational control and
status registers. This space, normally referred to as I/O space, must be implemented as memory-mapped
I/O space.

So...

EHCI::EHCI(pci_info *info, Stack *stack)
...
 // map the registers
 fRegisterArea = map_physical_memory("EHCI memory mapped registers",
                (void *)physicalAddress, mapSize, B_ANY_KERNEL_BLOCK_ADDRESS,  

I said it already, but I'm going to say it a million of times, I've never EVER would expected to work on such a project for the Google Summer of Code, I actually didn't even think I would get in the soc. But anyway, here I am... so let's begin!

Last night after I got bored reading the Kernel Kit section of the Be Book (it was about threads and related functions), I opened my shell and I dived right into the USB stack code.

I tried to follow some functions with ctags, because I was interested about how the actual data is sent to the device, and here is what I found out.

This is the method used to send data to the device.
GetBusManager()->SubmitTransfer(transfer);

EHCI driver status...

status_t      
EHCI::SubmitTransfer(Transfer *transfer)
{
...  

Quick Updates

19900-20000

• Introduction of USBKit reimplementation
• Interesting local message passing optimisations
• VMWare vmdk tools
  • vmdk image generator
  • vmdk jam target: haiku-vmware-image

Quick Updates

r19800-r19900

• Beginnings of AHCI support
• Hardware cache flush for SCSI
• Stability fixes for the USB stack
• Port of the following filesystems
  • GoogleFS
  • NFS
  • NTFS