user/sven/linux.git/drivers/devfreq/Kconfig, branch v4.14.105

PM / devfreq: Add dependency on PM_OPP

2017-08-28T01:23:57Z

The devfreq ues the OPP library to handle the voltage and frequency for the device basically. This patch adds the dependency on CONFIG_PM_OPP in order to prevent either the build break or the unknow behavior. Signed-off-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: rockchip: add PM_DEVFREQ_EVENT dependency

2016-09-19T11:12:17Z

The newly added ARM_RK3399_DMC_DEVFREQ driver requires the DEVFREQ_EVENT_ROCKCHIP_DFI driver and tries to turn that on through a 'select' statement, and that in turn has a dependency on PM_DEVFREQ_EVENT, which may be disabled here: warning: (ARM_RK3399_DMC_DEVFREQ) selects DEVFREQ_EVENT_ROCKCHIP_DFI which has unmet direct dependencies (PM_DEVFREQ && PM_DEVFREQ_EVENT && ARCH_ROCKCHIP) We probably want a 'depends on' here, but other drivers use 'select' too, so for consistency I'm doing the same. Signed-off-by: Arnd Bergmann Fixes: 5a893e31a636 (PM / devfreq: rockchip: add devfreq driver for rk3399 dmc) Acked-by: Chanwoo Choi Acked-by: MyungJoo Ham Signed-off-by: Rafael J. Wysocki

partial revert of "PM / devfreq: Add COMPILE_TEST for build coverage"

2016-09-14T21:06:38Z

This reverts the Tegra part of commit 797da5598f3a (PM / devfreq: Add COMPILE_TEST for build coverage) that introduced a build failute in in linux-next. [ rjw: Changelog ] Signed-off-by: Stephen Rothwell Signed-off-by: Rafael J. Wysocki

PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

2016-09-06T04:26:34Z

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

PM / devfreq: fix Kconfig indent style

2016-09-06T04:08:40Z

Use tab rather than space to indent, and tab + two spaces to indent help message. Signed-off-by: Jisheng Zhang Signed-off-by: MyungJoo Ham

PM / devfreq: Add COMPILE_TEST for build coverage

2016-09-06T04:08:40Z

The SoC-specific devfreq and devfreq-event drivers can be build tested on all architectures. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: make exynos-bus ARM_EXYNOS_BUS_DEVFREQ tristate

2016-07-06T04:11:22Z

The Kconfig currently controlling compilation of this code is: devfreq/Kconfig:config ARM_EXYNOS_BUS_DEVFREQ devfreq/Kconfig: bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver" ...meaning that it currently is not being built as a module by anyone. Rather than rip out the existing modular code, Chanwoo indicated that he'd rather see the driver offered as tristate. I don't have the hardware for runtime validation, so this change is only validated for compile and modpost. Signed-off-by: Paul Gortmaker Acked-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver

2016-05-03T02:20:09Z

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

PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor

2016-05-03T02:20:08Z

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 [tjakobi: Reported debugfs error during booting and cw00.choi fix it.] Reported-by: Tobias Jakobi Signed-off-by: MyungJoo Ham Acked-by: Krzysztof Kozlowski

PM / devfreq: Add new passive governor

2016-05-03T02:20:07Z

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