PM / devfreq: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of

PM / devfreq: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Add error message for devm_devfreq_add_device()

It's difficult to notice that driver failed to probe by looking at KMSG
when devm_devfreq_add_device() fails. Add explicit erro

PM / devfreq: tegra30: Add error message for devm_devfreq_add_device()

It's difficult to notice that driver failed to probe by looking at KMSG
when devm_devfreq_add_device() fails. Add explicit error message for this
case.

Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Register config_clks helper

There is a corner case with Tegra30, where we want to skip clk
configuration that happens via dev_pm_opp_set_opp(), but still want the
OPP core to

PM / devfreq: tegra30: Register config_clks helper

There is a corner case with Tegra30, where we want to skip clk
configuration that happens via dev_pm_opp_set_opp(), but still want the
OPP core to read the "opp-hz" property so we can find the right OPP via
freq finding helpers.

The OPP core provides support for the platforms to provide config_clks
helpers now, lets use that instead of devm_pm_opp_of_add_table_noclk()
to achieve the same result, as the OPP core won't parse the DT's
"opp-hz" property anymore if the clock isn't provided.

Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

PM / devfreq: tegra30: Check whether clk_round_rate() returns zero rate

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 re

PM / devfreq: tegra30: Check whether clk_round_rate() returns zero rate

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 <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

PM / devfreq: tegra30: Use resource-managed helpers

Use resource-managed API helpers to simplify driver's probe() function,
making code cleaner.

Signed-off-by: Dmitry Osipenko <[email protected]>
Ac

PM / devfreq: tegra30: Use resource-managed helpers

Use resource-managed API helpers to simplify driver's probe() function,
making code cleaner.

Signed-off-by: Dmitry Osipenko <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

PM / devfreq: tegra30: Support thermal cooling

Expose ACTMON devfreq device as a cooling device in order to throttle
memory freq on overheat. Throttling of memory freq has a significant
cooling effe

PM / devfreq: tegra30: Support thermal cooling

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 <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

devfreq: tegra30: Migrate to dev_pm_opp_set_opp()

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 manag

devfreq: tegra30: Migrate to dev_pm_opp_set_opp()

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 <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>

show more ...

PM / devfreq: tegra30: Separate configurations per-SoC generation

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 co

PM / devfreq: tegra30: Separate configurations per-SoC generation

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 <[email protected]>
Tested-by: Nicolas Chauvet <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Support interconnect and OPPs from device-tree

This patch moves ACTMON driver away from generating OPP table by itself,
transitioning it to use the table which comes from devi

PM / devfreq: tegra30: Support interconnect and OPPs from device-tree

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 <[email protected]>
Tested-by: Nicolas Chauvet <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Silence deferred probe error

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

PM / devfreq: tegra30: Silence deferred probe error

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

show more ...

PM / devfreq: Add governor attribute flag for specifc sysfs nodes

DEVFREQ supports the default governors like performance, simple_ondemand and
also allows the devfreq driver to add their own governo

PM / devfreq: Add governor attribute flag for specifc sysfs nodes

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 <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: Add governor feature flag

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 g

PM / devfreq: Add governor feature flag

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 <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Improve initial hardware resetting

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

PM / devfreq: tegra30: Improve initial hardware resetting

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 <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Disable clock on error in probe

This error path needs to call clk_disable_unprepare().

Fixes: 7296443b900e ("PM / devfreq: tegra30: Handle possible round-rate error")
Signed-

PM / devfreq: tegra30: Disable clock on error in probe

This error path needs to call clk_disable_unprepare().

Fixes: 7296443b900e ("PM / devfreq: tegra30: Handle possible round-rate error")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

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

The function “platform_get_irq” can log an error already.
Thus omit a redundant message for the exception handling in the
call

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

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

show more ...

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

We're taking into account both HW memory-accesses + CPU activity based on
current CPU's frequency. For memory-accesses ther

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

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 <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event name

DEVFREQ_GOV_INTERVAL event indicates that update the interval
for polling mode of devfreq device. But, this event name doesn't
specify

PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event name

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 <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

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

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 ver

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

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

show more ...

PM / devfreq: tegra30: Support variable polling interval

The ACTMON governor is interrupt-driven and currently hardware's polling
interval is fixed to 16ms in the driver. Devfreq supports variable p

PM / devfreq: tegra30: Support variable polling interval

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 <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

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

The dependency threshold designates a memory activity level below which
CPU's frequency isn't accounted. Currently the threshold is give

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

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 <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Disable consecutive interrupts when appropriate

Consecutive interrupts should be disabled when boosting is completed.

Currently the disabling of "lower" interrupt happens onl

PM / devfreq: tegra30: Disable consecutive interrupts when appropriate

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

show more ...

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

Consecutive up/down interrupt-bit is set in the interrupt status register
only if that interrupt was previously enabled. Th

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

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

show more ...

PM / devfreq: tegra30: Include appropriate header

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

PM / devfreq: tegra30: Include appropriate header

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

show more ...

PM / devfreq: tegra30: Constify structs

Constify unmodifiable structs, for consistency.

Reviewed-by: Chanwoo Choi <[email protected]>
Tested-by: Peter Geis <[email protected]>
Signed-off-by:

PM / devfreq: tegra30: Constify structs

Constify unmodifiable structs, for consistency.

Reviewed-by: Chanwoo Choi <[email protected]>
Tested-by: Peter Geis <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: tegra30: Don't enable consecutive-down interrupt on startup

The consecutive-down event tells that we should perform frequency
de-boosting, but boosting is in a reset state on start and

PM / devfreq: tegra30: Don't enable consecutive-down interrupt on startup

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

show more ...