summaryrefslogtreecommitdiff
path: root/drivers/devfreq/tegra30-devfreq.c
AgeCommit message (Collapse)Author
2021-10-05PM / devfreq: tegra30: Check whether clk_round_rate() returns zero rateDmitry Osipenko
EMC clock is always-on and can't be zero. Check whether clk_round_rate() returns zero rate and error out if it does. It can return zero if clock tree isn't initialized properly. Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-10-05PM / devfreq: tegra30: Use resource-managed helpersDmitry Osipenko
Use resource-managed API helpers to simplify driver's probe() function, making code cleaner. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-05-21PM / devfreq: tegra30: Support thermal coolingDmitry Osipenko
Expose ACTMON devfreq device as a cooling device in order to throttle memory freq on overheat. Throttling of memory freq has a significant cooling effect on NVIDIA Tegra SoCs since higher memory freqs require higher SoC core voltage which is one of the main causes of the heating. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2021-02-02devfreq: tegra30: Migrate to dev_pm_opp_set_opp()Viresh Kumar
dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should be used instead. Migrate to the new API. We don't want the OPP core to manage the clk for this driver, migrate to dev_pm_opp_of_add_table_noclk() to make sure dev_pm_opp_set_opp() doesn't have any side effects. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2020-12-07PM / devfreq: tegra30: Separate configurations per-SoC generationDmitry Osipenko
Previously we were using count-weight of the T124 for T30 in order to get EMC clock rate that was reasonable for T30. In fact the count-weight should be x2 times smaller on T30, but then devfreq was producing a bit too low EMC clock rate for ISO memory clients, like display controller for example. Now both Tegra ACTMON and Tegra DRM display drivers support interconnect framework and display driver tells to ICC what a minimum memory bandwidth is needed, preventing FIFO underflows. Thus, now we can use a proper count-weight value for Tegra30 and MC_ALL device config needs a bit more aggressive boosting. Add a separate ACTMON driver configuration that is specific to Tegra30. Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-12-07PM / devfreq: tegra30: Support interconnect and OPPs from device-treeDmitry Osipenko
This patch moves ACTMON driver away from generating OPP table by itself, transitioning it to use the table which comes from device-tree. This change breaks compatibility with older device-trees and brings support for the interconnect framework to the driver. This is a mandatory change which needs to be done in order to implement interconnect-based memory DVFS, i.e. device-trees need to be updated. Now ACTMON issues a memory bandwidth requests using dev_pm_opp_set_bw() instead of driving EMC clock rate directly. Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-10-26PM / devfreq: tegra30: Silence deferred probe errorDmitry Osipenko
Tegra EMC driver was turned into a regular kernel driver, meaning that it could be compiled as a loadable kernel module now. Hence EMC clock isn't guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER. Let's silence the deferred probe error. Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-10-26PM / devfreq: Add governor attribute flag for specifc sysfs nodesChanwoo Choi
DEVFREQ supports the default governors like performance, simple_ondemand and also allows the devfreq driver to add their own governor like tegra30-devfreq.c according to their requirement. In result, some sysfs attributes are useful or not useful. Prior to that the user can access all sysfs attributes regardless of the available attributes. So, clarify the access permission of sysfs attributes according to governor. When adding the devfreq governor, can specify the available attribute information by using DEVFREQ_GOV_ATTR_* constant variable. The user can read or write the sysfs attributes in accordance to the specified attributes. When adding the governor, can add the following attributes according to the governor feature. [Definition for speific sysfs attributes] - DEVFREQ_GOV_ATTR_POLLING_INTERVAL to update polling interval for timer. : /sys/class/devfreq/[devfreq dev name]/polling_interval - DEVFREQ_GOV_ATTR_TIMER to change the type of timer on either deferrable or dealyed timer. : /sys/class/devfreq/[devfreq dev name]/timer And all devfreq governors have to support the following common attributes. The common attributes are added to devfreq class by default. - governor - available_governors - available_frequencies - cur_freq - target_freq - min_freq - max_freq - trans_stat [Table of governor attribute flags for devfreq governors] ------------------------------------------------------------------------------ | simple | perfor | power | user | passive | tegra30 | ondemand | mance | save | space| | ------------------------------------------------------------------------------ governor | O | O | O | O | O | O available_governors | O | O | O | O | O | O available_frequencies | O | O | O | O | O | O cur_freq | O | O | O | O | O | O target_freq | O | O | O | O | O | O min_freq | O | O | O | O | O | O max_freq | O | O | O | O | O | O trans_stat | O | O | O | O | O | O -------------------------------------------------------- polling_interval | O | X | X | X | X | O timer | O | X | X | X | X | X ------------------------------------------------------------------------------ Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-10-26PM / devfreq: Add governor feature flagChanwoo Choi
The devfreq governor is able to have the specific flag as follows in order to implement the specific feature. For example, devfreq allows user to change the governors on runtime via sysfs interface. But, if devfreq device uses 'passive' governor, don't allow user to change the governor. For this case, define the DEVFREQ_GOV_FLAG_IMMUTABLE and set it to flag of passive governor. [Definition for governor flag] - DEVFREQ_GOV_FLAG_IMMUTABLE : If immutable flag is set, governor is never changeable to other governors. - DEVFREQ_GOV_FLAG_IRQ_DRIVEN : Devfreq core won't schedule polling work for this governor if value is set. [Table of governor flag for devfreq governors] ------------------------------------------------------------------------------ | simple | perfor | power | user | passive | tegra30 | ondemand | mance | save | space| | ------------------------------------------------------------------------------ immutable | X | X | X | X | O | O interrupt_driven | X(polling)| X | X | X | X | O (irq) ------------------------------------------------------------------------------ Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-09-29PM / devfreq: tegra30: Improve initial hardware resettingDmitry Osipenko
It's safe to enable the ACTMON clock at any time during driver probing, even if we don't know the state of hardware, because it's used only for collecting and processing stats, and interrupt is kept disabled. This allows us to slightly improve code which performs initial hardware resetting by making use of a single reset_control_reset() instead of assert/deassert pair. Secondly, a potential error of the reset-control API is handled nicely now. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-09-23PM / devfreq: tegra30: Disable clock on error in probeDan Carpenter
This error path needs to call clk_disable_unprepare(). Fixes: 7296443b900e ("PM / devfreq: tegra30: Handle possible round-rate error") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-05-28PM / devfreq: tegra30: Delete an error message in tegra_devfreq_probe()Markus Elfring
The function “platform_get_irq” can log an error already. Thus omit a redundant message for the exception handling in the calling function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-05-28PM / devfreq: tegra30: Make CPUFreq notifier to take into account boostingDmitry Osipenko
We're taking into account both HW memory-accesses + CPU activity based on current CPU's frequency. For memory-accesses there is a kind of hysteresis in a form of "boosting" which is managed by the tegra30-devfreq driver. If current HW memory activity is higher than activity judged based of the CPU's frequency, then there is no need to schedule cpufreq_update_work because the result of the work will be a NO-OP. And thus, tegra_actmon_cpufreq_contribution() should return 0, meaning that at the moment CPU frequency doesn't contribute anything to the final decision about required memory clock rate. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2020-03-25PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event nameChanwoo Choi
DEVFREQ_GOV_INTERVAL event indicates that update the interval for polling mode of devfreq device. But, this event name doesn't specify exactly what to do. Change DEVFREQ_GOV_INTERVAL event name to DEVFREQ_GOV_UPDATE_INTERVAL which specifies what to do by event name. And modify the function name to DEVFREQ_GOV_UPDATE_INTERVAL with 'devfreq_' prefix + verb + object as following: - devfreq_interval_update -> devfreq_updatee_interval Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.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: 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-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>