1. 10 12月, 2010 1 次提交
  2. 06 12月, 2010 1 次提交
  3. 24 10月, 2010 1 次提交
  4. 23 10月, 2010 1 次提交
  5. 18 10月, 2010 1 次提交
  6. 12 10月, 2010 1 次提交
  7. 10 6月, 2010 1 次提交
    • E
      x86, irq: Rename gsi_end gsi_top, and fix off by one errors · a4384df3
      Eric W. Biederman 提交于
      When I introduced the global variable gsi_end I thought gsi_end on
      io_apics was one past the end of the gsi range for the io_apic.  After
      it was pointed out the the range on io_apics was inclusive I changed
      my global variable to match.  That was a big mistake.  Inclusive
      semantics without a range start cannot describe the case when no gsi's
      are allocated.  Describing the case where no gsi's are allocated is
      important in sfi.c and mpparse.c so that we can assign gsi numbers
      instead of blindly copying the gsi assignments the BIOS has done as we
      do in the acpi case.
      
      To keep from getting the global variable confused with the gsi range
      end rename it gsi_top.
      
      To allow describing the case where no gsi's are allocated have gsi_top
      be one place the highest gsi number seen in the system.
      
      This fixes an off by one bug in sfi.c:
      Reported-by: Njacob pan <jacob.jun.pan@linux.intel.com>
      
      This fixes the same off by one bug in mpparse.c:
      
      This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
      Reported-by: NYinghai <yinghai.lu@oracle.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m17hm9jre7.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a4384df3
  8. 06 5月, 2010 1 次提交
  9. 05 5月, 2010 3 次提交
  10. 24 2月, 2010 2 次提交
  11. 20 2月, 2010 1 次提交
  12. 11 2月, 2010 1 次提交
    • Y
      x86: Fix SCI on IOAPIC != 0 · 18dce6ba
      Yinghai Lu 提交于
      Thomas Renninger <trenn@suse.de> reported on IBM x3330
      
      booting a latest kernel on this machine results in:
      
      PCI: PCI BIOS revision 2.10 entry at 0xfd61c, last bus=1
      PCI: Using configuration type 1 for base access bio: create slab <bio-0> at 0
      ACPI: SCI (IRQ30) allocation failed
      ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20090903/evevent-161)
      ACPI: Unable to start the ACPI Interpreter
      
      Later all kind of devices fail...
      
      and bisect it down to this commit:
      commit b9c61b70
      
          x86/pci: update pirq_enable_irq() to setup io apic routing
      
      it turns out we need to set irq routing for the sci on ioapic1 early.
      
      -v2: make it work without sparseirq too.
      -v3: fix checkpatch.pl warning, and cc to stable
      Reported-by: NThomas Renninger <trenn@suse.de>
      Bisected-by: NThomas Renninger <trenn@suse.de>
      Tested-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <1265793639-15071-2-git-send-email-yinghai@kernel.org>
      Cc: stable@kernel.org
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      18dce6ba
  13. 01 9月, 2009 1 次提交
    • T
      x86: Distangle ioapic and i8259 · bc07844a
      Thomas Gleixner 提交于
      The proposed Moorestown support patches use an extra feature flag
      mechanism to make the ioapic work w/o an i8259. There is a much
      simpler solution.
      
      Most i8259 specific functions are already called dependend on the irq
      number less than NR_IRQS_LEGACY. Replacing that constant by a
      read_mostly variable which can be set to 0 by the platform setup code
      allows us to achieve the same without any special feature flags.
      
      That trivial change allows us to proceed with MRST w/o doing a full
      blown overhaul of the ioapic code which would delay MRST unduly.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      bc07844a
  14. 29 8月, 2009 1 次提交
    • F
      ACPI, x86: expose some IO-APIC routines when CONFIG_ACPI=n · 2a4ab640
      Feng Tang 提交于
      Some IO-APIC routines are ACPI specific now, but need to
      be exposed when CONFIG_ACPI=n for the benefit of SFI.
      
      Remove #ifdef ACPI around these routines:
      
      io_apic_get_unique_id(int ioapic, int apic_id);
      io_apic_get_version(int ioapic);
      io_apic_get_redir_entries(int ioapic);
      
      Move these routines from ACPI-specific boot.c to io_apic.c:
      
      uniq_ioapic_id(u8 id)
      mp_find_ioapic()
      mp_find_ioapic_pin()
      mp_register_ioapic()
      
      Also, since uniq_ioapic_id() is now no longer static,
      re-name it to io_apic_unique_id() for consistency
      with the other public io_apic routines.
      
      For simplicity, do not #ifdef the resulting code ACPI || SFI,
      thought that could be done in the future if it is important
      to optimize the !ACPI !SFI IO-APIC x86 kernel for size.
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Cc: x86@kernel.org
      2a4ab640
  15. 27 8月, 2009 1 次提交
  16. 11 7月, 2009 1 次提交
    • Y
      x86/pci: insert ioapic resource before assigning unassigned resources · 857fdc53
      Yinghai Lu 提交于
      Stephen reported that his DL585 G2 needed noapic after 2.6.22 (?)
      
      Dann bisected it down to:
        commit 30a18d6c
        Date:   Tue Feb 19 03:21:20 2008 -0800
      
            x86: multi pci root bus with different io resource range, on
            64-bit
      
      It turns out that:
        1. that AMD-based systems have two HT chains.
        2. BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc
        3. that multi-peer-root patch will try to split root resources to peer
           root resources according to PCI conf of NB
        4. PCI core assigns unassigned resources, but they overlap with BARs
           that are used by ioapic addr of io4 and 8132.
      
      The reason: at that point ioapic address are not inserted yet.  Solution
      is to insert ioapic resources into the tree a bit earlier.
      Reported-by: NStephen Frost <sfrost@snowman.net>
      Reported-and-Tested-by: Ndann frazier <dannf@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: stable@kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@jbarnes-g45.(none)>
      857fdc53
  17. 18 5月, 2009 1 次提交
    • Y
      x86, apic: introduce io_apic_irq_attr · e5198075
      Yinghai Lu 提交于
      according to Ingo, io_apic irq-setup related functions have too many
      parameters with a repetitive signature.
      
      So reduce related funcs to get less params by passing a pointer
      to a newly defined io_apic_irq_attr structure.
      
      v2: io_apic_irq ==> irq_attr
          triggering ==> trigger
      
      v3: add set_io_apic_irq_attr
      
      [ Impact: cleanup ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A08ACD3.2070401@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e5198075
  18. 11 5月, 2009 1 次提交
  19. 28 4月, 2009 1 次提交
    • Y
      irq: change ACPI GSI APIs to also take a device argument · a2f809b0
      Yinghai Lu 提交于
      We want to use dev_to_node() later on, to be aware of the 'home node'
      of the GSI in question.
      
      [ Impact: cleanup, prepare the IRQ code to be more NUMA aware ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NLen Brown <lenb@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: Len Brown <lenb@kernel.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      LKML-Reference: <49F65560.20904@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a2f809b0
  20. 22 4月, 2009 1 次提交
    • S
      x86: x2apic, IR: remove reinit_intr_remapped_IO_APIC() · ff166cb5
      Suresh Siddha 提交于
      When interrupt-remapping is enabled, we are relying on
      setup_IO_APIC_irqs() to configure remapped entries in the
      IO-APIC, which comes little bit later after enabling
      interrupt-remapping.
      
      Meanwhile, restoration of old io-apic entries after enabling
      interrupt-remapping will not make the interrupts through
      io-apic functional anyway.
      
      So remove the unnecessary reinit_intr_remapped_IO_APIC() step.
      
      The longer story:
      
      When interrupt-remapping is enabled, IO-APIC entries need to be
      setup in the re-mappable format (pointing to
      interrupt-remapping table entries setup by the OS). This
      remapping configuration is happening in the same place where we
      traditionally configure IO-APIC (i.e., in
      setup_IO_APIC_irqs()).
      
      So when we enable interrupt-remapping successfully, there is no
      need to restore old io-apic RTE entries before we actually do a
      complete configuration shortly in setup_IO_APIC_irqs(). Old
      IO-APIC RTE's may be in traditional format (non re-mappable) or
      in re-mappable format pointing to interrupt-remapping table
      entries setup by BIOS. Restoring both of these will not make
      IO-APIC functional. We have to rely on setup_IO_APIC_irqs() for
      proper configuration by OS.
      
      So I am removing this unnecessary and broken step.
      
      [ Impact: remove unnecessary/broken IO-APIC setup step ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NWeidong Han <weidong.han@intel.com>
      Cc: dwmw2@infradead.org
      LKML-Reference: <20090420200450.552359000@linux-os.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ff166cb5
  21. 21 4月, 2009 1 次提交
  22. 04 4月, 2009 1 次提交
  23. 18 3月, 2009 2 次提交
    • S
      x86, ioapic: Fix non atomic allocation with interrupts disabled · 05c3dc2c
      Suresh Siddha 提交于
      Impact: fix possible race
      
      save_mask_IO_APIC_setup() was using non atomic memory allocation while getting
      called with interrupts disabled. Fix this by splitting this into two different
      function. Allocation part save_IO_APIC_setup() now happens before
      disabling interrupts.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      05c3dc2c
    • S
      x86, x2apic: cleanup the IO-APIC level migration with interrupt-remapping · 0280f7c4
      Suresh Siddha 提交于
      Impact: simplification
      
      In the current code, for level triggered migration, we need to modify the
      io-apic RTE with the update vector information, along with modifying interrupt
      remapping table entry(IRTE) with vector and destination. This is to ensure that
      remote IRR bit inthe IOAPIC RTE gets cleared when the cpu does EOI.
      
      With this patch, for level triggered, we eliminate the io-apic RTE modification
      (with the updated vector information), by using a virtual vector (io-apic pin
      number).  Real vector that is used for interrupting cpu will be coming from
      the interrupt-remapping table entry. Trigger mode in the IRTE will always be
      edge, and the actual level or edge trigger will be setup in the IO-APIC RTE.
      So a level triggered interrupt will appear as an edge to the local apic
      cpu but still as level to the IO-APIC.
      
      With this change, level irq migration can be done by simply modifying
      the interrupt-remapping table entry with out changing the io-apic RTE.
      And as the interrupt appears as edge at the cpu, in addition to do the
      local apic EOI, we need to do IO-APIC directed EOI to clear the remote
      IRR bit in  the IO-APIC RTE.
      
      This simplies the irq migration in the presence of interrupt-remapping.
      Idea-by: NRajesh Sankaran <rajesh.sankaran@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      0280f7c4
  24. 10 2月, 2009 1 次提交
  25. 06 2月, 2009 1 次提交
  26. 14 1月, 2009 2 次提交
  27. 09 12月, 2008 1 次提交
  28. 08 12月, 2008 1 次提交
  29. 23 10月, 2008 2 次提交
  30. 16 10月, 2008 2 次提交
  31. 23 7月, 2008 1 次提交
    • V
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum 提交于
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  32. 12 7月, 2008 2 次提交
    • S
      x64, x2apic/intr-remap: IO-APIC support for interrupt-remapping · 89027d35
      Suresh Siddha 提交于
      IO-APIC support in the presence of interrupt-remapping infrastructure.
      
      IO-APIC RTE will be programmed with interrupt-remapping table entry(IRTE)
      index and the IRTE will contain information about the vector, cpu destination,
      trigger mode etc, which traditionally was present in the IO-APIC RTE.
      
      Introduce a new irq_chip for cleaner irq migration (in the process
      context as opposed to the current irq migration in the context of an interrupt.
      interrupt-remapping infrastructure will help us achieve this cleanly).
      
      For edge triggered, irq migration is a simple atomic update(of vector
      and cpu destination) of IRTE and flush the hardware cache.
      
      For level triggered, we need to modify the io-apic RTE aswell with the update
      vector information, along with modifying IRTE with vector and cpu destination.
      So irq migration for level triggered is little  bit more complex compared to
      edge triggered migration. But the good news is, we use the same algorithm
      for level triggered migration as we have today, only difference being,
      we now initiate the irq migration from process context instead of the
      interrupt context.
      
      In future, when we do a directed EOI (combined with cpu EOI broadcast
      suppression) to the IO-APIC, level triggered irq migration will also be
      as simple as edge triggered migration and we can do the irq migration
      with a simple atomic update to IO-APIC RTE.
      
      TBD: some tests/changes needed in the presence of fixup_irqs() for
      level triggered irq migration.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: akpm@linux-foundation.org
      Cc: arjan@linux.intel.com
      Cc: andi@firstfloor.org
      Cc: ebiederm@xmission.com
      Cc: jbarnes@virtuousgeek.org
      Cc: steiner@sgi.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89027d35
    • S
      x64, x2apic/intr-remap: ioapic routines which deal with initial io-apic RTE setup · 4dc2f96c
      Suresh Siddha 提交于
      Generic ioapic specific routines which be used later during enabling
      interrupt-remapping.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: akpm@linux-foundation.org
      Cc: arjan@linux.intel.com
      Cc: andi@firstfloor.org
      Cc: ebiederm@xmission.com
      Cc: jbarnes@virtuousgeek.org
      Cc: steiner@sgi.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4dc2f96c