1. 10 Feb, 2015 5 commits
  2. 06 Feb, 2015 2 commits
    • Arnd Bergmann's avatar
      ARM: 8297/1: cache-l2x0: optimize aurora range operations · 1d889679
      Arnd Bergmann authored
      The aurora_inv_range(), aurora_clean_range() and aurora_flush_range()
      functions are highly redundant, both in source and in object code, and
      they are harder to understand than necessary.
      
      By moving the range loop into the aurora_pa_range() function, they
      become trivial wrappers, and the object code start looking like what
      one would expect for an optimal implementation.
      
      Further optimization may be possible by using the per-CPU "virtual"
      registers to avoid the spinlocks in most cases.
      
       (on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
       DMA traffic by reading data from a SD card)
      Reviewed-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      1d889679
    • Arnd Bergmann's avatar
      ARM: 8296/1: cache-l2x0: clean up aurora cache handling · 20e783e3
      Arnd Bergmann authored
      The aurora cache controller is the only remaining user of a couple
      of functions in this file and are completely unused when that is
      disabled, leading to build warnings:
      
      arch/arm/mm/cache-l2x0.c:167:13: warning: 'l2x0_cache_sync' defined but not used [-Wunused-function]
      arch/arm/mm/cache-l2x0.c:184:13: warning: 'l2x0_flush_all' defined but not used [-Wunused-function]
      arch/arm/mm/cache-l2x0.c:194:13: warning: 'l2x0_disable' defined but not used [-Wunused-function]
      
      With the knowledge that the code is now aurora-specific, we can
      simplify it noticeably:
      
      - The pl310 errata workarounds are not needed on aurora and can be removed
      - As confirmed by Thomas Petazzoni from the data sheet, the cache_wait()
        macro is never needed.
      - No need to hold the lock across atomic cache sync
      - We can load the l2x0_base into a local variable across operations
      
      There should be no functional change in this patch, but readability
      and the generated object code improves, along with avoiding the
      warnings.
      
       (on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
       DMA traffic by reading data from a SD card)
      Acked-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      20e783e3
  3. 03 Feb, 2015 1 commit
    • Will Deacon's avatar
      ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover · 8e648066
      Will Deacon authored
      Commit e1a5848e ("ARM: 7924/1: mm: don't bother with reserved ttbr0
      when running with LPAE") removed the use of the reserved TTBR0 value
      for LPAE systems, since the ASID is held in the TTBR and can be updated
      atomicly with the pgd of the next mm.
      
      Unfortunately, this patch forgot to update flush_context, which
      deliberately avoids marking the local active ASID as allocated, since we
      used to switch via ASID zero and didn't need to allocate the ASID of
      the previous mm. The side-effect of this is that we can allocate the
      same ASID to the next mm and, between flushing the local TLB and updating
      TTBR0, we can perform speculative TLB fills for userspace nG mappings
      using the page table of the previous mm.
      
      The consequence of this is that the next mm can erroneously hit some
      mappings of the previous mm. Note that this was made significantly
      harder to hit by a391263c ("ARM: 8203/1: mm: try to re-use old ASID
      assignments following a rollover") but is still theoretically possible.
      
      This patch fixes the problem by removing the code from flush_context
      that forces the allocated ASID to zero for the local CPU. Many thanks
      to the Broadcom guys for tracking this one down.
      
      Fixes: e1a5848e ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE")
      
      Cc: <stable@vger.kernel.org> # v3.14+
      Reported-by: default avatarRaymond Ngun <rngun@broadcom.com>
      Tested-by: default avatarRaymond Ngun <rngun@broadcom.com>
      Reviewed-by: default avatarGregory Fong <gregory.0xf0@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      8e648066
  4. 29 Jan, 2015 11 commits
  5. 21 Jan, 2015 13 commits
  6. 16 Jan, 2015 8 commits