linux-kernel - [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2016 16:26:17 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rafael Wysocki <rjw@...ysocki.net>
Cc:     linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>,
        Nishanth Menon <nm@...com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Kevin Hilman <khilman@...libre.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Lina Iyer <lina.iyer@...aro.org>, devicetree@...r.kernel.org,
        Nayak Rajendra <rnayak@...eaurora.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

Hello,

Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.

We had some discussions about it in the past on the PM list [1], which is
followed by discussions during the LPC. The outcome of all that was that we
should extend Power Domain framework to support active state power management
as well.

The power-domains until now were only concentrating on the idle state
management of the device and this needs to change in order to reuse the
infrastructure of power domains for active state management.

To get a complete picture of the proposed plan, following is what we
need to do:
- Create DT bindings to get domain performance state information for the
  platforms.
- Enhance OPP framework to parse these and call into the PM Qos
  framework with a performance state request.
- Enhance PM Qos framework to provide the API to be used by consumers
  (or OPP framework) and pass it on to the (Generic) Power Domain
  framework.
- Enhance Generic Power Domain framework to accept such requests,
  accumulate all belonging to a single power domain and call domain
  driver specific callback with the performance state we want for the
  domain.
- The domain driver shall then, in a platform specific way, set the
  requested performance level.
- Note that these features are applicable to the CPU, GPU and other IIO
  or non-IIO devices.
- There can be cases where a device can choose between multiple power
  domains based on what performance level we want for the device. In
  such cases, we should represent the multiplexer with a separate power
  domain. In effect, the device (or OPP table) will correspond to a
  single power domain, but the backend driver of that domain shall
  implement the multiplexing functionality.

This patchset implements the very first part of this chain and
introduces a new optional property for the consumers of the
power-domains: domain-performance-state. This property can be used
directly by the consumer or its OPP table.

V1->V2:
- The performance states get their own nodes as they can have multiple
  values.
- Allow optional property domain-microvolt for the performance states

--
viresh

[1] https://marc.info/?l=linux-pm&m=147747923708075&w=2

Viresh Kumar (2):
  PM / Domains: Introduce domain-performance-states binding
  PM / OPP: Introduce domain-performance-state binding to OPP nodes

 Documentation/devicetree/bindings/opp/opp.txt      | 59 ++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     | 69 ++++++++++++++++++++++
 2 files changed, 128 insertions(+)

-- 
2.7.1.410.g6faf27b