1. 14 Apr, 2015 12 commits
  2. 10 Apr, 2015 1 commit
  3. 07 Apr, 2015 1 commit
    • Russell King's avatar
      ARM: vexpress: fix CPU hotplug with CT9x4 tile. · f6ac49ba
      Russell King authored
      The Cortex A9 tile fails to unplug CPUs if errata 643719 is not enabled.
      This leads to random weird behaviours, but ultimately seem to lock the
      kernel one way or another when a CPU is hot unplugged.
      
      Symptoms range from a spinlock lockup in the scheduler, the entire
      system hanging, to dumping out the kernel printk buffer a few lines at
      a time, and other weird behaviours.
      
      This is caused by the outgoing CPU not having its inner caches properly
      flushed before it exits coherency - flush_cache_louis() is used to
      achieve this, but as a result of the hardware bug, this function ends
      up doing nothing without the errata workaround enabled.
      
      As the Versatile Express has an affected CPU, this errata must always
      be enabled.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      f6ac49ba
  4. 02 Apr, 2015 9 commits
    • Florian Fainelli's avatar
      ARM: 8276/1: Make CPU_DCACHE_DISABLE depend on !SMP · e1e2f6e4
      Florian Fainelli authored
      Enabling CPU_DCACHE_DISABLE on a SMP capable system will prevent the
      kernel from booting because of the following ldrex instruction in
      arch_spin_lock:
      
      (gdb) x/10i $pc
      => 0xc053cfa8 <_raw_spin_lock+4>:       ldrex   r3, [r0]
         0xc053cfac <_raw_spin_lock+8>:       add     r2, r3, #65536  ; 0x10000
      
      which is taken by the very first printk call:
      
          at /home/fainelli/work/linux/arch/arm/include/asm/spinlock.h:65
          fmt=0xc0637650 " 01 66Booting Linux on physical CPU 0x%xn", args=<incomplete type>)
          at kernel/printk/printk.c:1525
          fmt=0xc05370f4 <printk+52> " 24320215342 04340235344 20320215342 36377/341 17") at kernel/printk/printk.c:1688
      
      ldrex requires exclusive monitor(s) (local or global) which are no longer
      working when the Data cache is disabled in CP15 and will just hang the CPU
      there.
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e1e2f6e4
    • Paul Walmsley's avatar
      ARM: 8335/1: Documentation: DT bindings: Tegra AHB: document the legacy base address · 38e42f12
      Paul Walmsley authored
      Documentation: DT bindings: Tegra AHB: require the legacy base address for existing chips
      
      Per Stephen Warren, note in the Tegra AHB DT binding documentation
      that we specifically deprecate any attempt to use the IP block's
      actual hardware base address, and advocate the use of the legacy
      "off-by-four" address in the 'regs' property, for Tegra chips with
      existing upstream Linux DT files that include a Tegra AHB node.  This
      patch updates the documentation accordingly.
      
      Changing the existing kernel DT data isn't under consideration because
      Linux kernel DT data policy is to preserve compatibility between newer
      DT data files and older kernels.  However, this additional step of
      changing the documentation should discourage others from sending
      kernel patches to try to change the legacy kernel DT data.
      Furthermore, for out-of-tree software (such as bootloaders or other
      operating systems) that may rely on Linux kernel DT binding
      documentation as an ABI (but not the Linux kernel DT data itself),
      such a change may allow future convergence with the Linux kernel DT
      data without additional code changes.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Paul Walmsley <pwalmsley@nvidia.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      38e42f12
    • Paul Walmsley's avatar
      ARM: 8334/1: amba: tegra-ahb: detect and correct bogus base address · ce7a10b0
      Paul Walmsley authored
      amba: tegra-ahb: detect and correct bogus base address
      
      From a hardware SoC integration point of view, the starting address of
      this IP block in the existing Tegra SoC DT files is off by 4 bytes
      from the actual base address.  Since we attempt to make old DT files
      forward-compatible with newer kernels, we cannot fix the IP block base
      address in old DT data. This patch works around the problem by
      detecting the four byte base address offset in the driver code, and
      correcting it if it's detected.  (In general, IP block base addresses
      almost always have a null low byte.)
      
      Future SoC DT data for Tegra AHB should use the correct Tegra AHB base
      address, in cases where there is no DT data backward compatibility
      requirement.
      
      This patch is a revision of the patch originally titled
      "amba: tegra-ahb: use correct base address for future chip support".
      This revision implements changes requested by Russell King:
      
      http://marc.info/?l=linux-tegra&m=142658851825062&w=2
      http://marc.info/?l=linux-tegra&m=142658873925178&w=2Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Paul Walmsley <pwalmsley@nvidia.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Hiroshi DOYU <hdoyu@nvidia.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ce7a10b0
    • Paul Walmsley's avatar
      ARM: 8333/1: amba: tegra-ahb: fix register offsets in the macros · 049e4b3f
      Paul Walmsley authored
      amba: tegra-ahb: fix register offsets in the macros
      
      From a hardware SoC integration point of view, the offsets of the
      Tegra AHB registers that are currently defined in tegra-ahb.c macros
      are all off by four bytes.  Similarly, the starting address of this IP
      block in our existing DT files is also off by four bytes.  Since we
      attempt to make old DT files forward-compatible with newer kernels, we
      cannot fix the IP block base address in old DT data.  However, we can
      fix the offsets in the driver so that they are correct with respect to
      the hardware, which is what this patch does.  And a subsequent patch
      will allow the offset to be removed for DT 'compatible' strings used
      in future DT files for newer Tegra chips that the kernel does not yet
      support.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Paul Walmsley <pwalmsley@nvidia.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Hiroshi DOYU <hdoyu@nvidia.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      049e4b3f
    • Geert Uytterhoeven's avatar
      ARM: 8339/1: Enable CONFIG_GENERIC_IRQ_SHOW_LEVEL · 7c07005e
      Geert Uytterhoeven authored
      Several interrupt controllers support both edge and level interrupts, so
      it's useful to provide that information in /proc/interrupts.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7c07005e
    • Geert Uytterhoeven's avatar
      ARM: 8338/1: kexec: Relax SMP validation to improve DT compatibility · fee3fd4f
      Geert Uytterhoeven authored
      When trying to kexec into a new kernel on a platform where multiple CPU
      cores are present, but no SMP bringup code is available yet, the
      kexec_load system call fails with:
      
          kexec_load failed: Invalid argument
      
      The SMP test added to machine_kexec_prepare() in commit 2103f6cb
      ("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
      kexec on SMP platforms where it cannot disable secondary CPUs.
      However, this test is too strict: if the secondary CPUs couldn't be
      enabled in the first place, there's no need to disable them later at
      kexec time.  Hence skip the test in the absence of SMP bringup code.
      
      This allows to add all CPU cores to the DTS from the beginning, without
      having to implement SMP bringup first, improving DT compatibility.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      fee3fd4f
    • Tomasz Figa's avatar
      ARM: 8337/1: mm: Do not invoke OOM for higher order IOMMU DMA allocations · 49f28aa6
      Tomasz Figa authored
      IOMMU should be able to use single pages as well as bigger blocks, so if
      higher order allocations fail, we should not affect state of the system,
      with events such as OOM killer, but rather fall back to order 0
      allocations.
      
      This patch changes the behavior of ARM IOMMU DMA allocator to use
      __GFP_NORETRY, which bypasses OOM invocation, for orders higher than
      zero and, only if that fails, fall back to normal order 0 allocation
      which might invoke OOM killer.
      Signed-off-by: default avatarTomasz Figa <tfiga@chromium.org>
      Reviewed-by: default avatarDoug Anderson <dianders@chromium.org>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      49f28aa6
    • Russell King's avatar
      ARM: move reboot code to arch/arm/kernel/reboot.c · 045ab94e
      Russell King authored
      Move shutdown and reboot related code to a separate file, out of
      process.c.  This helps to avoid polluting process.c with non-process
      related code.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      045ab94e
    • Russell King's avatar
      ARM: fix broken hibernation · 767bf7e7
      Russell King authored
      Normally, when a CPU wants to clear a cache line to zero in the external
      L2 cache, it would generate bus cycles to write each word as it would do
      with any other data access.
      
      However, a Cortex A9 connected to a L2C-310 has a specific feature where
      the CPU can detect this operation, and signal that it wants to zero an
      entire cache line.  This feature, known as Full Line of Zeros (FLZ),
      involves a non-standard AXI signalling mechanism which only the L2C-310
      can properly interpret.
      
      There are separate enable bits in both the L2C-310 and the Cortex A9 -
      the L2C-310 needs to be enabled and have the FLZ enable bit set in the
      auxiliary control register before the Cortex A9 has this feature
      enabled.
      
      Unfortunately, the suspend code was not respecting this - it's not
      obvious from the code:
      
      swsusp_arch_suspend()
       cpu_suspend() /* saves the Cortex A9 auxiliary control register */
        arch_save_image()
        soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
         cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
      
      At this point, we end up with the L2C disabled, but the Cortex A9 with
      FLZ enabled - which means any memset() or zeroing of a full cache line
      will fail to take effect.
      
      A similar issue exists in the resume path, but it's slightly more
      complex:
      
      swsusp_arch_suspend()
       cpu_suspend() /* saves the Cortex A9 auxiliary control register */
        arch_save_image() /* image with A9 auxcr saved */
      ...
      swsusp_arch_resume()
       call_with_stack()
        arch_restore_image() /* restores image with A9 auxcr saved above */
        soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
         cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
      
      Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.
      
      There's no need to turn off the L2C in either of these two paths; there
      are benefits from not doing so - for example, the page copies will be
      faster with the L2C enabled.
      
      Hence, fix this by providing a variant of soft_restart() which can be
      used without turning the L2 cache controller off, and use it in both
      of these paths to keep the L2C enabled across the respective resume
      transitions.
      
      Fixes: 8ef418c7 ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
      Reported-by: default avatarSean Cross <xobs@kosagi.com>
      Tested-by: default avatarSean Cross <xobs@kosagi.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      767bf7e7
  5. 29 Mar, 2015 7 commits
  6. 28 Mar, 2015 7 commits
  7. 27 Mar, 2015 3 commits
    • Russell King's avatar
      ARM: add documentation for finding start of physical memory · 0a6a78b8
      Russell King authored
      Occasionally, there's a question about the method we use to find the
      start of physical memory.  Add some documentation so we don't have to
      keep repeating outselves on the mailing list.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      0a6a78b8
    • Nathan Lynch's avatar
      ARM: 8332/1: add CONFIG_VDSO Kconfig and Makefile bits · e5b61deb
      Nathan Lynch authored
      Allow users to enable the vdso in Kconfig; include the vdso in the
      build if CONFIG_VDSO is enabled.  Add 'vdso_install' target.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e5b61deb
    • Nathan Lynch's avatar
      ARM: 8331/1: VDSO initialization, mapping, and synchronization · ecf99a43
      Nathan Lynch authored
      Initialize the VDSO page list at boot, install the VDSO mapping at
      exec time, and update the data page during timer ticks.  This code is
      not built if CONFIG_VDSO is not enabled.
      
      Account for the VDSO length when randomizing the offset from the
      stack.  The [vdso] and [vvar] pages are placed immediately following
      the sigpage with separate _install_special_mapping calls.
      
      We want to "penalize" systems lacking the arch timer as little
      as possible.  Previous versions of this code installed the VDSO
      unconditionally and unmodified, making it a measurably slower way for
      glibc to invoke the real syscalls on such systems.  E.g. calling
      gettimeofday via glibc goes from ~560ns to ~630ns on i.MX6Q.
      
      If we can indicate to glibc that the time-related APIs in the VDSO are
      not accelerated, glibc can continue to invoke the syscalls directly
      instead of dispatching through the VDSO only to fall back to the slow
      path.
      
      Thus, if the architected timer is unusable for whatever reason, patch
      the VDSO at boot time so that symbol lookups for gettimeofday and
      clock_gettime return NULL.  (This is similar to what powerpc does and
      borrows code from there.)  This allows glibc to perform the syscall
      directly instead of passing control to the VDSO, which minimizes the
      penalty.  In my measurements the time taken for a gettimeofday call
      via glibc goes from ~560ns to ~580ns (again on i.MX6Q), and this is
      solely due to adding a test and branch to glibc's gettimeofday syscall
      wrapper.
      
      An alternative to patching the VDSO at boot would be to not install
      the VDSO at all when the arch timer isn't usable.  Another alternative
      is to include a separate "dummy" vdso.so without gettimeofday and
      clock_gettime, which would be selected at boot time.  Either of these
      would get cumbersome if the VDSO were to gain support for an API such
      as getcpu which is unrelated to arch timer support.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ecf99a43