1. 02 Nov, 2015 2 commits
    • Juan Castillo's avatar
      Remove deprecated IO return definitions · e098e244
      Juan Castillo authored
      Patch 7e26fe1f deprecates IO specific return definitions in favour
      of standard errno codes. This patch removes those definitions
      and its usage from the IO framework, IO drivers and IO platform
      layer. Following this patch, standard errno codes must be used
      when checking the return value of an IO function.
      
      Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
      e098e244
    • Sandrine Bailleux's avatar
      Introduce print_entry_point_info() function · 68a68c92
      Sandrine Bailleux authored
      This patch introduces a new function called 'print_entry_point_info'
      that prints an entry_point_t structure for debugging purposes.
      As such, it can be used to display the entry point address, SPSR and
      arguments passed from a firmware image to the next one.
      
      This function is now called in the following images transitions:
       - BL1 to BL2
       - BL1 to BL31
       - BL31 to the next image (typically BL32 or BL33)
      
      The following changes have been introduced:
      
       - Fix the output format of the SPSR value : SPSR is a 32-bit value,
         not a 64-bit one.
      
       - Print all arguments values.
         The entry_point_info_t structure allows to pass up to 8 arguments.
         In most cases, only the first 2 arguments were printed.
         print_entry_point_info() now prints all of them as 'VERBOSE'
         traces.
      
      Change-Id: Ieb384bffaa7849e6cb95a01a47c0b7fc2308653a
      68a68c92
  2. 30 Oct, 2015 3 commits
    • Soby Mathew's avatar
      Include xlat_tables.h in plat_arm.h · 8f6623f0
      Soby Mathew authored
      This patch fixes a compilation issue for platforms that are aligned to ARM
      Standard platforms and include the `plat_arm.h` header in their platform port.
      The compilation would fail for such a platform because `xlat_tables.h` which
      has the definition for `mmap_region_t` is not included in `plat_arm.h`. This
      patch fixes this by including `xlat_tables.h` in `plat_arm.h` header.
      
      Fixes ARM-Software/tf-issues#318
      
      Change-Id: I75f990cfb4078b3996fc353c8cd37c9de61d555e
      8f6623f0
    • Soby Mathew's avatar
      Support PSCI SYSTEM SUSPEND on Juno · c1bb8a05
      Soby Mathew authored
      This patch adds the capability to power down at system power domain level
      on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
      are modified to add support for power management operations at system
      power domain level. A new helper for populating `get_sys_suspend_power_state`
      handler in plat_psci_ops is defined. On entering the system suspend state,
      the SCP powers down the SYSTOP power domain on the SoC and puts the memory
      into retention mode. On wakeup from the power down, the system components
      on the CSS will be reinitialized by the platform layer and the PSCI client
      is responsible for restoring the context of these system components.
      
      According to PSCI Specification, interrupts targeted to cores in PSCI CPU
      SUSPEND should be able to resume it. On Juno, when the system power domain
      is suspended, the GIC is also powered down. The SCP resumes the final core
      to be suspend when an external wake-up event is received. But the other
      cores cannot be woken up by a targeted interrupt, because GIC doesn't
      forward these interrupts to the SCP. Due to this hardware limitation,
      we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
      level to cluster power domain level in `juno_validate_power_state()`
      and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.
      
      A system power domain resume helper `arm_system_pwr_domain_resume()` is
      defined for ARM standard platforms which resumes/re-initializes the
      system components on wakeup from system suspend. The security setup also
      needs to be done on resume from system suspend, which means
      `plat_arm_security_setup()` must now be included in the BL3-1 image in
      addition to previous BL images if system suspend need to be supported.
      
      Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
      c1bb8a05
    • Soby Mathew's avatar
      CSS: Implement topology support for System power domain · 5f3a6030
      Soby Mathew authored
      This patch implements the necessary topology changes for supporting
      system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
      PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
      specific. In addition, the `arm_power_domain_tree_desc[]` and
      `arm_pm_idle_states[]` are modified to support the system power domain
      at level 2. With this patch, even though the power management operations
      involving the system power domain will not return any error, the platform
      layer will silently ignore any operations to the power domain. The actual
      power management support for the system power domain will be added later.
      
      Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
      5f3a6030
  3. 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
  4. 23 Oct, 2015 2 commits
    • Juan Castillo's avatar
      Use standard errno definitions in load_auth_image() · 78460a05
      Juan Castillo authored
      This patch replaces custom definitions used as return values for
      the load_auth_image() function with standard error codes defined
      in errno.h. The custom definitions have been removed.
      
      It also replaces the usage of IO framework error custom definitions,
      which have been deprecated. Standard errno definitions are used
      instead.
      
      Change-Id: I1228477346d3876151c05b470d9669c37fd231be
      78460a05
    • Juan Castillo's avatar
      IO Framework: use standard errno codes as return values · 7e26fe1f
      Juan Castillo authored
      This patch redefines the values of IO_FAIL, IO_NOT_SUPPORTED and
      IO_RESOURCES_EXHAUSTED to match the corresponding definitions in
      errno.h:
      
          #define IO_FAIL                     (-ENOENT)
          #define IO_NOT_SUPPORTED            (-ENODEV)
          #define IO_RESOURCES_EXHAUSTED      (-ENOMEM)
      
      NOTE: please note that the IO_FAIL, IO_NOT_SUPPORTED and
      IO_RESOURCES_EXHAUSTED definitions are considered deprecated
      and their usage should be avoided. Callers should rely on errno.h
      definitions when checking the return values of IO functions.
      
      Change-Id: Ic8491aa43384b6ee44951ebfc053a3ded16a80be
      7e26fe1f
  5. 20 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Reorganise PSCI PM handler setup on ARM Standard platforms · 785fb92b
      Soby Mathew authored
      This patch does the following reorganization to psci power management (PM)
      handler setup for ARM standard platform ports :
      
      1. The mailbox programming required during `plat_setup_psci_ops()` is identical
         for all ARM platforms. Hence the implementation of this API is now moved
         to the common `arm_pm.c` file. Each ARM platform now must define the
         PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
         as ARM_SHARED_RAM_BASE.
      
      2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
         exported via `plat_arm_psci_pm_ops`. This allows the common implementation
         of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
         In the case of CSS platforms, a default weak implementation of the same is
         provided in `css_pm.c` which can be overridden by each CSS platform.
      
      3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
         made library functions and a new header file `css_pm.h` is added to export
         these generic PM handlers. This allows the platform to reuse the
         adequate CSS PM handlers and redefine others which need to be customized
         when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
      
      Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
      785fb92b
  6. 19 Oct, 2015 1 commit
    • Sandrine Bailleux's avatar
      Make CASSERT() macro callable from anywhere · c17a4dc3
      Sandrine Bailleux authored
      The CASSERT() macro introduces a typedef for the sole purpose of
      triggering a compilation error if the condition to check is false.
      This typedef is not used afterwards. As a consequence, when the
      CASSERT() macro is called from withing a function block, the compiler
      complains and outputs the following error message:
      
        error: typedef 'msg' locally defined but not used [-Werror=unused-local-typedefs]
      
      This patch adds the "unused" attribute for the aforementioned
      typedef. This silences the compiler warning and thus makes the
      CASSERT() macro callable from within function blocks as well.
      
      Change-Id: Ie36b58fcddae01a21584c48bb6ef43ec85590479
      c17a4dc3
  7. 30 Sep, 2015 1 commit
    • Varun Wadekar's avatar
      Send power management events to the Trusted OS (TLK) · cb790c5e
      Varun Wadekar authored
      
      
      This patch adds PM handlers to TLKD for the system suspend/resume and
      system poweroff/reset cases. TLK expects all SMCs through a single
      handler, which then fork out into multiple handlers depending on the
      SMC. We tap into the same single entrypoint by restoring the S-EL1
      context before passing the PM event via register 'x0'. On completion
      of the PM event, TLK sends a completion SMC and TLKD then moves on
      with the PM process.
      Signed-off-by: default avatarVarun Wadekar <vwadekar@nvidia.com>
      cb790c5e
  8. 28 Sep, 2015 1 commit
    • Sandrine Bailleux's avatar
      Bug fix in the SP804 dual timer driver · 54312877
      Sandrine Bailleux authored
      The generic delay timer driver expects a pointer to a timer_ops_t
      structure containing the specific timer driver information. It
      doesn't make a copy of the structure, instead it just keeps the
      pointer. Therefore, this pointer must remain valid over time.
      
      The SP804 driver doesn't satisfy this requirement. The
      sp804_timer_init() macro creates a temporary instanciation of the
      timer_ops_t structure on the fly and passes it to the generic
      delay timer. When this temporary instanciation gets deallocated,
      the generic delay timer is left with a pointer to invalid data.
      
      This patch fixes this bug by statically allocating the SP804
      timer_ops_t structure.
      
      Change-Id: I8fbf75907583aef06701e3fd9fabe0b2c9bc95bf
      54312877
  9. 14 Sep, 2015 2 commits
    • Achin Gupta's avatar
      Add a generic driver for ARM CCN IP · fd6007de
      Achin Gupta authored
      This patch adds a device driver which can be used to program the following
      aspects of ARM CCN IP:
      
      1. Specify the mapping between ACE/ACELite/ACELite+DVM/CHI master interfaces and
         Request nodes.
      2. Add and remove master interfaces from the snoop and dvm
         domains.
      3. Place the L3 cache in a given power state.
      4. Configuring system adress map and enabling 3 SN striping mode of memory
         controller operation.
      
      Change-Id: I0f665c6a306938e5b66f6a92f8549b529aa8f325
      fd6007de
    • 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
  10. 11 Sep, 2015 5 commits
    • Vikram Kanigiri's avatar
      Update ARM platform ports to use new bakery lock apis. · e25e6f41
      Vikram Kanigiri authored
      This patch updates ARM platform ports to use the new unified bakery locks
      API. The caller does not have to use a different bakery lock API depending upon
      the value of the USE_COHERENT_MEM build option.
      
      NOTE: THIS PATCH CAN BE USED AS A REFERENCE TO UPDATE OTHER PLATFORM PORTS.
      
      Change-Id: I1b26afc7c9a9808a6040eb22f603d30192251da7
      e25e6f41
    • 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
    • Vikram Kanigiri's avatar
      Separate CSS security setup from SOC security setup · 883852ca
      Vikram Kanigiri authored
      Currently, on ARM platforms(ex. Juno) non-secure access to specific
      peripheral regions, config registers which are inside and outside CSS
      is done in the soc_css_security_setup(). This patch separates the CSS
      security setup from the SOC security setup in the css_security_setup().
      
      The CSS security setup involves programming of the internal NIC to
      provide access to regions inside the CSS. This is needed only in
      Juno, hence Juno implements it in its board files as css_init_nic400().
      
      Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
      883852ca
    • Vikram Kanigiri's avatar
      Define the Non-Secure timer frame ID for ARM platforms · 4b1439c5
      Vikram Kanigiri authored
      On Juno and FVP platforms, the Non-Secure System timer corresponds
      to frame 1. However, this is a platform-specific decision and it
      shouldn't be hard-coded. Hence, this patch introduces
      PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
      to specify the correct non-secure timer frame.
      
      Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba
      4b1439c5
    • Vikram Kanigiri's avatar
      Re-factor definition of TZC-400 base address · e86c1ff0
      Vikram Kanigiri authored
      This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
      support different TrustZone Controller base addresses across ARM platforms.
      
      Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd
      e86c1ff0
  11. 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
  12. 02 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Ensure BL2 security state is secure · a2f8b166
      Vikram Kanigiri authored
      BL2 loads secure runtime code(BL3-1, BL3-2) and hence it has to
      run in secure world otherwise BL3-1/BL3-2 have to execute from
      non-secure memory. Hence, This patch removes the change_security_state()
      call in bl1_run_bl2() and replaces it with an assert to confirm
      the BL2 as secure.
      
      Fixes ARM-software/tf-issues#314
      
      Change-Id: I611b83f5c4090e58a76a2e950b0d797b46df3c29
      a2f8b166
  13. 01 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Configure all secure interrupts on ARM platforms · a7270d35
      Vikram Kanigiri authored
      ARM TF configures all interrupts as non-secure except those which
      are present in irq_sec_array. This patch updates the irq_sec_array
      with the missing secure interrupts for ARM platforms.
      
      It also updates the documentation to be inline with the latest
      implementation.
      
      Fixes ARM-software/tf-issues#312
      
      Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
      a7270d35
  14. 24 Aug, 2015 1 commit
  15. 20 Aug, 2015 1 commit
    • Juan Castillo's avatar
      TBB: abort boot if BL3-2 cannot be authenticated · fedbc049
      Juan Castillo authored
      BL3-2 image (Secure Payload) is optional. If the image cannot be
      loaded a warning message is printed and the boot process continues.
      According to the TBBR document, this behaviour should not apply in
      case of an authentication error, where the boot process should be
      aborted.
      
      This patch modifies the load_auth_image() function to distinguish
      between a load error and an authentication error. The caller uses
      the return value to abort the boot process or continue.
      
      In case of authentication error, the memory region used to store
      the image is wiped clean.
      
      Change-Id: I534391d526d514b2a85981c3dda00de67e0e7992
      fedbc049
  16. 13 Aug, 2015 15 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: Add documentation and fix plat_is_my_cpu_primary() · 58523c07
      Soby Mathew authored
      This patch adds the necessary documentation updates to porting_guide.md
      for the changes in the platform interface mandated as a result of the new
      PSCI Topology and power state management frameworks. It also adds a
      new document `platform-migration-guide.md` to aid the migration of existing
      platform ports to the new API.
      
      The patch fixes the implementation and callers of
      plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
      the function signature rather than x0 which was used previously.
      
      Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
      58523c07
    • Soby Mathew's avatar
      PSCI: Validate non secure entrypoint on ARM platforms · f9e858b1
      Soby Mathew authored
      This patch implements the platform power managment handler to verify
      non secure entrypoint for ARM platforms. The handler ensures that the
      entry point specified by the normal world during CPU_SUSPEND, CPU_ON
      or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
      DRAM.
      
      Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
      f9e858b1
    • 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
    • Sandrine Bailleux's avatar
      PSCI: Use a single mailbox for warm reset for FVP and Juno · 804040d1
      Sandrine Bailleux authored
      Since there is a unique warm reset entry point, the FVP and Juno
      port can use a single mailbox instead of maintaining one per core.
      The mailbox gets programmed only once when plat_setup_psci_ops()
      is invoked during PSCI initialization. This means mailbox is not
      zeroed out during wakeup.
      
      Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
      804040d1
    • Soby Mathew's avatar
      PSCI: Demonstrate support for composite power states · 2204afde
      Soby Mathew authored
      This patch adds support to the Juno and FVP ports for composite power states
      with both the original and extended state-id power-state formats. Both the
      platform ports use the recommended state-id encoding as specified in
      Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
      ARM_RECOM_STATE_ID_ENC is used to include this support.
      
      By default, to maintain backwards compatibility, the original power state
      parameter format is used and the state-id field is expected to be zero.
      
      Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
      2204afde
    • Soby Mathew's avatar
      PSCI: Migrate ARM reference platforms to new platform API · 38dce70f
      Soby Mathew authored
      This patch migrates ARM reference platforms, Juno and FVP, to the new platform
      API mandated by the new PSCI power domain topology and composite power state
      frameworks. The platform specific makefiles now exports the build flag
      ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
      
      Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
      38dce70f
    • 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
    • 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
  17. 05 Aug, 2015 1 commit
    • 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