26 Oct, 2011

1 commit

  • * 'core-locking-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (27 commits)
    rtmutex: Add missing rcu_read_unlock() in debug_rt_mutex_print_deadlock()
    lockdep: Comment all warnings
    lib: atomic64: Change the type of local lock to raw_spinlock_t
    locking, lib/atomic64: Annotate atomic64_lock::lock as raw
    locking, x86, iommu: Annotate qi->q_lock as raw
    locking, x86, iommu: Annotate irq_2_ir_lock as raw
    locking, x86, iommu: Annotate iommu->register_lock as raw
    locking, dma, ipu: Annotate bank_lock as raw
    locking, ARM: Annotate low level hw locks as raw
    locking, drivers/dca: Annotate dca_lock as raw
    locking, powerpc: Annotate uic->lock as raw
    locking, x86: mce: Annotate cmci_discover_lock as raw
    locking, ACPI: Annotate c3_lock as raw
    locking, oprofile: Annotate oprofilefs lock as raw
    locking, video: Annotate vga console lock as raw
    locking, latencytop: Annotate latency_lock as raw
    locking, timer_stats: Annotate table_lock as raw
    locking, rwsem: Annotate inner lock as raw
    locking, semaphores: Annotate inner lock as raw
    locking, sched: Annotate thread_group_cputimer as raw
    ...

    Fix up conflicts in kernel/posix-cpu-timers.c manually: making
    cputimer->cputime a raw lock conflicted with the ABBA fix in commit
    bcd5cff7216f ("cputimer: Cure lock inversion").

    Linus Torvalds
     

21 Sep, 2011

5 commits

  • Signed-off-by: Suresh Siddha
    Cc: yinghai@kernel.org
    Cc: youquan.song@intel.com
    Cc: joerg.roedel@amd.com
    Cc: tony.luck@intel.com
    Cc: dwmw2@infradead.org
    Link: http://lkml.kernel.org/r/20110824001456.386003047@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • Before the restructruing of the x86 IOMMU code,
    intel_iommu_init() was getting called directly from
    pci_iommu_init() and hence needed to explicitly set
    dmar_disabled to 1 for the failure conditions of
    check_zero_address().

    Recent changes don't call intel_iommu_init() if the intel iommu
    detection fails as a result of failure in check_zero_address().

    So no need for this ifdef and the code inside it.

    Signed-off-by: Suresh Siddha
    Cc: yinghai@kernel.org
    Cc: youquan.song@intel.com
    Cc: joerg.roedel@amd.com
    Cc: tony.luck@intel.com
    Cc: dwmw2@infradead.org
    Link: http://lkml.kernel.org/r/20110824001456.334878686@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • Move the IOMMU specific routines to intel-iommu.c leaving the
    dmar.c to the common ACPI dmar code shared between DMA-remapping
    and Interrupt-remapping.

    Signed-off-by: Suresh Siddha
    Cc: yinghai@kernel.org
    Cc: youquan.song@intel.com
    Cc: joerg.roedel@amd.com
    Cc: tony.luck@intel.com
    Cc: dwmw2@infradead.org
    Link: http://lkml.kernel.org/r/20110824001456.282401285@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • Both DMA-remapping aswell as Interrupt-remapping depend on the
    dmar dev scope to be initialized. When both DMA and
    IRQ-remapping are enabled, we depend on DMA-remapping init code
    to call dmar_dev_scope_init(). This resulted in not doing this
    init when DMA-remapping was turned off but interrupt-remapping
    turned on in the kernel config.

    This caused interrupt routing to break with CONFIG_INTR_REMAP=y
    and CONFIG_DMAR=n.

    This issue was introduced by this commit:

    | commit 9d5ce73a64be2be8112147a3e0b551ad9cd1247b
    | Author: FUJITA Tomonori
    | Date: Tue Nov 10 19:46:16 2009 +0900
    |
    | x86: intel-iommu: Convert detect_intel_iommu to use iommu_init hook

    Fix this by calling dmar_dev_scope_init() explicitly from the
    interrupt remapping code too.

    Reported-by: Andrew Vasquez
    Signed-off-by: Suresh Siddha
    Cc: yinghai@kernel.org
    Cc: youquan.song@intel.com
    Cc: joerg.roedel@amd.com
    Cc: tony.luck@intel.com
    Cc: dwmw2@infradead.org
    Link: http://lkml.kernel.org/r/20110824001456.229207526@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • On the platforms which are x2apic and interrupt-remapping
    capable, Linux kernel is enabling x2apic even if the BIOS
    doesn't. This is to take advantage of the features that x2apic
    brings in.

    Some of the OEM platforms are running into issues because of
    this, as their bios is not x2apic aware. For example, this was
    resulting in interrupt migration issues on one of the platforms.
    Also if the BIOS SMI handling uses APIC interface to send SMI's,
    then the BIOS need to be aware of x2apic mode that OS has
    enabled.

    On some of these platforms, BIOS doesn't have a HW mechanism to
    turnoff the x2apic feature to prevent OS from enabling it.

    To resolve this mess, recent changes to the VT-d2 specification:

    http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

    includes a mechanism that provides BIOS a way to request system
    software to opt out of enabling x2apic mode.

    Look at the x2apic optout flag in the DMAR tables before
    enabling the x2apic mode in the platform. Also print a warning
    that we have disabled x2apic based on the BIOS request.

    Kernel boot parameter "intremap=no_x2apic_optout" can be used to
    override the BIOS x2apic optout request.

    Signed-off-by: Youquan Song
    Signed-off-by: Suresh Siddha
    Cc: yinghai@kernel.org
    Cc: joerg.roedel@amd.com
    Cc: tony.luck@intel.com
    Cc: dwmw2@infradead.org
    Link: http://lkml.kernel.org/r/20110824001456.171766616@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

14 Sep, 2011

1 commit

  • Mark this lowlevel IRQ handler as non-threaded. This prevents a boot
    crash when "threadirqs" is on the kernel commandline. Also the
    interrupt handler is handling hardware critical events which should
    not be delayed into a thread.

    Signed-off-by: Thomas Gleixner
    Cc: stable@kernel.org
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     

13 Sep, 2011

2 commits

  • The qi->q_lock lock can be taken in atomic context and therefore
    cannot be preempted on -rt - annotate it.

    In mainline this change documents the low level nature of
    the lock - otherwise there's no functional difference. Lockdep
    and Sparse checking will work as usual.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     
  • The iommu->register_lock can be taken in atomic context and therefore
    must not be preempted on -rt - annotate it.

    In mainline this change documents the low level nature of
    the lock - otherwise there's no functional difference. Lockdep
    and Sparse checking will work as usual.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     

21 Jun, 2011

1 commit

  • This should ease finding similarities with different platforms,
    with the intention of solving problems once in a generic framework
    which everyone can use.

    Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
    has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled
    in this patch, too.

    As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it.

    Compile-tested on x86_64.

    Signed-off-by: Ohad Ben-Cohen
    Signed-off-by: Joerg Roedel

    Ohad Ben-Cohen