1. 14 Dec, 2015 1 commit
  2. 30 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Support PSCI SYSTEM SUSPEND on Juno · c1bb8a05
      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
      c1bb8a05
  3. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add common ARM and CSS platform code · b4315306
      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
      b4315306