2011-07-01 20:12:45 +00:00
|
|
|
/*
|
|
|
|
* drivers/base/power/domain.c - Common code related to device power domains.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2011 Rafael J. Wysocki <rjw@sisk.pl>, Renesas Electronics Corp.
|
|
|
|
*
|
|
|
|
* This file is released under the GPLv2.
|
|
|
|
*/
|
|
|
|
|
2015-06-26 09:14:14 +00:00
|
|
|
#include <linux/delay.h>
|
2011-07-01 20:12:45 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/io.h>
|
2014-09-19 18:27:36 +00:00
|
|
|
#include <linux/platform_device.h>
|
2011-07-01 20:12:45 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
|
|
|
#include <linux/pm_domain.h>
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
#include <linux/pm_qos.h>
|
2014-12-01 11:50:21 +00:00
|
|
|
#include <linux/pm_clock.h>
|
2011-07-01 20:12:45 +00:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/err.h>
|
2011-07-11 22:39:29 +00:00
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/suspend.h>
|
2011-11-27 12:11:36 +00:00
|
|
|
#include <linux/export.h>
|
|
|
|
|
2015-06-26 09:14:14 +00:00
|
|
|
#define GENPD_RETRY_MAX_MS 250 /* Approximate */
|
|
|
|
|
2011-11-27 12:11:36 +00:00
|
|
|
#define GENPD_DEV_CALLBACK(genpd, type, callback, dev) \
|
|
|
|
({ \
|
|
|
|
type (*__routine)(struct device *__d); \
|
|
|
|
type __ret = (type)0; \
|
|
|
|
\
|
|
|
|
__routine = genpd->dev_ops.callback; \
|
|
|
|
if (__routine) { \
|
|
|
|
__ret = __routine(dev); \
|
|
|
|
} \
|
|
|
|
__ret; \
|
|
|
|
})
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-11-30 23:02:17 +00:00
|
|
|
#define GENPD_DEV_TIMED_CALLBACK(genpd, type, callback, dev, field, name) \
|
|
|
|
({ \
|
|
|
|
ktime_t __start = ktime_get(); \
|
|
|
|
type __retval = GENPD_DEV_CALLBACK(genpd, type, callback, dev); \
|
|
|
|
s64 __elapsed = ktime_to_ns(ktime_sub(ktime_get(), __start)); \
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
struct gpd_timing_data *__td = &dev_gpd_data(dev)->td; \
|
|
|
|
if (!__retval && __elapsed > __td->field) { \
|
|
|
|
__td->field = __elapsed; \
|
2014-02-27 18:26:44 +00:00
|
|
|
dev_dbg(dev, name " latency exceeded, new value %lld ns\n", \
|
2011-11-30 23:02:17 +00:00
|
|
|
__elapsed); \
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
genpd->max_off_time_changed = true; \
|
|
|
|
__td->constraint_changed = true; \
|
2011-11-30 23:02:17 +00:00
|
|
|
} \
|
|
|
|
__retval; \
|
|
|
|
})
|
|
|
|
|
2011-07-13 10:31:52 +00:00
|
|
|
static LIST_HEAD(gpd_list);
|
|
|
|
static DEFINE_MUTEX(gpd_list_lock);
|
|
|
|
|
2012-08-06 23:11:14 +00:00
|
|
|
static struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd = NULL, *gpd;
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(domain_name))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mutex_lock(&gpd_list_lock);
|
|
|
|
list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
|
|
|
|
if (!strcmp(gpd->name, domain_name)) {
|
|
|
|
genpd = gpd;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&gpd_list_lock);
|
|
|
|
return genpd;
|
|
|
|
}
|
|
|
|
|
2015-03-20 17:20:33 +00:00
|
|
|
/*
|
|
|
|
* Get the generic PM domain for a particular struct device.
|
|
|
|
* This validates the struct device pointer, the PM domain pointer,
|
|
|
|
* and checks that the PM domain pointer is a real generic PM domain.
|
|
|
|
* Any failure results in NULL being returned.
|
|
|
|
*/
|
|
|
|
struct generic_pm_domain *pm_genpd_lookup_dev(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd = NULL, *gpd;
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(dev) || IS_ERR_OR_NULL(dev->pm_domain))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mutex_lock(&gpd_list_lock);
|
|
|
|
list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
|
|
|
|
if (&gpd->domain == dev->pm_domain) {
|
|
|
|
genpd = gpd;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&gpd_list_lock);
|
|
|
|
|
|
|
|
return genpd;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This should only be used where we are certain that the pm_domain
|
|
|
|
* attached to the device is a genpd domain.
|
|
|
|
*/
|
|
|
|
static struct generic_pm_domain *dev_to_genpd(struct device *dev)
|
2011-07-01 20:13:10 +00:00
|
|
|
{
|
|
|
|
if (IS_ERR_OR_NULL(dev->pm_domain))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
return pd_to_genpd(dev->pm_domain);
|
2011-07-01 20:13:10 +00:00
|
|
|
}
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-11-27 12:11:36 +00:00
|
|
|
static int genpd_stop_dev(struct generic_pm_domain *genpd, struct device *dev)
|
|
|
|
{
|
2011-11-30 23:02:17 +00:00
|
|
|
return GENPD_DEV_TIMED_CALLBACK(genpd, int, stop, dev,
|
|
|
|
stop_latency_ns, "stop");
|
2011-11-27 12:11:36 +00:00
|
|
|
}
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
static int genpd_start_dev(struct generic_pm_domain *genpd, struct device *dev,
|
|
|
|
bool timed)
|
2011-11-27 12:11:36 +00:00
|
|
|
{
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
if (!timed)
|
|
|
|
return GENPD_DEV_CALLBACK(genpd, int, start, dev);
|
|
|
|
|
2011-11-30 23:02:17 +00:00
|
|
|
return GENPD_DEV_TIMED_CALLBACK(genpd, int, start, dev,
|
|
|
|
start_latency_ns, "start");
|
2011-11-27 12:11:36 +00:00
|
|
|
}
|
|
|
|
|
2011-08-08 21:43:04 +00:00
|
|
|
static bool genpd_sd_counter_dec(struct generic_pm_domain *genpd)
|
2011-07-01 20:12:45 +00:00
|
|
|
{
|
2011-08-08 21:43:04 +00:00
|
|
|
bool ret = false;
|
|
|
|
|
|
|
|
if (!WARN_ON(atomic_read(&genpd->sd_count) == 0))
|
|
|
|
ret = !!atomic_dec_and_test(&genpd->sd_count);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void genpd_sd_counter_inc(struct generic_pm_domain *genpd)
|
|
|
|
{
|
|
|
|
atomic_inc(&genpd->sd_count);
|
2014-03-17 17:06:10 +00:00
|
|
|
smp_mb__after_atomic();
|
2011-07-01 20:12:45 +00:00
|
|
|
}
|
|
|
|
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
static void genpd_recalc_cpu_exit_latency(struct generic_pm_domain *genpd)
|
|
|
|
{
|
|
|
|
s64 usecs64;
|
|
|
|
|
2014-10-02 19:12:34 +00:00
|
|
|
if (!genpd->cpuidle_data)
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
usecs64 = genpd->power_on_latency_ns;
|
|
|
|
do_div(usecs64, NSEC_PER_USEC);
|
2014-10-02 19:12:34 +00:00
|
|
|
usecs64 += genpd->cpuidle_data->saved_exit_latency;
|
|
|
|
genpd->cpuidle_data->idle_state->exit_latency = usecs64;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
}
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
static int genpd_power_on(struct generic_pm_domain *genpd, bool timed)
|
2014-11-10 18:39:19 +00:00
|
|
|
{
|
|
|
|
ktime_t time_start;
|
|
|
|
s64 elapsed_ns;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!genpd->power_on)
|
|
|
|
return 0;
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
if (!timed)
|
|
|
|
return genpd->power_on(genpd);
|
|
|
|
|
2014-11-10 18:39:19 +00:00
|
|
|
time_start = ktime_get();
|
|
|
|
ret = genpd->power_on(genpd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));
|
|
|
|
if (elapsed_ns <= genpd->power_on_latency_ns)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
genpd->power_on_latency_ns = elapsed_ns;
|
|
|
|
genpd->max_off_time_changed = true;
|
|
|
|
genpd_recalc_cpu_exit_latency(genpd);
|
2015-03-20 17:20:28 +00:00
|
|
|
pr_debug("%s: Power-%s latency exceeded, new value %lld ns\n",
|
|
|
|
genpd->name, "on", elapsed_ns);
|
2014-11-10 18:39:19 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
static int genpd_power_off(struct generic_pm_domain *genpd, bool timed)
|
2014-11-10 18:39:19 +00:00
|
|
|
{
|
|
|
|
ktime_t time_start;
|
|
|
|
s64 elapsed_ns;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!genpd->power_off)
|
|
|
|
return 0;
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
if (!timed)
|
|
|
|
return genpd->power_off(genpd);
|
|
|
|
|
2014-11-10 18:39:19 +00:00
|
|
|
time_start = ktime_get();
|
|
|
|
ret = genpd->power_off(genpd);
|
|
|
|
if (ret == -EBUSY)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));
|
|
|
|
if (elapsed_ns <= genpd->power_off_latency_ns)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
genpd->power_off_latency_ns = elapsed_ns;
|
|
|
|
genpd->max_off_time_changed = true;
|
2015-03-20 17:20:28 +00:00
|
|
|
pr_debug("%s: Power-%s latency exceeded, new value %lld ns\n",
|
|
|
|
genpd->name, "off", elapsed_ns);
|
2014-11-10 18:39:19 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-07-01 20:13:10 +00:00
|
|
|
/**
|
2011-08-08 21:43:40 +00:00
|
|
|
* __pm_genpd_poweron - Restore power to a given PM domain and its masters.
|
2011-07-01 20:13:10 +00:00
|
|
|
* @genpd: PM domain to power up.
|
|
|
|
*
|
2011-08-08 21:43:40 +00:00
|
|
|
* Restore power to @genpd and all of its masters so that it is possible to
|
2011-07-01 20:13:10 +00:00
|
|
|
* resume a device belonging to it.
|
|
|
|
*/
|
2012-07-10 19:47:07 +00:00
|
|
|
static int __pm_genpd_poweron(struct generic_pm_domain *genpd)
|
2011-07-01 20:13:10 +00:00
|
|
|
{
|
2011-08-08 21:43:40 +00:00
|
|
|
struct gpd_link *link;
|
2011-07-01 20:13:10 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
2011-07-11 22:39:29 +00:00
|
|
|
if (genpd->status == GPD_STATE_ACTIVE
|
2011-07-01 20:13:19 +00:00
|
|
|
|| (genpd->prepared_count > 0 && genpd->suspend_power_off))
|
2011-08-08 21:43:29 +00:00
|
|
|
return 0;
|
2011-07-01 20:13:10 +00:00
|
|
|
|
2014-10-02 19:12:34 +00:00
|
|
|
if (genpd->cpuidle_data) {
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
cpuidle_pause_and_lock();
|
2014-10-02 19:12:34 +00:00
|
|
|
genpd->cpuidle_data->idle_state->disabled = true;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
cpuidle_resume_and_unlock();
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
/*
|
|
|
|
* The list is guaranteed not to change while the loop below is being
|
|
|
|
* executed, unless one of the masters' .power_on() callbacks fiddles
|
|
|
|
* with it.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(link, &genpd->slave_links, slave_node) {
|
|
|
|
genpd_sd_counter_inc(link->master);
|
2011-07-01 20:13:10 +00:00
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
ret = pm_genpd_poweron(link->master);
|
|
|
|
if (ret) {
|
|
|
|
genpd_sd_counter_dec(link->master);
|
2011-08-08 21:43:22 +00:00
|
|
|
goto err;
|
2011-08-08 21:43:40 +00:00
|
|
|
}
|
2011-07-01 20:13:10 +00:00
|
|
|
}
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
ret = genpd_power_on(genpd, true);
|
2014-11-10 18:39:19 +00:00
|
|
|
if (ret)
|
|
|
|
goto err;
|
2011-07-01 20:13:10 +00:00
|
|
|
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
out:
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
genpd->status = GPD_STATE_ACTIVE;
|
2011-08-08 21:43:29 +00:00
|
|
|
return 0;
|
2011-08-08 21:43:22 +00:00
|
|
|
|
|
|
|
err:
|
2011-08-08 21:43:40 +00:00
|
|
|
list_for_each_entry_continue_reverse(link, &genpd->slave_links, slave_node)
|
|
|
|
genpd_sd_counter_dec(link->master);
|
2011-08-08 21:43:22 +00:00
|
|
|
|
2011-08-08 21:43:29 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-08-08 21:43:40 +00:00
|
|
|
* pm_genpd_poweron - Restore power to a given PM domain and its masters.
|
2011-08-08 21:43:29 +00:00
|
|
|
* @genpd: PM domain to power up.
|
|
|
|
*/
|
|
|
|
int pm_genpd_poweron(struct generic_pm_domain *genpd)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&genpd->lock);
|
|
|
|
ret = __pm_genpd_poweron(genpd);
|
|
|
|
mutex_unlock(&genpd->lock);
|
|
|
|
return ret;
|
2011-07-01 20:13:10 +00:00
|
|
|
}
|
|
|
|
|
2012-08-06 23:11:14 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_name_poweron - Restore power to a given PM domain and its masters.
|
|
|
|
* @domain_name: Name of the PM domain to power up.
|
|
|
|
*/
|
|
|
|
int pm_genpd_name_poweron(const char *domain_name)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
genpd = pm_genpd_lookup_name(domain_name);
|
|
|
|
return genpd ? pm_genpd_poweron(genpd) : -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-07-11 20:42:52 +00:00
|
|
|
static int genpd_save_dev(struct generic_pm_domain *genpd, struct device *dev)
|
|
|
|
{
|
|
|
|
return GENPD_DEV_TIMED_CALLBACK(genpd, int, save_state, dev,
|
|
|
|
save_state_latency_ns, "state save");
|
|
|
|
}
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
static int genpd_restore_dev(struct generic_pm_domain *genpd,
|
|
|
|
struct device *dev, bool timed)
|
2012-07-11 20:42:52 +00:00
|
|
|
{
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
if (!timed)
|
|
|
|
return GENPD_DEV_CALLBACK(genpd, int, restore_state, dev);
|
|
|
|
|
2012-07-11 20:42:52 +00:00
|
|
|
return GENPD_DEV_TIMED_CALLBACK(genpd, int, restore_state, dev,
|
|
|
|
restore_state_latency_ns,
|
|
|
|
"state restore");
|
|
|
|
}
|
|
|
|
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
static int genpd_dev_pm_qos_notifier(struct notifier_block *nb,
|
|
|
|
unsigned long val, void *ptr)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain_data *gpd_data;
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
gpd_data = container_of(nb, struct generic_pm_domain_data, nb);
|
|
|
|
dev = gpd_data->base.dev;
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
struct pm_domain_data *pdd;
|
|
|
|
|
|
|
|
spin_lock_irq(&dev->power.lock);
|
|
|
|
|
|
|
|
pdd = dev->power.subsys_data ?
|
|
|
|
dev->power.subsys_data->domain_data : NULL;
|
2012-07-05 20:12:32 +00:00
|
|
|
if (pdd && pdd->dev) {
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
to_gpd_data(pdd)->td.constraint_changed = true;
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
} else {
|
|
|
|
genpd = ERR_PTR(-ENODATA);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_irq(&dev->power.lock);
|
|
|
|
|
|
|
|
if (!IS_ERR(genpd)) {
|
|
|
|
mutex_lock(&genpd->lock);
|
|
|
|
genpd->max_off_time_changed = true;
|
|
|
|
mutex_unlock(&genpd->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
dev = dev->parent;
|
|
|
|
if (!dev || dev->power.ignore_children)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
|
|
|
|
2011-07-11 22:40:03 +00:00
|
|
|
/**
|
|
|
|
* genpd_queue_power_off_work - Queue up the execution of pm_genpd_poweroff().
|
|
|
|
* @genpd: PM domait to power off.
|
|
|
|
*
|
|
|
|
* Queue up the execution of pm_genpd_poweroff() unless it's already been done
|
|
|
|
* before.
|
|
|
|
*/
|
2014-09-03 10:52:25 +00:00
|
|
|
static void genpd_queue_power_off_work(struct generic_pm_domain *genpd)
|
2011-07-11 22:40:03 +00:00
|
|
|
{
|
2013-01-11 12:37:23 +00:00
|
|
|
queue_work(pm_wq, &genpd->power_off_work);
|
2011-07-11 22:40:03 +00:00
|
|
|
}
|
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_poweroff - Remove power from a given PM domain.
|
|
|
|
* @genpd: PM domain to power down.
|
|
|
|
*
|
|
|
|
* If all of the @genpd's devices have been suspended and all of its subdomains
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
* have been powered down, remove power from @genpd.
|
2011-07-01 20:12:45 +00:00
|
|
|
*/
|
|
|
|
static int pm_genpd_poweroff(struct generic_pm_domain *genpd)
|
|
|
|
{
|
2011-08-25 13:34:12 +00:00
|
|
|
struct pm_domain_data *pdd;
|
2011-08-08 21:43:40 +00:00
|
|
|
struct gpd_link *link;
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
unsigned int not_suspended = 0;
|
2011-07-01 20:12:45 +00:00
|
|
|
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
/*
|
|
|
|
* Do not try to power off the domain in the following situations:
|
|
|
|
* (1) The domain is already in the "power off" state.
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
* (2) System suspend is in progress.
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
*/
|
2011-08-08 21:43:29 +00:00
|
|
|
if (genpd->status == GPD_STATE_POWER_OFF
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
|| genpd->prepared_count > 0)
|
2011-07-01 20:12:45 +00:00
|
|
|
return 0;
|
|
|
|
|
2011-08-08 21:43:04 +00:00
|
|
|
if (atomic_read(&genpd->sd_count) > 0)
|
2011-07-01 20:12:45 +00:00
|
|
|
return -EBUSY;
|
|
|
|
|
2012-10-24 00:08:30 +00:00
|
|
|
list_for_each_entry(pdd, &genpd->dev_list, list_node) {
|
|
|
|
enum pm_qos_flags_status stat;
|
|
|
|
|
|
|
|
stat = dev_pm_qos_flags(pdd->dev,
|
|
|
|
PM_QOS_FLAG_NO_POWER_OFF
|
|
|
|
| PM_QOS_FLAG_REMOTE_WAKEUP);
|
|
|
|
if (stat > PM_QOS_FLAGS_NONE)
|
|
|
|
return -EBUSY;
|
|
|
|
|
2011-08-25 13:37:04 +00:00
|
|
|
if (pdd->dev->driver && (!pm_runtime_suspended(pdd->dev)
|
2012-08-13 12:00:25 +00:00
|
|
|
|| pdd->dev->power.irq_safe))
|
2011-07-01 20:12:45 +00:00
|
|
|
not_suspended++;
|
2012-10-24 00:08:30 +00:00
|
|
|
}
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
if (not_suspended > genpd->in_progress)
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
if (genpd->gov && genpd->gov->power_down_ok) {
|
|
|
|
if (!genpd->gov->power_down_ok(&genpd->domain))
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
|
2014-10-02 19:12:34 +00:00
|
|
|
if (genpd->cpuidle_data) {
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
/*
|
2014-10-02 19:12:34 +00:00
|
|
|
* If cpuidle_data is set, cpuidle should turn the domain off
|
|
|
|
* when the CPU in it is idle. In that case we don't decrement
|
|
|
|
* the subdomain counts of the master domains, so that power is
|
|
|
|
* not removed from the current domain prematurely as a result
|
|
|
|
* of cutting off the masters' power.
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
*/
|
|
|
|
genpd->status = GPD_STATE_POWER_OFF;
|
|
|
|
cpuidle_pause_and_lock();
|
2014-10-02 19:12:34 +00:00
|
|
|
genpd->cpuidle_data->idle_state->disabled = false;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
cpuidle_resume_and_unlock();
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
return 0;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
}
|
|
|
|
|
2011-08-08 21:43:14 +00:00
|
|
|
if (genpd->power_off) {
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (atomic_read(&genpd->sd_count) > 0)
|
|
|
|
return -EBUSY;
|
2011-07-11 22:39:29 +00:00
|
|
|
|
2011-08-08 21:43:14 +00:00
|
|
|
/*
|
2011-08-08 21:43:40 +00:00
|
|
|
* If sd_count > 0 at this point, one of the subdomains hasn't
|
|
|
|
* managed to call pm_genpd_poweron() for the master yet after
|
2011-08-08 21:43:14 +00:00
|
|
|
* incrementing it. In that case pm_genpd_poweron() will wait
|
|
|
|
* for us to drop the lock, so we can call .power_off() and let
|
|
|
|
* the pm_genpd_poweron() restore power for us (this shouldn't
|
|
|
|
* happen very often).
|
|
|
|
*/
|
2015-05-29 15:24:23 +00:00
|
|
|
ret = genpd_power_off(genpd, true);
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2011-07-14 18:59:20 +00:00
|
|
|
}
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-07-11 22:39:29 +00:00
|
|
|
genpd->status = GPD_STATE_POWER_OFF;
|
2011-11-30 23:02:10 +00:00
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
list_for_each_entry(link, &genpd->slave_links, slave_node) {
|
|
|
|
genpd_sd_counter_dec(link->master);
|
|
|
|
genpd_queue_power_off_work(link->master);
|
|
|
|
}
|
2011-07-01 20:12:45 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
return 0;
|
2011-07-01 20:12:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* genpd_power_off_work_fn - Power off PM domain whose subdomain count is 0.
|
|
|
|
* @work: Work structure used for scheduling the execution of this function.
|
|
|
|
*/
|
|
|
|
static void genpd_power_off_work_fn(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
genpd = container_of(work, struct generic_pm_domain, power_off_work);
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
pm_genpd_poweroff(genpd);
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_runtime_suspend - Suspend a device belonging to I/O PM domain.
|
|
|
|
* @dev: Device to suspend.
|
|
|
|
*
|
|
|
|
* Carry out a runtime suspend of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a PM domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_runtime_suspend(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
2011-11-30 23:02:05 +00:00
|
|
|
bool (*stop_ok)(struct device *__dev);
|
2011-11-27 12:11:36 +00:00
|
|
|
int ret;
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
2011-07-01 20:13:10 +00:00
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
2011-07-01 20:12:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2011-11-30 23:02:05 +00:00
|
|
|
stop_ok = genpd->gov ? genpd->gov->stop_ok : NULL;
|
|
|
|
if (stop_ok && !stop_ok(dev))
|
|
|
|
return -EBUSY;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
ret = genpd_save_dev(genpd, dev);
|
2011-11-27 12:11:36 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2011-07-11 22:39:29 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
ret = genpd_stop_dev(genpd, dev);
|
|
|
|
if (ret) {
|
|
|
|
genpd_restore_dev(genpd, dev, true);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-08-25 13:37:04 +00:00
|
|
|
/*
|
|
|
|
* If power.irq_safe is set, this routine will be run with interrupts
|
|
|
|
* off, so it can't use mutexes.
|
|
|
|
*/
|
|
|
|
if (dev->power.irq_safe)
|
|
|
|
return 0;
|
|
|
|
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
genpd->in_progress++;
|
|
|
|
pm_genpd_poweroff(genpd);
|
|
|
|
genpd->in_progress--;
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_runtime_resume - Resume a device belonging to I/O PM domain.
|
|
|
|
* @dev: Device to resume.
|
|
|
|
*
|
|
|
|
* Carry out a runtime resume of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a PM domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_runtime_resume(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
int ret;
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
bool timed = true;
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
2011-07-01 20:13:10 +00:00
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
2011-07-01 20:12:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2011-08-25 13:37:04 +00:00
|
|
|
/* If power.irq_safe, the PM domain is never powered off. */
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
if (dev->power.irq_safe) {
|
|
|
|
timed = false;
|
|
|
|
goto out;
|
|
|
|
}
|
2011-08-25 13:37:04 +00:00
|
|
|
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-08-08 21:43:29 +00:00
|
|
|
ret = __pm_genpd_poweron(genpd);
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
PM / Domains: Allow callbacks to execute all runtime PM helpers
A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function. This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment). This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.
The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases. Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:
* pm_genpd_poweron() doesn't wait for the PM domain status to
change from GPD_STATE_BUSY. If it finds that the status is
not GPD_STATE_POWER_OFF, it returns without powering the domain on
(it may modify the status depending on the circumstances).
* pm_genpd_poweroff() returns as soon as it finds that the PM
domain's status changed from GPD_STATE_BUSY after it's released
the PM domain's lock.
* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing the domain's
.stop_device() callback and executes pm_genpd_poweroff() only
if pm_genpd_runtime_resume() is not executed in parallel.
* pm_genpd_runtime_resume() doesn't wait for the PM domain status
to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
and sets the domain's status to GPD_STATE_BUSY and increments its
counter of resuming devices (introduced by this change) immediately
after acquiring the lock. The counter of resuming devices is then
decremented after executing __pm_genpd_runtime_resume() for the
device and the domain's status is reset to GPD_STATE_ACTIVE (unless
there are more resuming devices in the domain, in which case the
status remains GPD_STATE_BUSY).
This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it. Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed. In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:36 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
out:
|
|
|
|
genpd_start_dev(genpd, dev, timed);
|
|
|
|
genpd_restore_dev(genpd, dev, timed);
|
2011-07-11 22:39:29 +00:00
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-03-28 05:20:21 +00:00
|
|
|
static bool pd_ignore_unused;
|
|
|
|
static int __init pd_ignore_unused_setup(char *__unused)
|
|
|
|
{
|
|
|
|
pd_ignore_unused = true;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("pd_ignore_unused", pd_ignore_unused_setup);
|
|
|
|
|
2011-08-14 11:34:31 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_poweroff_unused - Power off all PM domains with no devices in use.
|
|
|
|
*/
|
|
|
|
void pm_genpd_poweroff_unused(void)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
2014-03-28 05:20:21 +00:00
|
|
|
if (pd_ignore_unused) {
|
|
|
|
pr_warn("genpd: Not disabling unused power domains\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-08-14 11:34:31 +00:00
|
|
|
mutex_lock(&gpd_list_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(genpd, &gpd_list, gpd_list_node)
|
|
|
|
genpd_queue_power_off_work(genpd);
|
|
|
|
|
|
|
|
mutex_unlock(&gpd_list_lock);
|
|
|
|
}
|
|
|
|
|
2014-09-03 10:52:26 +00:00
|
|
|
static int __init genpd_poweroff_unused(void)
|
|
|
|
{
|
|
|
|
pm_genpd_poweroff_unused();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(genpd_poweroff_unused);
|
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
2012-08-05 23:39:57 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_present - Check if the given PM domain has been initialized.
|
|
|
|
* @genpd: PM domain to check.
|
|
|
|
*/
|
2014-11-10 18:37:39 +00:00
|
|
|
static bool pm_genpd_present(const struct generic_pm_domain *genpd)
|
2012-08-05 23:39:57 +00:00
|
|
|
{
|
2014-11-10 18:37:39 +00:00
|
|
|
const struct generic_pm_domain *gpd;
|
2012-08-05 23:39:57 +00:00
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(genpd))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
list_for_each_entry(gpd, &gpd_list, gpd_list_node)
|
|
|
|
if (gpd == genpd)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-11-27 12:11:36 +00:00
|
|
|
static bool genpd_dev_active_wakeup(struct generic_pm_domain *genpd,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
|
|
|
return GENPD_DEV_CALLBACK(genpd, bool, active_wakeup, dev);
|
|
|
|
}
|
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
/**
|
2011-08-08 21:43:40 +00:00
|
|
|
* pm_genpd_sync_poweroff - Synchronously power off a PM domain and its masters.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @genpd: PM domain to power off, if possible.
|
2015-05-29 15:24:23 +00:00
|
|
|
* @timed: True if latency measurements are allowed.
|
2011-07-01 20:13:19 +00:00
|
|
|
*
|
|
|
|
* Check if the given PM domain can be powered off (during system suspend or
|
2011-08-08 21:43:40 +00:00
|
|
|
* hibernation) and do that if so. Also, in that case propagate to its masters.
|
2011-07-01 20:13:19 +00:00
|
|
|
*
|
2012-08-05 23:39:57 +00:00
|
|
|
* This function is only called in "noirq" and "syscore" stages of system power
|
|
|
|
* transitions, so it need not acquire locks (all of the "noirq" callbacks are
|
|
|
|
* executed sequentially, so it is guaranteed that it will never run twice in
|
|
|
|
* parallel).
|
2011-07-01 20:13:19 +00:00
|
|
|
*/
|
2015-05-29 15:24:23 +00:00
|
|
|
static void pm_genpd_sync_poweroff(struct generic_pm_domain *genpd,
|
|
|
|
bool timed)
|
2011-07-01 20:13:19 +00:00
|
|
|
{
|
2011-08-08 21:43:40 +00:00
|
|
|
struct gpd_link *link;
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2011-07-11 22:39:29 +00:00
|
|
|
if (genpd->status == GPD_STATE_POWER_OFF)
|
2011-07-01 20:13:19 +00:00
|
|
|
return;
|
|
|
|
|
2011-08-08 21:43:04 +00:00
|
|
|
if (genpd->suspended_count != genpd->device_count
|
|
|
|
|| atomic_read(&genpd->sd_count) > 0)
|
2011-07-01 20:13:19 +00:00
|
|
|
return;
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
genpd_power_off(genpd, timed);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2011-07-11 22:39:29 +00:00
|
|
|
genpd->status = GPD_STATE_POWER_OFF;
|
2011-08-08 21:43:40 +00:00
|
|
|
|
|
|
|
list_for_each_entry(link, &genpd->slave_links, slave_node) {
|
|
|
|
genpd_sd_counter_dec(link->master);
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweroff(link->master, timed);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-05 23:39:16 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_sync_poweron - Synchronously power on a PM domain and its masters.
|
|
|
|
* @genpd: PM domain to power on.
|
2015-05-29 15:24:23 +00:00
|
|
|
* @timed: True if latency measurements are allowed.
|
2012-08-05 23:39:16 +00:00
|
|
|
*
|
2012-08-05 23:39:57 +00:00
|
|
|
* This function is only called in "noirq" and "syscore" stages of system power
|
|
|
|
* transitions, so it need not acquire locks (all of the "noirq" callbacks are
|
|
|
|
* executed sequentially, so it is guaranteed that it will never run twice in
|
|
|
|
* parallel).
|
2012-08-05 23:39:16 +00:00
|
|
|
*/
|
2015-05-29 15:24:23 +00:00
|
|
|
static void pm_genpd_sync_poweron(struct generic_pm_domain *genpd,
|
|
|
|
bool timed)
|
2012-08-05 23:39:16 +00:00
|
|
|
{
|
|
|
|
struct gpd_link *link;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
if (genpd->status == GPD_STATE_ACTIVE)
|
2012-08-05 23:39:16 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
list_for_each_entry(link, &genpd->slave_links, slave_node) {
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweron(link->master, timed);
|
2012-08-05 23:39:16 +00:00
|
|
|
genpd_sd_counter_inc(link->master);
|
|
|
|
}
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
genpd_power_on(genpd, timed);
|
2012-08-05 23:39:16 +00:00
|
|
|
|
|
|
|
genpd->status = GPD_STATE_ACTIVE;
|
|
|
|
}
|
|
|
|
|
PM / Domains: Improve handling of wakeup devices during system suspend
Kevin points out that if there's a device that can wake up the system
from sleep states, but it doesn't generate wakeup signals by itself
(they are generated on its behalf by other parts of the system) and
it currently is not enabled to wake up the system (that is,
device_may_wakeup() returns "false" for it), we may need to change
its wakeup settings during system suspend (for example, the device
might have been configured to signal remote wakeup from the system's
working state, as needed by runtime PM). Therefore the generic PM
domains code should invoke the system suspend callbacks provided by
the device's driver, which it doesn't do if the PM domain is powered
off during the system suspend's "prepare" stage. This is a valid
point. Moreover, this code also should make sure that system wakeup
devices that are enabled to wake up the system from sleep states and
have to remain active for this purpose are not suspended while the
system is in a sleep state.
To avoid the above issues, make the generic PM domains' .prepare()
routine, pm_genpd_prepare(), force runtime resume of devices whose
system wakeup settings may need to be changed during system suspend
or that should remain active while the system is in a sleep state to
be able to wake it up from that state.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:57 +00:00
|
|
|
/**
|
|
|
|
* resume_needed - Check whether to resume a device before system suspend.
|
|
|
|
* @dev: Device to check.
|
|
|
|
* @genpd: PM domain the device belongs to.
|
|
|
|
*
|
|
|
|
* There are two cases in which a device that can wake up the system from sleep
|
|
|
|
* states should be resumed by pm_genpd_prepare(): (1) if the device is enabled
|
|
|
|
* to wake up the system and it has to remain active for this purpose while the
|
|
|
|
* system is in the sleep state and (2) if the device is not enabled to wake up
|
|
|
|
* the system from sleep states and it generally doesn't generate wakeup signals
|
|
|
|
* by itself (those signals are generated on its behalf by other parts of the
|
|
|
|
* system). In the latter case it may be necessary to reconfigure the device's
|
|
|
|
* wakeup settings during system suspend, because it may have been set up to
|
|
|
|
* signal remote wakeup from the system's working state as needed by runtime PM.
|
|
|
|
* Return 'true' in either of the above cases.
|
|
|
|
*/
|
|
|
|
static bool resume_needed(struct device *dev, struct generic_pm_domain *genpd)
|
|
|
|
{
|
|
|
|
bool active_wakeup;
|
|
|
|
|
|
|
|
if (!device_can_wakeup(dev))
|
|
|
|
return false;
|
|
|
|
|
2011-11-27 12:11:36 +00:00
|
|
|
active_wakeup = genpd_dev_active_wakeup(genpd, dev);
|
PM / Domains: Improve handling of wakeup devices during system suspend
Kevin points out that if there's a device that can wake up the system
from sleep states, but it doesn't generate wakeup signals by itself
(they are generated on its behalf by other parts of the system) and
it currently is not enabled to wake up the system (that is,
device_may_wakeup() returns "false" for it), we may need to change
its wakeup settings during system suspend (for example, the device
might have been configured to signal remote wakeup from the system's
working state, as needed by runtime PM). Therefore the generic PM
domains code should invoke the system suspend callbacks provided by
the device's driver, which it doesn't do if the PM domain is powered
off during the system suspend's "prepare" stage. This is a valid
point. Moreover, this code also should make sure that system wakeup
devices that are enabled to wake up the system from sleep states and
have to remain active for this purpose are not suspended while the
system is in a sleep state.
To avoid the above issues, make the generic PM domains' .prepare()
routine, pm_genpd_prepare(), force runtime resume of devices whose
system wakeup settings may need to be changed during system suspend
or that should remain active while the system is in a sleep state to
be able to wake it up from that state.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:57 +00:00
|
|
|
return device_may_wakeup(dev) ? active_wakeup : !active_wakeup;
|
|
|
|
}
|
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_prepare - Start power transition of a device in a PM domain.
|
|
|
|
* @dev: Device to start the transition of.
|
|
|
|
*
|
|
|
|
* Start a power transition of a device (during a system-wide power transition)
|
|
|
|
* under the assumption that its pm_domain field points to the domain member of
|
|
|
|
* an object of type struct generic_pm_domain representing a PM domain
|
|
|
|
* consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_prepare(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
2011-07-11 22:39:21 +00:00
|
|
|
int ret;
|
2011-07-01 20:13:19 +00:00
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2011-07-11 22:39:29 +00:00
|
|
|
/*
|
|
|
|
* If a wakeup request is pending for the device, it should be woken up
|
|
|
|
* at this point and a system wakeup event should be reported if it's
|
|
|
|
* set up to wake up the system from sleep states.
|
|
|
|
*/
|
|
|
|
pm_runtime_get_noresume(dev);
|
|
|
|
if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
|
|
|
|
pm_wakeup_event(dev, 0);
|
|
|
|
|
|
|
|
if (pm_wakeup_pending()) {
|
2013-04-12 09:41:44 +00:00
|
|
|
pm_runtime_put(dev);
|
2011-07-11 22:39:29 +00:00
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
PM / Domains: Improve handling of wakeup devices during system suspend
Kevin points out that if there's a device that can wake up the system
from sleep states, but it doesn't generate wakeup signals by itself
(they are generated on its behalf by other parts of the system) and
it currently is not enabled to wake up the system (that is,
device_may_wakeup() returns "false" for it), we may need to change
its wakeup settings during system suspend (for example, the device
might have been configured to signal remote wakeup from the system's
working state, as needed by runtime PM). Therefore the generic PM
domains code should invoke the system suspend callbacks provided by
the device's driver, which it doesn't do if the PM domain is powered
off during the system suspend's "prepare" stage. This is a valid
point. Moreover, this code also should make sure that system wakeup
devices that are enabled to wake up the system from sleep states and
have to remain active for this purpose are not suspended while the
system is in a sleep state.
To avoid the above issues, make the generic PM domains' .prepare()
routine, pm_genpd_prepare(), force runtime resume of devices whose
system wakeup settings may need to be changed during system suspend
or that should remain active while the system is in a sleep state to
be able to wake it up from that state.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-07-11 22:39:57 +00:00
|
|
|
if (resume_needed(dev, genpd))
|
|
|
|
pm_runtime_resume(dev);
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2012-03-13 21:39:37 +00:00
|
|
|
if (genpd->prepared_count++ == 0) {
|
|
|
|
genpd->suspended_count = 0;
|
2011-07-11 22:39:29 +00:00
|
|
|
genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
|
2012-03-13 21:39:37 +00:00
|
|
|
}
|
2011-07-11 22:39:29 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
|
|
|
if (genpd->suspend_power_off) {
|
2011-07-11 22:39:29 +00:00
|
|
|
pm_runtime_put_noidle(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-07-11 22:39:29 +00:00
|
|
|
* The PM domain must be in the GPD_STATE_ACTIVE state at this point,
|
|
|
|
* so pm_genpd_poweron() will return immediately, but if the device
|
2011-11-27 12:11:36 +00:00
|
|
|
* is suspended (e.g. it's been stopped by genpd_stop_dev()), we need
|
2011-07-11 22:39:29 +00:00
|
|
|
* to make it operational.
|
2011-07-01 20:13:19 +00:00
|
|
|
*/
|
2011-07-11 22:39:29 +00:00
|
|
|
pm_runtime_resume(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
__pm_runtime_disable(dev, false);
|
|
|
|
|
2011-07-11 22:39:21 +00:00
|
|
|
ret = pm_generic_prepare(dev);
|
|
|
|
if (ret) {
|
|
|
|
mutex_lock(&genpd->lock);
|
|
|
|
|
|
|
|
if (--genpd->prepared_count == 0)
|
|
|
|
genpd->suspend_power_off = false;
|
|
|
|
|
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-11 22:39:29 +00:00
|
|
|
pm_runtime_enable(dev);
|
2011-07-11 22:39:21 +00:00
|
|
|
}
|
2011-07-11 22:39:29 +00:00
|
|
|
|
2013-04-12 09:41:44 +00:00
|
|
|
pm_runtime_put(dev);
|
2011-07-11 22:39:21 +00:00
|
|
|
return ret;
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_suspend - Suspend a device belonging to an I/O PM domain.
|
|
|
|
* @dev: Device to suspend.
|
|
|
|
*
|
|
|
|
* Suspend a device under the assumption that its pm_domain field points to the
|
|
|
|
* domain member of an object of type struct generic_pm_domain representing
|
|
|
|
* a PM domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_suspend(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_suspend(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_suspend_late - Late suspend of a device from an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to suspend.
|
|
|
|
*
|
|
|
|
* Carry out a late suspend of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a PM domain consisting of I/O devices.
|
|
|
|
*/
|
2012-01-29 19:39:02 +00:00
|
|
|
static int pm_genpd_suspend_late(struct device *dev)
|
2011-07-01 20:13:19 +00:00
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_suspend_late(dev);
|
2012-01-29 19:39:02 +00:00
|
|
|
}
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2012-01-29 19:39:02 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_suspend_noirq - Completion of suspend of device in an I/O PM domain.
|
|
|
|
* @dev: Device to suspend.
|
|
|
|
*
|
|
|
|
* Stop the device and remove power from the domain if all devices in it have
|
|
|
|
* been stopped.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_suspend_noirq(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2012-08-05 23:46:39 +00:00
|
|
|
if (genpd->suspend_power_off
|
2012-01-29 19:39:02 +00:00
|
|
|
|| (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev)))
|
PM / Domains: Wakeup devices support for system sleep transitions
There is the problem how to handle devices set up to wake up the
system from sleep states during system-wide power transitions.
In some cases, those devices can be turned off entirely, because the
wakeup signals will be generated on their behalf anyway. In some
other cases, they will generate wakeup signals if their clocks are
stopped, but only if power is not removed from them. Finally, in
some cases, they can only generate wakeup signals if power is not
removed from them and their clocks are enabled.
To allow platform-specific code to decide whether or not to put
wakeup devices (and their PM domains) into low-power state during
system-wide transitions, such as system suspend, introduce a new
generic PM domain callback, .active_wakeup(), that will be used
during the "noirq" phase of system suspend and hibernation (after
image creation) to decide what to do with wakeup devices.
Specifically, if this callback is present and returns "true", the
generic PM domain code will not execute .stop_device() for the
given wakeup device and its PM domain won't be powered off.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-01 20:13:29 +00:00
|
|
|
return 0;
|
|
|
|
|
2011-11-27 12:11:36 +00:00
|
|
|
genpd_stop_dev(genpd, dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since all of the "noirq" callbacks are executed sequentially, it is
|
|
|
|
* guaranteed that this function will never run twice in parallel for
|
|
|
|
* the same PM domain, so it is not necessary to use locking here.
|
|
|
|
*/
|
|
|
|
genpd->suspended_count++;
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweroff(genpd, true);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_resume_noirq - Start of resume of device in an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to resume.
|
|
|
|
*
|
2012-01-29 19:39:02 +00:00
|
|
|
* Restore power to the device's PM domain, if necessary, and start the device.
|
2011-07-01 20:13:19 +00:00
|
|
|
*/
|
|
|
|
static int pm_genpd_resume_noirq(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-08-05 23:46:39 +00:00
|
|
|
if (genpd->suspend_power_off
|
2012-03-13 21:39:31 +00:00
|
|
|
|| (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev)))
|
2011-07-01 20:13:19 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since all of the "noirq" callbacks are executed sequentially, it is
|
|
|
|
* guaranteed that this function will never run twice in parallel for
|
|
|
|
* the same PM domain, so it is not necessary to use locking here.
|
|
|
|
*/
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweron(genpd, true);
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->suspended_count--;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
return genpd_start_dev(genpd, dev, true);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_resume_early - Early resume of a device in an I/O PM domain.
|
|
|
|
* @dev: Device to resume.
|
|
|
|
*
|
|
|
|
* Carry out an early resume of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a power domain consisting of I/O
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_resume_early(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_resume_early(dev);
|
2012-01-29 19:39:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_resume - Resume of device in an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to resume.
|
|
|
|
*
|
|
|
|
* Resume a device under the assumption that its pm_domain field points to the
|
|
|
|
* domain member of an object of type struct generic_pm_domain representing
|
|
|
|
* a power domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_resume(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_resume(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_freeze - Freezing a device in an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to freeze.
|
|
|
|
*
|
|
|
|
* Freeze a device under the assumption that its pm_domain field points to the
|
|
|
|
* domain member of an object of type struct generic_pm_domain representing
|
|
|
|
* a power domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_freeze(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_freeze(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_freeze_late - Late freeze of a device in an I/O PM domain.
|
|
|
|
* @dev: Device to freeze.
|
|
|
|
*
|
|
|
|
* Carry out a late freeze of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a power domain consisting of I/O
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_freeze_late(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_freeze_late(dev);
|
2012-01-29 19:39:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_freeze_noirq - Completion of freezing a device in an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to freeze.
|
|
|
|
*
|
|
|
|
* Carry out a late freeze of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a power domain consisting of I/O
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_freeze_noirq(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-08-05 23:46:39 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : genpd_stop_dev(genpd, dev);
|
2012-01-29 19:39:02 +00:00
|
|
|
}
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2012-01-29 19:39:02 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_thaw_noirq - Early thaw of device in an I/O PM domain.
|
|
|
|
* @dev: Device to thaw.
|
|
|
|
*
|
|
|
|
* Start the device, unless power has been removed from the domain already
|
|
|
|
* before the system transition.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_thaw_noirq(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2012-01-29 19:39:02 +00:00
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : genpd_start_dev(genpd, dev, true);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_thaw_early - Early thaw of device in an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to thaw.
|
|
|
|
*
|
|
|
|
* Carry out an early thaw of a device under the assumption that its
|
|
|
|
* pm_domain field points to the domain member of an object of type
|
|
|
|
* struct generic_pm_domain representing a power domain consisting of I/O
|
|
|
|
* devices.
|
|
|
|
*/
|
2012-01-29 19:39:02 +00:00
|
|
|
static int pm_genpd_thaw_early(struct device *dev)
|
2011-07-01 20:13:19 +00:00
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_thaw_early(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_thaw - Thaw a device belonging to an I/O power domain.
|
|
|
|
* @dev: Device to thaw.
|
|
|
|
*
|
|
|
|
* Thaw a device under the assumption that its pm_domain field points to the
|
|
|
|
* domain member of an object of type struct generic_pm_domain representing
|
|
|
|
* a power domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_thaw(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-03 10:52:19 +00:00
|
|
|
return genpd->suspend_power_off ? 0 : pm_generic_thaw(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2012-01-29 19:39:02 +00:00
|
|
|
* pm_genpd_restore_noirq - Start of restore of device in an I/O PM domain.
|
2011-07-01 20:13:19 +00:00
|
|
|
* @dev: Device to resume.
|
|
|
|
*
|
2012-01-29 19:39:02 +00:00
|
|
|
* Make sure the domain will be in the same power state as before the
|
|
|
|
* hibernation the system is resuming from and start the device if necessary.
|
2011-07-01 20:13:19 +00:00
|
|
|
*/
|
|
|
|
static int pm_genpd_restore_noirq(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since all of the "noirq" callbacks are executed sequentially, it is
|
|
|
|
* guaranteed that this function will never run twice in parallel for
|
|
|
|
* the same PM domain, so it is not necessary to use locking here.
|
2012-03-13 21:39:37 +00:00
|
|
|
*
|
|
|
|
* At this point suspended_count == 0 means we are being run for the
|
|
|
|
* first time for the given domain in the present cycle.
|
2011-07-01 20:13:19 +00:00
|
|
|
*/
|
2012-03-13 21:39:37 +00:00
|
|
|
if (genpd->suspended_count++ == 0) {
|
2011-07-01 20:13:19 +00:00
|
|
|
/*
|
2012-03-13 21:39:37 +00:00
|
|
|
* The boot kernel might put the domain into arbitrary state,
|
2012-08-05 23:39:16 +00:00
|
|
|
* so make it appear as powered off to pm_genpd_sync_poweron(),
|
|
|
|
* so that it tries to power it on in case it was really off.
|
2011-07-01 20:13:19 +00:00
|
|
|
*/
|
2012-03-13 21:39:37 +00:00
|
|
|
genpd->status = GPD_STATE_POWER_OFF;
|
|
|
|
if (genpd->suspend_power_off) {
|
|
|
|
/*
|
|
|
|
* If the domain was off before the hibernation, make
|
|
|
|
* sure it will be off going forward.
|
|
|
|
*/
|
2015-05-29 15:24:23 +00:00
|
|
|
genpd_power_off(genpd, true);
|
2012-03-13 21:39:37 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
2012-03-19 09:38:14 +00:00
|
|
|
if (genpd->suspend_power_off)
|
|
|
|
return 0;
|
|
|
|
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweron(genpd, true);
|
2011-07-01 20:13:19 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
return genpd_start_dev(genpd, dev, true);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_complete - Complete power transition of a device in a power domain.
|
|
|
|
* @dev: Device to complete the transition of.
|
|
|
|
*
|
|
|
|
* Complete a power transition of a device (during a system-wide power
|
|
|
|
* transition) under the assumption that its pm_domain field points to the
|
|
|
|
* domain member of an object of type struct generic_pm_domain representing
|
|
|
|
* a power domain consisting of I/O devices.
|
|
|
|
*/
|
|
|
|
static void pm_genpd_complete(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
bool run_complete;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(genpd))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&genpd->lock);
|
|
|
|
|
|
|
|
run_complete = !genpd->suspend_power_off;
|
|
|
|
if (--genpd->prepared_count == 0)
|
|
|
|
genpd->suspend_power_off = false;
|
|
|
|
|
|
|
|
mutex_unlock(&genpd->lock);
|
|
|
|
|
|
|
|
if (run_complete) {
|
|
|
|
pm_generic_complete(dev);
|
2011-07-11 22:39:10 +00:00
|
|
|
pm_runtime_set_active(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
pm_runtime_enable(dev);
|
2013-04-12 09:41:06 +00:00
|
|
|
pm_request_idle(dev);
|
2011-07-01 20:13:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-05 23:39:57 +00:00
|
|
|
/**
|
2014-09-03 10:52:24 +00:00
|
|
|
* genpd_syscore_switch - Switch power during system core suspend or resume.
|
2012-08-05 23:39:57 +00:00
|
|
|
* @dev: Device that normally is marked as "always on" to switch power for.
|
|
|
|
*
|
|
|
|
* This routine may only be called during the system core (syscore) suspend or
|
|
|
|
* resume phase for devices whose "always on" flags are set.
|
|
|
|
*/
|
2014-09-03 10:52:24 +00:00
|
|
|
static void genpd_syscore_switch(struct device *dev, bool suspend)
|
2012-08-05 23:39:57 +00:00
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd;
|
|
|
|
|
|
|
|
genpd = dev_to_genpd(dev);
|
|
|
|
if (!pm_genpd_present(genpd))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (suspend) {
|
|
|
|
genpd->suspended_count++;
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweroff(genpd, false);
|
2012-08-05 23:39:57 +00:00
|
|
|
} else {
|
2015-05-29 15:24:23 +00:00
|
|
|
pm_genpd_sync_poweron(genpd, false);
|
2012-08-05 23:39:57 +00:00
|
|
|
genpd->suspended_count--;
|
|
|
|
}
|
|
|
|
}
|
2014-09-03 10:52:24 +00:00
|
|
|
|
|
|
|
void pm_genpd_syscore_poweroff(struct device *dev)
|
|
|
|
{
|
|
|
|
genpd_syscore_switch(dev, true);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pm_genpd_syscore_poweroff);
|
|
|
|
|
|
|
|
void pm_genpd_syscore_poweron(struct device *dev)
|
|
|
|
{
|
|
|
|
genpd_syscore_switch(dev, false);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pm_genpd_syscore_poweron);
|
2012-08-05 23:39:57 +00:00
|
|
|
|
2014-11-27 21:38:05 +00:00
|
|
|
#else /* !CONFIG_PM_SLEEP */
|
2011-07-01 20:13:19 +00:00
|
|
|
|
|
|
|
#define pm_genpd_prepare NULL
|
|
|
|
#define pm_genpd_suspend NULL
|
2012-01-29 19:39:02 +00:00
|
|
|
#define pm_genpd_suspend_late NULL
|
2011-07-01 20:13:19 +00:00
|
|
|
#define pm_genpd_suspend_noirq NULL
|
2012-01-29 19:39:02 +00:00
|
|
|
#define pm_genpd_resume_early NULL
|
2011-07-01 20:13:19 +00:00
|
|
|
#define pm_genpd_resume_noirq NULL
|
|
|
|
#define pm_genpd_resume NULL
|
|
|
|
#define pm_genpd_freeze NULL
|
2012-01-29 19:39:02 +00:00
|
|
|
#define pm_genpd_freeze_late NULL
|
2011-07-01 20:13:19 +00:00
|
|
|
#define pm_genpd_freeze_noirq NULL
|
2012-01-29 19:39:02 +00:00
|
|
|
#define pm_genpd_thaw_early NULL
|
2011-07-01 20:13:19 +00:00
|
|
|
#define pm_genpd_thaw_noirq NULL
|
|
|
|
#define pm_genpd_thaw NULL
|
|
|
|
#define pm_genpd_restore_noirq NULL
|
|
|
|
#define pm_genpd_complete NULL
|
|
|
|
|
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
|
|
|
|
2015-01-27 20:13:44 +00:00
|
|
|
static struct generic_pm_domain_data *genpd_alloc_dev_data(struct device *dev,
|
|
|
|
struct generic_pm_domain *genpd,
|
|
|
|
struct gpd_timing_data *td)
|
2012-07-05 20:12:32 +00:00
|
|
|
{
|
|
|
|
struct generic_pm_domain_data *gpd_data;
|
2015-01-27 20:13:43 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = dev_pm_get_subsys_data(dev);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
2012-07-05 20:12:32 +00:00
|
|
|
|
|
|
|
gpd_data = kzalloc(sizeof(*gpd_data), GFP_KERNEL);
|
2015-01-27 20:13:43 +00:00
|
|
|
if (!gpd_data) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_put;
|
|
|
|
}
|
2012-07-05 20:12:32 +00:00
|
|
|
|
2015-01-27 20:13:44 +00:00
|
|
|
if (td)
|
|
|
|
gpd_data->td = *td;
|
|
|
|
|
|
|
|
gpd_data->base.dev = dev;
|
|
|
|
gpd_data->td.constraint_changed = true;
|
|
|
|
gpd_data->td.effective_constraint_ns = -1;
|
|
|
|
gpd_data->nb.notifier_call = genpd_dev_pm_qos_notifier;
|
|
|
|
|
|
|
|
spin_lock_irq(&dev->power.lock);
|
|
|
|
|
|
|
|
if (dev->power.subsys_data->domain_data) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev->power.subsys_data->domain_data = &gpd_data->base;
|
|
|
|
dev->pm_domain = &genpd->domain;
|
|
|
|
|
|
|
|
spin_unlock_irq(&dev->power.lock);
|
|
|
|
|
2012-07-05 20:12:32 +00:00
|
|
|
return gpd_data;
|
2015-01-27 20:13:43 +00:00
|
|
|
|
2015-01-27 20:13:44 +00:00
|
|
|
err_free:
|
|
|
|
spin_unlock_irq(&dev->power.lock);
|
|
|
|
kfree(gpd_data);
|
2015-01-27 20:13:43 +00:00
|
|
|
err_put:
|
|
|
|
dev_pm_put_subsys_data(dev);
|
|
|
|
return ERR_PTR(ret);
|
2012-07-05 20:12:32 +00:00
|
|
|
}
|
|
|
|
|
2015-01-27 20:13:38 +00:00
|
|
|
static void genpd_free_dev_data(struct device *dev,
|
|
|
|
struct generic_pm_domain_data *gpd_data)
|
2012-07-05 20:12:32 +00:00
|
|
|
{
|
2015-01-27 20:13:44 +00:00
|
|
|
spin_lock_irq(&dev->power.lock);
|
|
|
|
|
|
|
|
dev->pm_domain = NULL;
|
|
|
|
dev->power.subsys_data->domain_data = NULL;
|
|
|
|
|
|
|
|
spin_unlock_irq(&dev->power.lock);
|
|
|
|
|
2012-07-05 20:12:32 +00:00
|
|
|
kfree(gpd_data);
|
2015-01-27 20:13:43 +00:00
|
|
|
dev_pm_put_subsys_data(dev);
|
2012-07-05 20:12:32 +00:00
|
|
|
}
|
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
/**
|
2011-11-30 23:02:05 +00:00
|
|
|
* __pm_genpd_add_device - Add a device to an I/O PM domain.
|
2011-07-01 20:12:45 +00:00
|
|
|
* @genpd: PM domain to add the device to.
|
|
|
|
* @dev: Device to be added.
|
2011-11-30 23:02:05 +00:00
|
|
|
* @td: Set of PM QoS timing parameters to attach to the device.
|
2011-07-01 20:12:45 +00:00
|
|
|
*/
|
2011-11-30 23:02:05 +00:00
|
|
|
int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
|
|
|
|
struct gpd_timing_data *td)
|
2011-07-01 20:12:45 +00:00
|
|
|
{
|
2015-01-27 20:13:42 +00:00
|
|
|
struct generic_pm_domain_data *gpd_data;
|
2011-07-01 20:12:45 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(dev))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-01-27 20:13:44 +00:00
|
|
|
gpd_data = genpd_alloc_dev_data(dev, genpd, td);
|
2015-01-27 20:13:43 +00:00
|
|
|
if (IS_ERR(gpd_data))
|
|
|
|
return PTR_ERR(gpd_data);
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
if (genpd->prepared_count > 0) {
|
|
|
|
ret = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2015-01-27 20:13:45 +00:00
|
|
|
ret = genpd->attach_dev ? genpd->attach_dev(genpd, dev) : 0;
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
2014-09-25 16:28:28 +00:00
|
|
|
|
2015-01-27 20:13:40 +00:00
|
|
|
genpd->device_count++;
|
|
|
|
genpd->max_off_time_changed = true;
|
|
|
|
|
2012-07-05 20:12:32 +00:00
|
|
|
list_add_tail(&gpd_data->base.list_node, &genpd->dev_list);
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
out:
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2015-01-27 20:13:42 +00:00
|
|
|
if (ret)
|
|
|
|
genpd_free_dev_data(dev, gpd_data);
|
|
|
|
else
|
|
|
|
dev_pm_qos_add_notifier(dev, &gpd_data->nb);
|
2012-07-05 20:12:32 +00:00
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-08-06 23:06:11 +00:00
|
|
|
/**
|
|
|
|
* __pm_genpd_name_add_device - Find I/O PM domain and add a device to it.
|
|
|
|
* @domain_name: Name of the PM domain to add the device to.
|
|
|
|
* @dev: Device to be added.
|
|
|
|
* @td: Set of PM QoS timing parameters to attach to the device.
|
|
|
|
*/
|
|
|
|
int __pm_genpd_name_add_device(const char *domain_name, struct device *dev,
|
|
|
|
struct gpd_timing_data *td)
|
|
|
|
{
|
2012-08-06 23:11:14 +00:00
|
|
|
return __pm_genpd_add_device(pm_genpd_lookup_name(domain_name), dev, td);
|
2012-08-06 23:06:11 +00:00
|
|
|
}
|
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_remove_device - Remove a device from an I/O PM domain.
|
|
|
|
* @genpd: PM domain to remove the device from.
|
|
|
|
* @dev: Device to be removed.
|
|
|
|
*/
|
|
|
|
int pm_genpd_remove_device(struct generic_pm_domain *genpd,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
struct generic_pm_domain_data *gpd_data;
|
2011-08-25 13:34:12 +00:00
|
|
|
struct pm_domain_data *pdd;
|
2012-05-01 19:33:53 +00:00
|
|
|
int ret = 0;
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
dev_dbg(dev, "%s()\n", __func__);
|
|
|
|
|
2015-03-20 17:20:38 +00:00
|
|
|
if (!genpd || genpd != pm_genpd_lookup_dev(dev))
|
2011-07-01 20:12:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2015-01-27 20:13:42 +00:00
|
|
|
/* The above validation also means we have existing domain_data. */
|
|
|
|
pdd = dev->power.subsys_data->domain_data;
|
|
|
|
gpd_data = to_gpd_data(pdd);
|
|
|
|
dev_pm_qos_remove_notifier(dev, &gpd_data->nb);
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
if (genpd->prepared_count > 0) {
|
|
|
|
ret = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
genpd->device_count--;
|
|
|
|
genpd->max_off_time_changed = true;
|
|
|
|
|
2014-09-25 16:28:28 +00:00
|
|
|
if (genpd->detach_dev)
|
2014-11-05 23:37:08 +00:00
|
|
|
genpd->detach_dev(genpd, dev);
|
2014-09-25 16:28:28 +00:00
|
|
|
|
2012-05-01 19:33:53 +00:00
|
|
|
list_del_init(&pdd->list_node);
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
|
2015-01-27 20:13:39 +00:00
|
|
|
genpd_free_dev_data(dev, gpd_data);
|
2012-07-05 20:12:32 +00:00
|
|
|
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
return 0;
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-07-01 20:13:19 +00:00
|
|
|
out:
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2015-01-27 20:13:42 +00:00
|
|
|
dev_pm_qos_add_notifier(dev, &gpd_data->nb);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_genpd_add_subdomain - Add a subdomain to an I/O PM domain.
|
|
|
|
* @genpd: Master PM domain to add the subdomain to.
|
2011-08-08 21:43:59 +00:00
|
|
|
* @subdomain: Subdomain to be added.
|
2011-07-01 20:12:45 +00:00
|
|
|
*/
|
|
|
|
int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
|
2011-08-08 21:43:59 +00:00
|
|
|
struct generic_pm_domain *subdomain)
|
2011-07-01 20:12:45 +00:00
|
|
|
{
|
2011-08-08 21:43:40 +00:00
|
|
|
struct gpd_link *link;
|
2011-07-01 20:12:45 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
2012-08-06 23:08:37 +00:00
|
|
|
if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain)
|
|
|
|
|| genpd == subdomain)
|
2011-07-01 20:12:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-08-08 21:43:59 +00:00
|
|
|
mutex_lock_nested(&subdomain->lock, SINGLE_DEPTH_NESTING);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-07-11 22:39:29 +00:00
|
|
|
if (genpd->status == GPD_STATE_POWER_OFF
|
2011-08-08 21:43:59 +00:00
|
|
|
&& subdomain->status != GPD_STATE_POWER_OFF) {
|
2011-07-01 20:12:45 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2012-05-07 19:35:45 +00:00
|
|
|
list_for_each_entry(link, &genpd->master_links, master_node) {
|
2011-08-08 21:43:59 +00:00
|
|
|
if (link->slave == subdomain && link->master == genpd) {
|
2011-07-01 20:12:45 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
link = kzalloc(sizeof(*link), GFP_KERNEL);
|
|
|
|
if (!link) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
link->master = genpd;
|
|
|
|
list_add_tail(&link->master_node, &genpd->master_links);
|
2011-08-08 21:43:59 +00:00
|
|
|
link->slave = subdomain;
|
|
|
|
list_add_tail(&link->slave_node, &subdomain->slave_links);
|
|
|
|
if (subdomain->status != GPD_STATE_POWER_OFF)
|
2011-08-08 21:43:04 +00:00
|
|
|
genpd_sd_counter_inc(genpd);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
out:
|
2011-08-08 21:43:59 +00:00
|
|
|
mutex_unlock(&subdomain->lock);
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-08-06 23:08:37 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_add_subdomain_names - Add a subdomain to an I/O PM domain.
|
|
|
|
* @master_name: Name of the master PM domain to add the subdomain to.
|
|
|
|
* @subdomain_name: Name of the subdomain to be added.
|
|
|
|
*/
|
|
|
|
int pm_genpd_add_subdomain_names(const char *master_name,
|
|
|
|
const char *subdomain_name)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *master = NULL, *subdomain = NULL, *gpd;
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(master_name) || IS_ERR_OR_NULL(subdomain_name))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&gpd_list_lock);
|
|
|
|
list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
|
|
|
|
if (!master && !strcmp(gpd->name, master_name))
|
|
|
|
master = gpd;
|
|
|
|
|
|
|
|
if (!subdomain && !strcmp(gpd->name, subdomain_name))
|
|
|
|
subdomain = gpd;
|
|
|
|
|
|
|
|
if (master && subdomain)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
mutex_unlock(&gpd_list_lock);
|
|
|
|
|
|
|
|
return pm_genpd_add_subdomain(master, subdomain);
|
|
|
|
}
|
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_remove_subdomain - Remove a subdomain from an I/O PM domain.
|
|
|
|
* @genpd: Master PM domain to remove the subdomain from.
|
2011-08-08 21:43:40 +00:00
|
|
|
* @subdomain: Subdomain to be removed.
|
2011-07-01 20:12:45 +00:00
|
|
|
*/
|
|
|
|
int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
|
2011-08-08 21:43:40 +00:00
|
|
|
struct generic_pm_domain *subdomain)
|
2011-07-01 20:12:45 +00:00
|
|
|
{
|
2011-08-08 21:43:40 +00:00
|
|
|
struct gpd_link *link;
|
2011-07-01 20:12:45 +00:00
|
|
|
int ret = -EINVAL;
|
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain))
|
2011-07-01 20:12:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
list_for_each_entry(link, &genpd->master_links, master_node) {
|
|
|
|
if (link->slave != subdomain)
|
2011-07-01 20:12:45 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
mutex_lock_nested(&subdomain->lock, SINGLE_DEPTH_NESTING);
|
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
list_del(&link->master_node);
|
|
|
|
list_del(&link->slave_node);
|
|
|
|
kfree(link);
|
2011-07-11 22:39:29 +00:00
|
|
|
if (subdomain->status != GPD_STATE_POWER_OFF)
|
2011-07-01 20:12:45 +00:00
|
|
|
genpd_sd_counter_dec(genpd);
|
|
|
|
|
|
|
|
mutex_unlock(&subdomain->lock);
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
2011-07-01 20:12:45 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-08-15 18:32:43 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_attach_cpuidle - Connect the given PM domain with cpuidle.
|
|
|
|
* @genpd: PM domain to be connected with cpuidle.
|
|
|
|
* @state: cpuidle state this domain can disable/enable.
|
|
|
|
*
|
|
|
|
* Make a PM domain behave as though it contained a CPU core, that is, instead
|
|
|
|
* of calling its power down routine it will enable the given cpuidle state so
|
|
|
|
* that the cpuidle subsystem can power it down (if possible and desirable).
|
|
|
|
*/
|
|
|
|
int pm_genpd_attach_cpuidle(struct generic_pm_domain *genpd, int state)
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
{
|
|
|
|
struct cpuidle_driver *cpuidle_drv;
|
2014-10-02 19:12:34 +00:00
|
|
|
struct gpd_cpuidle_data *cpuidle_data;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
struct cpuidle_state *idle_state;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(genpd) || state < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
|
2014-10-02 19:12:34 +00:00
|
|
|
if (genpd->cpuidle_data) {
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
ret = -EEXIST;
|
|
|
|
goto out;
|
|
|
|
}
|
2014-10-02 19:12:34 +00:00
|
|
|
cpuidle_data = kzalloc(sizeof(*cpuidle_data), GFP_KERNEL);
|
|
|
|
if (!cpuidle_data) {
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
cpuidle_drv = cpuidle_driver_ref();
|
|
|
|
if (!cpuidle_drv) {
|
|
|
|
ret = -ENODEV;
|
2012-10-22 22:54:38 +00:00
|
|
|
goto err_drv;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
}
|
|
|
|
if (cpuidle_drv->state_count <= state) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
idle_state = &cpuidle_drv->states[state];
|
|
|
|
if (!idle_state->disabled) {
|
|
|
|
ret = -EAGAIN;
|
|
|
|
goto err;
|
|
|
|
}
|
2014-10-02 19:12:34 +00:00
|
|
|
cpuidle_data->idle_state = idle_state;
|
|
|
|
cpuidle_data->saved_exit_latency = idle_state->exit_latency;
|
|
|
|
genpd->cpuidle_data = cpuidle_data;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
genpd_recalc_cpu_exit_latency(genpd);
|
|
|
|
|
|
|
|
out:
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
err:
|
|
|
|
cpuidle_driver_unref();
|
2012-10-22 22:54:38 +00:00
|
|
|
|
|
|
|
err_drv:
|
2014-10-02 19:12:34 +00:00
|
|
|
kfree(cpuidle_data);
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2012-08-15 18:32:59 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_name_attach_cpuidle - Find PM domain and connect cpuidle to it.
|
|
|
|
* @name: Name of the domain to connect to cpuidle.
|
|
|
|
* @state: cpuidle state this domain can manipulate.
|
|
|
|
*/
|
|
|
|
int pm_genpd_name_attach_cpuidle(const char *name, int state)
|
|
|
|
{
|
|
|
|
return pm_genpd_attach_cpuidle(pm_genpd_lookup_name(name), state);
|
|
|
|
}
|
|
|
|
|
2012-08-15 18:32:43 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_detach_cpuidle - Remove the cpuidle connection from a PM domain.
|
|
|
|
* @genpd: PM domain to remove the cpuidle connection from.
|
|
|
|
*
|
|
|
|
* Remove the cpuidle connection set up by pm_genpd_attach_cpuidle() from the
|
|
|
|
* given PM domain.
|
|
|
|
*/
|
|
|
|
int pm_genpd_detach_cpuidle(struct generic_pm_domain *genpd)
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
{
|
2014-10-02 19:12:34 +00:00
|
|
|
struct gpd_cpuidle_data *cpuidle_data;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
struct cpuidle_state *idle_state;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(genpd))
|
|
|
|
return -EINVAL;
|
|
|
|
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_lock(&genpd->lock);
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
|
2014-10-02 19:12:34 +00:00
|
|
|
cpuidle_data = genpd->cpuidle_data;
|
|
|
|
if (!cpuidle_data) {
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
ret = -ENODEV;
|
|
|
|
goto out;
|
|
|
|
}
|
2014-10-02 19:12:34 +00:00
|
|
|
idle_state = cpuidle_data->idle_state;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
if (!idle_state->disabled) {
|
|
|
|
ret = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
2014-10-02 19:12:34 +00:00
|
|
|
idle_state->exit_latency = cpuidle_data->saved_exit_latency;
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
cpuidle_driver_unref();
|
2014-10-02 19:12:34 +00:00
|
|
|
genpd->cpuidle_data = NULL;
|
|
|
|
kfree(cpuidle_data);
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
|
|
|
|
out:
|
PM / Domains: Remove intermediate states from the power off sequence
Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.
When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.
Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.
Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.
i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.
The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.
As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.
ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.
Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.
iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.
There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.
After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.
iiii)
Enable fine-grained PM for IRQ safe devices
Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.
As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.
Unfortunately this patch also comes with a drawback, as described in the
summary below.
Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.
However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).
Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18 13:17:53 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
PM / Domains: Add preliminary support for cpuidle, v2
On some systems there are CPU cores located in the same power
domains as I/O devices. Then, power can only be removed from the
domain if all I/O devices in it are not in use and the CPU core
is idle. Add preliminary support for that to the generic PM domains
framework.
First, the platform is expected to provide a cpuidle driver with one
extra state designated for use with the generic PM domains code.
This state should be initially disabled and its exit_latency value
should be set to whatever time is needed to bring up the CPU core
itself after restoring power to it, not including the domain's
power on latency. Its .enter() callback should point to a procedure
that will remove power from the domain containing the CPU core at
the end of the CPU power transition.
The remaining characteristics of the extra cpuidle state, referred to
as the "domain" cpuidle state below, (e.g. power usage, target
residency) should be populated in accordance with the properties of
the hardware.
Next, the platform should execute genpd_attach_cpuidle() on the PM
domain containing the CPU core. That will cause the generic PM
domains framework to treat that domain in a special way such that:
* When all devices in the domain have been suspended and it is about
to be turned off, the states of the devices will be saved, but
power will not be removed from the domain. Instead, the "domain"
cpuidle state will be enabled so that power can be removed from
the domain when the CPU core is idle and the state has been chosen
as the target by the cpuidle governor.
* When the first I/O device in the domain is resumed and
__pm_genpd_poweron(() is called for the first time after
power has been removed from the domain, the "domain" cpuidle
state will be disabled to avoid subsequent surprise power removals
via cpuidle.
The effective exit_latency value of the "domain" cpuidle state
depends on the time needed to bring up the CPU core itself after
restoring power to it as well as on the power on latency of the
domain containing the CPU core. Thus the "domain" cpuidle state's
exit_latency has to be recomputed every time the domain's power on
latency is updated, which may happen every time power is restored
to the domain, if the measured power on latency is greater than
the latency stored in the corresponding generic_pm_domain structure.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
2012-07-03 17:07:42 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-08-15 18:32:59 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_name_detach_cpuidle - Find PM domain and disconnect cpuidle from it.
|
|
|
|
* @name: Name of the domain to disconnect cpuidle from.
|
|
|
|
*/
|
|
|
|
int pm_genpd_name_detach_cpuidle(const char *name)
|
|
|
|
{
|
|
|
|
return pm_genpd_detach_cpuidle(pm_genpd_lookup_name(name));
|
|
|
|
}
|
|
|
|
|
PM / Domains: Rework system suspend callback routines (v2)
The current generic PM domains code attempts to use the generic
system suspend operations along with the domains' device stop/start
routines, which requires device drivers to assume that their
system suspend/resume (and hibernation/restore) callbacks will always
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM domain,
in which case it would be necessary to add "fake" PM domains to
satisfy the above assumption. Also, the domain the hardware belongs
to may not be handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, add new device callbacks,
.suspend(), .suspend_late(), .resume_early(), .resume(), .freeze(),
.freeze_late(), .thaw_early(), and .thaw(), that can be supplied by
the drivers in addition to their "standard" system suspend and
hibernation callbacks. These new callbacks, if defined, will be used
by the generic PM domains code for the handling of system suspend and
hibernation instead of the "standard" ones. This will allow drivers
to be designed to work with generic PM domains as well as without
them.
For backwards compatibility, introduce default implementations of the
new callbacks for PM domains that will execute pm_generic_suspend(),
pm_generic_suspend_noirq(), pm_generic_resume_noirq(),
pm_generic_resume(), pm_generic_freeze(), pm_generic_freeze_noirq(),
pm_generic_thaw_noirq(), and pm_generic_thaw(), respectively, for the
given device if its driver doesn't define those callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:51 +00:00
|
|
|
/* Default device callbacks for generic PM domains. */
|
|
|
|
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
/**
|
2014-09-16 19:59:39 +00:00
|
|
|
* pm_genpd_default_save_state - Default "save device state" for PM domains.
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_default_save_state(struct device *dev)
|
|
|
|
{
|
|
|
|
int (*cb)(struct device *__dev);
|
|
|
|
|
PM / Domains: Use subsystem runtime suspend/resume callbacks by default
Currently, the default "save state" and "restore state" routines
for generic PM domains, pm_genpd_default_save_state() and
pm_genpd_default_restore_state(), respectively, only use runtime PM
callbacks provided by device drivers, but in general those callbacks
need not provide the entire necessary functionality. Namely, in
general it may be necessary to execute subsystem (i.e. device type,
device class or bus type) callbacks that will carry out all of the
necessary operations.
For this reason, modify pm_genpd_default_save_state() and
pm_genpd_default_restore_state() to execute subsystem callbacks,
if they are provided, and fall back to driver callbacks otherwise.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-06-15 22:02:22 +00:00
|
|
|
if (dev->type && dev->type->pm)
|
|
|
|
cb = dev->type->pm->runtime_suspend;
|
|
|
|
else if (dev->class && dev->class->pm)
|
|
|
|
cb = dev->class->pm->runtime_suspend;
|
|
|
|
else if (dev->bus && dev->bus->pm)
|
|
|
|
cb = dev->bus->pm->runtime_suspend;
|
|
|
|
else
|
|
|
|
cb = NULL;
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
|
PM / Domains: Use subsystem runtime suspend/resume callbacks by default
Currently, the default "save state" and "restore state" routines
for generic PM domains, pm_genpd_default_save_state() and
pm_genpd_default_restore_state(), respectively, only use runtime PM
callbacks provided by device drivers, but in general those callbacks
need not provide the entire necessary functionality. Namely, in
general it may be necessary to execute subsystem (i.e. device type,
device class or bus type) callbacks that will carry out all of the
necessary operations.
For this reason, modify pm_genpd_default_save_state() and
pm_genpd_default_restore_state() to execute subsystem callbacks,
if they are provided, and fall back to driver callbacks otherwise.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-06-15 22:02:22 +00:00
|
|
|
if (!cb && dev->driver && dev->driver->pm)
|
|
|
|
cb = dev->driver->pm->runtime_suspend;
|
|
|
|
|
|
|
|
return cb ? cb(dev) : 0;
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2014-09-16 19:59:39 +00:00
|
|
|
* pm_genpd_default_restore_state - Default PM domains "restore device state".
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
*/
|
|
|
|
static int pm_genpd_default_restore_state(struct device *dev)
|
|
|
|
{
|
|
|
|
int (*cb)(struct device *__dev);
|
|
|
|
|
PM / Domains: Use subsystem runtime suspend/resume callbacks by default
Currently, the default "save state" and "restore state" routines
for generic PM domains, pm_genpd_default_save_state() and
pm_genpd_default_restore_state(), respectively, only use runtime PM
callbacks provided by device drivers, but in general those callbacks
need not provide the entire necessary functionality. Namely, in
general it may be necessary to execute subsystem (i.e. device type,
device class or bus type) callbacks that will carry out all of the
necessary operations.
For this reason, modify pm_genpd_default_save_state() and
pm_genpd_default_restore_state() to execute subsystem callbacks,
if they are provided, and fall back to driver callbacks otherwise.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-06-15 22:02:22 +00:00
|
|
|
if (dev->type && dev->type->pm)
|
|
|
|
cb = dev->type->pm->runtime_resume;
|
|
|
|
else if (dev->class && dev->class->pm)
|
|
|
|
cb = dev->class->pm->runtime_resume;
|
|
|
|
else if (dev->bus && dev->bus->pm)
|
|
|
|
cb = dev->bus->pm->runtime_resume;
|
|
|
|
else
|
|
|
|
cb = NULL;
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
|
PM / Domains: Use subsystem runtime suspend/resume callbacks by default
Currently, the default "save state" and "restore state" routines
for generic PM domains, pm_genpd_default_save_state() and
pm_genpd_default_restore_state(), respectively, only use runtime PM
callbacks provided by device drivers, but in general those callbacks
need not provide the entire necessary functionality. Namely, in
general it may be necessary to execute subsystem (i.e. device type,
device class or bus type) callbacks that will carry out all of the
necessary operations.
For this reason, modify pm_genpd_default_save_state() and
pm_genpd_default_restore_state() to execute subsystem callbacks,
if they are provided, and fall back to driver callbacks otherwise.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-06-15 22:02:22 +00:00
|
|
|
if (!cb && dev->driver && dev->driver->pm)
|
|
|
|
cb = dev->driver->pm->runtime_resume;
|
|
|
|
|
|
|
|
return cb ? cb(dev) : 0;
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
}
|
|
|
|
|
2011-07-01 20:12:45 +00:00
|
|
|
/**
|
|
|
|
* pm_genpd_init - Initialize a generic I/O PM domain object.
|
|
|
|
* @genpd: PM domain object to initialize.
|
|
|
|
* @gov: PM domain governor to associate with the domain (may be NULL).
|
|
|
|
* @is_off: Initial value of the domain's power_is_off field.
|
|
|
|
*/
|
|
|
|
void pm_genpd_init(struct generic_pm_domain *genpd,
|
|
|
|
struct dev_power_governor *gov, bool is_off)
|
|
|
|
{
|
|
|
|
if (IS_ERR_OR_NULL(genpd))
|
|
|
|
return;
|
|
|
|
|
2011-08-08 21:43:40 +00:00
|
|
|
INIT_LIST_HEAD(&genpd->master_links);
|
|
|
|
INIT_LIST_HEAD(&genpd->slave_links);
|
2011-07-01 20:12:45 +00:00
|
|
|
INIT_LIST_HEAD(&genpd->dev_list);
|
|
|
|
mutex_init(&genpd->lock);
|
|
|
|
genpd->gov = gov;
|
|
|
|
INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
|
|
|
|
genpd->in_progress = 0;
|
2011-08-08 21:43:04 +00:00
|
|
|
atomic_set(&genpd->sd_count, 0);
|
2011-07-11 22:39:29 +00:00
|
|
|
genpd->status = is_off ? GPD_STATE_POWER_OFF : GPD_STATE_ACTIVE;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->device_count = 0;
|
2011-11-30 23:02:10 +00:00
|
|
|
genpd->max_off_time_ns = -1;
|
PM / Domains: Cache device stop and domain power off governor results, v3
The results of the default device stop and domain power off governor
functions for generic PM domains, default_stop_ok() and
default_power_down_ok(), depend only on the timing data of devices,
which are static, and on their PM QoS constraints. Thus, in theory,
these functions only need to carry out their computations, which may
be time consuming in general, when it is known that the PM QoS
constraint of at least one of the devices in question has changed.
Use the PM QoS notifiers of devices to implement that. First,
introduce new fields, constraint_changed and max_off_time_changed,
into struct gpd_timing_data and struct generic_pm_domain,
respectively, and register a PM QoS notifier function when adding
a device into a domain that will set those fields to 'true' whenever
the device's PM QoS constraint is modified. Second, make
default_stop_ok() and default_power_down_ok() use those fields to
decide whether or not to carry out their computations from scratch.
The device and PM domain hierarchies are taken into account in that
and the expense is that the changes of PM QoS constraints of
suspended devices will not be taken into account immediately, which
isn't guaranteed anyway in general.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-05-01 19:34:07 +00:00
|
|
|
genpd->max_off_time_changed = true;
|
2011-07-01 20:12:45 +00:00
|
|
|
genpd->domain.ops.runtime_suspend = pm_genpd_runtime_suspend;
|
|
|
|
genpd->domain.ops.runtime_resume = pm_genpd_runtime_resume;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.prepare = pm_genpd_prepare;
|
|
|
|
genpd->domain.ops.suspend = pm_genpd_suspend;
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd->domain.ops.suspend_late = pm_genpd_suspend_late;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.suspend_noirq = pm_genpd_suspend_noirq;
|
|
|
|
genpd->domain.ops.resume_noirq = pm_genpd_resume_noirq;
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd->domain.ops.resume_early = pm_genpd_resume_early;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.resume = pm_genpd_resume;
|
|
|
|
genpd->domain.ops.freeze = pm_genpd_freeze;
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd->domain.ops.freeze_late = pm_genpd_freeze_late;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.freeze_noirq = pm_genpd_freeze_noirq;
|
|
|
|
genpd->domain.ops.thaw_noirq = pm_genpd_thaw_noirq;
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd->domain.ops.thaw_early = pm_genpd_thaw_early;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.thaw = pm_genpd_thaw;
|
PM / Domains: Rework system suspend callback routines (v2)
The current generic PM domains code attempts to use the generic
system suspend operations along with the domains' device stop/start
routines, which requires device drivers to assume that their
system suspend/resume (and hibernation/restore) callbacks will always
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM domain,
in which case it would be necessary to add "fake" PM domains to
satisfy the above assumption. Also, the domain the hardware belongs
to may not be handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, add new device callbacks,
.suspend(), .suspend_late(), .resume_early(), .resume(), .freeze(),
.freeze_late(), .thaw_early(), and .thaw(), that can be supplied by
the drivers in addition to their "standard" system suspend and
hibernation callbacks. These new callbacks, if defined, will be used
by the generic PM domains code for the handling of system suspend and
hibernation instead of the "standard" ones. This will allow drivers
to be designed to work with generic PM domains as well as without
them.
For backwards compatibility, introduce default implementations of the
new callbacks for PM domains that will execute pm_generic_suspend(),
pm_generic_suspend_noirq(), pm_generic_resume_noirq(),
pm_generic_resume(), pm_generic_freeze(), pm_generic_freeze_noirq(),
pm_generic_thaw_noirq(), and pm_generic_thaw(), respectively, for the
given device if its driver doesn't define those callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:51 +00:00
|
|
|
genpd->domain.ops.poweroff = pm_genpd_suspend;
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd->domain.ops.poweroff_late = pm_genpd_suspend_late;
|
PM / Domains: Rework system suspend callback routines (v2)
The current generic PM domains code attempts to use the generic
system suspend operations along with the domains' device stop/start
routines, which requires device drivers to assume that their
system suspend/resume (and hibernation/restore) callbacks will always
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM domain,
in which case it would be necessary to add "fake" PM domains to
satisfy the above assumption. Also, the domain the hardware belongs
to may not be handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, add new device callbacks,
.suspend(), .suspend_late(), .resume_early(), .resume(), .freeze(),
.freeze_late(), .thaw_early(), and .thaw(), that can be supplied by
the drivers in addition to their "standard" system suspend and
hibernation callbacks. These new callbacks, if defined, will be used
by the generic PM domains code for the handling of system suspend and
hibernation instead of the "standard" ones. This will allow drivers
to be designed to work with generic PM domains as well as without
them.
For backwards compatibility, introduce default implementations of the
new callbacks for PM domains that will execute pm_generic_suspend(),
pm_generic_suspend_noirq(), pm_generic_resume_noirq(),
pm_generic_resume(), pm_generic_freeze(), pm_generic_freeze_noirq(),
pm_generic_thaw_noirq(), and pm_generic_thaw(), respectively, for the
given device if its driver doesn't define those callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:51 +00:00
|
|
|
genpd->domain.ops.poweroff_noirq = pm_genpd_suspend_noirq;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.restore_noirq = pm_genpd_restore_noirq;
|
2012-01-29 19:39:02 +00:00
|
|
|
genpd->domain.ops.restore_early = pm_genpd_resume_early;
|
PM / Domains: Rework system suspend callback routines (v2)
The current generic PM domains code attempts to use the generic
system suspend operations along with the domains' device stop/start
routines, which requires device drivers to assume that their
system suspend/resume (and hibernation/restore) callbacks will always
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM domain,
in which case it would be necessary to add "fake" PM domains to
satisfy the above assumption. Also, the domain the hardware belongs
to may not be handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, add new device callbacks,
.suspend(), .suspend_late(), .resume_early(), .resume(), .freeze(),
.freeze_late(), .thaw_early(), and .thaw(), that can be supplied by
the drivers in addition to their "standard" system suspend and
hibernation callbacks. These new callbacks, if defined, will be used
by the generic PM domains code for the handling of system suspend and
hibernation instead of the "standard" ones. This will allow drivers
to be designed to work with generic PM domains as well as without
them.
For backwards compatibility, introduce default implementations of the
new callbacks for PM domains that will execute pm_generic_suspend(),
pm_generic_suspend_noirq(), pm_generic_resume_noirq(),
pm_generic_resume(), pm_generic_freeze(), pm_generic_freeze_noirq(),
pm_generic_thaw_noirq(), and pm_generic_thaw(), respectively, for the
given device if its driver doesn't define those callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:51 +00:00
|
|
|
genpd->domain.ops.restore = pm_genpd_resume;
|
2011-07-01 20:13:19 +00:00
|
|
|
genpd->domain.ops.complete = pm_genpd_complete;
|
PM / Domains: Introduce "save/restore state" device callbacks
The current PM domains code uses device drivers' .runtime_suspend()
and .runtime_resume() callbacks as the "save device state" and
"restore device state" operations, which may not be appropriate in
general, because it forces drivers to assume that they always will
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM
domain, in which case it would be necessary to add "fake" PM
domains to satisfy the above assumption. It also may be located in
a PM domain that's not handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, introduce new device callbacks,
.save_state() and .restore_state(), that can be supplied by the
drivers in addition to their "standard" runtime PM callbacks. This
will allow the drivers to be designed to work with generic PM domains
as well as without them.
For backwards compatibility, introduce default .save_state() and
.restore_state() callback routines for PM domains that will execute
a device driver's .runtime_suspend() and .runtime_resume() callbacks,
respectively, for the given device if the driver doesn't provide its
own implementations of .save_state() and .restore_state().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-11-27 12:11:44 +00:00
|
|
|
genpd->dev_ops.save_state = pm_genpd_default_save_state;
|
|
|
|
genpd->dev_ops.restore_state = pm_genpd_default_restore_state;
|
2014-12-01 11:50:21 +00:00
|
|
|
|
|
|
|
if (genpd->flags & GENPD_FLAG_PM_CLK) {
|
|
|
|
genpd->dev_ops.stop = pm_clk_suspend;
|
|
|
|
genpd->dev_ops.start = pm_clk_resume;
|
|
|
|
}
|
|
|
|
|
2011-07-13 10:31:52 +00:00
|
|
|
mutex_lock(&gpd_list_lock);
|
|
|
|
list_add(&genpd->gpd_list_node, &gpd_list);
|
|
|
|
mutex_unlock(&gpd_list_lock);
|
|
|
|
}
|
2014-09-19 18:27:36 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
|
|
|
|
/*
|
|
|
|
* Device Tree based PM domain providers.
|
|
|
|
*
|
|
|
|
* The code below implements generic device tree based PM domain providers that
|
|
|
|
* bind device tree nodes with generic PM domains registered in the system.
|
|
|
|
*
|
|
|
|
* Any driver that registers generic PM domains and needs to support binding of
|
|
|
|
* devices to these domains is supposed to register a PM domain provider, which
|
|
|
|
* maps a PM domain specifier retrieved from the device tree to a PM domain.
|
|
|
|
*
|
|
|
|
* Two simple mapping functions have been provided for convenience:
|
|
|
|
* - __of_genpd_xlate_simple() for 1:1 device tree node to PM domain mapping.
|
|
|
|
* - __of_genpd_xlate_onecell() for mapping of multiple PM domains per node by
|
|
|
|
* index.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct of_genpd_provider - PM domain provider registration structure
|
|
|
|
* @link: Entry in global list of PM domain providers
|
|
|
|
* @node: Pointer to device tree node of PM domain provider
|
|
|
|
* @xlate: Provider-specific xlate callback mapping a set of specifier cells
|
|
|
|
* into a PM domain.
|
|
|
|
* @data: context pointer to be passed into @xlate callback
|
|
|
|
*/
|
|
|
|
struct of_genpd_provider {
|
|
|
|
struct list_head link;
|
|
|
|
struct device_node *node;
|
|
|
|
genpd_xlate_t xlate;
|
|
|
|
void *data;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* List of registered PM domain providers. */
|
|
|
|
static LIST_HEAD(of_genpd_providers);
|
|
|
|
/* Mutex to protect the list above. */
|
|
|
|
static DEFINE_MUTEX(of_genpd_mutex);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __of_genpd_xlate_simple() - Xlate function for direct node-domain mapping
|
|
|
|
* @genpdspec: OF phandle args to map into a PM domain
|
|
|
|
* @data: xlate function private data - pointer to struct generic_pm_domain
|
|
|
|
*
|
|
|
|
* This is a generic xlate function that can be used to model PM domains that
|
|
|
|
* have their own device tree nodes. The private data of xlate function needs
|
|
|
|
* to be a valid pointer to struct generic_pm_domain.
|
|
|
|
*/
|
|
|
|
struct generic_pm_domain *__of_genpd_xlate_simple(
|
|
|
|
struct of_phandle_args *genpdspec,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
if (genpdspec->args_count != 0)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
return data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__of_genpd_xlate_simple);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __of_genpd_xlate_onecell() - Xlate function using a single index.
|
|
|
|
* @genpdspec: OF phandle args to map into a PM domain
|
|
|
|
* @data: xlate function private data - pointer to struct genpd_onecell_data
|
|
|
|
*
|
|
|
|
* This is a generic xlate function that can be used to model simple PM domain
|
|
|
|
* controllers that have one device tree node and provide multiple PM domains.
|
|
|
|
* A single cell is used as an index into an array of PM domains specified in
|
|
|
|
* the genpd_onecell_data struct when registering the provider.
|
|
|
|
*/
|
|
|
|
struct generic_pm_domain *__of_genpd_xlate_onecell(
|
|
|
|
struct of_phandle_args *genpdspec,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct genpd_onecell_data *genpd_data = data;
|
|
|
|
unsigned int idx = genpdspec->args[0];
|
|
|
|
|
|
|
|
if (genpdspec->args_count != 1)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
if (idx >= genpd_data->num_domains) {
|
|
|
|
pr_err("%s: invalid domain index %u\n", __func__, idx);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!genpd_data->domains[idx])
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
|
|
|
return genpd_data->domains[idx];
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__of_genpd_xlate_onecell);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __of_genpd_add_provider() - Register a PM domain provider for a node
|
|
|
|
* @np: Device node pointer associated with the PM domain provider.
|
|
|
|
* @xlate: Callback for decoding PM domain from phandle arguments.
|
|
|
|
* @data: Context pointer for @xlate callback.
|
|
|
|
*/
|
|
|
|
int __of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct of_genpd_provider *cp;
|
|
|
|
|
|
|
|
cp = kzalloc(sizeof(*cp), GFP_KERNEL);
|
|
|
|
if (!cp)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
cp->node = of_node_get(np);
|
|
|
|
cp->data = data;
|
|
|
|
cp->xlate = xlate;
|
|
|
|
|
|
|
|
mutex_lock(&of_genpd_mutex);
|
|
|
|
list_add(&cp->link, &of_genpd_providers);
|
|
|
|
mutex_unlock(&of_genpd_mutex);
|
|
|
|
pr_debug("Added domain provider from %s\n", np->full_name);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__of_genpd_add_provider);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* of_genpd_del_provider() - Remove a previously registered PM domain provider
|
|
|
|
* @np: Device node pointer associated with the PM domain provider
|
|
|
|
*/
|
|
|
|
void of_genpd_del_provider(struct device_node *np)
|
|
|
|
{
|
|
|
|
struct of_genpd_provider *cp;
|
|
|
|
|
|
|
|
mutex_lock(&of_genpd_mutex);
|
|
|
|
list_for_each_entry(cp, &of_genpd_providers, link) {
|
|
|
|
if (cp->node == np) {
|
|
|
|
list_del(&cp->link);
|
|
|
|
of_node_put(cp->node);
|
|
|
|
kfree(cp);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&of_genpd_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(of_genpd_del_provider);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* of_genpd_get_from_provider() - Look-up PM domain
|
|
|
|
* @genpdspec: OF phandle args to use for look-up
|
|
|
|
*
|
|
|
|
* Looks for a PM domain provider under the node specified by @genpdspec and if
|
|
|
|
* found, uses xlate function of the provider to map phandle args to a PM
|
|
|
|
* domain.
|
|
|
|
*
|
|
|
|
* Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
|
|
|
|
* on failure.
|
|
|
|
*/
|
2014-12-15 03:38:59 +00:00
|
|
|
struct generic_pm_domain *of_genpd_get_from_provider(
|
2014-09-19 18:27:36 +00:00
|
|
|
struct of_phandle_args *genpdspec)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
|
|
|
|
struct of_genpd_provider *provider;
|
|
|
|
|
|
|
|
mutex_lock(&of_genpd_mutex);
|
|
|
|
|
|
|
|
/* Check if we have such a provider in our array */
|
|
|
|
list_for_each_entry(provider, &of_genpd_providers, link) {
|
|
|
|
if (provider->node == genpdspec->np)
|
|
|
|
genpd = provider->xlate(genpdspec, provider->data);
|
|
|
|
if (!IS_ERR(genpd))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&of_genpd_mutex);
|
|
|
|
|
|
|
|
return genpd;
|
|
|
|
}
|
2014-12-15 03:38:59 +00:00
|
|
|
EXPORT_SYMBOL_GPL(of_genpd_get_from_provider);
|
2014-09-19 18:27:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* genpd_dev_pm_detach - Detach a device from its PM domain.
|
|
|
|
* @dev: Device to attach.
|
|
|
|
* @power_off: Currently not used
|
|
|
|
*
|
|
|
|
* Try to locate a corresponding generic PM domain, which the device was
|
|
|
|
* attached to previously. If such is found, the device is detached from it.
|
|
|
|
*/
|
|
|
|
static void genpd_dev_pm_detach(struct device *dev, bool power_off)
|
|
|
|
{
|
2015-03-20 17:20:33 +00:00
|
|
|
struct generic_pm_domain *pd;
|
2015-06-26 09:14:14 +00:00
|
|
|
unsigned int i;
|
2014-09-19 18:27:36 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
2015-03-20 17:20:33 +00:00
|
|
|
pd = pm_genpd_lookup_dev(dev);
|
2014-09-19 18:27:36 +00:00
|
|
|
if (!pd)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dev_dbg(dev, "removing from PM domain %s\n", pd->name);
|
|
|
|
|
2015-06-26 09:14:14 +00:00
|
|
|
for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) {
|
2014-09-19 18:27:36 +00:00
|
|
|
ret = pm_genpd_remove_device(pd, dev);
|
|
|
|
if (ret != -EAGAIN)
|
|
|
|
break;
|
2015-06-26 09:14:14 +00:00
|
|
|
|
|
|
|
mdelay(i);
|
2014-09-19 18:27:36 +00:00
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "failed to remove from PM domain %s: %d",
|
|
|
|
pd->name, ret);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if PM domain can be powered off after removing this device. */
|
|
|
|
genpd_queue_power_off_work(pd);
|
|
|
|
}
|
|
|
|
|
2015-03-20 14:55:12 +00:00
|
|
|
static void genpd_dev_pm_sync(struct device *dev)
|
|
|
|
{
|
|
|
|
struct generic_pm_domain *pd;
|
|
|
|
|
|
|
|
pd = dev_to_genpd(dev);
|
|
|
|
if (IS_ERR(pd))
|
|
|
|
return;
|
|
|
|
|
|
|
|
genpd_queue_power_off_work(pd);
|
|
|
|
}
|
|
|
|
|
2014-09-19 18:27:36 +00:00
|
|
|
/**
|
|
|
|
* genpd_dev_pm_attach - Attach a device to its PM domain using DT.
|
|
|
|
* @dev: Device to attach.
|
|
|
|
*
|
|
|
|
* Parse device's OF node to find a PM domain specifier. If such is found,
|
|
|
|
* attaches the device to retrieved pm_domain ops.
|
|
|
|
*
|
|
|
|
* Both generic and legacy Samsung-specific DT bindings are supported to keep
|
|
|
|
* backwards compatibility with existing DTBs.
|
|
|
|
*
|
2015-07-31 09:20:00 +00:00
|
|
|
* Returns 0 on successfully attached PM domain or negative error code. Note
|
|
|
|
* that if a power-domain exists for the device, but it cannot be found or
|
|
|
|
* turned on, then return -EPROBE_DEFER to ensure that the device is not
|
|
|
|
* probed and to re-try again later.
|
2014-09-19 18:27:36 +00:00
|
|
|
*/
|
|
|
|
int genpd_dev_pm_attach(struct device *dev)
|
|
|
|
{
|
|
|
|
struct of_phandle_args pd_args;
|
|
|
|
struct generic_pm_domain *pd;
|
2015-06-26 09:14:14 +00:00
|
|
|
unsigned int i;
|
2014-09-19 18:27:36 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!dev->of_node)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (dev->pm_domain)
|
|
|
|
return -EEXIST;
|
|
|
|
|
|
|
|
ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
|
|
|
|
"#power-domain-cells", 0, &pd_args);
|
|
|
|
if (ret < 0) {
|
|
|
|
if (ret != -ENOENT)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try legacy Samsung-specific bindings
|
|
|
|
* (for backwards compatibility of DT ABI)
|
|
|
|
*/
|
|
|
|
pd_args.args_count = 0;
|
|
|
|
pd_args.np = of_parse_phandle(dev->of_node,
|
|
|
|
"samsung,power-domain", 0);
|
|
|
|
if (!pd_args.np)
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
pd = of_genpd_get_from_provider(&pd_args);
|
|
|
|
if (IS_ERR(pd)) {
|
|
|
|
dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
|
|
|
|
__func__, PTR_ERR(pd));
|
|
|
|
of_node_put(dev->of_node);
|
2015-07-31 09:20:00 +00:00
|
|
|
return -EPROBE_DEFER;
|
2014-09-19 18:27:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
dev_dbg(dev, "adding to PM domain %s\n", pd->name);
|
|
|
|
|
2015-06-26 09:14:14 +00:00
|
|
|
for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) {
|
2014-09-19 18:27:36 +00:00
|
|
|
ret = pm_genpd_add_device(pd, dev);
|
|
|
|
if (ret != -EAGAIN)
|
|
|
|
break;
|
2015-06-26 09:14:14 +00:00
|
|
|
|
|
|
|
mdelay(i);
|
2014-09-19 18:27:36 +00:00
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dev, "failed to add to PM domain %s: %d",
|
|
|
|
pd->name, ret);
|
|
|
|
of_node_put(dev->of_node);
|
2015-07-31 09:20:00 +00:00
|
|
|
goto out;
|
2014-09-19 18:27:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
dev->pm_domain->detach = genpd_dev_pm_detach;
|
2015-03-20 14:55:12 +00:00
|
|
|
dev->pm_domain->sync = genpd_dev_pm_sync;
|
2015-07-31 09:20:00 +00:00
|
|
|
ret = pm_genpd_poweron(pd);
|
2014-09-19 18:27:36 +00:00
|
|
|
|
2015-07-31 09:20:00 +00:00
|
|
|
out:
|
|
|
|
return ret ? -EPROBE_DEFER : 0;
|
2014-09-19 18:27:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
|
2014-11-27 21:38:05 +00:00
|
|
|
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
/*** debugfs support ***/
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_ADVANCED_DEBUG
|
|
|
|
#include <linux/pm.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/debugfs.h>
|
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/kobject.h>
|
|
|
|
static struct dentry *pm_genpd_debugfs_dir;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* TODO: This function is a slightly modified version of rtpm_status_show
|
2014-11-27 21:38:05 +00:00
|
|
|
* from sysfs.c, so generalize it.
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
*/
|
|
|
|
static void rtpm_status_str(struct seq_file *s, struct device *dev)
|
|
|
|
{
|
|
|
|
static const char * const status_lookup[] = {
|
|
|
|
[RPM_ACTIVE] = "active",
|
|
|
|
[RPM_RESUMING] = "resuming",
|
|
|
|
[RPM_SUSPENDED] = "suspended",
|
|
|
|
[RPM_SUSPENDING] = "suspending"
|
|
|
|
};
|
|
|
|
const char *p = "";
|
|
|
|
|
|
|
|
if (dev->power.runtime_error)
|
|
|
|
p = "error";
|
|
|
|
else if (dev->power.disable_depth)
|
|
|
|
p = "unsupported";
|
|
|
|
else if (dev->power.runtime_status < ARRAY_SIZE(status_lookup))
|
|
|
|
p = status_lookup[dev->power.runtime_status];
|
|
|
|
else
|
|
|
|
WARN_ON(1);
|
|
|
|
|
|
|
|
seq_puts(s, p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pm_genpd_summary_one(struct seq_file *s,
|
2015-03-02 19:24:28 +00:00
|
|
|
struct generic_pm_domain *genpd)
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
{
|
|
|
|
static const char * const status_lookup[] = {
|
|
|
|
[GPD_STATE_ACTIVE] = "on",
|
|
|
|
[GPD_STATE_POWER_OFF] = "off"
|
|
|
|
};
|
|
|
|
struct pm_domain_data *pm_data;
|
|
|
|
const char *kobj_path;
|
|
|
|
struct gpd_link *link;
|
|
|
|
int ret;
|
|
|
|
|
2015-03-02 19:24:28 +00:00
|
|
|
ret = mutex_lock_interruptible(&genpd->lock);
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
if (ret)
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
2015-03-02 19:24:28 +00:00
|
|
|
if (WARN_ON(genpd->status >= ARRAY_SIZE(status_lookup)))
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
goto exit;
|
2015-03-02 19:24:28 +00:00
|
|
|
seq_printf(s, "%-30s %-15s ", genpd->name, status_lookup[genpd->status]);
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Modifications on the list require holding locks on both
|
|
|
|
* master and slave, so we are safe.
|
2015-03-02 19:24:28 +00:00
|
|
|
* Also genpd->name is immutable.
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
*/
|
2015-03-02 19:24:28 +00:00
|
|
|
list_for_each_entry(link, &genpd->master_links, master_node) {
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
seq_printf(s, "%s", link->slave->name);
|
2015-03-02 19:24:28 +00:00
|
|
|
if (!list_is_last(&link->master_node, &genpd->master_links))
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
seq_puts(s, ", ");
|
|
|
|
}
|
|
|
|
|
2015-03-02 19:24:28 +00:00
|
|
|
list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
kobj_path = kobject_get_path(&pm_data->dev->kobj, GFP_KERNEL);
|
|
|
|
if (kobj_path == NULL)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
seq_printf(s, "\n %-50s ", kobj_path);
|
|
|
|
rtpm_status_str(s, pm_data->dev);
|
|
|
|
kfree(kobj_path);
|
|
|
|
}
|
|
|
|
|
|
|
|
seq_puts(s, "\n");
|
|
|
|
exit:
|
2015-03-02 19:24:28 +00:00
|
|
|
mutex_unlock(&genpd->lock);
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pm_genpd_summary_show(struct seq_file *s, void *data)
|
|
|
|
{
|
2015-03-02 19:24:28 +00:00
|
|
|
struct generic_pm_domain *genpd;
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
seq_puts(s, " domain status slaves\n");
|
|
|
|
seq_puts(s, " /device runtime status\n");
|
|
|
|
seq_puts(s, "----------------------------------------------------------------------\n");
|
|
|
|
|
|
|
|
ret = mutex_lock_interruptible(&gpd_list_lock);
|
|
|
|
if (ret)
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
2015-03-02 19:24:28 +00:00
|
|
|
list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
|
|
|
|
ret = pm_genpd_summary_one(s, genpd);
|
PM / Domains: add debugfs listing of struct generic_pm_domain-s
Add /sys/kernel/debug/pm_genpd/pm_genpd_summary file, which
lists power domains in the system, their statuses and attached devices,
resembling /sys/kernel/debug/clk/clk_summary.
Currently it is impossible to inspect (from userland) whether
a power domain is on or off. And, if it is on, which device blocks it
from powering down. This change allows developers working on
embedded devices power efficiency to list all necessary information
about generic power domains in one place.
The content of pm_genpd/pm_genpd_summary file is generated by iterating
over all generic power domain in the system, and, for each,
over registered devices and over the subdomains, if present.
Example output:
$ cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
a4su off
a3sg off
a3sm on
a3sp on
/devices/e6600000.pwm suspended
/devices/e6c50000.serial active
/devices/e6850000.sd suspended
/devices/e6bd0000.mmc active
a4s on a3sp, a3sm, a3sg
/devices/e6900000.irqpin unsupported
/devices/e6900004.irqpin unsupported
/devices/e6900008.irqpin unsupported
/devices/e690000c.irqpin unsupported
/devices/e9a00000.ethernet active
a3rv off
a4r off a3rv
/devices/fff20000.i2c suspended
a4lc off
c5 on a4lc, a4r, a4s, a4su
/devices/e6050000.pfc unsupported
/devices/e6138000.timer active
To enable this feature, compile the kernel with debugfs
and CONFIG_PM_ADVANCED_DEBUG enabled.
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-15 11:09:10 +00:00
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
mutex_unlock(&gpd_list_lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pm_genpd_summary_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
return single_open(file, pm_genpd_summary_show, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations pm_genpd_summary_fops = {
|
|
|
|
.open = pm_genpd_summary_open,
|
|
|
|
.read = seq_read,
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
.release = single_release,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init pm_genpd_debug_init(void)
|
|
|
|
{
|
|
|
|
struct dentry *d;
|
|
|
|
|
|
|
|
pm_genpd_debugfs_dir = debugfs_create_dir("pm_genpd", NULL);
|
|
|
|
|
|
|
|
if (!pm_genpd_debugfs_dir)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
d = debugfs_create_file("pm_genpd_summary", S_IRUGO,
|
|
|
|
pm_genpd_debugfs_dir, NULL, &pm_genpd_summary_fops);
|
|
|
|
if (!d)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(pm_genpd_debug_init);
|
|
|
|
|
|
|
|
static void __exit pm_genpd_debug_exit(void)
|
|
|
|
{
|
|
|
|
debugfs_remove_recursive(pm_genpd_debugfs_dir);
|
|
|
|
}
|
|
|
|
__exitcall(pm_genpd_debug_exit);
|
|
|
|
#endif /* CONFIG_PM_ADVANCED_DEBUG */
|