On Tue, Jan 27, 2009 at 02:00:06PM -0800, David Brownell wrote: > On Tuesday 27 January 2009, Sarah Sharp wrote: > > On Mon, Jan 26, 2009 at 03:13:31PM -0800, David Brownell wrote: > > > > 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. > > > > > > So users would need to handle more than the usual number of > > > function-level reset/reinitialize events? Currently those > > > events are rare ... and only stateless devices/drivers manage > > > to avoid presenting them to users. > > > > I'm not sure what you mean by "users". Gadget drivers? > > I mean people ... who are trying to use the USB device for > whatever, and would probably believe you if you said there > was a specification for USB (but wouldn't read it). > > > > > 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. > > Does this only apply to a sub-tree that's being newly > connected? > > You said earlier that it applies to the whole tree. > As in, the whole tree re-enumerates whenever you > plug in one more device... Sorry about that confusion. I was talking about the whole tree enumerating on system power on, before the OS host controller got involved at all. A new USB 3.0 device being plugged into an existing tree does not cause the rest of the tree to re-enumerate. If a new device is plugged in, the OS gets a port status change for that device from its parent hub, after the hub link trains and resets the device. The parent hub is unaffected by the connection (or at least as unaffected as a USB 2.0 hub). Two devices plugged in at the same time will be enumerated by their parent hub (or hubs) in parallel. The OS then receives two port status changes and has two USB 3.0 devices sitting at address 0. This causes all kinds of interesting new issues. > Re "why they wanted that" -- faster boot time is > a win for everyone, and needing device-at-a-time > reset sequences for USB is a measurable slowdown. The beauty of this parallel training is that if a user has a large tree of devices plugged in at start up, they only incur the linking training and reset wait time once, instead of multiple times per level of the USB tree structure. > > > > 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? > > > > > > Any reason they shouldn't be treated just like a standard > > > reset event? Including re-initializing from scratch, based > > > on what the host tells them to do. > > > > Why reset them again? I have code that just skips the device reset when > > the host controller driver reports a connect on a USB 3.0 port. > > I didn't say "again". You did say they were at address 0, > which means they all got some kind of reset. If that's > only for "new" devices, no problem; but you said it applies > to the whole tree (which includes devices that were already > enumerated, in other branches; not just the new branch). The reset by the hub before the OS port status change is only for new devices, so there's no need for the OS to reset them again. > > The real reason the parallel link training went it was because Microsoft > > really wanted a fast boot from a USB hard drive deep in the device tree. > > Why they wanted that is a mystery to me, but they pushed very hard for > > it. I don't see any reason not to take advantage of that change, unless > > we find devices that don't work because of that. I hope we don't. > > I suspect you elided some important details, like > what you meant by "tree" maybe being more like just > a new branch not the whole tree. > > > > > > > That could affect the hub and HCD interfaces. What > > > > > (if anything) will interface and function drivers > > > > > need to understand differently? > > > > I didn't need to change the HCD interfaces at all. I did need to change > > khubd code to not reset the USB 3.0 device. The code seems to be working on > > the prototype USB 3.0 device I have. (Having more prototypes to test on > > would be wonderful too.) > > Especially ones that can implement arbitrary Linux-USB gadgets. ;) Oh yes, that would be nice. ;) > > > > Of course these changes discussed don't even cover the new link power > > > > management and function suspend for USB 3.0 devices. > > > > > > My quick glance suggests that "function suspend" may be a > > > misnomer, since it's an *interface* feature flag ... while > > > functions are not limited to single interfaces. > > > > "Function" is an officially defined term now. A USB device function is > > all the interfaces described by an interface association descriptor. So > > a function can include multiple interfaces. > > I suppose using an IAD was necessary, especially if the > OS equivalent of "usbcore" wasn't going to understand > things like CDC Union descriptors, and less-standard > analogues. > > > > The idea was to suspend pieces of the USB device while keeping the > > device as a whole functional. The OS might want to ask the USB printer > > gadget to power down its scanner interfaces if no device driver has > > claimed those interfaces. If all device drivers unclaimed all > > interfaces of a USB device, then the host OS should put the device into > > the selective suspend state (U3) as it does now. (Putting all the > > functions into function suspend does not automatically put the device > > into U3.) > > > > So there probably needs to be gadget interfaces similar to what it does > > for selective (device) suspend. > > Wouldn't it suffice to guarantee that the interfaces > receive the set_feature request for function suspend, > using the existing setup() mechanism? I haven't poked around that code, so I'll take your word for it until I look into it. 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
