[PATCH 1/2] iommu/amd: Check for the right TLP prefix bit
Unfortunatly the PRI spec changed and moved the
TLP-prefix-required bit to a different location. This patch
makes the necessary change in the AMD IOMMU driver.
Regressions are not expected because all hardware
implementing the PRI capability sets this bit to zero
anyway.
Cc: sta...@vger.kernel.org # v3.3
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/amd_iommu.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a5bee8e..08f3eec 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2035,20 +2035,20 @@ out_err:
}
/* FIXME: Move this to PCI code */
-#define PCI_PRI_TLP_OFF(1 2)
+#define PCI_PRI_TLP_OFF(1 15)
bool pci_pri_tlp_required(struct pci_dev *pdev)
{
- u16 control;
+ u16 status;
int pos;
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI);
if (!pos)
return false;
- pci_read_config_word(pdev, pos + PCI_PRI_CTRL, control);
+ pci_read_config_word(pdev, pos + PCI_PRI_STATUS, status);
- return (control PCI_PRI_TLP_OFF) ? true : false;
+ return (status PCI_PRI_TLP_OFF) ? true : false;
}
/*
--
1.7.5.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Before posting the next round of patches I wanted to clarify whether we need to take the Tegra driver through staging. Lucas brought this up referring to previous experience with Nouveau where Linus used to complain that userspace ABI was broken for non-staging drivers. I don't know how relevant that is for Tegra. We could also keep it in drivers/gpu/drm and only add userspace interfaces that we are sure are not going to change. Currently there isn't isn't anything that could be easily broken as only some of the standard DRM interfaces are supported anyway. Alternatively we could keep the driver in a separate tree until it becomes mature enough. Any thoughts? It's probably okay to avoid staging if it doesn't add any userspace ioctls. A KMS driver that just supports the dumb ioctls so -modesetting works, would be the first thing to aim for I suppose, like how the exynos guys did it. Adding userspace interfaces is where you'll get into ABI guarantees etc, and these are normally required only for the accel engines. Dave. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/4] Add NVIDIA Tegra DRM support
* Dave Airlie wrote: On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Before posting the next round of patches I wanted to clarify whether we need to take the Tegra driver through staging. Lucas brought this up referring to previous experience with Nouveau where Linus used to complain that userspace ABI was broken for non-staging drivers. I don't know how relevant that is for Tegra. We could also keep it in drivers/gpu/drm and only add userspace interfaces that we are sure are not going to change. Currently there isn't isn't anything that could be easily broken as only some of the standard DRM interfaces are supported anyway. Alternatively we could keep the driver in a separate tree until it becomes mature enough. Any thoughts? It's probably okay to avoid staging if it doesn't add any userspace ioctls. A KMS driver that just supports the dumb ioctls so -modesetting works, would be the first thing to aim for I suppose, like how the exynos guys did it. Adding userspace interfaces is where you'll get into ABI guarantees etc, and these are normally required only for the accel engines. I think this is what Lucas was concerned about. The plan is to look at how much can be used from the Nouveau code and make it work on the Tegra. So would it be possible to get a basic dumb KMS driver into mainline (non-staging) and phase in acceleration later on, with ABI guarantees? I guess development can go on in separate trees until the ABI is stable and can subsequently be ported to the mainline driver. Is that an acceptable approach? Thierry pgptDMAdOxRkD.pgp Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Linaro-mm-sig] [PATCHv9 10/10] ARM: dma-mapping: add support for IOMMU mapper
On 4/20/12, Abhinav Kochhar kochhar.abhi...@gmail.com wrote:
Hi Marek,
dma_addr_t dma_addr is an unused argument passed to the function
arm_iommu_mmap_attrs
Even though it's not used at here. it's mmap function field at dma_map_ops.
To match the type, it's required.
struct dma_map_ops iommu_ops = {
.alloc = arm_iommu_alloc_attrs,
.free = arm_iommu_free_attrs,
.mmap = arm_iommu_mmap_attrs,
Thank you,
Kyungmin Park
+static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct
*vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ struct dma_attrs *attrs)
+{
+ struct arm_vmregion *c;
+
+ vma-vm_page_prot = __get_dma_pgprot(attrs, vma-vm_page_prot);
+ c = arm_vmregion_find(consistent_
head, (unsigned long)cpu_addr);
+
+ if (c) {
+ struct page **pages = c-priv;
+
+ unsigned long uaddr = vma-vm_start;
+ unsigned long usize = vma-vm_end - vma-vm_start;
+ int i = 0;
+
+ do {
+ int ret;
+
+ ret = vm_insert_page(vma, uaddr, pages[i++]);
+ if (ret) {
+ pr_err(Remapping memory, error: %d\n,
ret);
+ return ret;
+ }
+
+ uaddr += PAGE_SIZE;
+ usize -= PAGE_SIZE;
+ } while (usize 0);
+ }
+ return 0;
+}
On Wed, Apr 18, 2012 at 10:44 PM, Marek Szyprowski m.szyprow...@samsung.com
wrote:
This patch add a complete implementation of DMA-mapping API for
devices which have IOMMU support.
This implementation tries to optimize dma address space usage by remapping
all possible physical memory chunks into a single dma address space chunk.
DMA address space is managed on top of the bitmap stored in the
dma_iommu_mapping structure stored in device-archdata. Platform setup
code has to initialize parameters of the dma address space (base address,
size, allocation precision order) with arm_iommu_create_mapping()
function.
To reduce the size of the bitmap, all allocations are aligned to the
specified order of base 4 KiB pages.
dma_alloc_* functions allocate physical memory in chunks, each with
alloc_pages() function to avoid failing if the physical memory gets
fragmented. In worst case the allocated buffer is composed of 4 KiB page
chunks.
dma_map_sg() function minimizes the total number of dma address space
chunks by merging of physical memory chunks into one larger dma address
space chunk. If requested chunk (scatter list entry) boundaries
match physical page boundaries, most calls to dma_map_sg() requests will
result in creating only one chunk in dma address space.
dma_map_page() simply creates a mapping for the given page(s) in the dma
address space.
All dma functions also perform required cache operation like their
counterparts from the arm linear physical memory mapping version.
This patch contains code and fixes kindly provided by:
- Krishna Reddy vdu...@nvidia.com,
- Andrzej Pietrasiewicz andrze...@samsung.com,
- Hiroshi DOYU hd...@nvidia.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Tested-By: Subash Patel subash.ramasw...@linaro.org
---
arch/arm/Kconfig |8 +
arch/arm/include/asm/device.h|3 +
arch/arm/include/asm/dma-iommu.h | 34 ++
arch/arm/mm/dma-mapping.c| 727
+-
arch/arm/mm/vmregion.h |2 +-
5 files changed, 759 insertions(+), 15 deletions(-)
create mode 100644 arch/arm/include/asm/dma-iommu.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0fd27d4..874e519 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -46,6 +46,14 @@ config ARM
config ARM_HAS_SG_CHAIN
bool
+config NEED_SG_DMA_LENGTH
+ bool
+
+config ARM_DMA_USE_IOMMU
+ select NEED_SG_DMA_LENGTH
+ select ARM_HAS_SG_CHAIN
+ bool
+
config HAVE_PWM
bool
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 6e2cb0e..b69c0d3 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,6 +14,9 @@ struct dev_archdata {
#ifdef CONFIG_IOMMU_API
void *iommu; /* private IOMMU data */
#endif
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
+ struct dma_iommu_mapping*mapping;
+#endif
};
struct omap_device;
diff --git a/arch/arm/include/asm/dma-iommu.h
b/arch/arm/include/asm/dma-iommu.h
new file mode 100644
index 000..799b094
--- /dev/null
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -0,0 +1,34 @@
+#ifndef ASMARM_DMA_IOMMU_H
+#define ASMARM_DMA_IOMMU_H
+
+#ifdef __KERNEL__
+
+#include linux/mm_types.h
Re: Reparenting a platform device
On Sat, 7 Apr 2012 13:35:10 +0200, Thierry Reding thierry.red...@avionic-design.de wrote: * Grant Likely wrote: On Thu, 5 Apr 2012 10:42:58 +0200, Thierry Reding thierry.red...@avionic-design.de wrote: Hi, I have a device tree where I have a GART device and a DRM device which uses the GART. The GART is implemented by an IOMMU driver (tegra-gart) and requires the user device to be a child of the GART device (it explicitly checks for this when the user device is attached). I've tried two alternatives to achieve this: create the GART device in the user driver's .probe() function and explicitly set the DRM device's parent to the resulting platform device like so: gart = platform_device_alloc(...); ... pdev-dev.parent = gart-dev; Yeah, don't *ever* try to do this. The device hierarchy is a complex data structure which must never be directly manipulated. The alternative is to use the device tree to look up the GART device node and resolve it to the corresponding struct device: gart_node = of_parse_phandle(drm-dev-of_node, gart-parent, 0); gart = bus_find_device(drm-dev-bus, NULL, gart_node, match_of_node); Where match_of_node matches each struct device's .of_node field to the gart_node. Both of these variants seem to work, and the DRM device can be properly attached to the GART device. However, after the DRM driver's .probe() exits, I get the following error: I don't understand what you're trying to describe here as the 2nd option. Regardless, reparenting should not ben the solution at all. What does the device tree that you envision look like for this? What devices are created, and what drivers bind to them? The reason why I need to reparent at all is because the IOMMU driver requires the user to be a child of the IOMMU device. If you look at the driver in drivers/iommu/tegra-gart.c you'll see that it references dev-parent in several places, most notably in the gart_iommu_attach_dev() function. So there's really only two options that I can see: 1) create a virtual device that is a child of the GART and is in charge of the actual allocations from the GART and have the DRM driver use that interface or 2) change the GART driver's behaviour in a way that the parent/child relationship is no longer a requirement. Either is fine by me. 1) has the advantage of providing a central allocation manager for the GART and will allow to register multiple clients with the GART. 2) does not have that advantage. Another alternative may be to allow only a single device to attach to the GART that doesn't have to be a child of the GART. That way the DRM could take care of GART aperture allocations, which seems to be the most logical place to do that anyway. That also works. As long as nothing messes about with odd reparenting then I'm happy. g. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
