1. 27 Feb, 2019 1 commit
    • Antonio Nino Diaz's avatar
      BL31: Enable pointer authentication support · 88cfd9a6
      Antonio Nino Diaz authored
      
      
      The size increase after enabling options related to ARMv8.3-PAuth is:
      
      +----------------------------+-------+-------+-------+--------+
      |                            |  text |  bss  |  data | rodata |
      +----------------------------+-------+-------+-------+--------+
      | CTX_INCLUDE_PAUTH_REGS = 1 |  +192 | +1536 |   +0  |   +0   |
      |                            |  0.3% |  3.1% |       |        |
      +----------------------------+-------+-------+-------+--------+
      | ENABLE_PAUTH = 1           | +1848 | +1536 |  +16  |   +0   |
      |                            |  3.3% |  3.1% |  3.1% |        |
      +----------------------------+-------+-------+-------+--------+
      
      Results calculated with the following build configuration:
      
          make PLAT=fvp SPD=tspd DEBUG=1 \
          SDEI_SUPPORT=1                 \
          EL3_EXCEPTION_HANDLING=1       \
          TSP_NS_INTR_ASYNC_PREEMPT=1    \
          CTX_INCLUDE_PAUTH_REGS=1       \
          ENABLE_PAUTH=1
      
      Change-Id: I43db7e509a4f39da6599ec2faa690d197573ec1b
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      88cfd9a6
  2. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  3. 08 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Standardise header guards across codebase · c3cf06f1
      Antonio Nino Diaz authored
      
      
      All identifiers, regardless of use, that start with two underscores are
      reserved. This means they can't be used in header guards.
      
      The style that this project is now to use the full name of the file in
      capital letters followed by 'H'. For example, for a file called
      "uart_example.h", the header guard is UART_EXAMPLE_H.
      
      The exceptions are files that are imported from other projects:
      
      - CryptoCell driver
      - dt-bindings folders
      - zlib headers
      
      Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c3cf06f1
  4. 30 Aug, 2018 1 commit
  5. 22 Aug, 2018 1 commit
  6. 20 Aug, 2018 2 commits
  7. 04 May, 2018 3 commits
    • Jeenu Viswambharan's avatar
      RAS: Allow individual interrupt registration · ca6d9185
      Jeenu Viswambharan authored
      
      
      EHF currently allows for registering interrupt handlers for a defined
      priority ranges. This is primarily targeted at various EL3 dispatchers
      to own ranges of secure interrupt priorities in order to delegate
      execution to lower ELs.
      
      The RAS support added by earlier patches necessitates registering
      handlers based on interrupt number so that error handling agents shall
      receive and handle specific Error Recovery or Fault Handling interrupts
      at EL3.
      
      This patch introduces a macro, RAS_INTERRUPTS() to declare an array of
      interrupt numbers and handlers. Error handling agents can use this macro
      to register handlers for individual RAS interrupts. The array is
      expected to be sorted in the increasing order of interrupt numbers.
      
      As part of RAS initialisation, the list of all RAS interrupts are sorted
      based on their ID so that, given an interrupt, its handler can be looked
      up with a simple binary search.
      
      For an error handling agent that wants to handle a RAS interrupt,
      platform must:
      
        - Define PLAT_RAS_PRI to be the priority of all RAS exceptions.
      
        - Enumerate interrupts to have the GIC driver program individual EL3
          interrupts to the required priority range. This is required by EHF
          even before this patch.
      
      Documentation to follow.
      
      Change-Id: I9471e4887ff541f8a7a63309e9cd8f771f76aeda
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      ca6d9185
    • Jeenu Viswambharan's avatar
      AArch64: Introduce RAS handling · 14c6016a
      Jeenu Viswambharan authored
      
      
      RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
      extensions to base ARMv8.0 architecture.
      
      This patch adds build system support to enable RAS features in ARM
      Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for
      this.
      
      With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is
      inserted at all EL3 vector entry and exit. ESBs will synchronize pending
      external aborts before entering EL3, and therefore will contain and
      attribute errors to lower EL execution. Any errors thus synchronized are
      detected via. DISR_EL1 register.
      
      When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1.
      
      Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      14c6016a
    • 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
  8. 28 Feb, 2018 2 commits
  9. 27 Feb, 2018 1 commit
    • Jeenu Viswambharan's avatar
      EHF: Introduce preempted return code parameter to ehf_allow_ns_preemption() · af34cd72
      Jeenu Viswambharan authored
      
      
      When a Yielding SMC is preempted, it's possible that Non-secure world is
      resumed afterwards. In this case, Non-secure execution would find itself
      in a state where the SMC has returned. However, the dispatcher might not
      get an opportunity to populate the corrected return code for having
      been preempted, and therefore the caller of the Yielding SMC cannot
      reliably determine whether the SMC had successfully completed or had
      been preempted.
      
      To solve this, this patch introduces a new parameter to the
      ehf_allow_ns_preemption() API. An SPD, through this parameter, would
      provide the expected error code when a Yielding SMC is preempted. EHF
      can then populate the specified value in x0 of the Non-secure context so
      that the caller of the Yielding SMC correctly identifies the SMC return
      as a preemption.
      
      Documentation updates to follow.
      
      Change-Id: Ia9c3f8f03f9d72d81aa235eaae2ee0374b972e1e
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      af34cd72
  10. 06 Feb, 2018 1 commit
  11. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      BL31: Program Priority Mask for SMC handling · 3d732e23
      Jeenu Viswambharan authored
      
      
      On GICv3 systems, as a side effect of adding provision to handle EL3
      interrupts (unconditionally routing FIQs to EL3), pending Non-secure
      interrupts (signalled as FIQs) may preempt execution in lower Secure ELs
      [1]. This will inadvertently disrupt the semantics of Fast SMC
      (previously called Atomic SMC) calls.
      
      To retain semantics of Fast SMCs, the GIC PMR must be programmed to
      prevent Non-secure interrupts from preempting Secure execution. To that
      effect, two new functions in the Exception Handling Framework subscribe
      to events introduced in an earlier commit:
      
        - Upon 'cm_exited_normal_world', the Non-secure PMR is stashed, and
          the PMR is programmed to the highest Non-secure interrupt priority.
      
        - Upon 'cm_entering_normal_world', the previously stashed Non-secure
          PMR is restored.
      
      The above sequence however prevents Yielding SMCs from being preempted
      by Non-secure interrupts as intended. To facilitate this, the public API
      exc_allow_ns_preemption() is introduced that programs the PMR to the
      original Non-secure PMR value. Another API
      exc_is_ns_preemption_allowed() is also introduced to check if
      exc_allow_ns_preemption() had been called previously.
      
      API documentation to follow.
      
      [1] On GICv2 systems, this isn't a problem as, unlike GICv3, pending NS
          IRQs during Secure execution are signalled as IRQs, which aren't
          routed to EL3.
      
      Change-Id: Ief96b162b0067179b1012332cd991ee1b3051dd0
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      3d732e23
    • Jeenu Viswambharan's avatar
      BL31: Introduce Exception Handling Framework · 21b818c0
      Jeenu Viswambharan authored
      
      
      EHF is a framework that allows dispatching of EL3 interrupts to their
      respective handlers in EL3.
      
      This framework facilitates the firmware-first error handling policy in
      which asynchronous exceptions may be routed to EL3. Such exceptions may
      be handed over to respective exception handlers. Individual handlers
      might further delegate exception handling to lower ELs.
      
      The framework associates the delegated execution to lower ELs with a
      priority value. For interrupts, this corresponds to the priorities
      programmed in GIC; for other types of exceptions, viz. SErrors or
      Synchronous External Aborts, individual dispatchers shall explicitly
      associate delegation to a secure priority. In order to prevent lower
      priority interrupts from preempting higher priority execution, the
      framework provides helpers to control preemption by virtue of
      programming Priority Mask register in the interrupt controller.
      
      This commit allows for handling interrupts targeted at EL3. Exception
      handlers own interrupts by assigning them a range of secure priorities,
      and registering handlers for each priority range it owns.
      
      Support for exception handling in BL31 image is enabled by setting the
      build option EL3_EXCEPTION_HANDLING=1.
      
      Documentation to follow.
      
      NOTE: The framework assumes the priority scheme supported by platform
      interrupt controller is compliant with that of ARM GIC architecture (v2
      or later).
      
      Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      21b818c0
  12. 16 Oct, 2017 2 commits
    • Jeenu Viswambharan's avatar
      GIC: Allow specifying interrupt properties · c639e8eb
      Jeenu Viswambharan authored
      
      
      The GIC driver initialization currently allows an array of interrupts to
      be configured as secure. Future use cases would require more interrupt
      configuration other than just security, such as priority.
      
      This patch introduces a new interrupt property array as part of both
      GICv2 and GICv3 driver data. The platform can populate the array with
      interrupt numbers and respective properties. The corresponding driver
      initialization iterates through the array, and applies interrupt
      configuration as required.
      
      This capability, and the current way of supplying array (or arrays, in
      case of GICv3) of secure interrupts, are however mutually exclusive.
      Henceforth, the platform should supply either:
      
        - A list of interrupts to be mapped as secure (the current way).
          Platforms that do this will continue working as they were. With this
          patch, this scheme is deprecated.
      
        - A list of interrupt properties (properties include interrupt group).
          Individual interrupt properties are specified via. descriptors of
          type 'interrupt_prop_desc_t', which can be populated with the macro
          INTR_PROP_DESC().
      
      A run time assert checks that the platform doesn't specify both.
      
      Henceforth the old scheme of providing list of secure interrupts is
      deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require
      that the interrupt properties are supplied instead of an array of secure
      interrupts.
      
      Add a section to firmware design about configuring secure interrupts.
      
      Fixes ARM-software/tf-issues#262
      
      Change-Id: I8eec29e72eb69dbb6bce77879febf32c95376942
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      c639e8eb
    • Jeenu Viswambharan's avatar
      GIC: Add API to set interrupt routing · fc529fee
      Jeenu Viswambharan authored
      
      
      SPIs can be routed to either a specific PE, or to any one of all
      available PEs.
      
      API documentation updated.
      
      Change-Id: I28675f634568aaf4ea1aa8aa7ebf25b419a963ed
      Co-authored-by: default avatarYousuf A <yousuf.sait@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      fc529fee
  13. 15 Jun, 2017 1 commit
  14. 03 May, 2017 1 commit
  15. 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
  16. 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
  17. 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
  18. 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
  19. 14 Jan, 2016 1 commit
  20. 13 Jan, 2016 1 commit
    • Soby Mathew's avatar
      Use designated initialization in DECLARE_RT_SVC macro · 7b3aabc0
      Soby Mathew authored
      This patch changes the anonymous initialization of `rt_svc_desc_t` structure
      by the `DECLARE_RT_SVC` macro to designated initialization. This makes the
      code more robust and less sensitive to potential changes to the
      `rt_svc_desc_t` structure.
      
      Change-Id: If6f1586730c0d29d92ef09e07eff7dd0d22857c7
      7b3aabc0
  21. 21 Dec, 2015 1 commit
  22. 09 Dec, 2015 2 commits
    • Yatharth Kochar's avatar
      Move context management code to common location · bbf8f6f9
      Yatharth Kochar authored
      The upcoming Firmware Update feature needs transitioning across
      Secure/Normal worlds to complete the FWU process and hence requires
      context management code to perform this task.
      
      Currently context management code is part of BL31 stage only.
      This patch moves the code from (include)/bl31 to (include)/common.
      Some function declarations/definitions and macros have also moved
      to different files to help code sharing.
      
      Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
      bbf8f6f9
    • Soby Mathew's avatar
      Enable support for EL3 interrupt in IMF · 4e0e0f44
      Soby Mathew authored
      This patch enables support for EL3 interrupts in the Interrupt Management
      Framework (IMF) of ARM Trusted Firmware. Please note that although the
      registration of the EL3 interrupt type is now supported, it has not been
      tested on any of the ARM Standard platforms.
      
      Change-Id: If4dcdc7584621522a2f3ea13ea9b1ad0a76bb8a1
      4e0e0f44
  23. 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
  24. 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
  25. 13 Aug, 2015 7 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: Migrate TF to the new platform API and CM helpers · 85a181ce
      Soby Mathew authored
      This patch migrates the rest of Trusted Firmware excluding Secure Payload and
      the dispatchers to the new platform and context management API. The per-cpu
      data framework APIs which took MPIDRs as their arguments are deleted and only
      the ones which take core index as parameter are retained.
      
      Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
      85a181ce
    • 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
    • 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