1. 28 Feb, 2018 1 commit
  2. 26 Feb, 2018 1 commit
  3. 24 Feb, 2018 1 commit
  4. 21 Feb, 2018 1 commit
  5. 14 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Remove URLs from comments · fb1198b1
      Antonio Nino Diaz authored
      
      
      This fixes all defects according to MISRA Rule 3.1: "The character
      sequences /* and // shall not be used within a comment". This affects
      all URLs in comments, so they have been removed:
      
      - The link in `sdei_state.c` can also be found in the documentation file
        `docs/sdei.rst`.
      
      - The bug that the file `io_fip.c` talks about doesn't affect the
        currently supported version of GCC, so it doesn't make sense to keep
        the comment. Note that the version of GCC officially supported is the
        one that comes with Linaro Release 17.10, which is GCC 6.2.
      
      - The link in `tzc400.c` was broken, and it didn't correctly direct to
        the Technical Reference Manual it should. The link has been replaced
        by the title of the document, which is more convenient when looking
        for the document.
      
      Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      fb1198b1
  6. 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
  7. 24 Jan, 2018 1 commit
  8. 19 Jan, 2018 4 commits
  9. 18 Jan, 2018 1 commit
  10. 17 Jan, 2018 1 commit
  11. 11 Jan, 2018 1 commit
  12. 13 Dec, 2017 1 commit
    • Roberto Vargas's avatar
      io: block: fix block_read/write may read/write overlap buffer · e19e40af
      Roberto Vargas authored
      
      
      The block operations were trying to optimize the number of memory
      copies, and it tried to use directly the buffer supplied by the user
      to them. This was a mistake because it created too many corner cases:
      
      	1- It was possible to generate unaligned
      	   operations to unaligned buffers. Drivers that were using
      	   DMA transfer failed in that case.
      
      	2- It was possible to generate read operations
      	   with sizes that weren't a multiple of the block size. Some
      	   low level drivers assumed that condition and they calculated
      	   the number of blocks dividing the number of bytes by the
      	   size of the block, without considering the remaining bytes.
      
      	3- The block_* operations didn't control the
      	   number of bytes actually copied to memory, because the
      	   low level drivers were writing directly to the user buffer.
      
      This patch rewrite block_read and block_write to use always the device
      buffer, which the platform ensures that has the correct aligment and
      the correct size.
      
      Change-Id: I5e479bb7bc137e6ec205a8573eb250acd5f40420
      Signed-off-by: default avatarQixiang Xu <qixiang.xu@arm.com>
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      e19e40af
  13. 12 Dec, 2017 1 commit
    • Julius Werner's avatar
      Add new function-pointer-based console API · 9536bae6
      Julius Werner authored
      
      
      This patch overhauls the console API to allow for multiple console
      instances of different drivers that are active at the same time. Instead
      of binding to well-known function names (like console_core_init),
      consoles now provide a register function (e.g. console_16550_register())
      that will hook them into the list of active consoles. All console
      operations will be dispatched to all consoles currently in the list.
      
      The new API will be selected by the build-time option MULTI_CONSOLE_API,
      which defaults to ${ERROR_DEPRECATED} for now. The old console API code
      will be retained to stay backwards-compatible to older platforms, but
      should no longer be used for any newly added platforms and can hopefully
      be removed at some point in the future.
      
      The new console API is intended to be used for both normal (bootup) and
      crash use cases, freeing platforms of the need to set up the crash
      console separately. Consoles can be individually configured to be active
      active at boot (until first handoff to EL2), at runtime (after first
      handoff to EL2), and/or after a crash. Console drivers should set a sane
      default upon registration that can be overridden with the
      console_set_scope() call. Code to hook up the crash reporting mechanism
      to this framework will be added with a later patch.
      
      This patch only affects AArch64, but the new API could easily be ported
      to AArch32 as well if desired.
      
      Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9536bae6
  14. 21 Nov, 2017 1 commit
  15. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      GIC: Fix Group 0 enabling · 385f1dbb
      Jeenu Viswambharan authored
      
      
      At present, the GIC drivers enable Group 0 interrupts only if there are
      Secure SPIs listed in the interrupt properties/list. This means that,
      even if there are Group 0 SGIs/PPIs configured, the group remained
      disabled in the absence of a Group 0 SPI.
      
      Modify both GICv2 and GICv3 SGI/PPI configuration to enable Group 0 when
      corresponding SGIs/PPIs are present.
      
      Change-Id: Id123e8aaee0c22b476eebe3800340906d83bbc6d
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      385f1dbb
    • Jeenu Viswambharan's avatar
      GICv2: Fix populating PE target data · 058efeef
      Jeenu Viswambharan authored
      
      
      This patch brings in the following fixes:
      
        - The per-PE target data initialized during power up needs to be
          flushed so as to be visible to other PEs.
      
        - Setup per-PE target data for the primary PE as well. At present,
          this was only setup for secondary PEs when they were powered on.
      
      Change-Id: Ibe3a57c14864e37b2326dd7ab321a5c7bf80e8af
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      058efeef
  16. 08 Nov, 2017 1 commit
    • Etienne Carriere's avatar
      ARMv7: GICv2 driver can manage GICv1 with security extension · 64deed19
      Etienne Carriere authored
      
      
      Some SoCs integrate a GIC in version 1 that is currently not supported
      by the trusted firmware. This change hijacks GICv2 driver to handle the
      GICv1 as GICv1 is compatible enough with GICv2 as far as the platform
      does not attempt to play with virtualization support or some GICv2
      specific power features.
      
      Note that current trusted firmware does not use these GICv2 features
      that are not available in GICv1 Security Extension.
      
      Change-Id: Ic2cb3055f1319a83455571d6d918661da583f179
      Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      64deed19
  17. 16 Oct, 2017 12 commits
  18. 06 Oct, 2017 1 commit
  19. 05 Oct, 2017 4 commits
    • Soby Mathew's avatar
      GICv3: ITS architectural save and restore helpers · b258278e
      Soby Mathew authored
      
      
      This patch adds functions to save and restore GICv3 ITS registers during
      system suspend. Please note that the power management of GIC ITS is
      implementation defined. These functions only implements the
      architectural part of the ITS power management and they do not restore
      memory structures or register content required to support ITS. Even if
      the ITS implementation stores structures in memory, an implementation
      defined power down sequence is likely to be required to flush some
      internal ITS caches to memory. If such implementation defined sequence
      is not followed, the platform must ensure that the ITS is not power
      gated during system suspend.
      
      Change-Id: I5f31e5541975aa7dcaab69b0b7f67583c0e27678
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      b258278e
    • Soby Mathew's avatar
      GICv3: add functions for save and restore · ebf1ca10
      Soby Mathew authored
      
      
      During system suspend, the GICv3 Distributor and Redistributor context
      can be lost due to power gating of the system power domain. This means
      that the GICv3 context needs to be saved prior to system suspend and
      restored on wakeup. Currently the consensus is that the Firmware should
      be in charge of this. See tf-issues#464 for more details.
      
      This patch introduces helper APIs in the GICv3 driver to save and
      restore the Distributor and Redistributor contexts. The GICv3 ITS
      context is not considered in this patch because the specification says
      that the details of ITS power management is implementation-defined.
      These APIs are expected to be appropriately invoked by the platform
      layer during system suspend.
      
      Fixes ARM-software/tf-issues#464
      
      Change-Id: Iebb9c6770ab8c4d522546f161fa402d2fe02ec00
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      ebf1ca10
    • Douglas Raillard's avatar
      GICv3: turn some macros into inline functions · a64b4e62
      Douglas Raillard authored
      
      
      Tidy up the code a bit by turning some macros into inline functions
      which allows to remove the do/while(0) idiom and backslashes at the end
      of the line.
      
      Change-Id: Ie41a4ea4a4da507f7b925247b53e85019101d717
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      a64b4e62
    • Douglas Raillard's avatar
      GICv3: Fix gic600.c indentation · b50bdcea
      Douglas Raillard authored
      
      
      Reindent the file using tabs as the mix of spaces and tabs confuses some
      editors and leads them to use spaces instead of tabs for new code
      although the coding style mandates tabs.
      
      Change-Id: I87fa4a5d368a048340054b9b3622325f3f7befba
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      b50bdcea
  20. 22 Sep, 2017 2 commits
  21. 21 Sep, 2017 1 commit
    • Antonio Nino Diaz's avatar
      Fix type of `unsigned long` constants · e47ac1fd
      Antonio Nino Diaz authored
      
      
      The type `unsigned long` is 32 bit wide in AArch32, but 64 bit wide in
      AArch64. This is inconsistent and that's why we avoid using it as per
      the Coding Guidelines. This patch changes all `UL` occurrences to `U`
      or `ULL` depending on the context so that the size of the constant is
      clear.
      
      This problem affected the macro `BIT(nr)`. As long as this macro is used
      to fill fields of registers, that's not a problem, since all registers
      are 32 bit wide in AArch32 and 64 bit wide in AArch64. However, if the
      macro is used to fill the fields of a 64-bit integer, it won't be able
      to set the upper 32 bits in AArch32.
      
      By changing the type of this macro to `unsigned long long` the behaviour
      is always the same regardless of the architecture, as this type is
      64-bit wide in both cases.
      
      Some Tegra platform files have been modified by this patch.
      
      Change-Id: I918264c03e7d691a931f0d1018df25a2796cc221
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e47ac1fd