On Thu, Jan 29, 2009 at 03:12:07PM +0100, Oliver Neukum wrote: > Am Wednesday 28 January 2009 22:43:21 schrieb David Brownell: > > On Wednesday 28 January 2009, Alan Stern wrote: > > > I've been too busy to take part in this discussion (upgrading to > > > Fedora 10 was a disaster because the X server doesn't work on my > > > machine) -- there hasn't even been time enough in the last few > > > months to read through much of the USB 3.0 spec. So I have only a > > > few comments to add... > > > > Which is why I encouraged a high-level description of the issues > > first. I don't think many folk have had a chance to read it. > > Hi Sarah, > > OK, having read it seems to me that some changes to common APIs are > needed. I'll just list the issues in the order I've noticed them, not > ranked by impact. That is apart from the burst support. > > 1. warm and hot resets We now have two kinds of resets and need to add > a "warmth" parameter to usb_reset_device() I'm not sure if we do need a new parameter. ISTR that the hardware will automatically attempt a hot reset under certain conditions, and then try a warm reset if that fails. I think we should just always specify the hardware use the less intrusive, less time consuming reset (which I think is the "hot reset", I don't remember exactly). The only reason I advocated having an OS way to specify which reset was used was because I could imagine a situation where a USB device always expects to see a warm reset, and breaks when it sees a hot reset. So we should be able to let the hardware (hub, root port) decide which type of reset to use unless we find these quirky devices. > 3. Section 9.2.5.2 I read this as saying that the device is allowed to > forget almost all internal state when going into U3 (==suspend). > Sarah? I think they were trying to err on the side of caution for USB devices. The bus spec specifies the minimum amount of data the device must retain, but the class specs will require more state to be saved. So I don't think we will see USB 3.0 devices completely lose all their internal state on device suspend. > 4. U1/U2 handling We have 3 depths of sleep compared to the binary > suspend/active distinction. U1/2 affects only the link, not the > device. They can be initiated both by the device and the host(hub) There is an extension to USB 2.0 that adds these link states, without the automatic management of link state transitions by USB hubs. So there could be USB 2.0 devices that implement these states, but I haven't seen or heard of them yet. > If we want to use this we need some support: > - We need to make sure the additional latency does not conflict with > periodic transfers > - We need timeout values for all interfaces. From this we should > compute the longest timeout, or if a driver forbids U1/U2 disable them Yes. The OS needs to sum all the exit latencies for hubs between the USB device and the rootport, and set the parent hub U1/U2 timers based on that. > - IMHO the default value should be $FF that is we allow devices to > initiate U1/2 but don't propose to enter it ourselves, unless periodic > transfers require U1/2 be disabled I think the OS still has to tell the device the exit latency for the tree above it, but I don't remember exactly. In any case, if we leave it up to the USB devices, they probably won't initiate link PM at first either. > - This might be hooked into latency/power user space interfaces Such as /sys/bus/usb/devices/../power/ ? I suppose we could let the user adjust the U1/U2 timeouts (keeping a lower bound of the exit latency of the tree, of course). Maybe something similar to the current /sys/bus/usb/devices/../power/autosuspend file? > 2. remote wakeup operates on the function level > We need to have true functions that request/release remote wakeup with > counters per function that request/release remote wakeup immediately. Yes, we will move to a per-function remote wake up counter. A legacy USB device could be represented as having one "function" that requests remote wakeup. > 5. Functions Section 9.6.4 USB 3.0 introduces functions as an > additional level between device and interfaces. In fact section 9.6.4 > can be read as recommending function level drivers in addition to > interface level drivers. Sarah, how do you read this? If you think about current USB devices, there are might several different interfaces that describe one function of a USB device. Like a USB video device that has many interfaces to describe different bandwidth requirements. I would think that all those interfaces would be handled by one USB video driver. So perhaps we need an extension of the claim_interface function that claims all interfaces described by an IAD? > As some functionality in powermanagement resides in functions, > we need to have a kernel representation of them. Particularily > we need to register which interfaces belong to a function and > autosuspend must be trained to go at functions. > That means interface association descriptors must be evaluated. Yes, they will need to be evaulated and stored some where, maybe in the struct usb_device? 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
