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@xxxxxxxxx> 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@xxxxxxxxx> 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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
