summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-08-13PSCI: Migrate SPDs and TSP to the new platform and framework APISoby Mathew
The new PSCI frameworks mandates that the platform APIs and the various frameworks in Trusted Firmware migrate away from MPIDR based core identification to one based on core index. Deprecated versions of the old APIs are still present to provide compatibility but their implementations are not optimal. This patch migrates the various SPDs exisiting within Trusted Firmware tree and TSP to the new APIs. Change-Id: Ifc37e7071c5769b5ded21d0b6a071c8c4cab7836
2015-08-13PSCI: Pool platform_mem_init() in common ARM platforms codeSandrine Bailleux
Now that the FVP mailbox is no longer zeroed, the function platform_mem_init() does nothing both on FVP and on Juno. Therefore, this patch pools it as the default implementation on ARM platforms. Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91
2015-08-13PSCI: Use a single mailbox for warm reset for FVP and JunoSandrine Bailleux
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
2015-08-13PSCI: Demonstrate support for composite power statesSoby Mathew
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
2015-08-13PSCI: Migrate ARM reference platforms to new platform APISoby Mathew
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
2015-08-13PSCI: Migrate TF to the new platform API and CM helpersSoby Mathew
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
2015-08-13PSCI: Add deprecated API for SPD when compatibility is disabledSoby Mathew
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
2015-08-13PSCI: Switch to the new PSCI frameworksSoby Mathew
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
2015-08-13PSCI: Implement platform compatibility layerSoby Mathew
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
2015-08-13PSCI: Unify warm reset entry pointsSandrine Bailleux
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
2015-08-13PSCI: Add framework to handle composite power statesSoby Mathew
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
2015-08-13PSCI: Introduce new platform interface to describe topologySoby Mathew
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
2015-08-13PSCI: Introduce new platform and CM helper APIsSoby Mathew
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
2015-08-12Merge pull request #360 from vwadekar/tegra-platform-def-v2danh-arm
Tegra: fix PLATFORM_{MAX_AFFLVL|CORE_COUNT|NUM_AFFS} macros
2015-08-12Merge pull request #357 from vwadekar/tegra-bl31-memmap-fixdanh-arm
Tegra: memmap the actual memory available for BL31
2015-08-12Tegra: fix PLATFORM_{CORE_COUNT|NUM_AFFS} macrosVarun Wadekar
This patch fixes the following macros for Tegra SoCs. * PLATFORM_CORE_COUNT: PLATFORM_CLUSTER_COUNT * PLATFORM_MAX_CPUS_PER_CLUSTER * PLATFORM_NUM_AFFS: PLATFORM_CORE_COUNT + PLATFORM_CLUSTER_COUNT + 1 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-08-11Merge pull request #356 from mtk09422/mt8173-support-v3danh-arm
Mt8173 support v3
2015-08-11Tegra: memmap the actual memory available for BL31Varun Wadekar
On Tegra SoCs, the TZDRAM contains the BL31 and BL32 images. This patch uses only the actual memory available for BL31 instead of mapping the entire TZDRAM. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-08-11Initial platform port for MediaTek mt8173CC Ma
- Boot up 4 cores. - Add a generic UART driver. - Add generic CPU helper functions - Supoort suspend - Add system_off & system_reset implementation - Add crash console reporting implementation - Add get_sys_suspend_power_state() for PSCI 1.0 SYSTEM_SUSPEND - Add Mediatek SIP runtime service - Add delay timer platform implementation Change-Id: I44138249f115ee10b9cbd26fdbc2dd3af04d825f Signed-off-by: CC Ma <cc.ma@mediatek.com> Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
2015-08-05PSCI: Remove references to affinity based power managementSoby Mathew
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
2015-08-05PSCI: Invoke PM hooks only for the highest levelSoby Mathew
This patch optimizes the invocation of the platform power management hooks for ON, OFF and SUSPEND such that they are called only for the highest affinity level which will be powered off/on. Earlier, the hooks were being invoked for all the intermediate levels as well. This patch requires that the platforms migrate to the new semantics of the PM hooks. It also removes the `state` parameter from the pm hooks as the `afflvl` parameter now indicates the highest affinity level for which power management operations are required. Change-Id: I57c87931d8a2723aeade14acc710e5b78ac41732
2015-08-05PSCI: Create new directory to implement new frameworksSoby Mathew
This patch creates a copy of the existing PSCI files and related psci.h and platform.h header files in a new `PSCI1.0` directory. The changes for the new PSCI power domain topology and extended state-ID frameworks will be added incrementally to these files. This incremental approach will aid in review and in understanding the changes better. Once all the changes have been introduced, these files will replace the existing PSCI files. Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff
2015-08-05cortex_a53: Add A53 errata #826319, #836870Jimmy Huang
- Apply a53 errata #826319 to revision <= r0p2 - Apply a53 errata #836870 to revision <= r0p3 - Update docs/cpu-specific-build-macros.md for newly added errata build flags Change-Id: I44918e36b47dca1fa29695b68700ff9bf888865e Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
2015-08-05Add mmio utility functionsJimmy Huang
- Add mmio 16 bits read/write functions. - Add clear/set/clear-and-set utility functions. Change-Id: I00fdbdf24af537424f8666b1cadaa5f77a2a46ed Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
2015-08-05Fix build error with optimizations disabled (-O0)Juan Castillo
If Trusted Firmware is built with optimizations disabled (-O0), the linker throws the following error: undefined reference to 'xxx' Where 'xxx' is a raw inline function defined in a header file. The reason is that, with optimizations disabled, GCC may decide to skip the inlining. If that is the case, an external definition to the compilation unit must be provided. Because no external definition is present, the linker throws the error. This patch fixes the problem by declaring the following inline functions static, so the internal definition is used: inline void soc_css_security_setup(void) inline const arm_config_t *get_arm_config(void) Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f
2015-08-04Merge pull request #351 from davwan01/davwan01/docs-updatedanh-arm
Some minor fixes to interrupt-framework-design.md
2015-08-04Merge pull request #349 from jcastillo-arm/jc/tbb_cert_optdanh-arm
TBB: rework cert_create tool to follow a data driven approach
2015-08-04Merge pull request #348 from vwadekar/bootargs-tzdram-base-v2danh-arm
Bootargs tzdram base v2
2015-08-04Some minor fixes to interrupt-framework-design.mdDavid Wang
This patch fixes a pair of typos. The security state had been described as non-secure where it should have been secure. Change-Id: Ib3f424708a6b8e2084e5447f8507ea4e9c99ee79
2015-08-01docs: fix the command to compile BL31 on TegraVarun Wadekar
This patch fixes the command line used to compile BL31 on Tegra platforms. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-31Tegra132: set TZDRAM_BASE to 0xF5C00000Varun Wadekar
The TZDRAM base on the reference platform has been bumped up due to some BL2 memory cleanup. Platforms can also use a different TZDRAM base by setting TZDRAM_BASE=<value> in the build command line. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-31Tegra: retrieve BL32's bootargs from bl32_ep_infoVarun Wadekar
This patch removes the bootargs pointer from the platform params structure. Instead the bootargs are passed by the BL2 in the bl32_ep_info struct which is a part of the EL3 params struct. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-28Merge pull request #344 from vwadekar/tegra-mselect-restore-v2danh-arm
Tegra210: enable WRAP to INCR burst type conversions
2015-07-27Tegra210: enable WRAP to INCR burst type conversionsVarun Wadekar
The Memory Select Switch Controller routes any CPU transactions to the appropriate slave depending on the transaction address. During system suspend, it loses all config settings and hence the CPU has to restore them during resume. This patch restores the controller's settings for enabling WRAP to INCR burst type conversions on the master ports, for any incoming requests from the AXI slave ports. Tested by performing multiple system suspend cycles. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-24Merge pull request #342 from vwadekar/tlkd-delete-need-bl32-v1danh-arm
tlkd: delete 'NEED_BL32' build variable
2015-07-24tlkd: delete 'NEED_BL32' build variableVarun Wadekar
Remove the 'NEED_BL32' flag from the makefile. TLK compiles using a completely different build system and is present on the device as a binary blob. The NEED_BL32 flag does not influence the TLK load/boot sequence at all. Moreover, it expects that TLK binary be present on the host before we can compile BL31 support for Tegra. This patch removes the flag from the makefile and thus decouples both the build systems. Tested by booting TLK without the NEED_BL32 flag. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-24Merge pull request #341 from vwadekar/tegra-denver-plat-support-v3danh-arm
Tegra denver plat support v3
2015-07-24Tegra: modify 'BUILD_PLAT' to point to soc specific build dirsVarun Wadekar
This patch modifies the 'BUILD_PLAT' makefile variable to point to the soc specific build directory in order to allow each Tegra soc to have its own build directory. This way we can keep the build outputs separate and can keep multiple soc specific builds alive at the same time. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-24Tegra: Support for Tegra's T132 platformsVarun Wadekar
This patch implements support for T132 (Denver CPU) based Tegra platforms. The following features have been added: * SiP calls to switch T132 CPU's AARCH mode * Complete PSCI support, including 'System Suspend' * Platform specific MMIO settings * Locking of CPU vector registers Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-24Add "Project Denver" CPU supportVarun Wadekar
Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is fully ARMv8 architecture compatible. Each of the two Denver cores implements a 7-way superscalar microarchitecture (up to 7 concurrent micro-ops can be executed per clock), and includes a 128KB 4-way L1 instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2 cache, which services both cores. Denver implements an innovative process called Dynamic Code Optimization, which optimizes frequently used software routines at runtime into dense, highly tuned microcode-equivalent routines. These are stored in a dedicated, 128MB main-memory-based optimization cache. After being read into the instruction cache, the optimized micro-ops are executed, re-fetched and executed from the instruction cache as long as needed and capacity allows. Effectively, this reduces the need to re-optimize the software routines. Instead of using hardware to extract the instruction-level parallelism (ILP) inherent in the code, Denver extracts the ILP once via software techniques, and then executes those routines repeatedly, thus amortizing the cost of ILP extraction over the many execution instances. Denver also features new low latency power-state transitions, in addition to extensive power-gating and dynamic voltage and clock scaling based on workloads. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-24Tegra: implement per-SoC validate_power_state() handlerVarun Wadekar
The validate_power_state() handler checks the power_state for a valid afflvl and state id. Although the afflvl check is common, the state ids are implementation defined. This patch moves the handler to the tegra/soc folder to allow each SoC to validate the power_state for supported parameters. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-24Tegra: T210: include CPU files from SoC's platform.mkVarun Wadekar
This patch moves the inclusion of CPU code (A53, A57) to T210's makefile. This way we can reduce code size for Tegra platforms by including only the required CPU files. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Merge pull request #337 from vwadekar/tegra-misc-fixes-v3danh-arm
Tegra misc fixes v3
2015-07-17Tegra: Introduce config for enabling NS access to L2/CPUECTRL regsVarun Wadekar
A new config, ENABLE_NS_L2_CPUECTRL_RW_ACCESS, allows Tegra platforms to enable read/write access to the L2 and CPUECTRL registers. T210 is the only platform that needs to enable this config for now. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Tegra210: lock PMC registers holding CPU vector addressesVarun Wadekar
This patch locks access to the PMC registers which hold the CPU reset vector addresses. The PMC registers are used by the warmboot code and must be locked during boot/resume to avoid booting into custom firmware installed by unknown parties e.g. hackers. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Tegra: PMC: lock SCRATCH22 registerVarun Wadekar
The PMC Scratch22 register contains the CPU reset vector to be used by the warmboot code to power up the CPU while resuming from system suspend. This patch locks this PMC register to avoid any further writes. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Tegra: PMC: check if a CPU is already onlineVarun Wadekar
This patch checks if the target CPU is already online before proceeding with it's power ON sequence. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Tegra210: deassert CPU reset signals during power onVarun Wadekar
This patch de-asserts the CPU reset signals for each CPU as part of it's power on sequence. This is needed to get rid of the wait in BPMP firmware during SC7 exit. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Tegra: Fix the delay loop used during SC7 exitVarun Wadekar
This patch fixes the delay loop used to wake up the BPMP during SC7 exit. The earlier loop would fail just when the timer was about to wrap-around (e.g. when TEGRA_TMRUS_BASE is 0xfffffffe, the target value becomes 0, which would cause the loop to exit before it's expiry). Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2015-07-17Tegra: introduce delay timer supportVarun Wadekar
This patch introduces the backend required for implementing the delay timer API. Tegra has an on-chip free flowing us timer which can be used as the delay timer. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>