On Mon, Dec 29, 2008 at 12:18:46PM +0530, viral.vkm@xxxxxxxxx wrote: > All, > I am very excited with the announcement of USB 3.0 in last november. > When I was going through the spec, certainly it is very promising and > looks like USB 3.0 will rock soon. > > At the same time, I am very sure that Linux kernel will need lots of > modifications in USB core code. Yes, the Linux USB core will need some changes for USB 3.0. I have some patches for these changes that I haven't cleaned up yet. (I'm also still working on some legal red tape before I can post them; I have to get an OK by some higher-ups who are still on vacation.) There are several basic changes for USB 3.0 that need to go in: 1. We need to add a new speed for USB devices (i.e. USB_SPEED_SUPER) and looking for case statements that fall back to full speed as the default speed. I have a partial patch for this. 2. USB 3.0 devices have a new "Endpoint Companion Descriptor". This specifies some new characteristics for each USB 3.0 endpoint. For example, the EP companion descriptor specifies how many "bursts" of the maximum packet size a bulk endpoint can receive before it must wait for an explicit acknowledgment of the first packet. The host controller driver needs to use the info from the EP companion descriptor, so the descriptor needs to be parsed and stored in the struct usb_host_endpoint. I have a patch for that. > For example, very basic change will be in "struct > usb_endpoint_descriptor", it will now need to keept track of one or > more OUT transactions which are not ACKed yet. > Grepping the supporting statement for above change from USB 3.0 spec "A > superspeed host may initiate one or more OUT transactions to one or more > endpoints while it waits for the completion of current bus transaction" Low-level bus transactions don't need to be tracked in software; that's the host controller hardware's job. I can't get into the details without talking about specific host controller implementations. The xHCI spec isn't published yet, unfortunately. :( > I will be happy to see if someone carries the discussion further... There are more complex changes that will need to happen for USB 3.0 devices to work. I really don't want to overwhelm anyone by talking about all the changes I've been thinking about for the past year, so I'll just talk about one for now. The enumeration sequence for USB 3.0 devices has changed. The USB folks wanted to support a fast boot from USB devices, so they changed the enumeration sequence to support parallel training of USB 3.0 links. On power-on and USB 3.0 termination detection, every USB 3.0 link in the tree is reset and link trained in parallel. By the time the OS is notified of the connect change by a root hub or external hub, the device has already been reset and is sitting at address 0. (They can get away with having multiple devices at address 0 because USB 3.0 packets are routed over the USB 3.0 wires. The route string specifies a destination port on each hub in the tree, with the hub being addressed by port 0. See section 10.1.3.2.) The OS may choose to treat all device connections the same, and reset the USB 3.0 device. However, it would be more efficient for the OS to skip an initial reset for USB 3.0 devices. I have a patch for this, although it still needs some more love and thought. There are several areas that I haven't started working on. External USB 3.0 hub support is one of those areas. USB 3.0 hubs have a new state machine and a new hub status/port change format. The khubd code needs to be changed, and I haven't even started on that. My current tree only works for xHCI roothubs, and it pretends that they're just USB 2.0 hubs by reusing the USB 2.0 roothub descriptor (struct ehci_hub_descriptor). I hope someone who knows that code well can help out with the khubd changes. Well, I suppose I had better go back to working on the legal requirements to release my USB 3.0 patches. Legal stuff is just so much less fun than coding. ;) Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
