2019-06-04 16:11:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
/*
|
|
|
|
* devfreq: Generic Dynamic Voltage and Frequency Scaling (DVFS) Framework
|
|
|
|
* for Non-CPU Devices.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2011 Samsung Electronics
|
|
|
|
* MyungJoo Ham <myungjoo.ham@samsung.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
2018-07-04 16:45:50 +08:00
|
|
|
#include <linux/kmod.h>
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/init.h>
|
2016-06-26 02:43:47 +08:00
|
|
|
#include <linux/export.h>
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
#include <linux/slab.h>
|
2011-11-10 17:16:23 +08:00
|
|
|
#include <linux/stat.h>
|
2013-09-20 05:03:52 +08:00
|
|
|
#include <linux/pm_opp.h>
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
#include <linux/devfreq.h>
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/printk.h>
|
|
|
|
#include <linux/hrtimer.h>
|
2015-11-10 19:31:07 +08:00
|
|
|
#include <linux/of.h>
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
#include "governor.h"
|
|
|
|
|
2019-02-19 02:21:09 +08:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <trace/events/devfreq.h>
|
|
|
|
|
2012-10-26 07:50:53 +08:00
|
|
|
static struct class *devfreq_class;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
/*
|
2012-10-26 07:50:09 +08:00
|
|
|
* devfreq core provides delayed work based load monitoring helper
|
|
|
|
* functions. Governors can use these or can implement their own
|
|
|
|
* monitoring mechanism.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*/
|
|
|
|
static struct workqueue_struct *devfreq_wq;
|
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
/* The list of all device-devfreq governors */
|
|
|
|
static LIST_HEAD(devfreq_governor_list);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
/* The list of all device-devfreq */
|
|
|
|
static LIST_HEAD(devfreq_list);
|
|
|
|
static DEFINE_MUTEX(devfreq_list_lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* find_device_devfreq() - find devfreq struct using device pointer
|
|
|
|
* @dev: device pointer used to lookup device devfreq.
|
|
|
|
*
|
|
|
|
* Search the list of device devfreqs and return the matched device's
|
|
|
|
* devfreq info. devfreq_list_lock should be held by the caller.
|
|
|
|
*/
|
|
|
|
static struct devfreq *find_device_devfreq(struct device *dev)
|
|
|
|
{
|
|
|
|
struct devfreq *tmp_devfreq;
|
|
|
|
|
2015-08-10 14:12:25 +08:00
|
|
|
if (IS_ERR_OR_NULL(dev)) {
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
WARN(!mutex_is_locked(&devfreq_list_lock),
|
|
|
|
"devfreq_list_lock must be locked.");
|
|
|
|
|
|
|
|
list_for_each_entry(tmp_devfreq, &devfreq_list, node) {
|
|
|
|
if (tmp_devfreq->dev.parent == dev)
|
|
|
|
return tmp_devfreq;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
}
|
|
|
|
|
2017-10-23 09:32:06 +08:00
|
|
|
static unsigned long find_available_min_freq(struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
struct dev_pm_opp *opp;
|
|
|
|
unsigned long min_freq = 0;
|
|
|
|
|
|
|
|
opp = dev_pm_opp_find_freq_ceil(devfreq->dev.parent, &min_freq);
|
|
|
|
if (IS_ERR(opp))
|
|
|
|
min_freq = 0;
|
|
|
|
else
|
|
|
|
dev_pm_opp_put(opp);
|
|
|
|
|
|
|
|
return min_freq;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long find_available_max_freq(struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
struct dev_pm_opp *opp;
|
|
|
|
unsigned long max_freq = ULONG_MAX;
|
|
|
|
|
|
|
|
opp = dev_pm_opp_find_freq_floor(devfreq->dev.parent, &max_freq);
|
|
|
|
if (IS_ERR(opp))
|
|
|
|
max_freq = 0;
|
|
|
|
else
|
|
|
|
dev_pm_opp_put(opp);
|
|
|
|
|
|
|
|
return max_freq;
|
|
|
|
}
|
|
|
|
|
2012-08-23 19:00:46 +08:00
|
|
|
/**
|
|
|
|
* devfreq_get_freq_level() - Lookup freq_table for the frequency
|
|
|
|
* @devfreq: the devfreq instance
|
|
|
|
* @freq: the target frequency
|
|
|
|
*/
|
|
|
|
static int devfreq_get_freq_level(struct devfreq *devfreq, unsigned long freq)
|
|
|
|
{
|
|
|
|
int lev;
|
|
|
|
|
|
|
|
for (lev = 0; lev < devfreq->profile->max_state; lev++)
|
|
|
|
if (freq == devfreq->profile->freq_table[lev])
|
|
|
|
return lev;
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2017-10-23 09:32:09 +08:00
|
|
|
static int set_freq_table(struct devfreq *devfreq)
|
2015-11-18 13:49:02 +08:00
|
|
|
{
|
|
|
|
struct devfreq_dev_profile *profile = devfreq->profile;
|
|
|
|
struct dev_pm_opp *opp;
|
|
|
|
unsigned long freq;
|
|
|
|
int i, count;
|
|
|
|
|
|
|
|
/* Initialize the freq_table from OPP table */
|
|
|
|
count = dev_pm_opp_get_opp_count(devfreq->dev.parent);
|
|
|
|
if (count <= 0)
|
2017-10-23 09:32:09 +08:00
|
|
|
return -EINVAL;
|
2015-11-18 13:49:02 +08:00
|
|
|
|
|
|
|
profile->max_state = count;
|
|
|
|
profile->freq_table = devm_kcalloc(devfreq->dev.parent,
|
|
|
|
profile->max_state,
|
|
|
|
sizeof(*profile->freq_table),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!profile->freq_table) {
|
|
|
|
profile->max_state = 0;
|
2017-10-23 09:32:09 +08:00
|
|
|
return -ENOMEM;
|
2015-11-18 13:49:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0, freq = 0; i < profile->max_state; i++, freq++) {
|
|
|
|
opp = dev_pm_opp_find_freq_ceil(devfreq->dev.parent, &freq);
|
|
|
|
if (IS_ERR(opp)) {
|
|
|
|
devm_kfree(devfreq->dev.parent, profile->freq_table);
|
|
|
|
profile->max_state = 0;
|
2017-10-23 09:32:09 +08:00
|
|
|
return PTR_ERR(opp);
|
2015-11-18 13:49:02 +08:00
|
|
|
}
|
2017-01-23 12:41:47 +08:00
|
|
|
dev_pm_opp_put(opp);
|
2015-11-18 13:49:02 +08:00
|
|
|
profile->freq_table[i] = freq;
|
|
|
|
}
|
2017-10-23 09:32:09 +08:00
|
|
|
|
|
|
|
return 0;
|
2015-11-18 13:49:02 +08:00
|
|
|
}
|
|
|
|
|
2012-08-23 19:00:46 +08:00
|
|
|
/**
|
|
|
|
* devfreq_update_status() - Update statistics of devfreq behavior
|
|
|
|
* @devfreq: the devfreq instance
|
|
|
|
* @freq: the update target frequency
|
|
|
|
*/
|
2017-01-31 14:38:17 +08:00
|
|
|
int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
|
2012-08-23 19:00:46 +08:00
|
|
|
{
|
2014-02-28 11:38:57 +08:00
|
|
|
int lev, prev_lev, ret = 0;
|
2012-08-23 19:00:46 +08:00
|
|
|
unsigned long cur_time;
|
|
|
|
|
2019-09-24 15:52:23 +08:00
|
|
|
lockdep_assert_held(&devfreq->lock);
|
2012-08-23 19:00:46 +08:00
|
|
|
cur_time = jiffies;
|
2014-02-28 11:38:57 +08:00
|
|
|
|
2016-09-29 20:36:36 +08:00
|
|
|
/* Immediately exit if previous_freq is not initialized yet. */
|
|
|
|
if (!devfreq->previous_freq)
|
|
|
|
goto out;
|
|
|
|
|
2014-02-28 11:38:57 +08:00
|
|
|
prev_lev = devfreq_get_freq_level(devfreq, devfreq->previous_freq);
|
|
|
|
if (prev_lev < 0) {
|
|
|
|
ret = prev_lev;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
devfreq->time_in_state[prev_lev] +=
|
2012-08-23 19:00:46 +08:00
|
|
|
cur_time - devfreq->last_stat_updated;
|
2014-02-28 11:38:57 +08:00
|
|
|
|
|
|
|
lev = devfreq_get_freq_level(devfreq, freq);
|
|
|
|
if (lev < 0) {
|
|
|
|
ret = lev;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (lev != prev_lev) {
|
2012-08-23 19:00:46 +08:00
|
|
|
devfreq->trans_table[(prev_lev *
|
|
|
|
devfreq->profile->max_state) + lev]++;
|
|
|
|
devfreq->total_trans++;
|
|
|
|
}
|
|
|
|
|
2014-02-28 11:38:57 +08:00
|
|
|
out:
|
|
|
|
devfreq->last_stat_updated = cur_time;
|
|
|
|
return ret;
|
2012-08-23 19:00:46 +08:00
|
|
|
}
|
2017-01-31 14:38:17 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_update_status);
|
2012-08-23 19:00:46 +08:00
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
/**
|
|
|
|
* find_devfreq_governor() - find devfreq governor from name
|
|
|
|
* @name: name of the governor
|
|
|
|
*
|
|
|
|
* Search the list of devfreq governors and return the matched
|
|
|
|
* governor's pointer. devfreq_list_lock should be held by the caller.
|
|
|
|
*/
|
|
|
|
static struct devfreq_governor *find_devfreq_governor(const char *name)
|
|
|
|
{
|
|
|
|
struct devfreq_governor *tmp_governor;
|
|
|
|
|
2015-08-10 14:12:25 +08:00
|
|
|
if (IS_ERR_OR_NULL(name)) {
|
2012-10-30 04:01:43 +08:00
|
|
|
pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
WARN(!mutex_is_locked(&devfreq_list_lock),
|
|
|
|
"devfreq_list_lock must be locked.");
|
|
|
|
|
|
|
|
list_for_each_entry(tmp_governor, &devfreq_governor_list, node) {
|
|
|
|
if (!strncmp(tmp_governor->name, name, DEVFREQ_NAME_LEN))
|
|
|
|
return tmp_governor;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
}
|
|
|
|
|
2018-07-04 16:45:50 +08:00
|
|
|
/**
|
|
|
|
* try_then_request_governor() - Try to find the governor and request the
|
|
|
|
* module if is not found.
|
|
|
|
* @name: name of the governor
|
|
|
|
*
|
|
|
|
* Search the list of devfreq governors and request the module and try again
|
|
|
|
* if is not found. This can happen when both drivers (the governor driver
|
|
|
|
* and the driver that call devfreq_add_device) are built as modules.
|
|
|
|
* devfreq_list_lock should be held by the caller. Returns the matched
|
2019-03-13 20:22:53 +08:00
|
|
|
* governor's pointer or an error pointer.
|
2018-07-04 16:45:50 +08:00
|
|
|
*/
|
|
|
|
static struct devfreq_governor *try_then_request_governor(const char *name)
|
|
|
|
{
|
|
|
|
struct devfreq_governor *governor;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(name)) {
|
|
|
|
pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
WARN(!mutex_is_locked(&devfreq_list_lock),
|
|
|
|
"devfreq_list_lock must be locked.");
|
|
|
|
|
|
|
|
governor = find_devfreq_governor(name);
|
|
|
|
if (IS_ERR(governor)) {
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
|
|
|
|
if (!strncmp(name, DEVFREQ_GOV_SIMPLE_ONDEMAND,
|
|
|
|
DEVFREQ_NAME_LEN))
|
|
|
|
err = request_module("governor_%s", "simpleondemand");
|
|
|
|
else
|
|
|
|
err = request_module("governor_%s", name);
|
|
|
|
/* Restore previous state before return */
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
if (err)
|
2019-06-22 05:39:49 +08:00
|
|
|
return (err < 0) ? ERR_PTR(err) : ERR_PTR(-EINVAL);
|
2018-07-04 16:45:50 +08:00
|
|
|
|
|
|
|
governor = find_devfreq_governor(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
return governor;
|
|
|
|
}
|
|
|
|
|
2016-01-26 12:21:26 +08:00
|
|
|
static int devfreq_notify_transition(struct devfreq *devfreq,
|
|
|
|
struct devfreq_freqs *freqs, unsigned int state)
|
|
|
|
{
|
|
|
|
if (!devfreq)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
case DEVFREQ_PRECHANGE:
|
|
|
|
srcu_notifier_call_chain(&devfreq->transition_notifier_list,
|
|
|
|
DEVFREQ_PRECHANGE, freqs);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DEVFREQ_POSTCHANGE:
|
|
|
|
srcu_notifier_call_chain(&devfreq->transition_notifier_list,
|
|
|
|
DEVFREQ_POSTCHANGE, freqs);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-12-05 19:05:52 +08:00
|
|
|
static int devfreq_set_target(struct devfreq *devfreq, unsigned long new_freq,
|
|
|
|
u32 flags)
|
|
|
|
{
|
|
|
|
struct devfreq_freqs freqs;
|
|
|
|
unsigned long cur_freq;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (devfreq->profile->get_cur_freq)
|
|
|
|
devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
|
|
|
|
else
|
|
|
|
cur_freq = devfreq->previous_freq;
|
|
|
|
|
|
|
|
freqs.old = cur_freq;
|
|
|
|
freqs.new = new_freq;
|
|
|
|
devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
|
|
|
|
|
|
|
|
err = devfreq->profile->target(devfreq->dev.parent, &new_freq, flags);
|
|
|
|
if (err) {
|
|
|
|
freqs.new = cur_freq;
|
|
|
|
devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
freqs.new = new_freq;
|
|
|
|
devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
|
|
|
|
|
|
|
|
if (devfreq_update_status(devfreq, new_freq))
|
|
|
|
dev_err(&devfreq->dev,
|
|
|
|
"Couldn't update frequency transition information.\n");
|
|
|
|
|
|
|
|
devfreq->previous_freq = new_freq;
|
2018-12-05 19:05:53 +08:00
|
|
|
|
|
|
|
if (devfreq->suspend_freq)
|
|
|
|
devfreq->resume_freq = cur_freq;
|
|
|
|
|
2018-12-05 19:05:52 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
/* Load monitoring helper functions for governors use */
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
/**
|
|
|
|
* update_devfreq() - Reevaluate the device and configure frequency.
|
|
|
|
* @devfreq: the devfreq instance.
|
|
|
|
*
|
|
|
|
* Note: Lock devfreq->lock before calling update_devfreq
|
|
|
|
* This function is exported for governors.
|
|
|
|
*/
|
|
|
|
int update_devfreq(struct devfreq *devfreq)
|
|
|
|
{
|
2018-12-05 19:05:52 +08:00
|
|
|
unsigned long freq, min_freq, max_freq;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
int err = 0;
|
2012-03-17 04:54:53 +08:00
|
|
|
u32 flags = 0;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
if (!mutex_is_locked(&devfreq->lock)) {
|
|
|
|
WARN(true, "devfreq->lock must be locked by the caller.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-10-30 04:01:45 +08:00
|
|
|
if (!devfreq->governor)
|
|
|
|
return -EINVAL;
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
/* Reevaluate the proper frequency */
|
|
|
|
err = devfreq->governor->get_target_freq(devfreq, &freq);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2012-03-17 04:54:53 +08:00
|
|
|
/*
|
2017-10-23 09:32:08 +08:00
|
|
|
* Adjust the frequency with user freq, QoS and available freq.
|
2012-03-17 04:54:53 +08:00
|
|
|
*
|
2015-08-15 01:57:00 +08:00
|
|
|
* List from the highest priority
|
|
|
|
* max_freq
|
2012-03-17 04:54:53 +08:00
|
|
|
* min_freq
|
|
|
|
*/
|
2018-04-25 03:46:39 +08:00
|
|
|
max_freq = min(devfreq->scaling_max_freq, devfreq->max_freq);
|
|
|
|
min_freq = max(devfreq->scaling_min_freq, devfreq->min_freq);
|
2012-03-17 04:54:53 +08:00
|
|
|
|
2018-08-04 04:05:09 +08:00
|
|
|
if (freq < min_freq) {
|
2017-10-23 09:32:08 +08:00
|
|
|
freq = min_freq;
|
2012-03-17 04:54:53 +08:00
|
|
|
flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
|
|
|
|
}
|
2018-08-04 04:05:09 +08:00
|
|
|
if (freq > max_freq) {
|
2017-10-23 09:32:08 +08:00
|
|
|
freq = max_freq;
|
2012-03-17 04:54:53 +08:00
|
|
|
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
|
|
|
|
}
|
|
|
|
|
2018-12-05 19:05:52 +08:00
|
|
|
return devfreq_set_target(devfreq, freq, flags);
|
2016-01-26 12:21:26 +08:00
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
2012-10-30 04:01:42 +08:00
|
|
|
EXPORT_SYMBOL(update_devfreq);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
/**
|
|
|
|
* devfreq_monitor() - Periodically poll devfreq objects.
|
|
|
|
* @work: the work struct used to run devfreq_monitor periodically.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void devfreq_monitor(struct work_struct *work)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
struct devfreq *devfreq = container_of(work,
|
|
|
|
struct devfreq, work.work);
|
|
|
|
|
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
err = update_devfreq(devfreq);
|
|
|
|
if (err)
|
|
|
|
dev_err(&devfreq->dev, "dvfs failed with (%d) error\n", err);
|
|
|
|
|
|
|
|
queue_delayed_work(devfreq_wq, &devfreq->work,
|
|
|
|
msecs_to_jiffies(devfreq->profile->polling_ms));
|
|
|
|
mutex_unlock(&devfreq->lock);
|
2019-02-19 02:21:09 +08:00
|
|
|
|
|
|
|
trace_devfreq_monitor(devfreq);
|
2012-10-26 07:50:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_monitor_start() - Start load monitoring of devfreq instance
|
|
|
|
* @devfreq: the devfreq instance.
|
|
|
|
*
|
2019-05-03 02:27:36 +08:00
|
|
|
* Helper function for starting devfreq device load monitoring. By
|
2012-10-26 07:50:09 +08:00
|
|
|
* default delayed work based monitoring is supported. Function
|
|
|
|
* to be called from governor in response to DEVFREQ_GOV_START
|
|
|
|
* event when device is added to devfreq framework.
|
|
|
|
*/
|
|
|
|
void devfreq_monitor_start(struct devfreq *devfreq)
|
|
|
|
{
|
2019-11-05 05:56:14 +08:00
|
|
|
if (devfreq->governor->interrupt_driven)
|
|
|
|
return;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
INIT_DEFERRABLE_WORK(&devfreq->work, devfreq_monitor);
|
|
|
|
if (devfreq->profile->polling_ms)
|
|
|
|
queue_delayed_work(devfreq_wq, &devfreq->work,
|
|
|
|
msecs_to_jiffies(devfreq->profile->polling_ms));
|
|
|
|
}
|
2012-11-29 03:29:17 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_monitor_start);
|
2012-10-26 07:50:09 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_monitor_stop() - Stop load monitoring of a devfreq instance
|
|
|
|
* @devfreq: the devfreq instance.
|
|
|
|
*
|
2019-05-03 02:27:36 +08:00
|
|
|
* Helper function to stop devfreq device load monitoring. Function
|
2012-10-26 07:50:09 +08:00
|
|
|
* to be called from governor in response to DEVFREQ_GOV_STOP
|
|
|
|
* event when device is removed from devfreq framework.
|
|
|
|
*/
|
|
|
|
void devfreq_monitor_stop(struct devfreq *devfreq)
|
|
|
|
{
|
2019-11-05 05:56:14 +08:00
|
|
|
if (devfreq->governor->interrupt_driven)
|
|
|
|
return;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
cancel_delayed_work_sync(&devfreq->work);
|
|
|
|
}
|
2012-11-29 03:29:17 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_monitor_stop);
|
2012-10-26 07:50:09 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_monitor_suspend() - Suspend load monitoring of a devfreq instance
|
|
|
|
* @devfreq: the devfreq instance.
|
|
|
|
*
|
2019-05-03 02:27:36 +08:00
|
|
|
* Helper function to suspend devfreq device load monitoring. Function
|
2012-10-26 07:50:09 +08:00
|
|
|
* to be called from governor in response to DEVFREQ_GOV_SUSPEND
|
|
|
|
* event or when polling interval is set to zero.
|
|
|
|
*
|
|
|
|
* Note: Though this function is same as devfreq_monitor_stop(),
|
|
|
|
* intentionally kept separate to provide hooks for collecting
|
|
|
|
* transition statistics.
|
|
|
|
*/
|
|
|
|
void devfreq_monitor_suspend(struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
if (devfreq->stop_polling) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-01-08 13:50:39 +08:00
|
|
|
devfreq_update_status(devfreq, devfreq->previous_freq);
|
2012-10-26 07:50:09 +08:00
|
|
|
devfreq->stop_polling = true;
|
|
|
|
mutex_unlock(&devfreq->lock);
|
2019-11-05 05:56:14 +08:00
|
|
|
|
|
|
|
if (devfreq->governor->interrupt_driven)
|
|
|
|
return;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
cancel_delayed_work_sync(&devfreq->work);
|
|
|
|
}
|
2012-11-29 03:29:17 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_monitor_suspend);
|
2012-10-26 07:50:09 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_monitor_resume() - Resume load monitoring of a devfreq instance
|
|
|
|
* @devfreq: the devfreq instance.
|
|
|
|
*
|
2019-05-03 02:27:36 +08:00
|
|
|
* Helper function to resume devfreq device load monitoring. Function
|
2012-10-26 07:50:09 +08:00
|
|
|
* to be called from governor in response to DEVFREQ_GOV_RESUME
|
|
|
|
* event or when polling interval is set to non-zero.
|
|
|
|
*/
|
|
|
|
void devfreq_monitor_resume(struct devfreq *devfreq)
|
|
|
|
{
|
2013-01-08 13:50:39 +08:00
|
|
|
unsigned long freq;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
if (!devfreq->stop_polling)
|
|
|
|
goto out;
|
|
|
|
|
2019-11-05 05:56:14 +08:00
|
|
|
if (devfreq->governor->interrupt_driven)
|
|
|
|
goto out_update;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
if (!delayed_work_pending(&devfreq->work) &&
|
|
|
|
devfreq->profile->polling_ms)
|
|
|
|
queue_delayed_work(devfreq_wq, &devfreq->work,
|
|
|
|
msecs_to_jiffies(devfreq->profile->polling_ms));
|
2013-01-08 13:50:39 +08:00
|
|
|
|
2019-11-05 05:56:14 +08:00
|
|
|
out_update:
|
2013-01-08 13:50:39 +08:00
|
|
|
devfreq->last_stat_updated = jiffies;
|
2012-10-26 07:50:09 +08:00
|
|
|
devfreq->stop_polling = false;
|
|
|
|
|
2013-01-08 13:50:39 +08:00
|
|
|
if (devfreq->profile->get_cur_freq &&
|
|
|
|
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
|
|
|
|
devfreq->previous_freq = freq;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
out:
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
}
|
2012-11-29 03:29:17 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_monitor_resume);
|
2012-10-26 07:50:09 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_interval_update() - Update device devfreq monitoring interval
|
|
|
|
* @devfreq: the devfreq instance.
|
|
|
|
* @delay: new polling interval to be set.
|
|
|
|
*
|
|
|
|
* Helper function to set new load monitoring polling interval. Function
|
|
|
|
* to be called from governor in response to DEVFREQ_GOV_INTERVAL event.
|
|
|
|
*/
|
|
|
|
void devfreq_interval_update(struct devfreq *devfreq, unsigned int *delay)
|
|
|
|
{
|
|
|
|
unsigned int cur_delay = devfreq->profile->polling_ms;
|
|
|
|
unsigned int new_delay = *delay;
|
|
|
|
|
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
devfreq->profile->polling_ms = new_delay;
|
|
|
|
|
|
|
|
if (devfreq->stop_polling)
|
|
|
|
goto out;
|
|
|
|
|
2019-11-05 05:56:14 +08:00
|
|
|
if (devfreq->governor->interrupt_driven)
|
|
|
|
goto out;
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
/* if new delay is zero, stop polling */
|
|
|
|
if (!new_delay) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
cancel_delayed_work_sync(&devfreq->work);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if current delay is zero, start polling with new delay */
|
|
|
|
if (!cur_delay) {
|
|
|
|
queue_delayed_work(devfreq_wq, &devfreq->work,
|
|
|
|
msecs_to_jiffies(devfreq->profile->polling_ms));
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if current delay is greater than new delay, restart polling */
|
|
|
|
if (cur_delay > new_delay) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
cancel_delayed_work_sync(&devfreq->work);
|
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
if (!devfreq->stop_polling)
|
|
|
|
queue_delayed_work(devfreq_wq, &devfreq->work,
|
2019-01-21 10:11:07 +08:00
|
|
|
msecs_to_jiffies(devfreq->profile->polling_ms));
|
2012-10-26 07:50:09 +08:00
|
|
|
}
|
|
|
|
out:
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
}
|
2012-11-29 03:29:17 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_interval_update);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_notifier_call() - Notify that the device frequency requirements
|
2019-01-21 10:11:07 +08:00
|
|
|
* has been changed out of devfreq framework.
|
2012-10-26 07:50:35 +08:00
|
|
|
* @nb: the notifier_block (supposed to be devfreq->nb)
|
|
|
|
* @type: not used
|
|
|
|
* @devp: not used
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*
|
|
|
|
* Called by a notifier that uses devfreq->nb.
|
|
|
|
*/
|
|
|
|
static int devfreq_notifier_call(struct notifier_block *nb, unsigned long type,
|
|
|
|
void *devp)
|
|
|
|
{
|
|
|
|
struct devfreq *devfreq = container_of(nb, struct devfreq, nb);
|
2019-11-01 05:34:18 +08:00
|
|
|
int err = -EINVAL;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
mutex_lock(&devfreq->lock);
|
2017-10-23 09:32:08 +08:00
|
|
|
|
|
|
|
devfreq->scaling_min_freq = find_available_min_freq(devfreq);
|
2019-11-01 05:34:18 +08:00
|
|
|
if (!devfreq->scaling_min_freq)
|
|
|
|
goto out;
|
2017-10-23 09:32:08 +08:00
|
|
|
|
|
|
|
devfreq->scaling_max_freq = find_available_max_freq(devfreq);
|
2019-11-01 05:34:18 +08:00
|
|
|
if (!devfreq->scaling_max_freq)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
err = update_devfreq(devfreq);
|
2017-10-23 09:32:08 +08:00
|
|
|
|
2019-11-01 05:34:18 +08:00
|
|
|
out:
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
2019-11-01 05:34:18 +08:00
|
|
|
if (err)
|
|
|
|
dev_err(devfreq->dev.parent,
|
|
|
|
"failed to update frequency from OPP notifier (%d)\n",
|
|
|
|
err);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2019-11-01 05:34:18 +08:00
|
|
|
return NOTIFY_OK;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2017-01-31 14:38:18 +08:00
|
|
|
* devfreq_dev_release() - Callback for struct device to release the device.
|
|
|
|
* @dev: the devfreq device
|
|
|
|
*
|
|
|
|
* Remove devfreq from the list and release its resources.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*/
|
2017-01-31 14:38:18 +08:00
|
|
|
static void devfreq_dev_release(struct device *dev)
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
{
|
2017-01-31 14:38:18 +08:00
|
|
|
struct devfreq *devfreq = to_devfreq(dev);
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
dev_warn(&devfreq->dev, "releasing devfreq which doesn't exist\n");
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
return;
|
|
|
|
}
|
2012-10-26 07:50:09 +08:00
|
|
|
list_del(&devfreq->node);
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
if (devfreq->profile->exit)
|
|
|
|
devfreq->profile->exit(devfreq->dev.parent);
|
|
|
|
|
|
|
|
mutex_destroy(&devfreq->lock);
|
|
|
|
kfree(devfreq);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_add_device() - Add devfreq feature to the device
|
|
|
|
* @dev: the device to add devfreq feature.
|
|
|
|
* @profile: device-specific profile to run devfreq.
|
2012-10-30 04:01:45 +08:00
|
|
|
* @governor_name: name of the policy to choose frequency.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
* @data: private data for the governor. The devfreq framework does not
|
|
|
|
* touch this value.
|
|
|
|
*/
|
|
|
|
struct devfreq *devfreq_add_device(struct device *dev,
|
|
|
|
struct devfreq_dev_profile *profile,
|
2012-10-30 04:01:45 +08:00
|
|
|
const char *governor_name,
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct devfreq *devfreq;
|
2012-10-30 04:01:45 +08:00
|
|
|
struct devfreq_governor *governor;
|
2017-01-31 15:47:57 +08:00
|
|
|
static atomic_t devfreq_no = ATOMIC_INIT(-1);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
int err = 0;
|
|
|
|
|
2012-10-30 04:01:45 +08:00
|
|
|
if (!dev || !profile || !governor_name) {
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
dev_err(dev, "%s: Invalid parameters.\n", __func__);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
devfreq = find_device_devfreq(dev);
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
if (!IS_ERR(devfreq)) {
|
2019-09-19 08:09:46 +08:00
|
|
|
dev_err(dev, "%s: devfreq device already exists!\n",
|
2016-11-19 21:47:36 +08:00
|
|
|
__func__);
|
2012-10-26 07:50:09 +08:00
|
|
|
err = -EINVAL;
|
|
|
|
goto err_out;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
devfreq = kzalloc(sizeof(struct devfreq), GFP_KERNEL);
|
|
|
|
if (!devfreq) {
|
|
|
|
err = -ENOMEM;
|
2011-11-16 04:59:09 +08:00
|
|
|
goto err_out;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_init(&devfreq->lock);
|
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
devfreq->dev.parent = dev;
|
|
|
|
devfreq->dev.class = devfreq_class;
|
|
|
|
devfreq->dev.release = devfreq_dev_release;
|
|
|
|
devfreq->profile = profile;
|
2012-10-30 04:01:45 +08:00
|
|
|
strncpy(devfreq->governor_name, governor_name, DEVFREQ_NAME_LEN);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
devfreq->previous_freq = profile->initial_freq;
|
2016-05-31 18:25:09 +08:00
|
|
|
devfreq->last_status.current_frequency = profile->initial_freq;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
devfreq->data = data;
|
|
|
|
devfreq->nb.notifier_call = devfreq_notifier_call;
|
|
|
|
|
2015-11-18 13:49:02 +08:00
|
|
|
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
2017-10-23 09:32:09 +08:00
|
|
|
err = set_freq_table(devfreq);
|
|
|
|
if (err < 0)
|
2019-01-20 00:04:54 +08:00
|
|
|
goto err_dev;
|
2015-11-18 13:49:02 +08:00
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
}
|
|
|
|
|
2018-05-26 04:30:33 +08:00
|
|
|
devfreq->scaling_min_freq = find_available_min_freq(devfreq);
|
|
|
|
if (!devfreq->scaling_min_freq) {
|
2017-10-23 09:32:06 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_dev;
|
|
|
|
}
|
2018-05-26 04:30:33 +08:00
|
|
|
devfreq->min_freq = devfreq->scaling_min_freq;
|
2017-10-23 09:32:06 +08:00
|
|
|
|
2018-05-26 04:30:33 +08:00
|
|
|
devfreq->scaling_max_freq = find_available_max_freq(devfreq);
|
|
|
|
if (!devfreq->scaling_max_freq) {
|
2017-10-23 09:32:06 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_dev;
|
|
|
|
}
|
2018-05-26 04:30:33 +08:00
|
|
|
devfreq->max_freq = devfreq->scaling_max_freq;
|
2017-10-23 09:32:06 +08:00
|
|
|
|
2018-12-05 19:05:53 +08:00
|
|
|
devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
|
|
|
|
atomic_set(&devfreq->suspend_count, 0);
|
|
|
|
|
2017-01-31 15:47:57 +08:00
|
|
|
dev_set_name(&devfreq->dev, "devfreq%d",
|
|
|
|
atomic_inc_return(&devfreq_no));
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
err = device_register(&devfreq->dev);
|
|
|
|
if (err) {
|
2012-10-26 07:50:09 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
2018-03-30 19:44:03 +08:00
|
|
|
put_device(&devfreq->dev);
|
|
|
|
goto err_out;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
|
|
|
|
2019-01-21 10:11:07 +08:00
|
|
|
devfreq->trans_table = devm_kzalloc(&devfreq->dev,
|
|
|
|
array3_size(sizeof(unsigned int),
|
|
|
|
devfreq->profile->max_state,
|
|
|
|
devfreq->profile->max_state),
|
|
|
|
GFP_KERNEL);
|
2019-01-20 00:04:53 +08:00
|
|
|
if (!devfreq->trans_table) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto err_devfreq;
|
|
|
|
}
|
|
|
|
|
treewide: devm_kzalloc() -> devm_kcalloc()
The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc().
This patch replaces cases of:
devm_kzalloc(handle, a * b, gfp)
with:
devm_kcalloc(handle, a * b, gfp)
as well as handling cases of:
devm_kzalloc(handle, a * b * c, gfp)
with:
devm_kzalloc(handle, array3_size(a, b, c), gfp)
as it's slightly less ugly than:
devm_kcalloc(handle, array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
devm_kzalloc(handle, 4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
Some manual whitespace fixes were needed in this patch, as Coccinelle
really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...".
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
expression HANDLE;
type TYPE;
expression THING, E;
@@
(
devm_kzalloc(HANDLE,
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
devm_kzalloc(HANDLE,
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression HANDLE;
expression COUNT;
typedef u8;
typedef __u8;
@@
(
devm_kzalloc(HANDLE,
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(char) * COUNT
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
expression HANDLE;
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
expression HANDLE;
identifier SIZE, COUNT;
@@
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression HANDLE;
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
devm_kzalloc(HANDLE,
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression HANDLE;
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
expression HANDLE;
identifier STRIDE, SIZE, COUNT;
@@
(
devm_kzalloc(HANDLE,
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression HANDLE;
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
|
devm_kzalloc(HANDLE,
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
devm_kzalloc(HANDLE,
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
devm_kzalloc(HANDLE,
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
devm_kzalloc(HANDLE,
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression HANDLE;
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
devm_kzalloc(HANDLE, sizeof(THING) * C2, ...)
|
devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...)
|
devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
|
devm_kzalloc(HANDLE, C1 * C2, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- (E1) * E2
+ E1, E2
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- (E1) * (E2)
+ E1, E2
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-13 05:07:58 +08:00
|
|
|
devfreq->time_in_state = devm_kcalloc(&devfreq->dev,
|
2019-01-21 10:11:07 +08:00
|
|
|
devfreq->profile->max_state,
|
|
|
|
sizeof(unsigned long),
|
|
|
|
GFP_KERNEL);
|
2019-01-20 00:04:53 +08:00
|
|
|
if (!devfreq->time_in_state) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto err_devfreq;
|
|
|
|
}
|
|
|
|
|
2015-10-02 11:39:23 +08:00
|
|
|
devfreq->last_stat_updated = jiffies;
|
|
|
|
|
2016-01-26 12:21:26 +08:00
|
|
|
srcu_init_notifier_head(&devfreq->transition_notifier_list);
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
|
2018-07-04 16:45:50 +08:00
|
|
|
governor = try_then_request_governor(devfreq->governor_name);
|
2016-12-28 19:52:35 +08:00
|
|
|
if (IS_ERR(governor)) {
|
|
|
|
dev_err(dev, "%s: Unable to find governor for the device\n",
|
|
|
|
__func__);
|
|
|
|
err = PTR_ERR(governor);
|
|
|
|
goto err_init;
|
|
|
|
}
|
|
|
|
|
|
|
|
devfreq->governor = governor;
|
|
|
|
err = devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_START,
|
|
|
|
NULL);
|
2012-10-26 07:50:09 +08:00
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "%s: Unable to start governor for the device\n",
|
|
|
|
__func__);
|
|
|
|
goto err_init;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
2018-07-04 16:45:50 +08:00
|
|
|
|
|
|
|
list_add(&devfreq->node, &devfreq_list);
|
|
|
|
|
2016-09-29 10:13:28 +08:00
|
|
|
mutex_unlock(&devfreq_list_lock);
|
2012-10-26 07:50:09 +08:00
|
|
|
|
2011-11-16 04:59:09 +08:00
|
|
|
return devfreq;
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
err_init:
|
2016-09-29 10:13:28 +08:00
|
|
|
mutex_unlock(&devfreq_list_lock);
|
2019-01-20 00:04:53 +08:00
|
|
|
err_devfreq:
|
2018-09-03 08:02:07 +08:00
|
|
|
devfreq_remove_device(devfreq);
|
2018-03-30 19:44:03 +08:00
|
|
|
devfreq = NULL;
|
2017-08-24 09:42:48 +08:00
|
|
|
err_dev:
|
2018-09-21 21:18:43 +08:00
|
|
|
kfree(devfreq);
|
2011-11-16 04:59:09 +08:00
|
|
|
err_out:
|
|
|
|
return ERR_PTR(err);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
2012-10-26 07:50:09 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_add_device);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_remove_device() - Remove devfreq feature from a device.
|
2012-10-26 07:50:35 +08:00
|
|
|
* @devfreq: the devfreq instance to be removed
|
2013-02-05 17:40:17 +08:00
|
|
|
*
|
|
|
|
* The opposite of devfreq_add_device().
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*/
|
|
|
|
int devfreq_remove_device(struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
if (!devfreq)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-09-03 08:02:07 +08:00
|
|
|
if (devfreq->governor)
|
|
|
|
devfreq->governor->event_handler(devfreq,
|
|
|
|
DEVFREQ_GOV_STOP, NULL);
|
2014-05-09 15:43:07 +08:00
|
|
|
device_unregister(&devfreq->dev);
|
2011-11-15 06:31:29 +08:00
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2012-10-26 07:50:09 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_remove_device);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2014-05-09 15:43:08 +08:00
|
|
|
static int devm_devfreq_dev_match(struct device *dev, void *res, void *data)
|
|
|
|
{
|
|
|
|
struct devfreq **r = res;
|
|
|
|
|
|
|
|
if (WARN_ON(!r || !*r))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return *r == data;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void devm_devfreq_dev_release(struct device *dev, void *res)
|
|
|
|
{
|
|
|
|
devfreq_remove_device(*(struct devfreq **)res);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devm_devfreq_add_device() - Resource-managed devfreq_add_device()
|
|
|
|
* @dev: the device to add devfreq feature.
|
|
|
|
* @profile: device-specific profile to run devfreq.
|
|
|
|
* @governor_name: name of the policy to choose frequency.
|
|
|
|
* @data: private data for the governor. The devfreq framework does not
|
|
|
|
* touch this value.
|
|
|
|
*
|
|
|
|
* This function manages automatically the memory of devfreq device using device
|
|
|
|
* resource management and simplify the free operation for memory of devfreq
|
|
|
|
* device.
|
|
|
|
*/
|
|
|
|
struct devfreq *devm_devfreq_add_device(struct device *dev,
|
|
|
|
struct devfreq_dev_profile *profile,
|
|
|
|
const char *governor_name,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct devfreq **ptr, *devfreq;
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_devfreq_dev_release, sizeof(*ptr), GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
devfreq = devfreq_add_device(dev, profile, governor_name, data);
|
|
|
|
if (IS_ERR(devfreq)) {
|
|
|
|
devres_free(ptr);
|
2017-11-06 13:27:41 +08:00
|
|
|
return devfreq;
|
2014-05-09 15:43:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
*ptr = devfreq;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
|
|
|
|
return devfreq;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_devfreq_add_device);
|
|
|
|
|
2015-11-10 19:31:07 +08:00
|
|
|
#ifdef CONFIG_OF
|
|
|
|
/*
|
|
|
|
* devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
|
|
|
|
* @dev - instance to the given device
|
|
|
|
* @index - index into list of devfreq
|
|
|
|
*
|
|
|
|
* return the instance of devfreq device
|
|
|
|
*/
|
|
|
|
struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
|
|
|
|
{
|
|
|
|
struct device_node *node;
|
|
|
|
struct devfreq *devfreq;
|
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
if (!dev->of_node)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
node = of_parse_phandle(dev->of_node, "devfreq", index);
|
|
|
|
if (!node)
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
list_for_each_entry(devfreq, &devfreq_list, node) {
|
|
|
|
if (devfreq->dev.parent
|
|
|
|
&& devfreq->dev.parent->of_node == node) {
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
2016-07-01 17:42:00 +08:00
|
|
|
of_node_put(node);
|
2015-11-10 19:31:07 +08:00
|
|
|
return devfreq;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
2016-07-01 17:42:00 +08:00
|
|
|
of_node_put(node);
|
2015-11-10 19:31:07 +08:00
|
|
|
|
|
|
|
return ERR_PTR(-EPROBE_DEFER);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
|
|
|
|
{
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_OF */
|
|
|
|
EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
|
|
|
|
|
2014-05-09 15:43:08 +08:00
|
|
|
/**
|
|
|
|
* devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
|
2019-07-25 02:59:53 +08:00
|
|
|
* @dev: the device from which to remove devfreq feature.
|
2014-05-09 15:43:08 +08:00
|
|
|
* @devfreq: the devfreq instance to be removed
|
|
|
|
*/
|
|
|
|
void devm_devfreq_remove_device(struct device *dev, struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
WARN_ON(devres_release(dev, devm_devfreq_dev_release,
|
|
|
|
devm_devfreq_dev_match, devfreq));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_devfreq_remove_device);
|
|
|
|
|
2012-10-26 07:50:18 +08:00
|
|
|
/**
|
|
|
|
* devfreq_suspend_device() - Suspend devfreq of a device.
|
|
|
|
* @devfreq: the devfreq instance to be suspended
|
2013-02-05 17:40:17 +08:00
|
|
|
*
|
|
|
|
* This function is intended to be called by the pm callbacks
|
|
|
|
* (e.g., runtime_suspend, suspend) of the device driver that
|
|
|
|
* holds the devfreq.
|
2012-10-26 07:50:18 +08:00
|
|
|
*/
|
|
|
|
int devfreq_suspend_device(struct devfreq *devfreq)
|
|
|
|
{
|
2018-12-05 19:05:53 +08:00
|
|
|
int ret;
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
if (!devfreq)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-12-05 19:05:53 +08:00
|
|
|
if (atomic_inc_return(&devfreq->suspend_count) > 1)
|
2012-10-30 04:01:45 +08:00
|
|
|
return 0;
|
|
|
|
|
2018-12-05 19:05:53 +08:00
|
|
|
if (devfreq->governor) {
|
|
|
|
ret = devfreq->governor->event_handler(devfreq,
|
|
|
|
DEVFREQ_GOV_SUSPEND, NULL);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (devfreq->suspend_freq) {
|
2019-11-12 18:47:34 +08:00
|
|
|
mutex_lock(&devfreq->lock);
|
2018-12-05 19:05:53 +08:00
|
|
|
ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
|
2019-11-12 18:47:34 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
2018-12-05 19:05:53 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2012-10-26 07:50:18 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devfreq_suspend_device);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_resume_device() - Resume devfreq of a device.
|
|
|
|
* @devfreq: the devfreq instance to be resumed
|
2013-02-05 17:40:17 +08:00
|
|
|
*
|
|
|
|
* This function is intended to be called by the pm callbacks
|
|
|
|
* (e.g., runtime_resume, resume) of the device driver that
|
|
|
|
* holds the devfreq.
|
2012-10-26 07:50:18 +08:00
|
|
|
*/
|
|
|
|
int devfreq_resume_device(struct devfreq *devfreq)
|
|
|
|
{
|
2018-12-05 19:05:53 +08:00
|
|
|
int ret;
|
|
|
|
|
2012-10-26 07:50:18 +08:00
|
|
|
if (!devfreq)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-12-05 19:05:53 +08:00
|
|
|
if (atomic_dec_return(&devfreq->suspend_count) >= 1)
|
2012-10-30 04:01:45 +08:00
|
|
|
return 0;
|
|
|
|
|
2018-12-05 19:05:53 +08:00
|
|
|
if (devfreq->resume_freq) {
|
2019-11-12 18:47:34 +08:00
|
|
|
mutex_lock(&devfreq->lock);
|
2018-12-05 19:05:53 +08:00
|
|
|
ret = devfreq_set_target(devfreq, devfreq->resume_freq, 0);
|
2019-11-12 18:47:34 +08:00
|
|
|
mutex_unlock(&devfreq->lock);
|
2018-12-05 19:05:53 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (devfreq->governor) {
|
|
|
|
ret = devfreq->governor->event_handler(devfreq,
|
|
|
|
DEVFREQ_GOV_RESUME, NULL);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2012-10-26 07:50:18 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devfreq_resume_device);
|
|
|
|
|
2018-12-05 19:05:54 +08:00
|
|
|
/**
|
|
|
|
* devfreq_suspend() - Suspend devfreq governors and devices
|
|
|
|
*
|
|
|
|
* Called during system wide Suspend/Hibernate cycles for suspending governors
|
|
|
|
* and devices preserving the state for resume. On some platforms the devfreq
|
|
|
|
* device must have precise state (frequency) after resume in order to provide
|
|
|
|
* fully operating setup.
|
|
|
|
*/
|
|
|
|
void devfreq_suspend(void)
|
|
|
|
{
|
|
|
|
struct devfreq *devfreq;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
list_for_each_entry(devfreq, &devfreq_list, node) {
|
|
|
|
ret = devfreq_suspend_device(devfreq);
|
|
|
|
if (ret)
|
|
|
|
dev_err(&devfreq->dev,
|
|
|
|
"failed to suspend devfreq device\n");
|
|
|
|
}
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_resume() - Resume devfreq governors and devices
|
|
|
|
*
|
|
|
|
* Called during system wide Suspend/Hibernate cycle for resuming governors and
|
|
|
|
* devices that are suspended with devfreq_suspend().
|
|
|
|
*/
|
|
|
|
void devfreq_resume(void)
|
|
|
|
{
|
|
|
|
struct devfreq *devfreq;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
list_for_each_entry(devfreq, &devfreq_list, node) {
|
|
|
|
ret = devfreq_resume_device(devfreq);
|
|
|
|
if (ret)
|
|
|
|
dev_warn(&devfreq->dev,
|
|
|
|
"failed to resume devfreq device\n");
|
|
|
|
}
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
}
|
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
/**
|
|
|
|
* devfreq_add_governor() - Add devfreq governor
|
|
|
|
* @governor: the devfreq governor to be added
|
|
|
|
*/
|
|
|
|
int devfreq_add_governor(struct devfreq_governor *governor)
|
|
|
|
{
|
|
|
|
struct devfreq_governor *g;
|
2012-10-30 04:01:45 +08:00
|
|
|
struct devfreq *devfreq;
|
2012-10-30 04:01:43 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (!governor) {
|
|
|
|
pr_err("%s: Invalid parameters.\n", __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
g = find_devfreq_governor(governor->name);
|
|
|
|
if (!IS_ERR(g)) {
|
|
|
|
pr_err("%s: governor %s already registered\n", __func__,
|
|
|
|
g->name);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_out;
|
|
|
|
}
|
2011-11-15 06:31:29 +08:00
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
list_add(&governor->node, &devfreq_governor_list);
|
|
|
|
|
2012-10-30 04:01:45 +08:00
|
|
|
list_for_each_entry(devfreq, &devfreq_list, node) {
|
|
|
|
int ret = 0;
|
|
|
|
struct device *dev = devfreq->dev.parent;
|
|
|
|
|
|
|
|
if (!strncmp(devfreq->governor_name, governor->name,
|
|
|
|
DEVFREQ_NAME_LEN)) {
|
|
|
|
/* The following should never occur */
|
|
|
|
if (devfreq->governor) {
|
|
|
|
dev_warn(dev,
|
|
|
|
"%s: Governor %s already present\n",
|
|
|
|
__func__, devfreq->governor->name);
|
|
|
|
ret = devfreq->governor->event_handler(devfreq,
|
|
|
|
DEVFREQ_GOV_STOP, NULL);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(dev,
|
|
|
|
"%s: Governor %s stop = %d\n",
|
|
|
|
__func__,
|
|
|
|
devfreq->governor->name, ret);
|
|
|
|
}
|
|
|
|
/* Fall through */
|
|
|
|
}
|
|
|
|
devfreq->governor = governor;
|
|
|
|
ret = devfreq->governor->event_handler(devfreq,
|
|
|
|
DEVFREQ_GOV_START, NULL);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(dev, "%s: Governor %s start=%d\n",
|
|
|
|
__func__, devfreq->governor->name,
|
|
|
|
ret);
|
|
|
|
}
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
err_out:
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devfreq_add_governor);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2012-10-30 04:01:43 +08:00
|
|
|
/**
|
2016-11-09 09:29:14 +08:00
|
|
|
* devfreq_remove_governor() - Remove devfreq feature from a device.
|
2012-10-30 04:01:43 +08:00
|
|
|
* @governor: the devfreq governor to be removed
|
|
|
|
*/
|
|
|
|
int devfreq_remove_governor(struct devfreq_governor *governor)
|
|
|
|
{
|
|
|
|
struct devfreq_governor *g;
|
2012-10-30 04:01:45 +08:00
|
|
|
struct devfreq *devfreq;
|
2012-10-30 04:01:43 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (!governor) {
|
|
|
|
pr_err("%s: Invalid parameters.\n", __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
|
|
|
g = find_devfreq_governor(governor->name);
|
|
|
|
if (IS_ERR(g)) {
|
|
|
|
pr_err("%s: governor %s not registered\n", __func__,
|
2012-11-21 13:06:13 +08:00
|
|
|
governor->name);
|
2012-11-21 13:06:14 +08:00
|
|
|
err = PTR_ERR(g);
|
2012-10-30 04:01:43 +08:00
|
|
|
goto err_out;
|
|
|
|
}
|
2012-10-30 04:01:45 +08:00
|
|
|
list_for_each_entry(devfreq, &devfreq_list, node) {
|
|
|
|
int ret;
|
|
|
|
struct device *dev = devfreq->dev.parent;
|
|
|
|
|
|
|
|
if (!strncmp(devfreq->governor_name, governor->name,
|
|
|
|
DEVFREQ_NAME_LEN)) {
|
|
|
|
/* we should have a devfreq governor! */
|
|
|
|
if (!devfreq->governor) {
|
|
|
|
dev_warn(dev, "%s: Governor %s NOT present\n",
|
|
|
|
__func__, governor->name);
|
|
|
|
continue;
|
|
|
|
/* Fall through */
|
|
|
|
}
|
|
|
|
ret = devfreq->governor->event_handler(devfreq,
|
|
|
|
DEVFREQ_GOV_STOP, NULL);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(dev, "%s: Governor %s stop=%d\n",
|
|
|
|
__func__, devfreq->governor->name,
|
|
|
|
ret);
|
|
|
|
}
|
|
|
|
devfreq->governor = NULL;
|
|
|
|
}
|
|
|
|
}
|
2012-10-30 04:01:43 +08:00
|
|
|
|
|
|
|
list_del(&governor->node);
|
|
|
|
err_out:
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
|
|
|
|
return err;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
2012-10-30 04:01:43 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_remove_governor);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t governor_show(struct device *dev,
|
2011-10-02 06:19:28 +08:00
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
2012-10-30 04:01:45 +08:00
|
|
|
if (!to_devfreq(dev)->governor)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2011-10-02 06:19:28 +08:00
|
|
|
return sprintf(buf, "%s\n", to_devfreq(dev)->governor->name);
|
|
|
|
}
|
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
|
2012-10-30 04:01:47 +08:00
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct devfreq *df = to_devfreq(dev);
|
|
|
|
int ret;
|
|
|
|
char str_governor[DEVFREQ_NAME_LEN + 1];
|
2019-03-11 18:06:30 +08:00
|
|
|
const struct devfreq_governor *governor, *prev_governor;
|
2012-10-30 04:01:47 +08:00
|
|
|
|
|
|
|
ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
|
|
|
|
if (ret != 1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
2018-07-04 16:45:50 +08:00
|
|
|
governor = try_then_request_governor(str_governor);
|
2012-10-30 04:01:47 +08:00
|
|
|
if (IS_ERR(governor)) {
|
|
|
|
ret = PTR_ERR(governor);
|
|
|
|
goto out;
|
|
|
|
}
|
2015-09-22 02:23:52 +08:00
|
|
|
if (df->governor == governor) {
|
|
|
|
ret = 0;
|
2012-10-30 04:01:47 +08:00
|
|
|
goto out;
|
2017-12-07 04:20:15 +08:00
|
|
|
} else if ((df->governor && df->governor->immutable) ||
|
|
|
|
governor->immutable) {
|
2017-01-31 14:38:16 +08:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
2015-09-22 02:23:52 +08:00
|
|
|
}
|
2012-10-30 04:01:47 +08:00
|
|
|
|
|
|
|
if (df->governor) {
|
|
|
|
ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
|
|
|
|
if (ret) {
|
|
|
|
dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
|
|
|
|
__func__, df->governor->name, ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
2019-03-11 18:06:30 +08:00
|
|
|
prev_governor = df->governor;
|
2012-10-30 04:01:47 +08:00
|
|
|
df->governor = governor;
|
|
|
|
strncpy(df->governor_name, governor->name, DEVFREQ_NAME_LEN);
|
|
|
|
ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
|
2019-03-11 18:06:30 +08:00
|
|
|
if (ret) {
|
2012-10-30 04:01:47 +08:00
|
|
|
dev_warn(dev, "%s: Governor %s not started(%d)\n",
|
|
|
|
__func__, df->governor->name, ret);
|
2019-03-11 18:06:30 +08:00
|
|
|
df->governor = prev_governor;
|
|
|
|
strncpy(df->governor_name, prev_governor->name,
|
|
|
|
DEVFREQ_NAME_LEN);
|
|
|
|
ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev,
|
|
|
|
"%s: reverting to Governor %s failed (%d)\n",
|
|
|
|
__func__, df->governor_name, ret);
|
|
|
|
df->governor = NULL;
|
|
|
|
}
|
|
|
|
}
|
2012-10-30 04:01:47 +08:00
|
|
|
out:
|
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
ret = count;
|
|
|
|
return ret;
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RW(governor);
|
|
|
|
|
|
|
|
static ssize_t available_governors_show(struct device *d,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *buf)
|
2012-10-30 04:01:48 +08:00
|
|
|
{
|
2017-01-31 14:38:16 +08:00
|
|
|
struct devfreq *df = to_devfreq(d);
|
2012-10-30 04:01:48 +08:00
|
|
|
ssize_t count = 0;
|
|
|
|
|
|
|
|
mutex_lock(&devfreq_list_lock);
|
2017-01-31 14:38:16 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The devfreq with immutable governor (e.g., passive) shows
|
|
|
|
* only own governor.
|
|
|
|
*/
|
2019-09-24 15:26:53 +08:00
|
|
|
if (df->governor && df->governor->immutable) {
|
2017-01-31 14:38:16 +08:00
|
|
|
count = scnprintf(&buf[count], DEVFREQ_NAME_LEN,
|
2019-01-21 10:11:07 +08:00
|
|
|
"%s ", df->governor_name);
|
2017-01-31 14:38:16 +08:00
|
|
|
/*
|
|
|
|
* The devfreq device shows the registered governor except for
|
|
|
|
* immutable governors such as passive governor .
|
|
|
|
*/
|
|
|
|
} else {
|
|
|
|
struct devfreq_governor *governor;
|
|
|
|
|
|
|
|
list_for_each_entry(governor, &devfreq_governor_list, node) {
|
|
|
|
if (governor->immutable)
|
|
|
|
continue;
|
|
|
|
count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
|
|
|
|
"%s ", governor->name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-30 04:01:48 +08:00
|
|
|
mutex_unlock(&devfreq_list_lock);
|
|
|
|
|
|
|
|
/* Truncate the trailing space */
|
|
|
|
if (count)
|
|
|
|
count--;
|
|
|
|
|
|
|
|
count += sprintf(&buf[count], "\n");
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RO(available_governors);
|
2012-10-30 04:01:47 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t cur_freq_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
2012-10-26 07:50:26 +08:00
|
|
|
{
|
|
|
|
unsigned long freq;
|
|
|
|
struct devfreq *devfreq = to_devfreq(dev);
|
|
|
|
|
|
|
|
if (devfreq->profile->get_cur_freq &&
|
|
|
|
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
|
2016-11-19 21:47:36 +08:00
|
|
|
return sprintf(buf, "%lu\n", freq);
|
2012-10-26 07:50:26 +08:00
|
|
|
|
|
|
|
return sprintf(buf, "%lu\n", devfreq->previous_freq);
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RO(cur_freq);
|
2012-10-26 07:50:26 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t target_freq_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
2011-10-02 06:19:28 +08:00
|
|
|
{
|
|
|
|
return sprintf(buf, "%lu\n", to_devfreq(dev)->previous_freq);
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RO(target_freq);
|
2011-10-02 06:19:28 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t polling_interval_show(struct device *dev,
|
2011-10-02 06:19:28 +08:00
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
|
|
|
|
}
|
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t polling_interval_store(struct device *dev,
|
2011-10-02 06:19:28 +08:00
|
|
|
struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct devfreq *df = to_devfreq(dev);
|
|
|
|
unsigned int value;
|
|
|
|
int ret;
|
|
|
|
|
2012-10-30 04:01:45 +08:00
|
|
|
if (!df->governor)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2011-10-02 06:19:28 +08:00
|
|
|
ret = sscanf(buf, "%u", &value);
|
|
|
|
if (ret != 1)
|
2012-10-26 07:50:43 +08:00
|
|
|
return -EINVAL;
|
2011-10-02 06:19:28 +08:00
|
|
|
|
2012-10-26 07:50:09 +08:00
|
|
|
df->governor->event_handler(df, DEVFREQ_GOV_INTERVAL, &value);
|
2011-10-02 06:19:28 +08:00
|
|
|
ret = count;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RW(polling_interval);
|
2011-10-02 06:19:28 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t min_freq_store(struct device *dev, struct device_attribute *attr,
|
2011-12-09 15:42:19 +08:00
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct devfreq *df = to_devfreq(dev);
|
|
|
|
unsigned long value;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = sscanf(buf, "%lu", &value);
|
|
|
|
if (ret != 1)
|
2012-10-26 07:50:43 +08:00
|
|
|
return -EINVAL;
|
2011-12-09 15:42:19 +08:00
|
|
|
|
|
|
|
mutex_lock(&df->lock);
|
2018-08-04 04:05:09 +08:00
|
|
|
|
|
|
|
if (value) {
|
|
|
|
if (value > df->max_freq) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
unsigned long *freq_table = df->profile->freq_table;
|
|
|
|
|
|
|
|
/* Get minimum frequency according to sorting order */
|
|
|
|
if (freq_table[0] < freq_table[df->profile->max_state - 1])
|
|
|
|
value = freq_table[0];
|
|
|
|
else
|
|
|
|
value = freq_table[df->profile->max_state - 1];
|
2011-12-09 15:42:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
df->min_freq = value;
|
|
|
|
update_devfreq(df);
|
|
|
|
ret = count;
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&df->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-10-23 09:32:07 +08:00
|
|
|
static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
2017-10-23 09:32:08 +08:00
|
|
|
struct devfreq *df = to_devfreq(dev);
|
|
|
|
|
2018-04-25 03:46:39 +08:00
|
|
|
return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq));
|
2017-10-23 09:32:07 +08:00
|
|
|
}
|
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
|
2011-12-09 15:42:19 +08:00
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct devfreq *df = to_devfreq(dev);
|
|
|
|
unsigned long value;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = sscanf(buf, "%lu", &value);
|
|
|
|
if (ret != 1)
|
2012-10-26 07:50:43 +08:00
|
|
|
return -EINVAL;
|
2011-12-09 15:42:19 +08:00
|
|
|
|
|
|
|
mutex_lock(&df->lock);
|
2018-08-04 04:05:09 +08:00
|
|
|
|
|
|
|
if (value) {
|
|
|
|
if (value < df->min_freq) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
unsigned long *freq_table = df->profile->freq_table;
|
|
|
|
|
|
|
|
/* Get maximum frequency according to sorting order */
|
|
|
|
if (freq_table[0] < freq_table[df->profile->max_state - 1])
|
|
|
|
value = freq_table[df->profile->max_state - 1];
|
|
|
|
else
|
|
|
|
value = freq_table[0];
|
2011-12-09 15:42:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
df->max_freq = value;
|
|
|
|
update_devfreq(df);
|
|
|
|
ret = count;
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&df->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
2017-10-23 09:32:07 +08:00
|
|
|
static DEVICE_ATTR_RW(min_freq);
|
2011-12-09 15:42:19 +08:00
|
|
|
|
2017-10-23 09:32:07 +08:00
|
|
|
static ssize_t max_freq_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
2017-10-23 09:32:08 +08:00
|
|
|
struct devfreq *df = to_devfreq(dev);
|
|
|
|
|
2018-04-25 03:46:39 +08:00
|
|
|
return sprintf(buf, "%lu\n", min(df->scaling_max_freq, df->max_freq));
|
2011-12-09 15:42:19 +08:00
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RW(max_freq);
|
2011-12-09 15:42:19 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t available_frequencies_show(struct device *d,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *buf)
|
2012-10-26 08:48:59 +08:00
|
|
|
{
|
|
|
|
struct devfreq *df = to_devfreq(d);
|
|
|
|
ssize_t count = 0;
|
2017-10-23 09:32:10 +08:00
|
|
|
int i;
|
2012-10-26 08:48:59 +08:00
|
|
|
|
2017-10-23 09:32:10 +08:00
|
|
|
mutex_lock(&df->lock);
|
2012-10-26 08:48:59 +08:00
|
|
|
|
2017-10-23 09:32:10 +08:00
|
|
|
for (i = 0; i < df->profile->max_state; i++)
|
2012-10-26 08:48:59 +08:00
|
|
|
count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
|
2017-10-23 09:32:10 +08:00
|
|
|
"%lu ", df->profile->freq_table[i]);
|
2012-10-26 08:48:59 +08:00
|
|
|
|
2017-10-23 09:32:10 +08:00
|
|
|
mutex_unlock(&df->lock);
|
2012-10-26 08:48:59 +08:00
|
|
|
/* Truncate the trailing space */
|
|
|
|
if (count)
|
|
|
|
count--;
|
|
|
|
|
|
|
|
count += sprintf(&buf[count], "\n");
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RO(available_frequencies);
|
2012-10-26 08:48:59 +08:00
|
|
|
|
2013-07-25 06:05:09 +08:00
|
|
|
static ssize_t trans_stat_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
2012-08-23 19:00:46 +08:00
|
|
|
{
|
|
|
|
struct devfreq *devfreq = to_devfreq(dev);
|
|
|
|
ssize_t len;
|
2013-01-08 13:50:39 +08:00
|
|
|
int i, j;
|
2012-08-23 19:00:46 +08:00
|
|
|
unsigned int max_state = devfreq->profile->max_state;
|
|
|
|
|
2015-11-23 14:45:36 +08:00
|
|
|
if (max_state == 0)
|
|
|
|
return sprintf(buf, "Not Supported.\n");
|
2012-08-23 19:00:46 +08:00
|
|
|
|
2019-09-24 15:52:23 +08:00
|
|
|
mutex_lock(&devfreq->lock);
|
|
|
|
if (!devfreq->stop_polling &&
|
|
|
|
devfreq_update_status(devfreq, devfreq->previous_freq)) {
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
mutex_unlock(&devfreq->lock);
|
|
|
|
|
2015-11-19 15:28:46 +08:00
|
|
|
len = sprintf(buf, " From : To\n");
|
|
|
|
len += sprintf(buf + len, " :");
|
2012-08-23 19:00:46 +08:00
|
|
|
for (i = 0; i < max_state; i++)
|
2015-11-19 15:28:46 +08:00
|
|
|
len += sprintf(buf + len, "%10lu",
|
2012-08-23 19:00:46 +08:00
|
|
|
devfreq->profile->freq_table[i]);
|
|
|
|
|
|
|
|
len += sprintf(buf + len, " time(ms)\n");
|
|
|
|
|
|
|
|
for (i = 0; i < max_state; i++) {
|
|
|
|
if (devfreq->profile->freq_table[i]
|
|
|
|
== devfreq->previous_freq) {
|
|
|
|
len += sprintf(buf + len, "*");
|
|
|
|
} else {
|
|
|
|
len += sprintf(buf + len, " ");
|
|
|
|
}
|
2015-11-19 15:28:46 +08:00
|
|
|
len += sprintf(buf + len, "%10lu:",
|
2012-08-23 19:00:46 +08:00
|
|
|
devfreq->profile->freq_table[i]);
|
|
|
|
for (j = 0; j < max_state; j++)
|
2015-11-19 15:28:46 +08:00
|
|
|
len += sprintf(buf + len, "%10u",
|
2012-08-23 19:00:46 +08:00
|
|
|
devfreq->trans_table[(i * max_state) + j]);
|
|
|
|
len += sprintf(buf + len, "%10u\n",
|
|
|
|
jiffies_to_msecs(devfreq->time_in_state[i]));
|
|
|
|
}
|
|
|
|
|
|
|
|
len += sprintf(buf + len, "Total transition : %u\n",
|
|
|
|
devfreq->total_trans);
|
|
|
|
return len;
|
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
static DEVICE_ATTR_RO(trans_stat);
|
|
|
|
|
|
|
|
static struct attribute *devfreq_attrs[] = {
|
|
|
|
&dev_attr_governor.attr,
|
|
|
|
&dev_attr_available_governors.attr,
|
|
|
|
&dev_attr_cur_freq.attr,
|
|
|
|
&dev_attr_available_frequencies.attr,
|
|
|
|
&dev_attr_target_freq.attr,
|
|
|
|
&dev_attr_polling_interval.attr,
|
|
|
|
&dev_attr_min_freq.attr,
|
|
|
|
&dev_attr_max_freq.attr,
|
|
|
|
&dev_attr_trans_stat.attr,
|
|
|
|
NULL,
|
2011-10-02 06:19:28 +08:00
|
|
|
};
|
2013-07-25 06:05:09 +08:00
|
|
|
ATTRIBUTE_GROUPS(devfreq);
|
2011-10-02 06:19:28 +08:00
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
static int __init devfreq_init(void)
|
|
|
|
{
|
|
|
|
devfreq_class = class_create(THIS_MODULE, "devfreq");
|
|
|
|
if (IS_ERR(devfreq_class)) {
|
|
|
|
pr_err("%s: couldn't create class\n", __FILE__);
|
|
|
|
return PTR_ERR(devfreq_class);
|
|
|
|
}
|
2012-10-26 07:50:09 +08:00
|
|
|
|
|
|
|
devfreq_wq = create_freezable_workqueue("devfreq_wq");
|
2013-08-15 15:55:10 +08:00
|
|
|
if (!devfreq_wq) {
|
2012-10-26 07:50:09 +08:00
|
|
|
class_destroy(devfreq_class);
|
|
|
|
pr_err("%s: couldn't create workqueue\n", __FILE__);
|
2013-08-15 15:55:10 +08:00
|
|
|
return -ENOMEM;
|
2012-10-26 07:50:09 +08:00
|
|
|
}
|
2013-07-25 06:05:09 +08:00
|
|
|
devfreq_class->dev_groups = devfreq_groups;
|
2012-10-26 07:50:09 +08:00
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
subsys_initcall(devfreq_init);
|
|
|
|
|
|
|
|
/*
|
2017-02-28 06:29:56 +08:00
|
|
|
* The following are helper functions for devfreq user device drivers with
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
* OPP framework.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_recommended_opp() - Helper function to get proper OPP for the
|
|
|
|
* freq value given to target callback.
|
2012-10-26 07:50:35 +08:00
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @freq: The frequency given to target function
|
|
|
|
* @flags: Flags handed from devfreq framework.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*
|
2017-01-23 12:41:47 +08:00
|
|
|
* The callers are required to call dev_pm_opp_put() for the returned OPP after
|
|
|
|
* use.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*/
|
2013-09-20 05:03:51 +08:00
|
|
|
struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
|
|
|
|
unsigned long *freq,
|
|
|
|
u32 flags)
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
{
|
2013-09-20 05:03:51 +08:00
|
|
|
struct dev_pm_opp *opp;
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2012-03-17 04:54:53 +08:00
|
|
|
if (flags & DEVFREQ_FLAG_LEAST_UPPER_BOUND) {
|
|
|
|
/* The freq is an upper bound. opp should be lower */
|
2013-09-20 05:03:50 +08:00
|
|
|
opp = dev_pm_opp_find_freq_floor(dev, freq);
|
2012-03-17 04:54:53 +08:00
|
|
|
|
|
|
|
/* If not available, use the closest opp */
|
2012-10-25 04:00:12 +08:00
|
|
|
if (opp == ERR_PTR(-ERANGE))
|
2013-09-20 05:03:50 +08:00
|
|
|
opp = dev_pm_opp_find_freq_ceil(dev, freq);
|
2012-03-17 04:54:53 +08:00
|
|
|
} else {
|
|
|
|
/* The freq is an lower bound. opp should be higher */
|
2013-09-20 05:03:50 +08:00
|
|
|
opp = dev_pm_opp_find_freq_ceil(dev, freq);
|
2012-03-17 04:54:53 +08:00
|
|
|
|
|
|
|
/* If not available, use the closest opp */
|
2012-10-25 04:00:12 +08:00
|
|
|
if (opp == ERR_PTR(-ERANGE))
|
2013-09-20 05:03:50 +08:00
|
|
|
opp = dev_pm_opp_find_freq_floor(dev, freq);
|
2012-03-17 04:54:53 +08:00
|
|
|
}
|
|
|
|
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
return opp;
|
|
|
|
}
|
2014-07-18 22:09:53 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_recommended_opp);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_register_opp_notifier() - Helper function to get devfreq notified
|
2019-01-21 10:11:07 +08:00
|
|
|
* for any changes in the OPP availability
|
|
|
|
* changes
|
2012-10-26 07:50:35 +08:00
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @devfreq: The devfreq object.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*/
|
|
|
|
int devfreq_register_opp_notifier(struct device *dev, struct devfreq *devfreq)
|
|
|
|
{
|
2017-01-02 17:11:03 +08:00
|
|
|
return dev_pm_opp_register_notifier(dev, &devfreq->nb);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
2014-07-18 22:09:53 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_register_opp_notifier);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* devfreq_unregister_opp_notifier() - Helper function to stop getting devfreq
|
2019-01-21 10:11:07 +08:00
|
|
|
* notified for any changes in the OPP
|
|
|
|
* availability changes anymore.
|
2012-10-26 07:50:35 +08:00
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @devfreq: The devfreq object.
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
*
|
|
|
|
* At exit() callback of devfreq_dev_profile, this must be included if
|
|
|
|
* devfreq_recommended_opp is used.
|
|
|
|
*/
|
|
|
|
int devfreq_unregister_opp_notifier(struct device *dev, struct devfreq *devfreq)
|
|
|
|
{
|
2017-01-02 17:11:03 +08:00
|
|
|
return dev_pm_opp_unregister_notifier(dev, &devfreq->nb);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
}
|
2014-07-18 22:09:53 +08:00
|
|
|
EXPORT_SYMBOL(devfreq_unregister_opp_notifier);
|
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 06:19:15 +08:00
|
|
|
|
2014-05-09 15:43:09 +08:00
|
|
|
static void devm_devfreq_opp_release(struct device *dev, void *res)
|
|
|
|
{
|
|
|
|
devfreq_unregister_opp_notifier(dev, *(struct devfreq **)res);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-01-21 10:11:07 +08:00
|
|
|
* devm_devfreq_register_opp_notifier() - Resource-managed
|
|
|
|
* devfreq_register_opp_notifier()
|
2014-05-09 15:43:09 +08:00
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @devfreq: The devfreq object.
|
|
|
|
*/
|
|
|
|
int devm_devfreq_register_opp_notifier(struct device *dev,
|
|
|
|
struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
struct devfreq **ptr;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_devfreq_opp_release, sizeof(*ptr), GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
ret = devfreq_register_opp_notifier(dev, devfreq);
|
|
|
|
if (ret) {
|
|
|
|
devres_free(ptr);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ptr = devfreq;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_devfreq_register_opp_notifier);
|
|
|
|
|
|
|
|
/**
|
2019-01-21 10:11:07 +08:00
|
|
|
* devm_devfreq_unregister_opp_notifier() - Resource-managed
|
|
|
|
* devfreq_unregister_opp_notifier()
|
2014-05-09 15:43:09 +08:00
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @devfreq: The devfreq object.
|
|
|
|
*/
|
|
|
|
void devm_devfreq_unregister_opp_notifier(struct device *dev,
|
|
|
|
struct devfreq *devfreq)
|
|
|
|
{
|
|
|
|
WARN_ON(devres_release(dev, devm_devfreq_opp_release,
|
|
|
|
devm_devfreq_dev_match, devfreq));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_devfreq_unregister_opp_notifier);
|
|
|
|
|
2016-01-26 12:21:26 +08:00
|
|
|
/**
|
|
|
|
* devfreq_register_notifier() - Register a driver with devfreq
|
|
|
|
* @devfreq: The devfreq object.
|
|
|
|
* @nb: The notifier block to register.
|
|
|
|
* @list: DEVFREQ_TRANSITION_NOTIFIER.
|
|
|
|
*/
|
|
|
|
int devfreq_register_notifier(struct devfreq *devfreq,
|
2019-01-21 10:11:07 +08:00
|
|
|
struct notifier_block *nb,
|
|
|
|
unsigned int list)
|
2016-01-26 12:21:26 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!devfreq)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (list) {
|
|
|
|
case DEVFREQ_TRANSITION_NOTIFIER:
|
|
|
|
ret = srcu_notifier_chain_register(
|
|
|
|
&devfreq->transition_notifier_list, nb);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devfreq_register_notifier);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* devfreq_unregister_notifier() - Unregister a driver with devfreq
|
|
|
|
* @devfreq: The devfreq object.
|
|
|
|
* @nb: The notifier block to be unregistered.
|
|
|
|
* @list: DEVFREQ_TRANSITION_NOTIFIER.
|
|
|
|
*/
|
|
|
|
int devfreq_unregister_notifier(struct devfreq *devfreq,
|
|
|
|
struct notifier_block *nb,
|
|
|
|
unsigned int list)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (!devfreq)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (list) {
|
|
|
|
case DEVFREQ_TRANSITION_NOTIFIER:
|
|
|
|
ret = srcu_notifier_chain_unregister(
|
|
|
|
&devfreq->transition_notifier_list, nb);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devfreq_unregister_notifier);
|
|
|
|
|
|
|
|
struct devfreq_notifier_devres {
|
|
|
|
struct devfreq *devfreq;
|
|
|
|
struct notifier_block *nb;
|
|
|
|
unsigned int list;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void devm_devfreq_notifier_release(struct device *dev, void *res)
|
|
|
|
{
|
|
|
|
struct devfreq_notifier_devres *this = res;
|
|
|
|
|
|
|
|
devfreq_unregister_notifier(this->devfreq, this->nb, this->list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devm_devfreq_register_notifier()
|
|
|
|
- Resource-managed devfreq_register_notifier()
|
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @devfreq: The devfreq object.
|
|
|
|
* @nb: The notifier block to be unregistered.
|
|
|
|
* @list: DEVFREQ_TRANSITION_NOTIFIER.
|
|
|
|
*/
|
|
|
|
int devm_devfreq_register_notifier(struct device *dev,
|
|
|
|
struct devfreq *devfreq,
|
|
|
|
struct notifier_block *nb,
|
|
|
|
unsigned int list)
|
|
|
|
{
|
|
|
|
struct devfreq_notifier_devres *ptr;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ptr = devres_alloc(devm_devfreq_notifier_release, sizeof(*ptr),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!ptr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
ret = devfreq_register_notifier(devfreq, nb, list);
|
|
|
|
if (ret) {
|
|
|
|
devres_free(ptr);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ptr->devfreq = devfreq;
|
|
|
|
ptr->nb = nb;
|
|
|
|
ptr->list = list;
|
|
|
|
devres_add(dev, ptr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_devfreq_register_notifier);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* devm_devfreq_unregister_notifier()
|
|
|
|
- Resource-managed devfreq_unregister_notifier()
|
|
|
|
* @dev: The devfreq user device. (parent of devfreq)
|
|
|
|
* @devfreq: The devfreq object.
|
|
|
|
* @nb: The notifier block to be unregistered.
|
|
|
|
* @list: DEVFREQ_TRANSITION_NOTIFIER.
|
|
|
|
*/
|
|
|
|
void devm_devfreq_unregister_notifier(struct device *dev,
|
2019-01-21 10:11:07 +08:00
|
|
|
struct devfreq *devfreq,
|
|
|
|
struct notifier_block *nb,
|
|
|
|
unsigned int list)
|
2016-01-26 12:21:26 +08:00
|
|
|
{
|
|
|
|
WARN_ON(devres_release(dev, devm_devfreq_notifier_release,
|
|
|
|
devm_devfreq_dev_match, devfreq));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(devm_devfreq_unregister_notifier);
|