If the kernel isn't built with interconnect support, icc_get_name()
returns NULL and we get following warning:
drivers/opp/debugfs.c: In function 'bw_name_read':
drivers/opp/debugfs.c:43:42: error: '%.62s' directive argument is null [-Werror=format-overflow=]
i = scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path));
Fix it.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Fixes: 0430b1d570 ("opp: Expose bandwidth information via debugfs")
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Dhruva Gole <[email protected]>
We currently get the following warning:
debugfs.c:105:54: error: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 8 [-Werror=format-truncation=]
snprintf(name, sizeof(name), "supply-%d", i);
^~
debugfs.c:105:46: note: directive argument in the range [-2147483644, 2147483646]
snprintf(name, sizeof(name), "supply-%d", i);
^~~~~~~~~~~
debugfs.c:105:17: note: 'snprintf' output between 9 and 19 bytes into a destination of size 15
snprintf(name, sizeof(name), "supply-%d", i);
Fix this and other potential issues it by allocating larger arrays.
Use the exact string format to allocate the arrays without getting into
these issues again.
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Dhruva Gole <[email protected]>
Move the declaration of functions defined in the OPP core to pm_opp.h.
These were added to cpufreq.h as it was the only user of the APIs, but
that was a mistake perhaps. Fix it.
Signed-off-by: Viresh Kumar <[email protected]>
Offlining a CPU and bringing it back online is a common operation and it
happens frequently during system suspend/resume, where the non-boot CPUs
are hotplugged out during suspend and brought back at resume.
The cpufreq core already tries to make this path as fast as possible as
the changes are only temporary in nature and full cleanup of resources
isn't required in this case. For example the drivers can implement
online()/offline() callbacks to avoid a lot of tear down of resources.
On similar lines, there is no need to unregister the cpufreq cooling
device during suspend / resume, but only while the policy is getting
removed.
Moreover, unregistering the cpufreq cooling device is resulting in an
unwanted outcome, where the system suspend is eventually aborted in the
process. Currently, during system suspend the cpufreq core unregisters
the cooling device, which in turn removes a kobject using device_del()
and that generates a notification to the userspace via uevent broadcast.
This causes system suspend to abort in some setups.
This was also earlier reported (indirectly) by Roman [1]. Maybe there is
another way around to fixing that problem properly, but this change
makes sense anyways.
Move the registering and unregistering of the cooling device to policy
creation and removal times onlyy.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218521
Reported-by: Manaf Meethalavalappu Pallikunhi <[email protected]>
Reported-by: Roman Stratiienko <[email protected]>
Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/ [1]
Tested-by: Manaf Meethalavalappu Pallikunhi <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Dhruva Gole <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The OPP core finds the eventual frequency to set with the help of
clk_round_rate() and the same was earlier getting passed to _set_opp()
and that's what would get configured.
The commit 1efae8d2e7 ("OPP: Make dev_pm_opp_set_opp() independent of
frequency") mistakenly changed that. Fix it.
Fixes: 1efae8d2e7 ("OPP: Make dev_pm_opp_set_opp() independent of frequency")
Cc: v5.18+ <[email protected]> # v6.0+
Signed-off-by: Viresh Kumar <[email protected]>
By mistake, dev_pm_opp_find_level_floor() used the level parameter as
unsigned long instead of unsigned int. Fix it.
Signed-off-by: Viresh Kumar <[email protected]>
_find_key_ceil() may return an error and that must be checked before
passing the same to dev_pm_opp_put().
Fixes: 41907aa4ae37 ("OPP: Level zero is valid")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Like other frameworks (clk, regulator, etc.) genpd core too takes care
of propagation to performance state to parent genpds. The OPP core
shouldn't attempt the same, or it may result in undefined behavior.
Add checks at various places to take care of the same.
Reviewed-by: Ulf Hansson <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Configuring the required OPP was never properly implemented, we just
took an exception for genpds and configured them directly, while leaving
out all other required OPP types.
Now that a standard call to dev_pm_opp_set_opp() takes care of
configuring the opp->level too, the special handling for genpds can be
avoided by simply calling dev_pm_opp_set_opp() for the required OPPs,
which shall eventually configure the corresponding level for genpds.
This also makes it possible for us to configure other type of required
OPPs (no concrete users yet though), via the same path. This is how
other frameworks take care of parent nodes, like clock, regulators, etc,
where we recursively call the same helper.
In order to call dev_pm_opp_set_opp() for the virtual genpd devices,
they must share the OPP table of the genpd. Call _add_opp_dev() for them
to get that done.
This commit also extends the struct dev_pm_opp_config to pass required
devices, for non-genpd cases, which can be used to call
dev_pm_opp_set_opp() for the non-genpd required devices.
Reviewed-by: Ulf Hansson <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
There are two genpd (as required-opp) cases that we need to handle,
devices with a single genpd and ones with multiple genpds.
The multiple genpds case is clear, where the OPP core calls
dev_pm_domain_attach_by_name() for them and uses the virtual devices
returned by this helper to call dev_pm_domain_set_performance_state()
later to change the performance state.
The single genpd case however requires special handling as we need to
use the same `dev` structure (instead of a virtual one provided by genpd
core) for setting the performance state via
dev_pm_domain_set_performance_state().
As we move towards more generic code to take care of the required OPPs,
where we will recursively call dev_pm_opp_set_opp() for all the required
OPPs, the above special case becomes a problem.
It doesn't make sense for a device's DT entry to have both "opp-level"
and single "required-opps" entry pointing to a genpd's OPP, as that
would make the OPP core call dev_pm_domain_set_performance_state() for
two different values for the same device structure. And so we can reuse
the 'opp->level" field in such a case and call _set_opp_level() for the
device.
Reviewed-by: Ulf Hansson <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The level zero can be used by some OPPs to drop performance state vote
for the device. It is perfectly fine to allow the same.
_set_opp_level() considers it as an invalid value currently and returns
early.
In order to support this properly, initialize the level field with
U32_MAX, which denotes unused level field.
Reported-by: Stephan Gerhold <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
When the new interface for attaching genpd's via the OPP core was added,
it was possible for required_opp_count to be zero, but not anymore.
Remove the unused check.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
All the config operations for OPP tables share common code paths now and
none of the other ones have such protection in place. Either all should
have it or none.
The understanding here is that user won't clear the OPP configs while
still using them and so such a case won't happen. We can always come
back and use a wider lock for all resource types if required.
Also fix the error on failing to allocate memory.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Virtio guests send VIRTIO_MMIO_QUEUE_NOTIFY notification when they need
to notify the backend of an update to the status of the virtqueue. The
backend or another entity, polls the MMIO address for updates to know
when the notification is sent.
It works well if the backend does this polling by itself. But as we move
towards generic backend implementations, we end up implementing this in
a separate user-space program.
Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In order to make such backends work with Xen, another
software layer needs to do the polling and send an event via eventfd to
the backend once the notification from guest is received. This results
in an extra context switch.
This is not a new problem in Linux though. It is present with other
hypervisors like KVM, etc. as well. The generic solution implemented in
the kernel for them is to provide an IOCTL call to pass the address to
poll and eventfd, which lets the kernel take care of polling and raise
an event on the eventfd, instead of handling this in user space (which
involves an extra context switch).
This patch adds similar support for xen.
Inspired by existing implementations for KVM, etc..
This also copies ioreq.h header file (only struct ioreq and related
macros) from Xen's source tree (Top commit 5d84f07fe6bf ("xen/pci: drop
remaining uses of bool_t")).
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/b20d83efba6453037d0c099912813c79c81f7714.1697439990.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <[email protected]>
Currently the handling of events is supported either in the kernel or
userspace, but not both.
In order to support fast delivery of interrupts from the guest to the
backend, we need to handle the Queue notify part of Virtio protocol in
kernel and the rest in userspace.
Update the interrupt handler registration flag to IRQF_SHARED for event
channels, which would allow multiple entities to bind their interrupt
handler for the same event channel port.
Also increment the reference count of irq_info when multiple entities
try to bind event channel to irqchip, so the unbinding happens only
after all the users are gone.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/99b1edfd3147c6b5d22a5139dab5861e767dc34a.1697439990.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <[email protected]>
We currently get the following warning:
debugfs.c: In function ‘opp_debug_create_one’:
debugfs.c:63:42: warning: ‘%.1d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-truncation=]
snprintf(name, sizeof(name), "icc-path-%.1d", i);
^~~~
debugfs.c:63:32: note: directive argument in the range [0, 2147483647]
snprintf(name, sizeof(name), "icc-path-%.1d", i);
^~~~~~~~~~~~~~~
debugfs.c:63:3: note: ‘snprintf’ output between 11 and 20 bytes into a destination of size 11
snprintf(name, sizeof(name), "icc-path-%.1d", i);
Fix it by increasing size of the `name` array.
Signed-off-by: Viresh Kumar <[email protected]>
These were previously exposed outside of the OPP core and needed doc
style commenting. They aren't public now and don't need the same.
This fixes warnings generated for builds with `W=1`:
core.c:2105: warning: Function parameter or member 'opp_table' not described in '_opp_set_supported_hw'
core.c:2105: warning: Excess function parameter 'dev' description in '_opp_set_supported_hw'
core.c:2148: warning: Function parameter or member 'opp_table' not described in '_opp_set_prop_name'
core.c:2148: warning: Excess function parameter 'dev' description in '_opp_set_prop_name'
core.c:2189: warning: Function parameter or member 'opp_table' not described in '_opp_set_regulators'
core.c:2189: warning: Excess function parameter 'count' description in '_opp_set_regulators'
core.c:2293: warning: Function parameter or member 'opp_table' not described in '_opp_set_clknames'
core.c:2293: warning: Function parameter or member 'config_clks' not described in '_opp_set_clknames'
core.c:2391: warning: Function parameter or member 'opp_table' not described in '_opp_set_config_regulators_helper'
core.c:2455: warning: Function parameter or member 'opp_table' not described in '_opp_attach_genpd'
core.c:2682: warning: Function parameter or member 'token' not described in 'dev_pm_opp_clear_config'
core.c:2682: warning: Excess function parameter 'opp_table' description in 'dev_pm_opp_clear_config'
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Viresh Kumar <[email protected]>
Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.
Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In order to make such backends work with Xen, another
software layer needs to poll the Eventfds and raise an interrupt to the
guest using the Xen based mechanism. This results in an extra context
switch.
This is not a new problem in Linux though. It is present with other
hypervisors like KVM, etc. as well. The generic solution implemented in
the kernel for them is to provide an IOCTL call to pass the interrupt
details and eventfd, which lets the kernel take care of polling the
eventfd and raising of the interrupt, instead of handling this in user
space (which involves an extra context switch).
This patch adds support to inject a specific interrupt to guest using
the eventfd mechanism, by preventing the extra context switch.
Inspired by existing implementations for KVM, etc..
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/8e724ac1f50c2bc1eb8da9b3ff6166f1372570aa.1692697321.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <[email protected]>
Now that we support finding indexed frequencies, lets update
_read_freq() to return the right one.
Signed-off-by: Viresh Kumar <[email protected]>
Acked-by: Manivannan Sadhasivam <[email protected]>
The indexed version of the API is added for other floor and ceil, add
the same for exact as well for completeness.
Signed-off-by: Viresh Kumar <[email protected]>
Rearrange the helper function declarations / definitions to keep them in
order of freq, level and then bw.
Signed-off-by: Viresh Kumar <[email protected]>
These callbacks can be called again by the cpufreq core after the driver
is initialized and must be kept around. We currently get section
mismatch build warnings.
Don't mark them with __init.
Fixes: dcfce7c2ce ("cpufreq: sparc: Don't allocate cpufreq_driver dynamically")
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]> # build-tested
Signed-off-by: Rafael J. Wysocki <[email protected]>
While adding support for "performance states" in the OPP and genpd core,
it was decided to set the `pstate` field via genpd's
pm_genpd_opp_to_performance_state() helper, to allow platforms to set
`pstate` even if they don't have a corresponding `level` field in the DT
OPP tables (More details are present in commit 6e41766a6a ("PM /
Domain: Implement of_genpd_opp_to_performance_state()")).
Revisiting that five years later clearly suggests that it was
over-designed as all current users are eventually using the `level`
value only.
The previous commit already added necessary checks to make sure pstate
is only used for genpd tables. Lets now simplify this a little, and use
`level` directly and remove `pstate` field altogether.
Suggested-by: Ulf Hansson <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
It is not very clear right now that the `pstate` field is only valid for
genpd OPP tables and not consumer tables. And there is no checking for
the same at various places.
Add checks in place to verify that and make it clear to the reader.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Tested-by: Bjorn Andersson <[email protected]>
This code was added (long back) by commit 009acd196f ("PM / OPP:
Support updating performance state of device's power domain") and at
that time the `opp->pstate` field was used to store the performance
state required by a device's OPP.
Over time that changed and the `->pstate` field is now used only for
genpd devices and consumer devices access that via the required-opps
instead.
Because of all these changes, _opp_table_kref_release() now drops the
constraint only when the genpd's OPP table gets freed and not the
device's. Which is definitely not what we wanted. And dropping the
constraint doesn't have much meaning as the genpd itself is going away.
Moreover, if we want to drop constraints here, then just dropping the
performance constraint alone isn't sufficient as there are other
resource constraints like clk, regulator, etc. too, which must be
handled.
Probably the right thing to do here is to leave this decision to the
consumers, which can call `dev_pm_opp_set_rate(dev, 0)` or similar APIs
to drop all constraints properly. Which many of the consumers already
do.
Remove the special code, which is broken anyway.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
The `opp_table_lock` lock is already used to protect the list elsewhere,
use it while adding or removing entries from it.
Reported-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
There is no point allocating the cpufreq driver dynamically and add so
much complexity in the driver.
Do what is done for other cpufreq drivers and statically allocate the
cpufreq driver.
Reported-by: Markus Elfring <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Since the cpufreq core directly uses freq_table, for cpufreq drivers
that set their target_index() callback, make it mandatory for them to
set the same.
Since this is set per policy and normally from policy->init(), do this
from cpufreq_table_validate_and_sort() which gets called right after
->init().
Reported-by: Yajun Deng <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
The required-opps configuration is closely tied to genpd and performance
states at the moment and it is not very obvious that required-opps can
live without genpds. Though we don't support configuring required-opps
for non-genpd cases currently.
This commit aims at separating these parts, where configuring genpds
would be a special case of configuring the required-opps.
Add a specialized callback, set_required_opps(), to the opp table and
set it to different callbacks accordingly.
This shouldn't result in any functional changes for now.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
There is no real need of keeping separate code for single genpd case, it
can be made to work with a simple change.
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
thermal_release() already frees cdev, let it do rest of the cleanup as
well in order to simplify the error paths in
__thermal_cooling_device_register().
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Yang Yingliang <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
put_device() shouldn't be called before a prior call to
device_register(). __thermal_cooling_device_register() doesn't follow
that properly and needs fixing. Also
thermal_cooling_device_destroy_sysfs() is getting called unnecessarily
on few error paths.
Fix all this by placing the calls at the right place.
Based on initial work done by Caleb Connolly.
Fixes: 4748f9687c ("thermal: core: fix some possible name leaks in error paths")
Fixes: c408b3d1d9 ("thermal: Validate new state in cur_state_store()")
Reported-by: Caleb Connolly <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Tested-by: Frank Rowand <[email protected]>
Reviewed-by: Yang Yingliang <[email protected]>
Tested-by: Caleb Connolly <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
opp_parse_supplies() has grown into too big of a routine (~190 lines)
and it is not straight-forward to understand it anymore.
Break it into smaller routines and reduce code redundancy a bit by using
the same code to parse properties.
This shouldn't result in any logical changes.
Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
We missed parsing the named opp-microwatt-<name> property, fix that.
Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The named microwatt-<name> property should look exactly like microvolt
and microamp properties. There were some differences, fix them.
Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
The bindings mentions "current" instead of "power". Fix it.
Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Now that the cooling device structure stores the max_state value, reuse
it and drop max_states from struct cooling_dev_stats.
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
In cur_state_store(), the new state of the cooling device is received
from user-space and is not validated by the thermal core but the same is
left for the individual drivers to take care of. Apart from duplicating
the code it leaves possibility for introducing bugs where a driver may
not do it right.
Lets make the thermal core check the new state itself and store the max
value in the cooling device structure.
Link: https://lore.kernel.org/all/Y0ltRJRjO7AkawvE@kili/
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Fix warnings with clang like:
arch/arm/mach-spear/spear6xx.c:365:13: warning: no previous prototype for function 'spear6xx_map_io' [-Wmissing-prototypes]
by making few definitions static.
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Commit 6240aaad75 was supposed to drop the reference count to the OPP,
instead it avoided more stuff if the OPP isn't found. This isn't
entirely correct. We already have a frequency value available, we just
couldn't align it with an OPP in case of IS_ERR(opp).
Lets continue with updating thermal pressure, etc, even if we aren't
able to find an OPP here.
This fixes warning generated by the 'smatch' tool.
Fixes: 6240aaad75 ("cpufreq: qcom-hw: fix the opp entries refcounting")
Cc: v5.18+ <[email protected]> # v5.18+
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
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]>
Viresh Kumar