Lines Matching refs:model
57 Routing model
69 A routing model for a type of interrupt (generated as FIQ or IRQ) is defined as
73 routed to EL3. A routing model is applicable only when execution is not in EL3.
75 The default routing model for an interrupt type is to route it to the FEL in
99 secure state. This is a valid routing model as secure software is in
103 state. This is a valid routing model as secure software in EL3 can
107 non-secure state. This is an invalid routing model as a secure interrupt
112 non-secure state. This is a valid routing model as secure software in EL3
121 non-secure software through EL3. This is a valid routing model as secure
126 state. This is a valid routing model as secure software in EL3 can save
128 interrupt to non-secure software. This model requires additional
133 non-secure state. This is a valid routing model as a non-secure interrupt
137 non-secure state. This is an invalid routing model as there is no valid
147 Secure-EL1/Secure-EL0. This is a valid routing model as secure software
151 However, when ``EL3_EXCEPTION_HANDLING`` is ``1``, this routing model is
157 Secure-EL1/Secure-EL0. This is a valid routing model as secure software
161 non-secure state. This is an invalid routing model as a secure interrupt
166 non-secure state. This is a valid routing model as secure software in EL3
177 programmed in ``SCR_EL3`` while applying the routing model for a type of
192 same interrupt signal will be forced to the same routing model. This should be
193 borne in mind when choosing the routing model for an interrupt type.
197 signal. So if either one of the interrupt type sets the routing model so
221 specification of the routing model for a type of interrupt.
239 The ``flags`` field stores the routing model for the interrupt type in
240 bits[1:0]. Bit[0] stores the routing model when execution is in the secure
241 state. Bit[1] stores the routing model when execution is in the non-secure
242 state. As mentioned in Section `Routing model`_, a value of ``0`` implies that
248 The ``scr_el3[2]`` field also stores the routing model but as a mapping of the
249 model in the ``flags`` field to the corresponding bit in the ``SCR_EL3`` for each
328 interrupt was generated and routed as per the routing model specified
351 interrupts. This API also requires the caller to specify the routing model for
374 model for each security state for the current CPU. The value of ``SCR_EL3`` stored
389 model using the ``cm_get_scr_el3()`` and ``cm_write_scr_el3_bit()`` APIs.
392 runtime firmware is responsible for programming the routing model. The SPD is
393 responsible for ensuring that the routing model has been adhered to upon
402 routing model supported by itself and the Secure Payload. It is also responsible
404 the routing model. It could determine the routing model at build time or at
408 If the routing model is not known to the SPD service at build time, then it must
410 program the routing model only after SP initialisation has completed e.g. in the
426 routing model at build time.
433 model is used for non-secure interrupts. They are routed to the FEL in
440 Secure-EL1. The default routing model is used for non secure interrupts in
497 (Secure-EL1 IHF) to support its chosen interrupt routing model. Secure payload
509 in the routing model where **CSS=1 and TEL3=0**. Secure-EL1 interrupts
510 will be routed to EL3 (as per the routing model where **CSS=1 and
515 both these interrupt handling models depending upon the chosen routing model.
517 The following list briefly describes how the choice of a valid routing model
519 IHF. If the choice of the interrupt routing model is not known to the SPD
535 synchronous interrupt handling model. The SP could implement this scenario
545 handling model as described in 1. above.
552 synchronous interrupt handling model described in 1. above.
579 model does not affect the SP behavior.
589 The routing model for Secure-EL1 and non-secure interrupts chosen by the TSP is
597 (synchronous handling model). It passes the reference to this entrypoint via
604 VBAR_EL1. It caters for the asynchronous handling model.
694 generated according to the interrupt routing model specified by the SPD
703 from non-secure state. Also if a routing model is chosen where Secure-EL1
709 routing model and interrupt type. For non secure and S-EL1 interrupt,
728 per the synchronous interrupt handling model it implements. A Secure-EL1
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
839 routing model for the non-secure interrupt to be routed to EL3 from secure state
850 routing model for non-secure interrupt in secure state is in effect
910 interrupt handling models depending upon the interrupt routing model it has
913 In the synchronous model, it should begin handling a Secure-EL1 interrupt after
922 In the asynchronous model, the Secure Payload is responsible for handling
956 The TSP handles interrupts under the asynchronous model as follows.