1. Are external devices can be integrated into the runtime suspend/resume , or are they outside the subject of PM ? for example I have external dsp connected to omap, can it be integrated to the PM ? If it is controled through character device how can it be tailored into the generic PM ?
Any external device can be integrated in runtime-pm framework provided its device driver or subsystem driver has runtime pm operations (namely dev_pm_ops->.runtime_suspend/resume/idle). Runtime suspend/resume is called by your driver to suspend the respective device. It can do so by incrementing/decrementing the usage count via pm_runtime_get and pm_runtime_put or by directly calling pm_runtime_suspend/pm_request_resume. So your char device driver for omap has to enable runtime pm for the device by calling pm_runtime_set_active() and pm_runtime_enable() from its init/probe methods. Whenever the driver needs to wakeup the device(say on receiving a interrupt), it can call runtime_pm_get. After handling the interrupt, if the driver wants to suspend the device, it can call runtime_pm_put. My statements are generic as I am unaware how the dsp functions.
2. When the system moves to idle does it then automatically call all tuntime suspend of all devices ?
As I have mentioned in my previous reply that the runtime-pm is device specific(and not system specific). so each device driver calls its runtime suspend/resume for its corresponding devices whenever it feels so. The runtime-pm framework has some policies like it checks if the device to be suspended has any active children or not, etc System moving to idle state would correspond to most devices in a runtime-pm idle state. Each device enter into idle state when its corresponding driver invokes so. Each device is independently moved to idle/suspend/resume state unless their exist a parent-child relationship between the devices. Runtime power management is different from system power management (ie suspend to RAM/Disk) in which the PM framework calls the suspend and resume of all the devices(sequentially). However, these suspend/resume functions are different from runtime suspend/resume functions. eg static const struct dev_pm_ops usb_device_pm_ops = { .prepare = usb_dev_prepare, .complete = usb_dev_complete, /* the following two functions are system power management's suspend/resume functions which are invoked by PM framework when the system suspends/hibernates. */ .suspend = usb_dev_suspend, .resume = usb_dev_resume, .freeze = usb_dev_freeze, .thaw = usb_dev_thaw, .poweroff = usb_dev_poweroff, .restore = usb_dev_restore, #ifdef CONFIG_USB_SUSPEND /* the following three functions are runtime power management's suspend/resume/idle functions invoked by the driver when it wants to put the corresponding device in suspend/idle/resume state. */ .runtime_suspend = usb_runtime_suspend, .runtime_resume = usb_runtime_resume, .runtime_idle = usb_runtime_idle, #endif }; Regards, Ayan Kumar Halder
Hi Ayan, Thanks very much for the explanations, it makes things a bit more clearer than before, but I still have some question marks. "System moving to idle state would correspond to most devices in a runtime-pm idle state. Each device enter into idle state when its corresponding driver invokes so" How does the driver invokes moving to idle state ? Is it the smae as invoking runtime suspend by the driver ? What is the difference between idle state to runtime suspend ? Are you familiar with any character device example for using PM ? Thanks, Ran On Wed, Sep 3, 2014 at 11:01 AM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
1. Are external devices can be integrated into the runtime suspend/resume , or are they outside the subject of PM ? for example I have external dsp connected to omap, can it be integrated to the PM ? If it is controled through character device how can it be tailored into the generic PM ?
Any external device can be integrated in runtime-pm framework provided its device driver or subsystem driver has runtime pm operations (namely dev_pm_ops->.runtime_suspend/resume/idle).
Runtime suspend/resume is called by your driver to suspend the respective device. It can do so by incrementing/decrementing the usage count via pm_runtime_get and pm_runtime_put or by directly calling pm_runtime_suspend/pm_request_resume. So your char device driver for omap has to enable runtime pm for the device by calling pm_runtime_set_active() and pm_runtime_enable() from its init/probe methods. Whenever the driver needs to wakeup the device(say on receiving a interrupt), it can call runtime_pm_get. After handling the interrupt, if the driver wants to suspend the device, it can call runtime_pm_put.
My statements are generic as I am unaware how the dsp functions.
2. When the system moves to idle does it then automatically call all tuntime suspend of all devices ?
As I have mentioned in my previous reply that the runtime-pm is device specific(and not system specific). so each device driver calls its runtime suspend/resume for its corresponding devices whenever it feels so. The runtime-pm framework has some policies like it checks if the device to be suspended has any active children or not, etc
System moving to idle state would correspond to most devices in a runtime-pm idle state. Each device enter into idle state when its corresponding driver invokes so. Each device is independently moved to idle/suspend/resume state unless their exist a parent-child relationship between the devices.
Runtime power management is different from system power management (ie suspend to RAM/Disk) in which the PM framework calls the suspend and resume of all the devices(sequentially). However, these suspend/resume functions are different from runtime suspend/resume functions. eg static const struct dev_pm_ops usb_device_pm_ops = { .prepare = usb_dev_prepare, .complete = usb_dev_complete,
/* the following two functions are system power management's suspend/resume functions which are invoked by PM framework when the system suspends/hibernates. */
.suspend = usb_dev_suspend, .resume = usb_dev_resume, .freeze = usb_dev_freeze, .thaw = usb_dev_thaw, .poweroff = usb_dev_poweroff, .restore = usb_dev_restore, #ifdef CONFIG_USB_SUSPEND /* the following three functions are runtime power management's suspend/resume/idle functions invoked by the driver when it wants to put the corresponding device in suspend/idle/resume state. */ .runtime_suspend = usb_runtime_suspend, .runtime_resume = usb_runtime_resume, .runtime_idle = usb_runtime_idle, #endif };
Regards, Ayan Kumar Halder
Hi Ayan, When adding some external device to power management, doesn't it need to belong to power domain ( /debug/pm_debug/count ). What is the power domain of external device ? Thanks Ran On Wed, Sep 3, 2014 at 11:23 PM, Ran Shalit <ranshalit@gmail.com> wrote:
Hi Ayan, Thanks very much for the explanations, it makes things a bit more clearer than before, but I still have some question marks.
"System moving to idle state would correspond to most devices in a runtime-pm idle state. Each device enter into idle state when its corresponding driver invokes so"
How does the driver invokes moving to idle state ? Is it the smae as invoking runtime suspend by the driver ? What is the difference between idle state to runtime suspend ? Are you familiar with any character device example for using PM ?
Thanks, Ran
On Wed, Sep 3, 2014 at 11:01 AM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
1. Are external devices can be integrated into the runtime suspend/resume , or are they outside the subject of PM ? for example I have external dsp connected to omap, can it be integrated to the PM ? If it is controled through character device how can it be tailored into the generic PM ?
Any external device can be integrated in runtime-pm framework provided its device driver or subsystem driver has runtime pm operations (namely dev_pm_ops->.runtime_suspend/resume/idle).
Runtime suspend/resume is called by your driver to suspend the respective device. It can do so by incrementing/decrementing the usage count via pm_runtime_get and pm_runtime_put or by directly calling pm_runtime_suspend/pm_request_resume. So your char device driver for omap has to enable runtime pm for the device by calling pm_runtime_set_active() and pm_runtime_enable() from its init/probe methods. Whenever the driver needs to wakeup the device(say on receiving a interrupt), it can call runtime_pm_get. After handling the interrupt, if the driver wants to suspend the device, it can call runtime_pm_put.
My statements are generic as I am unaware how the dsp functions.
2. When the system moves to idle does it then automatically call all tuntime suspend of all devices ?
As I have mentioned in my previous reply that the runtime-pm is device specific(and not system specific). so each device driver calls its runtime suspend/resume for its corresponding devices whenever it feels so. The runtime-pm framework has some policies like it checks if the device to be suspended has any active children or not, etc
System moving to idle state would correspond to most devices in a runtime-pm idle state. Each device enter into idle state when its corresponding driver invokes so. Each device is independently moved to idle/suspend/resume state unless their exist a parent-child relationship between the devices.
Runtime power management is different from system power management (ie suspend to RAM/Disk) in which the PM framework calls the suspend and resume of all the devices(sequentially). However, these suspend/resume functions are different from runtime suspend/resume functions. eg static const struct dev_pm_ops usb_device_pm_ops = { .prepare = usb_dev_prepare, .complete = usb_dev_complete,
/* the following two functions are system power management's suspend/resume functions which are invoked by PM framework when the system suspends/hibernates. */
.suspend = usb_dev_suspend, .resume = usb_dev_resume, .freeze = usb_dev_freeze, .thaw = usb_dev_thaw, .poweroff = usb_dev_poweroff, .restore = usb_dev_restore, #ifdef CONFIG_USB_SUSPEND /* the following three functions are runtime power management's suspend/resume/idle functions invoked by the driver when it wants to put the corresponding device in suspend/idle/resume state. */ .runtime_suspend = usb_runtime_suspend, .runtime_resume = usb_runtime_resume, .runtime_idle = usb_runtime_idle, #endif };
Regards, Ayan Kumar Halder
When adding some external device to power management, doesn't it need to belong to power domain ( /debug/pm_debug/count ).
Power Domains are decided by system designer. A board can be divided into multiple power domains which can be powered on/off or voltage/current regulated independently as each power domain is controlled by a power regulator.
What is the power domain of external device ? The right person to answer this question will be your system designer. You may look into the board schematics to find out power regulator of your external device. Each power domain is controlled by a power regulator.
It is not necessary for you to consider power domains if you do not wish to power up/down or regulate the voltage /current while running Linux on the board. Another generic way to do runtime-power management of various devices would be to perform clock scaling/gating (assuming you know the clock domains of your system).
Hi, Thanks very much for the detailed answer. If I may ask one more on this issue please... I am required to put some external device (led brightness) into minimal brightness when the system gets to idle. The control on led brightness value is done as part of dedicated character device which was written for the purpose of brightness control (which uses i2c bus) I wander if this is possible using the linux PM capabilities, and how this should be done. Thanks, Ran On Fri, Sep 5, 2014 at 7:13 PM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
When adding some external device to power management, doesn't it need to belong to power domain ( /debug/pm_debug/count ).
Power Domains are decided by system designer. A board can be divided into multiple power domains which can be powered on/off or voltage/current regulated independently as each power domain is controlled by a power regulator.
What is the power domain of external device ? The right person to answer this question will be your system designer. You may look into the board schematics to find out power regulator of your external device. Each power domain is controlled by a power regulator.
It is not necessary for you to consider power domains if you do not wish to power up/down or regulate the voltage /current while running Linux on the board. Another generic way to do runtime-power management of various devices would be to perform clock scaling/gating (assuming you know the clock domains of your system).
I am required to put some external device (led brightness) into minimal brightness when the system gets to idle.
Please elaborate on "System gets to idle state." Do you mean the system is suspended ? ------- case 1 or the device has moved to idle state? ------- case 2
The control on led brightness value is done as part of dedicated character device which was written for the purpose of brightness control (which uses i2c bus) I wander if this is possible using the linux PM capabilities, and how this should be done. In either case it should be possible as per my understanding. You need to implement it in the appropriate PM handlers. case1 ----> write the appropriate code in driver->pm->suspend case2 ----> write the appropriate code in driver->pm->runtime_idle
Regards, Ayan Kumar Halder
Thanks, Ran
On Fri, Sep 5, 2014 at 7:13 PM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
When adding some external device to power management, doesn't it need to belong to power domain ( /debug/pm_debug/count ).
Power Domains are decided by system designer. A board can be divided into multiple power domains which can be powered on/off or voltage/current regulated independently as each power domain is controlled by a power regulator.
What is the power domain of external device ? The right person to answer this question will be your system designer. You may look into the board schematics to find out power regulator of your external device. Each power domain is controlled by a power regulator.
It is not necessary for you to consider power domains if you do not wish to power up/down or regulate the voltage /current while running Linux on the board. Another generic way to do runtime-power management of various devices would be to perform clock scaling/gating (assuming you know the clock domains of your system).
participants (2)
-
AYAN KUMAR HALDER -
Ran Shalit