RE: [PATCH 0/7 v7] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Wednesday, September 12, 2018 10:29 PM
> To: Nipun Gupta 
> Cc: j...@8bytes.org; robin.mur...@arm.com; robh...@kernel.org;
> r...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> gre...@linuxfoundation.org; Laurentiu Tudor ;
> bhelg...@google.com; h...@lst.de; m.szyprow...@samsung.com;
> shawn...@kernel.org; frowand.l...@gmail.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li 
> Subject: Re: [PATCH 0/7 v7] Support for fsl-mc bus and its devices in SMMU
> 
> Hi Nipun,
> 
> On Mon, Sep 10, 2018 at 07:19:14PM +0530, Nipun Gupta wrote:
> > This patchset defines IOMMU DT binding for fsl-mc bus and adds
> > support in SMMU for fsl-mc bus.
> >
> > These patches
> >   - Define property 'iommu-map' for fsl-mc bus (patch 1)
> >   - Integrates the fsl-mc bus with the SMMU using this
> > IOMMU binding (patch 2,3,4)
> >   - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
> >   - Updates the fsl-mc device node with iommu/dma related changes (patch 7)
> 
> It looks like you have all the Acks in place for this series now, so I
> assume it's going to go via Joerg directly. Is that right?

This is what I am expecting :)
 
> Will
> 

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 7/7 v7] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.

Signed-off-by: Nipun Gupta 
Reviewed-by: Laurentiu Tudor 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..3d5e049 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,9 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   dma-coherent;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +508,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 6/7 v7] bus/fsl-mc: set coherent dma mask for devices on fsl-mc bus

[Nipun Gupta]

of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.

Signed-off-by: Nipun Gupta 
Reviewed-by: Robin Murphy 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index fa43c7d..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -627,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 1/7 v7] Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc bus

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta 
Reviewed-by: Rob Herring 
Acked-by: Robin Murphy 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..01fdc33 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+Documentation/networking/dpaa2/overview.rst
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/7 v7] iommu/of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.

Signed-off-by: Nipun Gupta 
Reviewed-by: Rob Herring 
Reviewed-by: Robin Murphy 
Acked-by: Bjorn Helgaas 
---
 drivers/iommu/of_iommu.c |   5 +--
 drivers/of/base.c| 102 +++
 drivers/of/irq.c |   5 +--
 drivers/pci/of.c | 101 --
 include/linux/of.h   |  11 +
 include/linux/of_pci.h   |  10 -
 6 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..811e160 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -149,9 +149,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
 
-   err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", _spec.np,
-iommu_spec.args);
+   err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 848f549..c7aac81 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1995,3 +1995,105 @@ int of_find_last_cache_level(unsigned int cpu)
 
return cache_level;
 }
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+

[PATCH 5/7 v7] bus/fsl-mc: support dma configure for devices on fsl-mc bus

[Nipun Gupta]

This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.

Signed-off-by: Nipun Gupta 
Reviewed-by: Laurentiu Tudor 
Reviewed-by: Robin Murphy 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..fa43c7d 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -633,10 +644,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/7 v7] iommu/arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta 
Reviewed-by: Robin Murphy 
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 13 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 30 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f7a96bc..a011bb6 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d227b86..df2f49e 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -988,6 +989,18 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   group = iommu_group_get(cont_dev);
+   if (!group)
+   group = iommu_group_alloc();
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7447b0b..209891d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/7 v7] iommu/of: support iommu configuration for fsl-mc devices

[Nipun Gupta]

With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus

Signed-off-by: Nipun Gupta 
Reviewed-by: Robin Murphy 
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -159,6 +160,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -190,6 +208,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/7 v7] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
  - Updates the fsl-mc device node with iommu/dma related changes (patch 7)

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

Changes in v3:
  - move of_map_rid in drivers/of/address.c

Changes in v4:
  - move of_map_rid in drivers/of/base.c

Changes in v5:
  - break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
  - add changelog text in patch 3/7 and patch 5/7
  - typo fix

Changes in v6:
  - Updated fsl_mc_device_group() API to be more rational
  - Added dma-coherent property in the LS2 smmu device node
  - Minor fixes in the device-tree documentation

Changes in v7:
  - Rebased over linux 4.19

Nipun Gupta (7):
  Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc
bus
  iommu/of: make of_pci_map_rid() available for other devices too
  iommu/of: support iommu configuration for fsl-mc devices
  iommu/arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: support dma configure for devices on fsl-mc bus
  bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   7 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  13 +++
 drivers/iommu/of_iommu.c   |  25 -
 drivers/of/base.c  | 102 +
 drivers/of/irq.c   |   5 +-
 drivers/pci/of.c   | 101 
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of.h |  11 +++
 include/linux/of_pci.h |  10 --
 13 files changed, 224 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 0/7 v6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

Hi Joerg/Robin,

Can you please let me know when these patches will be applied onto the tree.
Is there anything else pending from my side.

Thanks,
Nipun

> -Original Message-
> From: Nipun Gupta
> Sent: Monday, July 9, 2018 4:48 PM
> To: robin.mur...@arm.com; will.dea...@arm.com; robh...@kernel.org;
> r...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> gre...@linuxfoundation.org; Laurentiu Tudor ;
> bhelg...@google.com; h...@lst.de
> Cc: j...@8bytes.org; m.szyprow...@samsung.com; shawn...@kernel.org;
> frowand.l...@gmail.com; iommu@lists.linux-foundation.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li ; Nipun Gupta
> 
> Subject: [PATCH 0/7 v6] Support for fsl-mc bus and its devices in SMMU
> 
> This patchset defines IOMMU DT binding for fsl-mc bus and adds
> support in SMMU for fsl-mc bus.
> 
> The patch series is based on top of dma-mapping tree (for-next branch):
> http://git.infradead.org/users/hch/dma-mapping.git
> 
> These patches
>   - Define property 'iommu-map' for fsl-mc bus (patch 1)
>   - Integrates the fsl-mc bus with the SMMU using this
> IOMMU binding (patch 2,3,4)
>   - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
>   - Updates the fsl-mc device node with iommu/dma related changes (patch 7)
> 
> Changes in v2:
>   - use iommu-map property for fsl-mc bus
>   - rebase over patchset https://patchwork.kernel.org/patch/10317337/
> and make corresponding changes for dma configuration of devices on
> fsl-mc bus
> 
> Changes in v3:
>   - move of_map_rid in drivers/of/address.c
> 
> Changes in v4:
>   - move of_map_rid in drivers/of/base.c
> 
> Changes in v5:
>   - break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
>   - add changelog text in patch 3/7 and patch 5/7
>   - typo fix
> 
> Changes in v6:
>   - Updated fsl_mc_device_group() API to be more rational
>   - Added dma-coherent property in the LS2 smmu device node
>   - Minor fixes in the device-tree documentation
> 
> Nipun Gupta (7):
>   Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc
> bus
>   iommu/of: make of_pci_map_rid() available for other devices too
>   iommu/of: support iommu configuration for fsl-mc devices
>   iommu/arm-smmu: Add support for the fsl-mc bus
>   bus: fsl-mc: support dma configure for devices on fsl-mc bus
>   bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
>   arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc
> 
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
>  arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   7 +-
>  drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
>  drivers/iommu/arm-smmu.c   |   7 ++
>  drivers/iommu/iommu.c  |  13 +++
>  drivers/iommu/of_iommu.c   |  25 -
>  drivers/of/base.c  | 102 
> +
>  drivers/of/irq.c   |   5 +-
>  drivers/pci/of.c   | 101 
>  include/linux/fsl/mc.h |   8 ++
>  include/linux/iommu.h  |   2 +
>  include/linux/of.h |  11 +++
>  include/linux/of_pci.h |  10 --
>  13 files changed, 224 insertions(+), 122 deletions(-)
> 
> --
> 1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 7/7 v6] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.

Signed-off-by: Nipun Gupta 
Reviewed-by: Laurentiu Tudor 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..3d5e049 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,9 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   dma-coherent;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +508,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 6/7 v6] bus/fsl-mc: set coherent dma mask for devices on fsl-mc bus

[Nipun Gupta]

of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.

Signed-off-by: Nipun Gupta 
Reviewed-by: Robin Murphy 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index fa43c7d..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -627,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 5/7 v6] bus/fsl-mc: support dma configure for devices on fsl-mc bus

[Nipun Gupta]

This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.

Signed-off-by: Nipun Gupta 
Reviewed-by: Laurentiu Tudor 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..fa43c7d 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -633,10 +644,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/7 v6] iommu/arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 13 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 30 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f7a96bc..a011bb6 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d227b86..df2f49e 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -988,6 +989,18 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   group = iommu_group_get(cont_dev);
+   if (!group)
+   group = iommu_group_alloc();
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7447b0b..209891d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/7 v6] iommu/of: support iommu configuration for fsl-mc devices

[Nipun Gupta]

With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus

Signed-off-by: Nipun Gupta 
Reviewed-by: Robin Murphy 
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -159,6 +160,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -190,6 +208,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/7 v6] iommu/of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.

Signed-off-by: Nipun Gupta 
Reviewed-by: Rob Herring 
Reviewed-by: Robin Murphy 
Acked-by: Bjorn Helgaas 
---
 drivers/iommu/of_iommu.c |   5 +--
 drivers/of/base.c| 102 +++
 drivers/of/irq.c |   5 +--
 drivers/pci/of.c | 101 --
 include/linux/of.h   |  11 +
 include/linux/of_pci.h   |  10 -
 6 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..811e160 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -149,9 +149,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
 
-   err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", _spec.np,
-iommu_spec.args);
+   err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 848f549..c7aac81 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1995,3 +1995,105 @@ int of_find_last_cache_level(unsigned int cpu)
 
return cache_level;
 }
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+

[PATCH 1/7 v6] Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc bus

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..01fdc33 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+Documentation/networking/dpaa2/overview.rst
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/7 v6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

The patch series is based on top of dma-mapping tree (for-next branch):
http://git.infradead.org/users/hch/dma-mapping.git

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
  - Updates the fsl-mc device node with iommu/dma related changes (patch 7)

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

Changes in v3:
  - move of_map_rid in drivers/of/address.c

Changes in v4:
  - move of_map_rid in drivers/of/base.c

Changes in v5:
  - break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
  - add changelog text in patch 3/7 and patch 5/7
  - typo fix

Changes in v6:
  - Updated fsl_mc_device_group() API to be more rational
  - Added dma-coherent property in the LS2 smmu device node
  - Minor fixes in the device-tree documentation

Nipun Gupta (7):
  Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc
bus
  iommu/of: make of_pci_map_rid() available for other devices too
  iommu/of: support iommu configuration for fsl-mc devices
  iommu/arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: support dma configure for devices on fsl-mc bus
  bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   7 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  13 +++
 drivers/iommu/of_iommu.c   |  25 -
 drivers/of/base.c  | 102 +
 drivers/of/irq.c   |   5 +-
 drivers/pci/of.c   | 101 
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of.h |  11 +++
 include/linux/of_pci.h |  10 --
 13 files changed, 224 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 7/7 v5] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, July 3, 2018 10:06 PM
> To: Nipun Gupta ; will.dea...@arm.com;
> robh...@kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> catalin.mari...@arm.com; gre...@linuxfoundation.org; Laurentiu Tudor
> ; bhelg...@google.com
> Cc: h...@lst.de; j...@8bytes.org; m.szyprow...@samsung.com;
> shawn...@kernel.org; frowand.l...@gmail.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li 
> Subject: Re: [PATCH 7/7 v5] arm64: dts: ls208xa: comply with the iommu map
> binding for fsl_mc
> 
> On 20/05/18 14:49, Nipun Gupta wrote:
> > fsl-mc bus support the new iommu-map property. Comply to this binding
> > for fsl_mc bus.
> >
> > Signed-off-by: Nipun Gupta 
> > Reviewed-by: Laurentiu Tudor 
> > ---
> >   arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > index 137ef4d..6010505 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > @@ -184,6 +184,7 @@
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > +   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
> >
> > clockgen: clocking@130 {
> > compatible = "fsl,ls2080a-clockgen";
> > @@ -357,6 +358,8 @@
> > reg = <0x0008 0x0c00 0 0x40>,/* MC portal
> base */
> >   <0x 0x0834 0 0x4>; /* MC
> control reg */
> > msi-parent = <>;
> > +   iommu-map = <0  0 0>;  /* This is fixed-up by
> u-boot */
> > +   dma-coherent;
> > #address-cells = <3>;
> > #size-cells = <1>;
> >
> > @@ -460,6 +463,8 @@
> > compatible = "arm,mmu-500";
> > reg = <0 0x500 0 0x80>;
> > #global-interrupts = <12>;
> > +   #iommu-cells = <1>;
> > +   stream-match-mask = <0x7C00>;
> > interrupts = <0 13 4>, /* global secure fault */
> >  <0 14 4>, /* combined secure interrupt */
> >  <0 15 4>, /* global non-secure fault */
> > @@ -502,7 +507,6 @@
> >  <0 204 4>, <0 205 4>,
> >  <0 206 4>, <0 207 4>,
> >  <0 208 4>, <0 209 4>;
> > -   mmu-masters = <_mc 0x300 0>;
> 
> Since we're in here, is the SMMU itself also coherent? If it is, you
> probably want to say so and avoid the overhead of pointlessly cleaning
> cache lines on every page table update.

Yes, dma-coherent property is also required here. I missed it somehow.
Thanks for pointing this.

Regards,
Nipun

> 
> Robin.
> 
> > };
> >
> > dspi: dspi@210 {
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 5/7 v5] bus: fsl-mc: support dma configure for devices on fsl-mc bus

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, July 3, 2018 9:44 PM
> To: Nipun Gupta ; will.dea...@arm.com;
> robh...@kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> catalin.mari...@arm.com; gre...@linuxfoundation.org; Laurentiu Tudor
> ; bhelg...@google.com
> Cc: h...@lst.de; j...@8bytes.org; m.szyprow...@samsung.com;
> shawn...@kernel.org; frowand.l...@gmail.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li 
> Subject: Re: [PATCH 5/7 v5] bus: fsl-mc: support dma configure for devices
> on fsl-mc bus
> 
> On 20/05/18 14:49, Nipun Gupta wrote:
> > This patch adds support of dma configuration for devices on fsl-mc
> > bus using 'dma_configure' callback for busses. Also, directly calling
> > arch_setup_dma_ops is removed from the fsl-mc bus.
> 
> Looks like this is the final arch_setup_dma_ops offender, yay!
> 
> > Signed-off-by: Nipun Gupta 
> > Reviewed-by: Laurentiu Tudor 
> > ---
> >   drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++
> >   1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-
> bus.c
> > index 5d8266c..fa43c7d 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev,
> struct kobj_uevent_env *env)
> > return 0;
> >   }
> >
> > +static int fsl_mc_dma_configure(struct device *dev)
> > +{
> > +   struct device *dma_dev = dev;
> > +
> > +   while (dev_is_fsl_mc(dma_dev))
> > +   dma_dev = dma_dev->parent;
> > +
> > +   return of_dma_configure(dev, dma_dev->of_node, 0);
> > +}
> > +
> >   static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
> >  char *buf)
> >   {
> > @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> > .name = "fsl-mc",
> > .match = fsl_mc_bus_match,
> > .uevent = fsl_mc_bus_uevent,
> > +   .dma_configure  = fsl_mc_dma_configure,
> > .dev_groups = fsl_mc_dev_groups,
> >   };
> >   EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> > @@ -633,10 +644,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc
> *obj_desc,
> > goto error_cleanup_dev;
> > }
> >
> > -   /* Objects are coherent, unless 'no shareability' flag set. */
> > -   if (!(obj_desc->flags &
> FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> 
> Although it seems we do end up without any handling of this
> "non-coherent object behind coherent MC" case, and I'm not sure how
> easily that could be accommodated by generic code... :/ How important is
> the quirk?

We have all the devices as coherent in our SoC's now :) So this is fine.
We have internally discussed it.

Regards,
Nipun

> 
> Robin.
> 
> > -   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
> > -
> > /*
> >  * The device-specific probe callback will get invoked by device_add()
> >  */
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 1/7 v5] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, July 3, 2018 8:10 PM
> To: Nipun Gupta ; will.dea...@arm.com;
> robh...@kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> catalin.mari...@arm.com; gre...@linuxfoundation.org; Laurentiu Tudor
> ; bhelg...@google.com
> Cc: h...@lst.de; j...@8bytes.org; m.szyprow...@samsung.com;
> shawn...@kernel.org; frowand.l...@gmail.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li 
> Subject: Re: [PATCH 1/7 v5] Docs: dt: add fsl-mc iommu-map device-tree
> binding
> 
> On 20/05/18 14:49, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a generic binding for
> > mapping fsl-mc devices to IOMMUs, using iommu-map property.
> >
> > Signed-off-by: Nipun Gupta 
> > Reviewed-by: Rob Herring 
> > ---
> >   .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39
> ++
> >   1 file changed, 39 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..8cbed4f 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,25 @@ blocks that can be used to create functional hardware
> objects/devices
> >   such as network interfaces, crypto accelerator instances, L2 switches,
> >   etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> 
> Nit: Looks like that's Documentation/networking/dpaa2/overview.rst now.
> 
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> > +
> > +The generic 'iommus' property is insufficient to describe the relationship
> > +between ICIDs and IOMMUs, so an iommu-map property is used to
> define
> > +the set of possible ICIDs under a root DPRC and how they map to
> > +an IOMMU.
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >   Required properties:
> >
> >   - compatible
> > @@ -88,14 +107,34 @@ Sub-nodes:
> > Value type: 
> > Definition: Specifies the phandle to the PHY device node 
> > associated
> > with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-map: Maps an ICID to an IOMMU and associated iommu-
> specifier
> > +  data.
> > +
> > +  The property is an arbitrary number of tuples of
> > +  (icid-base,iommu,iommu-base,length).
> > +
> > +  Any ICID i in the interval [icid-base, icid-base + length) is
> > +  associated with the listed IOMMU, with the iommu-specifier
> > +  (i - icid-base + iommu-base).
> >
> >   Example:
> >
> > +smmu: iommu@500 {
> > +   compatible = "arm,mmu-500";
> > +   #iommu-cells = <2>;
> 
> This should be 1 if stream-match-mask is present. Bad example is bad :)

Agree :). Ill update it.

> 
> Robin.
> 
> > +   stream-match-mask = <0x7C00>;
> > +   ...
> > +};
> > +
> >   fsl_mc: fsl-mc@80c00 {
> >   compatible = "fsl,qoriq-mc";
> >   reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
> > base */
> > <0x 0x0834 0 0x4>; /* MC control 
> > reg */
> >   msi-parent = <>;
> > +/* define map for ICIDs 23-64 */
> > +iommu-map = <23  23 41>;
> >   #address-cells = <3>;
> >   #size-cells = <1>;
> >
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

Thanks Joro,

I will be sending it by mid of next week.

Regards,
Nipun

> -Original Message-
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Friday, July 6, 2018 4:43 PM
> To: Nipun Gupta 
> Cc: robin.mur...@arm.com; will.dea...@arm.com;
> gre...@linuxfoundation.org; h...@lst.de; m.szyprow...@samsung.com;
> shawn...@kernel.org; frowand.l...@gmail.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li 
> Subject: Re: [PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU
> 
> Hi Nipun,
> 
> On Thu, Jun 21, 2018 at 03:59:27AM +, Nipun Gupta wrote:
> > Will this patch-set be taken for the next kernel release (and via which 
> > tree)?
> 
> I can take this through IOMMU tree if nobody objects. Please work out
> the last remaining comment on patch 7 with Robin and then re-send with
> all Acks and Reviewed-by: tags included.
> 
> Oh, and please use 'iommu/of:' prefix instead of 'iommu: of:' and follow
> that sheme for the other patches/prefixes as well.
> 
> Thanks,
> 
>   Joerg

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

Hi Robin/Greg k-h,

Will this patch-set be taken for the next kernel release (and via which tree)?

Thanks,
Nipun

> -Original Message-
> From: Nipun Gupta
> Sent: Sunday, May 20, 2018 7:20 PM
> To: robin.mur...@arm.com; will.dea...@arm.com; robh...@kernel.org;
> r...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> gre...@linuxfoundation.org; Laurentiu Tudor ;
> bhelg...@google.com
> Cc: h...@lst.de; j...@8bytes.org; m.szyprow...@samsung.com;
> shawn...@kernel.org; frowand.l...@gmail.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Leo Li ; Nipun Gupta
> 
> Subject: [PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU
> 
> This patchset defines IOMMU DT binding for fsl-mc bus and adds
> support in SMMU for fsl-mc bus.
> 
> The patch series is based on top of dma-mapping tree (for-next branch):
> http://git.infradead.org/users/hch/dma-mapping.git
> 
> These patches
>   - Define property 'iommu-map' for fsl-mc bus (patch 1)
>   - Integrates the fsl-mc bus with the SMMU using this
> IOMMU binding (patch 2,3,4)
>   - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
>   - Updates the fsl-mc device node with iommu/dma related changes (patch 7)
> 
> Changes in v2:
>   - use iommu-map property for fsl-mc bus
>   - rebase over patchset https://patchwork.kernel.org/patch/10317337/
> and make corresponding changes for dma configuration of devices on
> fsl-mc bus
> 
> Changes in v3:
>   - move of_map_rid in drivers/of/address.c
> 
> Changes in v4:
>   - move of_map_rid in drivers/of/base.c
> 
> Changes in v5:
>   - break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
>   - add changelog text in patch 3/7 and patch 5/7
>   - typo fix
> 
> Nipun Gupta (7):
>   Docs: dt: add fsl-mc iommu-map device-tree binding
>   iommu: of: make of_pci_map_rid() available for other devices too
>   iommu: support iommu configuration for fsl-mc devices
>   iommu: arm-smmu: Add support for the fsl-mc bus
>   bus: fsl-mc: support dma configure for devices on fsl-mc bus
>   bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
>   arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc
> 
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
>  arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   6 +-
>  drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
>  drivers/iommu/arm-smmu.c   |   7 ++
>  drivers/iommu/iommu.c  |  21 +
>  drivers/iommu/of_iommu.c   |  25 -
>  drivers/of/base.c  | 102 
> +
>  drivers/of/irq.c   |   5 +-
>  drivers/pci/of.c   | 101 
>  include/linux/fsl/mc.h |   8 ++
>  include/linux/iommu.h  |   2 +
>  include/linux/of.h |  11 +++
>  include/linux/of_pci.h |  10 --
>  13 files changed, 231 insertions(+), 122 deletions(-)
> 
> --
> 1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 7/7 v5] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Laurentiu Tudor <laurentiu.tu...@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..6010505 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 5/7 v5] bus: fsl-mc: support dma configure for devices on fsl-mc bus

[Nipun Gupta]

This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Laurentiu Tudor <laurentiu.tu...@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..fa43c7d 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -633,10 +644,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/7 v5] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d2aa2320..6d4ce35 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee..2981200 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/7 v5] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -159,6 +160,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -190,6 +208,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/7 v5] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Rob Herring <r...@kernel.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
---
 drivers/iommu/of_iommu.c |   5 +--
 drivers/of/base.c| 102 +++
 drivers/of/irq.c |   5 +--
 drivers/pci/of.c | 101 --
 include/linux/of.h   |  11 +
 include/linux/of_pci.h   |  10 -
 6 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..811e160 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -149,9 +149,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
 
-   err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", _spec.np,
-iommu_spec.args);
+   err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 848f549..c7aac81 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1995,3 +1995,105 @@ int of_find_last_cache_level(unsigned int cpu)
 
return cache_level;
 }
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+  

[PATCH 1/7 v5] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Rob Herring <r...@kernel.org>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <2>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/7 v5] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

The patch series is based on top of dma-mapping tree (for-next branch):
http://git.infradead.org/users/hch/dma-mapping.git

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5, 6)
  - Updates the fsl-mc device node with iommu/dma related changes (patch 7)

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

Changes in v3:
  - move of_map_rid in drivers/of/address.c

Changes in v4:
  - move of_map_rid in drivers/of/base.c

Changes in v5:
  - break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
  - add changelog text in patch 3/7 and patch 5/7
  - typo fix

Nipun Gupta (7):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: support dma configure for devices on fsl-mc bus
  bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  21 +
 drivers/iommu/of_iommu.c   |  25 -
 drivers/of/base.c  | 102 +
 drivers/of/irq.c   |   5 +-
 drivers/pci/of.c   | 101 
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of.h |  11 +++
 include/linux/of_pci.h |  10 --
 13 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

> -Original Message-
> From: Laurentiu Tudor
> Sent: Monday, May 14, 2018 7:10 PM
> To: Nipun Gupta <nipun.gu...@nxp.com>; robin.mur...@arm.com;
> will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: h...@lst.de; gre...@linuxfoundation.org; j...@8bytes.org;
> robh...@kernel.org; m.szyprow...@samsung.com; shawn...@kernel.org;
> frowand.l...@gmail.com; bhelg...@google.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan <bharat.bhus...@nxp.com>;
> stuyo...@gmail.com; Leo Li <leoyang...@nxp.com>
> Subject: Re: [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices
> on fsl-mc bus
> 
> Hi Nipun,
> 
> On 04/27/2018 01:27 PM, Nipun Gupta wrote:
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >   drivers/bus/fsl-mc/fsl-mc-bus.c | 16 
> >   1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-
> bus.c
> > index 5d8266c..624828b 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev,
> struct kobj_uevent_env *env)
> > return 0;
> >   }
> >
> > +static int fsl_mc_dma_configure(struct device *dev)
> > +{
> > +   struct device *dma_dev = dev;
> > +
> > +   while (dev_is_fsl_mc(dma_dev))
> > +   dma_dev = dma_dev->parent;
> > +
> > +   return of_dma_configure(dev, dma_dev->of_node, 0);
> > +}
> > +
> >   static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
> >  char *buf)
> >   {
> > @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> > .name = "fsl-mc",
> > .match = fsl_mc_bus_match,
> > .uevent = fsl_mc_bus_uevent,
> > +   .dma_configure  = fsl_mc_dma_configure,
> > .dev_groups = fsl_mc_dev_groups,
> >   };
> >   EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> > @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc
> *obj_desc,
> > mc_dev->icid = parent_mc_dev->icid;
> > mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> > mc_dev->dev.dma_mask = _dev->dma_mask;
> > +   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
> 
> This change seems a bit unrelated to the patch subject. I wonder if it
> makes sense to split it it in a distinct patch.

Okay. I will spin a v5 after splitting this patch and adding changelog (Greg's 
comment), fixing typo (Bjorn's comment).

Regards,
Nipun

> 
> ---
> Best Regards, Laurentiu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 4/6] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d2aa2320..6d4ce35 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee..2981200 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 6/6] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..6010505 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 2/6] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c |   5 +--
 drivers/of/base.c| 102 +++
 drivers/of/irq.c |   5 +--
 drivers/pci/of.c | 101 --
 include/linux/of.h   |  11 +
 include/linux/of_pci.h   |  10 -
 6 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..811e160 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -149,9 +149,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
 
-   err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", _spec.np,
-iommu_spec.args);
+   err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 848f549..c7aac81 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1995,3 +1995,105 @@ int of_find_last_cache_level(unsigned int cpu)
 
return cache_level;
 }
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+   of_node_put(phandle_node);
+  

[PATCH v4 1/6] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Rob Herring <r...@kernel.org>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <2>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 3/6] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -159,6 +160,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -190,6 +208,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 0/6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

Changes in v3:
  - move of_map_rid in drivers/of/address.c

Changes in v4:
  - move of_map_rid in drivers/of/base.c

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  21 +
 drivers/iommu/of_iommu.c   |  25 -
 drivers/of/base.c  | 102 +
 drivers/of/irq.c   |   5 +-
 drivers/pci/of.c   | 101 
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of.h |  11 +++
 include/linux/of_pci.h |  10 --
 13 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, April 27, 2018 10:46 PM
> To: Nipun Gupta <nipun.gu...@nxp.com>
> Cc: robin.mur...@arm.com; will.dea...@arm.com; mark.rutl...@arm.com;
> catalin.mari...@arm.com; h...@lst.de; gre...@linuxfoundation.org;
> j...@8bytes.org; m.szyprow...@samsung.com; shawn...@kernel.org;
> frowand.l...@gmail.com; bhelg...@google.com; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan <bharat.bhus...@nxp.com>;
> stuyo...@gmail.com; Laurentiu Tudor <laurentiu.tu...@nxp.com>; Leo Li
> <leoyang...@nxp.com>
> Subject: Re: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On Fri, Apr 27, 2018 at 03:57:02PM +0530, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This
> > patch moves the of_pci_map_rid to generic location, so that it
> > can be used by other busses too.
> >
> > 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
> > functional change done in the API.
> >
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >  drivers/iommu/of_iommu.c   |   6 +--
> >  drivers/of/address.c   | 102
> +
> >  drivers/of/irq.c   |   7 ++--
> >  drivers/pci/of.c   | 101 
> > 
> >  include/linux/of_address.h |  11 +
> >  include/linux/of_pci.h |  10 -
> >  6 files changed, 120 insertions(+), 117 deletions(-)
> 
> of/address.c isn't really the best fit either, though I don't have a
> better suggestion.
> 
> I'm guessing this breaks on Sparc which doesn't build of/address.c.
> I guess move it to base.c and of.h if that is the case.

Sure, that makes sense. Thank you for the suggestion !!
I'll spin off new version with this change.

Regards,
Nipun

> 
> Rob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Acked-by: Bjorn Helgaas <bhelg...@google.com>  # PCI parts
---
Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

Changes in v3:
  - Rebase and changes corresponding to the changes in patch 1/2

Changes in v4:
  - Rebased on top of 4.17-rc2

 drivers/amba/bus.c| 1 -
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/of_device.h | 8 ++--
 10 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 867dc2b..abe73c4 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = platform_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 638d42e..c0ff1e7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a9ec99d..b39c1e9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
return 0;
 }
 
@@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void __host1x_device_del(struct host1x_device *device)
@@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = _bus_type;
device->dev.parent = host1x->dev;
 
-   of_dma_configure(>dev, host1x->dev->of_node);
+   of_dma_configure(>dev, host1x->dev->of_node, true);
 
err = host1x_device_parse_dt(device, driver);
if (err < 0) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 064c818..33d8551 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
  * of_dma_configure - Setup DMA configuration
  * @dev:   Device to apply DMA configuration
  * @np:Pointer to OF node having DMA configuration
+ * @force_dma:  Whether device is to be set up by of_d

[PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig <h...@lst.de>
Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>  # PCI parts
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

Changes in v3:
  - Move dma_common_configure() within platform_dma_configure() and
reuse platofrm_dma_configure() for AMBA bus too
  - Declare 'attr' in pci_dma_configure() inside the else statement
where it is used.

Changes in v4:
  - Rebased on top of 4.17-rc2

 drivers/amba/bus.c  |  4 
 drivers/base/dma-mapping.c  | 31 ---
 drivers/base/platform.c | 17 +
 drivers/gpu/host1x/bus.c|  8 
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/platform_device.h |  2 ++
 7 files changed, 71 insertions(+), 27 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..867dc2b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
 /*
  * Primecells are part of the Advanced Microcontroller Bus Architecture,
  * so we call the bus "amba".
+ * DMA configuration for platform and AMBA bus is same. So here we reuse
+ * platform's DMA config routine.
  */
 struct bus_type amba_bustype = {
.name   = "amba",
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index d82566d..f831a58 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -329,36 +329,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * enables DMA API use for a device
  */
-#include 
-
 int dma_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
-   enum dev_dma_attr attr;
-   int ret = 0;
-
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
-   if (attr != DEV_DMA_NOT_SUPPORTED)
-   ret = acpi_dma_configure(dev, attr);
-   }
-
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
-   return ret;
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+   return 0;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 8075ddc..638d42e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+int platform_dma_configure(struct device *dev)
+{
+   enum dev_dma_attr attr;
+   int ret = 0;
+
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+   if (attr != DEV_DMA_NOT_SUPPORTED)
+   ret = acpi_dma_configure(dev, attr);
+   }
+
+   return ret;
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {

RE: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Monday, April 23, 2018 6:27 PM
> To: Nipun Gupta <nipun.gu...@nxp.com>
> Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> gre...@linuxfoundation.org; m.szyprow...@samsung.com;
> bhelg...@google.com; zaj...@gmail.com; andy.gr...@linaro.org;
> david.br...@linaro.org; dan.j.willi...@intel.com; vinod.k...@intel.com;
> thierry.red...@gmail.com; robh...@kernel.org; frowand.l...@gmail.com;
> jarkko.sakki...@linux.intel.com; rafael.j.wyso...@intel.com;
> dmitry.torok...@gmail.com; jo...@kernel.org; msucha...@suse.de; linux-
> ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linux-
> wirel...@vger.kernel.org; linux-arm-...@vger.kernel.org; linux-
> s...@vger.kernel.org; dmaeng...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; linux-te...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan
> <bharat.bhus...@nxp.com>; Leo Li <leoyang...@nxp.com>
> Subject: Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus
> infrastructure
> 
> Can you resend your changes against Linux 4.17-rc2?  There are a lot
> of conflicts as-is.

Sure.. I will send it soon..

Regards,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 6/6 v3] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..6010505 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c   |   6 +--
 drivers/of/address.c   | 102 +
 drivers/of/irq.c   |   7 ++--
 drivers/pci/of.c   | 101 
 include/linux/of_address.h |  11 +
 include/linux/of_pci.h |  10 -
 6 files changed, 120 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..ea9ecef 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -149,9 +150,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
 
-   err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", _spec.np,
-iommu_spec.args);
+   err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5334991..4163f24 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -985,3 +985,105 @@ bool of_dma_is_coherent(struct device_node *np)
return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target)

[PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/6 v3] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

Changes in v3:
  - move of_map_rid in drivers/of/address.c

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 +++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  21 +
 drivers/iommu/of_iommu.c   |  26 +-
 drivers/of/address.c   | 102 +
 drivers/of/irq.c   |   7 +-
 drivers/pci/of.c   | 101 
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of_address.h |  11 +++
 include/linux/of_pci.h |  10 --
 13 files changed, 234 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/6 v3] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d2aa2320..6d4ce35 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee..2981200 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/6 v3] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index ea9ecef..3687882 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -160,6 +161,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -191,6 +209,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 1/6 v3] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <2>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gu...@nxp.com>; robh...@kernel.org;
> frowand.l...@gmail.com
> Cc: will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com;
> h...@lst.de; gre...@linuxfoundation.org; j...@8bytes.org;
> m.szyprow...@samsung.com; shawn...@kernel.org; bhelg...@google.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; linux-...@vger.kernel.org; Bharat Bhushan
> <bharat.bhus...@nxp.com>; stuyo...@gmail.com; Laurentiu Tudor
> <laurentiu.tu...@nxp.com>; Leo Li <leoyang...@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.
> >
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.

Thanks for pointing out.
Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case.

> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look 
> around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could 
> live?
> 
> >   drivers/of/irq.c |   6 +--
> >   drivers/pci/of.c | 101 
> > 
> >   include/linux/of_iommu.h |  11 +
> >   include/linux/of_pci.h   |  10 -
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >

[...]

> >   struct of_pci_iommu_alias_info {
> > struct device *dev;
> > struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> > struct of_phandle_args iommu_spec = { .args_count = 1 };
> > int err;
> >
> > -   err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -"iommu-map-mask", _spec.np,
> > -iommu_spec.args);
> > +   err = of_map_rid(info->np, alias, "iommu-map",
> > +"iommu-map-mask", _spec.np,
> > +iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, 
> but if
> it's being touched again, that would be nice ;)

Sure.. I'll take care of this in the next version :)

Regards,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

Fsl-mc bus now support the iommu-map property. Comply to this binding for
fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1b1c5eb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 +++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 ++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  21 
 drivers/iommu/of_iommu.c   | 126 -
 drivers/of/irq.c   |   6 +-
 drivers/pci/of.c   | 101 -
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of_iommu.h   |  11 ++
 include/linux/of_pci.h |  10 --
 12 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 4e7712f..af4fc3b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c | 106 +--
 drivers/of/irq.c |   6 +--
 drivers/pci/of.c | 101 
 include/linux/of_iommu.h |  11 +
 include/linux/of_pci.h   |  10 -
 5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
return ops->of_xlate(dev, iommu_spec);
 }
 
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+   of_node_put(phandle_node);
+   else
+   *target = phandle_node;
+
+   if (*target != phandle_node)
+   continue;
+   }
+
+   if (id_out)
+   *id_out = masked_rid - rid_base + out_base;
+
+   pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: 
%08x, length: %08x, rid: %08x -> %08x\n",
+   np, map_name, map_mask, rid_base, out_base,
+   rid_len, rid, masked_rid - rid_base + out_base);
+   return 0;
+   }
+
+   pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+   np, map_name, rid, target && *target ? *target : NULL);
+   return -EFAULT;
+}
+
 struct of_pci_iommu_alias_info {
struct device *dev;
struct device_node *np;
@@ -149,9 +249,9 @@ static int of_pci

[PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <2>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

Changes in v3:
  - Rebase and changes corresponding to the changes in patch 1/2

 drivers/amba/bus.c| 1 -
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/of_device.h | 8 ++--
 10 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 867dc2b..abe73c4 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = platform_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 72fdbf6..cfbc569 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a9ec99d..b39c1e9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
return 0;
 }
 
@@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void __host1x_device_del(struct host1x_device *device)
@@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = _bus_type;
device->dev.parent = host1x->dev;
 
-   of_dma_configure(>dev, host1x->dev->of_node);
+   of_dma_configure(>dev, host1x->dev->of_node, true);
 
err = host1x_device_parse_dt(device, driver);
if (err < 0) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 064c818..33d8551 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
  * of_dma_configure - Setup DMA configuration
  * @dev:   Device to apply DMA configuration
  * @np:Pointer to OF node having DMA configuration
+ * @force_dma:  Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not explicitly described by firmware.
  *
  * Try to get 

[PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig <h...@lst.de>
Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

Changes in v3
  - Move dma_common_configure() within platform_dma_configure() and
reuse platofrm_dma_configure() for AMBA bus too
  - Declare 'attr' in pci_dma_configure() inside the else statement
where it is used.

 drivers/amba/bus.c  |  4 
 drivers/base/dma-mapping.c  | 31 ---
 drivers/base/platform.c | 17 +
 drivers/gpu/host1x/bus.c|  8 
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/platform_device.h |  2 ++
 7 files changed, 71 insertions(+), 27 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..867dc2b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
 /*
  * Primecells are part of the Advanced Microcontroller Bus Architecture,
  * so we call the bus "amba".
+ * DMA configuration for platform and AMBA bus is same. So here we reuse
+ * platform's DMA config routine.
  */
 struct bus_type amba_bustype = {
.name   = "amba",
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..fdc1502 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -331,36 +331,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * enables DMA API use for a device
  */
-#include 
-
 int dma_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
-   enum dev_dma_attr attr;
-   int ret = 0;
-
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
-   if (attr != DEV_DMA_NOT_SUPPORTED)
-   ret = acpi_dma_configure(dev, attr);
-   }
-
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
-   return ret;
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+   return 0;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f1bf7b3..72fdbf6 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+int platform_dma_configure(struct device *dev)
+{
+   enum dev_dma_attr attr;
+   int ret = 0;
+
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+   if (attr != DEV_DMA_NOT_SUPPORTED)
+   ret = acpi_dma_configure(dev, attr);
+   }
+
+   return ret;
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

I am just going to send it within an hour :)

Thanks,
Nipun

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Friday, March 30, 2018 12:46
> To: Nipun Gupta <nipun.gu...@nxp.com>
> Cc: h...@lst.de; robin.mur...@arm.com; li...@armlinux.org.uk;
> gre...@linuxfoundation.org; m.szyprow...@samsung.com; bhelg...@google.com;
> dmitry.torok...@gmail.com; rafael.j.wyso...@intel.com;
> jarkko.sakki...@linux.intel.com; linus.wall...@linaro.org;
> jo...@kernel.org; msucha...@suse.de; linux-ker...@vger.kernel.org;
> iommu@lists.linux-foundation.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] dma-mapping: move dma configuration to bus
> infrastructure
> 
> Can you resend the current state of affairs so we can get it in for
> 4.17?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 22, 2018 13:49
> To: Nipun Gupta <nipun.gu...@nxp.com>
> 
> > --- a/drivers/dma/qcom/hidma_mgmt.c
> > +++ b/drivers/dma/qcom/hidma_mgmt.c
> > @@ -398,7 +398,7 @@ static int __init
> hidma_mgmt_of_populate_channels(struct device_node *np)
> > }
> > of_node_get(child);
> > new_pdev->dev.of_node = child;
> > -   of_dma_configure(_pdev->dev, child);
> > +   of_dma_configure(_pdev->dev, child, true);
> > /*
> >  * It is assumed that calling of_msi_configure is safe on
> >  * platforms with or without MSI support.
> 
> Where did we mark this bus as force_dma before?

I thought these devices to be on the platform bus as the device is of type
'struct platform_device', though I am not sure then why 'of_dma_configure()'
is called here. Is this not on platform bus?

> 
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 9a4f4246..895c83e 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -353,7 +353,7 @@ int of_reserved_mem_device_init_by_idx(struct device
> *dev,
> > /* ensure that dma_ops is set for virtual devices
> >  * using reserved memory
> >  */
> > -   of_dma_configure(dev, np);
> > +   of_dma_configure(dev, np, true);
> 
> Did all the callers of this one really force dma?  I have a hard time
> untangling the call stacks unfortunately.

I see this API being called indirectly from NXP DPAA device driver which
is for platform bus devices. So I marked 'true' out here. There are more places
from where it is being called.

Thanks,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 22, 2018 13:46
> To: Nipun Gupta <nipun.gu...@nxp.com>
> 
> > +static int amba_dma_configure(struct device *dev)
> > +{
> > +   return dma_common_configure(dev);
> > +}
> 
> So it turns out we only end with two callers of dma_common_configure
> after this series.  Based ont hat I'm tempted with the suggestion
> from Robin to just have amba call platform_dma_configure, and move
> the code from dma_common_configure to platform_dma_configure.

okay, that would be fine, trivial query - will it be okay to include
'linux/platform_device.h' in the AMBA bus? I am reluctant for this change
because of including platform file.

Thanks,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:05
> To: Nipun Gupta <nipun.gu...@nxp.com>
> Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> m.szyprow...@samsung.com; bhelg...@google.com; zaj...@gmail.com;
> andy.gr...@linaro.org; david.br...@linaro.org; dan.j.willi...@intel.com;
> vinod.k...@intel.com; thierry.red...@gmail.com; robh...@kernel.org;
> frowand.l...@gmail.com; jarkko.sakki...@linux.intel.com;
> rafael.j.wyso...@intel.com; dmitry.torok...@gmail.com; jo...@kernel.org;
> msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux-
> foundation.org; linux-wirel...@vger.kernel.org; linux-arm-
> m...@vger.kernel.org; linux-...@vger.kernel.org; dmaeng...@vger.kernel.org;
> dri-de...@lists.freedesktop.org; linux-te...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan
> <bharat.bhus...@nxp.com>; Leo Li <leoyang...@nxp.com>
> Subject: Re: [PATCH v2 2/2] drivers: remove force dma flag from buses
> 
> On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> > With each bus implementing its own DMA configuration callback,
> > there is no need for bus to explicitly have force_dma in its
> > global structure. This patch modifies of_dma_configure API to
> > accept an input parameter which specifies if implicit DMA
> > configuration is required even when it is not described by the
> > firmware.
> 
> Having to "remember" what that bool variable means on the end of the
> function call is a royal pain over time, right?
> 
> Why not just create a new function:
>   dma_common_configure_force(dma)
> that always does this?  Leave "dma_common_configure()" alone, and then
> wrap the old code with these two helper functions that call the 'core'
> code with the bool set properly?
> 
> That way you do not have to "know" what that parameter is, the function
> name just documents it automatically, so when you see it in the
> bus-specific code, no need to go and have to hunt for anything.  And if
> you are reading the dma core code, it's obvious what is happening as the
> functions are all right there.

How about we do not pass any flag in 'dma_common_configure()', and inside this
API we pass "true" to 'of_dma_configure()'? I am saying this because currently
both the busses (platform and AMBA) which uses 'dma_common_configure()' passes
"true" value. If we create additional 'dma_common_configure_force()', then
'dma_common_configure()' will not be used anytime and will become redundant.

If someday new busses come and they needs to use similar functionality which
'dma_common_configure()' provides, but with passing "false" to 
'of_dma_configure()',
then what you suggests of having two separate such API's will be more reasonable
and can be implemented?

Thanks,
Nipun

> 
> thanks,
> 
> greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:00



> > +int dma_configure(struct device *dev)
> > +{
> > +   if (dev->bus->dma_configure)
> > +   return dev->bus->dma_configure(dev);
> > +
> > +   return 0;
> > +}
> >  void dma_deconfigure(struct device *dev)
> 
> Empty line after this new function?  Sorry, couldn't help it :)
> 
> >  {
> > of_dma_deconfigure(dev);
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index f1bf7b3..d2d5891 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
> >
> >  #endif /* CONFIG_HIBERNATE_CALLBACKS */
> >



> > +
> > const struct dev_pm_ops *pm;
> >
> > const struct iommu_ops *iommu_ops;
> > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > index eb9eab4..c15986b 100644
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -761,6 +761,7 @@ void *dma_mark_declared_memory_occupied(struct
> device *dev,
> >  }
> >  #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
> >
> > +int dma_common_configure(struct device *dev);
> >  #ifdef CONFIG_HAS_DMA
> 
> Blank line after the new function declaration?
> 
> Other than those very minor things, nice job, this looks good:
> 
> Reviewed-by: Greg Kroah-Hartman 

Thank you for the review :). I will fix your comments in next version.

Regards,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Bharat Bhushan
> Sent: Wednesday, March 21, 2018 12:49

> >
> > +int dma_configure(struct device *dev)
> > +{
> > +   if (dev->bus->dma_configure)
> > +   return dev->bus->dma_configure(dev);
> 
> What if dma_common_configure() is called in case "bus->dma_configure" is
> not defined?
> 
> Thanks
> -Bharat

I think it is cleaner for bus to call '/dma_common_configure/' rather
than this been called implicitly, but Robin/Christoph can comment
better on this.

Thanks,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It's bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces '/dma_configure/' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig <h...@lst.de>
Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

 drivers/amba/bus.c  |  7 +++
 drivers/base/dma-mapping.c  | 35 +++
 drivers/base/platform.c |  6 ++
 drivers/gpu/host1x/bus.c|  9 +
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/dma-mapping.h |  1 +
 7 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..2fa1e8b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -171,6 +172,11 @@ static int amba_pm_runtime_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+static int amba_dma_configure(struct device *dev)
+{
+   return dma_common_configure(dev);
+}
+
 static const struct dev_pm_ops amba_pm = {
.suspend= pm_generic_suspend,
.resume = pm_generic_resume,
@@ -194,6 +200,7 @@ struct bus_type amba_bustype = {
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = amba_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..48f9af0 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -331,38 +331,33 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * Common configuration to enable DMA API use for a device.
+ * A bus can use this function in its 'dma_configure' callback, if
+ * suitable for the bus.
  */
-#include 
-
-int dma_configure(struct device *dev)
+int dma_common_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
enum dev_dma_attr attr;
int ret = 0;
 
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
ret = acpi_dma_configure(dev, attr);
}
 
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
return ret;
 }
 
+int dma_configure(struct device *dev)
+{
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+
+   return 0;
+}
 void dma_deconfigure(struct device *dev)
 {
of_dma_deconfigure(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f1bf7b3..d2d5891 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+static int platform_dma_configure(struct device *dev)
+{
+   return dma_common_configure(dev);
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,6 +1146,7 @@ struct bus_type platform_bus_type = {
.dev_groups = platform_dev_groups,
.match  = platform_match,
.uevent = platform_uevent,
+   .dma_configure  = platform_dm

[PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---

Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

 drivers/amba/bus.c| 3 +--
 drivers/base/dma-mapping.c| 4 ++--
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/dma-mapping.h   | 2 +-
 include/linux/of_device.h | 4 +++-
 12 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 2fa1e8b..1d58348 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -174,7 +174,7 @@ static int amba_pm_runtime_resume(struct device *dev)
 
 static int amba_dma_configure(struct device *dev)
 {
-   return dma_common_configure(dev);
+   return dma_common_configure(dev, true);
 }
 
 static const struct dev_pm_ops amba_pm = {
@@ -202,7 +202,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = amba_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 48f9af0..03f8584 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -335,13 +335,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
  * A bus can use this function in its 'dma_configure' callback, if
  * suitable for the bus.
  */
-int dma_common_configure(struct device *dev)
+int dma_common_configure(struct device *dev, bool force_dma)
 {
enum dev_dma_attr attr;
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, force_dma);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d2d5891..154707c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1132,7 +1132,7 @@ int platform_pm_restore(struct device *dev)
 
 static int platform_dma_configure(struct device *dev)
 {
-   return dma_common_configure(dev);
+   return dma_common_configure(dev, true);
 }
 
 static const struct dev_pm_ops platform_dev_pm_ops = {
@@ -1148,7 +1148,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index fa9896d..211eb6b 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
 
return 0;
 }
@@ -336,7 +336,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma =

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, March 13, 2018 17:06
> 
> On 12/03/18 15:24, Nipun Gupta wrote:
> > The change introduces 'dma_configure' & 'dma_deconfigure'as
> > bus callback functions so each bus can choose to implement
> > its own dma configuration function.
> > This eases the addition of new busses w.r.t. adding the dma
> > configuration functionality.
> 
> It's probably worth clarifying - either in the commit message, the
> kerneldoc, or both - that the bus-specific aspect is that of mapping
> between a given device on the bus and the relevant firmware description
> of its DMA configuration.

Okay.

>
> > The change also updates the PCI, Platform and ACPI bus to use
> > new introduced callbacks.
> >
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >   - This patch is based on the comments on:
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwo
> rk.kernel.org%2Fpatch%2F10259087%2F=02%7C01%7Cnipun.gupta%40nxp.com%7
> Cc541100ecb944e7650a408d588d69ab0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C636565377665676631=k2Xjn5B1GECx4UjCg9tChOpOrD3NPM7BkzIXLLSv3rI%
> 3D=0
> >   - I have validated for PCI and platform, but not for AMBA as I
> > do not have infrastructure to validate it.
> > Can anyone please validate them on AMBA?
> >
> >   drivers/amba/bus.c  | 38 -
> >   drivers/base/dd.c   | 14 +++
> >   drivers/base/dma-mapping.c  | 41 ---
> >   drivers/base/platform.c | 36 ++-
> >   drivers/pci/pci-driver.c| 59 -
> 
> >   include/linux/device.h  |  6 +
> >   include/linux/dma-mapping.h | 12 -
> >   7 files changed, 124 insertions(+), 82 deletions(-)
> >
> > diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> > index 594c228..58241d2 100644
> > --- a/drivers/amba/bus.c
> > +++ b/drivers/amba/bus.c
> > @@ -20,6 +20,8 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > +#include 
> >
> >   #include 
> >
> > @@ -171,6 +173,28 @@ static int amba_pm_runtime_resume(struct device
> *dev)
> >   }
> >   #endif /* CONFIG_PM */
> >
> > +int amba_dma_configure(struct device *dev)
> > +{
> > +   enum dev_dma_attr attr;
> > +   int ret = 0;
> > +
> > +   if (dev->of_node) {
> > +   ret = of_dma_configure(dev, dev->of_node);
> > +   } else if (has_acpi_companion(dev)) {
> > +   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
> > +   if (attr != DEV_DMA_NOT_SUPPORTED)
> > +   ret = acpi_dma_configure(dev, attr);
> > +   }
> > +
> > +   return ret;
> > +}
> 
> I would be inclined to have amba_bustype just reference
> platform_dma_configure() directly rather than duplicate it like this,
> since there's no sensible reason for them to ever differ.

I think dma_common_configure() having this as the common code seems pretty
Decent. All the busses will probably call this API.

> 
> > +
> > +void amba_dma_deconfigure(struct device *dev)
> > +{
> > +   of_dma_deconfigure(dev);
> > +   acpi_dma_deconfigure(dev);
> > +}
> > +
> >   static const struct dev_pm_ops amba_pm = {
> > .suspend= pm_generic_suspend,
> > .resume = pm_generic_resume,
> > @@ -190,12 +214,14 @@ static int amba_pm_runtime_resume(struct device
> *dev)
> >* so we call the bus "amba".
> >*/
> >   struct bus_type amba_bustype = {
> > -   .name   = "amba",
> > -   .dev_groups = amba_dev_groups,
> > -   .match  = amba_match,
> > -   .uevent = amba_uevent,
> > -   .pm = _pm,
> > -   .force_dma  = true,
> > +   .name   = "amba",
> > +   .dev_groups = amba_dev_groups,
> > +   .match  = amba_match,
> > +   .uevent = amba_uevent,
> > +   .pm = _pm,
> > +   .dma_configure  = amba_dma_configure,
> > +   .dma_deconfigure= amba_dma_deconfigure,
> > +   .force_dma  = true,
> 
> This patch should also be removing force_dma because it no longer makes
> sense. If DMA configuration is now done by a bus-level callback, then a
> bus which wants its children to get DMA configuration needs to implemen

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Tuesday, March 13, 2018 13:05
> > +int amba_dma_configure(struct device *dev)
> > +{
> > +   enum dev_dma_attr attr;
> > +   int ret = 0;
> > +
> > +   if (dev->of_node) {
> > +   ret = of_dma_configure(dev, dev->of_node);
> > +   } else if (has_acpi_companion(dev)) {
> > +   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
> > +   if (attr != DEV_DMA_NOT_SUPPORTED)
> > +   ret = acpi_dma_configure(dev, attr);
> > +   }
> > +
> > +   return ret;
> 
> This code sniplet is duplicated so many times that I think we should
> just have some sort of dma_common_configure() for it that the various
> busses can use.

Agree. There is no good point in duplicating the code.
So this new API will be part of 'drivers/base/dma-mapping.c' file?

> 
> > +void amba_dma_deconfigure(struct device *dev)
> > +{
> > +   of_dma_deconfigure(dev);
> > +   acpi_dma_deconfigure(dev);
> > +}
> 
> As mention in my previous reply I think we don't even need a deconfigure
> callback at this point - just remove the ACPI and OF wrappers and
> clear the dma ops.
> 
> Also in this series we should replace the force_dma flag by use of the
> proper method, e.g. give a force parameter to of_dma_configure and the
> new dma_common_configure helper that the busses that want it can set.

I am more inclined to what Robin states in other mail to keep symmetry.
i.e. to keep dma_configure() and dma_deconfigure() and call
dev->bus->dma_configure from dma_configure(). Is this okay?

Thanks,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Sinan Kaya [mailto:ok...@codeaurora.org]
> Sent: Monday, March 12, 2018 22:14
> To: Nipun Gupta <nipun.gu...@nxp.com>; h...@lst.de;
> robin.mur...@arm.com; li...@armlinux.org.uk; gre...@linuxfoundation.org;
> m.szyprow...@samsung.com; bhelg...@google.com
> Cc: dmitry.torok...@gmail.com; rafael.j.wyso...@intel.com;
> jarkko.sakki...@linux.intel.com; linus.wall...@linaro.org; jo...@kernel.org;
> msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux-
> foundation.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] dma-mapping: move dma configuration to bus
> infrastructure
> 
> On 3/12/2018 11:24 AM, Nipun Gupta wrote:
> > +   if (dma_dev->of_node) {
> > +   ret = of_dma_configure(dev, dma_dev->of_node);
> > +   } else if (has_acpi_companion(dma_dev)) {
> > +   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev-
> >fwnode));
> > +   if (attr != DEV_DMA_NOT_SUPPORTED)
> > +   ret = acpi_dma_configure(dev, attr);
> > +   }
> > +
> > +   pci_put_host_bridge_device(bridge);
> > +
> > +   return ret;
> > +}
> > +
> > +void pci_dma_deconfigure(struct device *dev)
> > +{
> > +   of_dma_deconfigure(dev);
> > +   acpi_dma_deconfigure(dev);
> > +}
> 
> Isn't this one or the other one but not both?
> 
> Something like:
> 
> if (dev->of_node)
>   of_dma_deconfigure(dev);
> else
>   acpi_dma_deconfigure(dev);
> 
> should work.

I understand your point. Seems reasonable as we should not expect
the 'of/acpi DMA deconfigure' API to not fail when they are not configured.

But, here we would also need to get dma_device (just as we get in
'pci_dma_configure') and need a check on it as for PCI there 'of_node'
is present in the dma_dev.

Ill update this in v2, and also make similar changes for platform and AMBA bus.

Thanks,
Nipun

> 
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
> Foundation Collaborative Project.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

The change introduces 'dma_configure' & 'dma_deconfigure'as
bus callback functions so each bus can choose to implement
its own dma configuration function.
This eases the addition of new busses w.r.t. adding the dma
configuration functionality.

The change also updates the PCI, Platform and ACPI bus to use
new introduced callbacks.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 - This patch is based on the comments on:
   https://patchwork.kernel.org/patch/10259087/
 - I have validated for PCI and platform, but not for AMBA as I
   do not have infrastructure to validate it.
   Can anyone please validate them on AMBA?

 drivers/amba/bus.c  | 38 -
 drivers/base/dd.c   | 14 +++
 drivers/base/dma-mapping.c  | 41 ---
 drivers/base/platform.c | 36 ++-
 drivers/pci/pci-driver.c| 59 -
 include/linux/device.h  |  6 +
 include/linux/dma-mapping.h | 12 -
 7 files changed, 124 insertions(+), 82 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..58241d2 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -171,6 +173,28 @@ static int amba_pm_runtime_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+int amba_dma_configure(struct device *dev)
+{
+   enum dev_dma_attr attr;
+   int ret = 0;
+
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+   if (attr != DEV_DMA_NOT_SUPPORTED)
+   ret = acpi_dma_configure(dev, attr);
+   }
+
+   return ret;
+}
+
+void amba_dma_deconfigure(struct device *dev)
+{
+   of_dma_deconfigure(dev);
+   acpi_dma_deconfigure(dev);
+}
+
 static const struct dev_pm_ops amba_pm = {
.suspend= pm_generic_suspend,
.resume = pm_generic_resume,
@@ -190,12 +214,14 @@ static int amba_pm_runtime_resume(struct device *dev)
  * so we call the bus "amba".
  */
 struct bus_type amba_bustype = {
-   .name   = "amba",
-   .dev_groups = amba_dev_groups,
-   .match  = amba_match,
-   .uevent = amba_uevent,
-   .pm = _pm,
-   .force_dma  = true,
+   .name   = "amba",
+   .dev_groups = amba_dev_groups,
+   .match  = amba_match,
+   .uevent = amba_uevent,
+   .pm = _pm,
+   .dma_configure  = amba_dma_configure,
+   .dma_deconfigure= amba_dma_deconfigure,
+   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index de6fd09..f124f3f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -421,9 +421,11 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
if (ret)
goto pinctrl_bind_failed;
 
-   ret = dma_configure(dev);
-   if (ret)
-   goto dma_failed;
+   if (dev->bus->dma_configure) {
+   ret = dev->bus->dma_configure(dev);
+   if (ret)
+   goto dma_failed;
+   }
 
if (driver_sysfs_add(dev)) {
printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
@@ -486,7 +488,8 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
goto done;
 
 probe_failed:
-   dma_deconfigure(dev);
+   if (dev->bus->dma_deconfigure)
+   dev->bus->dma_deconfigure(dev);
 dma_failed:
if (dev->bus)
blocking_notifier_call_chain(>bus->p->bus_notifier,
@@ -895,7 +898,8 @@ static void __device_release_driver(struct device *dev, 
struct device *parent)
drv->remove(dev);
 
device_links_driver_cleanup(dev);
-   dma_deconfigure(dev);
+   if (dev->bus->dma_deconfigure)
+   dev->bus->dma_deconfigure(dev);
 
devres_release_all(dev);
dev->driver = NULL;
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..f16bd49 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -6,11 +6,9 @@
  * Copyright (c) 2006  Tejun Heo <te...@suse.de>
  */
 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -329,42 +327,3 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
vunmap(cpu_addr);
 }
 #endif
-
-/*
- * Common configuration to enable DMA API use for a device
- */
-#include 
-
-int dma_configure(s

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Thursday, March 08, 2018 13:11
> 
> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> > Sorry for asking a trivial question - looking into dma_configure() I see 
> > that
> > PCI is used in the start and the end of the API.
> > In the end part pci_put_host_bridge_device() is called.
> > So are two bus callbacks something like 'dma_config_start' &
> 'dma_config_end'
> > will be required where the former one will return "dma_dev"?
> 
> I'd just use dma_configure as the callback.

This would be a decent stuff.

> 
> Currently the of_dma_configure and acpi_dma_configure are only used
> for PCI anyway, as no one else sets a non-NULL dma dev.

My understanding is that even the platform bus uses the of_dma_configure
and probably acpi_dma_configure too. So platform bus may also need the
callback implemented. Please correct me if my understanding is wrong.

I will submit the patch with 'dma_configure' callback implemented for
the busses shortly.

> For fsl-mc I suspect only of_dma_configure is relevanet, so just call that 
> directly.
> If at some point we get enough busses with either OF or ACPI we could
> create a helper called from ->dma_configure for that.

Totally agree with this.

Thanks,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, March 08, 2018 4:10
> To: Nipun Gupta <nipun.gu...@nxp.com>
> Cc: will.dea...@arm.com; robin.mur...@arm.com; mark.rutl...@arm.com;
> catalin.mari...@arm.com; devicet...@vger.kernel.org; stuyo...@gmail.com;
> Bharat Bhushan <bharat.bhus...@nxp.com>; gre...@linuxfoundation.org;
> j...@8bytes.org; linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> Leo Li <leoyang...@nxp.com>; iommu@lists.linux-foundation.org; Laurentiu
> Tudor <laurentiu.tu...@nxp.com>; shawn...@kernel.org; h...@lst.de; linux-
> arm-ker...@lists.infradead.org; m.szyprow...@samsung.com
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31
> ++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >  such as network interfaces, crypto accelerator instances, L2 switches,
> >  etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> > +
> > +The generic 'iommus' property is cannot be used to describe the 
> > relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> 
> Why not? It is just a link between 2 nodes.

We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a 
device.
Once USB and other devices start to use IOMMU we will also need this 
iommu-cells.

When #iommu-cells is defined as '1' and we have 'iommus=<>' compilation
reports warning about the mismatch.
In fsl-mc bus case we do not have any stream id associated with the bus.

As suggested by Robin, we can simply use the iommu-map property.

> 
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >  Required properties:
> >
> >  - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >Value type: 
> >Definition: Specifies the phandle to the PHY device node 
> > associated
> >with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> 
> If you want a generic property, this should be documented in the common
> binding.

We can use the iommu-map property which is already documented.

> 
> Couldn't you have more than 1 IOMMU upstream of a MC?

There is no such device currently with which fsl-mc bus uses more than one 
iommu.
Infact, our current systems have only single IOMMU :).

Even in future if such devices are there then we can use iommu-map to specify
more than one iommu with separate requester ID's (RID's).

Thank you for review...

Regards,
Nipun

> 
> >
> >  Example:
> >
> > +smmu: iommu@500 {
> > +   compatible = "arm,mmu-500";
> > +   #iommu-cells = <1>;
> > +   stream-match-mask = <0x7C00>;
> > +   ...
> > +};
> > +
> >  fsl_mc: fsl-mc@80c00 {
> >  compatible = "fsl,qoriq-mc";
> >  reg = <0x0008 0x0c00 0 0x40>,/* MC portal base 
> > */
> ><0x 0x0834 0 0x4>; /* MC control reg 
> > */
> >

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, March 06, 2018 0:22
> 
> On 05/03/18 18:39, Christoph Hellwig wrote:
> > On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote:
> >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
> >> software-discoverable and the only thing described in DT is the bus "host",
> >> thus we need the same sort of thing as for PCI to map from the child
> >> devices back to the bus root in order to find the appropriate firmware
> >> node. Worse than PCI, though, we wouldn't even have the option of
> >> describing child devices statically in firmware at all, since it's actually
> >> one of these runtime-configurable "build your own network accelerator"
> >> hardware pools where userspace gets to create and destroy "devices" as it
> >> likes.
> >
> > I really hate the PCI special case just as much.  Maybe we just
> > need a dma_configure method on the bus, and move PCI as well as fsl-mc
> > to it.
> 
> Hmm, on reflection, 100% ack to that idea. It would neatly supersede
> bus->force_dma *and* mean that we don't have to effectively pull pci.h
> into everything, which I've never liked. In hindsight dma_configure()
> does feel like it's grown into this odd choke point where we munge
> everything in just for it to awkwardly unpick things again.
> 
> Robin.

+1 to the idea.

Sorry for asking a trivial question - looking into dma_configure() I see that
PCI is used in the start and the end of the API.
In the end part pci_put_host_bridge_device() is called.
So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
will be required where the former one will return "dma_dev"?

Regards,
Nipun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, March 05, 2018 21:07
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com;
> mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: iommu@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> m.szyprow...@samsung.com; gre...@linuxfoundation.org; j...@8bytes.org;
> Leo Li <leoyang...@nxp.com>; shawn...@kernel.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; Bharat Bhushan
> <bharat.bhus...@nxp.com>; stuyo...@gmail.com; Laurentiu Tudor
> <laurentiu.tu...@nxp.com>
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 15:00, Nipun Gupta wrote:
> >
> >
> >> -Original Message-
> >> From: Robin Murphy [mailto:robin.mur...@arm.com]
> >> Sent: Monday, March 05, 2018 20:23
> >> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com;
> >> mark.rutl...@arm.com; catalin.mari...@arm.com
> >> Cc: iommu@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> >> m.szyprow...@samsung.com; gre...@linuxfoundation.org;
> j...@8bytes.org;
> >> Leo Li <leoyang...@nxp.com>; shawn...@kernel.org; linux-
> >> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> >> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; Bharat Bhushan
> >> <bharat.bhus...@nxp.com>; stuyo...@gmail.com; Laurentiu Tudor
> >> <laurentiu.tu...@nxp.com>
> >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree
> binding
> >>
> >> On 05/03/18 14:29, Nipun Gupta wrote:
> >>> The existing IOMMU bindings cannot be used to specify the relationship
> >>> between fsl-mc devices and IOMMUs. This patch adds a binding for
> >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >>
> >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> >> backward-compatibility bodge full of hard-coded assumptions, why would
> >> we want to knowingly introduce a similarly unpleasant equivalent for
> >> IOMMUs? What's wrong with "iommu-map"?
> >
> > Hi Robin,
> >
> > With 'msi-parent' the property is fixed up to have msi-map. In this case 
> > there is
> > no fixup required and simple 'iommu-parent' property can be used, with MC
> bus
> > itself providing the stream-id's (in the code execution via FW).
> >
> > We can also use the iommu-map property similar to PCI, which will require u-
> boot
> > fixup. But then it leads to little bit complications of u-boot - kernel
> compatibility.
> 
> What needs fixing up? With a stream-map-mask in place to ignore the
> upper Stream ID bits, you just need:
> 
>   iommu-map = <0  0 0x80>;
> 
> to say that the lower bits of the ICID value map directly to the lower
> bits of the Stream ID value - that's the same fixed property of the
> hardware that you're wanting to assume in iommu-parent.

Makes sense. I was going in a little bit wrong direction. Thanks for correcting.
I will send v2 patchset with iommu-map property.

Regards,
Nipun

> 
> > If you suggest we can re-use the iommu-map property. What is your opinion?
> 
> I think it makes a lot more sense to directly use the property which
> already exists, than to introduce a new one to merely assume one
> hard-coded value of the existing one. Extending msi-parent to msi-map
> was a case of "oops, it turns out we need more flexibility here"; for
> the case of iommu-map I can't imagine any justification for saying
> "oops, we need less flexibility here" (saving 9 whole bytes in the DT
> really is irrelevant).
> 
> Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, March 05, 2018 20:23
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com;
> mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: iommu@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> m.szyprow...@samsung.com; gre...@linuxfoundation.org; j...@8bytes.org;
> Leo Li <leoyang...@nxp.com>; shawn...@kernel.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; Bharat Bhushan
> <bharat.bhus...@nxp.com>; stuyo...@gmail.com; Laurentiu Tudor
> <laurentiu.tu...@nxp.com>
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 14:29, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> backward-compatibility bodge full of hard-coded assumptions, why would
> we want to knowingly introduce a similarly unpleasant equivalent for
> IOMMUs? What's wrong with "iommu-map"?

Hi Robin,

With 'msi-parent' the property is fixed up to have msi-map. In this case there 
is
no fixup required and simple 'iommu-parent' property can be used, with MC bus
itself providing the stream-id's (in the code execution via FW).

We can also use the iommu-map property similar to PCI, which will require u-boot
fixup. But then it leads to little bit complications of u-boot - kernel 
compatibility.

If you suggest we can re-use the iommu-map property. What is your opinion?

Thanks,
Nipun

> 
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >   .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31
> ++
> >   1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >   such as network interfaces, crypto accelerator instances, L2 switches,
> >   etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> 
> IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know
> they're currently documented under bindings/pci, but they're not really
> intended to be absolutely PCI-specific.
> 
> Robin.
> 
> > +The generic 'iommus' property is cannot be used to describe the 
> > relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >   Required properties:
> >
> >   - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> > Value type: 
> > Definition: Specifies the phandle to the PHY device node 
> > associated
> > with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> >
> >   Example:
> >
> > +smmu: iommu@500 {
> > +   compatible = "arm,mmu-500";
> > +   #iommu-cells = <1>;
> > +   stream-match-mask = <0x7C00>;
> > +   ...
> > +};
> > +
> >   fsl_mc: fsl-mc@80c00 {
> >   compatible = "fsl,qoriq-mc";
> >   reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
> > base */
> > <0x 0x0834 0 0x4>; /* MC control 
> > reg */
> >   msi-parent = <>;
> > +iommu-parent = <>;
> >   #address-cells = <3>;
> >   #size-cells = <1>;
> >
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/base/dma-mapping.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
  * Common configuration to enable DMA API use for a device
  */
 #include 
+#include 
 
 int dma_configure(struct device *dev)
 {
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
dma_dev = dma_dev->parent;
}
 
+   if (dev_is_fsl_mc(dev)) {
+   dma_dev = dev;
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+   }
+
if (dma_dev->of_node) {
ret = of_dma_configure(dev, dma_dev->of_node);
} else if (has_acpi_companion(dma_dev)) {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-parent = <>;
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   stream-match-mask = <0x7C00>;
+   dma-coherent;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver

[Nipun Gupta]

The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/6] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/of_iommu.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+ struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec;
+   int err;
+
+   iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+   if (!iommu_spec.np)
+   return NO_IOMMU;
+
+   iommu_spec.args[0] = mc_dev->icid;
+   iommu_spec.args_count = 1;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +106,27 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+  The property specifies the IOMMU behind which the devices on
+  fsl-mc bus are residing.
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+iommu-parent = <>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

These patches
  - Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3)
  - Adds the dma-mapping support for fsl-mc bus (patch 4,5)
  - Updates the fsl-mc device node with iommu/dma related changes

This patchset is based on staging-testing tree where fsl-mc bus is out
from staging

This patchset is dependent on patch 
https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-parent device-tree binding
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: remove dma ops setup from driver
  dma-mapping: support fsl-mc bus
  dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31 ++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |  6 -
 drivers/base/dma-mapping.c |  7 +
 drivers/bus/fsl-mc/fsl-mc-bus.c|  5 +---
 drivers/iommu/arm-smmu.c   |  7 +
 drivers/iommu/iommu.c  | 21 +++
 drivers/iommu/of_iommu.c   | 23 
 include/linux/fsl/mc.h |  8 ++
 include/linux/iommu.h  |  2 ++
 9 files changed, 105 insertions(+), 5 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property

[Nipun Gupta]

Thanks Robin,
This would be of great help.

Regards,
Nipun

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, March 02, 2017 22:18
> To: Nipun Gupta <nipun.gu...@nxp.com>; iommu@lists.linux-foundation.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Cc: mark.rutl...@arm.com; will.dea...@arm.com; stuyo...@gmail.com;
> Bharat Bhushan <bharat.bhus...@nxp.com>
> Subject: Re: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
> 
> On 02/03/17 04:18, Nipun Gupta wrote:
> >
> > Hi Robin/Will,
> >
> > This patch is currently not applied on the tree.
> > I had verified the patch and it seems good.
> > Is ack required on the patch or do I need to send a non RFC patch (with 
> > Robin's
> signoff)?
> > This is very much required to support SMMU on NXP platform.
> 
> It's still sat in my "patches to do something with" queue - I don't
> think we ever reached a concrete decision on the property name for a DT
> maintainer ack, but I've tweaked the description per Will's comment;
> thanks for the reminder. I'll send an rc1-based version out next week to
> reboot the discussion.
> 
> Robin.
> 
> >
> > Thanks,
> > Nipun
> >
> >
> >> -Original Message-
> >> From: Nipun Gupta
> >> Sent: Sunday, December 18, 2016 2:37
> >> To: Robin Murphy <robin.mur...@arm.com>; iommu@lists.linux-
> >> foundation.org; devicet...@vger.kernel.org; linux-arm-
> >> ker...@lists.infradead.org
> >> Cc: mark.rutl...@arm.com; will.dea...@arm.com; Stuart Yoder
> >> <stuart.yo...@nxp.com>
> >> Subject: RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking
> property
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> >>> boun...@lists.linux-foundation.org] On Behalf Of Robin Murphy
> >>> Sent: Friday, December 16, 2016 18:49
> >>> To: iommu@lists.linux-foundation.org; devicet...@vger.kernel.org; linux-
> >> arm-
> >>> ker...@lists.infradead.org
> >>> Cc: mark.rutl...@arm.com; will.dea...@arm.com; Stuart Yoder
> >>> <stuart.yo...@nxp.com>
> >>> Subject: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
> >>>
> >>> The current SMR masking support using a 2-cell iommu-specifier is
> >>> primarily intended to handle individual masters with large and/or
> >>> complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> >>> use-cases where we just want to consistently mask out the same part of
> >>> every Stream ID (e.g. for MMU-500 configurations where the appended TBU
> >>> number gets in the way unnecessarily). Let's add a new property to allow
> >>> a single global mask value to better fit the latter situation.
> >>>
> >>> CC: Stuart Yoder <stuart.yo...@nxp.com>
> >>
> >> Tested-by: Nipun Gupta <nipun.gu...@nxp.com>
> >>
> >>> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> >>> ---
> >>>
> >>> Compile-tested only...
> >>>
> >>>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 
> >>>  drivers/iommu/arm-smmu.c | 4 +++-
> >>>  2 files changed, 11 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>> index e862d1485205..98f5cbe5fdb4 100644
> >>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>> @@ -60,6 +60,14 @@ conditions.
> >>>aliases of secure registers have to be used during
> >>>SMMU configuration.
> >>>
> >>> +- stream-match-mask : Specifies a fixed SMR mask value to combine with
> >>> +  the Stream ID value from every iommu-specifier. This
> >>> +  may be used instead of an "#iommu-cells" value of 2
> >>> +  when there is no need for per-master SMR masks, but
> >>> +  it is still desired to mask some portion of every
> >>> +  Stream ID (e.g. for certain MMU-500 configurations
> >>> +  given globally unique external IDs).
> >

RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property

[Nipun Gupta]

Hi Robin/Will,

This patch is currently not applied on the tree.
I had verified the patch and it seems good.
Is ack required on the patch or do I need to send a non RFC patch (with Robin's 
signoff)?
This is very much required to support SMMU on NXP platform.

Thanks,
Nipun


> -Original Message-
> From: Nipun Gupta
> Sent: Sunday, December 18, 2016 2:37
> To: Robin Murphy <robin.mur...@arm.com>; iommu@lists.linux-
> foundation.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Cc: mark.rutl...@arm.com; will.dea...@arm.com; Stuart Yoder
> <stuart.yo...@nxp.com>
> Subject: RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
> 
> 
> 
> > -Original Message-
> > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> > boun...@lists.linux-foundation.org] On Behalf Of Robin Murphy
> > Sent: Friday, December 16, 2016 18:49
> > To: iommu@lists.linux-foundation.org; devicet...@vger.kernel.org; linux-
> arm-
> > ker...@lists.infradead.org
> > Cc: mark.rutl...@arm.com; will.dea...@arm.com; Stuart Yoder
> > <stuart.yo...@nxp.com>
> > Subject: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
> >
> > The current SMR masking support using a 2-cell iommu-specifier is
> > primarily intended to handle individual masters with large and/or
> > complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> > use-cases where we just want to consistently mask out the same part of
> > every Stream ID (e.g. for MMU-500 configurations where the appended TBU
> > number gets in the way unnecessarily). Let's add a new property to allow
> > a single global mask value to better fit the latter situation.
> >
> > CC: Stuart Yoder <stuart.yo...@nxp.com>
> 
> Tested-by: Nipun Gupta <nipun.gu...@nxp.com>
> 
> > Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> > ---
> >
> > Compile-tested only...
> >
> >  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 
> >  drivers/iommu/arm-smmu.c | 4 +++-
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index e862d1485205..98f5cbe5fdb4 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -60,6 +60,14 @@ conditions.
> >aliases of secure registers have to be used during
> >SMMU configuration.
> >
> > +- stream-match-mask : Specifies a fixed SMR mask value to combine with
> > +  the Stream ID value from every iommu-specifier. This
> > +  may be used instead of an "#iommu-cells" value of 2
> > +  when there is no need for per-master SMR masks, but
> > +  it is still desired to mask some portion of every
> > +  Stream ID (e.g. for certain MMU-500 configurations
> > +  given globally unique external IDs).
> > +
> >  ** Deprecated properties:
> >
> >  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 8f7281444551..f1abcb7dde36 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -1534,13 +1534,15 @@ static int arm_smmu_domain_set_attr(struct
> > iommu_domain *domain,
> >
> >  static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args
> *args)
> >  {
> > -   u32 fwid = 0;
> > +   u32 mask, fwid = 0;
> >
> > if (args->args_count > 0)
> > fwid |= (u16)args->args[0];
> >
> > if (args->args_count > 1)
> > fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
> > +   else if (!of_property_read_u32(args->np, "stream-match-mask",
> > ))
> > +   fwid |= (u16)mask << SMR_MASK_SHIFT;
> >
> > return iommu_fwspec_add_ids(dev, , 1);
> >  }
> > --
> > 2.10.2.dirty
> >
> > ___
> > iommu mailing list
> > iommu@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property

[Nipun Gupta]

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Robin Murphy
> Sent: Friday, December 16, 2016 18:49
> To: iommu@lists.linux-foundation.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Cc: mark.rutl...@arm.com; will.dea...@arm.com; Stuart Yoder
> <stuart.yo...@nxp.com>
> Subject: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
> 
> The current SMR masking support using a 2-cell iommu-specifier is
> primarily intended to handle individual masters with large and/or
> complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> use-cases where we just want to consistently mask out the same part of
> every Stream ID (e.g. for MMU-500 configurations where the appended TBU
> number gets in the way unnecessarily). Let's add a new property to allow
> a single global mask value to better fit the latter situation.
> 
> CC: Stuart Yoder <stuart.yo...@nxp.com>

Tested-by: Nipun Gupta <nipun.gu...@nxp.com>

> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> ---
> 
> Compile-tested only...
> 
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 
>  drivers/iommu/arm-smmu.c | 4 +++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index e862d1485205..98f5cbe5fdb4 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -60,6 +60,14 @@ conditions.
>aliases of secure registers have to be used during
>SMMU configuration.
> 
> +- stream-match-mask : Specifies a fixed SMR mask value to combine with
> +  the Stream ID value from every iommu-specifier. This
> +  may be used instead of an "#iommu-cells" value of 2
> +  when there is no need for per-master SMR masks, but
> +  it is still desired to mask some portion of every
> +  Stream ID (e.g. for certain MMU-500 configurations
> +  given globally unique external IDs).
> +
>  ** Deprecated properties:
> 
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f7281444551..f1abcb7dde36 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1534,13 +1534,15 @@ static int arm_smmu_domain_set_attr(struct
> iommu_domain *domain,
> 
>  static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args 
> *args)
>  {
> - u32 fwid = 0;
> + u32 mask, fwid = 0;
> 
>   if (args->args_count > 0)
>   fwid |= (u16)args->args[0];
> 
>   if (args->args_count > 1)
>   fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
> + else if (!of_property_read_u32(args->np, "stream-match-mask",
> ))
> + fwid |= (u16)mask << SMR_MASK_SHIFT;
> 
>   return iommu_fwspec_add_ids(dev, , 1);
>  }
> --
> 2.10.2.dirty
> 
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

[Nipun Gupta]

The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR) provides an
option to enable the updation of TLB in case of bypass transactions due to
no stream match in the stream match table. This reduces the latencies of
the subsequent transactions with the same stream-id which bypasses the SMMU.
This provides a significant performance benefit for certain networking
workloads.

With this change substantial performance improvement of ~9% is observed with
DPDK l3fwd application 
(http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
on NXP's LS2088a platform.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
Changes for v2:
- Incorporated Robin's comments on v1 related to
Setting SMTNMB_TLBEN in ACR only for MMU-500 as ACR is implementation 
dependent
Code comments and Naming convention
Changes for v3:
- Added correct patch version

 drivers/iommu/arm-smmu.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ce2a9d4..05901be 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -247,6 +247,7 @@ enum arm_smmu_s2cr_privcfg {
 #define ARM_MMU500_ACTLR_CPRE  (1 << 1)
 
 #define ARM_MMU500_ACR_CACHE_LOCK  (1 << 26)
+#define ARM_MMU500_ACR_SMTNMB_TLBEN(1 << 8)
 
 #define CB_PAR_F   (1 << 0)
 
@@ -1569,16 +1570,22 @@ static void arm_smmu_device_reset(struct 
arm_smmu_device *smmu)
for (i = 0; i < smmu->num_mapping_groups; ++i)
arm_smmu_write_sme(smmu, i);
 
-   /*
-* Before clearing ARM_MMU500_ACTLR_CPRE, need to
-* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
-* bit is only present in MMU-500r2 onwards.
-*/
-   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
-   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
-   if ((smmu->model == ARM_MMU500) && (major >= 2)) {
+   if (smmu->model == ARM_MMU500) {
+   /*
+* Before clearing ARM_MMU500_ACTLR_CPRE, need to
+* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
+* bit is only present in MMU-500r2 onwards.
+*/
+   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
+   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
-   reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+   if (major >= 2)
+   reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+   /*
+* Allow unmatched Stream IDs to allocate bypass
+* TLB entries for reduced latency.
+*/
+   reg |= ARM_MMU500_ACR_SMTNMB_TLBEN;
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
}
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

[Nipun Gupta]

> -Original Message-
> From: Stuart Yoder
> Sent: Friday, November 04, 2016 2:27
> To: Nipun Gupta <nipun.gu...@nxp.com>; robin.mur...@arm.com;
> will.dea...@arm.com; linux-arm-ker...@lists.infradead.org;
> iommu@lists.linux-foundation.org
> Cc: Nipun Gupta <nipun.gu...@nxp.com>
> Subject: RE: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> caching of bypass entries
> 
> 
> 
> > -Original Message-
> > From: Nipun Gupta [mailto:nipun.gu...@nxp.com]
> > Sent: Thursday, November 03, 2016 7:27 PM
> > To: robin.mur...@arm.com; will.dea...@arm.com;
> > linux-arm-ker...@lists.infradead.org; iommu@lists.linux-
> > foundation.org
> > Cc: Stuart Yoder <stuart.yo...@nxp.com>; Nipun Gupta
> > <nipun.gu...@nxp.com>
> > Subject: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> > caching of bypass entries
> 
> When you respin a patch, put the version number in the patch subject:
> 
>[PATCH v2] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching
> of bypass entries

I added that first, but in the last moment used git format-patch after minor 
updates
and somehow missed it in the final patch :/. Re-spinning v3 with correct 
version number.

Thanks,
Nipun

> 
> Stuart
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

[Nipun Gupta]

The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR) provides an
option to enable the updation of TLB in case of bypass transactions due to
no stream match in the stream match table. This reduces the latencies of
the subsequent transactions with the same stream-id which bypasses the SMMU.
This provides a significant performance benefit for certain networking
workloads.

With this change substantial performance improvement of ~9% is observed with
DPDK l3fwd application 
(http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
on NXP's LS2088a platform.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
Changes for v2:
- Incorporated Robin's comments on v1 related to
Setting SMTNMB_TLBEN in ACR only for MMU-500 as ACR is implementation 
dependent
Code comments and Naming convention

 drivers/iommu/arm-smmu.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ce2a9d4..05901be 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -247,6 +247,7 @@ enum arm_smmu_s2cr_privcfg {
 #define ARM_MMU500_ACTLR_CPRE  (1 << 1)
 
 #define ARM_MMU500_ACR_CACHE_LOCK  (1 << 26)
+#define ARM_MMU500_ACR_SMTNMB_TLBEN(1 << 8)
 
 #define CB_PAR_F   (1 << 0)
 
@@ -1569,16 +1570,22 @@ static void arm_smmu_device_reset(struct 
arm_smmu_device *smmu)
for (i = 0; i < smmu->num_mapping_groups; ++i)
arm_smmu_write_sme(smmu, i);
 
-   /*
-* Before clearing ARM_MMU500_ACTLR_CPRE, need to
-* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
-* bit is only present in MMU-500r2 onwards.
-*/
-   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
-   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
-   if ((smmu->model == ARM_MMU500) && (major >= 2)) {
+   if (smmu->model == ARM_MMU500) {
+   /*
+* Before clearing ARM_MMU500_ACTLR_CPRE, need to
+* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
+* bit is only present in MMU-500r2 onwards.
+*/
+   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
+   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
-   reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+   if (major >= 2)
+   reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+   /*
+* Allow unmatched Stream IDs to allocate bypass
+* TLB entries for reduced latency.
+*/
+   reg |= ARM_MMU500_ACR_SMTNMB_TLBEN;
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
}
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

[Nipun Gupta]

Hi Robin,

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, November 03, 2016 16:39
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; linux-arm-
> ker...@lists.infradead.org; iommu@lists.linux-foundation.org
> Cc: Stuart Yoder <stuart.yo...@nxp.com>
> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> caching of bypass entries
> 
> On 02/11/16 19:26, Nipun Gupta wrote:
> >
> > Hi Robin,
> >
> >> -Original Message-
> >> From: Robin Murphy [mailto:robin.mur...@arm.com]
> >> Sent: Wednesday, November 02, 2016 16:51
> >> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; linux-arm-
> >> ker...@lists.infradead.org; iommu@lists.linux-foundation.org
> >> Cc: Stuart Yoder <stuart.yo...@nxp.com>
> >> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to
> enable
> >> caching of bypass entries
> >>
> >> Hi Nipun,
> >>
> >> On 02/11/16 13:35, Nipun Gupta wrote:
> >>> The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR)
> >>> provides an option to enable the updation of TLB in case of bypass
> >>> transactions due to no stream match in the stream match table. This
> >>> reduces the latencies of the subsequent transactions with the same stream-
> id
> >> which bypasses the SMMU.
> >>> This provides a significant performance benefit for certain networking
> >>> workloads.
> >>
> >> ...at the cost of increased TLB contention against other workloads.
> >> However, in the general case we'd expect the system to be fully described, 
> >> so
> if
> >> there aren't any unmatched Stream IDs there hopefully shouldn't be an
> impact
> >> to leaving this switched on. I'd be interested to see some actual 
> >> performance
> >> numbers, though - you already know my opinion about unsubstantiated
> quotes
> >> from the MMU-500 TRM.
> >
> > With this change we have seen substantial performance improvement of ~9-
> 10%
> > with DPDK l3fwd application
> (http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
> > on NXP's LS2088a platform (single core as well as multi-core). Also, with 
> > ODP
> reflector application
> > (loopback mode - NXP in-house) we have seen 5% improvement in
> performance on
> > LS1088 platform.
> >
> > W.r.t. the read latencies, they are reduced to avg. ~50 platform cycles from
> avg. ~140
> > platform cycles per memory read transactions which follow this bypass path
> (on LS2088
> > with DPDK l3fwd application).
> >
> > (Apologies, I cannot share the DPDK/ODP exact performance numbers on the
> mailing list).
> 
> That's understandable, and I'm not sure I'd know how to interpret them
> anyway ;) I reckon the percentages make a sufficiently compelling
> qualification of the improvement, so it would be good to have that
> summarised in the commit log.

Sure, I'll add a part of it in the commit log.

> 
> >>
> >>> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> >>> ---
> >>>  drivers/iommu/arm-smmu.c | 21 +++--
> >>>  1 file changed, 15 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> >>> ce2a9d4..7010a5c 100644
> >>> --- a/drivers/iommu/arm-smmu.c
> >>> +++ b/drivers/iommu/arm-smmu.c
> >>> @@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
> >>>
> >>>  #define ARM_MMU500_ACTLR_CPRE(1 << 1)
> >>>
> >>> +#define ACR_SMTNMB_TLBEN (1 << 8)
> >>
> >> ACR is entirely implementation-defined, so there are no generic field 
> >> names.
> >> Please follow the naming convention handily demonstrated in the subsequent
> >> context line.
> >>
> >>>  #define ARM_MMU500_ACR_CACHE_LOCK(1 << 26)
> >>
> >> Actually, can we also please keep these in descending order of bit position
> like
> >> everything else?
> >>
> >>>  #define CB_PAR_F (1 << 0)
> >>> @@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct
> >> arm_smmu_device *smmu)
> >>>   for (i = 0; i < smmu->num_mapping_groups; ++i)
> >>>   arm_smmu_write_sme(smmu, i);
> >>>
> >>> + /* Get the major rev required for configuring ACR */
> >

RE: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

[Nipun Gupta]

Hi Robin,

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Wednesday, November 02, 2016 16:51
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; linux-arm-
> ker...@lists.infradead.org; iommu@lists.linux-foundation.org
> Cc: Stuart Yoder <stuart.yo...@nxp.com>
> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> caching of bypass entries
> 
> Hi Nipun,
> 
> On 02/11/16 13:35, Nipun Gupta wrote:
> > The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR)
> > provides an option to enable the updation of TLB in case of bypass
> > transactions due to no stream match in the stream match table. This
> > reduces the latencies of the subsequent transactions with the same stream-id
> which bypasses the SMMU.
> > This provides a significant performance benefit for certain networking
> > workloads.
> 
> ...at the cost of increased TLB contention against other workloads.
> However, in the general case we'd expect the system to be fully described, so 
> if
> there aren't any unmatched Stream IDs there hopefully shouldn't be an impact
> to leaving this switched on. I'd be interested to see some actual performance
> numbers, though - you already know my opinion about unsubstantiated quotes
> from the MMU-500 TRM.

With this change we have seen substantial performance improvement of ~9-10%
with DPDK l3fwd application 
(http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
on NXP's LS2088a platform (single core as well as multi-core). Also, with ODP 
reflector application
(loopback mode - NXP in-house) we have seen 5% improvement in performance on
LS1088 platform.

W.r.t. the read latencies, they are reduced to avg. ~50 platform cycles from 
avg. ~140
platform cycles per memory read transactions which follow this bypass path (on 
LS2088
with DPDK l3fwd application).

(Apologies, I cannot share the DPDK/ODP exact performance numbers on the 
mailing list).

> 
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > ---
> >  drivers/iommu/arm-smmu.c | 21 +++--
> >  1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> > ce2a9d4..7010a5c 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
> >
> >  #define ARM_MMU500_ACTLR_CPRE  (1 << 1)
> >
> > +#define ACR_SMTNMB_TLBEN   (1 << 8)
> 
> ACR is entirely implementation-defined, so there are no generic field names.
> Please follow the naming convention handily demonstrated in the subsequent
> context line.
> 
> >  #define ARM_MMU500_ACR_CACHE_LOCK  (1 << 26)
> 
> Actually, can we also please keep these in descending order of bit position 
> like
> everything else?
> 
> >  #define CB_PAR_F   (1 << 0)
> > @@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct
> arm_smmu_device *smmu)
> > for (i = 0; i < smmu->num_mapping_groups; ++i)
> > arm_smmu_write_sme(smmu, i);
> >
> > +   /* Get the major rev required for configuring ACR */
> 
> That comment is nonsense.
> 
> > +   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> > +   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> > +
> > /*
> >  * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> >  * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> >  * bit is only present in MMU-500r2 onwards.
> >  */
> > -   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> > -   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> > -   if ((smmu->model == ARM_MMU500) && (major >= 2)) {
> > -   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> > +   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> > +   if ((smmu->model == ARM_MMU500) && (major >= 2))
> > reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> > -   writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> > -   }
> > +
> > +   /*
> > +* Set the SMTNMB_TLBEN in ACR so that the transactions which
> > +* bypass with SMMU due to no stream match found in the SMR table
> > +* are updated in the TLB's.
> 
> Or simply, e.g. "Allow unmatched Stream IDs to allocate bypass TLB entries for
> reduced latency". It's already clear from the code what bit's being set 
> where, we
> only need to remember *why*.
> 
> > +*/
> > +   reg |= ACR_SMTNMB_TLBEN;
> > +   writel_

[PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

[Nipun Gupta]

The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR) provides an
option to enable the updation of TLB in case of bypass transactions due to
no stream match in the stream match table. This reduces the latencies of
the subsequent transactions with the same stream-id which bypasses the SMMU.
This provides a significant performance benefit for certain networking
workloads.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
---
 drivers/iommu/arm-smmu.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ce2a9d4..7010a5c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
 
 #define ARM_MMU500_ACTLR_CPRE  (1 << 1)
 
+#define ACR_SMTNMB_TLBEN   (1 << 8)
 #define ARM_MMU500_ACR_CACHE_LOCK  (1 << 26)
 
 #define CB_PAR_F   (1 << 0)
@@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct 
arm_smmu_device *smmu)
for (i = 0; i < smmu->num_mapping_groups; ++i)
arm_smmu_write_sme(smmu, i);
 
+   /* Get the major rev required for configuring ACR */
+   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
+   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
+
/*
 * Before clearing ARM_MMU500_ACTLR_CPRE, need to
 * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
 * bit is only present in MMU-500r2 onwards.
 */
-   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
-   major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
-   if ((smmu->model == ARM_MMU500) && (major >= 2)) {
-   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+   reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+   if ((smmu->model == ARM_MMU500) && (major >= 2))
reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
-   writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
-   }
+
+   /*
+* Set the SMTNMB_TLBEN in ACR so that the transactions which
+* bypass with SMMU due to no stream match found in the SMR table
+* are updated in the TLB's.
+*/
+   reg |= ACR_SMTNMB_TLBEN;
+   writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
 
/* Make sure all context banks are disabled and clear CB_FSR  */
for (i = 0; i < smmu->num_context_banks; ++i) {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Wednesday, October 05, 2016 15:26
> To: Nipun Gupta <nipun.gu...@nxp.com>
> Cc: will.dea...@arm.com; j...@8bytes.org; iommu@lists.linux-
> foundation.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; punit.agra...@arm.com;
> thunder.leiz...@huawei.com
> Subject: Re: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
> 
> On 05/10/16 08:00, Nipun Gupta wrote:
> >
> >
> >> -Original Message-
> >> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> >> boun...@lists.linux-foundation.org] On Behalf Of Robin Murphy
> >> Sent: Monday, September 12, 2016 21:44
> >> To: will.dea...@arm.com; j...@8bytes.org; iommu@lists.linux-
> >> foundation.org; linux-arm-ker...@lists.infradead.org
> >> Cc: devicet...@vger.kernel.org; punit.agra...@arm.com;
> >> thunder.leiz...@huawei.com
> >> Subject: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
> >>
> >> When an MSI doorbell is located downstream of an IOMMU, attaching
> >> devices to a DMA ops domain and switching on translation leads to a
> >> rude shock when their attempt to write to the physical address
> >> returned by the irqchip driver faults (or worse, writes into some
> >> already-mapped
> >> buffer) and no interrupt is forthcoming.
> >>
> >> Address this by adding a hook for relevant irqchip drivers to call
> >> from their
> >> compose_msi_msg() callback, to swizzle the physical address with an
> >> appropriatly-mapped IOVA for any device attached to one of our DMA
> >> ops domains.
> >>
> >> Acked-by: Thomas Gleixner <t...@linutronix.de>
> >> Acked-by: Marc Zyngier <marc.zyng...@arm.com>
> >> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> >> ---
> >>  drivers/iommu/dma-iommu.c| 136
> >> ++-
> >>  drivers/irqchip/irq-gic-v2m.c|   3 +
> >>  drivers/irqchip/irq-gic-v3-its.c |   3 +
> >>  include/linux/dma-iommu.h|   9 +++
> >>  4 files changed, 136 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> >> index 00c8a08d56e7..4329d18080cf 100644
> >> --- a/drivers/iommu/dma-iommu.c
> >> +++ b/drivers/iommu/dma-iommu.c
> >> @@ -25,10 +25,28 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>
> >> +struct iommu_dma_msi_page {
> >> +  struct list_headlist;
> >> +  dma_addr_t  iova;
> >> +  phys_addr_t phys;
> >> +};
> >> +
> >> +struct iommu_dma_cookie {
> >> +  struct iova_domain  iovad;
> >> +  struct list_headmsi_page_list;
> >> +  spinlock_t  msi_lock;
> >> +};
> >> +
> >> +static inline struct iova_domain *cookie_iovad(struct iommu_domain
> >> +*domain) {
> >> +  return &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad; }
> >> +
> >>  int iommu_dma_init(void)
> >>  {
> >>return iova_cache_get();
> >> @@ -43,15 +61,19 @@ int iommu_dma_init(void)
> >>   */
> >>  int iommu_get_dma_cookie(struct iommu_domain *domain)  {
> >> -  struct iova_domain *iovad;
> >> +  struct iommu_dma_cookie *cookie;
> >>
> >>if (domain->iova_cookie)
> >>return -EEXIST;
> >>
> >> -  iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
> >> -  domain->iova_cookie = iovad;
> >> +  cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> >> +  if (!cookie)
> >> +  return -ENOMEM;
> >>
> >> -  return iovad ? 0 : -ENOMEM;
> >> +  spin_lock_init(>msi_lock);
> >> +  INIT_LIST_HEAD(>msi_page_list);
> >> +  domain->iova_cookie = cookie;
> >> +  return 0;
> >>  }
> >>  EXPORT_SYMBOL(iommu_get_dma_cookie);
> >>
> >> @@ -63,14 +85,20 @@ EXPORT_SYMBOL(iommu_get_dma_cookie);
> >>   */
> >>  void iommu_put_dma_cookie(struct iommu_domain *domain)  {
> >> -  struct iova_domain *iovad = domain->iova_cookie;
> >> +  struct iommu_dma_cookie *cookie = domain->iova_cookie;
> >> +  struct iommu_dma_msi_page *msi, *tmp;
> >>
> >> -  if (!iovad)
> >>

RE: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs

[Nipun Gupta]

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Robin Murphy
> Sent: Monday, September 12, 2016 21:44
> To: will.dea...@arm.com; j...@8bytes.org; iommu@lists.linux-
> foundation.org; linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org; punit.agra...@arm.com;
> thunder.leiz...@huawei.com
> Subject: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
> 
> When an MSI doorbell is located downstream of an IOMMU, attaching devices
> to a DMA ops domain and switching on translation leads to a rude shock when
> their attempt to write to the physical address returned by the irqchip driver
> faults (or worse, writes into some already-mapped
> buffer) and no interrupt is forthcoming.
> 
> Address this by adding a hook for relevant irqchip drivers to call from their
> compose_msi_msg() callback, to swizzle the physical address with an
> appropriatly-mapped IOVA for any device attached to one of our DMA ops
> domains.
> 
> Acked-by: Thomas Gleixner 
> Acked-by: Marc Zyngier 
> Signed-off-by: Robin Murphy 
> ---
>  drivers/iommu/dma-iommu.c| 136
> ++-
>  drivers/irqchip/irq-gic-v2m.c|   3 +
>  drivers/irqchip/irq-gic-v3-its.c |   3 +
>  include/linux/dma-iommu.h|   9 +++
>  4 files changed, 136 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index
> 00c8a08d56e7..4329d18080cf 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -25,10 +25,28 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
> +struct iommu_dma_msi_page {
> + struct list_headlist;
> + dma_addr_t  iova;
> + phys_addr_t phys;
> +};
> +
> +struct iommu_dma_cookie {
> + struct iova_domain  iovad;
> + struct list_headmsi_page_list;
> + spinlock_t  msi_lock;
> +};
> +
> +static inline struct iova_domain *cookie_iovad(struct iommu_domain
> +*domain) {
> + return &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad; }
> +
>  int iommu_dma_init(void)
>  {
>   return iova_cache_get();
> @@ -43,15 +61,19 @@ int iommu_dma_init(void)
>   */
>  int iommu_get_dma_cookie(struct iommu_domain *domain)  {
> - struct iova_domain *iovad;
> + struct iommu_dma_cookie *cookie;
> 
>   if (domain->iova_cookie)
>   return -EEXIST;
> 
> - iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
> - domain->iova_cookie = iovad;
> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> + if (!cookie)
> + return -ENOMEM;
> 
> - return iovad ? 0 : -ENOMEM;
> + spin_lock_init(>msi_lock);
> + INIT_LIST_HEAD(>msi_page_list);
> + domain->iova_cookie = cookie;
> + return 0;
>  }
>  EXPORT_SYMBOL(iommu_get_dma_cookie);
> 
> @@ -63,14 +85,20 @@ EXPORT_SYMBOL(iommu_get_dma_cookie);
>   */
>  void iommu_put_dma_cookie(struct iommu_domain *domain)  {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iommu_dma_msi_page *msi, *tmp;
> 
> - if (!iovad)
> + if (!cookie)
>   return;
> 
> - if (iovad->granule)
> - put_iova_domain(iovad);
> - kfree(iovad);
> + if (cookie->iovad.granule)
> + put_iova_domain(>iovad);
> +
> + list_for_each_entry_safe(msi, tmp, >msi_page_list, list) {
> + list_del(>list);
> + kfree(msi);
> + }
> + kfree(cookie);
>   domain->iova_cookie = NULL;
>  }
>  EXPORT_SYMBOL(iommu_put_dma_cookie);
> @@ -88,7 +116,7 @@ EXPORT_SYMBOL(iommu_put_dma_cookie);
>   */
>  int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t
> base, u64 size)  {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
>   unsigned long order, base_pfn, end_pfn;
> 
>   if (!iovad)
> @@ -155,7 +183,7 @@ int dma_direction_to_prot(enum dma_data_direction
> dir, bool coherent)  static struct iova *__alloc_iova(struct iommu_domain
> *domain, size_t size,
>   dma_addr_t dma_limit)
>  {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
>   unsigned long shift = iova_shift(iovad);
>   unsigned long length = iova_align(iovad, size) >> shift;
> 
> @@ -171,7 +199,7 @@ static struct iova *__alloc_iova(struct iommu_domain
> *domain, size_t size,
>  /* The IOVA allocator knows what we mapped, so just unmap whatever that
> was */  static void __iommu_dma_unmap(struct iommu_domain *domain,
> dma_addr_t dma_addr)  {
> - struct iova_domain *iovad = domain->iova_cookie;
> + struct iova_domain *iovad = cookie_iovad(domain);
>   unsigned long shift = iova_shift(iovad);
>  

RE: [RFC PATCH 1/2] fsl-mc: Added header file to provide fsl-mc bus iommu group creation

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, June 30, 2016 19:44
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; Stuart Yoder
> <stuart.yo...@nxp.com>; iommu@lists.linux-foundation.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Bharat Bhushan <bharat.bhus...@nxp.com>
> Subject: Re: [RFC PATCH 1/2] fsl-mc: Added header file to provide fsl-mc bus
> iommu group creation
> 
> On 30/06/16 12:43, Nipun Gupta wrote:
> >
> >
> >> -Original Message-
> >> From: Robin Murphy [mailto:robin.mur...@arm.com]
> >> Sent: Thursday, June 30, 2016 16:26
> >> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; Stuart
> >> Yoder <stuart.yo...@nxp.com>; iommu@lists.linux-foundation.org;
> >> linux-arm- ker...@lists.infradead.org
> >> Cc: Bharat Bhushan <bharat.bhus...@nxp.com>
> >> Subject: Re: [RFC PATCH 1/2] fsl-mc: Added header file to provide
> >> fsl-mc bus iommu group creation
> >>
> >> On 29/06/16 18:14, Nipun Gupta wrote:
> >>> Added a header file fsl_mc_smmu.h to provide basic support of
> >>> creating an IOMMU group for a fsl-mc type device and also provide
> >>> helper macro to get the stream ID of fsl-mc tyoe device.
> >>>
> >>> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> >>> Signed-off-by: Bharat Bhushan <bharat.bhus...@nxp.com>
> >>> ---
> >>>  drivers/staging/fsl-mc/include/fsl_mc_smmu.h | 45
> >>> 
> >>>  1 file changed, 45 insertions(+)
> >>>  create mode 100644 drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> >>>
> >>> diff --git a/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> >>> b/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> >>> new file mode 100644
> >>> index 000..9dff5ba
> >>> --- /dev/null
> >>> +++ b/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> >>> @@ -0,0 +1,45 @@
> >>> +/*
> >>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> >>> + * Author: Nipun Gupta <nipun.gu...@freescale.com>
> >>> + *
> >>> + * This file is licensed under the terms of the GNU General Public
> >>> + * License version 2. This program is licensed "as is" without any
> >>> + * warranty of any kind, whether express or implied.
> >>> + */
> >>> +
> >>> +#ifndef _FSL_MC_SMMU_H_
> >>> +#define _FSL_MC_SMMU_H_
> >>> +
> >>> +#include <../drivers/staging/fsl-mc/include/mc.h>
> >>> +
> >>> +/* Macro to get the MC device ICID (Stream ID) */ #define
> >>> +fslmc_dev_streamid(_dev) (to_fsl_mc_device(_dev)->icid)
> >>
> >> Is the the full 15-bit ICID from the MC's point of view, just the 7
> >> bits that are actually routed to the SMMU, or the actual stream ID
> >> seen by the SMMU? None of those three are necessarily the same, and
> >> unless it's the third then I don't see the point of patches adding 
> >> incomplete
> code which isn't going to work.
> >
> > Hi Robin,
> >
> > It's the second one where just 7 bits are maintained in the 
> > 'fsl_mc_device---
> >icid' which is programmed in SMMU. Right, once the SMR masking support is
> there then only these patches would make more sense.
> > We have sent these patches to get some early comments and to have you guys
> well informed beforehand about the changes which we require in the SMMU
> driver specific to fsl-mc bus :).
> 
> Indeed, it's just kinda hard to review incomplete code, especially when it's 
> the
> parts which don't exist yet which are the most significant ;)
> 
> Either way, I'm deep in the middle of reworking SMMUv2 generic bindings[1]
> based on the latest iteration of the core code and iommu_fwspec[2], which
> removes the need for nearly all the bus-specific business within the driver 
> (it's
> getting too big to be 4.8 material now, but I'll have something to post 
> shortly).
> In that context, if the fsl-mc driver could process an "iommu-map" property on
> the MC node to plumb the ICID-to-stream-ID relationship into of_xlate, and
> inherit bus->iommu_ops from its parent bus, there shouldn't be any need to
> directly touch the SMMU driver at all.

Hi Robin,

One thing I would like to bring to your notice is that with our SoC the 
container devices gets dynamically created by MC (using linux command line). 
Once the container is created, the ICID is

RE: [RFC PATCH 2/2] iommu/arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, June 30, 2016 16:53
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; Stuart Yoder
> <stuart.yo...@nxp.com>; iommu@lists.linux-foundation.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Bharat Bhushan <bharat.bhus...@nxp.com>
> Subject: Re: [RFC PATCH 2/2] iommu/arm-smmu: Add support for the fsl-mc bus
> 
> On 29/06/16 18:14, Nipun Gupta wrote:
> > Implement bus specific support for the fsl-mc bus including
> > registering the arm_smmu_ops and bus specific smmu device init.
> >
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > Signed-off-by: Bharat Bhushan <bharat.bhus...@nxp.com>
> > ---
> >  drivers/iommu/arm-smmu.c | 43
> > +++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> > ab365ec..28d5dc8 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -47,6 +47,9 @@
> >
> >  #include 
> >
> > +/* Include path will be changed once FSL-MC support is out from
> > +staging */
> 
> How about we do that first?

Agree. We are working on that part :)

> 
> > +#include <../drivers/staging/fsl-mc/include/fsl_mc_smmu.h>
> > +
> >  #include "io-pgtable.h"
> >
> >  /* Maximum number of stream IDs assigned to a single device */ @@
> > -447,6 +450,11 @@ static struct device_node *dev_get_dev_node(struct
> device *dev)
> > return bus->bridge->parent->of_node;
> > }
> >
> > +   if (dev_is_fsl_mc(dev)) {
> 
> Where is dev_is_fsl_mc() defined? I don't see it anywhere in mainline, here, 
> or in
> -next.

My Bad. We have provided a patch on the de...@driverdev.osuosl.org ; 
linux-ker...@vger.kernel.org to have the macro dev_is_fsl_mc defined. Please 
see the attached patch.

> 
> > +   while (dev_is_fsl_mc(dev))
> > +   dev = dev->parent;
> > +   }
> > +
> > return dev->of_node;
> >  }
> >
> > @@ -1443,6 +1451,32 @@ static int arm_smmu_init_platform_device(struct
> device *dev,
> > return 0;
> >  }
> >
> > +static void __arm_smmu_release_fslmc_iommudata(void *data) {
> > +   kfree(data);
> > +}
> 
> There's already a suitable callback for this; nobody needs an exact duplicate 
> of
> it.

I see '__arm_smmu_release_pci_iommudata' similarly defined for PCI bus.
We will probably need it renaming to '__arm_smmu_release_iommudata' to have a 
better readable code. Seems okay?

> 
> > +static int arm_smmu_init_fslmc_device(struct device *dev,
> > + struct iommu_group *group)
> > +{
> > +   struct arm_smmu_master_cfg *cfg;
> > +
> > +   cfg = iommu_group_get_iommudata(group);
> > +   if (!cfg) {
> > +   cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
> > +   if (!cfg)
> > +   return -ENOMEM;
> > +
> > +   cfg->streamids[0] = fslmc_dev_streamid(dev);
> > +   cfg->num_streamids = 1;
> > +
> > +   iommu_group_set_iommudata(group, cfg,
> > +
> __arm_smmu_release_fslmc_iommudata);
> > +   }
> 
> So the group gets the ID of the container device (assuming that's the first 
> one
> added), and the subsequent IDs are just ignored and left to go wrong? Or is it
> inherently guaranteed that all devices in the same container are programmed
> with the same ID?

Yeah latter one is correct!! Each container is associated with an ID which is 
common for all the devices. Container device gets added first and is 
responsible for creating the iommu group and the master CFG.

Thanks,
Nipun

> 
> Robin.
> 
> > +   return 0;
> > +}
> > +
> >  static int arm_smmu_add_device(struct device *dev)  {
> > struct iommu_group *group;
> > @@ -1467,6 +1501,8 @@ static struct iommu_group
> > *arm_smmu_device_group(struct device *dev)
> >
> > if (dev_is_pci(dev))
> > group = pci_device_group(dev);
> > +   else if (dev_is_fsl_mc(dev))
> > +   group = fslmc_device_group(dev);
> > else
> > group = generic_device_group(dev);
> >
> > @@ -1475,6 +1511,8 @@ static struct iommu_group
> > *arm_smmu_device_group(struct device *dev)
> >
> > if (dev_is_pci(dev))
> > ret = arm_smmu_init_pci_device(to_pci_dev(dev), group);
> > +   else if (dev_is_fsl_mc(dev))
> > +   

RE: [RFC PATCH 1/2] fsl-mc: Added header file to provide fsl-mc bus iommu group creation

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, June 30, 2016 16:26
> To: Nipun Gupta <nipun.gu...@nxp.com>; will.dea...@arm.com; Stuart Yoder
> <stuart.yo...@nxp.com>; iommu@lists.linux-foundation.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Bharat Bhushan <bharat.bhus...@nxp.com>
> Subject: Re: [RFC PATCH 1/2] fsl-mc: Added header file to provide fsl-mc bus
> iommu group creation
> 
> On 29/06/16 18:14, Nipun Gupta wrote:
> > Added a header file fsl_mc_smmu.h to provide basic support of creating
> > an IOMMU group for a fsl-mc type device and also provide helper macro
> > to get the stream ID of fsl-mc tyoe device.
> >
> > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> > Signed-off-by: Bharat Bhushan <bharat.bhus...@nxp.com>
> > ---
> >  drivers/staging/fsl-mc/include/fsl_mc_smmu.h | 45
> > 
> >  1 file changed, 45 insertions(+)
> >  create mode 100644 drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> >
> > diff --git a/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> > b/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> > new file mode 100644
> > index 000..9dff5ba
> > --- /dev/null
> > +++ b/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
> > @@ -0,0 +1,45 @@
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Author: Nipun Gupta <nipun.gu...@freescale.com>
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2. This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + */
> > +
> > +#ifndef _FSL_MC_SMMU_H_
> > +#define _FSL_MC_SMMU_H_
> > +
> > +#include <../drivers/staging/fsl-mc/include/mc.h>
> > +
> > +/* Macro to get the MC device ICID (Stream ID) */ #define
> > +fslmc_dev_streamid(_dev) (to_fsl_mc_device(_dev)->icid)
> 
> Is the the full 15-bit ICID from the MC's point of view, just the 7 bits that 
> are
> actually routed to the SMMU, or the actual stream ID seen by the SMMU? None
> of those three are necessarily the same, and unless it's the third then I 
> don't see
> the point of patches adding incomplete code which isn't going to work.

Hi Robin,

It's the second one where just 7 bits are maintained in the 
'fsl_mc_device--->icid' which is programmed in SMMU. Right, once the SMR 
masking support is there then only these patches would make more sense. 
We have sent these patches to get some early comments and to have you guys well 
informed beforehand about the changes which we require in the SMMU driver 
specific to fsl-mc bus :).

Thanks,
Nipun

> 
> > +/* Macro to get the container device of a MC device */ #define
> > +fslmc_cont_dev(_dev) ((to_fsl_mc_device(dev)->flags & \
> > +   FSL_MC_IS_DPRC) ? (_dev) : (_dev->parent))
> > +
> > +/* Macro to check if a device is a container device */ #define
> > +is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & FSL_MC_IS_DPRC)
> > +
> > +static struct iommu_group *fslmc_device_group(struct device *dev) {
> > +   struct device *cont_dev = fslmc_cont_dev(dev);
> > +   struct iommu_group *group;
> > +
> > +   /* Container device is responsible for creating the iommu group */
> > +   if (is_cont_dev(dev)) {
> > +   group = iommu_group_alloc();
> > +
> > +   if (IS_ERR(group))
> > +   return NULL;
> > +   } else {
> > +   get_device(cont_dev);
> > +   group = iommu_group_get(cont_dev);
> > +   put_device(cont_dev);
> > +   }
> > +
> > +   return group;
> > +}
> 
> In isolation, though, this part seems perfectly reasonable.
> 
> Robin.
> 
> > +
> > +#endif /* _FSL_MC_SMMU_H_ */
> >

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RFC PATCH 2/2] iommu/arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering the arm_smmu_ops and bus specific smmu device init.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Signed-off-by: Bharat Bhushan <bharat.bhus...@nxp.com>
---
 drivers/iommu/arm-smmu.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ab365ec..28d5dc8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -47,6 +47,9 @@
 
 #include 
 
+/* Include path will be changed once FSL-MC support is out from staging */
+#include <../drivers/staging/fsl-mc/include/fsl_mc_smmu.h>
+
 #include "io-pgtable.h"
 
 /* Maximum number of stream IDs assigned to a single device */
@@ -447,6 +450,11 @@ static struct device_node *dev_get_dev_node(struct device 
*dev)
return bus->bridge->parent->of_node;
}
 
+   if (dev_is_fsl_mc(dev)) {
+   while (dev_is_fsl_mc(dev))
+   dev = dev->parent;
+   }
+
return dev->of_node;
 }
 
@@ -1443,6 +1451,32 @@ static int arm_smmu_init_platform_device(struct device 
*dev,
return 0;
 }
 
+static void __arm_smmu_release_fslmc_iommudata(void *data)
+{
+   kfree(data);
+}
+
+static int arm_smmu_init_fslmc_device(struct device *dev,
+ struct iommu_group *group)
+{
+   struct arm_smmu_master_cfg *cfg;
+
+   cfg = iommu_group_get_iommudata(group);
+   if (!cfg) {
+   cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
+   if (!cfg)
+   return -ENOMEM;
+
+   cfg->streamids[0] = fslmc_dev_streamid(dev);
+   cfg->num_streamids = 1;
+
+   iommu_group_set_iommudata(group, cfg,
+ __arm_smmu_release_fslmc_iommudata);
+   }
+
+   return 0;
+}
+
 static int arm_smmu_add_device(struct device *dev)
 {
struct iommu_group *group;
@@ -1467,6 +1501,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fslmc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -1475,6 +1511,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
ret = arm_smmu_init_pci_device(to_pci_dev(dev), group);
+   else if (dev_is_fsl_mc(dev))
+   ret = arm_smmu_init_fslmc_device(dev, group);
else
ret = arm_smmu_init_platform_device(dev, group);
 
@@ -2102,6 +2140,11 @@ static int __init arm_smmu_init(void)
}
 #endif
 
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
+
return 0;
 }
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RFC PATCH 1/2] fsl-mc: Added header file to provide fsl-mc bus iommu group creation

[Nipun Gupta]

Added a header file fsl_mc_smmu.h to provide basic support of creating
an IOMMU group for a fsl-mc type device and also provide helper macro
to get the stream ID of fsl-mc tyoe device.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Signed-off-by: Bharat Bhushan <bharat.bhus...@nxp.com>
---
 drivers/staging/fsl-mc/include/fsl_mc_smmu.h | 45 
 1 file changed, 45 insertions(+)
 create mode 100644 drivers/staging/fsl-mc/include/fsl_mc_smmu.h

diff --git a/drivers/staging/fsl-mc/include/fsl_mc_smmu.h 
b/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
new file mode 100644
index 000..9dff5ba
--- /dev/null
+++ b/drivers/staging/fsl-mc/include/fsl_mc_smmu.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Nipun Gupta <nipun.gu...@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _FSL_MC_SMMU_H_
+#define _FSL_MC_SMMU_H_
+
+#include <../drivers/staging/fsl-mc/include/mc.h>
+
+/* Macro to get the MC device ICID (Stream ID) */
+#define fslmc_dev_streamid(_dev) (to_fsl_mc_device(_dev)->icid)
+
+/* Macro to get the container device of a MC device */
+#define fslmc_cont_dev(_dev) ((to_fsl_mc_device(dev)->flags & \
+   FSL_MC_IS_DPRC) ? (_dev) : (_dev->parent))
+
+/* Macro to check if a device is a container device */
+#define is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & FSL_MC_IS_DPRC)
+
+static struct iommu_group *fslmc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fslmc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
+#endif /* _FSL_MC_SMMU_H_ */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu