user/sven/linux.git/drivers/devfreq, branch v5.4.3

PM / devfreq: passive: fix compiler warning

2019-08-26T12:37:37Z

The recent commit of PM / devfreq: passive: Use non-devm notifiers had incurred compiler warning, "unused variable 'dev'". Reported-by: Stephen Rothwell Signed-off-by: MyungJoo Ham

PM / devfreq: passive: Use non-devm notifiers

2019-08-25T03:47:31Z

The devfreq passive governor registers and unregisters devfreq transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers. If devfreq itself is registered with devm then a warning is triggered on rmmod from devm_devfreq_unregister_notifier. Call stack looks like this: devm_devfreq_unregister_notifier+0x30/0x40 devfreq_passive_event_handler+0x4c/0x88 devfreq_remove_device.part.8+0x6c/0x9c devm_devfreq_dev_release+0x18/0x20 release_nodes+0x1b0/0x220 devres_release_all+0x78/0x84 device_release_driver_internal+0x100/0x1c0 driver_detach+0x4c/0x90 bus_remove_driver+0x7c/0xd0 driver_unregister+0x2c/0x58 platform_driver_unregister+0x10/0x18 imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq] This happens because devres_release_all will first remove all the nodes into a separate todo list so the nested devres_release from devm_devfreq_unregister_notifier won't find anything. Fix the warning by calling the non-devm APIS for frequency notification. Using devm wrappers is not actually useful for a governor anyway: it relies on the devfreq core to correctly match the GOV_START/GOV_STOP notifications. Fixes: 996133119f57 ("PM / devfreq: Add new passive governor") Signed-off-by: Leonard Crestez Acked-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate()

2019-08-25T03:46:48Z

Reuse opp core code for setting bus clock and voltage. As a side effect this allow usage of coupled regulators feature (required for boards using Exynos5422/5800 SoCs) because dev_pm_opp_set_rate() uses regulator_set_voltage_triplet() for setting regulator voltage while the old code used regulator_set_voltage_tol() with fixed tolerance. This patch also removes no longer needed parsing of DT property "exynos,voltage-tolerance" (no Exynos devfreq DT node uses it). After applying changes both functions exynos_bus_passive_target() and exynos_bus_target() have the same code, so remove exynos_bus_passive_target(). In exynos_bus_probe() replace it with exynos_bus_target. Signed-off-by: Kamil Konieczny Acked-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: exynos-bus: Correct clock enable sequence

2019-08-25T03:46:07Z

Regulators should be enabled before clocks to avoid h/w hang. This require change in exynos_bus_probe() to move exynos_bus_parse_of() after exynos_bus_parent_parse_of() and change in error handling. Similar change is needed in exynos_bus_exit() where clock should be disabled before regulators. Signed-off-by: Kamil Konieczny Acked-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: Correct devm_devfreq_remove_device() documentation

2019-08-25T03:45:34Z

Correct the documentation for devm_devfreq_remove_device() argument. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: events: extend events by type of counted data

2019-08-25T03:44:38Z

This patch adds posibility to choose what type of data should be counted by the PPMU counter. Now the type comes from DT where the event has been defined. When there is no 'event-data-type' the default value is used, which is 'read+write data in bytes'. It is needed when you want to know not only read+write data bytes but i.e. only write data in byte, or number of read requests, etc. Signed-off-by: Lukasz Luba Acked-by: Chanwoo Choi [Updated property by MyungJoo. data_type --> event_type] Signed-off-by: MyungJoo Ham

PM / devfreq: exynos-events: change matching code during probe

2019-08-25T03:36:47Z

The patch changes the way how the 'ops' gets populated for different device versions. The matching function now uses 'of_device_id' in order to identify the device type. Signed-off-by: Lukasz Luba Signed-off-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: tegra20: add COMMON_CLK dependency

2019-08-24T11:11:12Z

Compile-testing the new driver on platforms without CONFIG_COMMON_CLK leads to a link error: drivers/devfreq/tegra20-devfreq.o: In function `tegra_devfreq_target': tegra20-devfreq.c:(.text+0x288): undefined reference to `clk_set_min_rate' Add a dependency on COMMON_CLK to avoid this. Fixes: 1d39ee8dad6d ("PM / devfreq: Introduce driver for NVIDIA Tegra20") Signed-off-by: Arnd Bergmann Reviewed-by: Dmitry Osipenko Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: events: add Exynos PPMU new events

2019-08-24T11:11:12Z

Define new performance events supported by Exynos5422 SoC counters. The counters are built-in in Dynamic Memory Controller and provide information regarding memory utilization. Signed-off-by: Lukasz Luba Acked-by: Chanwoo Choi Signed-off-by: MyungJoo Ham

PM / devfreq: Fix kernel oops on governor module load

2019-08-24T11:11:12Z

A bit unexpectedly (but still documented), request_module may return a positive value, in case of a modprobe error. This is currently causing issues in the devfreq framework. When a request_module exits with a positive value, we currently return that via ERR_PTR. However, because the value is positive, it's not a ERR_VALUE proper, and is therefore treated as a valid struct devfreq_governor pointer, leading to a kernel oops. Fix this by returning -EINVAL if request_module returns a positive value. Fixes: b53b0128052ff ("PM / devfreq: Fix static checker warning in try_then_request_governor") Signed-off-by: Ezequiel Garcia Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham