14 Dec, 2020
1 commit
-
Currently the generic power domain will power off the domain if all
devices in it have been stopped during system suspend.It is done by checking if the domain is active in genpd_sync_power_off,
then disable it. However, for power domains supporting multiple low power
states, it may have already entered an intermediate low power state by
runtime PM before system suspend and the status is already
GPD_STATE_POWER_OFF which results in then the power domain stay at an
intermediate low power state during system suspend.
Then genpd_sync_power_off will keep it at the low power state instead
of completely gate off it.Let's give the power domain a chance to switch to the deepest state in
case it's already off but in an intermediate low power state.Signed-off-by: Dong Aisheng
16 Oct, 2020
2 commits
-
To enable better debug of PM domains, keep a track of successful
and failing attempts to enter each domain idle state.This statistics are exported in debugfs when reading the
idle_states node associated with each PM domain.Signed-off-by: Lina Iyer
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki -
A device may have specific HW constraints that must be obeyed to, before
its corresponding PM domain (genpd) can be powered off - and vice verse at
power on. These constraints can't be managed through the regular runtime PM
based deployment for a device, because the access pattern for it, isn't
always request based. In other words, using the runtime PM callbacks to
deal with the constraints doesn't work for these cases.For these reasons, let's instead add a PM domain power on/off notification
mechanism to genpd. To add/remove a notifier for a device, the device must
already have been attached to the genpd, which also means that it needs to
be a part of the PM domain topology.To add/remove a notifier, let's introduce two genpd specific functions:
- dev_pm_genpd_add|remove_notifier()Note that, to further clarify when genpd power on/off notifiers may be
used, one can compare with the existing CPU_CLUSTER_PM_ENTER|EXIT
notifiers. In the long run, the genpd power on/off notifiers should be able
to replace them, but that requires additional genpd based platform support
for the current users.Signed-off-by: Ulf Hansson
Tested-by: Lina Iyer
Signed-off-by: Rafael J. Wysocki
03 Oct, 2020
1 commit
-
To clarify the code a bit, let's rename GPD_STATE_ACTIVE into
GENPD_STATE_ON and GPD_STATE_POWER_OFF to GENPD_STATE_OFF.Signed-off-by: Ulf Hansson
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki
14 Jul, 2020
1 commit
-
The rename of generic_pm_domain.slave_links to
generic_pm_domain.child_links accidentally dropped the TAB to align the
member's comment. Re-add the lost TAB to restore indentation.Fixes: 8d87ae48ced2dffd ("PM: domains: Fix up terminology with parent/child")
Signed-off-by: Geert Uytterhoeven
[ rjw: Minor subject edit ]
Signed-off-by: Rafael J. Wysocki
09 Jul, 2020
1 commit
-
The genpd infrastructure uses the terms master/slave, but such uses have
no external exposures (not even in Documentation/driver-api/pm/*) and are
not mandated by nor associated with any external specifications. Change
the language used through-out to parent/child.There was one possible exception in the debugfs node
"pm_genpd/pm_genpd_summary" but its path has no hits outside of the
kernel itself when performing a code search[1], and it seems even this
single usage has been non-functional since it was introduced due to a
typo in the Python ("apend" instead of correct "append"). Fix the typo
while we're at it.Link: https://codesearch.debian.net/ # [1]
Signed-off-by: Kees Cook
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Kieran Bingham
Signed-off-by: Rafael J. Wysocki
02 Jan, 2020
1 commit
-
We already have the of_genpd_add_subdomain() helper, but no corresponding
of_genpd_remove_subdomain(), so let's add it. Subsequent changes starts to
make use of it.Signed-off-by: Ulf Hansson
Acked-by: Rafael J. Wysocki
13 Nov, 2019
1 commit
-
For a subsystem/driver that either doesn't support runtime PM or makes use
of pm_runtime_set_active() during ->probe(), may try to access its device
when probing, even if it may not be fully powered on from the PM domain's
point of view. This may be the case when the used PM domain is a genpd
provider, that implements genpd's ->start|stop() device callbacks.There are cases where the subsystem/driver managed to avoid the above
problem, simply by calling pm_runtime_enable() and pm_runtime_get_sync()
during ->probe(). However, this approach comes with a drawback, especially
if the subsystem/driver implements a ->runtime_resume() callback.More precisely, the subsystem/driver then needs to use a device flag, which
is checked in its ->runtime_resume() callback, as to avoid powering on its
resources the first time the callback is invoked. This is needed because
the subsystem/driver has already powered on the resources for the device,
during ->probe() and before it called pm_runtime_get_sync().In a way to avoid this boilerplate code and the inefficient check for "if
(first_time_suspend)" in the ->runtime_resume() callback for these
subsystems/drivers, let's introduce and export a dev_pm_domain_start()
function, that may be called during ->probe() instead.Moreover, let the dev_pm_domain_start() invoke an optional ->start()
callback, added to the struct dev_pm_domain, as to allow a PM domain
specific implementation.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
05 Aug, 2019
1 commit
-
Align in-parameter names for the declarations of pm_genpd_add|
remove_subdomain() and of_genpd_add_subdomain() according to their
implementations, as to improve consistency.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
05 Jun, 2019
1 commit
-
Based on 1 normalized pattern(s):
this file is released under the gplv2
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 68 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Armijn Hemel
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de
Signed-off-by: Greg Kroah-Hartman
13 May, 2019
1 commit
-
This is for power domains which can only be powered off for suspend but
not as part of runtime PM.Suggested-by: Ulf Hansson
Signed-off-by: Leonard Crestez
Reviewed-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
26 Apr, 2019
1 commit
-
Attaching a device via genpd_dev_pm_attach_by_id|name() makes
genpd allocate a virtual device that it attaches instead. This
leads to a problem in case when the base device belongs to a CPU.
More precisely, it means genpd_get_cpu() compares against the
virtual device, thus it fails to find a matching CPU device.Address this limitation by passing the base device to genpd_get_cpu()
rather than the virtual device.Moreover, to deal with detach correctly from genpd_remove_device(),
store the CPU number in struct generic_pm_domain_data, so as to be
able to clear the corresponding bit in the cpumask for the genpd.Signed-off-by: Ulf Hansson
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
12 Apr, 2019
1 commit
-
After some preceding changes, PM domains managed by genpd may contain
CPU devices, so idle state residency values should be taken into
account during the state selection process. [The residency value is
the minimum amount of time to be spent by a CPU (or a group of CPUs)
in an idle state in order to save more energy than could be saved
by picking up a shallower idle state.]For this purpose, add a new genpd governor, pm_domain_cpu_gov, to be
used for selecting idle states of PM domains with CPU devices attached
either directly or through subdomains.The new governor computes the minimum expected idle duration for all
online CPUs attached to a PM domain and its subdomains. Next, it
finds the deepest idle state whose target residency is within the
expected idle duration and selects it as the target idle state of
the domain.It should be noted that the minimum expected idle duration computation
is based on the closest timer event information stored in the per-CPU
variables cpuidle_devices for all of the CPUs in the domain. That
needs to be revisited in future, as obviously there are other reasons
why a CPU may be woken up from idle.Co-developed-by: Lina Iyer
Acked-by: Daniel Lezcano
Signed-off-by: Ulf Hansson
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki
10 Apr, 2019
2 commits
-
To enable a CPU device to be attached to a PM domain managed by genpd,
make a few changes to it for convenience.To be able to quickly find out what CPUs are attached to a genpd,
which typically becomes useful from a genpd governor as subsequent
changes are about to show, add a cpumask to struct generic_pm_domain
to be updated when a CPU device gets attached to the genpd containing
that cpumask. Also, propagate the cpumask changes upwards in the
domain hierarchy to the master PM domains. This way, the cpumask for
a genpd hierarchically reflects all CPUs attached to the topology
below it.Finally, make this an opt-in feature, to avoid having to manage CPUs
and the cpumask for a genpd that don't need it. To that end, add
a new genpd configuration bit, GENPD_FLAG_CPU_DOMAIN.Co-developed-by: Lina Iyer
Acked-by: Daniel Lezcano
Signed-off-by: Ulf Hansson
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki -
Add a data pointer to the genpd_power_state struct, to allow a genpd
backend driver to store per-state specific data. To introduce the
pointer, change the way genpd deals with freeing of the corresponding
allocated data.More precisely, clarify the responsibility of whom that shall free the
data, by adding a ->free_states() callback to the generic_pm_domain
structure. The one allocating the data will be expected to set the
callback, to allow genpd to invoke it from genpd_remove().Co-developed-by: Lina Iyer
Acked-by: Daniel Lezcano
Signed-off-by: Ulf Hansson
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki
15 Feb, 2019
2 commits
-
As of the patch ("PM / Domains: Mark "name" const in
genpd_dev_pm_attach_by_name()") it's clear that the name in
dev_pm_domain_attach_by_name() can be const. Mark it as so. This
allows drivers to pass in a name that was declared "const" in a
driver.Fixes: 27dceb81f445 ("PM / Domains: Introduce dev_pm_domain_attach_by_name()")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Acked-by: Viresh Kumar
Reviewed-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
The genpd_dev_pm_attach_by_name() simply takes the name and passes it
to of_property_match_string() where the argument is "const char *".
Adding a const here allows a later patch to add a const to
dev_pm_domain_attach_by_name() which allows drivers to pass in a name
that was declared "const" in a driver.Fixes: 5d6be70add65 ("PM / Domains: Introduce option to attach a device by name to genpd")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Acked-by: Viresh Kumar
Reviewed-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
14 Dec, 2018
2 commits
-
Currently a genpd only handles the performance state requirements from
the devices under its control. This commit extends that to also handle
the performance state requirement(s) put on the master genpd by its
sub-domains. There is a separate value required for each master that
the genpd has and so a new field is added to the struct gpd_link
(link->performance_state), which represents the link between a genpd and
its master. The struct gpd_link also got another field
prev_performance_state, which is used by genpd core as a temporary
variable during transitions.On a call to dev_pm_genpd_set_performance_state(), the genpd core first
updates the performance state of the masters of the device's genpd and
then updates the performance state of the genpd. The masters do the same
and propagate performance state updates to their masters before updating
their own. The performance state transition from genpd to its master is
done with the help of dev_pm_opp_xlate_performance_state(), which looks
at the OPP tables of both the domains to translate the state.Tested-by: Rajendra Nayak
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar -
dev_pm_genpd_set_performance_state() will be required to call
dev_pm_opp_xlate_performance_state() going forward to translate from
performance state of a sub-domain to performance state of its master.
And dev_pm_opp_xlate_performance_state() needs pointers to the OPP
tables of both genpd and its master.Lets fetch and save them while the OPP tables are added. Fetching the
OPP tables should never fail as we just added the OPP tables and so add
a WARN_ON() for such a bug instead of full error paths.Tested-by: Rajendra Nayak
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
05 Nov, 2018
2 commits
-
The OPP core already has the performance state values for each of the
genpd's OPPs and there is no need to call the genpd callback again to
get the performance state for the case where the end device doesn't have
an OPP table and has the "required-opps" property directly in its node.This commit renames of_genpd_opp_to_performance_state() as
of_get_required_opp_performance_state() and moves it to the OPP core, as
it is all about OPP stuff now.Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar -
The OPP core currently stores the performance state in the consumer
device's OPP table, but that is going to change going forward and
performance state will rather be set directly in the genpd's OPP table.For that we need to get the performance state for genpd's device
structure (genpd->dev) instead of the consumer device's structure. Add a
new helper to do that.Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
18 Oct, 2018
1 commit
-
The current documented description of the GENPD_FLAG_* flags, are too
simplified, so let's extend them.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
09 Jul, 2018
2 commits
-
For the multiple PM domain case, let's introduce a new API called
dev_pm_domain_attach_by_name(). This allows a consumer driver to associate
its device with one of its PM domains, by using a name based lookup.Do note that, currently it's only genpd that supports multiple PM domains
per device, but dev_pm_domain_attach_by_name() can easily by extended to
cover other PM domain types, if/when needed.Signed-off-by: Ulf Hansson
Tested-by: Rajendra Nayak
Reviewed-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
For the multiple PM domain case, let's introduce a new function called
genpd_dev_pm_attach_by_name(). This allows a device to be associated with
its PM domain through genpd, by using a name based lookup.Note that, genpd_dev_pm_attach_by_name() shall only be called by the driver
core / PM core, similar to how the existing dev_pm_domain_attach_by_id()
makes use of genpd_dev_pm_attach_by_id(). However, this is implemented by
following changes on top.Signed-off-by: Ulf Hansson
Tested-by: Rajendra Nayak
Reviewed-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
25 Jun, 2018
2 commits
-
The DT node passed here isn't necessarily an OPP node, as this routine
can also be used for cases where the "required-opps" property is present
directly in the device's node. Rename it.This also removes a stale comment.
Acked-by: Ulf Hansson
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
of_genpd_opp_to_performance_state() should return 0 for errors, but the
dummy routine isn't doing that. Fix it.Signed-off-by: Viresh Kumar
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
06 Jun, 2018
2 commits
-
The existing dev_pm_domain_attach() function, allows a single PM domain to
be attached per device. To be able to support devices that are partitioned
across multiple PM domains, let's introduce a new interface,
dev_pm_domain_attach_by_id().The dev_pm_domain_attach_by_id() returns a new allocated struct device with
the corresponding attached PM domain. This enables for example a driver to
operate on the new device from a power management point of view. The driver
may then also benefit from using the received device, to set up so called
device-links towards its original device. Depending on the situation, these
links may then be dynamically changed.The new interface is typically called by drivers during their probe phase,
in case they manages devices which uses multiple PM domains. If that is the
case, the driver also becomes responsible of managing the detaching of the
PM domains, which typically should be done at the remove phase. Detaching
is done by calling the existing dev_pm_domain_detach() function and for
each of the received devices from dev_pm_domain_attach_by_id().Note, currently its only genpd that supports multiple PM domains per
device, but dev_pm_domain_attach_by_id() can easily by extended to cover
other PM domain types, if/when needed.Signed-off-by: Ulf Hansson
Acked-by: Jon Hunter
Tested-by: Jon Hunter
Reviewed-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
To support devices being partitioned across multiple PM domains, let's
begin with extending genpd to cope with these kind of configurations.Therefore, add a new exported function genpd_dev_pm_attach_by_id(), which
is similar to the existing genpd_dev_pm_attach(), but with the difference
that it allows its callers to provide an index to the PM domain that it
wants to attach.Note that, genpd_dev_pm_attach_by_id() shall only be called by the driver
core / PM core, similar to how the existing dev_pm_domain_attach() makes
use of genpd_dev_pm_attach(). However, this is implemented by following
changes on top.Because, only one PM domain can be attached per device, genpd needs to
create a virtual device that it can attach/detach instead. More precisely,
let the new function genpd_dev_pm_attach_by_id() register a virtual struct
device via calling device_register(). Then let it attach this device to the
corresponding PM domain, rather than the one that is provided by the
caller. The actual attaching is done via re-using the existing genpd OF
functions.At successful attachment, genpd_dev_pm_attach_by_id() returns the created
virtual device, which allows the caller to operate on it to deal with power
management. Following changes on top, provides more details in this
regards.To deal with detaching of a PM domain for the multiple PM domains case,
let's also extend the existing genpd_dev_pm_detach() function, to cover the
cleanup of the created virtual device, via make it call device_unregister()
on it. In this way, there is no need to introduce a new function to deal
with detach for the multiple PM domain case, but instead the existing one
is re-used.Signed-off-by: Ulf Hansson
Acked-by: Jon Hunter
Tested-by: Jon Hunter
Reviewed-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
30 May, 2018
3 commits
-
There is no need to pass a genpd struct to pm_genpd_remove_device(), as we
already have the information about the PM domain (genpd) through the device
structure.Additionally, we don't allow to remove a PM domain from a device, other
than the one it may have assigned to it, so really it does not make sense
to have a separate in-param for it.For these reason, drop it and update the current only call to
pm_genpd_remove_device() from amdgpu_acp.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
There are still a few non-DT existing users of genpd, however neither of
them uses __pm_genpd_add_device(), hence let's drop it.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki -
Using "extern" to declare a function in a public header file is somewhat
pointless, but also doesn't hurt. However, to make all the function
declarations in pm_domain.h to be consistent, let's drop the use of
"extern".Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
15 May, 2018
2 commits
-
Pull Operating Performance Points (OPP) library changes for v4.18
from Viresh Kumar.* 'opp/genpd-pstate-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
PM / OPP: Remove dev_pm_opp_{un}register_get_pstate_helper()
PM / OPP: Get performance state using genpd helper
PM / Domain: Implement of_genpd_opp_to_performance_state()
PM / Domain: Add support to parse domain's OPP table
PM / Domain: Add struct device to genpd
PM / OPP: Implement dev_pm_opp_get_of_node()
PM / OPP: Implement of_dev_pm_opp_find_required_opp()
PM / OPP: Implement dev_pm_opp_of_add_table_indexed()
PM / OPP: "opp-hz" is optional for power domains
PM / OPP: dt-bindings: Make "opp-hz" optional for power domains
PM / OPP: dt-bindings: Rename "required-opp" as "required-opps"
soc/tegra: pmc: Don't allocate struct tegra_powergate on stack -
The callers of dev_pm_domain_attach() currently checks the returned error
code for -EPROBE_DEFER and needs to ignore other error codes. This is an
unnecessary limitation, which also leads to a rather strange behaviour in
the error path.Address this limitation, by changing the return codes from
acpi_dev_pm_attach() and genpd_dev_pm_attach(). More precisely, let them
return 0, when no PM domain is needed for the device and then return 1, in
case the device was successfully attached to its PM domain. In this way,
dev_pm_domain_attach(), gets a better understanding of what happens in the
attach attempts and also allowing its caller to better act on real errors
codes.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
09 May, 2018
2 commits
-
This implements of_genpd_opp_to_performance_state() which can be used
from the device drivers or the OPP core to find the performance state
encoded in the "required-opps" property of a node. Normally this would
be called only once for each OPP of the device for which the OPP table
of the device is getting generated.Different platforms may encode the performance state differently using
the OPP table (they may simply return value of opp-hz or opp-microvolt,
or apply some algorithm on top of those values) and so a new callback
->opp_to_performance_state() is implemented to allow platform specific
drivers to convert the power domain OPP to a performance state value.Signed-off-by: Viresh Kumar
Acked-by: Ulf Hansson -
The power-domain core would be using the OPP core going forward and the
OPP core has the basic requirement of a device structure for its working.Add a struct device to the genpd structure. This doesn't register the
device with device core as the "dev" pointer is mostly used by the OPP
core as a cookie for now and registering the device is not mandatory.Signed-off-by: Viresh Kumar
Acked-by: Ulf Hansson
08 Nov, 2017
2 commits
-
There are no more users left of the gpd_dev_ops.active_wakeup()
callback. All have been converted to GENPD_FLAG_ACTIVE_WAKEUP.
Hence remove the callback.Signed-off-by: Geert Uytterhoeven
Acked-by: Ulf Hansson
Reviewed-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki -
It is quite common for PM Domains to require slave devices to be kept
active during system suspend if they are to be used as wakeup sources.
To enable this, currently each PM Domain or driver has to provide its
own gpd_dev_ops.active_wakeup() callback.Introduce a new flag GENPD_FLAG_ACTIVE_WAKEUP to consolidate this.
If specified, all slave devices configured as wakeup sources will be
kept active during system suspend.PM Domains that need more fine-grained controls, based on the slave
device, can still provide their own callbacks, as before.Signed-off-by: Geert Uytterhoeven
Acked-by: Ulf Hansson
Reviewed-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
14 Oct, 2017
1 commit
-
Some platforms have the capability to configure the performance state of
PM domains. This patch enhances the genpd core to support such
platforms.The performance levels (within the genpd core) are identified by
positive integer values, a lower value represents lower performance
state.This patch adds a new genpd API, which is called by user drivers (like
OPP framework):- int dev_pm_genpd_set_performance_state(struct device *dev,
unsigned int state);This updates the performance state constraint of the device on its PM
domain. On success, the genpd will have its performance state set to a
value which is >= "state" passed to this routine. The genpd core calls
the genpd->set_performance_state() callback, if implemented,
else -ENODEV is returned to the caller.The PM domain drivers need to implement the following callback if they
want to support performance states.- int (*set_performance_state)(struct generic_pm_domain *genpd,
unsigned int state);This is called internally by the genpd core on several occasions. The
genpd core passes the genpd pointer and the aggregate of the
performance states of the devices supported by that genpd to this
callback. This callback must update the performance state of the genpd
(in a platform dependent way).The power domains can avoid supplying above callback, if they don't
support setting performance-states.Currently we aren't propagating performance state changes of a subdomain
to its masters as we don't have hardware that needs it right now. Over
that, the performance states of subdomain and its masters may not have
one-to-one mapping and would require additional information. We can get
back to this once we have hardware that needs it.Tested-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
25 Jul, 2017
1 commit
-
This patch adds support to calculate the time spent by the generic
power domains in on and various idle states.Signed-off-by: Thara Gopinath
Acked-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
13 Jun, 2017
1 commit
-
Allow generic power domain providers to override the ->xlate() callback
in case the default genpd_xlate_onecell() translation callback is not
good enough.One potential use-case for this is to allow generic power domains to be
specified by an ID rather than an index.Signed-off-by: Thierry Reding
Acked-by: Ulf Hansson
Signed-off-by: Thierry Reding
