This is a snapshot of the devfreq-spdm driver as of msm-3.18
'commit fa156811a90f ("ASoC: msm: enable group config for both
tx and rx").
Change-Id: I11fbcbfbca8b9bc30b9b43d08557fd5774e1444d
Signed-off-by: Odelu Kukatla <okukatla@codeaurora.org>
Odelu Kukatlaauthored and Gerrit - the friendly Code Review servercommited 2017-12-18 21:32:14 -08:00
Adding the snapshot of the files from the msm-4.4 to msm-4.9.
Base commit in msm-4.4 tree is
Commit-Id: 8df0f9ec1df7b281f0a7a0f29321a90d19b3e381.
CRs-Fixed: 2017390
Change-Id: I45122ca1f0d1f7e443e7cdf1374e662625f17ee4
Signed-off-by: Oleg Perelet <operelet@codeaurora.org>
Use performance counters to detect the memory latency sensitivity
of CPU workloads and vote for higher DDR frequency if required.
Change-Id: Ie77a3523bc5713fc0315bd0abc3913f485a96e0e
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
Suggested-by: Saravana Kannan <skannan@codeaurora.org>
[junjiew@codeaurora.org: dropped changes in arch/arm64/Kconfig]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
CCI400 on MSM has additional PMU counters that can be used to monitor
cache requests. MSM CCI hardware monitor device configures these
registers to monitor cache and inform governor. It can also set an
IRQ when count exceeds a programmable limit.
Change-Id: I1d80f57749b91c3972e60e54c75226c4d49d2ec6
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Junjie Wuauthored and Rohit Guptacommited 2017-03-28 17:52:21 -07:00
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>
Saravana Kannanauthored and Stephen Boydcommited 2017-03-21 16:51:48 -07:00
This driver registers itself as a devfreq device that allows devfreq
governors to make CPU to DDR IB/AB bandwidth votes. This driver allows the
governors to be agnostic of the bandwidth voting APIs, the number of CPU
master ports or DDR slave ports, the actual port numbers, the system
topology, the available DDR frequencies, etc.
Change-Id: If055ddd580afd41f9668b111e6c09a047488b2e0
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Saravana Kannanauthored and Stephen Boydcommited 2017-03-21 16:51:48 -07:00
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>
Saravana Kannanauthored and Stephen Boydcommited 2017-03-21 16:51:47 -07:00
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>
Saravana Kannanauthored and Stephen Boydcommited 2017-03-21 16:51:46 -07:00
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>
Saravana Kannanauthored and Stephen Boydcommited 2017-03-21 16:51:46 -07:00
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>
Saravana Kannanauthored and Stephen Boydcommited 2017-03-21 16:51:45 -07:00
Adding the snapshot of the files from the msm-4.4 to v4.9,
4.4 base commit Commit-Id: 8df0f9ec1df7b281f0a7a0f29321a90d19b3e381.
CRs-Fixed: 1108475
Change-Id: Ifac5af4a2204c0c6f9df7214f64c222e172d6dc5
Signed-off-by: Oleg Perelet <operelet@codeaurora.org>
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: MyngJoo Ham <myngjoo.ham@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Lin Huangauthored and MyungJoo Hamcommited 2016-09-06 13:26:34 +09:00
This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Chanwoo Choiauthored and MyungJoo Hamcommited 2016-05-03 11:20:09 +09:00
This patch adds the new passive governor for DEVFREQ framework. The following
governors are already present and used for DVFS (Dynamic Voltage and Frequency
Scaling) drivers. The following governors are independently used for one device
driver which don't give the influence to other device drviers and also don't
receive the effect from other device drivers.
- ondemand / performance / powersave / userspace
The passive governor depends on operation of parent driver with specific
governos extremely and is not able to decide the new frequency by oneself.
According to the decided new frequency of parent driver with governor,
the passive governor uses it to decide the appropriate frequency for own
device driver. The passive governor must need the following information
from device tree:
- the source clock and OPP tables
- the instance of parent device
For exameple,
there are one more devfreq device drivers which need to change their source
clock according to their utilization on runtime. But, they share the same
power line (e.g., regulator). So, specific device driver is operated as parent
with ondemand governor and then the rest device driver with passive governor
is influenced by parent device.
Suggested-by: Myungjoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[tjakobi: Reported RCU locking issue and cw00.choi fix it]
Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
[linux.amoon: Reported possible recursive locking and cw00.choi fix it]
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Chanwoo Choiauthored and MyungJoo Hamcommited 2016-05-03 11:20:07 +09:00
This patch adds the generic exynos bus frequency driver for AMBA AXI bus
of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
have the common architecture for bus between DRAM and sub-blocks in SoC.
This driver can support the generic bus frequency driver for Exynos SoCs.
In devicetree, Each bus block has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl <m.reichl@fivetechno.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Chanwoo Choiauthored and MyungJoo Hamcommited 2016-05-03 11:20:05 +09:00
This patch fixes the build break of the exynos-ppmu driver because Makefile
in drivers/devfreq don't include the entry of devfreq-event.c driver.
The original patch[1] includes the entry to build devfreq-event.c without
the build break. This build break is generated in the process of merging the
patch.
[1] https://lkml.org/lkml/2015/1/25/579
- [PATCH v10 1/7] devfreq: event: Add new devfreq_event class to provide basic
data for devfreq governor
CC init/version.o
LD init/built-in.o
drivers/built-in.o: In function `exynos_ppmu_probe':
binder.c:(.text+0x4447ec): undefined reference to `devm_devfreq_event_add_edev'
make: *** [vmlinux] Error 1
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Chanwoo Choiauthored and MyungJoo Hamcommited 2015-01-30 17:56:41 +09:00
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>
Chanwoo Choiauthored and MyungJoo Hamcommited 2015-01-30 17:56:40 +09:00
The ACTMON block can monitor several counters, providing averaging and firing
interrupts based on watermarking configuration. This implementation monitors
the MCALL and MCCPU counters to choose an appropriate frequency for the
external memory clock.
This patch is based on work by Alex Frid <afrid@nvidia.com> and Mikko
Perttunen <mikko.perttunen@kapsi.fi>.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Tomeu Vizosoauthored and MyungJoo Hamcommited 2015-01-29 21:25:48 +09:00
Exynos5-bus device devfreq driver monitors PPMU counters and
adjusts operating frequencies and voltages with OPP. ASV should
be used to provide appropriate voltages as per the speed group
of the SoC rather than using a constant 1.025V.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
[myungjoo.ham@samsung.com: minor style update]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Abhilash Kesavanauthored and MyungJoo Hamcommited 2013-06-03 20:20:29 +09:00
In anticipation of the new exynos5 devfreq and ppmu driver, create
an exynos sub-directory. Move the existing exynos4 devfreq driver
into the same.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Abhilash Kesavanauthored and MyungJoo Hamcommited 2013-06-03 20:20:29 +09:00
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.
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>
MyungJoo Hamauthored and Rafael J. Wysockicommited 2011-10-02 00:19:34 +02:00
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>
MyungJoo Hamauthored and Rafael J. Wysockicommited 2011-10-02 00:19:15 +02:00
Odelu Kukatla
authored and
Gerrit - the friendly Code Review server
commited 
Oleg Perelet
commited 
Rohit Gupta
commited 
Junjie Wu
authored and
Saravana Kannan
authored and
Stephen Boyd
commited 
Lin Huang
authored and
MyungJoo Ham
commited 
Chanwoo Choi
authored and
Tomeu Vizoso
authored and
Abhilash Kesavan
authored and
Rafael J. Wysocki
commited