Re: RFC [2/3] - SoC, CPU LPS, Tickless idle and Device power management
On Tue, 2016-03-01 at 11:03 -0800, Dirk Brandewie wrote:
On 02/29/2016 01:59 AM, Thomas, Ramesh wrote:device***These are implemented and under review***
calleddrivers to define suspend and resume hook functions that can be
In this RFC I tried to keep the main ideas and feedbacks from theby the PM service app.There is a basic disconnects between my original RFC and this one.
original RFCs but made some modifications as I encountered issues during
implementation. These should not impact the general goals of the
changes. Listed below are the differences which can be reviewed again if
Way device_ops structure gets initialized changed.
1. (Original RFC) Modify DEVICE_INIT call of all drivers in the system
and add a suspend_fn and resume_fn parameter to it. The macro would
statically create the device_ops structure and initialize it with the
passed suspend_fn and resume_fn. Caller of DEVICE_INIT can pass the
address of a "null" function if they do not have any operation for
either suspend or resume.
2. (This RFC) DEVICE_INIT() macro would create the device_ops structure
same as option #1 but would by default initialize it with no-op
functions for suspend and resume. So this DEVICE_INIT macro API params
need not be changed. Drivers which need any operation for
suspend/resume, would at run time, update the device_ops with their
suspend/resume function using device_power_ops_configure(suspend_fn,
The "null" function referred to in #1 is same as the "no-op" function in
#2 except for the name change.
I picked #2 for the implementation because of the following reasons.
1. No need to modify DEVICE_INIT macros of all drivers (I greped 75+)
2. Scalable because if device_ops needs to be modified later to include
more ops, remove ops or add other fields, then we do not need to modify
all drivers calling DEVICE_INIT()
(I figured this only when I was about to modify the drivers and missed
it during original RFC discussion)
Let us review the above options and do whatever is appropriate. I have
no problem switching to any of them.
Also please review the other change from the original RFC -
device_suspend_all/device_resume_all now takes a parameter
system_devices. This gives an option to use this function only for
system devices if the PM app choses to call other devices suspend/resume
Let us review that also and if the parameter is not required then we can
To be honest if I had thought about it more when I was definingto
devicedo suspend and resume operations on system devices like the APIC
thewhich do not export device binding interface.
toaddresses of the functions they implement to these hooks during
policies.each driver, the integrator and the system power management
deviceinside CONFIG_DEVICE_POWER flag.
theiterate through that list and call the suspend hook function of each
fordevices were initialized.
functionsthe PM service app to call this function for system devices. This is
thmdirectly. For non-system devices, the PM service app can bind to
andand has the flexibility to call whichever device it requires to call
thisin the order it chooses to. If it chooses to call the suspend/resume
wouldfunction passing true for the <system_devices> parameter.
incall the resume hook functions of devices and they would be called
thethe same order as the devices were initialized.
Thisdevice's "device" structure.
operation to do.can be used to initialize hooks for which the device has no
specificwith this function by the kernel. Device drivers which have
functionsoperations for the hooks would overwrite with a suspend and resume
duringpassed as parameters. This function should be called by devices
asthe time of initialization if they have a specific suspend or resume
notparameter for any of the hooks it does not have an operation. If it
arecall this function at all. This is because the hooks for the devices
by default initialized with the no-op function by the kernel.