History log of /rk3399_ARM-atf/lib/psci/psci_off.c (Results 1 – 25 of 44)
Revision Date Author Comments
# 7138e659 26-Aug-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge "fix(psci): add missing curly braces" into integration


# bac32cc4 24-Apr-2025 Saivardhan Thatikonda <saivardhan.thatikonda@amd.com>

fix(psci): add missing curly braces

This corrects the MISRA violation C2012-15.6:
The body of an iteration-statement or a selection-statement shall
be a compound-statement.
Enclosed statement body w

fix(psci): add missing curly braces

This corrects the MISRA violation C2012-15.6:
The body of an iteration-statement or a selection-statement shall
be a compound-statement.
Enclosed statement body within the curly braces.

Change-Id: Ida2460b7fe6f27b23382a1259a5ac93fe36bd48d
Signed-off-by: Saivardhan Thatikonda <saivardhan.thatikonda@amd.com>
Signed-off-by: Suraj Kakade <suraj.hanumantkakade@amd.com>

show more ...


# 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 ...


# 5d893410 07-Jan-2025 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(gic): promote most of the GIC driver to common code

More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - c

refactor(gic): promote most of the GIC driver to common code

More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - calling
the top-level helpers from plat/arm/common/arm_gicvX.c or by using the
driver directly. Both of these methods allow for a high degree of
customisation - most functions are defined to be weak and there are no
calls to any of them in generic code.

As it turns out, requirements around those GICs are largely the same.
Platforms that use arm_gicvX.c use the helpers identically among each
other. Platforms that use the driver directly tend to end up with calls
that look a lot like the arm_gicvX.c helpers and the weakness of the
functions are never exercised.

All of this results in a lot of code duplication to do what is
essentially the same thing. Even though it's not a lot of code, when
multiplied among many platforms it becomes significant and makes
refactoring it quite difficult. It's also bug prone since the steps are
a little convoluted and things are likely to work even with subtle
errors (see 50009f61177421118f42d6a000611ba0e613d54b).

So promote as much of the GIC to be called from common code. Do the
setup in bl31_main() and have every PSCI method do the state management
directly instead of delegating it to the platform hooks. We can base
this implementation on arm_gicvX.c since they already offer logical
names and have worked quite well so far with minimal changes.

The main benefit of doing this is reduced code duplication. If we assume
that, outside of some platform setup, GIC management is identical, then
a platform can add support by telling the build system, regardless of
GIC revision. The other benefit is performance - BL31 and PSCI already
know the core_pos and they can pass it as an argument instead of having
to call plat_my_core_pos(). Now, the only platform specific GIC actions
necessary are the saving and restoring of context on entering and
exiting a power domain. The PSCI library does not keep track of this so
it is unable perform it itself. The routines themselves are also
provided.

For compatibility all of this is hidden behind a build flag. Platforms
are encouraged to adopt this driver, but it would not be practical to
convert and validate every GIC based platform.

This patch renames the functions in question to follow the
gic_<function>() convention. This allows the names to be version
agnostic.

Finally, drop the weak definitions - they are unused, likely to remain
so, and can be added back if the need arises.

Change-Id: I5b5267f4b72f633fb1096400ec8e4b208694135f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 10639cc9 03-Apr-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes from topic "xlnx_fix_gen_uniq_var" into integration

* changes:
fix(psci): avoid altering function parameters
fix(services): avoid altering function parameters
fix(common): ignore

Merge changes from topic "xlnx_fix_gen_uniq_var" into integration

* changes:
fix(psci): avoid altering function parameters
fix(services): avoid altering function parameters
fix(common): ignore the unused function return value
fix(psci): modify variable conflicting with external function
fix(delay-timer): create unique variable name

show more ...


# 0839cfc9 19-Apr-2024 Maheedhar Bollapalli <maheedharsai.bollapalli@amd.com>

fix(psci): modify variable conflicting with external function

This corrects the MISRA violation C2012-5.8:
Identifiers that define objects or functions with
external linkage shall be unique.
Modify

fix(psci): modify variable conflicting with external function

This corrects the MISRA violation C2012-5.8:
Identifiers that define objects or functions with
external linkage shall be unique.
Modify the variable name to prevent conflict with
external function declaration

Change-Id: I2f109242b6dd3b3c5e9289881e3dd5466c74fcb5
Signed-off-by: Nithin G <nithing@amd.com>
Signed-off-by: Maheedhar Bollapalli <maheedharsai.bollapalli@amd.com>

show more ...


# fcb80d7d 11-Feb-2025 Manish Pandey <manish.pandey2@arm.com>

Merge changes I765a7fa0,Ic33f0b6d,I8d1a88c7,I381f96be,I698fa849, ... into integration

* changes:
fix(cpus): clear CPUPWRCTLR_EL1.CORE_PWRDN_EN_BIT on reset
chore(docs): drop the "wfi" from `pwr_

Merge changes I765a7fa0,Ic33f0b6d,I8d1a88c7,I381f96be,I698fa849, ... into integration

* changes:
fix(cpus): clear CPUPWRCTLR_EL1.CORE_PWRDN_EN_BIT on reset
chore(docs): drop the "wfi" from `pwr_domain_pwr_down_wfi`
chore(psci): drop skip_wfi variable
feat(arm): convert arm platforms to expect a wakeup
fix(cpus): avoid SME related loss of context on powerdown
feat(psci): allow cores to wake up from powerdown
refactor: panic after calling psci_power_down_wfi()
refactor(cpus): undo errata mitigations
feat(cpus): add sysreg_bit_toggle

show more ...


# db5fe4f4 08-Oct-2024 Boyan Karatotev <boyan.karatotev@arm.com>

chore(docs): drop the "wfi" from `pwr_domain_pwr_down_wfi`

To allow for generic handling of a wakeup, this hook is no longer
expected to call wfi itself. Update the name everywhere to reflect this
e

chore(docs): drop the "wfi" from `pwr_domain_pwr_down_wfi`

To allow for generic handling of a wakeup, this hook is no longer
expected to call wfi itself. Update the name everywhere to reflect this
expectation so that future platform implementers don't get misled.

Change-Id: Ic33f0b6da74592ad6778fd802c2f0b85223af614
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 45c7328c 20-Sep-2024 Boyan Karatotev <boyan.karatotev@arm.com>

fix(cpus): avoid SME related loss of context on powerdown

Travis' and Gelas' TRMs tell us to disable SME (set PSTATE.{ZA, SM} to
0) when we're attempting to power down. What they don't tell us is th

fix(cpus): avoid SME related loss of context on powerdown

Travis' and Gelas' TRMs tell us to disable SME (set PSTATE.{ZA, SM} to
0) when we're attempting to power down. What they don't tell us is that
if this isn't done, the powerdown request will be rejected. On the
CPU_OFF path that's not a problem - we can force SVCR to 0 and be
certain the core will power off.

On the suspend to powerdown path, however, we cannot do this. The TRM
also tells us that the sequence could also be aborted on eg. GIC
interrupts. If this were to happen when we have overwritten SVCR to 0,
upon a return to the caller they would experience a loss of context. We
know that at least Linux may call into PSCI with SVCR != 0. One option
is to save the entire SME context which would be quite expensive just to
work around. Another option is to downgrade the request to a normal
suspend when SME was left on. This option is better as this is expected
to happen rarely enough to ignore the wasted power and we don't want to
burden the generic (correct) path with needless context management.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I698fa8490ebf51461f6aa8bba84f9827c5c46ad4

show more ...


# 2b5e00d4 19-Dec-2024 Boyan Karatotev <boyan.karatotev@arm.com>

feat(psci): allow cores to wake up from powerdown

The simplistic view of a core's powerdown sequence is that power is
atomically cut upon calling `wfi`. However, it turns out that it has
lots to do

feat(psci): allow cores to wake up from powerdown

The simplistic view of a core's powerdown sequence is that power is
atomically cut upon calling `wfi`. However, it turns out that it has
lots to do - it has to talk to the interconnect to exit coherency, clean
caches, check for RAS errors, etc. These take significant amounts of
time and are certainly not atomic. As such there is a significant window
of opportunity for external events to happen. Many of these steps are
not destructive to context, so theoretically, the core can just "give
up" half way (or roll certain actions back) and carry on running. The
point in this sequence after which roll back is not possible is called
the point of no return.

One of these actions is the checking for RAS errors. It is possible for
one to happen during this lengthy sequence, or at least remain
undiscovered until that point. If the core were to continue powerdown
when that happens, there would be no (easy) way to inform anyone about
it. Rejecting the powerdown and letting software handle the error is the
best way to implement this.

Arm cores since at least the a510 have included this exact feature. So
far it hasn't been deemed necessary to account for it in firmware due to
the low likelihood of this happening. However, events like GIC wakeup
requests are much more probable. Older cores will powerdown and
immediately power back up when this happens. Travis and Gelas include a
feature similar to the RAS case above, called powerdown abandon. The
idea is that this will improve the latency to service the interrupt by
saving on work which the core and software need to do.

So far firmware has relied on the `wfi` being the point of no return and
if it doesn't explicitly detect a pending interrupt quite early on, it
will embark onto a sequence that it expects to end with shutdown. To
accommodate for it not being a point of no return, we must undo all of
the system management we did, just like in the warm boot entrypoint.

To achieve that, the pwr_domain_pwr_down_wfi hook must not be terminal.
Most recent platforms do some platform management and finish on the
standard `wfi`, followed by a panic or an endless loop as this is
expected to not return. To make this generic, any platform that wishes
to support wakeups must instead let common code call
`psci_power_down_wfi()` right after. Besides wakeups, this lets common
code handle powerdown errata better as well.

Then, the CPU_OFF case is simple - PSCI does not allow it to return. So
the best that can be done is to attempt the `wfi` a few times (the
choice of 32 is arbitrary) in the hope that the wakeup is transient. If
it isn't, the only choice is to panic, as the system is likely to be in
a bad state, eg. interrupts weren't routed away. The same applies for
SYSTEM_OFF, SYSTEM_RESET, and SYSTEM_RESET2. There the panic won't
matter as the system is going offline one way or another. The RAS case
will be considered in a separate patch.

Now, the CPU_SUSPEND case is more involved. First, to powerdown it must
wipe its context as it is not written on warm boot. But it cannot be
overwritten in case of a wakeup. To avoid the catch 22, save a copy that
will only be used if powerdown fails. That is about 500 bytes on the
stack so it hopefully doesn't tip anyone over any limits. In future that
can be avoided by having a core manage its own context.

Second, when the core wakes up, it must undo anything it did to prepare
for poweroff, which for the cores we care about, is writing
CPUPWRCTLR_EL1.CORE_PWRDN_EN. The least intrusive for the cpu library
way of doing this is to simply call the power off hook again and have
the hook toggle the bit. If in the future there need to be more complex
sequences, their direction can be advised on the value of this bit.

Third, do the actual "resume". Most of the logic is already there for
the retention suspend, so that only needs a small touch up to apply to
the powerdown case as well. The missing bit is the powerdown specific
state management. Luckily, the warmboot entrypoint does exactly that
already too, so steal that and we're done.

All of this is hidden behind a FEAT_PABANDON flag since it has a large
memory and runtime cost that we don't want to burden non pabandon cores
with.

Finally, do some function renaming to better reflect their purpose and
make names a little bit more consistent.

Change-Id: I2405b59300c2e24ce02e266f91b7c51474c1145f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# f532cd30 15-Jan-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge changes I137f69be,Ia2e7168f,I0e569d12,I614272ec,Ib68293f2 into integration

* changes:
perf(psci): pass my_core_pos around instead of calling it repeatedly
refactor(psci): move timestamp co

Merge changes I137f69be,Ia2e7168f,I0e569d12,I614272ec,Ib68293f2 into integration

* changes:
perf(psci): pass my_core_pos around instead of calling it repeatedly
refactor(psci): move timestamp collection to psci_pwrdown_cpu
refactor(psci): factor common code out of the standby finisher
refactor(psci): don't use PSCI_INVALID_PWR_LVL to signal OFF state
docs(psci): drop outdated cache maintenance comment

show more ...


# 3b802105 06-Nov-2024 Boyan Karatotev <boyan.karatotev@arm.com>

perf(psci): pass my_core_pos around instead of calling it repeatedly

On some platforms plat_my_core_pos is a nontrivial function that takes a
bit of time and the compiler really doesn't like to inli

perf(psci): pass my_core_pos around instead of calling it repeatedly

On some platforms plat_my_core_pos is a nontrivial function that takes a
bit of time and the compiler really doesn't like to inline. In the PSCI
library, at least, we have no need to keep repeatedly calling it and we
can instead pass it around as an argument. This saves on a lot of
redundant calls, speeding the library up a bit.

Change-Id: I137f69bea80d7cac90d7a20ffe98e1ba8d77246f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 9b1e800e 10-Oct-2024 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(psci): move timestamp collection to psci_pwrdown_cpu

psci_pwrdown_cpu has two callers, both of which save timestamps meant to
measure how much time the cache maintenance operations take. Mo

refactor(psci): move timestamp collection to psci_pwrdown_cpu

psci_pwrdown_cpu has two callers, both of which save timestamps meant to
measure how much time the cache maintenance operations take. Move the
timestamp collection inside to save on a bit of code duplication.

Change-Id: Ia2e7168faf7773d99b696cbdb6c98db7b58e31cf
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# f4d011b0 12-Jun-2023 Manish Pandey <manish.pandey2@arm.com>

Merge changes from topic "psci-osi" into integration

* changes:
fix(psci): add optional pwr_domain_validate_suspend to plat_psci_ops_t
fix(sc7280): update pwr_domain_suspend
fix(fvp): update p

Merge changes from topic "psci-osi" into integration

* changes:
fix(psci): add optional pwr_domain_validate_suspend to plat_psci_ops_t
fix(sc7280): update pwr_domain_suspend
fix(fvp): update pwr_domain_suspend

show more ...


# d3488614 04-May-2023 Wing Li <wingers@google.com>

fix(psci): add optional pwr_domain_validate_suspend to plat_psci_ops_t

This patch adds a new optional member `pwr_domain_validate_suspend` to
the `plat_psci_ops_t` structure that allows a platform t

fix(psci): add optional pwr_domain_validate_suspend to plat_psci_ops_t

This patch adds a new optional member `pwr_domain_validate_suspend` to
the `plat_psci_ops_t` structure that allows a platform to optionally
perform platform specific validations in OS-initiated mode. This is
conditionally compiled into the build depending on the value of the
`PSCI_OS_INIT_MODE` build option.

In https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17682,
the return type of the `pwr_domain_suspend` handler was updated from
`void` to `int` to allow a platform to optionally perform platform
specific validations in OS-initiated mode. However, when an error code
other than `PSCI_E_SUCCESS` is returned, the current exit path does not
undo the operations in `psci_suspend_to_pwrdown_start`, and as a result,
the system ends up in an unexpected state.

The fix in this patch prevents the need to undo the operations in
`psci_suspend_to_pwrdown_start`, by allowing the platform to first
perform any necessary platform specific validations before the PSCI
generic code proceeds to the point of no return where the CPU_SUSPEND
request is expected to complete successfully.

Change-Id: I05d92c7ea3f5364da09af630d44d78252185db20
Signed-off-by: Wing Li <wingers@google.com>

show more ...


# f50107d3 03-May-2023 Manish Pandey <manish.pandey2@arm.com>

Merge changes I9d06e0ee,I6980e84f into integration

* changes:
feat(tegra): implement 'pwr_domain_off_early' handler
feat(psci): introduce 'pwr_domain_off_early' hook


# 6cf4ae97 25-Apr-2023 Varun Wadekar <vwadekar@nvidia.com>

feat(psci): introduce 'pwr_domain_off_early' hook

This patch introduces the 'pwr_domain_off_early' hook for
platforms wanting to perform housekeeping steps before the
PSCI framework starts the CPU

feat(psci): introduce 'pwr_domain_off_early' hook

This patch introduces the 'pwr_domain_off_early' hook for
platforms wanting to perform housekeeping steps before the
PSCI framework starts the CPU power off sequence. Platforms
might also want to use ths opportunity to ensure that the
CPU off sequence can proceed.

The PSCI framework expects a return code of PSCI_E_DENIED,
if the platform wants to halt the CPU off sequence.

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I6980e84fc4d6cb80537a178d0d3d26fb28a13853

show more ...


# 75eb87f0 16-Sep-2022 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes from topic "RDN2_WARM_REBOOT_WITH_SGI" into integration

* changes:
feat(sgi): enable css implementation of warm reset
feat(scmi): send powerdown request to online secondary cpus

Merge changes from topic "RDN2_WARM_REBOOT_WITH_SGI" into integration

* changes:
feat(sgi): enable css implementation of warm reset
feat(scmi): send powerdown request to online secondary cpus
feat(plat/arm/css): add interrupt handler for reboot request
refactor(psci): move psci_do_pwrdown_sequence() out of private header
feat(plat/arm/css): add per-cpu power down support for warm reset
feat(scmi): set warm reboot entry point
fix(gicv3): update the affinity mask to 8 bit

show more ...


# 65bbb935 22-Jul-2022 Pranav Madhu <pranav.madhu@arm.com>

refactor(psci): move psci_do_pwrdown_sequence() out of private header

Move the psci_do_pwrdown_sequence() function declaration from PSCI
private header to common header. The psci_do_pwrdown_sequence

refactor(psci): move psci_do_pwrdown_sequence() out of private header

Move the psci_do_pwrdown_sequence() function declaration from PSCI
private header to common header. The psci_do_pwrdown_sequence is
required to support warm reset, where each CPU need to execute the
powerdown sequence.

Change-Id: I298e7a120be814941fa91c0b001002a080e56263
Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>

show more ...


# 43636796 10-Jan-2020 Mark Dykes <mardyk01@review.trustedfirmware.org>

Merge "Unify type of "cpu_idx" across PSCI module." into integration


# 5b33ad17 13-Dec-2019 Deepika Bhavnani <deepika.bhavnani@arm.com>

Unify type of "cpu_idx" across PSCI module.

NOTE for platform integrators:
API `plat_psci_stat_get_residency()` third argument
`last_cpu_idx` is changed from "signed int" to the
"unsigned i

Unify type of "cpu_idx" across PSCI module.

NOTE for platform integrators:
API `plat_psci_stat_get_residency()` third argument
`last_cpu_idx` is changed from "signed int" to the
"unsigned int" type.

Issue / Trouble points
1. cpu_idx is used as mix of `unsigned int` and `signed int` in code
with typecasting at some places leading to coverity issues.

2. Underlying platform API's return cpu_idx as `unsigned int`
and comparison is performed with platform specific defines
`PLAFORM_xxx` which is not consistent

Misra Rule 10.4:
The value of a complex expression of integer type may only be cast to
a type that is narrower and of the same signedness as the underlying
type of the expression.

Based on above points, cpu_idx is kept as `unsigned int` to match
the API's and low-level functions and platform defines are updated
where ever required

Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com>
Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c

show more ...


# f5b904ea 10-Jun-2019 Soby Mathew <soby.mathew@arm.com>

Merge "PSCI: Lookup list of parent nodes to lock only once" into integration


# 74d27d00 04-Jun-2019 Andrew F. Davis <afd@ti.com>

PSCI: Lookup list of parent nodes to lock only once

When acquiring or releasing the power domain locks for a given CPU the
parent nodes are looked up by walking the up the PD tree list on both the
a

PSCI: Lookup list of parent nodes to lock only once

When acquiring or releasing the power domain locks for a given CPU the
parent nodes are looked up by walking the up the PD tree list on both the
acquire and release path, only one set of lookups is needed. Fetch the
parent nodes first and pass this list into both the acquire and release
functions to avoid the double lookup.

This also allows us to not have to do this lookup after coherency has
been exited during the core power down sequence. The shared struct
psci_cpu_pd_nodes is not placed in coherent memory like is done
for psci_non_cpu_pd_nodes and doing so would negatively affect
performance. With this patch we remove the need to have it in coherent
memory by moving the access out of psci_release_pwr_domain_locks().

Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: I7b9cfa9d31148dea0f5e21091c8b45ef7fe4c4ab

show more ...


# 9a207532 04-Jan-2019 Antonio Niño Díaz <antonio.ninodiaz@arm.com>

Merge pull request #1726 from antonio-nino-diaz-arm/an/includes

Sanitise includes across codebase


# 09d40e0e 14-Dec-2018 Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Sanitise includes across codebase

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- inclu

Sanitise includes across codebase

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}

The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).

For example, this patch had to be created because two headers were
called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a282 ("drivers: add tzc380 support").

This problem was introduced in commit 4ecca33988b9 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.

Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.

Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...


12