05 Mar, 2020
1 commit
-
commit 66d0e797bf095d407479c89952d42b1d96ef0a7f upstream.
This reverts commit 4585fbcb5331fc910b7e553ad3efd0dd7b320d14.
The name changing as devfreq(X) breaks some user space applications,
such as Android HAL from Unisoc and Hikey [1].
The device name will be changed unexpectly after every boot depending
on module init sequence. It will make trouble to setup some system
configuration like selinux for Android.So we'd like to revert it back to old naming rule before any better
way being found.[1] https://lkml.org/lkml/2018/5/8/1042
Cc: John Stultz
Cc: Greg Kroah-Hartman
Cc: stable@vger.kernel.org
Signed-off-by: Orson Zhai
Acked-by: Greg Kroah-Hartman
Signed-off-by: Chanwoo Choi
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
2 commits
-
[ Upstream commit eff5d31f7407fa9d31fb840106f1593399457298 ]
To build test, add COMPILE_TEST depedency to both ARM_RK3399_DMC_DEVFREQ
and DEVFREQ_EVENT_ROCKCHIP_DFI configuration. And ARM_RK3399_DMC_DEVFREQ
used the SMCCC interface so that add HAVE_ARM_SMCCC dependency to prevent
the build break.Reported-by: kbuild test robot
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin -
[ Upstream commit d4556f5e99d5f603913bac01adaff8670cb2d08b ]
Putting a 'struct devfreq_event_dev' object on the stack is generally
a bad idea and here it leads to a warnig about potential stack overflow:drivers/devfreq/event/exynos-ppmu.c:643:12: error: stack frame size of 1040 bytes in function 'exynos_ppmu_probe' [-Werror,-Wframe-larger-than=]
There is no real need for the device structure, only the string inside
it, so add an internal helper function that simply takes the string
as its argument and remove the device structure.Fixes: 1dd62c66d345 ("PM / devfreq: events: extend events by type of counted data")
Signed-off-by: Arnd Bergmann
[cw00.choi: Fix the issue from 'desc->name' to 'desc[j].name']
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin
06 Feb, 2020
1 commit
-
commit 2fee1a7cc6b1ce6634bb0f025be2c94a58dfa34d upstream.
The commit 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for
sysfs") changed the node name to devfreq(x). After this commit, it is not
possible to get the device name through /sys/class/devfreq/devfreq(X)/*.Add new name attribute in order to get device name.
Cc: stable@vger.kernel.org
Fixes: 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for sysfs")
Signed-off-by: Chanwoo Choi
Signed-off-by: Greg Kroah-Hartman
18 Jan, 2020
1 commit
-
commit 5fdb0684b5b0f41402161f068d3d84bf6ed1c3f4 upstream.
Compile-testing this driver fails if CONFIG_COMMON_CLK is not set:
drivers/devfreq/tegra30-devfreq.o: In function `tegra_devfreq_target':
tegra30-devfreq.c:(.text+0x164): undefined reference to `clk_set_min_rate'Fixes: 35f8dbc72721 ("PM / devfreq: tegra: Enable COMPILE_TEST for the driver")
Signed-off-by: Arnd Bergmann
Reviewed-by: Dmitry Osipenko
Signed-off-by: Chanwoo Choi
Signed-off-by: Greg Kroah-Hartman
09 Jan, 2020
4 commits
-
commit d68adc8f85cd757bd33c8d7b2660ad6f16f7f3dc upstream.
The governor is initialized after sysfs attributes become visible so in
theory the governor field can be NULL here.Fixes: bcf23c79c4e46 ("PM / devfreq: Fix available_governor sysfs")
Signed-off-by: Leonard Crestez
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Chanwoo Choi
Signed-off-by: Chanwoo Choi
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 42a6b25e67df6ee6675e8d1eaf18065bd73328ba ]
Right now devfreq_dev_release will print a warning and abort the rest of
the cleanup if the devfreq instance is not part of the global
devfreq_list. But this is a valid scenario, for example it can happen if
the governor can't be found or on any other init error that happens
after device_register.Initialize devfreq->node to an empty list head in devfreq_add_device so
that list_del becomes a safe noop inside devfreq_dev_release and we can
continue the rest of the cleanup.Signed-off-by: Leonard Crestez
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Chanwoo Choi
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin -
[ Upstream commit e7cc792d00049c874010b398a27c3cc7bc8fef34 ]
The devfreq_notifier_call functions will update scaling_min_freq and
scaling_max_freq when the OPP table is updated.If fetching the maximum frequency fails then scaling_max_freq remains
set to zero which is confusing. Set to ULONG_MAX instead so we don't
need special handling for this case in other places.Signed-off-by: Leonard Crestez
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Chanwoo Choi
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin -
[ Upstream commit e876e710ede23f670494331e062d643928e4142a ]
Notifier callbacks shouldn't return negative errno but one of the
NOTIFY_OK/DONE/BAD values.The OPP core will ignore return values from notifiers but returning a
value that matches NOTIFY_STOP_MASK will stop the notification chain.Fix by always returning NOTIFY_OK.
Signed-off-by: Leonard Crestez
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Chanwoo Choi
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin
18 Dec, 2019
1 commit
-
commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream.
There is no locking in this sysfs show function so stats printing can
race with a devfreq_update_status called as part of freq switching or
with initialization.Also add an assert in devfreq_update_status to make it clear that lock
must be held by caller.Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats")
Cc: stable@vger.kernel.org
Signed-off-by: Leonard Crestez
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Chanwoo Choi
Signed-off-by: Chanwoo Choi
Signed-off-by: Greg Kroah-Hartman
26 Aug, 2019
1 commit
-
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
25 Aug, 2019
6 commits
-
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 -
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 -
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 -
Correct the documentation for devm_devfreq_remove_device() argument.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Chanwoo Choi
Signed-off-by: MyungJoo Ham -
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 -
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
24 Aug, 2019
21 commits
-
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 -
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 -
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 -
Reorder 'i' and 'v' in "drvier".
Signed-off-by: Gaël PORTAY
Reviewed-by: Chanwoo Choi
Signed-off-by: MyungJoo Ham -
Add missing 'r' in "monitoing".
Signed-off-by: Gaël PORTAY
Reviewed-by: Chanwoo Choi
Signed-off-by: MyungJoo Ham -
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 -
The driver's compilation doesn't have any specific dependencies, hence
the COMPILE_TEST option can be supported in Kconfig.Signed-off-by: Dmitry Osipenko
Reviewed-by: Chanwoo Choi
Signed-off-by: MyungJoo Ham -
The devfreq driver can be used on Tegra30 without any code change and
it works perfectly fine, the default Tegra124 parameters are good enough
for Tegra30.Signed-off-by: Dmitry Osipenko
Reviewed-by: Chanwoo Choi
[Modified by MyungJoo to depends on Tegra30/114/124/210 only]
Signed-off-by: MyungJoo Ham -
Move hardware configuration to governor's start/resume methods.
This allows to re-initialize hardware counters and reconfigure
cleanly if governor was stopped/paused. That is needed because we
are not aware of all hardware changes that happened while governor
was stopped and the paused state may get out of sync with reality,
hence it's better to start with a clean slate after the pause. In
a result there is no memory bandwidth starvation after resume from
suspend-to-ram that results in display controller underflowing that
happens on resume because of improper decision made by devfreq about
the required memory frequency. This change also cleans up code a tad
by moving hardware-configuration code into a single location.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
There is no need to register the ACTMON's governor separately from
the driver, hence let's move the registration into the driver's probe
function for consistency and to make code cleaner a tad.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
The ACTMON's governor supports only the Tegra's devfreq device and there
is no need to use any other governor, hence let's mark Tegra governor as
immutable to permanently stick it with Tegra's devfreq device.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
The frequency value potentially could change in-between. It doesn't
cause any real problem at all right now, but that could change in the
future. Hence let's avoid the inconsistency.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
Reset hardware, disable ACTMON clock, release OPP's and handle all
possible error cases correctly, maintaining the correct tear down
order. Also use devm_platform_ioremap_resource() which is now available
in the kernel.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
There is no guarantee that interrupt handling isn't running in parallel
with tegra_actmon_disable_interrupts(), hence it is necessary to protect
DEV_CTRL register accesses and clear IRQ status with ACTMON's IRQ being
disabled in the Interrupt Controller in order to ensure that device
interrupt is indeed being disabled.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
There is no real need in the primary interrupt handler, hence move
everything to the secondary (threaded) handler. In a result locking
is consistent now and there are no potential races with the interrupt
handler because it is protected with the devfreq's mutex.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
There is no real benefit from doing so, hence let's drop that rate setting
for consistency.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
The clk_set_min_rate() could fail and in this case clk_set_rate() sets
rate to 0, which may drop EMC rate to minimum and make machine very
difficult to use.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
The write memory barrier isn't needed because the BUS buffer is flushed
by read after write that happens after the removed wmb(), we will also
use readl() instead of the relaxed version to ensure that read is indeed
completed.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
There is no need to insert memory barrier on each readl/writel
invocation, hence use the relaxed versions.Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham -
The kHz to Hz is incorrectly converted in a few places in the code,
this results in a wrong frequency being calculated because devfreq core
uses OPP frequencies that are given in Hz to clamp the rate, while
tegra-devfreq gives to the core value in kHz and then it also expects to
receive value in kHz from the core. In a result memory freq is always set
to a value which is close to ULONG_MAX because of the bug. Hence the EMC
frequency is always capped to the maximum and the driver doesn't do
anything useful. This patch was tested on Tegra30 and Tegra124 SoC's, EMC
frequency scaling works properly now.Cc: # 4.14+
Tested-by: Steev Klimaszewski
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: MyungJoo Ham
19 Jun, 2019
1 commit
-
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundationthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman
05 Jun, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more detailsextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 263 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Reviewed-by: Alexios Zavras
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de
Signed-off-by: Greg Kroah-Hartman