emitrax's blog

Coding Style

Blog post by emitrax on Wed, 2007-05-30 11:13
,

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.

UHCI Driver

Blog post by emitrax on Sun, 2007-04-29 22:10
, ,

After reading the main part of the USB specs, I moved on to the UHCI driver specs this week-end. I can now say, that implementing the isochronous part to the UHCI driver is a lot easier than I thought, and I guess Micheal can confirm. While reading the UHCI specs I followed Micheal's code, and I have some questions about it, but I'll write him an email for that. By the way, is R1 intended only for x86?

I just wanted to _announce_, that my gsoc project will probably change to adding USB OHCI full support, as the former would take less than a whole summer. I obviously already talked to both my mentor Oliver and Micheal about it. If it's ok with him though, I'd like to add isochronous support to the UHCI driver first. By the way, how does it work with patches and commits? Shall I just commit my changes to the svn or shall I first provide a patch so that someone can review it before it goes into the svn?

Anyway, I'm looking for some USB driver written in kernel space to see how drivers communicate with the bus_manager. I'm also looking for some USBKit documentation, even though I found some code like the FinePix driver, and the usb_dev_info command line that use it.

I guess it's all for now.

Stay tuned ;-)

Keep browsing

Blog post by emitrax on Wed, 2007-04-18 17:33
, ,

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,

Browsing the USB Stack code

Blog post by emitrax on Fri, 2007-04-13 21:49
, ,

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)
{
...
Syndicate content