Re: Difference between run time and normal suspend
hi Alan:
2015-01-19 0:49 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Sun, 18 Jan 2015, vichy wrote:
after tracing the source, I only can find the ehci_suspend is called
when system hibernate/suspend.
rpm_suspend use below method to find out suspend callback
if (dev-pm_domain)
callback = dev-pm_domain-ops.runtime_suspend;
else if (dev-type dev-type-pm)
callback = dev-type-pm-runtime_suspend;
else if (dev-class dev-class-pm)
callback = dev-class-pm-runtime_suspend;
else if (dev-bus dev-bus-pm)
callback = dev-bus-pm-runtime_suspend;
else
callback = NULL;
ehci_suspend doesn't register any one of above function.
ehci_pci_init() in ehci_pci.c stores ehci_suspend in
ehci_pci_hc_driver.pci_suspend. That pointer is called by
suspend_common() in hcd-pci.c, which is called by both
hcd_pci_suspend() and hcd_pci_runtime_suspend().
I have several questions:
a.
in ehci-pci driver, the runtime suspend is register in the driver
structure, driver-pm, like below.
static struct pci_driver ehci_pci_driver = {
...
.probe =usb_hcd_pci_probe,
.remove =usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
#ifdef CONFIG_PM_SLEEP
.driver ={
.pm =usb_hcd_pci_pm_ops
},
#endif
};
But rpm_suspend search runtime suspend from device structure.
like dev-pm_domain, dev-type, dev-class, dev-bus, etc.
Why hcd_pci_runtime_suspend will be called?
b.
Contrary to pci system, in ehci-platfomr.c, there is no any runtime
suspend call back register in ehci_platform_pm_ops.
Could we get the conclusion that ehci controller will NOT be suspended
when all device on the root hub and root hub are suspended?
Sincerely appreciate your kind help,
--
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
Re: Difference between run time and normal suspend
On Mon, 19 Jan 2015, vichy wrote:
I have several questions:
a.
in ehci-pci driver, the runtime suspend is register in the driver
structure, driver-pm, like below.
static struct pci_driver ehci_pci_driver = {
...
.probe =usb_hcd_pci_probe,
.remove =usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
#ifdef CONFIG_PM_SLEEP
.driver ={
.pm =usb_hcd_pci_pm_ops
},
#endif
};
But rpm_suspend search runtime suspend from device structure.
like dev-pm_domain, dev-type, dev-class, dev-bus, etc.
Why hcd_pci_runtime_suspend will be called?
We are talking about a PCI implementation of EHCI, so dev-type is
pci_bus_type. In drivers/pci/pci-driver.c, pci_bus_type.pm is set to
pci_dev_pm_ops.
The .runtime_suspend member of pci_dev_pm_ops is set to
pci_pm_runtime_suspend. That routine calls
dev-driver-pm-runtime_suspend.
For ehci-pci, dev-driver is ehci_pci_driver.driver and its .pm field
is usb_hcd_pci_pm_ops. Therefore hcd_pci_runtime_suspend will be
called.
b.
Contrary to pci system, in ehci-platfomr.c, there is no any runtime
suspend call back register in ehci_platform_pm_ops.
Could we get the conclusion that ehci controller will NOT be suspended
when all device on the root hub and root hub are suspended?
That's right. The ehci-platform driver does not support runtime
suspend of the controller. It doesn't support hibernation either.
Alan stern
--
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
Re: Difference between run time and normal suspend
Is 3rd situation you mentioned above the function will be called is hcd-bus_suspend? hcd-bus_suspend will be called first, and shortly afterward ehci-suspend will be called (if this is an EHCI controller). Fourthly, you should realize that controller itself will also be put into runtime suspend means the controller itself will be put into runtime suspend. is 4th situation you mentioned above the function will be called is ehci_suspend, (take ehci for example)? Yes. after tracing the source, I only can find the ehci_suspend is called when system hibernate/suspend. rpm_suspend use below method to find out suspend callback if (dev-pm_domain) callback = dev-pm_domain-ops.runtime_suspend; else if (dev-type dev-type-pm) callback = dev-type-pm-runtime_suspend; else if (dev-class dev-class-pm) callback = dev-class-pm-runtime_suspend; else if (dev-bus dev-bus-pm) callback = dev-bus-pm-runtime_suspend; else callback = NULL; ehci_suspend doesn't register any one of above function. but ehci_supend is called when system is going to suspend/hibernate, or it will be called even in runtime suspend? Both. BTW, when I turn off the led on the keyboard, the keyboard can successfully go to runtime suspend. Good. Would you mind to let us know how you find out the problem from mon files? Is it due there is no remote wake control message on the mon file? The usbmon trace showed that the interrupt URB for one of the HID interfaces was cancelled (indicating that the interface had been suspended) but the interrupt URB for the other HID interface was not cancelled (indicating that the interface had failed to suspend). Reading the source code for the usbhid driver showed that there are only a few reasons for failing to suspend an interface, and one of those reasons was if an LED was illuminated. Sincerely appreciate your kind help, -- 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
Re: Difference between run time and normal suspend
On Sun, 18 Jan 2015, vichy wrote: after tracing the source, I only can find the ehci_suspend is called when system hibernate/suspend. rpm_suspend use below method to find out suspend callback if (dev-pm_domain) callback = dev-pm_domain-ops.runtime_suspend; else if (dev-type dev-type-pm) callback = dev-type-pm-runtime_suspend; else if (dev-class dev-class-pm) callback = dev-class-pm-runtime_suspend; else if (dev-bus dev-bus-pm) callback = dev-bus-pm-runtime_suspend; else callback = NULL; ehci_suspend doesn't register any one of above function. ehci_pci_init() in ehci_pci.c stores ehci_suspend in ehci_pci_hc_driver.pci_suspend. That pointer is called by suspend_common() in hcd-pci.c, which is called by both hcd_pci_suspend() and hcd_pci_runtime_suspend(). Alan Stern -- 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
Re: Difference between run time and normal suspend
hi alan: Firstly, you should realize that a hub port can be put into suspend _only_ if a device is plugged into it. If nothing is plugged into a port then the port cannot be put into suspend. Secondly, you should realize that putting a USB device into suspend means the same thing as suspending the hub port the device is plugged into. Thirdly, you should realize therefore that if _all_ the devices attached to the host controller are in runtime suspend, then all the connected ports must be suspended. (And none of the disconnected ports can be suspended, since it is impossible to suspend a disconnected port.) Is 3rd situation you mentioned above the function will be called is hcd-bus_suspend? Fourthly, you should realize that controller itself will also be put into runtime suspend means the controller itself will be put into runtime suspend. is 4th situation you mentioned above the function will be called is ehci_suspend, (take ehci for example)? but ehci_supend is called when system is going to suspend/hibernate, or it will be called even in runtime suspend? BTW, when I turn off the led on the keyboard, the keyboard can successfully go to runtime suspend. Would you mind to let us know how you find out the problem from mon files? Is it due there is no remote wake control message on the mon file? Sincerely appreciate your kind help, -- 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
Re: Difference between run time and normal suspend
hi Alan: 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. here controller itself will also be put into runtime suspend. mean the controller itself will put into suspend or root hub ports will put in suspend? Sincerely appreciate your kind help, -- 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
Re: Difference between run time and normal suspend
On Sun, 11 Jan 2015, vichy wrote: hi Alan: 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. here controller itself will also be put into runtime suspend. mean the controller itself will put into suspend or root hub ports will put in suspend? Firstly, you should realize that a hub port can be put into suspend _only_ if a device is plugged into it. If nothing is plugged into a port then the port cannot be put into suspend. Secondly, you should realize that putting a USB device into suspend means the same thing as suspending the hub port the device is plugged into. Thirdly, you should realize therefore that if _all_ the devices attached to the host controller are in runtime suspend, then all the connected ports must be suspended. (And none of the disconnected ports can be suspended, since it is impossible to suspend a disconnected port.) Fourthly, you should realize that controller itself will also be put into runtime suspend means the controller itself will 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Difference between run time and normal suspend
On Fri, 2015-01-09 at 13:32 +0800, Peter Chen wrote: 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. This bug in some devices is known. There is a quirk flag for it. HID_QUIRK_ALWAYS_POLL should be set for those devices. Do all devices of those vendors show the problem? 2. For USB keyboard issue usbhid-ledcount has some problems, need to set ignoreled=1 to let auto-suspend work Do the LEDs go out when they shouldn't? Regards Oliver -- 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
RE: Difference between run time and normal suspend
On Fri, 2015-01-09 at 13:32 +0800, Peter Chen wrote:
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.
This bug in some devices is known. There is a quirk flag for it.
HID_QUIRK_ALWAYS_POLL should be set for those devices. Do all devices of
those vendors show the problem?
All Microsoft mouse I meet have this problem.
2. For USB keyboard issue
usbhid-ledcount has some problems, need to set ignoreled=1 to let
auto-suspend work
Do the LEDs go out when they shouldn't?
What's your mean?
Peter
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: Difference between run time and normal suspend
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Difference between run time and normal suspend
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 -- 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
Re: Difference between run time and normal suspend
hi alan: 2015-01-06 23:54 GMT+08:00 Alan Stern st...@rowland.harvard.edu: 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 , 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. I attach usbmon for your reference. But keyboard is still not working on 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. Would you mind to show me where the program determine controller go into runtime suspend if all devices on it go to suspend? BTW a. if even controller suspended, does that mean all devices on it will be disconnect and re-enumerated when resume? b. is there any usb sysfs file can let us suspend specific port on root or normal hub? appreciate your kind help, liteon.keyboard.mon.tar.bz2 Description: BZip2 compressed data
Re: Difference between run time and normal suspend
hi alan: 2015-01-06 8:39 GMT+08:00 vichy vichy@gmail.com: 2015-01-05 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. 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? appreciate your help in advance, # lsmod Not tainted usbhid 21486 0 - Live 0xbe4a3000 hid_generic 954 0 - Live 0xbe49f000 hid 72898 2 usbhid,hid_generic, Live 0xbe487000 usb_storage 43962 0 - Live 0xbe473000 ehci_hcd 60249 0 - Live 0xbe45e000 xhci_hcd 92188 0 - Live 0xbe441000 usbcore 182850 4 usbhid,usb_storage,ehci_hcd,xhci_hcd, Live 0xbe404000 usb_common 1822 1 usbcore, Live 0xbe40 # # [0-57.0178] usb 6-1: new low-speed USB device number 3 using platform-ehci [0-57.1687] usb 6-1: New USB device found, idVendor=04ca, idProduct=002f [0-57.1752] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [0-57.1821] usb 6-1: Product: USB Multimedia Keyboard [0-57.1869] usb 6-1: Manufacturer: Lite-On Technology Corp. [0-57.2035] input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/fc1a.ehci/usb6/6-1/6-1:1.0/input/input0 [0-57.2152] hid-generic 0003:04CA:002F.0001: input: USB HID v1.10 Keyboard [Lite-On Technology Corp. USB Multimedia Keyboard] on usb-platform-1/input0 [0-57.2409] input: Lite-On Technology Corp. USB Multimedia Keyboard as /devices/fc1a.ehci/usb6/6-1/6-1:1.1/input/input1 [0-57.2522] hid-generic 0003:04CA:002F.0002: input: USB HID v1.10 Device [Lite-On Technology Corp. USB Multimedia Keyboard] on usb-platform-1/input1 # # cat /sys/bus/usb/devices/6-1/power/control on # echo auto /sys/bus/usb/devices/6-1/power/control # echo 0 /sys/bus/usb/devices/6-1/power/autosuspend # cat /sys/bus/usb/devices/6-1/power/ active_duration runtime_active_time wakeup_count autosuspend runtime_status wakeup_expire_count autosuspend_delay_msruntime_suspended_time wakeup_last_time_ms connected_duration wakeup wakeup_max_time_ms control wakeup_abort_count wakeup_total_time_ms level wakeup_active persist wakeup_active_count # cat /sys/bus/usb/devices/6-1/power/runtime_status active # cat /sys/bus/usb/devices/6-1/power/runtime_suspended_time 0 #
Re: Difference between run time and normal suspend
hi all: 2015-01-06 16:06 GMT+08:00 vichy vichy@gmail.com: hi alan: 2015-01-06 8:39 GMT+08:00 vichy vichy@gmail.com: 2015-01-05 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. 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? I test the same keyboard on the NB is also not seeing autosuspend work. the kernel version of NB is 3.18 and my embedded system is 3.10 (I also attach usb descriptor of the keyboard I used in the mail) thanks for your help, liteon.keyboard.desc.txt.tar.bz2 Description: BZip2 compressed data
Re: Difference between run time and normal suspend
hi Alan: 2015-01-06 23:03 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Tue, 6 Jan 2015, vichy wrote: I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. 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 , and it will directly call runtime suspend related function 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? 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? appreciate your kind help, liteon.keyboard.desc.txt.tar.bz2 Description: BZip2 compressed data
Re: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: The mouse will reconnect even I just kept it connected and not moving it. is there any method or debug message we can tell what is going on to make it resume? usbmon. My guess is that the mouse disconnects and reconnects all by itself after a few seconds of suspend. Alan Stern -- 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
Re: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. 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? Alan Stern -- 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
Re: Difference between run time and normal suspend
On Tue, 6 Jan 2015, vichy wrote: I use keyboard, it should be default support runtime suspend, for testing runtime suspend like the attach log. insert related modules, change related suspend parameters. 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? No. I test the same keyboard on the NB is also not seeing autosuspend work. the kernel version of NB is 3.18 and my embedded system is 3.10 (I also attach usb descriptor of the keyboard I used in the mail) If you want to find out what's happening, add some debugging printk statements to autosuspend_check() in drivers/usb/core/driver.c. Maybe also to usb_runtime_suspend(). You might also want to enable CONFIG_PM_ADVANCED_DEBUG and see what the other runtime_* files in the .../power directory say. Alan Stern -- 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
Re: Difference between run time and normal suspend
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 , 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Difference between run time and normal suspend
hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? 2. I plug in one mouse and found the device will auto disconnect every 2 secs, the default value of usb_autosuspend_delay. But I have some questions a. how kernel judge the device is idle, from usb spec, the idle mean there is no any bus traffic, including sof, over 3ms and host will always firing sof even there is no transaction on the bus. b. I think dynamic suspend is used for saving power when device is idle for a specific time, but why the mouse will dynamic resume when suspend for a while. it should resume when user or external event trigger it for resume right? appreciate your help in advance, -- 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
Re: Difference between run time and normal suspend
2015-01-05 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. 2. I plug in one mouse and found the device will auto disconnect every 2 secs, the default value of usb_autosuspend_delay. But I have some questions a. how kernel judge the device is idle, from usb spec, the idle mean there is no any bus traffic, including sof, over 3ms and host will always firing sof even there is no transaction on the bus. The kernel judges a device to be idle if it hasn't been used in some time. The bus traffic has nothing to do with it. b. I think dynamic suspend is used for saving power when device is idle for a specific time, but why the mouse will dynamic resume when suspend for a while. it should resume when user or external event trigger it for resume right? That's right. If your mouse is resuming, it must be because some event has triggered the resume. The mouse will reconnect even I just kept it connected and not moving it. is there any method or debug message we can tell what is going on to make it resume? sincere appreciate your help, -- 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
Re: Difference between run time and normal suspend
On Mon, 5 Jan 2015, vichy wrote: hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto /sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. 2. I plug in one mouse and found the device will auto disconnect every 2 secs, the default value of usb_autosuspend_delay. But I have some questions a. how kernel judge the device is idle, from usb spec, the idle mean there is no any bus traffic, including sof, over 3ms and host will always firing sof even there is no transaction on the bus. The kernel judges a device to be idle if it hasn't been used in some time. The bus traffic has nothing to do with it. b. I think dynamic suspend is used for saving power when device is idle for a specific time, but why the mouse will dynamic resume when suspend for a while. it should resume when user or external event trigger it for resume right? That's right. If your mouse is resuming, it must be because some event has triggered the resume. Alan Stern -- 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
