| #
bc3dac6c |
| 27-Nov-2025 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge "fix(cpufeat): require FEAT_AMUv1p1 to enable the auxiliary counters" into integration
|
| #
6edbd2d6 |
| 10-Nov-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(cpufeat): require FEAT_AMUv1p1 to enable the auxiliary counters
The auxiliary counters are a feature of FEAT_AMUv1p1 but it's possible to enable them (ENABLE_AMU_AUXILIARY_COUNTERS=1) without en
fix(cpufeat): require FEAT_AMUv1p1 to enable the auxiliary counters
The auxiliary counters are a feature of FEAT_AMUv1p1 but it's possible to enable them (ENABLE_AMU_AUXILIARY_COUNTERS=1) without enabling FEAT_AMUv1p1. As a result, the AMU_RESTRICT_COUNTERS may not take effect, making this configuration potentially insecure.
Fix this by adding a constraints and rejigging auxiliary counter enables such that they only happen when FEAT_AMUv1p1 has been enabled so that's more apparent.
Change-Id: I5b5061d603013598f07d70401d68915c016a1a1b Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
42ddca15 |
| 23-Oct-2025 |
Bipin Ravi <bipin.ravi@arm.com> |
Merge "fix(tc): force specifying TARGET_PLATFORM" into integration
|
| #
81fece21 |
| 20-Oct-2025 |
Olivier Deprez <olivier.deprez@arm.com> |
fix(tc): force specifying TARGET_PLATFORM
tc platform.mk has assumptions about TARGET_PLATFORM to be properly defined.
For PLAT=tc if not specifying TARGET_PLATFORM on build command line, it emits
fix(tc): force specifying TARGET_PLATFORM
tc platform.mk has assumptions about TARGET_PLATFORM to be properly defined.
For PLAT=tc if not specifying TARGET_PLATFORM on build command line, it emits the cryptic error message:
expr: syntax error: unexpected argument \u20182\u2019 plat/arm/board/tc/platform.mk:75: *** Platform tc is no longer available.. Stop.
Add an assert such that the error becomes:
plat/arm/board/tc/platform.mk:9: *** TARGET_PLATFORM must not be empty. Stop.
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: If53a01b537768a806495d8dc1c5096059eafa490
show more ...
|
| #
ddc1fcee |
| 26-Sep-2025 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "refactor(arm/common): gate coherency behind flag" into integration
|
| #
36fbcf4d |
| 17-Sep-2025 |
Ahmed Azeem <ahmed.azeem@arm.com> |
refactor(arm/common): gate coherency behind flag
Introduce a macro guard so platform coherency functions are only compiled when HW_ASSISTED_COHERENCY is 0 (disabled). Many platforms enable HW-assist
refactor(arm/common): gate coherency behind flag
Introduce a macro guard so platform coherency functions are only compiled when HW_ASSISTED_COHERENCY is 0 (disabled). Many platforms enable HW-assisted coherency by default, so compiling empty definitions is unnecessary.
This refactor removes those empty functions for Arm CSS platforms.
Change-Id: I102ead46960e9da2d8b968f60cbfd3e5e5da1096 Signed-off-by: Ahmed Azeem <ahmed.azeem@arm.com>
show more ...
|
| #
cd30f9f8 |
| 18-Sep-2025 |
Govindraj Raja <govindraj.raja@arm.com> |
Merge "chore(tc): align core names to Arm Lumex" into integration
|
| #
7dae0451 |
| 04-Sep-2025 |
Min Yao Ng <minyao.ng@arm.com> |
chore(tc): align core names to Arm Lumex
Adopt core names aligned to Arm Lumex [1]
Nevis => C1-Nano Gelas => C1-Pro Travis => C1-Ultra Alto => C1-Premium
C1-Pro TRM: https://developer.arm.com/docu
chore(tc): align core names to Arm Lumex
Adopt core names aligned to Arm Lumex [1]
Nevis => C1-Nano Gelas => C1-Pro Travis => C1-Ultra Alto => C1-Premium
C1-Pro TRM: https://developer.arm.com/documentation/107771/0102/ C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/ C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/ C1-Nano TRM: https://developer.arm.com/documentation/107753/0001/
[1]: https://www.arm.com/product-filter?families=c1%20cpus https://www.arm.com/products/mobile/compute-subsystems/lumex
Signed-off-by: Min Yao Ng <minyao.ng@arm.com> Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: Id4b487ef6a6fd1b00b75b09c5d06d81bce50a15d Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
|
| #
35b2bbf4 |
| 28-Jul-2025 |
Manish Pandey <manish.pandey2@arm.com> |
Merge changes from topic "bk/pabandon_cleanup" into integration
* changes: feat(cpus): add pabandon support to the Alto cpu feat(psci): optimise clock init on a pabandon feat(psci): check that
Merge changes from topic "bk/pabandon_cleanup" into integration
* changes: feat(cpus): add pabandon support to the Alto cpu feat(psci): optimise clock init on a pabandon feat(psci): check that CPUs handled a pabandon feat(psci): make pabandon support generic refactor(psci): unify coherency exit between AArch64 and AArch32 refactor(psci): absorb psci_power_down_wfi() into common code refactor(platforms): remove usage of psci_power_down_wfi fix(cm): disable SPE/TRBE correctly
show more ...
|
| #
04c39e46 |
| 24-Mar-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
feat(psci): make pabandon support generic
Support for aborted powerdowns does not require much dedicated code. Rather, it is largely a matter of orchestrating things to happen in the right order.
T
feat(psci): make pabandon support generic
Support for aborted powerdowns does not require much dedicated code. Rather, it is largely a matter of orchestrating things to happen in the right order.
The only exception to this are older secure world dispatchers, which assume that a CPU_SUSPEND call will be terminal and therefore can clobber context. This was patched over in common code and hidden behind a flag. This patch moves this to the dispatchers themselves.
Dispatchers that don't register svc_suspend{_finish} are unaffected. Those that do must save the NS context before clobbering it and restoring in only in case of a pabandon. Due to this operation being non-trivial, this patch makes the assumption that these dispatchers will only be present on hardware that does not support pabandon and therefore does not add any contexting for them. In case this assumption ever changes, asserts are added that should alert us of this change.
Change-Id: I94a907515b782b4d2136c0d274246cfe1d567c0e Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
9e7679ed |
| 23-Jun-2025 |
Govindraj Raja <govindraj.raja@arm.com> |
Merge "feat(tc): add support for configuring DSU settings" into integration
|
| #
fd4e6026 |
| 14-May-2025 |
Arvind Ram Prakash <arvind.ramprakash@arm.com> |
feat(tc): add support for configuring DSU settings
This patch allows tc platforms to update DSU CLUSTERPWRDN_EL1 and CLUSTERPWRCTLR_EL1 settings. TC22 and TC23 use the DSU-120. Currently we use the
feat(tc): add support for configuring DSU settings
This patch allows tc platforms to update DSU CLUSTERPWRDN_EL1 and CLUSTERPWRCTLR_EL1 settings. TC22 and TC23 use the DSU-120. Currently we use the reset values as default settings as per the DSU-120 TRM.
Reference: https://developer.arm.com/documentation/102547/0201
Change-Id: I48e0b5bd5881612e9b8b804948260f69c25c34d9 Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
show more ...
|
| #
f8901e38 |
| 23-Jun-2025 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "feat(dsu): support power control and autonomous powerdown config" into integration
|
| #
d52ff2b3 |
| 07-May-2025 |
Arvind Ram Prakash <arvind.ramprakash@arm.com> |
feat(dsu): support power control and autonomous powerdown config
This patch allows platforms to enable certain DSU settings to ensure memory retention and control over cache power requests. We also
feat(dsu): support power control and autonomous powerdown config
This patch allows platforms to enable certain DSU settings to ensure memory retention and control over cache power requests. We also move the driver out of css into drivers/arm. Platforms can configure the CLUSTERPWRCTLR and CLUSTERPWRDN registers [1] to improve power efficiency.
These registers enable finer-grained control of DSU power state transitions, including powerdown and retention.
IMP_CLUSTERPWRCTLR_EL1 provides: - Functional retention: Allows configuration of the duration of inactivity before the DSU uses CLUSTERPACTIVE to request functional retention.
- Cache power request: These bits are output on CLUSTERPACTIVE[19:16] to indicate to the power controller which cache portions must remain powered.
IMP_CLUSTERPWRDN_EL1 includes: - Powerdown: Triggers full cluster powerdown, including control logic.
- Memory retention: Requests memory retention mode, keeping L3 RAM contents while powering off the rest of the DSU.
The DSU-120 TRM [2] provides the full field definitions, which are used as references in the `dsu_driver_data` structure.
References: [1]: https://developer.arm.com/documentation/100453/latest/ [2]: https://developer.arm.com/documentation/102547/0201/?lang=en
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com> Change-Id: I2eba808b8f2a27797782a333c65dd092b03208fe
show more ...
|
| #
c76da4ec |
| 25-Apr-2025 |
Olivier Deprez <olivier.deprez@arm.com> |
Merge "chore(tc): remove TC2 platform variant" into integration
|
| #
139a5d05 |
| 18-Apr-2025 |
Madhukar Pappireddy <madhukar.pappireddy@arm.com> |
Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration
* changes: chore: fix preprocessor checks refactor: convert arm platforms to use the generic GIC driver refacto
Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration
* changes: chore: fix preprocessor checks refactor: convert arm platforms to use the generic GIC driver refactor(gic): promote most of the GIC driver to common code refactor: make arm_gicv2.c and arm_gicv3.c common refactor(fvp): use more arm generic code for gicv3
show more ...
|
| #
c5c54e20 |
| 07-Jan-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor: convert arm platforms to use the generic GIC driver
This reduces the code the platforms have to carry and makes their build rules a bit simpler.
The main benefit is that plat_my_core_pos(
refactor: convert arm platforms to use the generic GIC driver
This reduces the code the platforms have to carry and makes their build rules a bit simpler.
The main benefit is that plat_my_core_pos() no longer needs to be called within the driver, helping with performance a bit.
Change-Id: I0b0d1d36d20d67c41c8c9dc14ade11bda6d4a6af Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
35d18d8d |
| 07-Jan-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor: make arm_gicv2.c and arm_gicv3.c common
These files were meant to be platform specific, but they are generic enough that a range of platforms find them useful. However, refactoring them is
refactor: make arm_gicv2.c and arm_gicv3.c common
These files were meant to be platform specific, but they are generic enough that a range of platforms find them useful. However, refactoring them is difficult as their use is platform specific. So copy them to a generic place and redirect platforms to them.
The new copies will remain for compatibility for platforms that don't want to or can't take up upcoming refactors and the old copies can be drastically refactored to make them more widely applicable.
Change-Id: I056c8710cdda4d8a81b324d392762c29e02cdae1 Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
f036ddaf |
| 09-Apr-2025 |
Manish V Badarkhe <Manish.Badarkhe@arm.com> |
chore(tc): remove TC2 platform variant
Remove TC2 platform support which was deprecated in the last release.
Change-Id: Ibf4a94a0168151ebc66eaca044a143c51e974a1f Signed-off-by: Manish V Badarkhe <M
chore(tc): remove TC2 platform variant
Remove TC2 platform support which was deprecated in the last release.
Change-Id: Ibf4a94a0168151ebc66eaca044a143c51e974a1f Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
show more ...
|
| #
31ddca40 |
| 14-Apr-2025 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge "feat(psci): remove cpu context init by index" into integration
|
| #
ef738d19 |
| 21-Jun-2024 |
Manish Pandey <manish.pandey2@arm.com> |
feat(psci): remove cpu context init by index
Currently, the calling core (meaning the core which received the call to CPU_ON or the powerdown path of CPU_SUSPEND on the same core) is in charge of in
feat(psci): remove cpu context init by index
Currently, the calling core (meaning the core which received the call to CPU_ON or the powerdown path of CPU_SUSPEND on the same core) is in charge of initialising the context for the waking core (the warmboot entrypoint for both). This is convenient because the calling core can write the context while in coherency and the waking core will only need the context after its entered coherency. This avoids any cache maintenance and makes communication simple.
However, this has 3 main problems: a) asymmetric feature support is problematic - the calling core has no way of knowing the feature set of the waking core. If the two diverge, the architectural feature discovery via ID registers breaks down. We've thus far "fixed" this on a case by case basis which doesn't scale and introduces redundancy.
b) powerdown abandon (pabandon) introduces a contradiction - the calling core has to initialise the context for when the core wakes up, but should the core not powerdown it needs its old context intact. The only way to work around this is by keeping two copies of context which incurs a runtime and memory overhead.
c) cm_prepare_el3_exit[_ns]() doesn't have access to the entrypoint but needs it to make initialisation decisions. We can infer some of this from registers that have already been written but this is awkwardly limiting for what we can do. This also necessitates the split from the context initialisation.
We can solve all three by a making a core be in full ownership of its own context. The calling core then only writes entrypoint information and nothing else. The waking core then initialises its own context as it sees fit with full knowledge of the whole picture.
The only tricky bit is cache coherency - the waking core has to be able to coherently observe its new entrypoint. Calling cores will write to the shared region with coherent caches on. If we make sure to read the context only after the waking core has entered coherency, then we can avoid cache operations and let hardware handle everything.
We can skip the spsr check for FEAT_TCR2 as it doesn't make a difference. We can also skip enabling it twice from generic code.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com> Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: I86e7fe8b698191fc3b469e5ced1fd010f8754b0e
show more ...
|
| #
2e0354f5 |
| 25-Feb-2025 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge changes I3d950e72,Id315a8fe,Ib62e6e9b,I1d0475b2 into integration
* changes: perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root context perf(psci): get PMF timestamps wi
Merge changes I3d950e72,Id315a8fe,Ib62e6e9b,I1d0475b2 into integration
* changes: perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root context perf(psci): get PMF timestamps with no cache flushes if possible perf(amu): greatly simplify AMU context management perf(mpmm): greatly simplify MPMM enablement
show more ...
|
| #
83ec7e45 |
| 06-Nov-2024 |
Boyan Karatotev <boyan.karatotev@arm.com> |
perf(amu): greatly simplify AMU context management
The current code is incredibly resilient to updates to the spec and has worked quite well so far. However, recent implementations expose a weakness
perf(amu): greatly simplify AMU context management
The current code is incredibly resilient to updates to the spec and has worked quite well so far. However, recent implementations expose a weakness in that this is rather slow. A large part of it is written in assembly, making it opaque to the compiler for optimisations. The future proofness requires reading registers that are effectively `volatile`, making it even harder for the compiler, as well as adding lots of implicit barriers, making it hard for the microarchitecutre to optimise as well.
We can make a few assumptions, checked by a few well placed asserts, and remove a lot of this burden. For a start, at the moment there are 4 group 0 counters with static assignments. Contexting them is a trivial affair that doesn't need a loop. Similarly, there can only be up to 16 group 1 counters. Contexting them is a bit harder, but we can do with a single branch with a falling through switch. If/when both of these change, we have a pair of asserts and the feature detection mechanism to guard us against pretending that we support something we don't.
We can drop contexting of the offset registers. They are fully accessible by EL2 and as such are its responsibility to preserve on powerdown.
Another small thing we can do, is pass the core_pos into the hook. The caller already knows which core we're running on, we don't need to call this non-trivial function again.
Finally, knowing this, we don't really need the auxiliary AMUs to be described by the device tree. Linux doesn't care at the moment, and any information we need for EL3 can be neatly placed in a simple array.
All of this, combined with lifting the actual saving out of assembly, reduces the instructions to save the context from 180 to 40, including a lot fewer branches. The code is also much shorter and easier to read.
Also propagate to aarch32 so that the two don't diverge too much.
Change-Id: Ib62e6e9ba5be7fb9fb8965c8eee148d5598a5361 Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
2590e819 |
| 25-Nov-2024 |
Boyan Karatotev <boyan.karatotev@arm.com> |
perf(mpmm): greatly simplify MPMM enablement
MPMM is a core-specific microarchitectural feature. It has been present in every Arm core since the Cortex-A510 and has been implemented in exactly the s
perf(mpmm): greatly simplify MPMM enablement
MPMM is a core-specific microarchitectural feature. It has been present in every Arm core since the Cortex-A510 and has been implemented in exactly the same way. Despite that, it is enabled more like an architectural feature with a top level enable flag. This utilised the identical implementation.
This duality has left MPMM in an awkward place, where its enablement should be generic, like an architectural feature, but since it is not, it should also be core-specific if it ever changes. One choice to do this has been through the device tree.
This has worked just fine so far, however, recent implementations expose a weakness in that this is rather slow - the device tree has to be read, there's a long call stack of functions with many branches, and system registers are read. In the hot path of PSCI CPU powerdown, this has a significant and measurable impact. Besides it being a rather large amount of code that is difficult to understand.
Since MPMM is a microarchitectural feature, its correct placement is in the reset function. The essence of the current enablement is to write CPUPPMCR_EL3.MPMM_EN if CPUPPMCR_EL3.MPMMPINCTL == 0. Replacing the C enablement with an assembly macro in each CPU's reset function achieves the same effect with just a single close branch and a grand total of 6 instructions (versus the old 2 branches and 32 instructions).
Having done this, the device tree entry becomes redundant. Should a core that doesn't support MPMM arise, this can cleanly be handled in the reset function. As such, the whole ENABLE_MPMM_FCONF and platform hooks mechanisms become obsolete and are removed.
Change-Id: I1d0475b21a1625bb3519f513ba109284f973ffdf Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
e0be63c8 |
| 13-Feb-2025 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge changes I712712d7,I1932500e,I75dda77e,I12f3b8a3,Ia72e5900 into integration
* changes: refactor(rse)!: remove rse_comms_init refactor(arm): switch to rse_mbx_init refactor(rse): put MHU c
Merge changes I712712d7,I1932500e,I75dda77e,I12f3b8a3,Ia72e5900 into integration
* changes: refactor(rse)!: remove rse_comms_init refactor(arm): switch to rse_mbx_init refactor(rse): put MHU code in a dedicated file refactor(tc): add plat_rse_comms_init refactor(arm)!: rename PLAT_MHU_VERSION flag
show more ...
|