On Tue, 6 Jan 2015, vichy wrote: > >> But I cannot see the keyboard go to suspend even I force autosuspend as 0. > >> is there any other way to trigger runtime suspend immediately instead > >> of waiting kernel judge it is idle for a while? > > > > There may be other reasons why the keyboard does not get suspended. > > For example, it may not support remote wakeup. What does "lsusb -v" > > show? And what does usbmon show? > here is the output of lsusb and usbmon will be attach soon. > BTW, > 1. is there any other method to trigger runtime suspend instead of > waiting device to be idle. > such as echo xxx > xxxx, and it will directly call runtime > suspend related function No, there isn't. > 2. why remote wake up feature of hid is related to runtime suspend? > runtime suspend is kernel use to saving power and suspend/resume > actively, right? That's true. But it wouldn't work very well if the keyboard went into runtime suspend and stayed that way even when you tried to type on it! If a keyboard doesn't support remote wakeup then we must not put it into runtime suspend. However, I see from the lsusb output that your keyboard _does_ support remote wakeup, so that isn't the reason. > 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. 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
