With the new design in place, the show() and store() callbacks check if
the policy is active or not before proceeding any further to avoid
potential races. And in order to guarantee that cpufreq_policy_free()
must be called after clearing the policy->cpus mask, i.e. by marking the
policy inactive.
In order to avoid introducing a bug around this later, print a warning
message if we end up freeing an active policy.
Also update cpufreq_online() a bit to make sure we clear the cpus mask
for each error case before calling cpufreq_policy_free().
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
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]>
There is a corner case with Tegra30, where we want to skip clk
configuration 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.
This is the easiest of the ways to make it work, without any special
hacks in the OPP core. Allow config_clks to be passed for single clk
case.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
This provides a simple implementation to configure multiple clocks for a
device.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Many helpers can be safely called only for devices that have a single
clk associated with them. Assert the same for those routines.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The helpers for the clock key, at least, would need to assert that the
helpers are called only for single clock case. Prepare for that by
adding an argument to the key finding helpers.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Replicate the same behavior as "rates" here and compare all values
instead of relying on the first entry alone.
Signed-off-by: Viresh Kumar <[email protected]>
This patch adds support to allow multiple clocks for a device.
The design is pretty much similar to how this is done for regulators,
and platforms can supply their own version of the config_clks() callback
if they have multiple clocks for their device. The core manages the
calls via opp_table->config_clks() eventually.
We have kept both "clk" and "clks" fields in the OPP table structure and
the reason is provided as a comment in _opp_set_clknames(). The same
isn't done for "rates" though and we use rates[0] at most of the places
now.
Co-developed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Tested-by: Jon Hunter <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>
Tested-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
dev_pm_opp_set_opp() can be called for any device, it may or may not
have a frequency value associated with it.
If a frequency value isn't available, we pass 0 to _set_opp(). Make it
optional instead by making _set_opp() accept a pointer instead, as the
frequency value is anyway available in the OPP. This makes
dev_pm_opp_set_opp() and _set_opp() completely independent of any
special key value.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Reuse _opp_compare_key() in _opp_add_static_v2() instead of just
comparing frequency while finding suspend frequency. Also add a comment
over _opp_compare_key() explaining its return values.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
commit 32715be4fe ("opp: Fix adding OPP entries in a wrong order if
rate is unavailable") removed the only user of this field, get rid of
rest of it now.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The OPP table is called "opp_table" at most of the places and "table" at
few. Make all of them follow the same naming convention, "opp_table".
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
There are three type of helpers, to find exact, ceil, and floor values,
replicated for multiple key types, freq, level, bw. And all of these
helpers share a lot of boilerplate code.
Add generic key finding helpers to reduce code redundancy.
Also update the freq finder helpers to use the new infrastructure.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
This was added few years back, but the code that was supposed to use it
never got merged. Remove the unused helper.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The only user of the custom helper is migrated to use
dev_pm_opp_set_config_regulators() interface. Remove the now unused
custom OPP helper support.
This cleans up _set_opp() and leaves a single code path to be used by
all users.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core now provides dev_pm_opp_set_config_regulators() interface,
which needs the platforms to just set the OPP voltages instead of both
clk and voltage. The clock is set by the OPP core instead and hence
reduces code redundancy.
Migrate the only user of the custom set_opp() to
dev_pm_opp_set_config_regulators().
Signed-off-by: Viresh Kumar <[email protected]>
We already have an API for getting voltage information for a single
regulator, dev_pm_opp_get_voltage(), but there is nothing available for
multiple regulator case.
This patch adds a new API, dev_pm_opp_get_supplies(), to get all
information related to the supplies for an OPP.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
In order to reuse the same code path, i.e. clk_set_rate() from
_set_opp(), migrate _generic_set_opp_regulator() to implement a
config_regulators() interface.
It is renamed to _opp_config_regulator_single() and is set as the
preferred config_regulators() interface whenever we have a single
regulator available.
Note that this also drops code responsible for restoring the
voltage/freq in case of errors. We aren't handling that properly
currently, restoring only some of the resources while leaving others out
(like bandwidth and required OPPs). It is better to drop all of it
instead of partial restoration.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Extend the dev_pm_opp_set_config() interface to allow adding
config_regulators() helpers. This helper will be called to set the
voltages of the regulators from the regular path in _set_opp(), while we
are trying to change the OPP.
This will eventually replace the custom set_opp() helper.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Now that we have a central API to handle all OPP table configurations,
migrate the set-prop-name family of helpers to use the new
infrastructure.
The return type and parameter to the APIs change a bit due to this,
update the current users as well in the same commit in order to avoid
breaking builds.
Acked-by: Samuel Holland <[email protected]> # sun50i
Signed-off-by: Viresh Kumar <[email protected]>
Now that we have a central API to handle all OPP table configurations,
migrate the attach-genpd family of helpers to use the new
infrastructure.
Signed-off-by: Viresh Kumar <[email protected]>
Now that we have a central API to handle all OPP table configurations,
migrate the set-opp-helper family of helpers to use the new
infrastructure.
The return type and parameter to the APIs change a bit due to this,
update the current users as well in the same commit in order to avoid
breaking builds.
Remove devm_pm_opp_register_set_opp_helper() as it has no users
currently.
Signed-off-by: Viresh Kumar <[email protected]>
Now that we have a central API to handle all OPP table configurations,
migrate the set-clk-name family of helpers to use the new
infrastructure.
Signed-off-by: Viresh Kumar <[email protected]>
Now that we have a central API to handle all OPP table configurations,
migrate the set-supported-hw family of helpers to use the new
infrastructure.
The return type and parameter to the APIs change a bit due to this,
update the current users as well in the same commit in order to avoid
breaking builds.
Signed-off-by: Viresh Kumar <[email protected]>
Now that we have a central API to handle all OPP table configurations,
migrate the set-regulators family of helpers to use the new
infrastructure.
The return type and parameter to the APIs change a bit due to this,
update the current users as well in the same commit in order to avoid
breaking builds.
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Explain why special handling was required here, it isn't obvious at all.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core now provides a unified API for setting all configuration
types, i.e. dev_pm_opp_set_config().
Lets start using it.
Signed-off-by: Viresh Kumar <[email protected]>
The OPP core already have few configuration specific APIs and it is
getting complex or messy for both the OPP core and its users.
Lets introduce a new set of API which will be used for all kind of
different configurations, and shall eventually be used by all the
existing ones.
The new API, returns a unique token instead of a pointer to the OPP
table, which allows the OPP core to drop the resources selectively later
on.
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
instead of making the callers keep the two parameters in sync, which
creates an opportunity for bugs to get in.
Suggested-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Steven Price <[email protected]> # panfrost
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
This change was introduced long back by commit 4f750c9308 ("cpufreq:
Synchronize the cpufreq store_*() routines with CPU hotplug").
Since then, both cpufreq and hotplug core have been reworked and have
much better locking in place. The race mentioned in commit 4f750c9308
isn't possible anymore.
Drop the unnecessary locking.
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Instead of specially adding a space for each CPU, except the first one,
lets add space for each of them and remove it at the end.
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Track if the clock name is configured by the platform or not. This is a
preparatory change and will be used by later commits. This also makes
the behavior of the clkname API similar to other ones, which allow
repeated calls to the same API for each CPU.
Signed-off-by: Viresh Kumar <[email protected]>
add_cpu_dev_symlink() is responsible for setting the CPUs in the
real_cpus mask, the reverse of which should be done from
remove_cpu_dev_symlink() to make it look clean and avoid any breakage
later on.
Move the call to clear the mask to remove_cpu_dev_symlink().
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
This reverts commit f346e96267.
The commit tried to fix a possible real bug but it made it even worse.
The fix was simply buggy as now an error out to out_offline_policy or
out_exit_policy will try to release a semaphore which was never taken in
the first place. This works fine only if we failed late, i.e. via
out_destroy_policy.
Fixes: f346e96267 ("cpufreq: Fix possible race in cpufreq online error path")
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
For some platforms, the frequency returned by hardware may be slightly
different from what is provided in the frequency table. For example,
hardware may return 499 MHz instead of 500 MHz. In such cases it is
better to avoid getting into unnecessary frequency updates, as we may
end up switching policy->cur between the two and sending unnecessary
pre/post update notifications, etc.
This patch has chosen allows the hardware frequency and table frequency
to deviate by 1 MHz for now, we may want to increase it a bit later on
if someone still complains.
Reported-by: Rex-BC Chen <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Tested-by: Jia-wei Chang <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
It is difficult to find which OPPs are active at the moment, specially
if there are multiple OPPs with same frequency available in the device
tree (controlled by supported hardware feature).
Expose name of the DT node to find out the exact OPP.
While at it, also expose level field.
Reported-by: Leo Yan <[email protected]>
Tested-by: Leo Yan <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep.
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
The virtio specification received a new mandatory feature
(VIRTIO_I2C_F_ZERO_LENGTH_REQUEST) for zero length requests. Fail if the
feature isn't offered by the device.
For each read-request, set the VIRTIO_I2C_FLAGS_M_RD flag, as required
by the VIRTIO_I2C_F_ZERO_LENGTH_REQUEST feature.
This allows us to support zero length requests, like SMBUS Quick, where
the buffer need not be sent anymore.
Signed-off-by: Viresh Kumar <[email protected]>
Link: https://lore.kernel.org/r/7c58868cd26d2fc4bd82d0d8b0dfb55636380110.1634808714.git.viresh.kumar@linaro.org
Signed-off-by: Michael S. Tsirkin <[email protected]>
Acked-by: Jie Deng <[email protected]> # once the spec is merged
This merges few entries for the SPEAr platform as separate entries
aren't really required.
Moreover it adds [email protected] as 'M' entry, to let them be cc'd for
patches, since they only pickup the patches for SPEAr directly due to
very low traffic for the same.
Suggested-by: Rob Herring <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
The ->ready() callback is going away and since we don't do any important
stuff in sh_cpufreq_cpu_ready(), remove it.
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The ready() callback was implemented earlier for acpi-cpufreq driver as
we wanted to use policy->cpuinfo.max_freq for which the policy was
required to be verified.
That is no longer the case and we can do the pr_warn() right from
->init() callback now. Remove acpi_cpufreq_cpu_ready().
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Fix warnings reported by sparse, related to type mismatch between u16
and __le16.
Reported-by: kernel test robot <[email protected]>
Fixes: 3a29355a22 ("gpio: Add virtio-gpio driver")
Signed-off-by: Viresh Kumar <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Set the newly added .register_em() callback to register with the EM
after the cpufreq policy is properly initialized.
Acked-by: Sudeep Holla <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Acked-by: Sudeep Holla <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Acked-by: Sudeep Holla <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
This patch adds a new driver for Virtio based GPIO devices.
This allows a guest VM running Linux to access GPIO lines provided by
the host. It supports all basic operations, except interrupts for the
GPIO lines.
Based on the initial work posted by:
"Enrico Weigelt, metux IT consult" <[email protected]>.
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Signed-off-by: Viresh Kumar <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Signed-off-by: Viresh Kumar <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Signed-off-by: Viresh Kumar <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Signed-off-by: Viresh Kumar <[email protected]>
Set the newly added .register_em() callback with
cpufreq_register_em_with_opp() to register with the EM core.
Signed-off-by: Viresh Kumar <[email protected]>
Many cpufreq drivers register with the energy model for each policy and
do exactly the same thing. Follow the footsteps of thermal-cooling, to
get it done from the cpufreq core itself.
Provide a new callback, which will be called, if present, by the cpufreq
core at the right moment (more on that in the code's comment). Also
provide a generic implementation that uses dev_pm_opp_of_register_em().
This also allows us to register with the EM at a later point of time,
compared to ->init(), from where the EM core can access cpufreq policy
directly using cpufreq_cpu_get() type of helpers and perform other work,
like marking few frequencies inefficient, this will be done separately.
Reviewed-by: Quentin Perret <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Reuse the cpufreq core's registration of cooling device by setting the
CPUFREQ_IS_COOLING_DEV flag. Set this only if bL switcher isn't enabled.
Signed-off-by: Viresh Kumar <[email protected]>
The Frequency Invariance Engine (FIE) is providing a frequency scaling
correction factor that helps achieve more accurate load-tracking.
Normally, this scaling factor can be obtained directly with the help of
the cpufreq drivers as they know the exact frequency the hardware is
running at. But that isn't the case for CPPC cpufreq driver.
Another way of obtaining that is using the arch specific counter
support, which is already present in kernel, but that hardware is
optional for platforms.
This patch updates the CPPC driver to register itself with the topology
core to provide its own implementation (cppc_scale_freq_tick()) of
topology_scale_freq_tick() which gets called by the scheduler on every
tick. Note that the arch specific counters have higher priority than
CPPC counters, if available, though the CPPC driver doesn't need to have
any special handling for that.
On an invocation of cppc_scale_freq_tick(), we schedule an irq work
(since we reach here from hard-irq context), which then schedules a
normal work item and cppc_scale_freq_workfn() updates the per_cpu
arch_freq_scale variable based on the counter updates since the last
tick.
To allow platforms to disable this CPPC counter-based frequency
invariance support, this is all done under CONFIG_ACPI_CPPC_CPUFREQ_FIE,
which is enabled by default.
This also exports sched_setattr_nocheck() as the CPPC driver can be
built as a module.
Cc: [email protected]
Tested-by: Vincent Guittot <[email protected]>
Reviewed-by: Ionela Voinescu <[email protected]>
Tested-by: Qian Cai <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Currently topology_scale_freq_tick() (which gets called from
scheduler_tick()) may end up using a pointer to "struct
scale_freq_data", which was previously cleared by
topology_clear_scale_freq_source(), as there is no protection in place
here. The users of topology_clear_scale_freq_source() though needs a
guarantee that the previously cleared scale_freq_data isn't used
anymore, so they can free the related resources.
Since topology_scale_freq_tick() is called from scheduler tick, we don't
want to add locking in there. Use the RCU update mechanism instead
(which is already used by the scheduler's utilization update path) to
guarantee race free updates here.
synchronize_rcu() makes sure that all RCU critical sections that started
before it is called, will finish before it returns. And so the callers
of topology_clear_scale_freq_source() don't need to worry about their
callback getting called anymore.
Cc: Paul E. McKenney <[email protected]>
Fixes: 01e055c120 ("arch_topology: Allow multiple entities to provide sched_freq_tick() callback")
Tested-by: Vincent Guittot <[email protected]>
Reviewed-by: Ionela Voinescu <[email protected]>
Tested-by: Qian Cai <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
It's a classic example of memleak, we allocate something, we fail and
never free the resources.
Make sure we free all resources on policy ->init() failures.
Fixes: a28b2bfc09 ("cppc_cpufreq: replace per-cpu data array with a list")
Tested-by: Vincent Guittot <[email protected]>
Reviewed-by: Ionela Voinescu <[email protected]>
Tested-by: Qian Cai <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Commit e3c0623608 ("cpufreq: add cpufreq_driver_resolve_freq()")
introduced this callback, back in 2016, for drivers that provide the
->target() callback.
The kernel hasn't seen a single user of it in the past 5 years and
it is not likely to be used any time soon.
Remove it for now.
Signed-off-by: Viresh Kumar <[email protected]>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
__cpufreq_driver_target() open codes cpufreq_driver_resolve_freq(), lets
make the former reuse the later.
Separate out __resolve_freq() to accept relation as well as an argument
and use it at both the locations.
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Now that all users of ->stop_cpu() have been migrated to using other
callbacks, drop it from the core.
Signed-off-by: Viresh Kumar <[email protected]>
[ rjw: Minor edits in the subject and changelog ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Commit 367dc4aa93 ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the ->stop_cpu() callback to allow the drivers to do
clean up before the CPU is completely down and its state can't be
modified.
At that time the CPU hotplug framework used to call the cpufreq core's
registered notifier for different events like CPU_DOWN_PREPARE and
CPU_POST_DEAD. The ->stop_cpu() callback was called during the
CPU_DOWN_PREPARE event.
This is no longer the case, cpuhp_cpufreq_offline() is called only
once by the CPU hotplug core now and we don't really need two
separate callbacks for cpufreq drivers, i.e. ->stop_cpu() and
->exit(), as everything can be done from the ->exit() callback
itself.
Migrate to using the ->exit() callback instead of ->stop_cpu().
Signed-off-by: Viresh Kumar <[email protected]>
[ rjw: Minor changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Commit 367dc4aa93 ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the ->stop_cpu() callback to allow the drivers to do
clean up before the CPU is completely down and its state can't be
modified.
At that time the CPU hotplug framework used to call the cpufreq core's
registered notifier for different events like CPU_DOWN_PREPARE and
CPU_POST_DEAD. The ->stop_cpu() callback was called during the
CPU_DOWN_PREPARE event.
This is no longer the case, cpuhp_cpufreq_offline() is called only
once by the CPU hotplug core now and we don't really need two
separate callbacks for cpufreq drivers, i.e. ->stop_cpu() and
-<exit(), as everything can be done from the ->exit() callback
itself.
Migrate to using the ->exit() callback instead of ->stop_cpu().
Signed-off-by: Viresh Kumar <[email protected]>
[ rjw: Minor edits in the changelog and subject ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
This reverts commit 4c38f2df71.
There are few races in the frequency invariance support for CPPC driver,
namely the driver doesn't stop the kthread_work and irq_work on policy
exit during suspend/resume or CPU hotplug.
A proper fix won't be possible for the 5.13-rc, as it requires a lot of
changes. Lets revert the patch instead for now.
Fixes: 4c38f2df71 ("cpufreq: CPPC: Add support for frequency invariance")
Reported-by: Qian Cai <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Rename them in accordance with the coding guidelines.
Reviewed-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Now that fdtoverlay is part of the kernel build, start using it to test
the unitest overlays we have by applying them statically. Create two new
base files static_base_1.dts and static_base_2.dts which includes other
.dtsi files.
Some unittest overlays deliberately contain errors that unittest checks
for. These overlays will cause fdtoverlay to fail, and are thus not
included for static builds.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Frank Rowand <[email protected]>
Tested-by: Frank Rowand <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/da6b4e6429aae2e7832a8be2ba2da473d449895b.1615354376.git.viresh.kumar@linaro.org
In order to build-test the same unit-test files using fdtoverlay tool,
move the device nodes from the existing overlay_base.dts and
testcases_common.dts files to .dtsi counterparts. The .dts files now
include the new .dtsi files, resulting in exactly the same behavior as
earlier.
The .dtsi files can now be reused for compile time tests using
fdtoverlay (will be done by a later commit).
This is required because the base files passed to fdtoverlay tool
shouldn't be overlays themselves (i.e. shouldn't have the /plugin/;
tag).
Note that this commit also moves "testcase-device2" node to
testcases.dts from tests-interrupts.dtsi, as this node has a deliberate
error in it and is only relevant for runtime testing done with
unittest.c.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Frank Rowand <[email protected]>
Tested-by: Frank Rowand <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/c3354a042ba34a03fd563061cbaa7fc96cb2d71a.1615354376.git.viresh.kumar@linaro.org
The Frequency Invariance Engine (FIE) is providing a frequency scaling
correction factor that helps achieve more accurate load-tracking.
Normally, this scaling factor can be obtained directly with the help of
the cpufreq drivers as they know the exact frequency the hardware is
running at. But that isn't the case for CPPC cpufreq driver.
Another way of obtaining that is using the arch specific counter
support, which is already present in kernel, but that hardware is
optional for platforms.
This patch updates the CPPC driver to register itself with the topology
core to provide its own implementation (cppc_scale_freq_tick()) of
topology_scale_freq_tick() which gets called by the scheduler on every
tick. Note that the arch specific counters have higher priority than
CPPC counters, if available, though the CPPC driver doesn't need to have
any special handling for that.
On an invocation of cppc_scale_freq_tick(), we schedule an irq work
(since we reach here from hard-irq context), which then schedules a
normal work item and cppc_scale_freq_workfn() updates the per_cpu
arch_freq_scale variable based on the counter updates since the last
tick.
To allow platforms to disable this CPPC counter-based frequency
invariance support, this is all done under CONFIG_ACPI_CPPC_CPUFREQ_FIE,
which is enabled by default.
This also exports sched_setattr_nocheck() as the CPPC driver can be
built as a module.
Cc: [email protected]
Reviewed-by: Ionela Voinescu <[email protected]>
Tested-by: Ionela Voinescu <[email protected]>
Tested-by: Vincent Guittot <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
It is possible now for other parts of the kernel to provide their own
implementation of sched_freq_tick() and they can very well be modules
themselves (like CPPC cpufreq driver, which is going to use these in a
later commit).
Export arch_freq_scale and topology_{set|clear}_scale_freq_source().
Reviewed-by: Ionela Voinescu <[email protected]>
Tested-by: Ionela Voinescu <[email protected]>
Tested-by: Vincent Guittot <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
This patch attempts to make it generic enough so other parts of the
kernel can also provide their own implementation of scale_freq_tick()
callback, which is called by the scheduler periodically to update the
per-cpu arch_freq_scale variable.
The implementations now need to provide 'struct scale_freq_data' for the
CPUs for which they have hardware counters available, and a callback
gets registered for each possible CPU in a per-cpu variable.
The arch specific (or ARM AMU) counters are updated to adapt to this and
they take the highest priority if they are available, i.e. they will be
used instead of CPPC based counters for example.
The special code to rebuild the sched domains, in case invariance status
change for the system, is moved out of arm64 specific code and is added
to arch_topology.c.
Note that this also defines SCALE_FREQ_SOURCE_CPUFREQ but doesn't use it
and it is added to show that cpufreq is also acts as source of
information for FIE and will be used by default if no other counters are
supported for a platform.
Reviewed-by: Ionela Voinescu <[email protected]>
Tested-by: Ionela Voinescu <[email protected]>
Acked-by: Will Deacon <[email protected]> # for arm64
Tested-by: Vincent Guittot <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Rename freq_scale to a less generic name, as it will get exported soon
for modules. Since x86 already names its own implementation of this as
arch_freq_scale, lets stick to that.
Suggested-by: Will Deacon <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
It is possible that 'data' passed to kfree() is set to a error value
instead of allocated space. Make sure it doesn't get called with invalid
pointer.
Fixes: 5a6338cce9 ("mailbox: arm_mhuv2: Add driver")
Cc: v5.11 <[email protected]> # v5.11
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Jassi Brar <[email protected]>
freq_qos_update_request() returns 1 if the effective constraint value
has changed, 0 if the effective constraint value has not changed, or a
negative error code on failures.
The frequency constraints for CPUs can be set by different parts of the
kernel. If the maximum frequency constraint set by other parts of the
kernel are set at a lower value than the one corresponding to cooling
state 0, then we will never be able to cool down the system as
freq_qos_update_request() will keep on returning 0 and we will skip
updating cpufreq_state and thermal pressure.
Fix that by doing the updates even in the case where
freq_qos_update_request() returns 0, as we have effectively set the
constraint to a new value even if the consolidated value of the
actual constraint is unchanged because of external factors.
Cc: v5.7+ <[email protected]> # v5.7+
Reported-by: Thara Gopinath <[email protected]>
Fixes: f12e4f66ab ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping")
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Tested-by: Lukasz Luba <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Tested-by: Thara Gopinath<[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/b2b7e84944937390256669df5a48ce5abba0c1ef.1613540713.git.viresh.kumar@linaro.org
This flag is set by one of the drivers but it isn't used in the code
otherwise. Remove the unused flag and update the driver.
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
During cpufreq driver's registration, if the ->init() callback for all
the CPUs fail then there is not much point in keeping the driver around
as it will only account for more of unnecessary noise, for example
cpufreq core will try to suspend/resume the driver which never got
registered properly.
The removal of such a driver is avoided if the driver carries the
CPUFREQ_STICKY flag. This was added way back [1] in 2004 and perhaps no
one should ever need it now. A lot of drivers do set this flag, probably
because they just copied it from other drivers.
This was added earlier for some platforms [2] because their cpufreq
drivers were getting registered before the CPUs were registered with
subsys framework. And hence they used to fail.
The same isn't true anymore though. The current code flow in the kernel
is:
start_kernel()
-> kernel_init()
-> kernel_init_freeable()
-> do_basic_setup()
-> driver_init()
-> cpu_dev_init()
-> subsys_system_register() //For CPUs
-> do_initcalls()
-> cpufreq_register_driver()
Clearly, the CPUs will always get registered with subsys framework
before any cpufreq driver can get probed. Remove the flag and update the
relevant drivers.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/include/linux/cpufreq.h?id=7cc9f0d9a1ab04cedc60d64fd8dcf7df224a3b4d # [1]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/arm/mach-sa1100/cpu-sa1100.c?id=f59d3bbe35f6268d729f51be82af8325d62f20f5 # [2]
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Checkpatch gives following warning for new patches, and the new patches
normally follow the existing standards for such stuff. Lets fix it
properly.
WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP.
Signed-off-by: Viresh Kumar <[email protected]>
Viresh Kumar