1. 29 3月, 2011 3 次提交
  2. 06 10月, 2010 1 次提交
    • T
      [IA64] Initialize interrupts later (from init_IRQ()) · 4de0a759
      Tony Luck 提交于
      Thomas Gleixner is cleaning up the generic irq code, and ia64 ran
      into problems because it calls register_intr() before early_irq_init()
      is called.  Move the call to acpi_boot_init() from setup_arch() to
      init_IRQ().
      
      As a bonus - moving the call later means we no longer need the
      hacks in iosapic.c to switch between the bootmem and regular
      allocator - we can just used kzalloc() for allocation.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      4de0a759
  3. 28 9月, 2010 1 次提交
    • T
      [IA64] Stop using the deprecated __do_IRQ() code path · 5d4bff94
      Tony Luck 提交于
      Thomas Gleixner <tglx@linutronix.de> wrote:
      >__do_IRQ() has been deprecated after a two years migration phase in
      >commit 0e57aa11. Since then another 18 months have gone by ...
      
      Mostly trivial stuff for this. The only tricky part was realizing
      that the new handler_*_irq() paths do not use desc->chip->end(irq).
      Not a problem for the edge case as the ia64 iosapic routine for
      that was nop(). But the "level" case handled interrupt migration
      there.  Just use a slightly modified version of the "end" routine
      as "unmask" for the level triggered case.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      5d4bff94
  4. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  5. 15 12月, 2009 1 次提交
  6. 12 8月, 2009 1 次提交
  7. 16 6月, 2009 3 次提交
  8. 28 4月, 2009 1 次提交
    • Y
      irq: change ->set_affinity() to return status · d5dedd45
      Yinghai Lu 提交于
      according to Ingo, change set_affinity() in irq_chip should return int,
      because that way we can handle failure cases in a much cleaner way, in
      the genirq layer.
      
      v2: fix two typos
      
      [ Impact: extend API ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: linux-arch@vger.kernel.org
      LKML-Reference: <49F654E9.4070809@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d5dedd45
  9. 26 2月, 2009 1 次提交
  10. 13 1月, 2009 1 次提交
  11. 26 12月, 2008 1 次提交
  12. 13 12月, 2008 1 次提交
  13. 02 8月, 2008 1 次提交
    • T
      [IA64] Move include/asm-ia64 to arch/ia64/include/asm · 7f30491c
      Tony Luck 提交于
      After moving the the include files there were a few clean-ups:
      
      1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h>
      
      2) Some comments alerted maintainers to look at various header files to
      make matching updates if certain code were to be changed. Updated these
      comments to use the new include paths.
      
      3) Some header files mentioned their own names in initial comments. Just
      deleted these self references.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      7f30491c
  14. 25 6月, 2008 1 次提交
  15. 28 5月, 2008 1 次提交
  16. 07 3月, 2008 1 次提交
  17. 05 3月, 2008 1 次提交
    • K
      [IA64] Fix irq migration in multiple vector domain · a6cd6322
      Kenji Kaneshige 提交于
      Fix the problem that the following error message is sometimes displayed
      at irq migration when vector domain is enabled.
      
          "Unexpected interrupt vector %d on CPU %d is not mapped to any IRQ!"
      
      The cause of this problem is an interrupt is sent to the previous
      target CPU after cleaning up vector to irq mapping table. To clean up
      vector to irq map on the previous target CPU safty, change the irq
      migration in multiple vector domain as follows. The original idea is
      from x86 interrupt management code.
      
          - Delay vector to irq table cleanup until the interrupts are sent
            to new target CPUs. By this, it is ensured that target CPU is
            completely changed on the interrupt controller side.
      
          - Even after the interrupts are sent to new target CPUs, there can
            be pended interrupts remaining on the previous target CPU. So we
            need to delay clearning up vector to irq table until the pended
            interrupt is handled. For this, send IPI to the previous target
            CPU with lower priority vector and clean up vector to irq table
            in its handler.
      
      This patch affects only to irq migration code with multiple vector
      domain is enabled.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a6cd6322
  18. 08 12月, 2007 2 次提交
  19. 10 11月, 2007 1 次提交
  20. 02 8月, 2007 1 次提交
  21. 31 7月, 2007 2 次提交
    • K
      [IA64] Fix registered interrupt check · c4c376f7
      Kenji Kaneshige 提交于
      Fix the problem that interrupts are not initialized correctly at PCI
      hotplug or driver reloading time.
      
      By vector domain change, the iosapic_rte_info structure was changed to
      be on the iosapic_intr_info[irq].rtes list even after the interrupts
      are unregistered. So iosapic_intr_info[irq].rtes list must not be
      checked to see if there are registered interrupts (RTEs) on the
      irq. We must check iosapic_intr_info[irq].count counter instead.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      c4c376f7
    • S
      [IA64] fix a few section mismatch warnings · 056e6d89
      Sam Ravnborg 提交于
      Fix the following section mismatch warnings:
      
      WARNING: vmlinux.o(.text+0x41902): Section mismatch: reference to .init.text:__alloc_bootmem (between 'ia64_mca_cpu_init' and 'ia64_do_tlb_purge')
      WARNING: vmlinux.o(.text+0x49222): Section mismatch: reference to .init.text:__alloc_bootmem (between 'register_intr' and 'iosapic_register_intr')
      WARNING: vmlinux.o(.text+0x62beb2): Section mismatch: reference to .init.text:__alloc_bootmem_node (between 'hubdev_init_node' and 'cnodeid_get_geoid')
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      056e6d89
  22. 20 7月, 2007 1 次提交
    • Y
      [IA64] Delete iosapic_free_rte() · bf903d0a
      Yasuaki Ishimatsu 提交于
      >   arch/ia64/kernel/iosapic.c:597: warning: 'iosapic_free_rte' defined but not used
      >
      > This isn't spurious, the only call to iosapic_free_rte() has been removed, but there
      > is still a call to iosapic_alloc_rte() ... which means we must have a memory leak.
      
      I did it on purpose (and gave the warning a miss...) and I consider
      iosapic_free_rte() is no longer needed.
      
      I decided to remain iosapic_rte_info to keep gsi-to-irq binding
      after device disable. Indeed it needs some extra memory, but it
      is only "sizeof(iosapic_rte_info) * <the number of removed devices>"
      bytes and has no memory leak becasue re-enabled devices use the
      iosapic_rte_info which they used before disabling.
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      bf903d0a
  23. 18 7月, 2007 10 次提交
  24. 09 5月, 2007 1 次提交
  25. 08 5月, 2007 1 次提交