- 30 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch adds the capability to power down at system power domain level on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers are modified to add support for power management operations at system power domain level. A new helper for populating `get_sys_suspend_power_state` handler in plat_psci_ops is defined. On entering the system suspend state, the SCP powers down the SYSTOP power domain on the SoC and puts the memory into retention mode. On wakeup from the power down, the system components on the CSS will be reinitialized by the platform layer and the PSCI client is responsible for restoring the context of these system components. According to PSCI Specification, interrupts targeted to cores in PSCI CPU SUSPEND should be able to resume it. On Juno, when the system power domain is suspended, the GIC is also powered down. The SCP resumes the final core to be suspend when an external wake-up event is received. But the other cores cannot be woken up by a targeted interrupt, because GIC doesn't forward these interrupts to the SCP. Due to this hardware limitation, we down-grade PSCI CPU SUSPEND requests targeted to the system power domain level to cluster power domain level in `juno_validate_power_state()` and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c. A system power domain resume helper `arm_system_pwr_domain_resume()` is defined for ARM standard platforms which resumes/re-initializes the system components on wakeup from system suspend. The security setup also needs to be done on resume from system suspend, which means `plat_arm_security_setup()` must now be included in the BL3-1 image in addition to previous BL images if system suspend need to be supported. Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
-
- 11 Sep, 2015 1 commit
-
-
Vikram Kanigiri authored
Currently, on ARM platforms(ex. Juno) non-secure access to specific peripheral regions, config registers which are inside and outside CSS is done in the soc_css_security_setup(). This patch separates the CSS security setup from the SOC security setup in the css_security_setup(). The CSS security setup involves programming of the internal NIC to provide access to regions inside the CSS. This is needed only in Juno, hence Juno implements it in its board files as css_init_nic400(). Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
-
- 28 Apr, 2015 1 commit
-
-
Dan Handley authored
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
-