01 Oct, 2020
1 commit
-
[ Upstream commit 53b4b2aeee26f42cde5ff2a16dd0d8590c51a55a ]
There is another kHz-conversion bug in the code, resulting in integer
overflow. Although, this time the resulting value is 4294966296 and it's
close to ULONG_MAX, which is okay in this case.Reviewed-by: Chanwoo Choi
Tested-by: Peter Geis
Signed-off-by: Dmitry Osipenko
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin
03 Sep, 2020
3 commits
-
[ Upstream commit 63ef91f24f9bfc70b6446319f6cabfd094481372 ]
Booting a recent kernel on a rk3399-based system (nanopc-t4),
equipped with a recent u-boot and ATF results in an Oops due
to a NULL pointer dereference.This turns out to be due to the rk3399-dmc driver looking for
an *undocumented* property (rockchip,pmu), and happily using
a NULL pointer when the property isn't there.Instead, make most of what was brought in with 9173c5ceb035
("PM / devfreq: rk3399_dmc: Pass ODT and auto power down parameters
to TF-A.") conditioned on finding this property in the device-tree,
preventing the driver from exploding.Cc: stable@vger.kernel.org
Fixes: 9173c5ceb035 ("PM / devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.")
Signed-off-by: Marc Zyngier
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin -
[ Upstream commit 39a6e4739c19d5334e552d71ceca544ed84f4b87 ]
The probe process may fail, but the devfreq event device remains
enabled. Call devfreq_event_disable_edev on the error return path.Signed-off-by: Yangtao Li
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin -
[ Upstream commit 29d867e97f7d781972ed542acfca3c2c0b512603 ]
of_node_put() needs to be called when the device node which is got
from of_parse_phandle has finished using.Signed-off-by: Yangtao Li
Signed-off-by: Chanwoo Choi
Signed-off-by: Sasha Levin
10 May, 2020
1 commit
-
commit e1e047ace8cef6d143f38c7d769753f133becbe6 upstream.
Commit 2abb0d5268ae ("PM / devfreq: Lock devfreq in trans_stat_show")
revealed a missing locking while calling devfreq_update_status() function
during suspend/resume cycle.Code analysis revealed that devfreq_set_target() function was called
without needed locks held for setting device specific suspend_freq if such
has been defined. This patch fixes that by adding the needed locking, what
fixes following kernel warning on Exynos4412-based OdroidU3 board during
system suspend:PM: suspend entry (deep)
Filesystems sync: 0.002 seconds
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1385 at drivers/devfreq/devfreq.c:204 devfreq_update_status+0xc0/0x188
Modules linked in:
CPU: 2 PID: 1385 Comm: rtcwake Not tainted 5.4.0-rc6-next-20191111 #6848
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb4/0xe0)
[] (dump_stack) from [] (__warn+0xf4/0x10c)
[] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
[] (warn_slowpath_fmt) from [] (devfreq_update_status+0xc0/0x188)
[] (devfreq_update_status) from [] (devfreq_set_target+0xb0/0x15c)
[] (devfreq_set_target) from [] (devfreq_suspend+0x2c/0x64)
[] (devfreq_suspend) from [] (dpm_suspend+0xa4/0x57c)
[] (dpm_suspend) from [] (dpm_suspend_start+0x98/0xa0)
[] (dpm_suspend_start) from [] (suspend_devices_and_enter+0xec/0xc74)
[] (suspend_devices_and_enter) from [] (pm_suspend+0x340/0x410)
[] (pm_suspend) from [] (state_store+0x6c/0xc8)
[] (state_store) from [] (kernfs_fop_write+0x10c/0x228)
[] (kernfs_fop_write) from [] (__vfs_write+0x30/0x1d0)
[] (__vfs_write) from [] (vfs_write+0xa4/0x180)
[] (vfs_write) from [] (ksys_write+0x60/0xd8)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed3d7fa8 to 0xed3d7ff0)
...
irq event stamp: 9667
hardirqs last enabled at (9679): [] _raw_spin_unlock_irq+0x20/0x58
hardirqs last disabled at (9698): [] __schedule+0xd8/0x818
softirqs last enabled at (9694): [] __do_softirq+0x4fc/0x5fc
softirqs last disabled at (9719): [] irq_exit+0x16c/0x170
---[ end trace 41ac5b57d046bdbc ]---
------------[ cut here ]------------Signed-off-by: Marek Szyprowski
Acked-by: Chanwoo Choi
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
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
18 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
