On Mon, 24 Sep 2012, Ming Lei wrote: > On Mon, Sep 24, 2012 at 12:51 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, 23 Sep 2012, Ming Lei wrote: > > > >> > In fact, sometimes new connected device _does_ mean there will be > >> > another new connection in the next few seconds. This happens because > >> > >> Looks I should have made it clearer, and I mean the physical device > >> connection or disconnection, eg, device plugging and unplugging. > > > > What difference does it make whether the connection was caused by > > manipulating a physical plug or by electrical signalling? The end > > result is the same. > > > >> > some devices have trouble initializing when they are first plugged in. > >> > They disconnect themselves from the bus and then reconnect a second or > >> > so later. > >> > >> First, the situation should be less like to happen. > >> > >> Secondly, the patch may only affect the case when the new > >> connected device is a hub. > > > > No, it can happen with any device. > > The patch just changes the hub's autosuspend delay as 0, so > the default 2 sec delay of other device won't make the hub > suspend immediately. 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. > If you change usb hid device's autosuspend delay as 0, you will > find the mouse can't work basically. > > The driver may not know when the URB for receiving data will > complete, and increasing the PM counter under the situation may not > let the device suspend. And changing the autosuspend delay as > 0 will kill the URB immediately which is not completed, so > it doesn't work. Ah, okay, now I get it. You're right, this is an important point. I would express it differently: 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.) > > 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. 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. :-) > > 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. Alan Stern -- 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
