1. 07 1月, 2015 4 次提交
  2. 24 12月, 2014 1 次提交
    • J
      arm64: mm: Add pgd_page to support RCU fast_gup · 5d96e0cb
      Jungseok Lee 提交于
      This patch adds pgd_page definition in order to keep supporting
      HAVE_GENERIC_RCU_GUP configuration. In addition, it changes pud_page
      expression to align with pmd_page for readability.
      
      An introduction of pgd_page resolves the following build breakage
      under 4KB + 4Level memory management combo.
      
      mm/gup.c: In function 'gup_huge_pgd':
      mm/gup.c:889:2: error: implicit declaration of function 'pgd_page' [-Werror=implicit-function-declaration]
        head = pgd_page(orig);
        ^
      mm/gup.c:889:7: warning: assignment makes pointer from integer without a cast
        head = pgd_page(orig);
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Signed-off-by: NJungseok Lee <jungseoklee85@gmail.com>
      [catalin.marinas@arm.com: remove duplicate pmd_page definition]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      5d96e0cb
  3. 22 12月, 2014 1 次提交
  4. 18 12月, 2014 1 次提交
  5. 13 12月, 2014 4 次提交
  6. 12 12月, 2014 1 次提交
    • A
      arch: Add lightweight memory barriers dma_rmb() and dma_wmb() · 1077fa36
      Alexander Duyck 提交于
      There are a number of situations where the mandatory barriers rmb() and
      wmb() are used to order memory/memory operations in the device drivers
      and those barriers are much heavier than they actually need to be.  For
      example in the case of PowerPC wmb() calls the heavy-weight sync
      instruction when for coherent memory operations all that is really needed
      is an lsync or eieio instruction.
      
      This commit adds a coherent only version of the mandatory memory barriers
      rmb() and wmb().  In most cases this should result in the barrier being the
      same as the SMP barriers for the SMP case, however in some cases we use a
      barrier that is somewhere in between rmb() and smp_rmb().  For example on
      ARM the rmb barriers break down as follows:
      
        Barrier   Call     Explanation
        --------- -------- ----------------------------------
        rmb()     dsb()    Data synchronization barrier - system
        dma_rmb() dmb(osh) data memory barrier - outer sharable
        smp_rmb() dmb(ish) data memory barrier - inner sharable
      
      These new barriers are not as safe as the standard rmb() and wmb().
      Specifically they do not guarantee ordering between coherent and incoherent
      memories.  The primary use case for these would be to enforce ordering of
      reads and writes when accessing coherent memory that is shared between the
      CPU and a device.
      
      It may also be noted that there is no dma_mb().  Most architectures don't
      provide a good mechanism for performing a coherent only full barrier without
      resorting to the same mechanism used in mb().  As such there isn't much to
      be gained in trying to define such a function.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1077fa36
  7. 11 12月, 2014 2 次提交
  8. 05 12月, 2014 1 次提交
    • S
      clocksource: arch_timer: Fix code to use physical timers when requested · 0b46b8a7
      Sonny Rao 提交于
      This is a bug fix for using physical arch timers when
      the arch_timer_use_virtual boolean is false.  It restores the
      arch_counter_get_cntpct() function after removal in
      
      0d651e4e "clocksource: arch_timer: use virtual counters"
      
      We need this on certain ARMv7 systems which are architected like this:
      
      * The firmware doesn't know and doesn't care about hypervisor mode and
        we don't want to add the complexity of hypervisor there.
      
      * The firmware isn't involved in SMP bringup or resume.
      
      * The ARCH timer come up with an uninitialized offset between the
        virtual and physical counters.  Each core gets a different random
        offset.
      
      * The device boots in "Secure SVC" mode.
      
      * Nothing has touched the reset value of CNTHCTL.PL1PCEN or
        CNTHCTL.PL1PCTEN (both default to 1 at reset)
      
      One example of such as system is RK3288 where it is much simpler to
      use the physical counter since there's nobody managing the offset and
      each time a core goes down and comes back up it will get reinitialized
      to some other random value.
      
      Fixes: 0d651e4e ("clocksource: arch_timer: use virtual counters")
      Cc: stable@vger.kernel.org
      Signed-off-by: NSonny Rao <sonnyrao@chromium.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      0b46b8a7
  9. 04 12月, 2014 6 次提交
  10. 03 12月, 2014 1 次提交
  11. 01 12月, 2014 1 次提交
  12. 28 11月, 2014 3 次提交
  13. 26 11月, 2014 2 次提交
  14. 25 11月, 2014 9 次提交
  15. 21 11月, 2014 3 次提交