Re: [PATCHv4 5/7] iommu/tegra: smmu: Support mmu-masters binding
On Nov 11, 2013, at 2:31 AM, Hiroshi Doyu hd...@nvidia.com wrote:
Follow arm,smmu's mmu-masters binding.
Signed-off-by: Hiroshi Doyu hd...@nvidia.com
---
Update:
Newly added for v4. In v3, I used nvidia,swgroups and
nvidia,memory-clients bindings.
---
.../bindings/iommu/nvidia,tegra30-smmu.txt | 28 -
drivers/iommu/tegra-smmu.c | 138 +
2 files changed, 141 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
index 89fb543..51884e9 100644
--- a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
@@ -8,9 +8,16 @@ Required properties:
- nvidia,#asids : # of ASIDs
- dma-window : IOVA start address and length.
- nvidia,ahb : phandle to the ahb bus connected to SMMU.
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation
+ and their corresponding StreamIDs (see example below).
+ Each device node linked from this list must have a
+ #stream-id-cells property, indicating the number of
+ StreamIDs(swgroup ID) associated with it, which is defined
+ in include/dt-bindings/memory/tegra-swgroup.h.
Example:
- smmu {
+ iommu {
compatible = nvidia,tegra30-smmu;
reg = 0x7000f010 0x02c
0x7000f1f0 0x010
@@ -18,4 +25,23 @@ Example:
nvidia,#asids = 4;/* # of ASIDs */
dma-window = 0 0x4000;/* IOVA start length */
nvidia,ahb = ahb;
+
+ mmu-masters = host1x TEGRA_SWGROUP_HC,
+ mpe TEGRA_SWGROUP_MPE,
+ vi TEGRA_SWGROUP_VI,
+ epp TEGRA_SWGROUP_EPP,
+ isp TEGRA_SWGROUP_ISP,
+ gr2d TEGRA_SWGROUP_G2,
+ gr3d TEGRA_SWGROUP_NV TEGRA_SWGROUP_NV2,
+ dc TEGRA_SWGROUP_DC,
+ dcb TEGRA_SWGROUP_DCB,
+ uarta TEGRA_SWGROUP_PPCS,
+ uartb TEGRA_SWGROUP_PPCS,
+ uartc TEGRA_SWGROUP_PPCS,
+ uartd TEGRA_SWGROUP_PPCS,
+ uarte TEGRA_SWGROUP_PPCS,
+ sdhci0 TEGRA_SWGROUP_PPCS,
+ sdhci1 TEGRA_SWGROUP_PPCS,
+ sdhci2 TEGRA_SWGROUP_PPCS,
+ sdhci3 TEGRA_SWGROUP_PPCS;
};
At first glance this seems backward from all other cases we have in which we
usually have the device have a property that points back, like interrupt-parent.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
On Mar 28, 2013, at 2:53 PM, Varun Sethi wrote: Add an iommu domain pointer to device (powerpc) archdata. Devices are attached to iommu domains and this pointer provides a mechanism to correlate between a device and the associated iommu domain. This field is set when a device is attached to a domain. Signed-off-by: Varun Sethi varun.se...@freescale.com --- - no change in v11. - no change in v10. - Added CONFIG_IOMMU_API in v9. arch/powerpc/include/asm/device.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 17, 2013, at 10:48 AM, Sethi Varun-B16395 wrote: + guts_node = of_find_compatible_node(NULL, NULL, + fsl,qoriq-device-config-1.0); This doesn't work for T4 or B4 device trees. [Sethi Varun-B16395]hmm I need to use the dcfg space for this. Let's see with the SoC arch's if something like fsl,qoriq-device-config-2.0 makes sense for T4 B4. - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
+/*
+ * Table of SVRs and the corresponding PORT_ID values.
+ *
+ * All future CoreNet-enabled SOCs will have this erratum fixed, so this
table
+ * should never need to be updated. SVRs are guaranteed to be unique, so
+ * there is no worry that a future SOC will inadvertently have one of these
+ * values.
+ */
Maybe add to the comment about what port_id represents
+static const struct {
+ u32 svr;
+ u32 port_id;
+} port_id_map[] = {
+ {0x82100010, 0xFF00}, /* P2040 1.0 */
+ {0x82100011, 0xFF00}, /* P2040 1.1 */
+ {0x82100110, 0xFF00}, /* P2041 1.0 */
+ {0x82100111, 0xFF00}, /* P2041 1.1 */
+ {0x82110310, 0xFF00}, /* P3041 1.0 */
+ {0x82110311, 0xFF00}, /* P3041 1.1 */
+ {0x82010020, 0xFFF8}, /* P4040 2.0 */
+ {0x8220, 0xFFF8}, /* P4080 2.0 */
+ {0x82210010, 0xFC00}, /* P5010 1.0 */
+ {0x82210020, 0xFC00}, /* P5010 2.0 */
+ {0x82200010, 0xFC00}, /* P5020 1.0 */
+ {0x82050010, 0xFF80}, /* P5021 1.0 */
+ {0x82040010, 0xFF80}, /* P5040 1.0 */
+};
+
+#define SVR_SECURITY 0x8 /* The Security (E) bit */
+
+static int __init fsl_pamu_probe(struct platform_device *pdev)
+{
+ void __iomem *pamu_regs = NULL;
+ struct ccsr_guts __iomem *guts_regs = NULL;
+ u32 pamubypenr, pamu_counter;
+ unsigned long pamu_reg_off;
+ unsigned long pamu_reg_base;
+ struct pamu_isr_data *data;
+ struct device_node *guts_node;
+ u64 size;
+ struct page *p;
+ int ret = 0;
+ int irq;
+ phys_addr_t ppaact_phys;
+ phys_addr_t spaact_phys;
+ phys_addr_t omt_phys;
+ size_t mem_size = 0;
+ unsigned int order = 0;
+ u32 csd_port_id = 0;
+ unsigned i;
+ /*
+ * enumerate all PAMUs and allocate and setup PAMU tables
+ * for each of them,
+ * NOTE : All PAMUs share the same LIODN tables.
+ */
+
+ pamu_regs = of_iomap(pdev-dev.of_node, 0);
+ if (!pamu_regs) {
+ dev_err(pdev-dev, ioremap of PAMU node failed\n);
+ return -ENOMEM;
+ }
+ of_get_address(pdev-dev.of_node, 0, size, NULL);
+
+ irq = irq_of_parse_and_map(pdev-dev.of_node, 0);
+ if (irq == NO_IRQ) {
+ dev_warn(pdev-dev, no interrupts listed in PAMU node\n);
+ goto error;
+ }
+
+ data = kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
+ if (!data) {
+ iounmap(pamu_regs);
+ return -ENOMEM;
+ }
+ data-pamu_reg_base = pamu_regs;
+ data-count = size / PAMU_OFFSET;
+
+ /* The ISR needs access to the regs, so we won't iounmap them */
+ ret = request_irq(irq, pamu_av_isr, 0, pamu, data);
+ if (ret 0) {
+ dev_err(pdev-dev, error %i installing ISR for irq %i\n,
+ ret, irq);
+ goto error;
+ }
+
+ guts_node = of_find_compatible_node(NULL, NULL,
+ fsl,qoriq-device-config-1.0);
This doesn't work for T4 or B4 device trees.
+ if (!guts_node) {
+ dev_err(pdev-dev, could not find GUTS node %s\n,
+ pdev-dev.of_node-full_name);
+ ret = -ENODEV;
+ goto error;
+ }
+
+ guts_regs = of_iomap(guts_node, 0);
+ of_node_put(guts_node);
+ if (!guts_regs) {
+ dev_err(pdev-dev, ioremap of GUTS node failed\n);
+ ret = -ENODEV;
+ goto error;
+ }
+
+ /* read in the PAMU capability registers */
+ get_pamu_cap_values((unsigned long)pamu_regs);
+ /*
+ * To simplify the allocation of a coherency domain, we allocate the
+ * PAACT and the OMT in the same memory buffer. Unfortunately, this
+ * wastes more memory compared to allocating the buffers separately.
+ */
+ /* Determine how much memory we need */
+ mem_size = (PAGE_SIZE get_order(PAACT_SIZE)) +
+ (PAGE_SIZE get_order(SPAACT_SIZE)) +
+ (PAGE_SIZE get_order(OMT_SIZE));
+ order = get_order(mem_size);
+
+ p = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
+ if (!p) {
+ dev_err(pdev-dev, unable to allocate PAACT/SPAACT/OMT
block\n);
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ ppaact = page_address(p);
+ ppaact_phys = page_to_phys(p);
+
+ /* Make sure the memory is naturally aligned */
+ if (ppaact_phys ((PAGE_SIZE order) - 1)) {
+ dev_err(pdev-dev, PAACT/OMT block is unaligned\n);
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ spaact = (void *)ppaact + (PAGE_SIZE get_order(PAACT_SIZE));
+ omt = (void *)spaact + (PAGE_SIZE get_order(SPAACT_SIZE));
+
+ dev_dbg(pdev-dev, ppaact virt=%p phys=0x%llx\n, ppaact,
+
Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
On Mar 14, 2013, at 3:20 PM, Kumar Gala wrote:
On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
+/*
+ * Table of SVRs and the corresponding PORT_ID values.
+ *
+ * All future CoreNet-enabled SOCs will have this erratum fixed, so this
table
+ * should never need to be updated. SVRs are guaranteed to be unique, so
+ * there is no worry that a future SOC will inadvertently have one of these
+ * values.
+ */
Maybe add to the comment about what port_id represents
also, add reference to the erratum #/id/name
+static const struct {
+u32 svr;
+u32 port_id;
+} port_id_map[] = {
+{0x82100010, 0xFF00}, /* P2040 1.0 */
+{0x82100011, 0xFF00}, /* P2040 1.1 */
+{0x82100110, 0xFF00}, /* P2041 1.0 */
+{0x82100111, 0xFF00}, /* P2041 1.1 */
+{0x82110310, 0xFF00}, /* P3041 1.0 */
+{0x82110311, 0xFF00}, /* P3041 1.1 */
+{0x82010020, 0xFFF8}, /* P4040 2.0 */
+{0x8220, 0xFFF8}, /* P4080 2.0 */
+{0x82210010, 0xFC00}, /* P5010 1.0 */
+{0x82210020, 0xFC00}, /* P5010 2.0 */
+{0x82200010, 0xFC00}, /* P5020 1.0 */
+{0x82050010, 0xFF80}, /* P5021 1.0 */
+{0x82040010, 0xFF80}, /* P5040 1.0 */
+};
+
+#define SVR_SECURITY0x8 /* The Security (E) bit */
+
+static int __init fsl_pamu_probe(struct platform_device *pdev)
+{
+void __iomem *pamu_regs = NULL;
+struct ccsr_guts __iomem *guts_regs = NULL;
+u32 pamubypenr, pamu_counter;
+unsigned long pamu_reg_off;
+unsigned long pamu_reg_base;
+struct pamu_isr_data *data;
+struct device_node *guts_node;
+u64 size;
+struct page *p;
+int ret = 0;
+int irq;
+phys_addr_t ppaact_phys;
+phys_addr_t spaact_phys;
+phys_addr_t omt_phys;
+size_t mem_size = 0;
+unsigned int order = 0;
+u32 csd_port_id = 0;
+unsigned i;
+/*
+ * enumerate all PAMUs and allocate and setup PAMU tables
+ * for each of them,
+ * NOTE : All PAMUs share the same LIODN tables.
+ */
+
+pamu_regs = of_iomap(pdev-dev.of_node, 0);
+if (!pamu_regs) {
+dev_err(pdev-dev, ioremap of PAMU node failed\n);
+return -ENOMEM;
+}
+of_get_address(pdev-dev.of_node, 0, size, NULL);
+
+irq = irq_of_parse_and_map(pdev-dev.of_node, 0);
+if (irq == NO_IRQ) {
+dev_warn(pdev-dev, no interrupts listed in PAMU node\n);
+goto error;
+}
+
+data = kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
+if (!data) {
+iounmap(pamu_regs);
+return -ENOMEM;
+}
+data-pamu_reg_base = pamu_regs;
+data-count = size / PAMU_OFFSET;
+
+/* The ISR needs access to the regs, so we won't iounmap them */
+ret = request_irq(irq, pamu_av_isr, 0, pamu, data);
+if (ret 0) {
+dev_err(pdev-dev, error %i installing ISR for irq %i\n,
+ret, irq);
+goto error;
+}
+
+guts_node = of_find_compatible_node(NULL, NULL,
+fsl,qoriq-device-config-1.0);
This doesn't work for T4 or B4 device trees.
+if (!guts_node) {
+dev_err(pdev-dev, could not find GUTS node %s\n,
+pdev-dev.of_node-full_name);
+ret = -ENODEV;
+goto error;
+}
+
+guts_regs = of_iomap(guts_node, 0);
+of_node_put(guts_node);
+if (!guts_regs) {
+dev_err(pdev-dev, ioremap of GUTS node failed\n);
+ret = -ENODEV;
+goto error;
+}
+
+/* read in the PAMU capability registers */
+get_pamu_cap_values((unsigned long)pamu_regs);
+/*
+ * To simplify the allocation of a coherency domain, we allocate the
+ * PAACT and the OMT in the same memory buffer. Unfortunately, this
+ * wastes more memory compared to allocating the buffers separately.
+ */
+/* Determine how much memory we need */
+mem_size = (PAGE_SIZE get_order(PAACT_SIZE)) +
+(PAGE_SIZE get_order(SPAACT_SIZE)) +
+(PAGE_SIZE get_order(OMT_SIZE));
+order = get_order(mem_size);
+
+p = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
+if (!p) {
+dev_err(pdev-dev, unable to allocate PAACT/SPAACT/OMT
block\n);
+ret = -ENOMEM;
+goto error;
+}
+
+ppaact = page_address(p);
+ppaact_phys = page_to_phys(p);
+
+/* Make sure the memory is naturally aligned */
+if (ppaact_phys ((PAGE_SIZE order) - 1)) {
+dev_err(pdev-dev, PAACT/OMT block is unaligned\n);
+ret = -ENOMEM;
+goto error;
+}
+
+spaact = (void *)ppaact + (PAGE_SIZE get_order(PAACT_SIZE));
+omt = (void *)spaact + (PAGE_SIZE get_order(SPAACT_SIZE));
+
+dev_dbg(pdev-dev, ppaact virt=%p phys=0x%llx\n, ppaact
Re: [PATCH 3/6] powerpc/fsl_pci: Added defines for the FSL PCI controller BRR1 register.
On Feb 27, 2013, at 5:33 AM, Joerg Roedel wrote: On Mon, Feb 18, 2013 at 06:22:16PM +0530, Varun Sethi wrote: Macros for checking FSL PCI controller version. Signed-off-by: Varun Sethi varun.se...@freescale.com --- arch/powerpc/include/asm/pci-bridge.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h index 025a130..c12ed78 100644 --- a/arch/powerpc/include/asm/pci-bridge.h +++ b/arch/powerpc/include/asm/pci-bridge.h @@ -14,6 +14,10 @@ struct device_node; +/* FSL PCI controller BRR1 register */ +#define PCI_FSL_BRR1 0xbf8 +#define PCI_FSL_BRR1_VER 0x + Please merge this patch with the one where you actually make use of these defines for the first time. Joerg This also seems an odd place for these defines. - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote: This patch is present in the next branch of linux ppc tree maintained by Kumar Gala. Following is the commit id: 52c5affc545053d37c0b05224bbf70f5336caa20 I am not sure if this would be part of 3.9-rc1. Regards varun This is now in Linus's tree so will be in 3.9-rc1 - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer in archdata.
On Nov 25, 2012, at 11:33 PM, Sethi Varun-B16395 wrote:
Hi Kumar,
Can you please apply this patch.
Regards
Varun
Was waiting on the others to apply this all together. (ie getting an Ack from
Joerg, and follow comments from Timur to be resolved)
- k
-Original Message-
From: Sethi Varun-B16395
Sent: Tuesday, November 20, 2012 7:25 PM
To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421;
Tabi Timur-B04825
Cc: Sethi Varun-B16395
Subject: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer
in archdata.
Add a new field in the device (powerpc) archdata structure for storing
iommu domain information pointer. This pointer is stored when the device
is attached to a particular domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+/* IOMMU domain information pointer. This would be set
+ * when this device is attached to an iommu_domain.
+ */
+void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/4] iommu/fsl: Add PAMU bypass enable register to ccsr_guts structure.
On Nov 20, 2012, at 7:54 AM, Varun Sethi wrote: PAMU bypass enable register added to the ccsr_guts structure. Signed-off-by: Timur Tabi ti...@freescale.com Signed-off-by: Varun Sethi varun.se...@freescale.com --- arch/powerpc/include/asm/fsl_guts.h |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) applied to next - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
On Sep 19, 2012, at 8:17 AM, b16...@freescale.com b16...@freescale.com
wrote:
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e83370..eaa40c6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,28 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped*/
dma_addr_t aperture_end; /* Last address that can be mapped */
bool force_aperture; /* DMA only allowed in mappable range? */
+
+ /* The subwindows field indicates number of DMA subwindows supported
+ * by the geometry. Following is the interpretation of
+ * values for this field:
+ * 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of subwindows
+ * being = 1MB/4KB = 256.
+ * 1 : Only one DMA window i.e. no subwindows.
+ * value other than 0 or 1 would indicate actual number of subwindows.
+ */
+ u32 subwindows;
+};
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
seems like this should be enum instead of u32 for cache
With enum being something like:
enum iommu_attr_stash_cache {
IOMMU_ATTR_CACHE_L1,
IOMMU_ATTR_CACHE_L2,
IOMMU_ATTR_CACHE_L3,
};
};
struct iommu_domain {
@@ -60,6 +82,14 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+ * parameters.
+ */
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
