1. 02 11月, 2009 3 次提交
    • S
      x86: Remove move_cleanup_count from irq_cfg · 23359a88
      Suresh Siddha 提交于
      move_cleanup_count for each irq in irq_cfg is keeping track of
      the total number of cpus that need to free the corresponding
      vectors associated with the irq which has now been migrated to
      new destination. As long as this move_cleanup_count is non-zero
      (i.e., as long as we have n't freed the vector allocations on
      the old destinations) we were preventing the irq's further
      migration.
      
      This cleanup count is unnecessary and it is enough to not allow
      the irq migration till we send the cleanup vector to the
      previous irq destination, for which we already have irq_cfg's
      move_in_progress.  All we need to make sure is that we free the
      vector at the old desintation but we don't need to wait till
      that gets freed.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.752968906@sbs-t61.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      23359a88
    • S
      x86, intr-remap: Avoid irq_chip mask/unmask in fixup_irqs() for intr-remapping · 84e21493
      Suresh Siddha 提交于
      In the presence of interrupt-remapping, irqs will be migrated in
      the process context and we don't do (and there is no need to)
      irq_chip mask/unmask while migrating the interrupt.
      
      Similarly fix the fixup_irqs() that get called during cpu
      offline and avoid calling irq_chip mask/unmask for irqs that are
      ok to be migrated in the process context.
      
      While we didn't observe any race condition with the existing
      code, this change takes complete advantage of
      interrupt-remapping in the newer generation platforms and avoids
      any potential HW lockup's (that often worry Eric :)
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: garyhade@us.ibm.com
      LKML-Reference: <20091026230001.661423939@sbs-t61.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      84e21493
    • S
      x86: Unify fixup_irqs() for 32-bit and 64-bit kernels · 7a7732bc
      Suresh Siddha 提交于
      There is no reason to have different fixup_irqs() for 32-bit and
      64-bit kernels. Unify by using the superior 64-bit version for
      both the kernels.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.562512739@sbs-t61.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7a7732bc
  2. 27 10月, 2009 1 次提交
  3. 15 10月, 2009 1 次提交
    • C
      x86: apic: Allow noop operations to be called almost at any time · f88f2b4f
      Cyrill Gorcunov 提交于
      As only apic noop is used we allow to use almost any operation
      caller wants (and which of them noop driver supports of
      course).
      
      Initially it was reported by Ingo Molnar that apic noop
      issue a warning for pkg id (which is actually false positive
      and should be eliminated).
      
      So we save checking (and warning issue) for read/write
      operations while allow any other ops to be freely used.
      
      Also:
       - fix noop_cpu_to_logical_apicid, it should be 0.
       - rename noop_default_phys_pkg_id to noop_phys_pkg_id
         (we use default_ prefix for more general routines
          in apic subsystem).
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      LKML-Reference: <20091015150416.GC5331@lenovo>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f88f2b4f
  4. 14 10月, 2009 16 次提交
  5. 13 10月, 2009 17 次提交
  6. 12 10月, 2009 2 次提交
    • D
      x86: Move pci_iommu_init to rootfs_initcall() · 9a821b23
      David Woodhouse 提交于
      We want this to happen after the PCI quirks, which are now running at
      the very end of the fs_initcalls.
      
      This works around the BIOS problems which were originally addressed by
      commit db8be50c ('USB: Work around BIOS
      bugs by quiescing USB controllers earlier'), which was reverted in
      commit d93a8f82.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      9a821b23
    • D
      Run pci_apply_final_quirks() sooner. · cf6f3bf7
      David Woodhouse 提交于
      Having this as a device_initcall() means that some real device drivers
      can actually initialise _before_ the quirks are run, which is wrong.
      
      We want it to run _before_ device_initcall(), but _after_ fs_initcall(),
      since some arch-specific PCI initialisation like pcibios_assign_resources()
      is done at fs_initcall().
      
      We could use rootfs_initcall() but I actually want to use that for the
      IOMMU initialisation, which has to come after the quirks, but still
      before the real devices. So use fs_initcall_sync() instead -- since this
      is entirely synchronous, it doesn't hurt that it'll escape the
      synchronisation.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      cf6f3bf7