1. 09 Feb, 2012 1 commit
  2. 04 Feb, 2012 2 commits
  3. 03 Feb, 2012 1 commit
  4. 02 Feb, 2012 6 commits
    • Catalin Marinas's avatar
      ARM: 7302/1: Add TLB flushing for both entries in a PMD · 6d3ec1ae
      Catalin Marinas authored
      Linux uses two PMD entries for a PTE with the classic page table format,
      covering 2MB range. However, the __pte_free_tlb() function only adds a
      single TLB flush corresponding to 1MB range covering 'addr'. On
      Cortex-A15, level 1 entries can be cached by the TLB independently of
      the level 2 entries and without additional flushing a PMD entry would be
      left pointing at the wrong PTE. The patch limits the TLB flushing range
      to two 4KB pages around the 1MB boundary within PMD.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Will Deacon's avatar
      ARM: 7303/1: perf: add empty NODE event definitions for Cortex-A5 and Cortex-A15 · 91756acb
      Will Deacon authored
      Commit 89d6c0b5
       ("perf, arch: Add generic NODE cache events") added
      empty NODE event definitions for the ARM PMU implementations. This was
      merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
      out on the original patch.
      This patch adds the empty definitions to Cortex-A5 and Cortex-A15.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Will Deacon's avatar
      ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers · 8130b9d7
      Will Deacon authored
      If we are context switched whilst copying into a thread's
      vfp_hard_struct then the partial copy may be corrupted by the VFP
      context switching code (see "ARM: vfp: flush thread hwstate before
      restoring context from sigframe").
      This patch updates the ptrace VFP set code so that the thread state is
      flushed before the copy, therefore disabling VFP and preventing
      corruption from occurring.
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Dave Martin's avatar
      ARM: 7307/1: vfp: fix ptrace regset modification race · 247f4993
      Dave Martin authored
      In a preemptible kernel, vfp_set() can be preempted, causing the
      hardware VFP context to be switched while the thread vfp state is
      being read and modified.  This leads to a race condition which can
      cause the thread vfp state to become corrupted if lazy VFP context
      save occurs due to preemption in between the time thread->vfpstate
      is read and the time the modified state is written back.
      This may occur if preemption occurs during the execution of a
      ptrace() call which modifies the VFP register state of a thread.
      Such instances should be very rare in most realistic scenarios --
      none has been reported, so far as I am aware.  Only uniprocessor
      systems should be affected, since VFP context save is not currently
      lazy in SMP kernels.
      The problem was introduced by my earlier patch migrating to use
      regsets to implement ptrace.
      This patch does a vfp_sync_hwstate() before reading
      thread->vfpstate, to make sure that the thread's VFP state is not
      live in the hardware registers while the registers are modified.
      Thanks to Will Deacon for spotting this.
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Martin <dave.martin@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Will Deacon's avatar
      ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe · 2af276df
      Will Deacon authored
      Following execution of a signal handler, we currently restore the VFP
      context from the ucontext in the signal frame. This involves copying
      from the user stack into the current thread's vfp_hard_struct and then
      flushing the new data out to the hardware registers.
      This is problematic when using a preemptible kernel because we could be
      context switched whilst updating the vfp_hard_struct. If the current
      thread has made use of VFP since the last context switch, the VFP
      notifier will copy from the hardware registers into the vfp_hard_struct,
      overwriting any data that had been partially copied by the signal code.
      Disabling preemption across copy_from_user calls is a terrible idea, so
      instead we move the VFP thread flush *before* we update the
      vfp_hard_struct. Since the flushing is performed lazily, this has the
      effect of disabling VFP and clearing the CPU's VFP state pointer,
      therefore preventing the thread from being updated with stale data on
      the next context switch.
      Cc: stable <stable@vger.kernel.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Russell King's avatar
      Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" · 97f10409
      Russell King authored
      This reverts commit 3c424f35.
      Joachim Eastwood reports:
      | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
      | Commit: 3c424f35
       in Linus master
      | Breaks booting on my custom AT91RM9200 board.
      | There isn't any error messages or anything that indicates what goes
      | wrong it just stops after; Uncompressing Linux... done, booting the
      | kernel.
      | Reverting it makes my board boot again.
      and further debugging reveals:
      ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
      ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
      ioremap: found: addr fef74000 => fed73000 => fed73400
      Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
      0xfffff.  This happens because the changed if statement becomes:
                      if (0x00200 > 0xfffff ||
                          0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
      and therefore:
                      if (0x00200 > 0xfffff ||
                          0x000003ff > 0x00203fff)
      The if condition fails, and so we _believe_ that the SRAM mapping fits
      our request.  Clearly that's totally bogus.
      Moreover, the original premise of the 'fix' patch was wrong:
      |    The condition checking boundaries of the requested and existing
      |    mappings didn't take in-page offset into consideration though,
      |    which lead to obscure and hard to debug problems when requested
      |    mapping crossed end of the static one.
      as the code immediately above this loop does:
              size = PAGE_ALIGN(offset + size);
      so 'size' already contains the requested offset into the page.
      So, revert the broken 'fix'.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
  5. 01 Feb, 2012 1 commit
  6. 27 Jan, 2012 2 commits
  7. 26 Jan, 2012 15 commits
  8. 25 Jan, 2012 9 commits
  9. 24 Jan, 2012 1 commit
    • Paul Walmsley's avatar
      tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip · 43cf7c0b
      Paul Walmsley authored
      It seems that when the transmit FIFO threshold is reached on OMAP
      UARTs, it does not result in a PRCM wakeup.  This appears to be a
      silicon bug.  This means that if the MPU powerdomain is in a low-power
      state, the MPU will not be awakened to refill the FIFO until the next
      interrupt from another device.
      The best solution, at least for the short term, would be for the OMAP
      serial driver to call a OMAP subarchitecture function to prevent the
      MPU powerdomain from entering a low power state while the FIFO has
      data to transmit.  However, we no longer have a clean way to do this,
      since patches that add platform_data function pointers have been
      deprecated by the OMAP maintainer.  So we attempt to work around this
      as well.  The workarounds depend on the setting of CONFIG_CPU_IDLE.
      When CONFIG_CPU_IDLE=n, the driver will now only transmit one byte at
      a time.  This causes the transmit FIFO threshold interrupt to stay
      active until there is no more data to be sent.  Thus, the MPU
      powerdomain stays on during transmits.  Aside from that energy
      consumption penalty, each transmitted byte results in a huge number of
      UART interrupts -- about five per byte.  This wastes CPU time and is
      quite inefficient, but is probably the most expedient workaround in
      this case.
      When CONFIG_CPU_IDLE=y, there is a slightly more direct workaround:
      the PM QoS constraint can be abused to keep the MPU powerdomain on.
      This results in a normal number of interrupts, but, similar to the
      above workaround, wastes power by preventing the MPU from entering
      Future patches are planned for the 3.4 merge window to implement more
      efficient, but also more disruptive, workarounds to these problems.
      DMA operation is unaffected by this patch.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Govindraj Raja <govindraj.r@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  10. 23 Jan, 2012 2 commits