Currently SPDM driver uses hvc calls to support
the dcvs algorithm logic. On some targets this
dcvs algorithm support is present in TZ and which
is accessed via separate calls. Add SCM call to
support TZ based dcvs algorithm.
Change-Id: I197f0f13b4107047151e10e19e4849008607f3e8
Signed-off-by: Dan Sneddon <dsneddon@codeaurora.org>
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
The devfreq_spdm driver implements support for bandwidth voting
based on input from the SPDM device on MSM SoC's. The SPDM
governor registers for the SPDM interrupt and then calls
the hypervisor to determine the correct bandwidth to vote for.
The devfreq framework poll timer is used to perdiocially
ask the hypervisor for the new bandwidth to request from
the MSM bus scaling code.
Change-Id: I851457e40d49b5929f01c510249d3e6bb4ff2f1d
Signed-off-by: Dan Sneddon <dsneddon@codeaurora.org>
The existing devfreq governor_msm_adreno_tz supports both GPU DCVS and BMC
(Bus Modification Calculation) at the same time. This change splits BMC
code into a new governor_gpubw_mon.
Change-Id: Ie7162985e994aa5bed0fb41eb2741a811cf8bd56
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
The ARM PMU supports monitoring bus access from each CPU. It also has the
ability to raise an IRQ when the counters overflow. This allows for it to
be used with the bw_hwmon governor to scale the CPU BW requests by
monitoring on the actual bus access traffic.
Change-Id: I0594a6acb846acdc11a18744033636951f22e387
Signed-off-by: Jacob Stevens <jstevens@codeaurora.org>
The BIMC bwmon device supports monitoring read/write traffic from each BIMC
master port. It also has the capability to raise an IRQ when the traffic
count exceeds a programmable threshold. This allows for it to be used with
the bw_hwmon governor to scale the BW requests from each BIMC master.
Change-Id: Ie8a1471226411e23954ed556292186a5a864ddc1
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Making the driver more generic would allow it to be reused for voting for
BW requirements of other devices like GPU, etc.
Instead of cpubw and qcom,cpubw, the driver and the device are now called
devbw and qcom,devbw respectively.
Change-Id: I49e5a5ba6d46517da19d013413abd471a730af29
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
The refactored governor will be called bw_hwmon since it's no longer
limited to monitoring the CPU BW in hardware.
The refactor allows the governor to support multiple devfreq devices. This
is done by having different HW monitor instances register their capability
to monitor different devfreq devices and then picking the right HW monitor
based on which devfreq device is using this governor.
The refactor also fixes a very unlikely race condition that can happen when
starting/stopping the governor.
Change-Id: Ifeeeb256115f6ae3075f391d9b4b02666e06f737
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
The cache HW monitor devfreq governor uses the hardware counters to
determine the load on the cache and the appropriate frequency needed to
support that load. This governor can be used in conjunction with the cache
devfreq device to dynamically scale the cache frequency based on the
demand/actual usage from the CPU subsystem.
The governor is written to be agnostic of the actual counters used to
determine the load. On Krait based CPUs, the governor uses the Krait L2 PM
counters which can conflict with certain profiling tools.
The Krait L2 performance monitor counters have the capability to count
different types of requests going to the L2 cache. They also have the
capability to raise interrupts when they overflow. This driver uses those
counters to determine the true usage of L2 from the Krait processor
subsystem and then recommends L2 frequency based on the measured values and
the following tunable parameters.
The driver provides various tunables that allow it to be tuned more in
favor of power or performance:
- cycles_per_high_req: The no. of cache clock cycles that are necessary to
efficiently process a high-work request to the cache. A higher value
means higher power and potentially higher performance. A lower value
means lower power and potentially lower performance.
- cycles_per_med_req: The no. of cache clock cycles that are necessary to
efficiently process a medium-work request to the cache. A higher value
means higher power and potentially higher performance. A lower value
means lower power and potentially lower performance.
- polling_ms: The sampling period in milliseconds. This only affects the
sampling period when cache use is ramping down or is increasing very
slowly (See tolerance_mrps).
- min_busy: The minimum percentage of time the cache should be busy. This
is also applied as a lower bound to the measured busy percentage before
it's used in calculations. This has to be lower than or equal to
max_busy. Lower values will make the scaling more aggressive.
- max_busy: The maximum percentage of time the cache should be busy. This
is also applied as an upper bound to the measured busy percentage before
it's used in calculations. This has to be greater than or equal to
min_busy. Lower values will make the scaling more aggressive.
- tolerance_mrps: The minimum increase (in millions of requests per second)
in cache requests, compared to previous sample, that will trigger an IRQ
to immediately re-evaluate the cache frequency.
- decay_rate: The parameter controls the rate at which the history is
forgotten when ramping down. This is expressed as a percentage of history
to be forgotten. So 100% means ignore history, 0% means never forget the
historical max. The default 90% means forget 90% of history each time.
- guard_band_mhz: This is a margin that's added to the computed cache
frequency to account for the time it takes between the load increasing
and the governor/device finishes ramping up the cache frequency.
Change-Id: I918ae178cd3c9d14cb7714d7eb312cbbbb0d977b
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
The devfreq cpufreq governor and the devfreq devices for CPUBW and cache
now handle CPUBW and cache frequency scaling based on CPU frequency. So,
delete all the unused code in the cpufreq driver that relates to scaling
CPUBW and cache.
Also update the msm-cpufreq DT format/data accordingly.
Change-Id: I30bf7d8478c964ffa300dd78039cd8c280ec63fc
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Enable the cpufreq governor for the cpubw device on all targets by:
- Adding the devfreq-cpufreq node for mapping CPU freq to cpubw
- Enabling the cpufreq governor configs when CPUBW config is selected
- Switching the default governor for cpubw device to "cpufreq"
Change-Id: Ic10b645123192ed13c66340f288d6a8553d6f251
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
This driver registers a devfreq device that allows devfreq governors to
scale the frequency of a device clock. This single driver can be used to
support multiple devices as long as those devices don't have a need or
mechanism to monitor their load and use clock APIs to control their
device/core clock.
If devices need to support device specific status monitoring, they could
extend this driver to allow registering device specific status monitoring
funtions or write their own specific devfreq device driver.
Change-Id: Ie1797acf7b35cac6dc49428e270c23082634eb1e
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
This devfreq governor is a generic implementation that can scale any
devfreq device based on the current CPU frequency of all ONLINE CPUs. It
allows for specifying CPU freq to devfreq mapping for specific devices.
When such a mapping is not present, it defaults to scaling the device
frequency in proportion to the CPU frequency.
Change-Id: I8d3b1fea26572defbad2ce8b6cf87930caa25ca6
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
In order to share devfreq_cpubw among all targets, it needs to be
moved outside arch/arm/mach-msm directory. Move the file and
Kconfig to drivers/devfreq.
Change-Id: I4dd476b315b04f84b07855bec3ed5b6061549ea9
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
The CPUBW HW monitor devfreq governor uses the Krait L2 PM counters to
determine the bandwidth needed by the Krait CPU subsystem. This governor
can be used in conjunction with the CPUBW devfreq device to dynamically
scale the DDR frequency based on the demand/actual usage from the Krait CPU
subsystem. Since this governor uses the Krait L2 PM counters it can
conflict with certain profiling tools.
The Krait L2 performance monitor counters have the capability to count the
no. of read/write transactions going out the master ports. They also have
the capability to raise interrupts when they overflow. This driver uses
those counters to determine the true usage of DDR from the Krait processor
subsystem and then recommends CPU DDR BW votes based on the measured values
and the following tunable parameters.
The driver provides various tunables that allow it to be tuned more in
favor of power or performance:
- io_percent: The percentage of the CPU time that can be spent waiting on
memory I/O. Lower value is better performance and worse power.
- sample_ms: The sampling period in milliseconds. This only affects the
sampling period when DDR use is ramping down or is increasing very slowly
(See tolerance_percent).
- tolerance_percent: The minimum increase in DDR use, compared to previous
sample, that will trigger an IRQ to immediately bump up the bandwidth
vote. It's expressed as a percentage of the previous sampled DDR use.
- decay_rate: The parameter controls the rate at which the history is
forgotten when ramping down. This is expressed as a percentage of history
to be forgotten. So 100% means ignore history, 0% mean never forget the
historical max. The default 90% means forget 90% of history each time.
- guard_band_mbps: This is a margin that's added to the measured BW (and
hence also the Bus BW votes) that's present to account for the time it
takes to ramp up the DDR BW while the CPU continues to use the DDR.
- bw_step: All BW votes are rounded up to multiples of bw_step. The default
value is 200 MB/s that turns out to ~25 or 12.5 MHz based on the SoC. A
smaller value would mean more frequent bus BW changes. A higher value
would mean less frequent BW vote updates, but also means at times an
unnecessarily higher BW vote (due to the rounding up).
Change-Id: I88629a3e545cdca7160af8f8ca616ecc949d9947
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
The MSM CPUfreq devfreq governor determines the CPU to DDR bandwidth vote
based on the current CPU frequency of all the active CPUs.
This functionality used to be a part of the MSM CPUfreq driver that
directly voted for the CPU to DDR bandwidth using MSM bus scaling APIs.
This refactor decouples CPU to DDR BW scaling from CPU frequency and allows
switch between various CPU BW governors.
The bandwidth values in the msm-cpufreq table have to be updated since the
new CPU BW driver does the MBps to Bps conversion correctly. The MSM
CPUfreq driver used to do * 1000 * 1000 to convert from MBps to Bps instead
of doing * 1024 * 1024.
Change-Id: I184f09d628a1b27d52506d2f760d65831f1a1110
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
This governor can be used to control adreno GPUs.
It is unlikely to be useful for other devices.
Change-Id: Icf481322454b814d2f41019f2f01286062409952
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Add GPL module license and remove the static build
restrictions for building governors. This allows governors now
to be loaded on a need basis and reloaded independently of kernel
build
Cc: Rajagopal Venkat <rajagopal.venkat@linaro.org>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Kevin Hilman <khilman@ti.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Exynos4-bus device devfreq driver add DVFS capability for
Exynos4210/4212/4412-Bus (memory). The driver monitors PPMU counters of memory
controllers and adjusts operating frequencies and voltages with OPP.
For Exynos4210, vdd_int is controlled. For exynos4412/4212, vdd_mif and
vdd_int are controlled.
Dependency (CONFIG_EXYNOS_ASV):
Exynos4 ASV driver has been posted in the mailing list; however, it
si not yet upstreamed. Although the current revision of Exynos4 ASV
patch does not contain "CONFIG_EXYNOS_ASV", we have added the symbol
to hide the dependent from compilers for now. As soon as Exynos4 ASV
drivers are merged, the #ifdef statement will be removed or the
name will be changed.
However, enabling ASV is essential in most Exynos4 chips to reduce
the power consumption of Exynos4210 because without ASV, this Devfreq
driver assumes the worst case scenario, which consumes more power.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Changes from v1
- Support 4212 and 4412 as well as 4210.
Devfreq does not depend on OPP. The dependency is removed.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Four cpufreq-like governors are provided as examples.
powersave: use the lowest frequency possible. The user (device) should
set the polling_ms as 0 because polling is useless for this governor.
performance: use the highest freqeuncy possible. The user (device)
should set the polling_ms as 0 because polling is useless for this
governor.
userspace: use the user specified frequency stored at
devfreq.user_set_freq. With sysfs support in the following patch, a user
may set the value with the sysfs interface.
simple_ondemand: simplified version of cpufreq's ondemand governor.
When a user updates OPP entries (enable/disable/add), OPP framework
automatically notifies devfreq to update operating frequency
accordingly. Thus, devfreq users (device drivers) do not need to update
devfreq manually with OPP entry updates or set polling_ms for powersave
, performance, userspace, or any other "static" governors.
Note that these are given only as basic examples for governors and any
devices with devfreq may implement their own governors with the drivers
and use them.
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>
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>
Dan Sneddon