Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 25 6月, 2018 1 次提交
  3. 06 6月, 2018 3 次提交
  5. 30 5月, 2018 4 次提交
  7. 25 5月, 2018 1 次提交
  9. 15 5月, 2018 5 次提交
  11. 09 5月, 2018 3 次提交
    • V
      PM / Domain: Implement of_genpd_opp_to_performance_state() · 6e41766a
      由 Viresh Kumar 提交于 
      This implements of_genpd_opp_to_performance_state() which can be used
from the device drivers or the OPP core to find the performance state
encoded in the "required-opps" property of a node. Normally this would
be called only once for each OPP of the device for which the OPP table
of the device is getting generated.

Different platforms may encode the performance state differently using
the OPP table (they may simply return value of opp-hz or opp-microvolt,
or apply some algorithm on top of those values) and so a new callback
->opp_to_performance_state() is implemented to allow platform specific
drivers to convert the power domain OPP to a performance state value.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      6e41766a
    • V
      PM / Domain: Add support to parse domain's OPP table · 6a0ae73d
      由 Viresh Kumar 提交于 
      The generic power domains can have an OPP table for themselves now, and
phandle of their OPP nodes can be used by the devices powered by the
domain. In order for the OPP core to translate requirements between the
devices and their power domains, both need to have an OPP table in
kernel.

Parse the OPP table for power domains
if they have their
set_performance_state() callback set.

With this patch, an OPP table would be created for the genpd in kernel
based on the OPP table present in DT, if the genpd have its
set_performance_state() callback set.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      6a0ae73d
    • V
      PM / Domain: Add struct device to genpd · 401ea157
      由 Viresh Kumar 提交于 
      The power-domain core would be using the OPP core going forward and the
OPP core has the basic requirement of a device structure for its working.

Add a struct device to the genpd structure. This doesn't register the
device with device core as the "dev" pointer is mostly used by the OPP
core as a cookie for now and registering the device is not mandatory.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      401ea157
  13. 07 2月, 2018 1 次提交
    • U
      PM / domains: Fix up domain-idle-states OF parsing · a3381e3a
      由 Ulf Hansson 提交于 
      Commit b539cc82 (PM / Domains: Ignore domain-idle-states that are
not compatible), made it possible to ignore non-compatible
domain-idle-states OF nodes. However, in case that happens while doing
the OF parsing, the number of elements in the allocated array would
exceed the numbers actually needed, thus wasting memory.

Fix this by pre-iterating the genpd OF node and counting the number of
compatible domain-idle-states nodes, before doing the allocation. While
doing this, it makes sense to rework the code a bit to avoid open coding,
of parts responsible for the OF node iteration.

Let's also take the opportunity to clarify the function header for
of_genpd_parse_idle_states(), about what is being returned in case of
errors.

Fixes: b539cc82 (PM / Domains: Ignore domain-idle-states that are not compatible)
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLina Iyer <ilina@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a3381e3a
  15. 15 1月, 2018 1 次提交
    • R
      PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume() · 17218e00
      由 Rafael J. Wysocki 提交于 
      There are problems with calling pm_runtime_force_suspend/resume()
to "stop" and "start" devices in genpd_finish_suspend() and
genpd_resume_noirq() (and in analogous hibernation-specific genpd
callbacks) after commit 122a2237 (PM / Domains: Stop/start
devices during system PM suspend/resume in genpd) as those routines
do much more than just "stopping" and "starting" devices (which was
the stated purpose of that commit) unnecessarily and may not play
well with system-wide PM driver callbacks.

First, consider the pm_runtime_force_suspend() in
genpd_finish_suspend().  If the current runtime PM status of the
device is "suspended", that function most likely does the right thing
by ignoring the device, because it should have been "stopped" already
and whatever needed to be done to deactivate it shoud have been done.
In turn, if the runtime PM status of the device is "active",
genpd_runtime_suspend() is called for it (indirectly) and (1) runs
the ->runtime_suspend callback provided by the device's driver
(assuming no bus type with ->runtime_suspend of its own), (2) "stops"
the device and (3) checks if the domain can be powered down, and then
(4) the device's runtime PM status is changed to "suspended".  Out of
the four actions above (1) is not necessary and it may be outright
harmful, (3) is pointless and (4) is questionable.  The only
operation that needs to be carried out here is (2).

The reason why (1) is not necessary is because the system-wide
PM callbacks provided by the device driver for the transition in
question have been run and they should have taken care of the
driver's part of device suspend already.  Moreover, it may be
harmful, because the ->runtime_suspend callback may want to
access the device which is partially suspended at that point
and may not be responsive.  Also, system-wide PM callbacks may
have been run already (in the previous phases of the system
transition under way) for the device's parent or for its supplier
devices (if any) and the device may not be accessible because of
that.

There also is no reason to do (3), because genpd_finish_suspend()
will repeat it anyway, and (4) potentially causes confusion to ensue
during the subsequent system transition to the working state.

Consider pm_runtime_force_resume() in genpd_resume_noirq() now.
It runs genpd_runtime_resume() for all devices with runtime PM
status set to "suspended", which includes all of the devices
whose runtime PM status was changed by pm_runtime_force_suspend()
before and may include some devices already suspended when the
pm_runtime_force_suspend() was running, which may be confusing.  The
genpd_runtime_resume() first tries to power up the domain, which
(again) is pointless, because genpd_resume_noirq() has done that
already.  Then, it "starts" the device and runs the ->runtime_resume
callback (from the driver, say) for it.  If all is well, the device
is left with the runtime PM status set to "active".

Unfortunately, running the driver's ->runtime_resume callback
before its system-wide PM callbacks and possibly before some
system-wide PM callbacks of the parent device's driver (let
alone supplier drivers) is asking for trouble, especially if
the device had been suspended before pm_runtime_force_suspend()
ran previously or if the callbacks in question expect to be run
back-to-back with their suspend-side counterparts.  It also should
not be necessary, because the system-wide PM driver callbacks that
will be invoked for the device subsequently should take care of
resuming it just fine.

[Running the driver's ->runtime_resume callback in the "noirq"
phase of the transition to the working state may be problematic
even for devices whose drivers do use pm_runtime_force_resume()
in (or as) their system-wide PM callbacks if they have suppliers
other than their parents, because it may cause the supplier to
be resumed after the consumer in some cases.]

Because of the above, modify genpd as follows:

 1. Change genpd_finish_suspend() to only "stop" devices with
    runtime PM status set to "active" (without invoking runtime PM
    callbacks for them, changing their runtime PM status and so on).

    That doesn't change the handling of devices whose drivers use
    pm_runtime_force_suspend/resume() in (or as) their system-wide
    PM callbacks and addresses the issues described above for the
    other devices.

 2. Change genpd_resume_noirq() to only "start" devices with
    runtime PM status set to "active" (without invoking runtime PM
    callbacks for them, changing their runtime PM status and so on).

    Again, that doesn't change the handling of devices whose drivers
    use pm_runtime_force_suspend/resume() in (or as) their system-wide
    PM callbacks and addresses the described issues for the other
    devices.  Devices with runtime PM status set to "suspended"
    are not started with the assumption that they will be resumed
    later, either by pm_runtime_force_resume() or via runtime PM.

 3. Change genpd_restore_noirq() to follow genpd_resume_noirq().

    That causes devices already suspended before hibernation to be
    left alone (which also is the case without the change) and
    avoids running the ->runtime_resume driver callback too early
    for the other devices.

 4. Change genpd_freeze_noirq() and genpd_thaw_noirq() in accordance
    with the above modifications.

Fixes: 122a2237 (PM / Domains: Stop/start devices during system PM suspend/resume in genpd)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      17218e00
  17. 11 1月, 2018 1 次提交
  19. 13 12月, 2017 1 次提交
  21. 08 11月, 2017 5 次提交
    • U
      PM / Domains: Fix genpd to deal with drivers returning 1 from ->prepare() · 5241ab40
      由 Ulf Hansson 提交于 
      During system-wide PM, genpd relies on its PM callbacks to be invoked for
all its attached devices, as to deal with powering off/on the PM domain. In
other words, genpd is not compatible with the direct_complete path, if
executed by the PM core for any of its attached devices.

However, when genpd's ->prepare() callback invokes pm_generic_prepare(), it
does not take into account that it may return 1. Instead it treats that as
an error internally and expects the PM core to abort the prepare phase and
roll back. This leads to genpd not properly powering on/off the PM domain,
because its internal counters gets wrongly balanced.

To fix the behaviour, allow drivers to return 1 from their ->prepare()
callbacks, but let's return 0 from genpd's ->prepare() callback in such
case, as that prevents the PM core from running the direct_complete path
for the device.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5241ab40
    • R
      PM / QoS: Fix device resume latency framework · 0759e80b
      由 Rafael J. Wysocki 提交于 
      The special value of 0 for device resume latency PM QoS means
"no restriction", but there are two problems with that.

First, device resume latency PM QoS requests with 0 as the
value are always put in front of requests with positive
values in the priority lists used internally by the PM QoS
framework, causing 0 to be chosen as an effective constraint
value.  However, that 0 is then interpreted as "no restriction"
effectively overriding the other requests with specific
restrictions which is incorrect.

Second, the users of device resume latency PM QoS have no
way to specify that *any* resume latency at all should be
avoided, which is an artificial limitation in general.

To address these issues, modify device resume latency PM QoS to
use S32_MAX as the "no constraint" value and 0 as the "no
latency at all" one and rework its users (the cpuidle menu
governor, the genpd QoS governor and the runtime PM framework)
to follow these changes.

Also add a special "n/a" value to the corresponding user space I/F
to allow user space to indicate that it cannot accept any resume
latencies at all for the given device.

Fixes: 85dc0b8a (PM / QoS: Make it possible to expose PM QoS latency constraints)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197323Reported-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NReinette Chatre <reinette.chatre@intel.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NRamesh Thomas <ramesh.thomas@intel.com>
      0759e80b
    • R
      PM / domains: Rework governor code to be more consistent · 704d2ce6
      由 Rafael J. Wysocki 提交于 
      The genpd governor currently uses negative PM QoS values to indicate
the "no suspend" condition and 0 as "no restriction", but it doesn't
use them consistently.  Moreover, it tries to refresh QoS values for
already suspended devices in a quite questionable way.

For the above reasons, rework it to be a bit more consistent.

First off, note that dev_pm_qos_read_value() in
dev_update_qos_constraint() and __default_power_down_ok() is
evaluated for devices in suspend.  Moreover, that only happens if the
effective_constraint_ns value for them is negative (meaning "no
suspend").  It is not evaluated in any other cases, so effectively
the QoS values are only updated for devices in suspend that should
not have been suspended in the first place.  In all of the other
cases, the QoS values taken into account are the effective ones from
the time before the device has been suspended, so generally devices
need to be resumed and suspended again for new QoS values to take
effect anyway.  Thus evaluating dev_update_qos_constraint() in
those two places doesn't make sense at all, so drop it.

Second, initialize effective_constraint_ns to 0 ("no constraint")
rather than to (-1) ("no suspend"), which makes more sense in
general and in case effective_constraint_ns is never updated
(the device is in suspend all the time or it is never suspended)
it doesn't affect the device's parent and so on.

Finally, rework default_suspend_ok() to explicitly handle the
"no restriction" and "no suspend" special cases.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NTero Kristo <t-kristo@ti.com>
Reviewed-by: NRamesh Thomas <ramesh.thomas@intel.com>
      704d2ce6
    • G
      PM / Domains: Remove gpd_dev_ops.active_wakeup() callback · d0af45f1
      由 Geert Uytterhoeven 提交于 
      There are no more users left of the gpd_dev_ops.active_wakeup()
callback.  All have been converted to GENPD_FLAG_ACTIVE_WAKEUP.
Hence remove the callback.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d0af45f1
    • G
      PM / Domains: Allow genpd users to specify default active wakeup behavior · 95a20ef6
      由 Geert Uytterhoeven 提交于 
      It is quite common for PM Domains to require slave devices to be kept
active during system suspend if they are to be used as wakeup sources.
To enable this, currently each PM Domain or driver has to provide its
own gpd_dev_ops.active_wakeup() callback.

Introduce a new flag GENPD_FLAG_ACTIVE_WAKEUP to consolidate this.
If specified, all slave devices configured as wakeup sources will be
kept active during system suspend.

PM Domains that need more fine-grained controls, based on the slave
device, can still provide their own callbacks, as before.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      95a20ef6
  23. 14 10月, 2017 2 次提交
    • R
      PM / QoS: Drop PM_QOS_FLAG_REMOTE_WAKEUP · 20f97caf
      由 Rafael J. Wysocki 提交于 
      The PM QoS flag PM_QOS_FLAG_REMOTE_WAKEUP is not used consistently
and the vast majority of code simply assumes that remote wakeup
should be enabled for devices in runtime suspend if they can
generate wakeup signals, so drop it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      20f97caf
    • V
      PM / Domains: Add support to select performance-state of domains · 42f6284a
      由 Viresh Kumar 提交于 
      Some platforms have the capability to configure the performance state of
PM domains. This patch enhances the genpd core to support such
platforms.

The performance levels (within the genpd core) are identified by
positive integer values, a lower value represents lower performance
state.

This patch adds a new genpd API, which is called by user drivers (like
OPP framework):

- int dev_pm_genpd_set_performance_state(struct device *dev,
					 unsigned int state);

  This updates the performance state constraint of the device on its PM
  domain. On success, the genpd will have its performance state set to a
  value which is >= "state" passed to this routine. The genpd core calls
  the genpd->set_performance_state() callback, if implemented,
  else -ENODEV is returned to the caller.

The PM domain drivers need to implement the following callback if they
want to support performance states.

- int (*set_performance_state)(struct generic_pm_domain *genpd,
			       unsigned int state);

  This is called internally by the genpd core on several occasions. The
  genpd core passes the genpd pointer and the aggregate of the
  performance states of the devices supported by that genpd to this
  callback. This callback must update the performance state of the genpd
  (in a platform dependent way).

The power domains can avoid supplying above callback, if they don't
support setting performance-states.

Currently we aren't propagating performance state changes of a subdomain
to its masters as we don't have hardware that needs it right now. Over
that, the performance states of subdomain and its masters may not have
one-to-one mapping and would require additional information. We can get
back to this once we have hardware that needs it.
Tested-by: NRajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      42f6284a
  25. 11 10月, 2017 1 次提交
  27. 25 8月, 2017 1 次提交
  29. 25 7月, 2017 2 次提交
  31. 19 7月, 2017 1 次提交
  33. 05 7月, 2017 2 次提交
  35. 29 6月, 2017 5 次提交