summaryrefslogtreecommitdiff
path: root/drivers/devfreq
AgeCommit message (Collapse)Author
2019-11-29PM / devfreq: Add missing locking while setting suspend_freqMarek Szyprowski
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) [<c0112588>] (unwind_backtrace) from [<c010e070>] (show_stack+0x10/0x14) [<c010e070>] (show_stack) from [<c0afb010>] (dump_stack+0xb4/0xe0) [<c0afb010>] (dump_stack) from [<c01272e0>] (__warn+0xf4/0x10c) [<c01272e0>] (__warn) from [<c01273a8>] (warn_slowpath_fmt+0xb0/0xb8) [<c01273a8>] (warn_slowpath_fmt) from [<c07d105c>] (devfreq_update_status+0xc0/0x188) [<c07d105c>] (devfreq_update_status) from [<c07d2d70>] (devfreq_set_target+0xb0/0x15c) [<c07d2d70>] (devfreq_set_target) from [<c07d3598>] (devfreq_suspend+0x2c/0x64) [<c07d3598>] (devfreq_suspend) from [<c05de0b0>] (dpm_suspend+0xa4/0x57c) [<c05de0b0>] (dpm_suspend) from [<c05def74>] (dpm_suspend_start+0x98/0xa0) [<c05def74>] (dpm_suspend_start) from [<c0195b58>] (suspend_devices_and_enter+0xec/0xc74) [<c0195b58>] (suspend_devices_and_enter) from [<c0196a20>] (pm_suspend+0x340/0x410) [<c0196a20>] (pm_suspend) from [<c019480c>] (state_store+0x6c/0xc8) [<c019480c>] (state_store) from [<c033fc50>] (kernfs_fop_write+0x10c/0x228) [<c033fc50>] (kernfs_fop_write) from [<c02a6d3c>] (__vfs_write+0x30/0x1d0) [<c02a6d3c>] (__vfs_write) from [<c02a9afc>] (vfs_write+0xa4/0x180) [<c02a9afc>] (vfs_write) from [<c02a9d58>] (ksys_write+0x60/0xd8) [<c02a9d58>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xed3d7fa8 to 0xed3d7ff0) ... irq event stamp: 9667 hardirqs last enabled at (9679): [<c0b1e7c4>] _raw_spin_unlock_irq+0x20/0x58 hardirqs last disabled at (9698): [<c0b16a20>] __schedule+0xd8/0x818 softirqs last enabled at (9694): [<c01026fc>] __do_softirq+0x4fc/0x5fc softirqs last disabled at (9719): [<c012fe68>] irq_exit+0x16c/0x170 ---[ end trace 41ac5b57d046bdbc ]--- ------------[ cut here ]------------ Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-11-06PM / devfreq: tegra30: Tune up MCCPU boost-down coefficientDmitry Osipenko
MCCPU boosts up very aggressively by 800% and boosts down very mildly by 10%. This doesn't work well when system is idling because the very slow de-boosting results in lots of consecutive-down interrupts, in result memory stays clocked high and CPU doesn't enter deepest idling state instead of keeping memory at lowest freq and having CPU cluster turned off. A more faster de-boosting fixes the case of idling system and doesn't affect the case of an active system. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Support variable polling intervalDmitry Osipenko
The ACTMON governor is interrupt-driven and currently hardware's polling interval is fixed to 16ms in the driver. Devfreq supports variable polling interval by the generic governors, let's re-use the generic interface for changing of the polling interval. Now the polling interval can be changed dynamically via /sys/class/devfreq/devfreq0/polling_interval. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: Add new interrupt_driven flag for governorsDmitry Osipenko
Currently interrupt-driven governors (like NVIDIA Tegra30 ACTMON governor) are used to set polling_ms=0 in order to avoid periodic polling of device status by devfreq core. This means that polling interval can't be changed by userspace for such governors. The new governor flag allows interrupt-driven governors to convey that devfreq core shouldn't perform polling of device status and thus generic devfreq polling interval could be supported by these governors now. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Use kHz units for dependency thresholdDmitry Osipenko
The dependency threshold designates a memory activity level below which CPU's frequency isn't accounted. Currently the threshold is given in "memory cycle" units and that value depends on the polling interval which is fixed to 12ms in the driver. Later on we'd want to add support for a variable polling interval and thus the threshold value either needs to be scaled in accordance to the polling interval or it needs to be represented in a units that do not depend on the polling interval. It is nicer to have threshold value being defined independently of the polling interval, thus this patch converts the dependency threshold units from "cycle" to "kHz". Having this change as a separate-preparatory patch will make easier to follow further patches. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Disable consecutive interrupts when appropriateDmitry Osipenko
Consecutive interrupts should be disabled when boosting is completed. Currently the disabling of "lower" interrupt happens only for MCCPU monitor that uses dependency threshold, but even in a case of MCCPU the interrupt isn't getting disabled if CPU's activity is above the threshold. This results in a lot of dummy interrupt requests. The boosting feature is used by both MCCPU and MCALL, boosting should be stopped once it reaches 0 for both of the monitors and regardless of the activity level. The boosting stops to grow once the maximum limit is hit and thus the "upper" interrupt needs to be disabled when the limit is reached. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Don't enable already enabled consecutive interruptsDmitry Osipenko
Consecutive up/down interrupt-bit is set in the interrupt status register only if that interrupt was previously enabled. Thus enabling the already enabled interrupt doesn't do much for us. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Include appropriate headerDmitry Osipenko
It's not very correct to include mod_devicetable.h for the OF device drivers and of_device.h should be included instead. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Constify structsDmitry Osipenko
Constify unmodifiable structs, for consistency. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Don't enable consecutive-down interrupt on startupDmitry Osipenko
The consecutive-down event tells that we should perform frequency de-boosting, but boosting is in a reset state on start and hence the event won't do anything useful for us and it will be just a dummy interrupt request. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Reset boosting on startupDmitry Osipenko
Governor could be stopped while boosting is active. We have assumption that everything is reset on governor's restart, including the boosting value, which was missed. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Move clk-notifier's registration to governor's startDmitry Osipenko
There is no point in receiving of the notifications while governor is stopped, let's keep them disabled like we do for the CPU freq-change notifications. This also fixes a potential use-after-free bug if notification happens after device's removal. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Use CPUFreq notifierDmitry Osipenko
The CPU's client need to take into account that CPUFreq may change while memory activity not, staying high. Thus an appropriate frequency notifier should be used in addition to the clk-notifier. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Use kHz units uniformly in the codeDmitry Osipenko
Part of the code uses Hz units and the other kHz, let's switch to kHz everywhere for consistency. A small benefit from this change (besides code's cleanup) is that now powertop utility correctly displays devfreq's stats, for some reason it expects them to be in kHz. Tested-by: Peter Geis <pgwipeout@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Fix integer overflow on CPU's freq max outDmitry Osipenko
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 <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Drop write-barrierDmitry Osipenko
There is no need in a write-barrier now, given that interrupt masking is handled by CPU's GIC now. Hence we know exactly that interrupt won't fire after stopping the devfreq's governor. In other cases we don't care about potential buffering of the writes to hardware and thus there is no need to stall CPU. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Handle possible round-rate errorDmitry Osipenko
The EMC clock rate rounding technically could fail, hence let's handle the error cases properly. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Keep interrupt disabled while governor is stoppedDmitry Osipenko
There is no real need to keep interrupt always-enabled, will be nicer to keep it disabled while governor is inactive. Suggested-by: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: tegra30: Change irq type to unsigned intDmitry Osipenko
IRQ numbers are always positive, hence the corresponding variable should be unsigned to keep types consistent. This is a minor change that cleans up code a tad more. Suggested-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: exynos-ppmu: remove useless assignmentMarek Szyprowski
The error code is propagated to the caller, so there is no need to keep it additionally in the unused variable. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: Lock devfreq in trans_stat_showLeonard Crestez
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 <leonard.crestez@nxp.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: Check NULL governor in available_governors_showLeonard Crestez
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 <leonard.crestez@nxp.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-11-06PM / devfreq: Make log message more explicit when devfreq device already existsMatthias Kaehlcke
Before creating a new devfreq device devfreq_add_device() checks if there is already a devfreq dev associated with the requesting device (parent). If that's the case the function rejects to create another devfreq dev for that parent and logs an error. The error message is very unspecific, make it a bit more explicit. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2019-08-26PM / devfreq: passive: fix compiler warningMyungJoo Ham
The recent commit of PM / devfreq: passive: Use non-devm notifiers had incurred compiler warning, "unused variable 'dev'". Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-25PM / devfreq: passive: Use non-devm notifiersLeonard Crestez
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 <leonard.crestez@nxp.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-25PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate()Kamil Konieczny
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 <k.konieczny@partner.samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-25PM / devfreq: exynos-bus: Correct clock enable sequenceKamil Konieczny
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 <k.konieczny@partner.samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-25PM / devfreq: Correct devm_devfreq_remove_device() documentationKrzysztof Kozlowski
Correct the documentation for devm_devfreq_remove_device() argument. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-25PM / devfreq: events: extend events by type of counted dataLukasz Luba
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 <l.luba@partner.samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> [Updated property by MyungJoo. data_type --> event_type] Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-25PM / devfreq: exynos-events: change matching code during probeLukasz Luba
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 <l.luba@partner.samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra20: add COMMON_CLK dependencyArnd Bergmann
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 <arnd@arndb.de> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: events: add Exynos PPMU new eventsLukasz Luba
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 <l.luba@partner.samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: Fix kernel oops on governor module loadEzequiel Garcia
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 <ezequiel@collabora.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: rk3399_dmc: Fix spelling typoGaël PORTAY
Reorder 'i' and 'v' in "drvier". Signed-off-by: Gaël PORTAY <gael.portay@collabora.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: Fix spelling typoGaël PORTAY
Add missing 'r' in "monitoing". Signed-off-by: Gaël PORTAY <gael.portay@collabora.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: Introduce driver for NVIDIA Tegra20Dmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> [Removed MAINTAINERS updates by MyungJoo so that it can be sent elsewhere.] Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.cDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Enable COMPILE_TEST for the driverDmitry Osipenko
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 <digetx@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Support Tegra30Dmitry Osipenko
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 <digetx@gmail.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> [Modified by MyungJoo to depends on Tegra30/114/124/210 only] Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Reconfigure hardware on governor's restartDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Move governor registration to driver's probeDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Mark ACTMON's governor as immutableDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Avoid inconsistency of current frequency valueDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Clean up driver's probe / removeDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Properly disable interruptsDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Drop primary interrupt handlerDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Don't set EMC clock rate to maximum on probeDmitry Osipenko
There is no real benefit from doing so, hence let's drop that rate setting for consistency. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Don't ignore clk errorsDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Replace write memory barrier with the read barrierDmitry Osipenko
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 <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
2019-08-24PM / devfreq: tegra: Replace readl-writel with relaxed versionsDmitry Osipenko
There is no need to insert memory barrier on each readl/writel invocation, hence use the relaxed versions. Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>