1. 03 May, 2017 1 commit
  2. 03 Nov, 2016 1 commit
    • dp-arm's avatar
      Perform a cache flush after ENTER PSCI timestamp capture · bfef6106
      dp-arm authored
      
      
      Without an explicit cache flush, the next timestamp captured might have
      a bogus value.
      
      This can happen if the following operations happen in order,
      on a CPU that's being powered down.
      
      1) ENTER PSCI timestamp is captured with caches enabled.
      
      2) The next timestamp (ENTER_HW_LOW_PWR) is captured with caches
         disabled.
      
      3) On a system that uses a write-back cache configuration, the
         cache line that holds the PMF timestamps is evicted.
      
      After step 1), the ENTER_PSCI timestamp is cached and not in main memory.
      After step 2), the ENTER_HW_LOW_PWR timestamp is stored in main memory.
      Before the CPU power down happens, the hardware evicts the cache line that
      contains the PMF timestamps for this service.  As a result, the timestamp
      captured in step 2) is overwritten with a bogus value.
      
      Change-Id: Ic1bd816498d1a6d4dc16540208ed3a5efe43f529
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      bfef6106
  3. 12 Oct, 2016 1 commit
    • dp-arm's avatar
      Add PMF instrumentation points in TF · 872be88a
      dp-arm authored
      
      
      In order to quantify the overall time spent in the PSCI software
      implementation, an initial collection of PMF instrumentation points
      has been added.
      
      Instrumentation has been added to the following code paths:
      
      - Entry to PSCI SMC handler.  The timestamp is captured as early
        as possible during the runtime exception and stored in memory
        before entering the PSCI SMC handler.
      
      - Exit from PSCI SMC handler.  The timestamp is captured after
        normal return from the PSCI SMC handler or if a low power state
        was requested it is captured in the bl31 warm boot path before
        return to normal world.
      
      - Entry to low power state.  The timestamp is captured before entry
        to a low power state which implies either standby or power down.
        As these power states are mutually exclusive, only one timestamp
        is defined to describe both.  It is possible to differentiate between
        the two power states using the PSCI STAT interface.
      
      - Exit from low power state.  The timestamp is captured after a standby
        or power up operation has completed.
      
      To calculate the number of cycles spent running code in Trusted Firmware
      one can perform the following calculation:
      
      (exit_psci - enter_psci) - (exit_low_pwr - enter_low_pwr).
      
      The resulting number of cycles can be converted to time given the
      frequency of the counter.
      
      Change-Id: Ie3b8f3d16409b6703747093b3a2d5c7429ad0166
      Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      872be88a
  4. 22 Sep, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Do psci_setup() as part of std_svc_setup() · 58e946ae
      Soby Mathew authored
      This patch moves the invocation of `psci_setup()` from BL31 and SP_MIN
      into `std_svc_setup()` as part of ARM Standard Service initialization.
      This allows us to consolidate ARM Standard Service initializations which
      will be added to in the future. A new function `get_arm_std_svc_args()`
      is introduced to get arguments corresponding to each standard service.
      This function must be implemented by the EL3 Runtime Firmware and both
      SP_MIN and BL31 implement it.
      
      Change-Id: I38e1b644f797fa4089b20574bd4a10f0419de184
      58e946ae
  5. 19 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce PSCI Library Interface · cf0b1492
      Soby Mathew authored
      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
      cf0b1492
  6. 18 Jul, 2016 3 commits
    • Soby Mathew's avatar
      Introduce `el3_runtime` and `PSCI` libraries · 532ed618
      Soby Mathew authored
      This patch moves the PSCI services and BL31 frameworks like context
      management and per-cpu data into new library components `PSCI` and
      `el3_runtime` respectively. This enables PSCI to be built independently from
      BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
      PSCI library sources and gets included by `bl31.mk`. Other changes which
      are done as part of this patch are:
      
      * The runtime services framework is now moved to the `common/` folder to
        enable reuse.
      * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
        specific folder.
      * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
        to `plat/common` folder. The original file location now has a stub which
        just includes the file from new location to maintain platform compatibility.
      
      Most of the changes wouldn't affect platform builds as they just involve
      changes to the generic bl1.mk and bl31.mk makefiles.
      
      NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
      THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
      MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.
      
      Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
      532ed618
    • Soby Mathew's avatar
      Fix coding guideline warnings · da554d74
      Soby Mathew authored
      This patch fixes some coding guideline warnings reported by the checkpatch
      script. Only files related to upcoming feature development have been fixed.
      
      Change-Id: I26fbce75c02ed62f00493ed6c106fe7c863ddbc5
      da554d74
    • Soby Mathew's avatar
      Rework type usage in Trusted Firmware · 4c0d0390
      Soby Mathew authored
      This patch reworks type usage in generic code, drivers and ARM platform files
      to make it more portable. The major changes done with respect to
      type usage are as listed below:
      
      * Use uintptr_t for storing address instead of uint64_t or unsigned long.
      * Review usage of unsigned long as it can no longer be assumed to be 64 bit.
      * Use u_register_t for register values whose width varies depending on
        whether AArch64 or AArch32.
      * Use generic C types where-ever possible.
      
      In addition to the above changes, this patch also modifies format specifiers
      in print invocations so that they are AArch64/AArch32 agnostic. Only files
      related to upcoming feature development have been reworked.
      
      Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
      4c0d0390
  7. 16 Jun, 2016 1 commit
    • Yatharth Kochar's avatar
      Add optional PSCI STAT residency & count functions · 170fb93d
      Yatharth Kochar authored
      This patch adds following optional PSCI STAT functions:
      
      - PSCI_STAT_RESIDENCY: This call returns the amount of time spent
        in power_state in microseconds, by the node represented by the
        `target_cpu` and the highest level of `power_state`.
      
      - PSCI_STAT_COUNT: This call returns the number of times a
        `power_state` has been used by the node represented by the
        `target_cpu` and the highest power level of `power_state`.
      
      These APIs provides residency statistics for power states that has
      been used by the platform. They are implemented according to v1.0
      of the PSCI specification.
      
      By default this optional feature is disabled in the PSCI
      implementation. To enable it, set the boolean flag
      `ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1.
      
      Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff
      170fb93d
  8. 25 May, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Add pwr_domain_pwr_down_wfi() hook in plat_psci_ops · ac1cc8eb
      Soby Mathew authored
      This patch adds a new optional platform hook `pwr_domain_pwr_down_wfi()` in
      the plat_psci_ops structure. This hook allows the platform to perform platform
      specific actions including the wfi invocation to enter powerdown. This hook
      is invoked by both psci_do_cpu_off() and psci_cpu_suspend_start() functions.
      The porting-guide.md is also updated for the same.
      
      This patch also modifies the `psci_power_down_wfi()` function to invoke
      `plat_panic_handler` incase of panic instead of the busy while loop.
      
      Fixes ARM-Software/tf-issues#375
      
      Change-Id: Iba104469a1445ee8d59fb3a6fdd0a98e7f24dfa3
      ac1cc8eb
  9. 20 May, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Add 32 bit version of plat_get_syscnt_freq · d4486391
      Antonio Nino Diaz authored
      Added plat_get_syscnt_freq2, which is a 32 bit variant of the 64 bit
      plat_get_syscnt_freq. The old one has been flagged as deprecated.
      Common code has been updated to use this new version. Porting guide
      has been updated.
      
      Change-Id: I9e913544926c418970972bfe7d81ee88b4da837e
      d4486391
  10. 25 Apr, 2016 2 commits
  11. 08 Feb, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Resolve GCC static analysis false positive · 6d18969f
      Soby Mathew authored
      When BL31 is compiled at `-O3` optimization level using Linaro GCC 4.9
      AArch64 toolchain, it reports the following error:
      
      ```
      services/std_svc/psci/psci_common.c: In function 'psci_do_state_coordination':
      services/std_svc/psci/psci_common.c:220:27: error: array subscript is above
      array bounds [-Werror=array-bounds]
        psci_req_local_pwr_states[pwrlvl - 1][cpu_idx] = req_pwr_state;
                                 ^
      ```
      
      This error is a false positive and this patch resolves the error by asserting
      the array bounds in `psci_do_state_coordination()`.
      
      Fixes ARM-software/tf-issues#347
      
      Change-Id: I3584ed7b2e28faf455b082cb3281d6e1d11d6495
      6d18969f
  12. 01 Feb, 2016 1 commit
    • Soby Mathew's avatar
      Fix PSCI CPU ON race when setting state to ON_PENDING · 203cdfe2
      Soby Mathew authored
      When a CPU is powered down using PSCI CPU OFF API, it disables its caches
      and updates its `aff_info_state` to OFF. The corresponding cache line is
      invalidated by the CPU so that the update will be observed by other CPUs
      running with caches enabled. There is a possibility that another CPU
      which has been trying to turn ON this CPU via PSCI CPU ON API,
      has already seen the update to `aff_info_state` and proceeds to update
      the state to ON_PENDING prior to the cache invalidation. This may result
      in the update of the state to ON_PENDING being discarded.
      
      This patch fixes this issue by making sure that the update of `aff_info_state`
      to ON_PENDING sticks by reading back the value after the cache flush and
      retrying it if not updated. The patch also adds a dsbish() to
      `psci_do_cpu_off()` to ensure ordering of the update to `aff_info_state`
      prior to cache line invalidation.
      
      Fixes ARM-software/tf-issues#349
      
      Change-Id: I225de99957fe89871f8c57bcfc243956e805dcca
      203cdfe2
  13. 14 Jan, 2016 1 commit
  14. 21 Dec, 2015 1 commit
  15. 14 Dec, 2015 1 commit
  16. 06 Oct, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Update state only if CPU_OFF is not denied by SPD · 16e05cdb
      Soby Mathew authored
      This patch fixes an issue in the PSCI framework where the affinity info
      state of a core was being set to OFF even when the SPD had denied the
      CPU_OFF request. Now, the state remains set to ON instead.
      
      Fixes ARM-software/tf-issues#323
      
      Change-Id: Ia9042aa41fae574eaa07fd2ce3f50cf8cae1b6fc
      16e05cdb
  17. 14 Sep, 2015 1 commit
    • Achin Gupta's avatar
      Make generic code work in presence of system caches · 54dc71e7
      Achin Gupta authored
      On the ARMv8 architecture, cache maintenance operations by set/way on the last
      level of integrated cache do not affect the system cache. This means that such a
      flush or clean operation could result in the data being pushed out to the system
      cache rather than main memory. Another CPU could access this data before it
      enables its data cache or MMU. Such accesses could be serviced from the main
      memory instead of the system cache. If the data in the sysem cache has not yet
      been flushed or evicted to main memory then there could be a loss of
      coherency. The only mechanism to guarantee that the main memory will be updated
      is to use cache maintenance operations to the PoC by MVA(See section D3.4.11
      (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).
      
      This patch removes the reliance of Trusted Firmware on the flush by set/way
      operation to ensure visibility of data in the main memory. Cache maintenance
      operations by MVA are now used instead. The following are the broad category of
      changes:
      
      1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is
         initialised. This ensures that any stale cache lines at any level of cache
         are removed.
      
      2. Updates to global data in runtime firmware (BL31) by the primary CPU are made
         visible to secondary CPUs using a cache clean operation by MVA.
      
      3. Cache maintenance by set/way operations are only used prior to power down.
      
      NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN
      ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.
      
      Fixes ARM-software/tf-issues#205
      
      Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
      54dc71e7
  18. 11 Sep, 2015 1 commit
    • Andrew Thoelke's avatar
      Re-design bakery lock memory allocation and algorithm · ee7b35c4
      Andrew Thoelke authored
      This patch unifies the bakery lock api's across coherent and normal
      memory implementation of locks by using same data type `bakery_lock_t`
      and similar arguments to functions.
      
      A separate section `bakery_lock` has been created and used to allocate
      memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are
      allocated in normal memory, each lock for a core has to spread
      across multiple cache lines. By using the total size allocated in a
      separate cache line for a single core at compile time, the memory for
      other core locks is allocated at link time by multiplying the single
      core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock
      algorithm now uses lock address instead of the `id` in the per_cpu_data.
      For locks allocated in coherent memory, it moves locks from
      tzfw_coherent_memory to bakery_lock section.
      
      The bakery locks are allocated as part of bss or in coherent memory
      depending on usage of coherent memory. Both these regions are
      initialised to zero as part of run_time_init before locks are used.
      Hence, bakery_lock_init() is made an empty function as the lock memory
      is already initialised to zero.
      
      The above design lead to the removal of psci bakery locks from
      non_cpu_power_pd_node to psci_locks.
      
      NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED.
      THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY
      LOCKS IN NORMAL MEMORY.
      
      Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
      ee7b35c4
  19. 10 Sep, 2015 1 commit
    • Achin Gupta's avatar
      Pass the target suspend level to SPD suspend hooks · f1054c93
      Achin Gupta authored
      In certain Trusted OS implementations it is a requirement to pass them the
      highest power level which will enter a power down state during a PSCI
      CPU_SUSPEND or SYSTEM_SUSPEND API invocation. This patch passes this power level
      to the SPD in the "max_off_pwrlvl" parameter of the svc_suspend() hook.
      
      Currently, the highest power level which was requested to be placed in a low
      power state (retention or power down) is passed to the SPD svc_suspend_finish()
      hook. This hook is called after emerging from the low power state. It is more
      useful to pass the highest power level which was powered down instead. This
      patch does this by changing the semantics of the parameter passed to an SPD's
      svc_suspend_finish() hook. The name of the parameter has been changed from
      "suspend_level" to "max_off_pwrlvl" as well. Same changes have been made to the
      parameter passed to the tsp_cpu_resume_main() function.
      
      NOTE: THIS PATCH CHANGES THE SEMANTICS OF THE EXISTING "svc_suspend_finish()"
            API BETWEEN THE PSCI AND SPD/SP IMPLEMENTATIONS. THE LATTER MIGHT NEED
            UPDATES TO ENSURE CORRECT BEHAVIOUR.
      
      Change-Id: If3a9d39b13119bbb6281f508a91f78a2f46a8b90
      f1054c93
  20. 13 Aug, 2015 8 commits
    • Soby Mathew's avatar
      PSCI: Rework generic code to conform to coding guidelines · 9d070b99
      Soby Mathew authored
      This patch reworks the PSCI generic implementation to conform to ARM
      Trusted Firmware coding guidelines as described here:
      https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      This patch also reviews the use of signed data types within PSCI
      Generic code and replaces them with their unsigned counterparts wherever
      they are not appropriate. The PSCI_INVALID_DATA macro which was defined
      to -1 is now replaced with PSCI_INVALID_PWR_LVL macro which is defined
      to PLAT_MAX_PWR_LVL + 1.
      
      Change-Id: Iaea422d0e46fc314e0b173c2b4c16e0d56b2515a
      9d070b99
    • Soby Mathew's avatar
      PSCI: Fix the return code for invalid entrypoint · 617540d8
      Soby Mathew authored
      As per PSCI1.0 specification, the error code to be returned when an invalid
      non secure entrypoint address is specified by the PSCI client for CPU_SUSPEND,
      CPU_ON or SYSTEM_SUSPEND must be PSCI_E_INVALID_ADDRESS. The current PSCI
      implementation returned PSCI_E_INVAL_PARAMS. This patch rectifies this error
      and also implements a common helper function to validate the entrypoint
      information to be used across these PSCI API implementations.
      
      Change-Id: I52d697d236c8bf0cd3297da4008c8e8c2399b170
      617540d8
    • Soby Mathew's avatar
      PSCI: Switch to the new PSCI frameworks · 67487846
      Soby Mathew authored
      This commit does the switch to the new PSCI framework implementation replacing
      the existing files in PSCI folder with the ones in PSCI1.0 folder. The
      corresponding makefiles are modified as required for the new implementation.
      The platform.h header file is also is switched to the new one
      as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults
      to 1 to enable compatibility layer which let the existing platform ports to
      continue to build and run with minimal changes.
      
      The default weak implementation of platform_get_core_pos() is now removed from
      platform_helpers.S and is provided by the compatibility layer.
      
      Note: The Secure Payloads and their dispatchers still use the old platform
      and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build
      flag will remain enabled in subsequent patch. The compatibility for SPDs using
      the older APIs on platforms migrated to the new APIs will be added in the
      following patch.
      
      Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719
      67487846
    • Soby Mathew's avatar
      PSCI: Implement platform compatibility layer · 32bc85f2
      Soby Mathew authored
      The new PSCI topology framework and PSCI extended State framework introduces
      a breaking change in the platform port APIs. To ease the migration of the
      platform ports to the new porting interface, a compatibility layer is
      introduced which essentially defines the new platform API in terms of the
      old API. The old PSCI helpers to retrieve the power-state, its associated
      fields and the highest coordinated physical OFF affinity level of a core
      are also implemented for compatibility. This allows the existing
      platform ports to work with the new PSCI framework without significant
      rework. This layer will be enabled by default once the switch to the new
      PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT.
      
      Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3
      32bc85f2
    • Sandrine Bailleux's avatar
      PSCI: Unify warm reset entry points · eb975f52
      Sandrine Bailleux authored
      There used to be 2 warm reset entry points:
      
       - the "on finisher", for when the core has been turned on using a
         PSCI CPU_ON call;
      
       - the "suspend finisher", entered upon resumption from a previous
         PSCI CPU_SUSPEND call.
      
      The appropriate warm reset entry point used to be programmed into the
      mailboxes by the power management hooks.
      
      However, it is not required to provide this information to the PSCI
      entry point code, as it can figure it out by itself. By querying affinity
      info state, a core is able to determine on which execution path it is.
      If the state is ON_PENDING then it means it's been turned on else
      it is resuming from suspend.
      
      This patch unifies the 2 warm reset entry points into a single one:
      psci_entrypoint(). The patch also implements the necessary logic
      to distinguish between the 2 types of warm resets in the power up
      finisher.
      
      The plat_setup_psci_ops() API now takes the
      secure entry point as an additional parameter to enable the platforms
      to configure their mailbox. The platform hooks `pwr_domain_on`
      and `pwr_domain_suspend` no longer take secure entry point as
      a parameter.
      
      Change-Id: I7d1c93787b54213aefdbc046b8cd66a555dfbfd9
      eb975f52
    • Soby Mathew's avatar
      PSCI: Add framework to handle composite power states · 8ee24980
      Soby Mathew authored
      The state-id field in the power-state parameter of a CPU_SUSPEND call can be
      used to describe composite power states specific to a platform. The current PSCI
      implementation does not interpret the state-id field. It relies on the target
      power level and the state type fields in the power-state parameter to perform
      state coordination and power management operations. The framework introduced
      in this patch allows the PSCI implementation to intepret generic global states
      like RUN, RETENTION or OFF from the State-ID to make global state coordination
      decisions and reduce the complexity of platform ports. It adds support to
      involve the platform in state coordination which facilitates the use of
      composite power states and improves the support for entering standby states
      at multiple power domains.
      
      The patch also includes support for extended state-id format for the power
      state parameter as specified by PSCIv1.0.
      
      The PSCI implementation now defines a generic representation of the power-state
      parameter. It depends on the platform port to convert the power-state parameter
      (possibly encoding a composite power state) passed in a CPU_SUSPEND call to this
      representation via the `validate_power_state()` plat_psci_ops handler. It is an
      array where each index corresponds to a power level. Each entry contains the
      local power state the power domain at that power level could enter.
      
      The meaning of the local power state values is platform defined, and may vary
      between levels in a single platform. The PSCI implementation constrains the
      values only so that it can classify the state as RUN, RETENTION or OFF as
      required by the specification:
         * zero means RUN
         * all OFF state values at all levels must be higher than all RETENTION
           state values at all levels
         * the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values
           to the framework
      
      The platform also must define the macros PLAT_MAX_RET_STATE and
      PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power
      domains have been requested to enter a retention or power down state. The PSCI
      implementation does not interpret the local power states defined by the
      platform. The only constraint is that the PLAT_MAX_RET_STATE <
      PLAT_MAX_OFF_STATE.
      
      For a power domain tree, the generic implementation maintains an array of local
      power states. These are the states requested for each power domain by all the
      cores contained within the domain. During a request to place multiple power
      domains in a low power state, the platform is passed an array of requested
      power-states for each power domain through the plat_get_target_pwr_state()
      API. It coordinates amongst these states to determine a target local power
      state for the power domain. A default weak implementation of this API is
      provided in the platform layer which returns the minimum of the requested
      power-states back to the PSCI state coordination.
      
      Finally, the plat_psci_ops power management handlers are passed the target
      local power states for each affected power domain using the generic
      representation described above. The platform executes operations specific to
      these target states.
      
      The platform power management handler for placing a power domain in a standby
      state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for
      placing a core power domain into a standby or retention state should now be
      used to only place the core power domain in a standby or retention state.
      
      The extended state-id power state format can be enabled by setting the
      build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default.
      
      Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c
      8ee24980
    • Soby Mathew's avatar
      PSCI: Introduce new platform interface to describe topology · 82dcc039
      Soby Mathew authored
      This patch removes the assumption in the current PSCI implementation that MPIDR
      based affinity levels map directly to levels in a power domain tree. This
      enables PSCI generic code to support complex power domain topologies as
      envisaged by PSCIv1.0 specification. The platform interface for querying
      the power domain topology has been changed such that:
      
      1. The generic PSCI code does not generate MPIDRs and use them to query the
         platform about the number of power domains at a particular power level. The
         platform now provides a description of the power domain tree on the SoC
         through a data structure. The existing platform APIs to provide the same
         information have been removed.
      
      2. The linear indices returned by plat_core_pos_by_mpidr() and
         plat_my_core_pos() are used to retrieve core power domain nodes from the
         power domain tree. Power domains above the core level are accessed using a
         'parent' field in the tree node descriptors.
      
      The platform describes the power domain tree in an array of 'unsigned
      char's. The first entry in the array specifies the number of power domains at
      the highest power level implemented in the system. Each susbsequent entry
      corresponds to a power domain and contains the number of power domains that are
      its direct children. This array is exported to the generic PSCI implementation
      via the new `plat_get_power_domain_tree_desc()` platform API.
      
      The PSCI generic code uses this array to populate its internal power domain tree
      using the Breadth First Search like algorithm. The tree is split into two
      arrays:
      
      1. An array that contains all the core power domain nodes
      
      2. An array that contains all the other power domain nodes
      
      A separate array for core nodes allows certain core specific optimisations to
      be implemented e.g. remove the bakery lock, re-use per-cpu data framework for
      storing some information.
      
      Entries in the core power domain array are allocated such that the
      array index of the domain is equal to the linear index returned by
      plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR
      corresponding to that domain. This relationship is key to be able to use
      an MPIDR to find the corresponding core power domain node, traverse to higher
      power domain nodes and index into arrays that contain core specific
      information.
      
      An introductory document has been added to briefly describe the new interface.
      
      Change-Id: I4b444719e8e927ba391cae48a23558308447da13
      82dcc039
    • Soby Mathew's avatar
      PSCI: Introduce new platform and CM helper APIs · 12d0d00d
      Soby Mathew authored
      This patch introduces new platform APIs and context management helper APIs
      to support the new topology framework based on linear core position. This
      framework will be introduced in the follwoing patch and it removes the
      assumption that the MPIDR based affinity levels map directly to levels
      in a power domain tree. The new platforms APIs and context management
      helpers based on core position are as described below:
      
      * plat_my_core_pos() and plat_core_pos_by_mpidr()
      
      These 2 new mandatory platform APIs are meant to replace the existing
      'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the
      linear index of the calling core and 'plat_core_pos_by_mpidr()' returns
      the linear index of a core specified by its MPIDR. The latter API will also
      validate the MPIDR passed as an argument and will return an error code (-1)
      if an invalid MPIDR is passed as the argument. This enables the caller to
      safely convert an MPIDR of another core to its linear index without querying
      the PSCI topology tree e.g. during a call to PSCI CPU_ON.
      
      Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always
      platform specific, it is no longer possible to maintain a default implementation
      of this API. Also it might not be possible for a platform port to verify an
      MPIDR before the C runtime has been setup or the topology has been initialized.
      This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to
      topology setup. As a result, the generic Trusted Firmware code does not call
      this API before the topology setup has been done.
      
      The 'plat_my_core_pos' API should be able to run without a C runtime.
      Since this API needs to return a core position which is equal to the one
      returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR,
      this too cannot have default implementation and is a mandatory API for
      platform ports. These APIs will be implemented by the ARM reference platform
      ports later in the patch stack.
      
      * plat_get_my_stack() and plat_set_my_stack()
      
      These APIs are the stack management APIs which set/return stack addresses
      appropriate for the calling core. These replace the 'platform_get_stack()' and
      'platform_set_stack()' APIs. A default weak MP version and a global UP version
      of these APIs are provided for the platforms.
      
      * Context management helpers based on linear core position
      
      A set of new context management(CM) helpers viz cm_get_context_by_index(),
      cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index()
      are defined which are meant to replace the old helpers which took MPIDR
      as argument. The old CM helpers are implemented based on the new helpers to
      allow for code consolidation and will be deprecated once the switch to the new
      framework is done.
      
      Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
      12d0d00d
  21. 05 Aug, 2015 3 commits
    • Soby Mathew's avatar
      PSCI: Remove references to affinity based power management · 4067dc31
      Soby Mathew authored
      As per Section 4.2.2. in the PSCI specification, the term "affinity"
      is used in the context of describing the hierarchical arrangement
      of cores. This often, but not always, maps directly to the processor
      power domain topology of the system. The current PSCI implementation
      assumes that this is always the case i.e. MPIDR based levels of
      affinity always map to levels in a power domain topology tree.
      
      This patch is the first in a series of patches which remove this
      assumption. It removes all occurences of the terms "affinity
      instances and levels" when used to describe the power domain
      topology. Only the terminology is changed in this patch. Subsequent
      patches will implement functional changes to remove the above
      mentioned assumption.
      
      Change-Id: Iee162f051b228828310610c5a320ff9d31009b4e
      4067dc31
    • Soby Mathew's avatar
      PSCI: Invoke PM hooks only for the highest level · 6590ce22
      Soby Mathew authored
      This patch optimizes the invocation of the platform power management hooks for
      ON, OFF and SUSPEND such that they are called only for the highest affinity
      level which will be powered off/on. Earlier, the hooks were being invoked for
      all the intermediate levels as well.
      
      This patch requires that the platforms migrate to the new semantics of the PM
      hooks.  It also removes the `state` parameter from the pm hooks as the `afflvl`
      parameter now indicates the highest affinity level for which power management
      operations are required.
      
      Change-Id: I57c87931d8a2723aeade14acc710e5b78ac41732
      6590ce22
    • Soby Mathew's avatar
      PSCI: Create new directory to implement new frameworks · b48349eb
      Soby Mathew authored
      This patch creates a copy of the existing PSCI files and related psci.h and
      platform.h header files in a new `PSCI1.0` directory. The changes for the
      new PSCI power domain topology and extended state-ID frameworks will be
      added incrementally to these files. This incremental approach will
      aid in review and in understanding the changes better. Once all the
      changes have been introduced, these files will replace the existing PSCI
      files.
      
      Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff
      b48349eb
  22. 22 Jun, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Add SYSTEM_SUSPEND API support · c0aff0e0
      Soby Mathew authored
      This patch adds support for SYSTEM_SUSPEND API as mentioned in the PSCI 1.0
      specification. This API, on being invoked on the last running core on a
      supported platform, will put the system into a low power mode with memory
      retention.
      
      The psci_afflvl_suspend() internal API has been reused as most of the actions
      to suspend a system are the same as invoking the PSCI CPU_SUSPEND API with the
      target affinity level as 'system'. This API needs the 'power state' parameter
      for the target low power state. This parameter is not passed by the caller of
      the SYSTEM_SUSPEND API. Hence, the platform needs to implement the
      get_sys_suspend_power_state() platform function to provide this information.
      Also, the platform also needs to add support for suspending the system to the
      existing 'plat_pm_ops' functions: affinst_suspend() and
      affinst_suspend_finish().
      
      Change-Id: Ib6bf10809cb4e9b92f463755608889aedd83cef5
      c0aff0e0
  23. 19 Jun, 2015 1 commit
    • Andrew Thoelke's avatar
      Fix integer extension in mpidr_set_aff_inst() · 9b89613e
      Andrew Thoelke authored
      mpidr_set_aff_inst() is left shifting an int constant and an
      unsigned char value to construct an MPIDR. For affinity level 3 a
      shift of 32 would result in shifting out of the 32-bit type and
      have no effect on the MPIDR.
      
      These values need to be extended to unsigned long before shifting
      to ensure correct results for affinity level 3.
      
      Change-Id: I1ef40afea535f14cfd820c347a065a228e8f4536
      9b89613e
  24. 04 Jun, 2015 2 commits
    • Sandrine Bailleux's avatar
      Introduce PROGRAMMABLE_RESET_ADDRESS build option · bf031bba
      Sandrine Bailleux authored
      This patch introduces a new platform build option, called
      PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
      a programmable or fixed reset vector address.
      
      If the reset vector address is fixed then the code relies on the
      platform_get_entrypoint() mailbox mechanism to figure out where
      it is supposed to jump. On the other hand, if it is programmable
      then it is assumed that the platform code will program directly
      the right address into the RVBAR register (instead of using the
      mailbox redirection) so the mailbox is ignored in this case.
      
      Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
      bf031bba
    • Sandrine Bailleux's avatar
      Rationalize reset handling code · 52010cc7
      Sandrine Bailleux authored
      The attempt to run the CPU reset code as soon as possible after reset
      results in highly complex conditional code relating to the
      RESET_TO_BL31 option.
      
      This patch relaxes this requirement a little. In the BL1, BL3-1 and
      PSCI entrypoints code, the sequence of operations is now as follows:
       1) Detect whether it is a cold or warm boot;
       2) For cold boot, detect whether it is the primary or a secondary
          CPU. This is needed to handle multiple CPUs entering cold reset
          simultaneously;
       3) Run the CPU init code.
      
      This patch also abstracts the EL3 registers initialisation done by
      the BL1, BL3-1 and PSCI entrypoints into common code.
      
      This improves code re-use and consolidates the code flows for
      different types of systems.
      
      NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
      NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
      FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
      OTHERWISE, SECONDARY CPUS WILL PANIC.
      
      Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
      52010cc7
  25. 13 May, 2015 1 commit
    • Soby Mathew's avatar
      PSCI: Set ON_PENDING state early during CPU_ON · 42cae5a1
      Soby Mathew authored
      In the debug build of the function get_power_on_target_afflvl(), there is a
      check to ensure that the CPU is emerging from a SUSPEND or ON_PENDING state.
      The state is checked without acquiring the lock for the CPU node. The state
      could be updated to ON_PENDING in psci_afflvl_on() after the target CPU has
      been powered up. This results in a race condition which could cause the
      check for the ON_PENDING state in get_power_on_target_afflvl() to fail.
      This patch resolves this race condition by setting the state of the target
      CPU to ON_PENDING before the platform port attempts to power it on. The
      target CPU is thus guaranteed to read the correct the state. In case
      the power on operation fails, the state of the CPU is restored to OFF.
      
      Fixes ARM-software/tf-issues#302
      
      Change-Id: I3f2306a78c58d47b1a0fb7e33ab04f917a2d5044
      42cae5a1
  26. 08 Apr, 2015 1 commit
    • Kévin Petit's avatar
      Add support to indicate size and end of assembly functions · 8b779620
      Kévin Petit authored
      
      
      In order for the symbol table in the ELF file to contain the size of
      functions written in assembly, it is necessary to report it to the
      assembler using the .size directive.
      
      To fulfil the above requirements, this patch introduces an 'endfunc'
      macro which contains the .endfunc and .size directives. It also adds
      a .func directive to the 'func' assembler macro.
      
      The .func/.endfunc have been used so the assembler can fail if
      endfunc is omitted.
      
      Fixes ARM-Software/tf-issues#295
      
      Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
      Signed-off-by: default avatarKévin Petit <kevin.petit@arm.com>
      8b779620
  27. 13 Mar, 2015 1 commit
    • Vikram Kanigiri's avatar
      Initialise cpu ops after enabling data cache · 12e7c4ab
      Vikram Kanigiri authored
      The cpu-ops pointer was initialized before enabling the data cache in the cold
      and warm boot paths. This required a DCIVAC cache maintenance operation to
      invalidate any stale cache lines resident in other cpus.
      
      This patch moves this initialization to the bl31_arch_setup() function
      which is always called after the data cache and MMU has been enabled.
      
      This change removes the need:
       1. for the DCIVAC cache maintenance operation.
       2. to initialise the CPU ops upon resumption from a PSCI CPU_SUSPEND
          call since memory contents are always preserved in this case.
      
      Change-Id: Ibb2fa2f7460d1a1f1e721242025e382734c204c6
      12e7c4ab