On Wed, Jan 07, 2015 at 10:33:29AM -0500, Alan Stern wrote: > On Wed, 7 Jan 2015, vichy wrote: > > > I attach usbmon for your reference. > > But keyboard is still not working on runtime suspend. > > The usbmon trace resembles what I got during a test some time ago. I > don't remember the details; the problem was related to the fact that > the keyboard had two HID interfaces. One of them was suspending okay > but the other one wasn't, and that prevented the entire keyboard from > going into runtime suspend. The same thing is happening to you. > > The problem turned out to be something like the LED settings. Does the > keyboard go into runtime suspend if you turn off all the LEDs (Caps > Lock, Num Lock, and so on)? Or if you turn on the "ignoreled" module > parameter for usbhid? > > An illuminated LED requires more current than a suspended device is > allowed to draw from the USB bus. Therefore a bus-powered keyboard > cannot be put into runtime suspend if any of its LEDs is turned on. > > > >> 3. for host part, runtime suspend/resume is only doing port > > >> suspend/resume or both host and port going to suspend/resume? > > > > > > Only the port. However, when _all_ the devices attached to the host > > > controlluer go into runtime suspend, the controller itself will also be > > > put into runtime suspend. > > Would you mind to show me where the program determine controller go > > into runtime suspend if all devices on it go to suspend? > > That is handled by the runtime PM core. Look for the comment line: > > /* Maybe the parent is now able to suspend. */ > > in rpm_suspend() in drivers/base/power/runtime.c. > > > BTW > > a. if even controller suspended, does that mean all devices on it will > > be disconnect and re-enumerated when resume? > > No. When the controller resumes, the devices should still be connected > to it. > > > b. is there any usb sysfs file can let us suspend specific port on > > root or normal hub? > > No, there's only the .../power/control file. > > Alan Stern I may met both of your problems before. 1. For USB mouse auto disconnect issue It is caused by mouse itself, the Microsoft and Logitech mouse may have this issue, the dell mouse has no this issue. Two reasons together cause this problem - Special mouse which will disconnect (pulldown dm) if there is no host IN token within limited time (60s has observed at one microsoft mouse) - The rootfs has not opened mouse, it causes the host does not send IN token to mouse, if rootfs has opened mouse (eg, some gnome application or using 'evtest' to open mouse ), it will send IN token every 8ms. 2. For USB keyboard issue usbhid->ledcount has some problems, need to set ignoreled=1 to let auto-suspend work -- Best Regards, Peter Chen -- 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
