avoid adding devices without pm_ops to dpm list

avoid adding devices without pm_ops to dpm list

[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 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

Re: avoid adding devices without pm_ops to dpm list

[Alan Stern]

On Mon, 21 Apr 2014, Sravan wrote:

> 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.

What are you talking about?  _No_ device has a pm_ops structure; there
is no such member inside struct device.

> 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 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

Re: avoid adding devices without pm_ops to dpm list

[Sravan]

On 4/21/2014 7:39 PM, Alan Stern wrote:
> On Mon, 21 Apr 2014, Sravan wrote:
>
>> 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.
> What are you talking about?  _No_ device has a pm_ops structure; there
> is no such member inside struct device.
>
>> 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 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
>
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

Re: avoid adding devices without pm_ops to dpm list

[Alan Stern]

On Sun, 4 May 2014, Sravan wrote:

> 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.

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.

> 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.

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