kernel/Documentation/devicetree/bindings/opp, branch linux-5.1.y

dt-bindings: opp: Introduce opp-level bindings

2019-01-22T21:06:11Z

Add opp-level as an additional property in the OPP node to describe the performance level of the device. On some SoCs (especially from Qualcomm and MediaTek) this value is communicated to a remote microprocessor by the CPU, which then takes some actions (like adjusting voltage values across various rails) based on the value passed. Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson Reviewed-by: Rob Herring Acked-by: Viresh Kumar Signed-off-by: Rajendra Nayak Signed-off-by: Bjorn Andersson Signed-off-by: Andy Gross

Merge branch 'pm-cpufreq'

2018-06-04T08:40:57Z

* pm-cpufreq: (25 commits) dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu cpufreq: Add Kryo CPU scaling driver cpufreq: Use static SRCU initializer kernel/SRCU: provide a static initializer cpufreq: Fix new policy initialization during limits updates via sysfs cpufreq: tegra20: Wrap cpufreq into platform driver cpufreq: tegra20: Allow cpufreq driver to be built as loadable module cpufreq: tegra20: Check if this is Tegra20 machine cpufreq: tegra20: Remove unneeded variable initialization cpufreq: tegra20: Remove unnecessary parentheses cpufreq: tegra20: Remove unneeded check in tegra_cpu_init cpufreq: tegra20: Release clocks properly cpufreq: tegra20: Remove EMC clock usage cpufreq: tegra20: Clean up included headers cpufreq: tegra20: Clean up whitespaces in the code cpufreq: tegra20: Change module description Revert "cpufreq: rcar: Add support for R8A7795 SoC" Revert "cpufreq: dt: Add r8a7796 support to to use generic cpufreq driver" cpufreq: intel_pstate: allow trace in passive mode cpufreq: optimize cpufreq_notify_transition() ...

dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu

2018-05-30T10:53:11Z

The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC to provide the OPP framework with required information. This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. This change adds documentation for the DT bindings. The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2" with following parameters: - nvmem-cells (NVMEM area containig the speedbin information) - opp-supported-hw: A single 32 bit bitmap value, representing compatible HW: 0: MSM8996 V3, speedbin 0 1: MSM8996 V3, speedbin 1 2: MSM8996 V3, speedbin 2 3: unused 4: MSM8996 SG, speedbin 0 5: MSM8996 SG, speedbin 1 6: MSM8996 SG, speedbin 2 7-31: unused Signed-off-by: Ilia Lin Reviewed-by: Rob Herring Reviewed-by: Amit Kucheria Tested-by: Amit Kucheria Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

PM / OPP: dt-bindings: Make "opp-hz" optional for power domains

2018-05-09T04:44:56Z

The "opp-hz" property is not relevant across all the devices that use the OPP tables now. For example, for a power domain a frequency value wouldn't mean anything. Though they must have another property, which may be implementation defined, which uniquely identifies the OPP nodes. Make "opp-hz" optional for such devices. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson Reviewed-by: Rob Herring

PM / OPP: dt-bindings: Rename "required-opp" as "required-opps"

2018-05-08T04:58:49Z

This property can contain more than one phandle and it must be named "required-opps" instead. Suggested-by: Stephen Boyd Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson Reviewed-by: Rob Herring

Merge branches 'pm-opp', 'pm-devfreq', 'pm-avs' and 'pm-tools'

2018-01-18T01:56:04Z

* pm-opp: OPP: Introduce "required-opp" property OPP: Allow OPP table to be used for power-domains * pm-devfreq: PM / devfreq: Fix potential NULL pointer dereference in governor_store PM / devfreq: Propagate error from devfreq_add_device() * pm-avs: PM / AVS: rockchip-io: account for const type of of_device_id.data * pm-tools: tools/power/x86/intel_pstate_tracer: Free the trace buffer memory cpupower: Remove FSF address

OPP: Introduce "required-opp" property

2017-12-22T05:16:18Z

Devices have inter-dependencies some times. For example a device that needs to run at 800 MHz, needs another device (e.g. Its power domain) to be configured at a particular operating performance point. This patch introduces a new property "required-opp" which can be present directly in a device's node (if it doesn't need to change its OPPs), or in device's OPP nodes. More details on the property can be seen in the binding itself. Reviewed-by: Ulf Hansson Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar

OPP: Allow OPP table to be used for power-domains

2017-12-22T05:16:16Z

Power-domains can also have their active states and this patch enhances the OPP binding to define those. The power domains can use the OPP bindings as is, with one additional change to Allow "operating-points-v2" property to contain multiple phandles for power domain providers providing multiple domains. Reviewed-by: Ulf Hansson Reviewed-by: Rob Herring Signed-off-by: Viresh Kumar

dt-bindings: opp: Introduce ti-opp-supply bindings

2017-12-17T18:17:44Z

Document the devicetree bindings that describe Texas Instruments opp-supply which allow a platform to describe multiple regulators and additional information, such as registers containing data needed to program aforementioned regulators. Signed-off-by: Dave Gerlach Acked-by: Viresh Kumar Acked-by: Rob Herring Signed-off-by: Rafael J. Wysocki

dt-bindings: Remove "status" from examples

2017-09-05T15:03:06Z

Pretty much any node can have a status property, so it doesn't need to be in examples. Converted with the following command and removed examples with SoC and board specific splits: git grep -l -E 'status.*=.*' Documentation/devicetree/ | xargs sed -i -E '/\sstatus.*=.*"(disabled|ok|okay)/d' Acked-by: Mark Rutland Signed-off-by: Rob Herring