1. 30 5月, 2018 1 次提交
  2. 15 5月, 2018 1 次提交
    • U
      PM / Domains: Allow a better error handling of dev_pm_domain_attach() · 919b7308
      Ulf Hansson 提交于
      The callers of dev_pm_domain_attach() currently checks the returned error
      code for -EPROBE_DEFER and needs to ignore other error codes. This is an
      unnecessary limitation, which also leads to a rather strange behaviour in
      the error path.
      
      Address this limitation, by changing the return codes from
      acpi_dev_pm_attach() and genpd_dev_pm_attach(). More precisely, let them
      return 0, when no PM domain is needed for the device and then return 1, in
      case the device was successfully attached to its PM domain. In this way,
      dev_pm_domain_attach(), gets a better understanding of what happens in the
      attach attempts and also allowing its caller to better act on real errors
      codes.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      919b7308
  3. 09 5月, 2018 2 次提交
    • 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 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
  4. 08 11月, 2017 2 次提交
  5. 14 10月, 2017 1 次提交
    • 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
  6. 25 7月, 2017 1 次提交
  7. 13 6月, 2017 1 次提交
  8. 04 4月, 2017 1 次提交
  9. 29 3月, 2017 1 次提交
    • U
      PM / Domains: Enable users of genpd to specify always on PM domains · ffaa42e8
      Ulf Hansson 提交于
      The current way to implement an always on PM domain consists of returning
      -EBUSY from the ->power_off() callback. This is a bit different compared to
      using the always on genpd governor, which prevents the PM domain from being
      powered off via runtime suspend, but not via system suspend.
      
      The approach to return -EBUSY from the ->power_off() callback to support
      always on PM domains in genpd is suboptimal. That is because it requires
      genpd to follow the regular execution path of the power off sequence, which
      ends by invoking the ->power_off() callback.
      
      To enable genpd to early abort the power off sequence for always on PM
      domains, it needs static information about these configurations. Therefore
      let's add a new genpd configuration flag, GENPD_FLAG_ALWAYS_ON.
      
      Users of the new GENPD_FLAG_ALWAYS_ON flag, are by genpd required to make
      sure the PM domain is powered on before calling pm_genpd_init(). Moreover,
      users don't need to implement the ->power_off() callback, as genpd doesn't
      ever invoke it.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ffaa42e8
  10. 09 2月, 2017 1 次提交
  11. 22 10月, 2016 6 次提交
  12. 13 9月, 2016 6 次提交
    • J
      PM / Domains: Add support for removing nested PM domains by provider · 17926551
      Jon Hunter 提交于
      If a device supports PM domains that are subdomains of another PM
      domain, then the PM domains should be removed in reverse order to
      ensure that the subdomains are removed first. Furthermore, if there is
      more than one provider, then there needs to be a way to remove the
      domains in reverse order for a specific provider.
      
      Add the function of_genpd_remove_last() to remove the last PM domain
      added by a given PM domain provider and return the generic_pm_domain
      structure for the PM domain that was removed.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      17926551
    • J
      PM / Domains: Add support for removing PM domains · 3fe57710
      Jon Hunter 提交于
      The genpd framework allows users to add PM domains via the pm_genpd_init()
      function, however, there is no corresponding function to remove a PM
      domain. For most devices this may be fine as the PM domains are never
      removed, however, for devices that wish to populate the PM domains from
      within a driver, having the ability to remove a PM domain if the probing
      of the device fails or the driver is unloaded is necessary.
      
      Add the function pm_genpd_remove() to remove a PM domain by referencing
      it's generic_pm_domain structure. Note that the bulk of the code that
      removes the PM domain is placed in a separate local function
      genpd_remove() (which is called by pm_genpd_remove()). The code is
      structured in this way to prepare for adding another function to remove
      a PM domain by provider that will also call genpd_remove(). Note that
      users of genpd_remove() must call this function with the mutex,
      gpd_list_lock, held.
      
      PM domains can only be removed if the associated provider has been
      removed, they are not a parent domain to another PM domain and have no
      devices associated with them.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3fe57710
    • J
      PM / Domains: Store the provider in the PM domain structure · de0aa06d
      Jon Hunter 提交于
      It is possible that a device has more than one provider of PM domains
      and to support the removal of a PM domain by provider, it is necessary
      to store a reference to the provider in the PM domain structure.
      Therefore, store a reference to the firmware node handle in the PM
      domain structure and populate it when providers (only device-tree based
      providers are currently supported by PM domains) are registered.
      
      Please note that when removing PM domains, it is necessary to verify
      that the PM domain provider has been removed from the list of providers
      before the PM domain can be removed. To do this add another member to
      the PM domain structure that indicates if the provider is present and
      set this member accordingly when providers are added and removed.
      
      Initialise the 'provider' and 'has_provider' members of the
      generic_pm_domain structure when a PM domains is added by calling
      pm_genpd_init().
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      de0aa06d
    • J
      PM / Domains: Don't expose xlate and provider helper functions · 892ebdcc
      Jon Hunter 提交于
      Functions __of_genpd_xlate_simple(), __of_genpd_xlate_onecell() and
      __of_genpd_add_provider() are not used outside of the core generic PM
      domain code. Therefore, reduce the number of APIs exposed by making
      these static. At the same time don't expose the typedef for
      genpd_xlate_t either and make this a local definition as well.
      
      The functions are renamed to follow the naming conventions for static
      functions in the generic PM domain core.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      892ebdcc
    • J
      PM / Domains: Don't expose generic_pm_domain structure to clients · f58d4e5a
      Jon Hunter 提交于
      There should be no need to expose the generic_pm_domain structure to
      clients and this eliminates the need to implement reference counting for
      any external reference to a PM domain. Therefore, make the functions
      pm_genpd_lookup_dev() and of_genpd_get_from_provider() private to the
      PM domain core. The functions are renamed in accordance with the naming
      conventions for genpd static functions.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f58d4e5a
    • J
      PM / Domains: Add new helper functions for device-tree · ec69572b
      Jon Hunter 提交于
      Ideally, if we are returning a reference to a PM domain via a call to
      of_genpd_get_from_provider(), then we should keep track of such
      references via a reference count. The reference count could then be used
      to determine if a PM domain can be safely removed. Alternatively, it is
      possible to avoid such external references by providing APIs to access
      the PM domain and hence, eliminate any calls to
      of_genpd_get_from_provider().
      
      Add new helper functions for adding a device and a subdomain to a PM
      domain when using device-tree, so that external calls to
      of_genpd_get_from_provider() can be removed.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ec69572b
  13. 29 6月, 2016 1 次提交
  14. 16 6月, 2016 1 次提交
    • U
      PM / Domains: Allow genpd to power on during system PM phases · 39dd0f23
      Ulf Hansson 提交于
      If a PM domain is powered off when the first device starts its system PM
      prepare phase, genpd prevents any further attempts to power on the PM
      domain during the following system PM phases. Not until the system PM
      complete phase is finalized for all devices in the PM domain, genpd again
      allows it to be powered on.
      
      This behaviour needs to be changed, as a subsystem/driver for a device in
      the same PM domain may still need to be able to serve requests in some of
      the system PM phases. Accordingly, it may need to runtime resume its
      device and thus also request the corresponding PM domain to be powered on.
      
      To deal with these scenarios, let's make the device operational in the
      system PM prepare phase by runtime resuming it, no matter if the PM domain
      is powered on or off. Changing this also enables us to remove genpd's
      suspend_power_off flag, as it's being used to track this condition.
      Additionally, we must allow the PM domain to be powered on via runtime PM
      during the system PM phases.
      
      This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
      driver. It registers a genpd to model the ACP as a PM domain, but
      unfortunately it's also abuses genpd's "internal" suspend_power_off flag
      to deal with a corner case at system PM resume.
      
      More precisely, the so called SMU block powers on the ACP at system PM
      resume, unconditionally if it's being used or not. This may lead to that
      genpd's internal status of the power state, may not correctly reflect the
      power state of the HW after a system PM resume.
      
      Because of changing the behaviour of genpd, by runtime resuming devices in
      the prepare phase, the AMD ACP drm driver no longer have to deal with this
      corner case. So let's just drop the related code in this driver.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NKevin Hilman <khilman@baylibre.com>
      Acked-by: NMaruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      39dd0f23
  15. 22 4月, 2016 2 次提交
  16. 16 2月, 2016 2 次提交
    • A
      PM / Domains: remove old power on/off latencies · 90e63452
      Axel Haslam 提交于
      Now that all known users have been converted to use state latencies,
      we can remove the latency field in the generic_pm_domain structure.
      Signed-off-by: NAxel Haslam <ahaslam+renesas@baylibre.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      90e63452
    • A
      PM / Domains: Support for multiple states · fc5cbf0c
      Axel Haslam 提交于
      Some hardware (eg. OMAP), has the ability to enter different low power
      modes for a given power domain. This allows for more fine grained control
      over the power state of the platform. As a typical example, some registers
      of the hardware may be implemented with retention flip-flops and be able
      to retain their state at lower voltages allowing for faster on/off
      latencies and an increased window of opportunity to enter an intermediate
      low power state other than "off"
      
      When trying to set a power domain to off, the genpd governor will choose
      the deepest state that will respect the qos constraints of all the devices
      and sub-domains on the power domain. The state chosen by the governor is
      saved in the "state_idx" field of the generic_pm_domain structure and
      shall be used by the power_off and power_on callbacks to perform the
      necessary actions to set the power domain into (and out of) the state
      indicated by state_idx.
      
      States must be declared in ascending order from shallowest to deepest,
      deepest meaning the state which takes longer to enter and exit.
      
      For platforms that don't declare any states, a single a single "off"
      state is used. Once all platforms are converted to use the state array,
      the legacy on/off latencies will be removed.
      
      [ Lina: Modified genpd state initialization and remove use of
              save_state_latency_ns in genpd timing data ]
      Suggested-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NLina Iyer <lina.iyer@linaro.org>
      Signed-off-by: NAxel Haslam <ahaslam+renesas@baylibre.com>
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fc5cbf0c
  17. 08 1月, 2016 1 次提交
  18. 28 10月, 2015 1 次提交
  19. 13 10月, 2015 3 次提交
  20. 26 9月, 2015 2 次提交
  21. 29 8月, 2015 1 次提交
  22. 01 8月, 2015 1 次提交
    • U
      PM / Domains: Remove intermediate states from the power off sequence · ba2bbfbf
      Ulf Hansson 提交于
      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: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: NLina Iyer <lina.iyer@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ba2bbfbf
  23. 23 3月, 2015 1 次提交