On Mon, Sep 24, 2012 at 11:07 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> > It doesn't matter. Here's the scenario: > > New device is plugged in. > The hub wakes up. > The hub driver tries to initialize the new device and fails. > The device disconnects itself from the USB bus. > The hub is autosuspended after 0 seconds. > 1 second later the device reconnects itself to the USB bus. > The hub wakes up. > The hub driver initializes the new device successfully. > > This can happen for any type of newly connected device. Yes, it is the case in which the patch may introduce one extra suspend/resume on hub. The device might be a buggy one, or one just for firmware downloading, and the time taken to reconnect may be more than 2 seconds too, :-). So the case is not a general one, we can eliminate the effect by setting an appropriate autosuspend delay for its parent device in the probe() if someone requires. > > Unlike the usbhid driver, the hub driver does not rely on the > autosuspend delay to provide enough time to handle a wakeup event. It > uses the PM usage counter to avoid autosuspending until the event has > been fully processed. Setting the autosuspend delay to 0 won't cause > the hub driver to stop working correctly. > > (BTW, if anyone wanted to do it, the usbhid driver could be changed so > that it too would work correctly with 0 delay. I don't see any reason > for doing this, however.) IMO, it might be not doable because the pressed key for remote wakeup may be lost by the HID device, and holding the PM counter will never put the device in suspend state. Looks it is very common on my USB mouse, the 1st button pressed is only for remote wakeup and always not obtained by driver when the device is in suspend. > >> > You are ignoring the energy required to make the transition between the >> > active and suspended states, >> >> The current(Ct) during transition can't go above the hub's downstream port >> limit >> (100mA or 500mA) per '7.2.1' of USB 2.0 spec, and suppose the below: >> >> - the transition from active to suspend current is Cw > > You mean Ct here. > >> - the working(active state) current is Cw >> - the transition time is Tt( <= 10ms, per '7.1.7.6 Suspending') > > You have to add in the transition time for resuming. > >> - the suspend time is Ts(suppose 2900ms) > > Suppose 50 ms. > >> - the suspend current is Cs(2.5mA) >> - suppose VBUS voltage(V) not change >> >> So the extra energy consumed during the transition is that E1 = V*(Ct-Cw)*Tt, >> and the saved energy during suspend period is E2 = V*(Cw-Cs)*Ts. We can >> easily get that E1 < E2 suppose Cw = 1/3 Ct or less. > > Nevertheless, there is a cutoff point. If Ts is too small then E1 > > E2. The autosuspend delay shouldn't be much smaller than this cutoff > value for Ts (_how_ much smaller depends on how likely it is that a > resume will be required shortly after a suspend). > >> > Why do you think we have an autosuspend delay in the first place? Why >> > not always use a delay of 0 for every device? >> >> See the above USB HID example. > > No, that's not it at all. The real reason is performance (i.e., speed > of operation). If we had to resume a device before every I/O operation > and suspend it afterward, performance would be terrible. Not only on performance, and correctness thing may be involved, still see above HID example, :-) > > We try to mitigate this problem by avoiding autosuspends in situations > where we think an I/O operation is likely to occur in the near future. > Since the computer can't predict the future accurately, all we can do > is assume that an I/O operation is more likely to occur if one just > finished. That's the real reason for not suspending immediately after > each operation. > > To justify an autosuspend delay of 0 seconds, you have to demonstrate > why this argument doesn't apply. In the case of hubs, there are three > types of operations to consider: > > 1: USB traffic to/from a child device, > > 2: I/O requests from usbfs or sysfs, > > 3: Port change events (mostly connects and disconnects). > > For type 1, the hub's autosuspend delay doesn't matter. The hub can't > suspend as long as the child is active, so the child's own autosuspend > delay will prevent the hub from suspending too soon. > > Type 2 is probably too infrequent to worry about. The lsusb example is > one of the few places it crops up in reality. > > Type 3 is the one that matters most. Here the general reasoning says > that just after a connect or disconnect event, a new event is more > likely to occur. Except for the situation I outlined above > (initializing a buggy device), this is not true. Thus the general > argument doesn't apply, so the only lower limit on autosuspend delays > for hubs is the power requirement discussed above. > > _That_ is what you should explain in the comments. But try to make it > shorter than what I wrote. :-) OK, will do it. > >> > Remember that devices can be bound to usbfs as well as to their regular >> > drivers. usbfs does not support suspend/resume. >> >> usbfs always wake up device first in the open(), then the device can be >> accessed, so keeping the autosuspend delay as zero can't cause problem >> for the case, can it? > > No, it doesn't cause problems -- it only causes unnecessary > suspend/resume cycles sometimes. I see the patch of 'usbfs: Add a new disconnect-and-claim ioctl (v2)' is introduced recently, which may avoid the unnecessary suspend/resume cycle for the case. IMO, it should be reasonable to set the device's autosuspend delay as zero when its driver is unbound because no one can predict when the device will be bound to a new driver. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
