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>
diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst
index 9ca2aa9..ea05cc7 100644
--- a/docs/porting-guide.rst
+++ b/docs/porting-guide.rst
@@ -3436,6 +3436,18 @@
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
~~~~~~~~~~~~~~~~~~~~~~~~~~