Merge branch 'pm-cpufreq'

Example:

compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";

Power management

----------------

For power management (particularly DVFS and AVS), the North Bridge

Power Management component is needed:

Required properties:

- compatible     : should contain "marvell,armada-3700-nb-pm", "syscon";

- reg            : the register start and length for the North Bridge

		    Power Management

Example:

nb_pm: syscon@14000 {

	compatible = "marvell,armada-3700-nb-pm", "syscon";

	reg = <0x14000 0x60>;

}

Texas Instruments OMAP compatible OPP supply description

OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which

contain data that can be used to adjust voltages programmed for some of their

supplies for more efficient operation. This binding provides the information

needed to read these values and use them to program the main regulator during

an OPP transitions.

Also, some supplies may have an associated vbb-supply which is an Adaptive Body

Bias regulator which much be transitioned in a specific sequence with regards

to the vdd-supply and clk when making an OPP transition. By supplying two

regulators to the device that will undergo OPP transitions we can make use

of the multi regulator binding that is part of the OPP core described here [1]

to describe both regulators needed by the platform.

[1] Documentation/devicetree/bindings/opp/opp.txt

Required Properties for Device Node:

- vdd-supply: phandle to regulator controlling VDD supply

- vbb-supply: phandle to regulator controlling Body Bias supply

	      (Usually Adaptive Body Bias regulator)

Required Properties for opp-supply node:

- compatible: Should be one of:

	"ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB

	"ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD

			    along with VBB

	"ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD

			    but no VBB.

- reg: Address and length of the efuse register set for the device (mandatory

	only for "ti,omap5-opp-supply")

- ti,efuse-settings: An array of u32 tuple items providing information about

	optimized efuse configuration. Each item consists of the following:

	volt: voltage in uV - reference voltage (OPP voltage)

	efuse_offseet: efuse offset from reg where the optimized voltage is stored.

- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.

Example:

/* Device Node (CPU)  */

cpus {

	cpu0: cpu@0 {

		device_type = "cpu";

		...

		vdd-supply = <&vcc>;

		vbb-supply = <&abb_mpu>;

	};

};

/* OMAP OPP Supply with Class0 registers */

opp_supply_mpu: opp_supply@4a003b20 {

	compatible = "ti,omap5-opp-supply";

	reg = <0x4a003b20 0x8>;

	ti,efuse-settings = <

	/* uV   offset */

	1060000 0x0

	1160000 0x4

	1210000 0x8

	>;

	ti,absolute-max-voltage-uv = <1500000>;

};

   clip_cpus: cpumask of cpus where the frequency constraints will happen.

1.1.2 struct thermal_cooling_device *of_cpufreq_cooling_register(

	struct device_node *np, const struct cpumask *clip_cpus)

					struct cpufreq_policy *policy)

    This interface function registers the cpufreq cooling device with

    the name "thermal-cpufreq-%x" linking it with a device tree node, in

    order to bind it via the thermal DT code. This api can support multiple

    instances of cpufreq cooling devices.

    np: pointer to the cooling device device tree node

    clip_cpus: cpumask of cpus where the frequency constraints will happen.

1.1.3 struct thermal_cooling_device *cpufreq_power_cooling_register(

    const struct cpumask *clip_cpus, u32 capacitance,

    get_static_t plat_static_func)

Similar to cpufreq_cooling_register, this function registers a cpufreq

cooling device.  Using this function, the cooling device will

implement the power extensions by using a simple cpu power model.  The

cpus must have registered their OPPs using the OPP library.

The additional parameters are needed for the power model (See 2. Power

models).  "capacitance" is the dynamic power coefficient (See 2.1

Dynamic power).  "plat_static_func" is a function to calculate the

static power consumed by these cpus (See 2.2 Static power).

1.1.4 struct thermal_cooling_device *of_cpufreq_power_cooling_register(

    struct device_node *np, const struct cpumask *clip_cpus, u32 capacitance,

    get_static_t plat_static_func)

Similar to cpufreq_power_cooling_register, this function register a

cpufreq cooling device with power extensions using the device tree

information supplied by the np parameter.

    policy: CPUFreq policy.

1.1.5 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

1.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

    This interface function unregisters the "thermal-cpufreq-%x" cooling device.

2. Power models

The power API registration functions provide a simple power model for

CPUs.  The current power is calculated as dynamic + (optionally)

static power.  This power model requires that the operating-points of

CPUs.  The current power is calculated as dynamic power (static power isn't

supported currently).  This power model requires that the operating-points of

the CPUs are registered using the kernel's opp library and the

`cpufreq_frequency_table` is assigned to the `struct device` of the

cpu.  If you are using CONFIG_CPUFREQ_DT then the

`cpufreq_frequency_table` should already be assigned to the cpu

device.

The `plat_static_func` parameter of `cpufreq_power_cooling_register()`

and `of_cpufreq_power_cooling_register()` is optional.  If you don't

provide it, only dynamic power will be considered.

2.1 Dynamic power

The dynamic power consumption of a processor depends on many factors.

For a given processor implementation the primary factors are:

from 100 to 500.  For reference, the approximate values for the SoC in

ARM's Juno Development Platform are 530 for the Cortex-A57 cluster and

140 for the Cortex-A53 cluster.

2.2 Static power

Static leakage power consumption depends on a number of factors.  For a

given circuit implementation the primary factors are:

- Time the circuit spends in each 'power state'

- Temperature

- Operating voltage

- Process grade

The time the circuit spends in each 'power state' for a given

evaluation period at first order means OFF or ON.  However,

'retention' states can also be supported that reduce power during

inactive periods without loss of context.

Note: The visibility of state entries to the OS can vary, according to

platform specifics, and this can then impact the accuracy of a model

based on OS state information alone.  It might be possible in some

cases to extract more accurate information from system resources.

The temperature, operating voltage and process 'grade' (slow to fast)

of the circuit are all significant factors in static leakage power

consumption.  All of these have complex relationships to static power.

Circuit implementation specific factors include the chosen silicon

process as well as the type, number and size of transistors in both

the logic gates and any RAM elements included.

The static power consumption modelling must take into account the

power managed regions that are implemented.  Taking the example of an

ARM processor cluster, the modelling would take into account whether

each CPU can be powered OFF separately or if only a single power

region is implemented for the complete cluster.

In one view, there are others, a static power consumption model can

then start from a set of reference values for each power managed

region (e.g. CPU, Cluster/L2) in each state (e.g. ON, OFF) at an

arbitrary process grade, voltage and temperature point.  These values

are then scaled for all of the following: the time in each state, the

process grade, the current temperature and the operating voltage.

However, since both implementation specific and complex relationships

dominate the estimate, the appropriate interface to the model from the

cpu cooling device is to provide a function callback that calculates

the static power in this platform.  When registering the cpu cooling

device pass a function pointer that follows the `get_static_t`

prototype:

    int plat_get_static(cpumask_t *cpumask, int interval,

                        unsigned long voltage, u32 &power);

`cpumask` is the cpumask of the cpus involved in the calculation.

`voltage` is the voltage at which they are operating.  The function

should calculate the average static power for the last `interval`

milliseconds.  It returns 0 on success, -E* on error.  If it

succeeds, it should store the static power in `power`.  Reading the

temperature of the cpus described by `cpumask` is left for

plat_get_static() to do as the platform knows best which thermal

sensor is closest to the cpu.

If `plat_static_func` is NULL, static power is considered to be

negligible for this platform and only dynamic power is considered.

The platform specific callback can then use any combination of tables

and/or equations to permute the estimated value.  Process grade

information is not passed to the model since access to such data, from

on-chip measurement capability or manufacture time data, is platform

specific.

Note: the significance of static power for CPUs in comparison to

dynamic power is highly dependent on implementation.  Given the

potential complexity in implementation, the importance and accuracy of

its inclusion when using cpu cooling devices should be assessed on a

case by case basis.

F:	arch/arm/configs/mvebu_*_defconfig

F:	arch/arm/mach-mvebu/

F:	arch/arm64/boot/dts/marvell/armada*

F:	drivers/cpufreq/armada-37xx-cpufreq.c

F:	drivers/cpufreq/mvebu-cpufreq.c

F:	drivers/irqchip/irq-armada-370-xp.c

F:	drivers/irqchip/irq-mvebu-*

			clock-latency = <61036>; /* two CLK32 periods */

			operating-points = <

				/* kHz	uV */

				696000	1275000

				528000	1175000

				396000	1025000

				198000	950000

			>;

			fsl,soc-operating-points = <

				/* KHz	uV */

				696000	1275000

				528000	1175000

				396000	1175000

				198000	1175000