1. 28 Sep, 2018 4 commits
  2. 19 Jul, 2018 3 commits
    • Jeenu Viswambharan's avatar
      RAS: Introduce handler for EL3 EAs · eaeaa4d0
      Jeenu Viswambharan authored
      
      
      External Aborts while executing in EL3 is fatal in nature. This patch
      allows for the platform to define a handler for External Aborts received
      while executing in EL3. A default implementation is added which falls
      back to platform unhandled exception.
      
      Change-Id: I466f2c8113a33870f2c7d2d8f2bf20437d9fd354
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      eaeaa4d0
    • Jeenu Viswambharan's avatar
      RAS: Introduce handler for Double Faults · d5a23af5
      Jeenu Viswambharan authored
      
      
      Double fault is when the PE receives another error whilst one is being
      handled. To detect double fault condition, a per-CPU flag is introduced
      to track the status of error handling. The flag is checked/modified
      while temporarily masking external aborts on the PE.
      
      This patch routes double faults to a separate platform-defined handler.
      
      Change-Id: I70e9b7ba4c817273c55a0af978d9755ff32cc702
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      d5a23af5
    • Jeenu Viswambharan's avatar
      RAS: Introduce handler for Uncontainable errors · b56dc2a9
      Jeenu Viswambharan authored
      
      
      Uncontainable errors are the most severe form of errors, which typically
      mean that the system state can't be trusted any more. This further means
      that normal error recovery process can't be followed, and an orderly
      shutdown of the system is often desirable.
      
      This patch allows for the platform to define a handler for Uncontainable
      errors received. Due to the nature of Uncontainable error, the handler
      is expected to initiate an orderly shutdown of the system, and therefore
      is not expected to return. A default implementation is added which falls
      back to platform unhandled exception.
      
      Also fix ras_arch.h header guards.
      
      Change-Id: I072e336a391a0b382e77e627eb9e40729d488b55
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      b56dc2a9
  3. 27 Jun, 2018 1 commit
    • Jeenu Viswambharan's avatar
      DynamIQ: Enable MMU without using stack · 64ee263e
      Jeenu Viswambharan authored
      
      
      Having an active stack while enabling MMU has shown coherency problems.
      This patch builds on top of translation library changes that introduces
      MMU-enabling without using stacks.
      
      Previously, with HW_ASSISTED_COHERENCY, data caches were disabled while
      enabling MMU only because of active stack. Now that we can enable MMU
      without using stack, we can enable both MMU and data caches at the same
      time.
      
      NOTE: Since this feature depends on using translation table library v2,
      disallow using translation table library v1 with HW_ASSISTED_COHERENCY.
      
      Fixes ARM-software/tf-issues#566
      
      Change-Id: Ie55aba0c23ee9c5109eb3454cb8fa45d74f8bbb2
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      64ee263e
  4. 15 May, 2018 1 commit
  5. 04 May, 2018 2 commits
    • Jeenu Viswambharan's avatar
      RAS: Add support for node registration · 362599ec
      Jeenu Viswambharan authored
      
      
      Previous patches added frameworks for handling RAS errors. This patch
      introduces features that the platform can use to enumerate and iterate
      RAS nodes:
      
        - The REGISTER_RAS_NODES() can be used to expose an array of
          ras_node_info_t structures. Each ras_node_info_t describes a RAS
          node, along with handlers for probing the node for error, and if
          did record an error, another handler to handle it.
      
        - The macro for_each_ras_node() can be used to iterate over the
          registered RAS nodes, probe for, and handle any errors.
      
      The common platform EA handler has been amended using error handling
      primitives introduced by both this and previous patches.
      
      Change-Id: I2e13f65a88357bc48cd97d608db6c541fad73853
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      362599ec
    • Jeenu Viswambharan's avatar
      AArch64: Introduce External Abort handling · 76454abf
      Jeenu Viswambharan authored
      
      
      At present, any External Abort routed to EL3 is reported as an unhandled
      exception and cause a panic. This patch enables ARM Trusted Firmware to
      handle External Aborts routed to EL3.
      
      With this patch, when an External Abort is received at EL3, its handling
      is delegated to plat_ea_handler() function. Platforms can provide their
      own implementation of this function. This patch adds a weak definition
      of the said function that prints out a message and just panics.
      
      In order to support handling External Aborts at EL3, the build option
      HANDLE_EA_EL3_FIRST must be set to 1.
      
      Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to
      compilation; this patch fixes that too.
      
      Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      76454abf
  6. 27 Apr, 2018 1 commit
    • Masahiro Yamada's avatar
      types: use int-ll64 for both aarch32 and aarch64 · 0a2d5b43
      Masahiro Yamada authored
      Since commit 031dbb12
      
       ("AArch32: Add essential Arch helpers"),
      it is difficult to use consistent format strings for printf() family
      between aarch32 and aarch64.
      
      For example, uint64_t is defined as 'unsigned long long' for aarch32
      and as 'unsigned long' for aarch64.  Likewise, uintptr_t is defined
      as 'unsigned int' for aarch32, and as 'unsigned long' for aarch64.
      
      A problem typically arises when you use printf() in common code.
      
      One solution could be, to cast the arguments to a type long enough
      for both architectures.  For example, if 'val' is uint64_t type,
      like this:
      
        printf("val = %llx\n", (unsigned long long)val);
      
      Or, somebody may suggest to use a macro provided by <inttypes.h>,
      like this:
      
        printf("val = %" PRIx64 "\n", val);
      
      But, both would make the code ugly.
      
      The solution adopted in Linux kernel is to use the same typedefs for
      all architectures.  The fixed integer types in the kernel-space have
      been unified into int-ll64, like follows:
      
          typedef signed char           int8_t;
          typedef unsigned char         uint8_t;
      
          typedef signed short          int16_t;
          typedef unsigned short        uint16_t;
      
          typedef signed int            int32_t;
          typedef unsigned int          uint32_t;
      
          typedef signed long long      int64_t;
          typedef unsigned long long    uint64_t;
      
      [ Linux commit: 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf ]
      
      This gets along with the codebase shared between 32 bit and 64 bit,
      with the data model called ILP32, LP64, respectively.
      
      The width for primitive types is defined as follows:
      
                         ILP32           LP64
          int            32              32
          long           32              64
          long long      64              64
          pointer        32              64
      
      'long long' is 64 bit for both, so it is used for defining uint64_t.
      'long' has the same width as pointer, so for uintptr_t.
      
      We still need an ifdef conditional for (s)size_t.
      
      All 64 bit architectures use "unsigned long" size_t, and most 32 bit
      architectures use "unsigned int" size_t.  H8/300, S/390 are known as
      exceptions; they use "unsigned long" size_t despite their architecture
      is 32 bit.
      
      One idea for simplification might be to define size_t as 'unsigned long'
      across architectures, then forbid the use of "%z" string format.
      However, this would cause a distortion between size_t and sizeof()
      operator.  We have unknowledge about the native type of sizeof(), so
      we need a guess of it anyway.  I want the following formula to always
      return 1:
      
        __builtin_types_compatible_p(size_t, typeof(sizeof(int)))
      
      Fortunately, ARM is probably a majority case.  As far as I know, all
      32 bit ARM compilers use "unsigned int" size_t.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0a2d5b43
  7. 01 Mar, 2018 1 commit
    • Dan Handley's avatar
      Suppress spurious deprecated declaration warnings · 97924e45
      Dan Handley authored
      
      
      Some generic compatibility functions emit deprecated declaration warnings
      even when platforms do not use the deprecated functions directly. This
      can be confusing. Suppress these warnings by using:
      `#pragma GCC diagnostic ignored "-Wdeprecated-declarations"`
      
      Also emit a runtime warning if the weak plat/common implemntation of
      plat_get_syscnt_freq2() is used, as this implies the platform has not
      migrated from plat_get_syscnt_freq(). The deprecated  declaration warnings
      only help detect when platforms are calling deprecated functions, not when
      they are defining deprecated functions.
      
      Fixes ARM-software/tf-issues#550
      
      Change-Id: Id14a92279c2634c1e76db8ef210da8affdbb2a5d
      Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
      97924e45
  8. 26 Feb, 2018 1 commit
    • Soby Mathew's avatar
      Introduce the new BL handover interface · a6f340fe
      Soby Mathew authored
      
      
      This patch introduces a new BL handover interface. It essentially allows
      passing 4 arguments between the different BL stages. Effort has been made
      so as to be compatible with the previous handover interface. The previous
      blx_early_platform_setup() platform API is now deprecated and the new
      blx_early_platform_setup2() variant is introduced. The weak compatiblity
      implementation for the new API is done in the `plat_bl_common.c` file.
      Some of the new arguments in the new API will be reserved for generic
      code use when dynamic configuration support is implemented. Otherwise
      the other registers are available for platform use.
      
      Change-Id: Ifddfe2ea8e32497fe1beb565cac155ad9d50d404
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a6f340fe
  9. 01 Feb, 2018 1 commit
  10. 19 Jan, 2018 1 commit
    • Julius Werner's avatar
      Add default crash console code to hook up to new console API · 17cd67d2
      Julius Werner authored
      
      
      This patch expands the weak stubs for the plat_crash_console_xxx
      functions in common platform code to use the new console API for crash
      output. This should make crash console output "just work" for most cases
      without the need for the platform to explicitly set up a crash console.
      For cases where the normal console framework doesn't work (e.g. very
      early crashes, before the platform can register any consoles), platforms
      are still able to override the functions just like before.
      
      This feature requires the MULTI_CONSOLE_API compile-time flag to work.
      For builds which don't have it set, this patch has no practical effect.
      
      Change-Id: I80dd161cb43f9db59a0bad2dae33c6560cfac584
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      17cd67d2
  11. 12 Dec, 2017 1 commit
    • Julius Werner's avatar
      Add new function-pointer-based console API · 9536bae6
      Julius Werner authored
      
      
      This patch overhauls the console API to allow for multiple console
      instances of different drivers that are active at the same time. Instead
      of binding to well-known function names (like console_core_init),
      consoles now provide a register function (e.g. console_16550_register())
      that will hook them into the list of active consoles. All console
      operations will be dispatched to all consoles currently in the list.
      
      The new API will be selected by the build-time option MULTI_CONSOLE_API,
      which defaults to ${ERROR_DEPRECATED} for now. The old console API code
      will be retained to stay backwards-compatible to older platforms, but
      should no longer be used for any newly added platforms and can hopefully
      be removed at some point in the future.
      
      The new console API is intended to be used for both normal (bootup) and
      crash use cases, freeing platforms of the need to set up the crash
      console separately. Consoles can be individually configured to be active
      active at boot (until first handoff to EL2), at runtime (after first
      handoff to EL2), and/or after a crash. Console drivers should set a sane
      default upon registration that can be overridden with the
      console_set_scope() call. Code to hook up the crash reporting mechanism
      to this framework will be added with a later patch.
      
      This patch only affects AArch64, but the new API could easily be ported
      to AArch32 as well if desired.
      
      Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9536bae6
  12. 13 Nov, 2017 1 commit
  13. 24 Oct, 2017 1 commit
  14. 03 May, 2017 1 commit
  15. 20 Apr, 2017 1 commit
    • Antonio Nino Diaz's avatar
      Remove build option `ASM_ASSERTION` · 044bb2fa
      Antonio Nino Diaz authored
      
      
      The build option `ENABLE_ASSERTIONS` should be used instead. That way
      both C and ASM assertions can be enabled or disabled together.
      
      All occurrences of `ASM_ASSERTION` in common code and ARM platforms have
      been replaced by `ENABLE_ASSERTIONS`.
      
      ASM_ASSERTION has been removed from the user guide.
      
      Change-Id: I51f1991f11b9b7ff83e787c9a3270c274748ec6f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      044bb2fa
  16. 31 Mar, 2017 1 commit
  17. 20 Mar, 2017 1 commit
  18. 08 Mar, 2017 1 commit
  19. 24 Oct, 2016 1 commit
  20. 19 Aug, 2016 1 commit
    • Sandrine Bailleux's avatar
      Add WFI in platform's unexpected error handlers · 8c9e1af0
      Sandrine Bailleux authored
      This patch adds a WFI instruction in the default implementations of
      plat_error_handler() and plat_panic_handler(). This potentially reduces
      power consumption by allowing the hardware to enter a low-power state.
      The same change has been made to the FVP and Juno platform ports.
      
      Change-Id: Ia4e6e1e5bf1ed42efbba7d0ebbad7be8d5f9f173
      8c9e1af0
  21. 18 Jul, 2016 2 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
      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
  22. 08 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Derive stack alignment from CACHE_WRITEBACK_GRANULE · 663db206
      Soby Mathew authored
      The per-cpu stacks should be aligned to the cache-line size and
      the `declare_stack` helper in asm_macros.S macro assumed a
      cache-line size of 64 bytes. The platform defines the cache-line
      size via CACHE_WRITEBACK_GRANULE macro. This patch modifies
      `declare_stack` helper macro to derive stack alignment from the
      platform defined macro.
      
      Change-Id: I1e1b00fc8806ecc88190ed169f4c8d3dd25fe95b
      663db206
  23. 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
  24. 14 Mar, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove all non-configurable dead loops · 1c3ea103
      Antonio Nino Diaz authored
      Added a new platform porting function plat_panic_handler, to allow
      platforms to handle unexpected error situations. It must be
      implemented in assembly as it may be called before the C environment
      is initialized. A default implementation is provided, which simply
      spins.
      
      Corrected all dead loops in generic code to call this function
      instead. This includes the dead loop that occurs at the end of the
      call to panic().
      
      All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
      been removed.
      
      Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
      1c3ea103
  25. 09 Dec, 2015 1 commit
    • Soby Mathew's avatar
      Ensure BL31 does not print to boot console by default · 78e61613
      Soby Mathew authored
      It is not ideal for BL31 to continue to use boot console at
      runtime which could be potentially uninitialized. This patch
      introduces a new optional platform porting API
      `bl31_plat_runtime_setup()` which allows the platform to perform
      any BL31 runtime setup just prior to BL31 exit during cold boot.
      The default weak implementation of this function will invoke
      `console_uninit()` which will suppress any BL31 runtime logs.
      
      On the ARM Standard platforms, there is an anomaly that
      the boot console will be reinitialized on resumption from
      system suspend in `arm_system_pwr_domain_resume()`. This
      will be resolved in the following patch.
      
      NOTE: The default weak definition of `bl31_plat_runtime_setup()`
      disables the BL31 console. To print the BL31 runtime
      messages, platforms must override this API and initialize a
      runtime console.
      
      Fixes ARM-software/tf-issues#328
      
      Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a
      78e61613
  26. 26 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      Pass the entry point info to bl1_plat_prepare_exit() · 862b5dc2
      Sandrine Bailleux authored
      This patch modifies the prototype of the bl1_plat_prepare_exit()
      platform API to pass the address of the entry point info structure
      received from BL2. The structure contains information that can be
      useful, depending on the kind of clean up or bookkeeping operations
      to perform.
      
      The weak implementation of this function ignores this argument to
      preserve platform backwards compatibility.
      
      NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
      FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.
      
      Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
      862b5dc2
  27. 28 Oct, 2015 1 commit
    • Juan Castillo's avatar
      Add optional platform error handler API · 40fc6cd1
      Juan Castillo authored
      This patch adds an optional API to the platform port:
      
          void plat_error_handler(int err) __dead2;
      
      The platform error handler is called when there is a specific error
      condition after which Trusted Firmware cannot continue. While panic()
      simply prints the crash report (if enabled) and spins, the platform
      error handler can be used to hand control over to the platform port
      so it can perform specific bookeeping or post-error actions (for
      example, reset the system). This function must not return.
      
      The parameter indicates the type of error using standard codes from
      errno.h. Possible errors reported by the generic code are:
      
          -EAUTH  : a certificate or image could not be authenticated
                    (when Trusted Board Boot is enabled)
          -ENOENT : the requested image or certificate could not be found
                    or an IO error was detected
          -ENOMEM : resources exhausted. Trusted Firmware does not use
                    dynamic memory, so this error is usually an indication
                    of an incorrect array size
      
      A default weak implementation of this function has been provided.
      It simply implements an infinite loop.
      
      Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
      40fc6cd1
  28. 20 Oct, 2015 1 commit
    • Juan Castillo's avatar
      Add optional bl1_plat_prepare_exit() API · e3f67124
      Juan Castillo authored
      This patch adds an optional API to the platform port:
      
          void bl1_plat_prepare_exit(void);
      
      This function is called prior to exiting BL1 in response to the
      RUN_IMAGE_SMC request raised by BL2. It should be used to perform
      platform specific clean up or bookkeeping operations before
      transferring control to the next image.
      
      A weak empty definition of this function has been provided to
      preserve platform backwards compatibility.
      
      Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1
      e3f67124
  29. 13 Aug, 2015 5 commits
    • Soby Mathew's avatar
      PSCI: Add deprecated API for SPD when compatibility is disabled · 5c8babcd
      Soby Mathew authored
      This patch defines deprecated platform APIs to enable Trusted
      Firmware components like Secure Payload and their dispatchers(SPD)
      to continue to build and run when platform compatibility is disabled.
      This decouples the migration of platform ports to the new platform API
      from SPD and enables them to be migrated independently. The deprecated
      platform APIs defined in this patch are : platform_get_core_pos(),
      platform_get_stack() and platform_set_stack().
      
      The patch also deprecates MPIDR based context management helpers like
      cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context().
      A mechanism to deprecate APIs and identify callers of these APIs during
      build is introduced, which is controlled by the build flag WARN_DEPRECATED.
      If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be
      flagged either as a link error for assembly files or compile time warning
      for C files during build.
      
      Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613
      5c8babcd
    • 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
    • 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 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