You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
304 lines
14 KiB
304 lines
14 KiB
PSCI Power Domain Tree Structure
|
|
================================
|
|
|
|
Requirements
|
|
------------
|
|
|
|
#. A platform must export the ``plat_get_aff_count()`` and
|
|
``plat_get_aff_state()`` APIs to enable the generic PSCI code to
|
|
populate a tree that describes the hierarchy of power domains in the
|
|
system. This approach is inflexible because a change to the topology
|
|
requires a change in the code.
|
|
|
|
It would be much simpler for the platform to describe its power domain tree
|
|
in a data structure.
|
|
|
|
#. The generic PSCI code generates MPIDRs in order to populate the power domain
|
|
tree. It also uses an MPIDR to find a node in the tree. The assumption that
|
|
a platform will use exactly the same MPIDRs as generated by the generic PSCI
|
|
code is not scalable. The use of an MPIDR also restricts the number of
|
|
levels in the power domain tree to four.
|
|
|
|
Therefore, there is a need to decouple allocation of MPIDRs from the
|
|
mechanism used to populate the power domain topology tree.
|
|
|
|
#. The current arrangement of the power domain tree requires a binary search
|
|
over the sibling nodes at a particular level to find a specified power
|
|
domain node. During a power management operation, the tree is traversed from
|
|
a 'start' to an 'end' power level. The binary search is required to find the
|
|
node at each level. The natural way to perform this traversal is to
|
|
start from a leaf node and follow the parent node pointer to reach the end
|
|
level.
|
|
|
|
Therefore, there is a need to define data structures that implement the tree in
|
|
a way which facilitates such a traversal.
|
|
|
|
#. The attributes of a core power domain differ from the attributes of power
|
|
domains at higher levels. For example, only a core power domain can be identified
|
|
using an MPIDR. There is no requirement to perform state coordination while
|
|
performing a power management operation on the core power domain.
|
|
|
|
Therefore, there is a need to implement the tree in a way which facilitates this
|
|
distinction between a leaf and non-leaf node and any associated
|
|
optimizations.
|
|
|
|
--------------
|
|
|
|
Design
|
|
------
|
|
|
|
Describing a power domain tree
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fulfill requirement 1., the existing platform APIs
|
|
``plat_get_aff_count()`` and ``plat_get_aff_state()`` have been
|
|
removed. A platform must define an array of unsigned chars such that:
|
|
|
|
#. The first entry in the array specifies the number of power domains at the
|
|
highest power level implemented in the platform. This caters for platforms
|
|
where the power domain tree does not have a single root node, for example,
|
|
the FVP has two cluster power domains at the highest level (1).
|
|
|
|
#. Each subsequent entry corresponds to a power domain and contains the number
|
|
of power domains that are its direct children.
|
|
|
|
#. The size of the array minus the first entry will be equal to the number of
|
|
non-leaf power domains.
|
|
|
|
#. The value in each entry in the array is used to find the number of entries
|
|
to consider at the next level. The sum of the values (number of children) of
|
|
all the entries at a level specifies the number of entries in the array for
|
|
the next level.
|
|
|
|
The following example power domain topology tree will be used to describe the
|
|
above text further. The leaf and non-leaf nodes in this tree have been numbered
|
|
separately.
|
|
|
|
::
|
|
|
|
+-+
|
|
|0|
|
|
+-+
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
/ \
|
|
+-+ +-+
|
|
|1| |2|
|
|
+-+ +-+
|
|
/ \ / \
|
|
/ \ / \
|
|
/ \ / \
|
|
/ \ / \
|
|
+-+ +-+ +-+ +-+
|
|
|3| |4| |5| |6|
|
|
+-+ +-+ +-+ +-+
|
|
+---+-----+ +----+----| +----+----+ +----+-----+-----+
|
|
| | | | | | | | | | | | |
|
|
| | | | | | | | | | | | |
|
|
v v v v v v v v v v v v v
|
|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +--+ +--+ +--+
|
|
|0| |1| |2| |3| |4| |5| |6| |7| |8| |9| |10| |11| |12|
|
|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +--+ +--+ +--+
|
|
|
|
This tree is defined by the platform as the array described above as follows:
|
|
|
|
.. code:: c
|
|
|
|
#define PLAT_NUM_POWER_DOMAINS 20
|
|
#define PLATFORM_CORE_COUNT 13
|
|
#define PSCI_NUM_NON_CPU_PWR_DOMAINS \
|
|
(PLAT_NUM_POWER_DOMAINS - PLATFORM_CORE_COUNT)
|
|
|
|
unsigned char plat_power_domain_tree_desc[] = { 1, 2, 2, 2, 3, 3, 3, 4};
|
|
|
|
Removing assumptions about MPIDRs used in a platform
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fulfill requirement 2., it is assumed that the platform assigns a
|
|
unique number (core index) between ``0`` and ``PLAT_CORE_COUNT - 1`` to each core
|
|
power domain. MPIDRs could be allocated in any manner and will not be used to
|
|
populate the tree.
|
|
|
|
``plat_core_pos_by_mpidr(mpidr)`` will return the core index for the core
|
|
corresponding to the MPIDR. It will return an error (-1) if an MPIDR is passed
|
|
which is not allocated or corresponds to an absent core. The semantics of this
|
|
platform API have changed since it is required to validate the passed MPIDR. It
|
|
has been made a mandatory API as a result.
|
|
|
|
Another mandatory API, ``plat_my_core_pos()`` has been added to return the core
|
|
index for the calling core. This API provides a more lightweight mechanism to get
|
|
the index since there is no need to validate the MPIDR of the calling core.
|
|
|
|
The platform should assign the core indices (as illustrated in the diagram above)
|
|
such that, if the core nodes are numbered from left to right, then the index
|
|
for a core domain will be the same as the index returned by
|
|
``plat_core_pos_by_mpidr()`` or ``plat_my_core_pos()`` for that core. This
|
|
relationship allows the core nodes to be allocated in a separate array
|
|
(requirement 4.) during ``psci_setup()`` in such an order that the index of the
|
|
core in the array is the same as the return value from these APIs.
|
|
|
|
Dealing with holes in MPIDR allocation
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
For platforms where the number of allocated MPIDRs is equal to the number of
|
|
core power domains, for example, Juno and FVPs, the logic to convert an MPIDR to
|
|
a core index should remain unchanged. Both Juno and FVP use a simple collision
|
|
proof hash function to do this.
|
|
|
|
It is possible that on some platforms, the allocation of MPIDRs is not
|
|
contiguous or certain cores have been disabled. This essentially means that the
|
|
MPIDRs have been sparsely allocated, that is, the size of the range of MPIDRs
|
|
used by the platform is not equal to the number of core power domains.
|
|
|
|
The platform could adopt one of the following approaches to deal with this
|
|
scenario:
|
|
|
|
#. Implement more complex logic to convert a valid MPIDR to a core index while
|
|
maintaining the relationship described earlier. This means that the power
|
|
domain tree descriptor will not describe any core power domains which are
|
|
disabled or absent. Entries will not be allocated in the tree for these
|
|
domains.
|
|
|
|
#. Treat unallocated MPIDRs and disabled cores as absent but still describe them
|
|
in the power domain descriptor, that is, the number of core nodes described
|
|
is equal to the size of the range of MPIDRs allocated. This approach will
|
|
lead to memory wastage since entries will be allocated in the tree but will
|
|
allow use of a simpler logic to convert an MPIDR to a core index.
|
|
|
|
Traversing through and distinguishing between core and non-core power domains
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fulfill requirement 3 and 4, separate data structures have been defined
|
|
to represent leaf and non-leaf power domain nodes in the tree.
|
|
|
|
.. code:: c
|
|
|
|
/*******************************************************************************
|
|
* The following two data structures implement the power domain tree. The tree
|
|
* is used to track the state of all the nodes i.e. power domain instances
|
|
* described by the platform. The tree consists of nodes that describe CPU power
|
|
* domains i.e. leaf nodes and all other power domains which are parents of a
|
|
* CPU power domain i.e. non-leaf nodes.
|
|
******************************************************************************/
|
|
typedef struct non_cpu_pwr_domain_node {
|
|
/*
|
|
* Index of the first CPU power domain node level 0 which has this node
|
|
* as its parent.
|
|
*/
|
|
unsigned int cpu_start_idx;
|
|
|
|
/*
|
|
* Number of CPU power domains which are siblings of the domain indexed
|
|
* by 'cpu_start_idx' i.e. all the domains in the range 'cpu_start_idx
|
|
* -> cpu_start_idx + ncpus' have this node as their parent.
|
|
*/
|
|
unsigned int ncpus;
|
|
|
|
/* Index of the parent power domain node */
|
|
unsigned int parent_node;
|
|
|
|
-----
|
|
} non_cpu_pd_node_t;
|
|
|
|
typedef struct cpu_pwr_domain_node {
|
|
u_register_t mpidr;
|
|
|
|
/* Index of the parent power domain node */
|
|
unsigned int parent_node;
|
|
|
|
-----
|
|
} cpu_pd_node_t;
|
|
|
|
The power domain tree is implemented as a combination of the following data
|
|
structures.
|
|
|
|
.. code:: c
|
|
|
|
non_cpu_pd_node_t psci_non_cpu_pd_nodes[PSCI_NUM_NON_CPU_PWR_DOMAINS];
|
|
cpu_pd_node_t psci_cpu_pd_nodes[PLATFORM_CORE_COUNT];
|
|
|
|
Populating the power domain tree
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The ``populate_power_domain_tree()`` function in ``psci_setup.c`` implements the
|
|
algorithm to parse the power domain descriptor exported by the platform to
|
|
populate the two arrays. It is essentially a breadth-first-search. The nodes for
|
|
each level starting from the root are laid out one after another in the
|
|
``psci_non_cpu_pd_nodes`` and ``psci_cpu_pd_nodes`` arrays as follows:
|
|
|
|
::
|
|
|
|
psci_non_cpu_pd_nodes -> [[Level 3 nodes][Level 2 nodes][Level 1 nodes]]
|
|
psci_cpu_pd_nodes -> [Level 0 nodes]
|
|
|
|
For the example power domain tree illustrated above, the ``psci_cpu_pd_nodes``
|
|
will be populated as follows. The value in each entry is the index of the parent
|
|
node. Other fields have been ignored for simplicity.
|
|
|
|
::
|
|
|
|
+-------------+ ^
|
|
CPU0 | 3 | |
|
|
+-------------+ |
|
|
CPU1 | 3 | |
|
|
+-------------+ |
|
|
CPU2 | 3 | |
|
|
+-------------+ |
|
|
CPU3 | 4 | |
|
|
+-------------+ |
|
|
CPU4 | 4 | |
|
|
+-------------+ |
|
|
CPU5 | 4 | | PLATFORM_CORE_COUNT
|
|
+-------------+ |
|
|
CPU6 | 5 | |
|
|
+-------------+ |
|
|
CPU7 | 5 | |
|
|
+-------------+ |
|
|
CPU8 | 5 | |
|
|
+-------------+ |
|
|
CPU9 | 6 | |
|
|
+-------------+ |
|
|
CPU10 | 6 | |
|
|
+-------------+ |
|
|
CPU11 | 6 | |
|
|
+-------------+ |
|
|
CPU12 | 6 | v
|
|
+-------------+
|
|
|
|
The ``psci_non_cpu_pd_nodes`` array will be populated as follows. The value in
|
|
each entry is the index of the parent node.
|
|
|
|
::
|
|
|
|
+-------------+ ^
|
|
PD0 | -1 | |
|
|
+-------------+ |
|
|
PD1 | 0 | |
|
|
+-------------+ |
|
|
PD2 | 0 | |
|
|
+-------------+ |
|
|
PD3 | 1 | | PLAT_NUM_POWER_DOMAINS -
|
|
+-------------+ | PLATFORM_CORE_COUNT
|
|
PD4 | 1 | |
|
|
+-------------+ |
|
|
PD5 | 2 | |
|
|
+-------------+ |
|
|
PD6 | 2 | |
|
|
+-------------+ v
|
|
|
|
Each core can find its node in the ``psci_cpu_pd_nodes`` array using the
|
|
``plat_my_core_pos()`` function. When a core is turned on, the normal world
|
|
provides an MPIDR. The ``plat_core_pos_by_mpidr()`` function is used to validate
|
|
the MPIDR before using it to find the corresponding core node. The non-core power
|
|
domain nodes do not need to be identified.
|
|
|
|
--------------
|
|
|
|
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
|
|
|