1. 04 Dec, 2015 1 commit
  2. 02 Nov, 2015 2 commits
  3. 28 Oct, 2015 2 commits
  4. 14 Oct, 2015 1 commit
  5. 12 Oct, 2015 3 commits
  6. 09 Oct, 2015 1 commit
  7. 27 Sep, 2015 1 commit
  8. 26 Sep, 2015 2 commits
  9. 05 Sep, 2015 1 commit
  10. 03 Sep, 2015 1 commit
  11. 28 Aug, 2015 3 commits
  12. 31 Jul, 2015 2 commits
    • Jon Hunter's avatar
      PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain · 311fa6ad
      Jon Hunter authored
      When a device is probed, the function dev_pm_domain_attach() is called
      to see if there is a power-domain that is associated with the device and
      needs to be turned on. If dev_pm_domain_attach() does not return
      -EPROBE_DEFER then the device will be probed.
      For devices using genpd, dev_pm_domain_attach() will call
      genpd_dev_pm_attach(). If genpd_dev_pm_attach() does not find a power
      domain associated with the device then it returns an error code not
      equal to -EPROBE_DEFER to allow the device to be probed. However, if
      genpd_dev_pm_attach() does find a power-domain that is associated with
      the device, then it does not return -EPROBE_DEFER on failure and hence
      the device will still be probed. Furthermore, genpd_dev_pm_attach() does
      not check the error code returned by pm_genpd_poweron() to see if the
      power-domain was turned on successfully.
      Fix this by checking the return code from pm_genpd_poweron() and
      returning -EPROBE_DEFER from genpd_dev_pm_attach on failure, if there
      is a power-domain associated with the device.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Acked-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    • Ulf Hansson's avatar
      PM / Domains: Remove intermediate states from the power off sequence · ba2bbfbf
      Ulf Hansson authored
      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
      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.
      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
      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
      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.
      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
      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: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarKevin Hilman <khilman@linaro.org>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: default avatarLina Iyer <lina.iyer@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  13. 06 Jul, 2015 1 commit
  14. 15 Jun, 2015 1 commit
    • Geert Uytterhoeven's avatar
      PM / Domains: Skip timings during syscore suspend/resume · a4630c61
      Geert Uytterhoeven authored
      The PM Domain code uses ktime_get() to perform various latency
      measurements.  However, if ktime_get() is called while timekeeping is
      suspended, the following warning is printed:
          WARNING: CPU: 0 PID: 1340 at kernel/time/timekeeping.c:576 ktime_get+0x3
      This happens when resuming the PM Domain that contains the clock events
      source, which calls pm_genpd_syscore_poweron(). Chain of operations is:
      				ktime_get(), but timekeeping_suspended == 1
      	timekeeping_suspended = 0;
      Fix this by adding a "timed" parameter to genpd_power_{on,off}() and
      pm_genpd_sync_power{off,on}(), to indicate whether latency measurements
      are allowed.  This parameter is passed as false in
      genpd_syscore_switch() (i.e. during syscore suspend/resume), and true in
      all other cases.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  15. 23 Mar, 2015 1 commit
  16. 22 Mar, 2015 3 commits
  17. 04 Mar, 2015 1 commit
  18. 03 Feb, 2015 8 commits
  19. 23 Jan, 2015 1 commit
  20. 17 Dec, 2014 1 commit
  21. 03 Dec, 2014 2 commits
  22. 20 Nov, 2014 1 commit
    • Ulf Hansson's avatar
      PM / Domains: Power on the PM domain right after attach completes · 2ed12769
      Ulf Hansson authored
      Vast amount of platform drivers which enables runtime PM, don't invoke
      a pm_runtime_get_sync() while probing their devices.
      Instead, once they have turned on their PM resourses during ->probe()
      and are ready to handle I/O, these invokes pm_runtime_set_active() to
      synchronize its state towards the runtime PM core.
      From the runtime PM point of view this behavior is perfectly acceptable,
      but we encounter probe failures if their corresponding devices resides
      in the generic PM domain. The issues are observed for those devices,
      which requires its PM domain to stay powered during ->probe() since
      that's not being controlled.
      While using the generic OF-based PM domain look-up, a device's PM
      domain will be attached during the probe sequence. For this path, let's
      fix the probe failures, by simply power on the PM domain right after
      when it's been attached to the device.
      The generic PM domain stays powered until all of its devices becomes
      runtime PM enabled and runtime PM suspended.
      The old SOCs which makes use of the generic PM domain but don't use the
      generic OF-based PM domain look-up, will not be affected from this
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>