mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-19 11:04:20 +00:00
interrupt-framework-design.rst: Cosmetic changes
Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This commit is contained in:
parent
6027796fff
commit
fb750ee161
1 changed files with 9 additions and 12 deletions
|
@ -135,7 +135,7 @@ Non-secure interrupts
|
||||||
former's state is correctly saved by the latter.
|
former's state is correctly saved by the latter.
|
||||||
|
|
||||||
#. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in
|
#. **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.
|
is handled by non-secure software.
|
||||||
|
|
||||||
#. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
|
#. **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
|
#. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution
|
||||||
in EL3.
|
in EL3.
|
||||||
|
|
||||||
#. .. rubric:: Interrupt management
|
#. Interrupt management: the following sections describe how interrupts are
|
||||||
:name: interrupt-management
|
managed by the interrupt handling framework. This entails:
|
||||||
|
|
||||||
The following sections describe how interrupts are managed by the interrupt
|
#. Providing an interface to allow registration of a handler and
|
||||||
handling framework. This entails:
|
specification of the routing model for a type of interrupt.
|
||||||
|
|
||||||
#. Providing an interface to allow registration of a handler and specification
|
#. Implementing support to hand control of an interrupt type to its
|
||||||
of the routing model for a type of interrupt.
|
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
|
Both aspects of interrupt management involve various components in the secure
|
||||||
software stack spanning from EL3 to Secure-EL1. These components are described
|
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:
|
for the following:
|
||||||
|
|
||||||
#. Validating the interrupt. This involves ensuring that the interrupt was
|
#. 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
|
service during registration. It should use the security state of the
|
||||||
exception level (passed in the ``flags`` parameter of the handler) where
|
exception level (passed in the ``flags`` parameter of the handler) where
|
||||||
the interrupt was taken from to determine this. If the interrupt is not
|
the interrupt was taken from to determine this. If the interrupt is not
|
||||||
recognised then the handler should treat it as an irrecoverable error
|
recognised then the handler should treat it as an irrecoverable error
|
||||||
condition.
|
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
|
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
|
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
|
interrupts are routed to S-EL1 when execution is in Secure state, then a
|
||||||
|
|
Loading…
Add table
Reference in a new issue