linux-toradex.git/drivers/devfreq/tegra30-devfreq.c, branch v5.9-rc5

PM / devfreq: tegra30: Delete an error message in tegra_devfreq_probe()

2020-05-28T09:02:39+00:00

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 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Make CPUFreq notifier to take into account boosting

2020-05-28T09:02:39+00:00

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 
Signed-off-by: Chanwoo Choi

PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event name

2020-03-24T23:35:03+00:00

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 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Tune up MCCPU boost-down coefficient

2019-11-06T03:04:01+00:00

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 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Support variable polling interval

2019-11-06T03:04:01+00:00

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 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Use kHz units for dependency threshold

2019-11-06T03:04:01+00:00

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 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Disable consecutive interrupts when appropriate

2019-11-06T03:04:01+00:00

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 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Don't enable already enabled consecutive interrupts

2019-11-06T03:04:01+00:00

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 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Include appropriate header

2019-11-06T03:04:01+00:00

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 
Tested-by: Peter Geis 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi

PM / devfreq: tegra30: Constify structs

2019-11-06T03:04:01+00:00

Constify unmodifiable structs, for consistency.

Reviewed-by: Chanwoo Choi 
Tested-by: Peter Geis 
Signed-off-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi