summaryrefslogtreecommitdiff
path: root/include/linux/devfreq.h
diff options
context:
space:
mode:
authorChanwoo Choi <cw00.choi@samsung.com>2016-03-22 13:44:03 +0900
committerMyungJoo Ham <myungjoo.ham@samsung.com>2016-05-03 11:20:07 +0900
commit996133119f57334c38b020dbfaaac5b5eb127e29 (patch)
treee197b5d3bc8b7816db57c3bff4b509c6eb111a1f /include/linux/devfreq.h
parent0fe3a66410a3ba96679be903f1e287d7a0a264a9 (diff)
downloadlwn-996133119f57334c38b020dbfaaac5b5eb127e29.tar.gz
lwn-996133119f57334c38b020dbfaaac5b5eb127e29.zip
PM / devfreq: Add new passive governor
This patch adds the new passive governor for DEVFREQ framework. The following governors are already present and used for DVFS (Dynamic Voltage and Frequency Scaling) drivers. The following governors are independently used for one device driver which don't give the influence to other device drviers and also don't receive the effect from other device drivers. - ondemand / performance / powersave / userspace The passive governor depends on operation of parent driver with specific governos extremely and is not able to decide the new frequency by oneself. According to the decided new frequency of parent driver with governor, the passive governor uses it to decide the appropriate frequency for own device driver. The passive governor must need the following information from device tree: - the source clock and OPP tables - the instance of parent device For exameple, there are one more devfreq device drivers which need to change their source clock according to their utilization on runtime. But, they share the same power line (e.g., regulator). So, specific device driver is operated as parent with ondemand governor and then the rest device driver with passive governor is influenced by parent device. Suggested-by: Myungjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> [tjakobi: Reported RCU locking issue and cw00.choi fix it] Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [linux.amoon: Reported possible recursive locking and cw00.choi fix it] Reported-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Diffstat (limited to 'include/linux/devfreq.h')
-rw-r--r--include/linux/devfreq.h33
1 files changed, 33 insertions, 0 deletions
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c699304e12..2de4e2eea180 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -272,6 +272,39 @@ struct devfreq_simple_ondemand_data {
};
#endif
+#if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
+/**
+ * struct devfreq_passive_data - void *data fed to struct devfreq
+ * and devfreq_add_device
+ * @parent: the devfreq instance of parent device.
+ * @get_target_freq: Optional callback, Returns desired operating frequency
+ * for the device using passive governor. That is called
+ * when passive governor should decide the next frequency
+ * by using the new frequency of parent devfreq device
+ * using governors except for passive governor.
+ * If the devfreq device has the specific method to decide
+ * the next frequency, should use this callback.
+ * @this: the devfreq instance of own device.
+ * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
+ *
+ * The devfreq_passive_data have to set the devfreq instance of parent
+ * device with governors except for the passive governor. But, don't need to
+ * initialize the 'this' and 'nb' field because the devfreq core will handle
+ * them.
+ */
+struct devfreq_passive_data {
+ /* Should set the devfreq instance of parent device */
+ struct devfreq *parent;
+
+ /* Optional callback to decide the next frequency of passvice device */
+ int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
+
+ /* For passive governor's internal use. Don't need to set them */
+ struct devfreq *this;
+ struct notifier_block nb;
+};
+#endif
+
#else /* !CONFIG_PM_DEVFREQ */
static inline struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq_dev_profile *profile,