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>
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>
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>
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>
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>
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>
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>
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>
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>
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.