avoid adding devices without pm_ops to dpm list
Hello,
I have come across below code which looks can be optimized to reduce suspend/resume latencies.
During device registration at boot up, device_add() is called.
In this device_add() function, device_pm_add() is called without checking if the device has pm_ops or not. Thus dpm_list is generated with all devices even if some devices don't have pm_ops.
device_add() -> device_pm_add()-> generate dpm_list
During suspend/resume process, suspend/resume APIs are called for devices present in dpm_list. due to this, suspend/resume APIs for devices without pm_ops also called and just return with NULL.
Can we optimize this code by adding *ONLY* devices with pm_ops to dpm_list and ignore remaining?
It will help reduce suspend/resume latencies. I observed 10mS savings with my debug code. It may change based on number of devices without pm_ops.
Let me know your opinion/suggestions on this.
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Quoted 11 lines · Sravan
Hello,
I have come across below code which looks can be optimized to reduce suspend/resume latencies.
During device registration at boot up,
device_add()is called. In thisdevice_add()function,device_pm_add()is called without checking if the device haspm_opsor not.
Thusdpm_listis generated with all devices even if some devices don't havepm_ops.
Quoted 6 lines
device_add()-> device_pm_add()-> generatedpm_listDuring suspend/resume process, suspend/resume APIs are called for devices present in
dpm_list.
due to this, suspend/resume APIs for devices withoutpm_opsalso called and just return with NULL.
What are you talking about? _No_ device has a pm_ops structure; there is no such member inside struct device.
Quoted 6 lines
Can we optimize this code by adding *ONLY* devices with
pm_opstodpm_listand ignore remaining?
It will help reduce suspend/resume latencies. I observed 10mS savings with my debug code. It may change based on number of devices withoutpm_ops.Let me know your opinion/suggestions on this.
The suspend and resume routines look at pm_ops structures in the device's power domain, device type, bus type, class, and driver. Even though most of those remain constant throughout the device's lifetime, the driver can change at any time. Therefore it is not possible to leave devices off the dpm_list.
Alan Stern
Quoted 27 lines · Alan Stern
Quoted 11 lines · Sravan
Hello,
I have come across below code which looks can be optimized to reduce suspend/resume latencies.
During device registration at boot up,
device_add()is called. In thisdevice_add()function,device_pm_add()is called without checking if the device haspm_opsor not.
Thusdpm_listis generated with all devices even if some devices don't havepm_ops.Quoted 6 lines
device_add()-> device_pm_add()-> generatedpm_listDuring suspend/resume process, suspend/resume APIs are called for devices present in
dpm_list.
due to this, suspend/resume APIs for devices withoutpm_opsalso called and just return with NULL.What are you talking about? _No_ device has a
pm_opsstructure; there is no such member inside struct device.Quoted 5 lines
Can we optimize this code by adding *ONLY* devices with
pm_opstodpm_listand ignore remaining?
It will help reduce suspend/resume latencies. I observed 10mS savings with my debug code. It may change based on number of devices withoutpm_ops.
Quoted 9 lines
Quoted 1 line
Let me know your opinion/suggestions on this.
The suspend and resume routines look at
pm_opsstructures in the device's power domain, device type, bus type, class, and driver. Even though most of those remain constant throughout the device's lifetime, the driver can change at any time. Therefore it is not possible to leave devices off thedpm_list.Alan Stern
Hi Alan,
If i follow below steps, won't it resolve the issue?
1. Add pm_ops check for driver during driver registration
2. If driver has pm_ops, i will add device to dpm_list.
3. error handling to remove device from dpm_list if driver is unregistered
driver attach to device code flow is as below:driver_register->bus_add_driver->driver_attach->__driver_attach->driver_probe_device->really_probe
Thus dpm_list is becoming dynamic and unnecessary devices are removed from dpm_list.
I observed few hundreds of devices without pm_ops (no pm_ops for any of pm_domain, type, class, driver) on my device. So i am looking for better solution to optimize this Suspend/Resume path and latencies.
Let me know if you think of any side effects with above approach and better alternative solutions.
Sravan
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Quoted 5 lines · Sravan
Hi Alan,
If i follow below steps, won't it resolve the issue?1. Add
pm_opscheck for driver during driver registration
2. If driver haspm_ops, i will add device todpm_list.
Where will you add it? Devices have to be added in the correct place in the list. You mustn't just add a device to the end of the list.
Quoted 8 lines
3. error handling to remove device from
dpm_listif driver is unregistereddriver attach to device code flow is as below:
driver_register->bus_add_driver->driver_attach->__driver_attach->driver_probe_device->really_probeThus
dpm_listis becoming dynamic and unnecessary devices are removed fromdpm_list.
Quoted 7 lines
I observed few hundreds of devices without
pm_ops(nopm_opsfor any ofpm_domain, type, class, driver)
on my device. So i am looking for better solution to optimize this Suspend/Resume path and latencies.Let me know if you think of any side effects with above approach and better alternative solutions.
A better approach might be for dpm_prepare() to look for devices with no callbacks. When it finds one, it can mark the device structure so that later stages can skip the device quickly.
Alan Stern