Re: [PATCH 04/13] pci: New pci_dma_quirk()
Alex, On Sat, May 12, 2012 at 6:55 AM, Alex Williamson alex.william...@redhat.com wrote: Integrating IOMMU groups more closely into the driver core allows us to more easily work around DMA quirks. The Ricoh multifunction controller is a favorite example of devices that are currently incompatible with IOMMU isolation as all the functions use the requestor ID of function 0 for DMA. Passing this device into pci_dma_quirk returns the PCI device to use for DMA. The IOMMU driver can then construct an IOMMU group including both devices. Please give some thought to the Marvell SATA controller quirk as well. Instead of multiple visible functions using the same requester ID of function 0, the Marvell device only makes function 0 visible, but uses the requestor ID of function 1 as well during DMA. See https://bugzilla.redhat.com/show_bug.cgi?id=757166 -- A. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv10 00/11] ARM: DMA-mapping framework redesign
Hello, This is another update on dma-mapping redesign patches for ARM. I integrated a few minor fixes that were needed to solve the issues reported after putting these patches for testing in linux-next branch. The patches are also available on my git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git 3.4-rc7-arm-dma-v10 History of the development: v1: (initial version of the DMA-mapping redesign patches): http://www.spinics.net/lists/linux-mm/msg21241.html v2: http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000571.html http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000577.html v3: http://www.spinics.net/lists/linux-mm/msg25490.html v4 and v5: http://www.spinics.net/lists/arm-kernel/msg151147.html http://www.spinics.net/lists/arm-kernel/msg154889.html v6: http://www.spinics.net/lists/linux-mm/msg29903.html v7: http://www.spinics.net/lists/arm-kernel/msg162149.html v8: http://www.spinics.net/lists/arm-kernel/msg168478.html v9: http://www.spinics.net/lists/linux-arch/msg17443.html Best regards Marek Szyprowski Samsung Poland RD Center Patch summary: Marek Szyprowski (11): common: add dma_mmap_from_coherent() function ARM: dma-mapping: use dma_mmap_from_coherent() ARM: dma-mapping: use pr_* instread of printk ARM: dma-mapping: introduce DMA_ERROR_CODE constant ARM: dma-mapping: remove offset parameter to prepare for generic dma_ops ARM: dma-mapping: use asm-generic/dma-mapping-common.h ARM: dma-mapping: implement dma sg methods on top of any generic dma ops ARM: dma-mapping: move all dma bounce code to separate dma ops structure ARM: dma-mapping: remove redundant code and do the cleanup ARM: dma-mapping: use alloc, mmap, free from dma_ops ARM: dma-mapping: add support for IOMMU mapper arch/arm/Kconfig |9 + arch/arm/common/dmabounce.c| 84 ++- arch/arm/include/asm/device.h |4 + arch/arm/include/asm/dma-iommu.h | 34 ++ arch/arm/include/asm/dma-mapping.h | 407 --- arch/arm/mm/dma-mapping.c | 1015 ++-- arch/arm/mm/vmregion.h |2 +- drivers/base/dma-coherent.c| 42 ++ include/asm-generic/dma-coherent.h |4 +- 9 files changed, 1134 insertions(+), 467 deletions(-) create mode 100644 arch/arm/include/asm/dma-iommu.h -- 1.7.10.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv10 02/11] ARM: dma-mapping: use dma_mmap_from_coherent()
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- arch/arm/mm/dma-mapping.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index db23ae4..7ec0863 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -401,6 +401,9 @@ static int dma_mmap(struct device *dev, struct vm_area_struct *vma, unsigned long user_size, kern_size; struct arm_vmregion *c; + if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, ret)) + return ret; + user_size = (vma-vm_end - vma-vm_start) PAGE_SHIFT; c = arm_vmregion_find(consistent_head, (unsigned long)cpu_addr); -- 1.7.10.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv10 04/11] ARM: dma-mapping: introduce DMA_ERROR_CODE constant
Replace all uses of ~0 with DMA_ERROR_CODE, what should make the code
easier to read.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-By: Subash Patel subash.ramasw...@linaro.org
---
arch/arm/common/dmabounce.c|6 +++---
arch/arm/include/asm/dma-mapping.h |4 +++-
arch/arm/mm/dma-mapping.c |2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 595ecd29..210ad1b 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -254,7 +254,7 @@ static inline dma_addr_t map_single(struct device *dev,
void *ptr, size_t size,
if (buf == NULL) {
dev_err(dev, %s: unable to map unsafe buffer %p!\n,
__func__, ptr);
- return ~0;
+ return DMA_ERROR_CODE;
}
dev_dbg(dev, %s: unsafe buffer %p (dma=%#x) mapped to %p (dma=%#x)\n,
@@ -320,7 +320,7 @@ dma_addr_t __dma_map_page(struct device *dev, struct page
*page,
ret = needs_bounce(dev, dma_addr, size);
if (ret 0)
- return ~0;
+ return DMA_ERROR_CODE;
if (ret == 0) {
__dma_page_cpu_to_dev(page, offset, size, dir);
@@ -329,7 +329,7 @@ dma_addr_t __dma_map_page(struct device *dev, struct page
*page,
if (PageHighMem(page)) {
dev_err(dev, DMA buffer bouncing of HIGHMEM pages is not
supported\n);
- return ~0;
+ return DMA_ERROR_CODE;
}
return map_single(dev, page_address(page) + offset, size, dir);
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index cb3b7c9..6a838da 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -10,6 +10,8 @@
#include asm-generic/dma-coherent.h
#include asm/memory.h
+#define DMA_ERROR_CODE (~0)
+
#ifdef __arch_page_to_dma
#error Please update to __arch_pfn_to_dma
#endif
@@ -123,7 +125,7 @@ extern int dma_set_mask(struct device *, u64);
*/
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
- return dma_addr == ~0;
+ return dma_addr == DMA_ERROR_CODE;
}
/*
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 322c70a..e4ac5fc 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -342,7 +342,7 @@ __dma_alloc(struct device *dev, size_t size, dma_addr_t
*handle, gfp_t gfp,
*/
gfp = ~(__GFP_COMP);
- *handle = ~0;
+ *handle = DMA_ERROR_CODE;
size = PAGE_ALIGN(size);
page = __dma_alloc_buffer(dev, size, gfp);
--
1.7.10.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 04/13] pci: New pci_dma_quirk()
On Thu, 2012-05-17 at 15:19 +0800, Anonymous wrote: Alex, On Sat, May 12, 2012 at 6:55 AM, Alex Williamson alex.william...@redhat.com wrote: Integrating IOMMU groups more closely into the driver core allows us to more easily work around DMA quirks. The Ricoh multifunction controller is a favorite example of devices that are currently incompatible with IOMMU isolation as all the functions use the requestor ID of function 0 for DMA. Passing this device into pci_dma_quirk returns the PCI device to use for DMA. The IOMMU driver can then construct an IOMMU group including both devices. Please give some thought to the Marvell SATA controller quirk as well. Instead of multiple visible functions using the same requester ID of function 0, the Marvell device only makes function 0 visible, but uses the requestor ID of function 1 as well during DMA. See https://bugzilla.redhat.com/show_bug.cgi?id=757166 Wow. That one isn't quite as easy to deal with since there's no existing device in the kernel to point to. This comment might be on the right track: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c11 Perhaps David Woodhouse can comment on support for phantom functions. If we had infrastructure for that it might be easy for the quirk to update the pci_dev struct, inserting a new phantom function. Otherwise we'd need to create a new device in the kernel for it. Thanks, Alex ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
