- 13 9月, 2011 3 次提交
-
-
由 Thomas Gleixner 提交于
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: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thomas Gleixner 提交于
The irq_2_ir_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: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 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: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 02 9月, 2011 2 次提交
-
-
由 Joerg Roedel 提交于
The domain_flush_devices() function takes the domain->lock. But this function is only called from update_domain() which itself is already called unter the domain->lock. This causes a deadlock situation when the dma-address-space of a domain grows larger than 1GB. Cc: stable@kernel.org Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg Roedel 提交于
The value is only set to true but never set back to false, which causes to many completion-wait commands to be sent to hardware. Fix it with this patch. Cc: stable@kernel.org Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
- 06 7月, 2011 1 次提交
-
-
由 Joerg Roedel 提交于
Reserve the MSI address range in the address allocator so that MSI addresses are not handed out as dma handles. Cc: stable@kernel.org Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
- 21 6月, 2011 5 次提交
-
-
由 Joerg Roedel 提交于
A few parts of the driver were missing in drivers/iommu. Move them there to have the complete driver in that directory. Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg Roedel 提交于
For better navigation this patch moves the drivers/iommu drivers into its own submenu in Kconfig. Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Ohad Ben-Cohen 提交于
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: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Ohad Ben-Cohen 提交于
This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested on x86_64. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Ohad Ben-Cohen 提交于
This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NDavid Brown <davidb@codeaurora.org> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
- 14 6月, 2011 1 次提交
-
-
由 Ohad Ben-Cohen 提交于
Create a dedicated folder for iommu drivers, and move the base iommu implementation over there. Grouping the various iommu drivers in a single location will help finding similar problems shared by different platforms, so they could be solved once, in the iommu framework, instead of solved differently (or duplicated) in each driver. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-