docs(ras): document RAS considerations with powerdown

RAS errors can cause problems for powerdown. On cpus like the A510,
receiving a RAS error after executing the powerdown `wfi` will deadlock
the core. The TRM suggests disabling the generation of interrupts.
However, which interrupts to disable is not apparent for generic code as
the meaning of each error record is *heavily* IMPDEF, despite the
standard format. Iterating over the list and disabling all is not
desirable as this might disable errors for components that do not have
an effect on the core that is powering down.

As such, leave this for the platform port to handle. Leave a note in the
porting guide so this is not missed.

Change-Id: I43c3f6f909fafc449d3b4e748b015b05338d9618
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
This commit is contained in:
Boyan Karatotev 2024-10-21 14:18:46 +01:00
parent 722efeaa8c
commit 839739e234

View file

@ -3436,6 +3436,18 @@ This API is used to setup the early console, it is required only if the flag
External Abort handling and RAS Support
---------------------------------------
If any cores on the platform support powerdown abandon (i.e. ``FEAT_PABANDON``
is set, check the "Core powerup and powerdown sequence" in their TRMs), then
these functions should be able to handle being called with power domains off and
after the powerdown ``wfi``. In other words it may run after a call to
``pwr_domain_suspend()`` and before a call to ``pwr_domain_suspend_finish()``
(and their power off counterparts).
Should this not be desirable, or if there is no powerdown abandon support, then
RAS errors should be masked by writing any relevant error records in any
powerdown hooks to prevent deadlocks due to a RAS error after the point of no
return. See the core's TRM for further information.
Function : plat_ea_handler
~~~~~~~~~~~~~~~~~~~~~~~~~~