Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux

* Temperature Sensor on hisilicon SoCs

** Required properties :

- compatible: "hisilicon,tsensor".

- reg: physical base address of thermal sensor and length of memory mapped

  region.

- interrupt: The interrupt number to the cpu. Defines the interrupt used

  by /SOCTHERM/tsensor.

- clock-names: Input clock name, should be 'thermal_clk'.

- clocks: phandles for clock specified in "clock-names" property.

- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.

Example :

	tsensor: tsensor@0,f7030700 {

		compatible = "hisilicon,tsensor";

		reg = <0x0 0xf7030700 0x0 0x1000>;

		interrupts = <0 7 0x4>;

		clocks = <&sys_ctrl HI6220_TSENSOR_CLK>;

		clock-names = "thermal_clk";

		#thermal-sensor-cells = <1>;

	}

Qualcomm QPNP PMIC Temperature Alarm

QPNP temperature alarm peripherals are found inside of Qualcomm PMIC chips

that utilize the Qualcomm SPMI implementation. These peripherals provide an

interrupt signal and status register to identify high PMIC die temperature.

Required properties:

- compatible:      Should contain "qcom,spmi-temp-alarm".

- reg:             Specifies the SPMI address and length of the controller's

                   registers.

- interrupts:      PMIC temperature alarm interrupt.

- #thermal-sensor-cells: Should be 0. See thermal.txt for a description.

Optional properties:

- io-channels:     Should contain IIO channel specifier for the ADC channel,

                   which report chip die temperature.

- io-channel-names: Should contain "thermal".

Example:

	pm8941_temp: thermal-alarm@2400 {

		compatible = "qcom,spmi-temp-alarm";

		reg = <0x2400 0x100>;

		interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;

		#thermal-sensor-cells = <0>;

		io-channels = <&pm8941_vadc VADC_DIE_TEMP>;

		io-channel-names = "thermal";

	};

	thermal-zones {

		pm8941 {

			polling-delay-passive = <250>;

			polling-delay = <1000>;

			thermal-sensors = <&pm8941_temp>;

			trips {

				passive {

					temperature = <1050000>;

					hysteresis = <2000>;

					type = "passive";

				};

				alert {

					temperature = <125000>;

					hysteresis = <2000>;

					type = "hot";

				};

				crit {

					temperature = <145000>;

					hysteresis = <2000>;

					type = "critical";

				};

			};

		};

	};

			by means of sensor ID. Additional coefficients are

			interpreted as constant offset.

- sustainable-power:	An estimate of the sustainable power (in mW) that the

  Type: unsigned	thermal zone can dissipate at the desired

  Size: one cell	control temperature.  For reference, the

			sustainable power of a 4'' phone is typically

			2000mW, while on a 10'' tablet is around

			4500mW.

Note: The delay properties are bound to the maximum dT/dt (temperature

derivative over time) in two situations for a thermal zone:

(i)  - when passive cooling is activated (polling-delay-passive); and

		 */

		coefficients =		<1200	-345	890>;

		sustainable-power = <2500>;

		trips {

			/* Trips are based on resulting linear equation */

			cpu_trip: cpu-trip {

    np: pointer to the cooling device device tree node

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

1.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

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.

1.1.5 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)

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

    cdev: Cooling device pointer which has to be unregistered.

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

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:

- The time the processor spends running, consuming dynamic power, as

  compared to the time in idle states where dynamic consumption is

  negligible.  Herein we refer to this as 'utilisation'.

- The voltage and frequency levels as a result of DVFS.  The DVFS

  level is a dominant factor governing power consumption.

- In running time the 'execution' behaviour (instruction types, memory

  access patterns and so forth) causes, in most cases, a second order

  variation.  In pathological cases this variation can be significant,

  but typically it is of a much lesser impact than the factors above.

A high level dynamic power consumption model may then be represented as:

Pdyn = f(run) * Voltage^2 * Frequency * Utilisation

f(run) here represents the described execution behaviour and its

result has a units of Watts/Hz/Volt^2 (this often expressed in

mW/MHz/uVolt^2)

The detailed behaviour for f(run) could be modelled on-line.  However,

in practice, such an on-line model has dependencies on a number of

implementation specific processor support and characterisation

factors.  Therefore, in initial implementation that contribution is

represented as a constant coefficient.  This is a simplification

consistent with the relative contribution to overall power variation.

In this simplified representation our model becomes:

Pdyn = Capacitance * Voltage^2 * Frequency * Utilisation

Where `capacitance` is a constant that represents an indicative

running time dynamic power coefficient in fundamental units of

mW/MHz/uVolt^2.  Typical values for mobile CPUs might lie in range

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.

Power allocator governor tunables

=================================

Trip points

-----------

The governor requires the following two passive trip points:

1.  "switch on" trip point: temperature above which the governor

    control loop starts operating.  This is the first passive trip

    point of the thermal zone.

2.  "desired temperature" trip point: it should be higher than the

    "switch on" trip point.  This the target temperature the governor

    is controlling for.  This is the last passive trip point of the

    thermal zone.

PID Controller

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

The power allocator governor implements a

Proportional-Integral-Derivative controller (PID controller) with

temperature as the control input and power as the controlled output:

    P_max = k_p * e + k_i * err_integral + k_d * diff_err + sustainable_power

where

    e = desired_temperature - current_temperature

    err_integral is the sum of previous errors

    diff_err = e - previous_error

It is similar to the one depicted below:

                                      k_d

                                       |

current_temp                           |

     |                                 v

     |                +----------+   +---+

     |         +----->| diff_err |-->| X |------+

     |         |      +----------+   +---+      |

     |         |                                |      tdp        actor

     |         |                      k_i       |       |  get_requested_power()

     |         |                       |        |       |        |     |

     |         |                       |        |       |        |     | ...

     v         |                       v        v       v        v     v

   +---+       |      +-------+      +---+    +---+   +---+   +----------+

   | S |-------+----->| sum e |----->| X |--->| S |-->| S |-->|power     |

   +---+       |      +-------+      +---+    +---+   +---+   |allocation|

     ^         |                                ^             +----------+

     |         |                                |                |     |

     |         |        +---+                   |                |     |

     |         +------->| X |-------------------+                v     v

     |                  +---+                               granted performance

desired_temperature       ^

                          |

                          |

                      k_po/k_pu

Sustainable power

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

An estimate of the sustainable dissipatable power (in mW) should be

provided while registering the thermal zone.  This estimates the

sustained power that can be dissipated at the desired control

temperature.  This is the maximum sustained power for allocation at

the desired maximum temperature.  The actual sustained power can vary

for a number of reasons.  The closed loop controller will take care of

variations such as environmental conditions, and some factors related

to the speed-grade of the silicon.  `sustainable_power` is therefore

simply an estimate, and may be tuned to affect the aggressiveness of

the thermal ramp. For reference, the sustainable power of a 4" phone

is typically 2000mW, while on a 10" tablet is around 4500mW (may vary

depending on screen size).

If you are using device tree, do add it as a property of the

thermal-zone.  For example:

	thermal-zones {

		soc_thermal {

			polling-delay = <1000>;

			polling-delay-passive = <100>;

			sustainable-power = <2500>;

			...

Instead, if the thermal zone is registered from the platform code, pass a

`thermal_zone_params` that has a `sustainable_power`.  If no

`thermal_zone_params` were being passed, then something like below

will suffice:

	static const struct thermal_zone_params tz_params = {

		.sustainable_power = 3500,

	};

and then pass `tz_params` as the 5th parameter to

`thermal_zone_device_register()`

k_po and k_pu

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

The implementation of the PID controller in the power allocator

thermal governor allows the configuration of two proportional term

constants: `k_po` and `k_pu`.  `k_po` is the proportional term

constant during temperature overshoot periods (current temperature is

above "desired temperature" trip point).  Conversely, `k_pu` is the

proportional term constant during temperature undershoot periods

(current temperature below "desired temperature" trip point).

These controls are intended as the primary mechanism for configuring

the permitted thermal "ramp" of the system.  For instance, a lower

`k_pu` value will provide a slower ramp, at the cost of capping

available capacity at a low temperature.  On the other hand, a high

value of `k_pu` will result in the governor granting very high power

whilst temperature is low, and may lead to temperature overshooting.

The default value for `k_pu` is:

    2 * sustainable_power / (desired_temperature - switch_on_temp)

This means that at `switch_on_temp` the output of the controller's

proportional term will be 2 * `sustainable_power`.  The default value

for `k_po` is:

    sustainable_power / (desired_temperature - switch_on_temp)

Focusing on the proportional and feed forward values of the PID

controller equation we have:

    P_max = k_p * e + sustainable_power

The proportional term is proportional to the difference between the

desired temperature and the current one.  When the current temperature

is the desired one, then the proportional component is zero and

`P_max` = `sustainable_power`.  That is, the system should operate in

thermal equilibrium under constant load.  `sustainable_power` is only

an estimate, which is the reason for closed-loop control such as this.

Expanding `k_pu` we get:

    P_max = 2 * sustainable_power * (T_set - T) / (T_set - T_on) +

        sustainable_power

where

    T_set is the desired temperature

    T is the current temperature

    T_on is the switch on temperature

When the current temperature is the switch_on temperature, the above

formula becomes:

    P_max = 2 * sustainable_power * (T_set - T_on) / (T_set - T_on) +

        sustainable_power = 2 * sustainable_power + sustainable_power =

        3 * sustainable_power

Therefore, the proportional term alone linearly decreases power from

3 * `sustainable_power` to `sustainable_power` as the temperature

rises from the switch on temperature to the desired temperature.

k_i and integral_cutoff

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

`k_i` configures the PID loop's integral term constant.  This term

allows the PID controller to compensate for long term drift and for

the quantized nature of the output control: cooling devices can't set

the exact power that the governor requests.  When the temperature

error is below `integral_cutoff`, errors are accumulated in the

integral term.  This term is then multiplied by `k_i` and the result

added to the output of the controller.  Typically `k_i` is set low (1

or 2) and `integral_cutoff` is 0.

k_d

---

`k_d` configures the PID loop's derivative term constant.  It's

recommended to leave it as the default: 0.

Cooling device power API

========================

Cooling devices controlled by this governor must supply the additional

"power" API in their `cooling_device_ops`.  It consists on three ops:

1. int get_requested_power(struct thermal_cooling_device *cdev,

	struct thermal_zone_device *tz, u32 *power);

@cdev: The `struct thermal_cooling_device` pointer

@tz: thermal zone in which we are currently operating

@power: pointer in which to store the calculated power

`get_requested_power()` calculates the power requested by the device

in milliwatts and stores it in @power .  It should return 0 on

success, -E* on failure.  This is currently used by the power

allocator governor to calculate how much power to give to each cooling

device.

2. int state2power(struct thermal_cooling_device *cdev, struct

        thermal_zone_device *tz, unsigned long state, u32 *power);

@cdev: The `struct thermal_cooling_device` pointer

@tz: thermal zone in which we are currently operating

@state: A cooling device state

@power: pointer in which to store the equivalent power

Convert cooling device state @state into power consumption in

milliwatts and store it in @power.  It should return 0 on success, -E*

on failure.  This is currently used by thermal core to calculate the

maximum power that an actor can consume.

3. int power2state(struct thermal_cooling_device *cdev, u32 power,

	unsigned long *state);

@cdev: The `struct thermal_cooling_device` pointer

@power: power in milliwatts

@state: pointer in which to store the resulting state

Calculate a cooling device state that would make the device consume at

most @power mW and store it in @state.  It should return 0 on success,

-E* on failure.  This is currently used by the thermal core to convert

a given power set by the power allocator governor to a state that the

cooling device can set.  It is a function because this conversion may

depend on external factors that may change so this function should the

best conversion given "current circumstances".

Cooling device weights

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

Weights are a mechanism to bias the allocation among cooling

devices.  They express the relative power efficiency of different

cooling devices.  Higher weight can be used to express higher power

efficiency.  Weighting is relative such that if each cooling device

has a weight of one they are considered equal.  This is particularly

useful in heterogeneous systems where two cooling devices may perform

the same kind of compute, but with different efficiency.  For example,

a system with two different types of processors.

If the thermal zone is registered using

`thermal_zone_device_register()` (i.e., platform code), then weights

are passed as part of the thermal zone's `thermal_bind_parameters`.

If the platform is registered using device tree, then they are passed

as the `contribution` property of each map in the `cooling-maps` node.

Limitations of the power allocator governor

===========================================

The power allocator governor's PID controller works best if there is a

periodic tick.  If you have a driver that calls

`thermal_zone_device_update()` (or anything that ends up calling the

governor's `throttle()` function) repetitively, the governor response

won't be very good.  Note that this is not particular to this

governor, step-wise will also misbehave if you call its throttle()

faster than the normal thermal framework tick (due to interrupts for

example) as it will overreact.