External devices

External devices

[Ran Shalit]

Hello,

I am new in the subject of PM, and though been trying to delve into it
and reading, I still see it is hugh subject and still have many
unresolved questions.
I hope you can help me with some of them:

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 ?
2. When the system moves to idle does it then automatically call all
tuntime suspend of all devices ?

Thanks very much,
Ran

Re: External devices

[AYAN KUMAR HALDER]

> 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

External devices

[AYAN KUMAR HALDER]

> 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

Re: External devices

[Ran Shalit]

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

External devices

[Ran Shalit]

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

Re: External devices

[Ran Shalit]

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

External devices

[Ran Shalit]

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

Re: External devices

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

External devices

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

Re: External devices

[Ran Shalit]

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

External devices

[Ran Shalit]

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

Re: External devices

[AYAN KUMAR HALDER]

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

External devices

[AYAN KUMAR HALDER]

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

External devices

[AYAN KUMAR HALDER]

On Mon, Sep 8, 2014 at 9:19 AM, Ran Shalit <ranshalit@gmail.com> wrote:
>>> 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
>>
> Where should be the command to change brightness to minimum through
> i2c ? In runtime_suspend ?
>
If you want to reduce brightness to minimum when the character device goes in
a runtime-suspend mode, then Yes.
(Please include kernelnewbies, as others will also be able to respond
to your query
and rectify if I am mistaken)

External devices

[AYAN KUMAR HALDER]

> When a device wakes up, what about the cpu , is it still on idle with cpuidle ?
> for example how a mouse move trigger the screen to wake up ?
>
This is a case of system suspend/resume. Your mouse is a wake-up device. It is
configured to send wakeup interrupts. It would wake up the cpu first
and then  the cpu wakes up
all the devices.

External devices

[Ran Shalit]

On Mon, Sep 8, 2014 at 9:16 PM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
>> When a device wakes up, what about the cpu , is it still on idle with cpuidle ?
>> for example how a mouse move trigger the screen to wake up ?
>>
> This is a case of system suspend/resume. Your mouse is a wake-up device. It is
> configured to send wakeup interrupts. It would wake up the cpu first
> and then  the cpu wakes up
> all the devices.

Hi,
Do you mean runtime suspend/resume ? Why will the mouse wake the cpu
from idle (cpuidle) ? Isn't it that the wakeup source will wake only
the specific device which was runtime suspended ? Thanks

External devices

[AYAN KUMAR HALDER]

> Hi,
> Do you mean runtime suspend/resume ?
No, I am talking about system suspend/resume (suspend to RAM, etc).

> Why will the mouse wake the cpu
Because it has been configured as a wakeup device.

> from idle (cpuidle) ? Isn't it that the wakeup source will wake only
> the specific device which was runtime suspended ? Thanks
You are bringing too many things here.
1. cpuidle is a different concept.
2. The situation you had described above is not of runtime-suspend.
"Movement of mouse wakes up the system"

External devices

[Ran Shalit]

On Mon, Sep 8, 2014 at 9:57 PM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
>> Hi,
>> Do you mean runtime suspend/resume ?
> No, I am talking about system suspend/resume (suspend to RAM, etc).
>
>> Why will the mouse wake the cpu
> Because it has been configured as a wakeup device.
>
>> from idle (cpuidle) ? Isn't it that the wakeup source will wake only
>> the specific device which was runtime suspended ? Thanks
> You are bringing too many things here.
> 1. cpuidle is a different concept.
> 2. The situation you had described above is not of runtime-suspend.
> "Movement of mouse wakes up the system"
 Hi Ayan,
Yes, I know...This is exactly the point in PM I don't understand yet...
I try to configure the linux in my board to do it all automatically
(this are actually my requirements) , i.e. using the following
mechanism: cpuidle, cpufreq, DVFS & runtime PM.
Now, the thing I don't yet understand is what the wakeup source means
in this configuration. Wakeup only for a specific device driver ?
Thanks for clarification this issue for me....
Ran

Fwd: External devices

[AYAN KUMAR HALDER]

> Now, the thing I don't yet understand is what the wakeup source means
> in this configuration. Wakeup only for a specific device driver ?
Wakeup source has its relevance mostly for system suspend/resume where in
a device (eg keyboard) can pull the system out of suspend mode.

In Runtime-pm, the device is the wake-up source for itself unless there exist
a parent-child relationship ie under some conditions the child can
wakeup the parent.
So there is no such relevance for wakeup device in runtime-pm

Re: External devices

[AYAN KUMAR HALDER]

Hi Ran,

Please find my replies as follows:-

> How does the driver invokes moving to idle state ?

The driver uses numerous apis to send its device to idle state. Some
of them are as follows:-
1. pm_runtime_put/pm_runtime_put_sync - which decreases the usage
count and ultimately calls pm_runtime_idle.
2. pm_runtime_idle - which calls the corresponding
driver->runtime_idle after checking the usage count
3. pm_request_idle - calls pm_runtime_idle

Is it the same as
> invoking runtime suspend by the driver ?

In some cases, eg In platform subsystem drivers , runtime_suspend gets
called from runtime_idle. eg Refer drivers/base/platform.c, the
runtime operations assigned are :-
static const struct dev_pm_ops platform_dev_pm_ops = {
        .runtime_suspend = pm_generic_runtime_suspend,
        .runtime_resume = pm_generic_runtime_resume,
        .runtime_idle = pm_generic_runtime_idle,
        USE_PLATFORM_PM_SLEEP_OPS
};
Here pm_generic_runtime_idle() after calling the driver specific
runtime_idle api, calls pm_runtime_suspend -->
pm_generic_runtime_suspend  ---> driver specific runtime suspend call.

> What is the difference between idle state to runtime suspend ?

I don't clearly understand the difference between idle state and
runtime suspend as in case of most devices (eg platform devices, usb
devices)
, I see that runtime_idle eventually calls runtime_suspend. eg
drivers/usb/core/usb.c , usb_runtime_idle() -----> pm_runtime_autosuspend()

> Are you familiar with any character device example for using PM ?

Check drivers/usb/core/usb.c.

Regards,
Ayan Kumar Halder

External devices

[AYAN KUMAR HALDER]

Hi Ran,

Please find my replies as follows:-

> How does the driver invokes moving to idle state ?

The driver uses numerous apis to send its device to idle state. Some
of them are as follows:-
1. pm_runtime_put/pm_runtime_put_sync - which decreases the usage
count and ultimately calls pm_runtime_idle.
2. pm_runtime_idle - which calls the corresponding
driver->runtime_idle after checking the usage count
3. pm_request_idle - calls pm_runtime_idle

Is it the same as
> invoking runtime suspend by the driver ?

In some cases, eg In platform subsystem drivers , runtime_suspend gets
called from runtime_idle. eg Refer drivers/base/platform.c, the
runtime operations assigned are :-
static const struct dev_pm_ops platform_dev_pm_ops = {
        .runtime_suspend = pm_generic_runtime_suspend,
        .runtime_resume = pm_generic_runtime_resume,
        .runtime_idle = pm_generic_runtime_idle,
        USE_PLATFORM_PM_SLEEP_OPS
};
Here pm_generic_runtime_idle() after calling the driver specific
runtime_idle api, calls pm_runtime_suspend -->
pm_generic_runtime_suspend  ---> driver specific runtime suspend call.

> What is the difference between idle state to runtime suspend ?

I don't clearly understand the difference between idle state and
runtime suspend as in case of most devices (eg platform devices, usb
devices)
, I see that runtime_idle eventually calls runtime_suspend. eg
drivers/usb/core/usb.c , usb_runtime_idle() -----> pm_runtime_autosuspend()

> Are you familiar with any character device example for using PM ?

Check drivers/usb/core/usb.c.

Regards,
Ayan Kumar Halder

External devices

[Ran Shalit]

On Tue, Sep 9, 2014 at 8:44 PM, AYAN KUMAR HALDER <ayankumarh@gmail.com> wrote:
>> Now, the thing I don't yet understand is what the wakeup source means
>> in this configuration. Wakeup only for a specific device driver ?
> Wakeup source has its relevance mostly for system suspend/resume where in
> a device (eg keyboard) can pull the system out of suspend mode.
>
> In Runtime-pm, the device is the wake-up source for itself unless there exist
> a parent-child relationship ie under some conditions the child can
> wakeup the parent.
> So there is no such relevance for wakeup device in runtime-pm

Thanks very very much. You've resolved my misunderstanding :)