aboutsummaryrefslogtreecommitdiff
path: root/lib/psci/psci_setup.c
diff options
context:
space:
mode:
authorSoby Mathew <soby.mathew@arm.com>2016-04-29 19:01:30 +0100
committerSoby Mathew <soby.mathew@arm.com>2016-07-19 10:19:01 +0100
commitcf0b1492ede6cbbf788144a56d276d8d7924500a (patch)
treee9c92fdc4021598fed52484d1a11100dbebc2b19 /lib/psci/psci_setup.c
parent532ed6183868036e4a4f83cd7a71b93266a3bdb7 (diff)
downloadarm-trusted-firmware-cf0b1492ede6cbbf788144a56d276d8d7924500a.tar.gz
Introduce PSCI Library Interface
This patch introduces the PSCI Library interface. The major changes introduced are as follows: * Earlier BL31 was responsible for Architectural initialization during cold boot via bl31_arch_setup() whereas PSCI was responsible for the same during warm boot. This functionality is now consolidated by the PSCI library and it does Architectural initialization via psci_arch_setup() during both cold and warm boots. * Earlier the warm boot entry point was always `psci_entrypoint()`. This was not flexible enough as a library interface. Now PSCI expects the runtime firmware to provide the entry point via `psci_setup()`. A new function `bl31_warm_entrypoint` is introduced in BL31 and the previous `psci_entrypoint()` is deprecated. * The `smc_helpers.h` is reorganized to separate the SMC Calling Convention defines from the Trusted Firmware SMC helpers. The former is now in a new header file `smcc.h` and the SMC helpers are moved to Architecture specific header. * The CPU context is used by PSCI for context initialization and restoration after power down (PSCI Context). It is also used by BL31 for SMC handling and context management during Normal-Secure world switch (SMC Context). The `psci_smc_handler()` interface is redefined to not use SMC helper macros thus enabling to decouple the PSCI context from EL3 runtime firmware SMC context. This enables PSCI to be integrated with other runtime firmware using a different SMC context. NOTE: With this patch the architectural setup done in `bl31_arch_setup()` is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be invoked prior to architectural setup. It is highly unlikely that the platform setup will depend on architectural setup and cause any failure. Please be be aware of this change in sequence. Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73
Diffstat (limited to 'lib/psci/psci_setup.c')
-rw-r--r--lib/psci/psci_setup.c39
1 files changed, 29 insertions, 10 deletions
diff --git a/lib/psci/psci_setup.c b/lib/psci/psci_setup.c
index fac0edec..d35e0001 100644
--- a/lib/psci/psci_setup.c
+++ b/lib/psci/psci_setup.c
@@ -184,15 +184,17 @@ static void populate_power_domain_tree(const unsigned char *topology)
}
/*******************************************************************************
- * This function initializes the power domain topology tree by querying the
- * platform. The power domain nodes higher than the CPU are populated in the
- * array psci_non_cpu_pd_nodes[] and the CPU power domains are populated in
- * psci_cpu_pd_nodes[]. The platform exports its static topology map through the
+ * This function does the architectural setup and takes the warm boot
+ * entry-point `mailbox_ep` as an argument. The function also initializes the
+ * power domain topology tree by querying the platform. The power domain nodes
+ * higher than the CPU are populated in the array psci_non_cpu_pd_nodes[] and
+ * the CPU power domains are populated in psci_cpu_pd_nodes[]. The platform
+ * exports its static topology map through the
* populate_power_domain_topology_tree() API. The algorithm populates the
* psci_non_cpu_pd_nodes and psci_cpu_pd_nodes iteratively by using this
- * topology map. On a platform that implements two clusters of 2 cpus each, and
- * supporting 3 domain levels, the populated psci_non_cpu_pd_nodes would look
- * like this:
+ * topology map. On a platform that implements two clusters of 2 cpus each,
+ * and supporting 3 domain levels, the populated psci_non_cpu_pd_nodes would
+ * look like this:
*
* ---------------------------------------------------
* | system node | cluster 0 node | cluster 1 node |
@@ -204,10 +206,13 @@ static void populate_power_domain_tree(const unsigned char *topology)
* | CPU 0 | CPU 1 | CPU 2 | CPU 3 |
* ------------------------------------------------
******************************************************************************/
-int psci_setup(void)
+int psci_setup(uintptr_t mailbox_ep)
{
const unsigned char *topology_tree;
+ /* Do the Architectural initialization */
+ psci_arch_setup();
+
/* Query the topology map from the platform */
topology_tree = plat_get_power_domain_tree_desc();
@@ -229,8 +234,8 @@ int psci_setup(void)
*/
psci_set_pwr_domains_to_run(PLAT_MAX_PWR_LVL);
- plat_setup_psci_ops((uintptr_t)psci_entrypoint,
- &psci_plat_pm_ops);
+ assert(mailbox_ep);
+ plat_setup_psci_ops(mailbox_ep, &psci_plat_pm_ops);
assert(psci_plat_pm_ops);
/* Initialize the psci capability */
@@ -259,3 +264,17 @@ int psci_setup(void)
return 0;
}
+
+/*******************************************************************************
+ * This duplicates what the primary cpu did after a cold boot in BL1. The same
+ * needs to be done when a cpu is hotplugged in. This function could also over-
+ * ride any EL3 setup done by BL1 as this code resides in rw memory.
+ ******************************************************************************/
+void psci_arch_setup(void)
+{
+ /* Program the counter frequency */
+ write_cntfrq_el0(plat_get_syscnt_freq2());
+
+ /* Initialize the cpu_ops pointer. */
+ init_cpu_ops();
+}