28 May, 2020
1 commit
-
Add initial support for dynamic frequency switching on pieces of the imx
interconnect fabric.All this driver does is set a clk rate based on an opp table, it does
not map register areas.Signed-off-by: Leonard Crestez
Tested-by: Martin Kepplinger
Acked-by: Chanwoo Choi
Signed-off-by: Chanwoo Choi
30 Dec, 2019
1 commit
-
Add driver for dynamic scaling the DDR Controller on imx8m chips. Actual
frequency switching is implemented inside TF-A, this driver wraps the
SMC calls and synchronizes the clk tree.The DRAM clocks on imx8m have the following structure (abridged):
+----------+ |\ +------+
| dram_pll |-------|M| dram_core | |
+----------+ |U|---------->| D |
/--|X| | D |
dram_alt_root | |/ | R |
| | C |
+---------+ | |
|FIX DIV/4| | |
+---------+ | |
composite: | | |
+----------+ | | |
| dram_alt |----/ | |
+----------+ | |
| dram_apb |-------------------->| |
+----------+ +------+The dram_pll is used for higher rates and dram_alt is used for lower
rates. The dram_alt and dram_apb clocks are "imx composite" and their
parent can also be modified.This driver will prepare/enable the new parents ahead of switching (so
that the expected roots are enabled) and afterwards it will call
clk_set_parent to ensure the parents in clock framework are up-to-date.The driver relies on dram_pll dram_alt and dram_apb being marked with
CLK_GET_RATE_NOCACHE for rate updates.Signed-off-by: Leonard Crestez
Acked-by: Chanwoo Choi
[cw00.choi: Edit the COMPILE_TEST module dependency in Kconfig]
Signed-off-by: Chanwoo Choi
24 Aug, 2019
2 commits
-
Add devfreq driver for NVIDIA Tegra20 SoC's. The driver periodically
reads out Memory Controller counters and adjusts memory frequency based
on the memory clients activity.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
[Removed MAINTAINERS updates by MyungJoo so that it can be sent elsewhere.]
Signed-off-by: MyungJoo Ham -
In order to reflect that driver serves NVIDIA Tegra30 and later SoC
generations, let's rename the driver's source file to "tegra30-devfreq.c".
This will make driver files to look more consistent after addition of a
driver for Tegra20.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Signed-off-by: MyungJoo Ham
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
06 Sep, 2016
1 commit
-
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
Signed-off-by: MyngJoo Ham
Reviewed-by: Chanwoo Choi
03 May, 2016
3 commits
-
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
Signed-off-by: MyungJoo Ham
Acked-by: Krzysztof Kozlowski -
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 / userspaceThe 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 deviceFor 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
Signed-off-by: Chanwoo Choi
[tjakobi: Reported RCU locking issue and cw00.choi fix it]
Reported-by: Tobias Jakobi
[linux.amoon: Reported possible recursive locking and cw00.choi fix it]
Reported-by: Anand Moon
Signed-off-by: MyungJoo Ham
Acked-by: Krzysztof Kozlowski -
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
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl
Tested-by: Anand Moon
Signed-off-by: MyungJoo Ham
Acked-by: Krzysztof Kozlowski
30 Jan, 2015
2 commits
-
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 governorCC 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 1Cc: Rafael J. Wysocki
Cc: MyungJoo Ham
Signed-off-by: Chanwoo Choi -
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 governorCc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
[Commit message rewritten & conflict resolved by MyungJoo]
Signed-off-by: MyungJoo Ham
29 Jan, 2015
1 commit
-
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 and Mikko
Perttunen .Signed-off-by: Tomeu Vizoso
Signed-off-by: MyungJoo Ham
03 Jun, 2013
2 commits
-
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
[myungjoo.ham@samsung.com: minor style update]
Signed-off-by: MyungJoo Ham
Cc: Jonghwan Choi
Cc: Kukjin Kim -
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
Acked-by: MyungJoo Ham
Cc: Jonghwan Choi
Cc: Kukjin Kim
20 Dec, 2011
1 commit
-
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
Signed-off-by: Kyungmin Park---
Changes from v1
- Support 4212 and 4412 as well as 4210.
02 Oct, 2011
2 commits
-
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
Signed-off-by: Kyungmin Park
Reviewed-by: Mike Turquette
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Kyungmin Park
Reviewed-by: Mike Turquette
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki