Skip to contentSkip to conversation

devfreq: Add suspend and resume apis

PATCH MyungJoo Ham 2 participants 2 messages Oct 8, 2012 – Oct 15, 2012

lore
Share & tools
lore
#0 lore raw
Quoted 9 lines · Rafael J. Wysocki
Quoted 8 lines · On Thursday 04 of October 2012 14:58:33 Rajagopal Venkat wrote:
Quoted 6 lines

Add devfreq suspend/resume apis for devfreq users. This patch supports suspend and resume of devfreq load monitoring, required for devices which can idle.

Quoted 6 lines
Quoted 3 lines

Well, I wonder if this may be tied in to the runtime PM framework, so that, for example, pm_runtime_suspend() will automatically suspend devfreq on success (and the runtime resume of the device will resume devfreq)?

That's a good idea. If you agree, we can handle this as separate patch on top this patchset.

I guess implementing the idea may be not so obvious; thus, seperating the patchset would be appropriate.

When we implement the idea, we may need to implement at the pm_runtime core. Because devfreq->dev is a child of the target dev, not a parent, runtime-pm event of the target dev does not automatically invoke a cascaded action on the devfreq->dev.

Maybe either
1) capability to allow a child to monitor the power state of a parent (I remember Inki Dae once suggested to add notifiers at runtime-pm, but it seems to be not merged)
or
2) letting runtime-pm be aware of devfreq
(doesn't feel alright with this??)
is required?

Quoted 110 lines
Quoted 110 lines

Rafael

Quoted 105 lines
---
 drivers/devfreq/devfreq.c                 | 28 ++++++++++++++++++++++++++++
 drivers/devfreq/governor.h                |  2 ++
 drivers/devfreq/governor_simpleondemand.c |  9 +++++++++
 include/linux/devfreq.h                   | 12 ++++++++++++
 4 files changed, 51 insertions(+)
drivers/devfreq/devfreq.c +28 -0
index 41a4099..63e075e 100644
@@ -428,6 +428,34 @@ int devfreq_remove_device(struct devfreq *devfreq)
 }
 EXPORT_SYMBOL(devfreq_remove_device);
 
+/**
+ * devfreq_suspend_device() - Suspend devfreq of a device.
+ * @devfreq  the devfreq instance to be suspended
+ */
+int devfreq_suspend_device(struct devfreq *devfreq)
+{
+     if (!devfreq)
+             return -EINVAL;
+
+     return devfreq->governor->event_handler(devfreq,
+                             DEVFREQ_GOV_SUSPEND, NULL);
+}
+EXPORT_SYMBOL(devfreq_suspend_device);
+
+/**
+ * devfreq_resume_device() - Resume devfreq of a device.
+ * @devfreq  the devfreq instance to be resumed
+ */
+int devfreq_resume_device(struct devfreq *devfreq)
+{
+     if (!devfreq)
+             return -EINVAL;
+
+     return devfreq->governor->event_handler(devfreq,
+                             DEVFREQ_GOV_RESUME, NULL);
+}
+EXPORT_SYMBOL(devfreq_resume_device);
+
 static ssize_t show_governor(struct device *dev,
                           struct device_attribute *attr, char *buf)
 {
drivers/devfreq/governor.h +2 -0
index bb3aff3..26432ac 100644
@@ -22,6 +22,8 @@
 #define DEVFREQ_GOV_START                    0x1
 #define DEVFREQ_GOV_STOP                     0x2
 #define DEVFREQ_GOV_INTERVAL                 0x3
+#define DEVFREQ_GOV_SUSPEND                  0x4
+#define DEVFREQ_GOV_RESUME                   0x5
 
 /* Caution: devfreq->lock must be locked before calling update_devfreq */
 extern int update_devfreq(struct devfreq *devfreq);
drivers/devfreq/governor_simpleondemand.c +9 -0
index cf94218..a8ba78c 100644
@@ -104,6 +104,15 @@ int devfreq_simple_ondemand_handler(struct devfreq *devfreq,
      case DEVFREQ_GOV_INTERVAL:
              devfreq_interval_update(devfreq, (unsigned int *)data);
              break;
+
+     case DEVFREQ_GOV_SUSPEND:
+             devfreq_monitor_suspend(devfreq);
+             break;
+
+     case DEVFREQ_GOV_RESUME:
+             devfreq_monitor_resume(devfreq);
+             break;
+
      default:
              break;
      }
include/linux/devfreq.h +11 -0
index 9cdffde..ee243a3 100644
@@ -158,6 +158,8 @@ extern struct devfreq *devfreq_add_device(struct device *dev,
                                const struct devfreq_governor *governor,
                                void *data);
 extern int devfreq_remove_device(struct devfreq *devfreq);
+extern int devfreq_suspend_device(struct devfreq *devfreq);
+extern int devfreq_resume_device(struct devfreq *devfreq);
 
 /* Helper functions for devfreq user device driver with OPP. */
 extern struct opp *devfreq_recommended_opp(struct device *dev,
@@ -211,6 +213,16 @@ static int devfreq_remove_device(struct devfreq *devfreq)
      return 0;
 }
 
+static int devfreq_suspend_device(struct devfreq *devfreq)
+{
+     return 0;
+}
+
+static int devfreq_resume_device(struct devfreq *devfreq)
+{
+     return 0;
+}
Quoted 21 lines
Quoted 8 lines

include/linux/devfreq.h static int devfreq_remove_device(struct devfreq *devfreq) · line 228

Quoted 5 lines
include/linux/devfreq.h +1 -0
+
 static struct opp *devfreq_recommended_opp(struct device *dev,
                                         unsigned long *freq, u32 flags)
 {

--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Signature · 2 lines
Regards,
Rajagopal

�淸�{.n�+돴윯돪�+%듚�깁負쪐w��{.n�+돴쪐{깸G쳺��{ay����,j�f"톒쉹��묎�z_溫(�쉸듶줷"얎�m����G쳺�◀?솳鈺�&x�~뤳턨O뺞촾퇉v�^�m��� �띠�◀?뻀�

#1 lore raw
Quoted 9 lines · On Monday 08 of October 2012 10:48:24 MyungJoo Ham wrote:
Quoted 9 lines · Rafael J. Wysocki
Quoted 8 lines · On Thursday 04 of October 2012 14:58:33 Rajagopal Venkat wrote:
Quoted 6 lines

Add devfreq suspend/resume apis for devfreq users. This patch supports suspend and resume of devfreq load monitoring, required for devices which can idle.

Quoted 6 lines
Quoted 6 lines
Quoted 3 lines

Well, I wonder if this may be tied in to the runtime PM framework, so that, for example, pm_runtime_suspend() will automatically suspend devfreq on success (and the runtime resume of the device will resume devfreq)?

That's a good idea. If you agree, we can handle this as separate patch on top this patchset.

Sure.

Quoted 7 lines

I guess implementing the idea may be not so obvious; thus, seperating the patchset would be appropriate.

When we implement the idea, we may need to implement at the pm_runtime core. Because devfreq->dev is a child of the target dev, not a parent, runtime-pm event of the target dev does not automatically invoke a cascaded action on the devfreq->dev.

I'm not exactly sure what you mean, care to explain?

Quoted 8 lines

Maybe either
1) capability to allow a child to monitor the power state of a parent (I remember Inki Dae once suggested to add notifiers at runtime-pm, but it seems to be not merged)
or
2) letting runtime-pm be aware of devfreq
(doesn't feel alright with this??)
is required?

I'm not a big fan of notifiers, so I'd prefer to avoid using them, if possible.

Thanks,
Rafael

Signature · 2 lines
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.