Skip to content

GitLab

Switch branch/tag
  1. 06 Feb, 2018 4 commits
    • Jeenu Viswambharan's avatar
      TSPD: Require NS preemption along with EL3 exception handling · 6027796f
      Jeenu Viswambharan authored 
      
At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how
Non-secure interrupt affects TSPs execution. When TSP is executing:

  1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received
     at the TSP's exception vector, and TSP voluntarily preempts itself.

  2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a
     trap to EL3, which preempts TSP execution.

When EL3 exception handling is in place (i.e.,
EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system
with GICv3, pending NS interrupts while TSP is executing will be
signalled as FIQ (which traps to EL3). This situation necessitates the
same treatment applied to case (2) above.

Therefore, when EL3 exception handling is in place, additionally
require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1.

Strictly speaking, this is not required on a system with GICv2, but the
same model is uniformly followed regardless, for simplicity.

Relevant documentation updated.

Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      6027796f
    • Jeenu Viswambharan's avatar
      TSPD: Explicitly allow NS preemption for Yielding SMCs · 1dd022ca
      Jeenu Viswambharan authored 
      
When EL3 exception handling is in effect (i.e.,
EL3_EXCEPTION_HANDLING=1), Non-secure interrupts can't preempt Secure
execution. However, for yielding SMCs, preemption by Non-secure
interupts is intended.

This patch therefore adds a call to ehf_allow_ns_preemption() before
dispatching a Yielding SMC to TSP.

Change-Id: Ia3a1ae252f3adc0f14e6d7e0502f251bdb349bdf
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1dd022ca
    • Jeenu Viswambharan's avatar
      Deprecate one EL3 interrupt routing model with EL3 exception handling · 26ea3908
      Jeenu Viswambharan authored 
      
When ARM Trusted Firmware is built with EL3_EXCEPTION_HANDLING=1,
EL3 interrupts (INTR_TYPE_EL3) will always preempt both Non-secure and
secure execution.

The interrupt management framework currently treats EL3 interrupt
routing as valid. For the above reason, this patch makes them invalid
when EL3_EXCEPTION_HANDLING is in effect.

Change-Id: I95bca8f5dc8df8eb0ff6f305cfba098611522a39
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      26ea3908
    • Jeenu Viswambharan's avatar
      Add EL3_EXCEPTION_HANDLING to build command line · c8b55b8f
      Jeenu Viswambharan authored 
      Commit 21b818c0

 (BL31: Introduce
Exception Handling Framework) introduced the build option
EL3_EXCEPTION_HANDLING, but missed to pass that to the build command
line. This patch fixes that.

Change-Id: I0a1be2c7b41a81e748ad7d6cf795aab7f6d19193
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      c8b55b8f
  3. 02 Feb, 2018 5 commits
  5. 01 Feb, 2018 4 commits
  7. 31 Jan, 2018 2 commits
  9. 30 Jan, 2018 5 commits
  11. 29 Jan, 2018 15 commits
  13. 27 Jan, 2018 2 commits
  15. 26 Jan, 2018 2 commits
  17. 25 Jan, 2018 1 commit
    • Julius Werner's avatar
      delay_timer: Guarantee that delay time can never be undershot · e2aec918
      Julius Werner authored 
      
Delay functions like udelay() are often used to ensure that the
necessary time passed to allow some asynchronous event to finish, such
as the stabilization delay for a power rail. For these use cases it is
not very problematic if the delay is slightly longer than requested,
but it is critical that the delay must never be shorter.

The current udelay() implementation contains two hazards that may cause
the delay to be slightly shorter than intended: Firstly, the amount of
ticks to wait is calculated with an integer division, which may cut off
the last fraction of ticks needed. Secondly, the delay may be short by a
fraction of a tick because we do not know whether the initial ("start")
sample of the timer was near the start or near the end of the current
tick. Thus, if the code intends to wait for one tick, it might read the
timer value close to the end of the current tick and then read it again
right after the start of the next tick, concluding that the duration of
a full tick has passed when it in fact was just a fraction of it.

This patch rounds up the division and always adds one extra tick to
counteract both problems and ensure that delays will always be larger
but never smaller than requested.

Change-Id: Ic5fe5f858b5cdf3c0dbf3e488d4d5702d9569433
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      e2aec918