2019-05-19 08:07:45 -04: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-01 18:19:15 -04:00
|
|
|
menuconfig PM_DEVFREQ
|
|
|
|
|
bool "Generic Dynamic Voltage and Frequency Scaling (DVFS) support"
|
2014-12-05 11:24:45 -05:00
|
|
|
select SRCU
|
2017-08-23 21:42:51 -04:00
|
|
|
select PM_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-01 18:19:15 -04:00
|
|
|
help
|
2011-11-14 17:31:35 -05:00
|
|
|
A device may have a list of frequencies and voltages available.
|
|
|
|
|
devfreq, a generic DVFS framework can be registered for a device
|
|
|
|
|
in order to let the governor provided to devfreq choose an
|
|
|
|
|
operating frequency based on the device driver's policy.
|
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-01 18:19:15 -04:00
|
|
|
|
2011-11-14 17:31:35 -05:00
|
|
|
Each device may have its own governor and policy. Devfreq can
|
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-01 18:19:15 -04:00
|
|
|
reevaluate the device state periodically and/or based on the
|
2011-11-14 17:31:35 -05:00
|
|
|
notification to "nb", a notifier block, of 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-01 18:19:15 -04:00
|
|
|
|
2011-11-14 17:31:35 -05:00
|
|
|
Like some CPUs with CPUfreq, a device may have multiple clocks.
|
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-01 18:19:15 -04:00
|
|
|
However, because the clock frequencies of a single device are
|
2011-11-14 17:31:35 -05:00
|
|
|
determined by the single device's state, an instance of 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-01 18:19:15 -04:00
|
|
|
is attached to a single device and returns a "representative"
|
2011-11-14 17:31:35 -05:00
|
|
|
clock frequency of the device, which is also attached
|
|
|
|
|
to a device by 1-to-1. The device registering devfreq takes the
|
2012-04-13 11:14:11 -04:00
|
|
|
responsibility to "interpret" the representative frequency and
|
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-01 18:19:15 -04:00
|
|
|
to set its every clock accordingly with the "target" callback
|
2011-11-14 17:31:35 -05:00
|
|
|
given to devfreq.
|
|
|
|
|
|
|
|
|
|
When OPP is used with the devfreq device, it is recommended to
|
|
|
|
|
register devfreq's nb to the OPP's notifier head. If OPP is
|
|
|
|
|
used with the devfreq device, you may use OPP helper
|
|
|
|
|
functions defined in devfreq.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-01 18:19:15 -04:00
|
|
|
|
|
|
|
|
if PM_DEVFREQ
|
|
|
|
|
|
2011-10-01 18:19:34 -04:00
|
|
|
comment "DEVFREQ Governors"
|
|
|
|
|
|
|
|
|
|
config DEVFREQ_GOV_SIMPLE_ONDEMAND
|
2012-10-29 16:01:46 -04:00
|
|
|
tristate "Simple Ondemand"
|
2011-10-01 18:19:34 -04:00
|
|
|
help
|
|
|
|
|
Chooses frequency based on the recent load on the device. Works
|
|
|
|
|
similar as ONDEMAND governor of CPUFREQ does. A device with
|
|
|
|
|
Simple-Ondemand should be able to provide busy/total counter
|
|
|
|
|
values that imply the usage rate. A device may provide tuned
|
|
|
|
|
values to the governor with data field at devfreq_add_device().
|
|
|
|
|
|
|
|
|
|
config DEVFREQ_GOV_PERFORMANCE
|
2012-10-29 16:01:46 -04:00
|
|
|
tristate "Performance"
|
2011-10-01 18:19:34 -04:00
|
|
|
help
|
|
|
|
|
Sets the frequency at the maximum available frequency.
|
|
|
|
|
This governor always returns UINT_MAX as frequency so that
|
|
|
|
|
the DEVFREQ framework returns the highest frequency available
|
|
|
|
|
at any time.
|
|
|
|
|
|
|
|
|
|
config DEVFREQ_GOV_POWERSAVE
|
2012-10-29 16:01:46 -04:00
|
|
|
tristate "Powersave"
|
2011-10-01 18:19:34 -04:00
|
|
|
help
|
|
|
|
|
Sets the frequency at the minimum available frequency.
|
|
|
|
|
This governor always returns 0 as frequency so that
|
|
|
|
|
the DEVFREQ framework returns the lowest frequency available
|
|
|
|
|
at any time.
|
|
|
|
|
|
|
|
|
|
config DEVFREQ_GOV_USERSPACE
|
2012-10-29 16:01:46 -04:00
|
|
|
tristate "Userspace"
|
2011-10-01 18:19:34 -04:00
|
|
|
help
|
|
|
|
|
Sets the frequency at the user specified one.
|
|
|
|
|
This governor returns the user configured frequency if there
|
|
|
|
|
has been an input to /sys/devices/.../power/devfreq_set_freq.
|
2016-03-14 11:29:02 -04:00
|
|
|
Otherwise, the governor does not change the frequency
|
2011-10-01 18:19:34 -04:00
|
|
|
given at the initialization.
|
|
|
|
|
|
2016-03-22 00:44:03 -04:00
|
|
|
config DEVFREQ_GOV_PASSIVE
|
|
|
|
|
tristate "Passive"
|
|
|
|
|
help
|
|
|
|
|
Sets the frequency based on the frequency of its parent devfreq
|
|
|
|
|
device. This governor does not change the frequency by itself
|
|
|
|
|
through sysfs entries. The passive governor recommends that
|
|
|
|
|
devfreq device uses the OPP table to get the frequency/voltage.
|
|
|
|
|
|
2019-01-16 21:15:27 -05:00
|
|
|
config QCOM_BIMC_BWMON
|
|
|
|
|
tristate "QCOM BIMC Bandwidth monitor hardware"
|
|
|
|
|
depends on ARCH_QCOM
|
|
|
|
|
help
|
|
|
|
|
The BIMC Bandwidth monitor hardware allows for monitoring the
|
|
|
|
|
traffic coming from each master port connected to the BIMC. It also
|
|
|
|
|
has the capability to raise an IRQ when the count exceeds a
|
|
|
|
|
programmable limit.
|
|
|
|
|
|
2019-01-16 22:00:20 -05:00
|
|
|
config ARM_MEMLAT_MON
|
|
|
|
|
tristate "ARM CPU Memory Latency monitor hardware"
|
|
|
|
|
depends on ARCH_QCOM
|
|
|
|
|
help
|
|
|
|
|
The PMU present on these ARM cores allow for the use of counters to
|
|
|
|
|
monitor the memory latency characteristics of an ARM CPU workload.
|
|
|
|
|
This driver uses these counters to implement the APIs needed by
|
|
|
|
|
the mem_latency devfreq governor.
|
|
|
|
|
|
2019-01-16 21:03:28 -05:00
|
|
|
config DEVFREQ_GOV_QCOM_BW_HWMON
|
|
|
|
|
tristate "HW monitor based governor for device BW"
|
|
|
|
|
depends on QCOM_BIMC_BWMON
|
|
|
|
|
help
|
|
|
|
|
HW monitor based governor for device to DDR bandwidth voting.
|
|
|
|
|
This governor sets the CPU BW vote by using BIMC counters to monitor
|
|
|
|
|
the CPU's use of DDR. Since this uses target specific counters it
|
|
|
|
|
can conflict with existing profiling tools. This governor is unlikely
|
|
|
|
|
to be useful for non-QCOM devices.
|
|
|
|
|
|
2019-01-16 20:59:51 -05:00
|
|
|
config DEVFREQ_GOV_QCOM_CACHE_HWMON
|
|
|
|
|
tristate "HW monitor based governor for cache frequency"
|
|
|
|
|
help
|
|
|
|
|
HW monitor based governor for cache frequency scaling. This
|
|
|
|
|
governor sets the cache frequency by using PM counters to monitor the
|
|
|
|
|
CPU's use of cache. Since this governor uses some of the PM counters
|
|
|
|
|
it can conflict with existing profiling tools. This governor is
|
|
|
|
|
unlikely to be useful for other devices.
|
|
|
|
|
|
2019-01-16 22:00:20 -05:00
|
|
|
config DEVFREQ_GOV_MEMLAT
|
|
|
|
|
tristate "HW monitor based governor for device BW"
|
|
|
|
|
depends on ARM_MEMLAT_MON
|
|
|
|
|
help
|
|
|
|
|
HW monitor based governor for device to DDR bandwidth voting.
|
|
|
|
|
This governor sets the CPU BW vote based on stats obtained from memalat
|
|
|
|
|
monitor if it determines that a workload is memory latency bound. Since
|
|
|
|
|
this uses target specific counters it can conflict with existing profiling
|
|
|
|
|
tools.
|
|
|
|
|
|
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-01 18:19:15 -04:00
|
|
|
comment "DEVFREQ Drivers"
|
|
|
|
|
|
2015-11-03 05:04:16 -05:00
|
|
|
config ARM_EXYNOS_BUS_DEVFREQ
|
2016-06-25 14:43:49 -04:00
|
|
|
tristate "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
|
2016-08-19 02:36:55 -04:00
|
|
|
depends on ARCH_EXYNOS || COMPILE_TEST
|
2015-11-03 05:04:16 -05:00
|
|
|
select DEVFREQ_GOV_SIMPLE_ONDEMAND
|
PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor
This patch adds the support of bus frequency feature for sub-blocks which share
the one power line. If each bus depends on the power line, each bus is not able
to change the voltage by oneself. To optimize the power-consumption on runtime,
some buses using the same power line should change the source clock and
regulator at the same time. So, this patch uses the passive governor to support
the bus frequency for all buses which sharing the one power line.
For example,
Exynos3250 include the two power line for AXI buses as following:
: VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller)
with the power (regulator).
: VDD_INT : INT (Internal) provide the various sub-blocks with the power
(regulator).
Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC bus
use the power line. So, there is no any depencency between buese. But, in the
case of VDD_INT, various buses share the one power line of VDD_INT. We need to
make the depenency between buses. When using passive governor, there is no
problem to support the bus frequency as DVFS for all buses. One bus should be
operated as the parent bus device which gathering the current load of INT block
and then decides the new frequency with some governors except of passive
governor. After deciding the new frequency by the parent bus device, the rest
bus devices will change the each source clock according to new frequency of the
parent bus device.
- MIF (Memory Interface) block
: VDD_MIF |--- DMC
- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent)
|--- PERIL
|--- MFC
|--- G3D
|--- RIGHTBUS
|--- FSYS
|--- LCD0
|--- PERIR
|--- ISP
|--- CAM
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[tjakobi: Reported debugfs error during booting and cw00.choi fix it.]
Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
2015-11-05 04:29:27 -05:00
|
|
|
select DEVFREQ_GOV_PASSIVE
|
2015-11-03 05:04:16 -05:00
|
|
|
select DEVFREQ_EVENT_EXYNOS_PPMU
|
|
|
|
|
select PM_DEVFREQ_EVENT
|
|
|
|
|
select PM_OPP
|
|
|
|
|
help
|
|
|
|
|
This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
|
|
|
|
|
Memory bus has one more group of memory bus (e.g, MIF and INT block).
|
|
|
|
|
Each memory bus group could contain many memoby bus block. It reads
|
|
|
|
|
PPMU counters of memory controllers by using DEVFREQ-event device
|
|
|
|
|
and adjusts the operating frequencies and voltages with OPP support.
|
|
|
|
|
This does not yet operate with optimal voltages.
|
|
|
|
|
|
2014-11-24 07:28:17 -05:00
|
|
|
config ARM_TEGRA_DEVFREQ
|
2019-05-01 19:38:12 -04:00
|
|
|
tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver"
|
|
|
|
|
depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \
|
|
|
|
|
ARCH_TEGRA_132_SOC || ARCH_TEGRA_124_SOC || \
|
2019-05-01 19:38:13 -04:00
|
|
|
ARCH_TEGRA_210_SOC || \
|
|
|
|
|
COMPILE_TEST
|
2016-08-25 08:06:14 -04:00
|
|
|
select PM_OPP
|
2019-12-11 20:56:31 -05:00
|
|
|
depends on COMMON_CLK
|
2016-08-25 08:06:14 -04:00
|
|
|
help
|
|
|
|
|
This adds the DEVFREQ driver for the Tegra family of SoCs.
|
|
|
|
|
It reads ACTMON counters of memory controllers and adjusts the
|
|
|
|
|
operating frequencies and voltages with OPP support.
|
2014-11-24 07:28:17 -05:00
|
|
|
|
2019-05-01 19:38:15 -04:00
|
|
|
config ARM_TEGRA20_DEVFREQ
|
|
|
|
|
tristate "NVIDIA Tegra20 DEVFREQ Driver"
|
|
|
|
|
depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST
|
2019-06-28 06:32:20 -04:00
|
|
|
depends on COMMON_CLK
|
2019-05-01 19:38:15 -04:00
|
|
|
select DEVFREQ_GOV_SIMPLE_ONDEMAND
|
|
|
|
|
select PM_OPP
|
|
|
|
|
help
|
|
|
|
|
This adds the DEVFREQ driver for the Tegra20 family of SoCs.
|
|
|
|
|
It reads Memory Controller counters and adjusts the operating
|
|
|
|
|
frequencies and voltages with OPP support.
|
|
|
|
|
|
2016-09-05 01:06:10 -04:00
|
|
|
config ARM_RK3399_DMC_DEVFREQ
|
|
|
|
|
tristate "ARM RK3399 DMC DEVFREQ Driver"
|
2019-12-11 21:20:30 -05:00
|
|
|
depends on (ARCH_ROCKCHIP && HAVE_ARM_SMCCC) || \
|
|
|
|
|
(COMPILE_TEST && HAVE_ARM_SMCCC)
|
2016-09-05 01:06:10 -04:00
|
|
|
select DEVFREQ_EVENT_ROCKCHIP_DFI
|
|
|
|
|
select DEVFREQ_GOV_SIMPLE_ONDEMAND
|
2016-09-15 11:44:58 -04:00
|
|
|
select PM_DEVFREQ_EVENT
|
2016-09-05 01:06:10 -04:00
|
|
|
select PM_OPP
|
|
|
|
|
help
|
|
|
|
|
This adds the DEVFREQ driver for the RK3399 DMC(Dynamic Memory Controller).
|
|
|
|
|
It sets the frequency for the memory controller and reads the usage counts
|
|
|
|
|
from hardware.
|
|
|
|
|
|
2014-01-21 21:49:37 -05:00
|
|
|
config DEVFREQ_SIMPLE_DEV
|
|
|
|
|
tristate "Device driver for simple clock device with no status info"
|
|
|
|
|
select DEVFREQ_GOV_PERFORMANCE
|
|
|
|
|
select DEVFREQ_GOV_POWERSAVE
|
|
|
|
|
select DEVFREQ_GOV_USERSPACE
|
|
|
|
|
help
|
|
|
|
|
Device driver for simple devices that control their frequency using
|
|
|
|
|
clock APIs and don't have any form of status reporting.
|
|
|
|
|
|
2019-01-16 21:09:59 -05:00
|
|
|
config QCOM_DEVFREQ_ICC
|
|
|
|
|
bool "Qualcomm Technologies Inc. DEVFREQ device for device master <-> slave IB/AB BW voting"
|
|
|
|
|
depends on ARCH_QCOM
|
|
|
|
|
select DEVFREQ_GOV_PERFORMANCE
|
|
|
|
|
select DEVFREQ_GOV_POWERSAVE
|
|
|
|
|
select DEVFREQ_GOV_USERSPACE
|
|
|
|
|
select INTERCONNECT
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Different devfreq governors use this devfreq device to make CPU to
|
|
|
|
|
DDR IB/AB bandwidth votes. This driver provides a SoC topology
|
|
|
|
|
agnostic interface to so that some of the devfreq governors can be
|
|
|
|
|
shared across SoCs.
|
|
|
|
|
|
2019-05-23 17:17:34 -04:00
|
|
|
config ARM_QCOM_DEVFREQ_QOSLAT
|
|
|
|
|
bool "Qualcomm Technologies Inc. DEVFREQ QOSLAT device driver"
|
|
|
|
|
depends on ARCH_QCOM
|
|
|
|
|
select DEVFREQ_GOV_PERFORMANCE
|
|
|
|
|
select DEVFREQ_GOV_POWERSAVE
|
|
|
|
|
select DEVFREQ_GOV_USERSPACE
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Some Qualcomm Technologies, Inc. (QTI) chipsets have an
|
|
|
|
|
interface to vote for a memory latency QoS level. This
|
|
|
|
|
driver votes on this interface to request a particular
|
|
|
|
|
memory latency QoS level.
|
|
|
|
|
|
PM / devfreq: event: Add devfreq_event class
This patch adds a new class in devfreq, devfreq_event, which provides
raw data (e.g., memory bus utilization, GPU utilization) for devfreq
governors.
- devfreq_event device : Provides raw data for a governor of a devfreq device
- devfreq device : Monitors device state and changes frequency/voltage
of the device using the raw data from its
devfreq_event device.
A devfreq device dertermines performance states (normally the frequency
and the voltage vlues) based on the results its designtated devfreq governor:
e.g., ondemand, performance, powersave.
In order to give such results required by a devfreq device, the devfreq
governor requires data that indicates the performance requirement given
to the devfreq device. The conventional (previous) implementatino of
devfreq subsystem requires a devfreq device driver to implement its own
mechanism to acquire performance requirement for its governor. However,
there had been issues with such requirements:
1. Although performance requirement of such devices is usually acquired
from common devices (PMU/PPMU), we do not have any abstract structure to
represent them properly.
2. Such performance requirement devices (PMU/PPMU) are actual hardware
pieces that may be represented by Device Tree directly while devfreq device
itself is a virtual entity that are not considered to be represented by
Device Tree according to Device Tree folks.
In order to address such issues, a devferq_event device (represented by
this patch) provides a template for device drivers representing
performance monitoring unit, which gives the basic or raw data for
preformance requirement, which in turn, is required by devfreq governors.
The following description explains the feature of two kind of devfreq class:
- devfreq class (existing)
: devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
- devfreq_event class (new)
: Provide measured raw data to devfreq device for governor
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[Commit message rewritten & conflict resolved by MyungJoo]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2015-01-25 23:16:27 -05:00
|
|
|
source "drivers/devfreq/event/Kconfig"
|
|
|
|
|
|
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-01 18:19:15 -04:00
|
|
|
endif # PM_DEVFREQ
|
