Merge branch 'android-4.14-eas-integration' into experimental-android-4.14

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

Energy cost bindings for Energy Aware Scheduling

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

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

1 - Introduction

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

This note specifies bindings required for energy-aware scheduling

(EAS)[1]. Historically, the scheduler's primary objective has been

performance.  EAS aims to provide an alternative objective - energy

efficiency. EAS relies on a simple platform energy cost model to

guide scheduling decisions.  The model only considers the CPU

subsystem.

This note is aligned with the definition of the layout of physical

CPUs in the system as described in the ARM topology binding

description [2]. The concept is applicable to any system so long as

the cost model data is provided for those processing elements in

that system's topology that EAS is required to service.

Processing elements refer to hardware threads, CPUs and clusters of

related CPUs in increasing order of hierarchy.

EAS requires two key cost metrics - busy costs and idle costs. Busy

costs comprise of a list of compute capacities for the processing

element in question and the corresponding power consumption at that

capacity.  Idle costs comprise of a list of power consumption values

for each idle state [C-state] that the processing element supports.

For a detailed description of these metrics, their derivation and

their use see [3].

These cost metrics are required for processing elements in all

scheduling domain levels that EAS is required to service.

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

2 - energy-costs node

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

Energy costs for the processing elements in scheduling domains that

EAS is required to service are defined in the energy-costs node

which acts as a container for the actual per processing element cost

nodes. A single energy-costs node is required for a given system.

- energy-costs node

	Usage: Required

	Description: The energy-costs node is a container node and

	it's sub-nodes describe costs for each processing element at

	all scheduling domain levels that EAS is required to

	service.

	Node name must be "energy-costs".

	The energy-costs node's parent node must be the cpus node.

	The energy-costs node's child nodes can be:

	- one or more cost nodes.

	Any other configuration is considered invalid.

The energy-costs node can only contain a single type of child node

whose bindings are described in paragraph 4.

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

3 - energy-costs node child nodes naming convention

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

energy-costs child nodes must follow a naming convention where the

node name must be "thread-costN", "core-costN", "cluster-costN"

depending on whether the costs in the node are for a thread, core or

cluster.  N (where N = {0, 1, ...}) is the node number and has no

bearing to the OS' logical thread, core or cluster index.

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

4 - cost node bindings

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

Bindings for cost nodes are defined as follows:

- system-cost node

	Description: Optional. Must be declared within an energy-costs

	node. A system should contain no more than one system-cost node.

	Systems with no modelled system cost should not provide this

	node.

	The system-cost node name must be "system-costN" as

	described in 3 above.

	A system-cost node must be a leaf node with no children.

	Properties for system-cost nodes are described in paragraph

	5 below.

	Any other configuration is considered invalid.

- cluster-cost node

	Description: must be declared within an energy-costs node. A

	system can contain multiple clusters and each cluster

	serviced by EAS	must have a corresponding cluster-costs

	node.

	The cluster-cost node name must be "cluster-costN" as

	described in 3 above.

	A cluster-cost node must be a leaf node with no children.

	Properties for cluster-cost nodes are described in paragraph

	5 below.

	Any other configuration is considered invalid.

- core-cost node

	Description: must be declared within an energy-costs node. A

	system can contain multiple cores and each core serviced by

	EAS must have a corresponding core-cost node.

	The core-cost node name must be "core-costN" as described in

	3 above.

	A core-cost node must be a leaf node with no children.

	Properties for core-cost nodes are described in paragraph

	5 below.

	Any other configuration is considered invalid.

- thread-cost node

	Description: must be declared within an energy-costs node. A

	system can contain cores with multiple hardware threads and

	each thread serviced by EAS must have a corresponding

	thread-cost node.

	The core-cost node name must be "core-costN" as described in

	3 above.

	A core-cost node must be a leaf node with no children.

	Properties for thread-cost nodes are described in paragraph

	5 below.

	Any other configuration is considered invalid.

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

5 - Cost node properties

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

All cost node types must have only the following properties:

- busy-cost-data

	Usage: required

	Value type: An array of 2-item tuples. Each item is of type

	u32.

	Definition: The first item in the tuple is the capacity

	value as described in [3]. The second item in the tuple is

	the energy cost value as described in [3].

- idle-cost-data

	Usage: required

	Value type: An array of 1-item tuples. The item is of type

	u32.

	Definition: The item in the tuple is the energy cost value

	as described in [3].

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

4 - Extensions to the cpu node

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

The cpu node is extended with a property that establishes the

connection between the processing element represented by the cpu

node and the cost-nodes associated with this processing element.

The connection is expressed in line with the topological hierarchy

that this processing element belongs to starting with the level in

the hierarchy that this processing element itself belongs to through

to the highest level that EAS is required to service.  The

connection cannot be sparse and must be contiguous from the

processing element's level through to the highest desired level. The

highest desired level must be the same for all processing elements.

Example: Given that a cpu node may represent a thread that is a part

of a core, this property may contain multiple elements which

associate the thread with cost nodes describing the costs for the

thread itself, the core the thread belongs to, the cluster the core

belongs to and so on. The elements must be ordered from the lowest

level nodes to the highest desired level that EAS must service. The

highest desired level must be the same for all cpu nodes. The

elements must not be sparse: there must be elements for the current

thread, the next level of hierarchy (core) and so on without any

'holes'.

Example: Given that a cpu node may represent a core that is a part

of a cluster of related cpus this property may contain multiple

elements which associate the core with cost nodes describing the

costs for the core itself, the cluster the core belongs to and so

on. The elements must be ordered from the lowest level nodes to the

highest desired level that EAS must service. The highest desired

level must be the same for all cpu nodes. The elements must not be

sparse: there must be elements for the current thread, the next

level of hierarchy (core) and so on without any 'holes'.

If the system comprises of hierarchical clusters of clusters, this

property will contain multiple associations with the relevant number

of cluster elements in hierarchical order.

Property added to the cpu node:

- sched-energy-costs

	Usage: required

	Value type: List of phandles

	Definition: a list of phandles to specific cost nodes in the

	energy-costs parent node that correspond to the processing

	element represented by this cpu node in hierarchical order

	of topology.

	The order of phandles in the list is significant. The first

	phandle is to the current processing element's own cost

	node.  Subsequent phandles are to higher hierarchical level

	cost nodes up until the maximum level that EAS is to

	service.

	All cpu nodes must have the same highest level cost node.

	The phandle list must not be sparsely populated with handles

	to non-contiguous hierarchical levels. See commentary above

	for clarity.

	Any other configuration is invalid.

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

5 - Example dts

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

Example 1 (ARM 64-bit, 6-cpu system, two clusters of cpus, one

cluster of 2 Cortex-A57 cpus, one cluster of 4 Cortex-A53 cpus):

cpus {

	#address-cells = <2>;

	#size-cells = <0>;

	.

	.

	.

	A57_0: cpu@0 {

		compatible = "arm,cortex-a57","arm,armv8";

		reg = <0x0 0x0>;

		device_type = "cpu";

		enable-method = "psci";

		next-level-cache = <&A57_L2>;

		clocks = <&scpi_dvfs 0>;

		cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;

		sched-energy-costs = <&CPU_COST_0 &CLUSTER_COST_0>;

	};

	A57_1: cpu@1 {

		compatible = "arm,cortex-a57","arm,armv8";

		reg = <0x0 0x1>;

		device_type = "cpu";

		enable-method = "psci";

		next-level-cache = <&A57_L2>;

		clocks = <&scpi_dvfs 0>;

		cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;

		sched-energy-costs = <&CPU_COST_0 &CLUSTER_COST_0>;

	};

	A53_0: cpu@100 {

		compatible = "arm,cortex-a53","arm,armv8";

		reg = <0x0 0x100>;

		device_type = "cpu";

		enable-method = "psci";

		next-level-cache = <&A53_L2>;

		clocks = <&scpi_dvfs 1>;

		cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;

		sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>;

	};

	A53_1: cpu@101 {

		compatible = "arm,cortex-a53","arm,armv8";

		reg = <0x0 0x101>;

		device_type = "cpu";

		enable-method = "psci";

		next-level-cache = <&A53_L2>;

		clocks = <&scpi_dvfs 1>;

		cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;

		sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>;

	};

	A53_2: cpu@102 {

		compatible = "arm,cortex-a53","arm,armv8";

		reg = <0x0 0x102>;

		device_type = "cpu";

		enable-method = "psci";

		next-level-cache = <&A53_L2>;

		clocks = <&scpi_dvfs 1>;

		cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;

		sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>;

	};

	A53_3: cpu@103 {

		compatible = "arm,cortex-a53","arm,armv8";

		reg = <0x0 0x103>;

		device_type = "cpu";

		enable-method = "psci";

		next-level-cache = <&A53_L2>;

		clocks = <&scpi_dvfs 1>;

		cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;

		sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>;

	};

	energy-costs {

		CPU_COST_0: core-cost0 {

			busy-cost-data = <

				417   168

				579   251

				744   359

				883   479

				1024  616

			>;

			idle-cost-data = <

				15

				0

			>;

		};

		CPU_COST_1: core-cost1 {

			busy-cost-data = <

				235 33

				302 46

				368 61

				406 76

				447 93

			>;

			idle-cost-data = <

				6

				0

			>;

		};

		CLUSTER_COST_0: cluster-cost0 {

			busy-cost-data = <

				417   24

				579   32

				744   43

				883   49

				1024  64

			>;

			idle-cost-data = <

				65

				24

			>;

		};

		CLUSTER_COST_1: cluster-cost1 {

			busy-cost-data = <

				235 26

				303 30

				368 39

				406 47

				447 57

			>;

			idle-cost-data = <

				56

				17

			>;

		};

	};

};

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

[1] https://lkml.org/lkml/2015/5/12/728

[2] Documentation/devicetree/bindings/topology.txt

[3] Documentation/scheduler/sched-energy.txt

			cci-control-port = <&cci_control1>;

			cpu-idle-states = <&CLUSTER_SLEEP_BIG>;

			capacity-dmips-mhz = <1024>;

			sched-energy-costs = <&CPU_COST_A15 &CLUSTER_COST_A15>;

		};

		cpu1: cpu@1 {

			cci-control-port = <&cci_control1>;

			cpu-idle-states = <&CLUSTER_SLEEP_BIG>;

			capacity-dmips-mhz = <1024>;

			sched-energy-costs = <&CPU_COST_A15 &CLUSTER_COST_A15>;

		};

		cpu2: cpu@2 {

			cci-control-port = <&cci_control2>;

			cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;

			capacity-dmips-mhz = <516>;

			sched-energy-costs = <&CPU_COST_A7 &CLUSTER_COST_A7>;

		};

		cpu3: cpu@3 {

			cci-control-port = <&cci_control2>;

			cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;

			capacity-dmips-mhz = <516>;

			sched-energy-costs = <&CPU_COST_A7 &CLUSTER_COST_A7>;

		};

		cpu4: cpu@4 {

			cci-control-port = <&cci_control2>;

			cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;

			capacity-dmips-mhz = <516>;

			sched-energy-costs = <&CPU_COST_A7 &CLUSTER_COST_A7>;

		};

		idle-states {

				min-residency-us = <2500>;

			};

		};

		energy-costs {

			CPU_COST_A15: core-cost0 {

				busy-cost-data = <

					426    2021

					512    2312

					597    2756

					682    3125

					768    3524

					853    3846

					938    5177

					1024   6997

				>;

				idle-cost-data = <

					0

					0

					0

				>;

			};

			CPU_COST_A7: core-cost1 {

				busy-cost-data = <

					150    187

					172    275

					215    334

					258    407

					301    447

					344    549

					387    761

					430    1024

				>;

				idle-cost-data = <

					0

					0

					0

				>;

			};

			CLUSTER_COST_A15: cluster-cost0 {

				busy-cost-data = <

					426    7920

					512    8165

					597    8172

					682    8195

					768    8265

					853    8446

					938    11426

					1024   15200

				>;

				idle-cost-data = <

					 70

					 70

					 25

				>;

			};

			CLUSTER_COST_A7: cluster-cost1 {

				busy-cost-data = <

					150    2967

					172    2792

					215    2810

					258    2815

					301    2919

					344    2847

					387    3917

					430    4905

				>;

				idle-cost-data = <

					25

					25

					10

				>;

			};

		};

	};

	memory@80000000 {

void store_cpu_topology(unsigned int cpuid);

const struct cpumask *cpu_coregroup_mask(int cpu);

#include <linux/arch_topology.h>

/* Replace task scheduler's default frequency-invariant accounting */

#define arch_scale_freq_capacity topology_get_freq_scale

/* Replace task scheduler's default cpu-invariant accounting */

#define arch_scale_cpu_capacity topology_get_cpu_scale

/* Enable topology flag updates */

#define arch_update_cpu_topology topology_update_cpu_topology

#else

static inline void init_cpu_topology(void) { }