andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

interrupt-framework-design.rst: Cosmetic changes 

Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This commit is contained in:
Jeenu Viswambharan 2018-01-10 14:56:03 +00:00
parent 6027796fff
commit fb750ee161
1 changed files with 9 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/interrupt-framework-design.rst
View File

@ -135,7 +135,7 @@ Non-secure interrupts
former's state is correctly saved by the latter.
#. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in
non-secure state. This is an valid routing model as a non-secure interrupt
non-secure state. This is a valid routing model as a non-secure interrupt
is handled by non-secure software.
#. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
@ -216,17 +216,14 @@ The framework makes the following assumptions to simplify its implementation.
#. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution
in EL3.
#. .. rubric:: Interrupt management
:name: interrupt-management
#. Interrupt management: the following sections describe how interrupts are
managed by the interrupt handling framework. This entails:
The following sections describe how interrupts are managed by the interrupt
handling framework. This entails:
#. Providing an interface to allow registration of a handler and
specification of the routing model for a type of interrupt.
#. Providing an interface to allow registration of a handler and specification
of the routing model for a type of interrupt.
#. Implementing support to hand control of an interrupt type to its registered
handler when the interrupt is generated.
#. Implementing support to hand control of an interrupt type to its
registered handler when the interrupt is generated.
Both aspects of interrupt management involve various components in the secure
software stack spanning from EL3 to Secure-EL1. These components are described
@ -685,14 +682,14 @@ the handler function for that type of interrupt. The SPD service is responsible
for the following:
#. Validating the interrupt. This involves ensuring that the interrupt was
generating according to the interrupt routing model specified by the SPD
generated according to the interrupt routing model specified by the SPD
service during registration. It should use the security state of the
exception level (passed in the ``flags`` parameter of the handler) where
the interrupt was taken from to determine this. If the interrupt is not
recognised then the handler should treat it as an irrecoverable error
condition.
A SPD service can register a handler for Secure-EL1 and/or Non-secure
An SPD service can register a handler for Secure-EL1 and/or Non-secure
interrupts. A non-secure interrupt should never be routed to EL3 from
from non-secure state. Also if a routing model is chosen where Secure-EL1
interrupts are routed to S-EL1 when execution is in Secure state, then a