On Mon, Jan 26, 2009 at 12:40:41PM +0530, viral.mehta@xxxxxxxxxxxxxx wrote: > > Hi, > I am also supposed to work on the same area i.e., Linux gadget side driver > compliant with USB 3.0 stack. > I would also like to be part of the conversation. However, you are keeping this > conversation offline and I do not know whether I can be a part of that or not. Ok, let's get everyone involved on the linux-usb list then. :) It seems that Synopsis, Info Chips, STN Wireless, and some of the Intel ultra-mobile device engineers are interested in developing Linux gadget-side USB 3.0 support. Let's figure out what needs to be added or changed to support Linux gadget-side USB 3.0. On Sun, Jan 25, 2009 at 12:57:55PM -0800, David Brownell wrote: > On Friday 23 January 2009, Kawshol Devilal SHARMA wrote: > > Thanks I appreciate your response, I will start getting things > > together. Please let me know how you would like to address this. > > Start with a rough description of what needs to change, > then work up to proposals. So, I know what needs to change for to support USB 3.0 on the host-side, but I'm not familiar with the gadget side of things. > Example, changes to <linux/usb/ch9.h> will cover both > host and peripheral sides of the stack; mostly new or > updated descriptors, but presumably also updating the > device speed enumeration. That would likely go well > as a single early patch. One new thing for USB 3.0 devices is the requirement for an endpoint companion descriptor after every endpoint. You can see what sort of information is in that descriptor by looking at section 9.6.7 of the USB 3.0 bus spec. I have a patch to add the structure to include/linux/usb/ch9.h and parse that descriptor on the host side. Would the gadget size need more than that? There's also a new Binary Object Store descriptor required for USB 3.0 devices (section 9.6.2.2). I don't have any patches that deal with descriptor yet. David Vrabel said the wireless USB stack has some code to parse the BOS descriptor. The new SuperSpeed USB Device Capability BOS descriptor structure would still need to be added to include/linux/usb/ch9.h. > The basic design problem here will be converting what > comes out of the spec development process -- likely a > "formats and protocols" level spec -- into updates for > the Linux-USB stack. Is enumeration affected? How? There are enumeration changes for USB 3.0 devices, but I think much of it is taken care of by the PHY. One interesting thing to note is that USB 3.0 devices in a tree structure are reset and link trained in parallel by the PHY. By the time the OS receives the port status change notification, all USB 3.0 devices below that root port are all at address 0. So there is no need for the OS to reset them. The OS addresses USB 3.0 devices by using a route string (you can see an example of this in section 10.1.3.2 of the USB 3.0 bus spec). I have host-side code that modifies the host-side enumeration sequence to take care of this. I'm not sure how much new gadget side support is needed. Ideas? > That could affect the hub and HCD interfaces. What > (if anything) will interface and function drivers > need to understand differently? There is a new hub descriptor for USB 3.0, new requests, and new state machines for devices. I worked around these requirements by pretending the xHCI USB 3.0 root hubs had a USB 2.0 descriptor with the speed changed. So the xHCI driver won't work with external hubs yet. I think there will need to be some changes made to khubd, but I haven't looked at the hub state machines in a while. With the USB 3.0 bus spec, they tried to get rid of the polling of interrupt endpoints. If a device doesn't have data, it can respond with a NRDY (not ready) packet. The host will then wait for the device to send a ERDY (endpoint ready) packet before communicating with that endpoint again. There will be some gadget-side changes necessary for this. I think the host-side changes are all taken care of in the hardware, but I would have to check on that. > Stuff that percolates into usbcore deserves some > discussion; ditto stuff affecting how e.g. composite > gadgets get assembled. Of course these changes discussed don't even cover the new link power management and function suspend for USB 3.0 devices. Those will both be a requirement for USB 3.0 device compliance, but we can discuss those after we have an idea of the changes necessary for basic USB 3.0 gadget-side support. Can anyone think of any other changes for USB 3.0 gadget side support? 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
