Lines Matching refs:the
15 #. A platform must export the ``plat_get_aff_count()`` and
16 ``plat_get_aff_state()`` APIs to enable the generic PSCI code to
17 populate a tree that describes the hierarchy of power domains in the
18 system. This approach is inflexible because a change to the topology
19 requires a change in the code.
21 It would be much simpler for the platform to describe its power domain tree
24 #. The generic PSCI code generates MPIDRs in order to populate the power domain
25 tree. It also uses an MPIDR to find a node in the tree. The assumption that
26 a platform will use exactly the same MPIDRs as generated by the generic PSCI
27 code is not scalable. The use of an MPIDR also restricts the number of
28 levels in the power domain tree to four.
30 Therefore, there is a need to decouple allocation of MPIDRs from the
31 mechanism used to populate the power domain topology tree.
33 #. The current arrangement of the power domain tree requires a binary search
34 over the sibling nodes at a particular level to find a specified power
35 domain node. During a power management operation, the tree is traversed from
36 a 'start' to an 'end' power level. The binary search is required to find the
38 start from a leaf node and follow the parent node pointer to reach the end
41 Therefore, there is a need to define data structures that implement the tree in
44 #. The attributes of a core power domain differ from the attributes of power
47 performing a power management operation on the core power domain.
49 Therefore, there is a need to implement the tree in a way which facilitates this
61 To fulfill requirement 1., the existing platform APIs
65 #. The first entry in the array specifies the number of power domains at the
66 highest power level implemented in the platform. This caters for platforms
67 where the power domain tree does not have a single root node, for example,
68 the FVP has two cluster power domains at the highest level (1).
70 #. Each subsequent entry corresponds to a power domain and contains the number
73 #. The size of the array minus the first entry will be equal to the number of
76 #. The value in each entry in the array is used to find the number of entries
77 to consider at the next level. The sum of the values (number of children) of
78 all the entries at a level specifies the number of entries in the array for
79 the next level.
81 The following example power domain topology tree will be used to describe the
118 This tree is defined by the platform as the array described above as follows:
132 To fulfill requirement 2., it is assumed that the platform assigns a
135 populate the tree.
137 ``plat_core_pos_by_mpidr(mpidr)`` will return the core index for the core
138 corresponding to the MPIDR. It will return an error (-1) if an MPIDR is passed
140 platform API have changed since it is required to validate the passed MPIDR. It
143 Another mandatory API, ``plat_my_core_pos()`` has been added to return the core
144 index for the calling core. This API provides a more lightweight mechanism to get
145 the index since there is no need to validate the MPIDR of the calling core.
147 The platform should assign the core indices (as illustrated in the diagram above)
148 such that, if the core nodes are numbered from left to right, then the index
149 for a core domain will be the same as the index returned by
151 relationship allows the core nodes to be allocated in a separate array
152 (requirement 4.) during ``psci_setup()`` in such an order that the index of the
153 core in the array is the same as the return value from these APIs.
158 For platforms where the number of allocated MPIDRs is equal to the number of
159 core power domains, for example, Juno and FVPs, the logic to convert an MPIDR to
163 It is possible that on some platforms, the allocation of MPIDRs is not
164 contiguous or certain cores have been disabled. This essentially means that the
165 MPIDRs have been sparsely allocated, that is, the size of the range of MPIDRs
166 used by the platform is not equal to the number of core power domains.
168 The platform could adopt one of the following approaches to deal with this
172 maintaining the relationship described earlier. This means that the power
174 disabled or absent. Entries will not be allocated in the tree for these
178 in the power domain descriptor, that is, the number of core nodes described
179 is equal to the size of the range of MPIDRs allocated. This approach will
180 lead to memory wastage since entries will be allocated in the tree but will
187 to represent leaf and non-leaf power domain nodes in the tree.
192 * The following two data structures implement the power domain tree. The tree
193 * is used to track the state of all the nodes i.e. power domain instances
194 * described by the platform. The tree consists of nodes that describe CPU power
200 * Index of the first CPU power domain node level 0 which has this node
206 * Number of CPU power domains which are siblings of the domain indexed
207 * by 'cpu_start_idx' i.e. all the domains in the range 'cpu_start_idx
212 /* Index of the parent power domain node */
221 /* Index of the parent power domain node */
227 The power domain tree is implemented as a combination of the following data
235 Populating the power domain tree
238 The ``populate_power_domain_tree()`` function in ``psci_setup.c`` implements the
239 algorithm to parse the power domain descriptor exported by the platform to
240 populate the two arrays. It is essentially a breadth-first-search. The nodes for
241 each level starting from the root are laid out one after another in the
249 For the example power domain tree illustrated above, the ``psci_cpu_pd_nodes``
250 will be populated as follows. The value in each entry is the index of the parent
284 each entry is the index of the parent node.
304 Each core can find its node in the ``psci_cpu_pd_nodes`` array using the
305 ``plat_my_core_pos()`` function. When a core is turned on, the normal world
307 the MPIDR before using it to find the corresponding core node. The non-core power