1. 03 10月, 2013 5 次提交
  2. 13 9月, 2013 3 次提交
    • M
      Remove GENERIC_HARDIRQ config option · 0244ad00
      Martin Schwidefsky 提交于
      After the last architecture switched to generic hard irqs the config
      options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code
      for !CONFIG_GENERIC_HARDIRQS can be removed.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0244ad00
    • M
      MIPS: DECstation I/O ASIC DMA interrupt handling fix · 5359b938
      Maciej W. Rozycki 提交于
      This change complements commit d0da7c002f7b2a93582187a9e3f73891a01d8ee4
      and brings clear_ioasic_irq back, renaming it to clear_ioasic_dma_irq at
      the same time, to make I/O ASIC DMA interrupts functional.
      
      Unlike ordinary I/O ASIC interrupts DMA interrupts need to be deasserted
      by software by writing 0 to the respective bit in I/O ASIC's System
      Interrupt Register (SIR), similarly to how CP0.Cause.IP0 and CP0.Cause.IP1
      bits are handled in the CPU (the difference is SIR DMA interrupt bits are
      R/W0C so there's no need for an RMW cycle).  Otherwise the handler is
      reentered over and over again.
      
      The only current user is the DEC LANCE Ethernet driver and its extremely
      uncommon DMA memory error handler that does not care when exactly the
      interrupt is cleared.  Anticipating the use of DMA interrupts by the Zilog
      SCC driver this change however exports clear_ioasic_dma_irq for device
      drivers to choose the right application-specific sequence to clear the
      request explicitly rather than calling it implicitly in the .irq_eoi
      handler of `struct irq_chip'.  Previously these interrupts were cleared in
      the .end handler of the said structure, before it was removed.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5826/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5359b938
    • K
      thp: account anon transparent huge pages into NR_ANON_PAGES · 3cd14fcd
      Kirill A. Shutemov 提交于
      We use NR_ANON_PAGES as base for reporting AnonPages to user.  There's
      not much sense in not accounting transparent huge pages there, but add
      them on printing to user.
      
      Let's account transparent huge pages in NR_ANON_PAGES in the first place.
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: Ning Qu <quning@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3cd14fcd
  3. 12 9月, 2013 32 次提交