[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

Here is an updated v3 of the series. Series introduces support for setting up
dma parameters based on device tree properties like 'dma-ranges' and
'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
series can be found here [3], [2] and [1].

The 'dma-ranges' helps to take care of few DMAable system memory restrictions
by use of dma_pfn_offset which we maintain now per device. Arch code then
uses it for dma address translations for such cases. We update the
dma_pfn_offset accordingly during DT the device creation process.The
'dma-coherent' property is used to setup arch's coherent dma_ops.

Hopefully with acks, tested-by this version can get into 3.16 queue. I will
post a followup series for Keystone SOC which will use this infrastructure.
Linus W also wants to use this for ARM integrator platform dma offset issue.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>

Grygorii Strashko (2):
  of: introduce of_dma_get_range() helper
  ARM: dma: Use dma_pfn_offset for dma address translation

Santosh Shilimkar (5):
  device: introduce per device dma_pfn_offset
  of: introduce of_dma_is_coherent() helper
  of: configure the platform device dma parameters
  ARM: dma: implement set_arch_dma_coherent_ops()
  ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]

 arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
 arch/arm/mm/dma-mapping.c          |    4 +-
 drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
 drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
 include/linux/device.h             |    2 +
 include/linux/dma-mapping.h        |    7 +++
 include/linux/of_address.h         |    8 ++++
 include/linux/of_platform.h        |    6 +++
 8 files changed, 204 insertions(+), 9 deletions(-)

Regards,
Santosh

[1] http://www.spinics.net/lists/arm-kernel/msg311678.html
[2] https://lkml.org/lkml/2014/3/6/186
[3] https://lkml.org/lkml/2014/4/19/80
-- 
1.7.9.5

[PATCH v3 1/7] device: introduce per device dma_pfn_offset

[Santosh Shilimkar]

On few architectures, there are few restrictions on DMAble area of system
RAM. That also means that devices needs to know about this restrictions so
that the dma_masks can be updated accordingly and dma address translation
helpers can add/subtract the dma offset.

In most of cases DMA addresses can be performed using offset value of
Bus address space relatively to physical address space as following:

PFN->DMA:  __pfn_to_phys(pfn + [-]dma_pfn_offset)
DMA->PFN:  __phys_to_pfn(dma_addr) + [-]dma_pfn_offset

So we introduce per device dma_pfn_offset which can be popullated
by architecture init code while creating the devices.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 include/linux/device.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index 233bbbe..85a52d6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -691,6 +691,7 @@ struct acpi_dev_node {
  * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
  * 		hardware supports 64-bit addresses for consistent allocations
  * 		such descriptors.
+ * @dma_pfn_offset: offset of DMA memory range relatively of RAM
  * @dma_parms:	A low level driver may set these to teach IOMMU code about
  * 		segment limitations.
  * @dma_pools:	Dma pools (if dma'ble device).
@@ -756,6 +757,7 @@ struct device {
 					     not all hardware supports
 					     64 bit addresses for consistent
 					     allocations such descriptors. */
+	unsigned long	dma_pfn_offset;
 
 	struct device_dma_parameters *dma_parms;
 
-- 
1.7.9.5

[PATCH v3 1/7] device: introduce per device dma_pfn_offset

[Rob Herring]

On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On few architectures, there are few restrictions on DMAble area of system
> RAM. That also means that devices needs to know about this restrictions so
> that the dma_masks can be updated accordingly and dma address translation
> helpers can add/subtract the dma offset.
>
> In most of cases DMA addresses can be performed using offset value of
> Bus address space relatively to physical address space as following:
>
> PFN->DMA:  __pfn_to_phys(pfn + [-]dma_pfn_offset)
> DMA->PFN:  __phys_to_pfn(dma_addr) + [-]dma_pfn_offset
>
> So we introduce per device dma_pfn_offset which can be popullated
> by architecture init code while creating the devices.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Reviewed-by: Rob Herring <robh@kernel.org>

Rob

> ---
>  include/linux/device.h |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 233bbbe..85a52d6 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -691,6 +691,7 @@ struct acpi_dev_node {
>   * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
>   *             hardware supports 64-bit addresses for consistent allocations
>   *             such descriptors.
> + * @dma_pfn_offset: offset of DMA memory range relatively of RAM
>   * @dma_parms: A low level driver may set these to teach IOMMU code about
>   *             segment limitations.
>   * @dma_pools: Dma pools (if dma'ble device).
> @@ -756,6 +757,7 @@ struct device {
>                                              not all hardware supports
>                                              64 bit addresses for consistent
>                                              allocations such descriptors. */
> +       unsigned long   dma_pfn_offset;
>
>         struct device_dma_parameters *dma_parms;
>
> --
> 1.7.9.5
>

[PATCH v3 2/7] of: introduce of_dma_get_range() helper

[Santosh Shilimkar]

From: Grygorii Strashko <grygorii.strashko@ti.com>

The of_dma_get_range() allows to find "dma-range" property for
the specified device and parse it.
 dma-ranges format:
   DMA addr (dma_addr)          : naddr cells
   CPU addr (phys_addr_t)       : pna cells
   size                         : nsize cells

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/of/address.c       |   87 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h |    8 ++++
 2 files changed, 95 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..c54baee 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -721,3 +721,90 @@ void __iomem *of_iomap(struct device_node *np, int index)
 	return ioremap(res.start, resource_size(&res));
 }
 EXPORT_SYMBOL(of_iomap);
+
+/**
+ * of_dma_get_range - Get DMA range info
+ * @np:		device node to get DMA range info
+ * @dma_addr:	pointer to store initial DMA address of DMA range
+ * @paddr:	pointer to store initial CPU address of DMA range
+ * @size:	pointer to store size of DMA range
+ *
+ * Look in bottom up direction for the first "dma-ranges" property
+ * and parse it.
+ *  dma-ranges format:
+ *	DMA addr (dma_addr)	: naddr cells
+ *	CPU addr (phys_addr_t)	: pna cells
+ *	size			: nsize cells
+ *
+ * It returns -ENODEV if "dma-ranges" property was not found
+ * for this device in DT.
+ */
+int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+{
+	struct device_node *node = of_node_get(np);
+	const __be32 *ranges = NULL;
+	int len, naddr, nsize, pna;
+	int ret = 0;
+	u64 dmaaddr;
+
+	if (!node)
+		return -EINVAL;
+
+	while (1) {
+		naddr = of_n_addr_cells(node);
+		nsize = of_n_size_cells(node);
+		node = of_get_next_parent(node);
+		if (!node)
+			break;
+
+		ranges = of_get_property(node, "dma-ranges", &len);
+
+		/* Ignore empty ranges, they imply no translation required */
+		if (ranges && len > 0)
+			break;
+
+		/*
+		 * At least empty ranges has to be defined for parent node if
+		 * DMA is supported
+		 */
+		if (!ranges)
+			break;
+	}
+
+	if (!ranges) {
+		pr_debug("%s: no dma-ranges found for node(%s)\n",
+			 __func__, np->full_name);
+		ret = -ENODEV;
+		goto out;
+	}
+
+	len /= sizeof(u32);
+
+	pna = of_n_addr_cells(node);
+
+	/* dma-ranges format:
+	 * DMA addr	: naddr cells
+	 * CPU addr	: pna cells
+	 * size		: nsize cells
+	 */
+	dmaaddr = of_read_number(ranges, naddr);
+	*paddr = of_translate_dma_address(np, ranges);
+	if (*paddr == OF_BAD_ADDR) {
+		pr_err("%s: translation of DMA address(%pad) to CPU address failed node(%s)\n",
+		       __func__, dma_addr, np->full_name);
+		ret = -EINVAL;
+		goto out;
+	}
+	*dma_addr = dmaaddr;
+
+	*size = of_read_number(ranges + naddr + pna, nsize);
+
+	pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+		 *dma_addr, *paddr, *size);
+
+out:
+	of_node_put(node);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_get_range);
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 5f6ed6b..4d7b325 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -63,6 +63,8 @@ extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 extern struct of_pci_range *of_pci_range_parser_one(
 					struct of_pci_range_parser *parser,
 					struct of_pci_range *range);
+extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
+				u64 *paddr, u64 *size);
 #else /* CONFIG_OF_ADDRESS */
 static inline struct device_node *of_find_matching_node_by_address(
 					struct device_node *from,
@@ -90,6 +92,12 @@ static inline struct of_pci_range *of_pci_range_parser_one(
 {
 	return NULL;
 }
+
+static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
+				u64 *paddr, u64 *size)
+{
+	return -ENODEV;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_OF
-- 
1.7.9.5

[PATCH v3 2/7] of: introduce of_dma_get_range() helper

[Rob Herring]

On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> The of_dma_get_range() allows to find "dma-range" property for
> the specified device and parse it.
>  dma-ranges format:
>    DMA addr (dma_addr)          : naddr cells
>    CPU addr (phys_addr_t)       : pna cells
>    size                         : nsize cells
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Reviewed-by: Rob Herring <robh@kernel.org>

> ---
>  drivers/of/address.c       |   87 ++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |    8 ++++
>  2 files changed, 95 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index cb4242a..c54baee 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -721,3 +721,90 @@ void __iomem *of_iomap(struct device_node *np, int index)
>         return ioremap(res.start, resource_size(&res));
>  }
>  EXPORT_SYMBOL(of_iomap);
> +
> +/**
> + * of_dma_get_range - Get DMA range info
> + * @np:                device node to get DMA range info
> + * @dma_addr:  pointer to store initial DMA address of DMA range
> + * @paddr:     pointer to store initial CPU address of DMA range
> + * @size:      pointer to store size of DMA range
> + *
> + * Look in bottom up direction for the first "dma-ranges" property
> + * and parse it.
> + *  dma-ranges format:
> + *     DMA addr (dma_addr)     : naddr cells
> + *     CPU addr (phys_addr_t)  : pna cells
> + *     size                    : nsize cells
> + *
> + * It returns -ENODEV if "dma-ranges" property was not found
> + * for this device in DT.
> + */
> +int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
> +{
> +       struct device_node *node = of_node_get(np);
> +       const __be32 *ranges = NULL;
> +       int len, naddr, nsize, pna;
> +       int ret = 0;
> +       u64 dmaaddr;
> +
> +       if (!node)
> +               return -EINVAL;
> +
> +       while (1) {
> +               naddr = of_n_addr_cells(node);
> +               nsize = of_n_size_cells(node);
> +               node = of_get_next_parent(node);
> +               if (!node)
> +                       break;
> +
> +               ranges = of_get_property(node, "dma-ranges", &len);
> +
> +               /* Ignore empty ranges, they imply no translation required */
> +               if (ranges && len > 0)
> +                       break;
> +
> +               /*
> +                * At least empty ranges has to be defined for parent node if
> +                * DMA is supported
> +                */
> +               if (!ranges)
> +                       break;
> +       }
> +
> +       if (!ranges) {
> +               pr_debug("%s: no dma-ranges found for node(%s)\n",
> +                        __func__, np->full_name);
> +               ret = -ENODEV;
> +               goto out;
> +       }
> +
> +       len /= sizeof(u32);
> +
> +       pna = of_n_addr_cells(node);
> +
> +       /* dma-ranges format:
> +        * DMA addr     : naddr cells
> +        * CPU addr     : pna cells
> +        * size         : nsize cells
> +        */
> +       dmaaddr = of_read_number(ranges, naddr);
> +       *paddr = of_translate_dma_address(np, ranges);
> +       if (*paddr == OF_BAD_ADDR) {
> +               pr_err("%s: translation of DMA address(%pad) to CPU address failed node(%s)\n",
> +                      __func__, dma_addr, np->full_name);
> +               ret = -EINVAL;
> +               goto out;
> +       }
> +       *dma_addr = dmaaddr;
> +
> +       *size = of_read_number(ranges + naddr + pna, nsize);
> +
> +       pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> +                *dma_addr, *paddr, *size);
> +
> +out:
> +       of_node_put(node);
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_dma_get_range);
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 5f6ed6b..4d7b325 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -63,6 +63,8 @@ extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>  extern struct of_pci_range *of_pci_range_parser_one(
>                                         struct of_pci_range_parser *parser,
>                                         struct of_pci_range *range);
> +extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
> +                               u64 *paddr, u64 *size);
>  #else /* CONFIG_OF_ADDRESS */
>  static inline struct device_node *of_find_matching_node_by_address(
>                                         struct device_node *from,
> @@ -90,6 +92,12 @@ static inline struct of_pci_range *of_pci_range_parser_one(
>  {
>         return NULL;
>  }
> +
> +static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
> +                               u64 *paddr, u64 *size)
> +{
> +       return -ENODEV;
> +}
>  #endif /* CONFIG_OF_ADDRESS */
>
>  #ifdef CONFIG_OF
> --
> 1.7.9.5
>

[PATCH v3 3/7] of: introduce of_dma_is_coherent() helper

[Santosh Shilimkar]

The of_dma_is_coherent() helper parses the given DT device
node to see if the "dma-coherent" property is supported and
returns true or false accordingly.

If the arch is always coherent or always noncoherent, then the default
DMA ops has to be specified accordingly.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 drivers/of/platform.c       |   23 +++++++++++++++++++++++
 include/linux/of_platform.h |    6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..48de98f 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -485,4 +485,27 @@ int of_platform_populate(struct device_node *root,
 	return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_dma_is_coherent - Check if device is coherent
+ * @np:	device node
+ *
+ * It returns true if "dma-coherent" property was found
+ * for this device in DT.
+ */
+bool of_dma_is_coherent(struct device_node *np)
+{
+	struct device_node *node = of_node_get(np);
+
+	while (node) {
+		if (of_property_read_bool(node, "dma-coherent")) {
+			of_node_put(node);
+			return true;
+		}
+		node = of_get_next_parent(node);
+	}
+	of_node_put(node);
+	return false;
+}
+EXPORT_SYMBOL_GPL(of_dma_is_coherent);
 #endif /* CONFIG_OF_ADDRESS */
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 05cb4a9..b9a3cb2 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,7 @@ extern int of_platform_populate(struct device_node *root,
 				const struct of_device_id *matches,
 				const struct of_dev_auxdata *lookup,
 				struct device *parent);
+extern bool of_dma_is_coherent(struct device_node *np);
 #else
 static inline int of_platform_populate(struct device_node *root,
 					const struct of_device_id *matches,
@@ -80,6 +81,11 @@ static inline int of_platform_populate(struct device_node *root,
 {
 	return -ENODEV;
 }
+
+static inline bool of_dma_is_coherent(struct device_node *np)
+{
+	return false;
+}
 #endif
 
 #endif	/* _LINUX_OF_PLATFORM_H */
-- 
1.7.9.5

[PATCH v3 3/7] of: introduce of_dma_is_coherent() helper

[Rob Herring]

On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> The of_dma_is_coherent() helper parses the given DT device
> node to see if the "dma-coherent" property is supported and
> returns true or false accordingly.
>
> If the arch is always coherent or always noncoherent, then the default
> DMA ops has to be specified accordingly.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
>  drivers/of/platform.c       |   23 +++++++++++++++++++++++
>  include/linux/of_platform.h |    6 ++++++

I thought I said this already, but this does not belong in these files
as the function does not deal with platform devices. Probably
address.c/of_address.h would be the best place.

Rob

>  2 files changed, 29 insertions(+)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 404d1da..48de98f 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -485,4 +485,27 @@ int of_platform_populate(struct device_node *root,
>         return rc;
>  }
>  EXPORT_SYMBOL_GPL(of_platform_populate);
> +
> +/**
> + * of_dma_is_coherent - Check if device is coherent
> + * @np:        device node
> + *
> + * It returns true if "dma-coherent" property was found
> + * for this device in DT.
> + */
> +bool of_dma_is_coherent(struct device_node *np)
> +{
> +       struct device_node *node = of_node_get(np);
> +
> +       while (node) {
> +               if (of_property_read_bool(node, "dma-coherent")) {
> +                       of_node_put(node);
> +                       return true;
> +               }
> +               node = of_get_next_parent(node);
> +       }
> +       of_node_put(node);
> +       return false;
> +}
> +EXPORT_SYMBOL_GPL(of_dma_is_coherent);
>  #endif /* CONFIG_OF_ADDRESS */
> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
> index 05cb4a9..b9a3cb2 100644
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -72,6 +72,7 @@ extern int of_platform_populate(struct device_node *root,
>                                 const struct of_device_id *matches,
>                                 const struct of_dev_auxdata *lookup,
>                                 struct device *parent);
> +extern bool of_dma_is_coherent(struct device_node *np);
>  #else
>  static inline int of_platform_populate(struct device_node *root,
>                                         const struct of_device_id *matches,
> @@ -80,6 +81,11 @@ static inline int of_platform_populate(struct device_node *root,
>  {
>         return -ENODEV;
>  }
> +
> +static inline bool of_dma_is_coherent(struct device_node *np)
> +{
> +       return false;
> +}
>  #endif
>
>  #endif /* _LINUX_OF_PLATFORM_H */
> --
> 1.7.9.5
>

[PATCH v3 3/7] of: introduce of_dma_is_coherent() helper

[Santosh Shilimkar]

On Thursday 01 May 2014 08:56 PM, Rob Herring wrote:
> On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> The of_dma_is_coherent() helper parses the given DT device
>> node to see if the "dma-coherent" property is supported and
>> returns true or false accordingly.
>>
>> If the arch is always coherent or always noncoherent, then the default
>> DMA ops has to be specified accordingly.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Olof Johansson <olof@lixom.net>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>>  drivers/of/platform.c       |   23 +++++++++++++++++++++++
>>  include/linux/of_platform.h |    6 ++++++
> 
> I thought I said this already, but this does not belong in these files
> as the function does not deal with platform devices. Probably
> address.c/of_address.h would be the best place.
> 
Updated patch with functions now moved to of_address.h/address.c

>From 08fb70715afe4adf203d24f1737dba7123c6713b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 24 Apr 2014 11:30:03 -0400
Subject: [PATCH v3 3/7] of: introduce of_dma_is_coherent() helper

The of_dma_is_coherent() helper parses the given DT device
node to see if the "dma-coherent" property is supported and
returns true or false accordingly.

If the arch is always coherent or always noncoherent, then the default
DMA ops has to be specified accordingly.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 drivers/of/address.c       |   23 +++++++++++++++++++++++
 include/linux/of_address.h |    6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index c54baee..d244b28 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -808,3 +808,26 @@ out:
 	return ret;
 }
 EXPORT_SYMBOL_GPL(of_dma_get_range);
+
+/**
+ * of_dma_is_coherent - Check if device is coherent
+ * @np:	device node
+ *
+ * It returns true if "dma-coherent" property was found
+ * for this device in DT.
+ */
+bool of_dma_is_coherent(struct device_node *np)
+{
+	struct device_node *node = of_node_get(np);
+
+	while (node) {
+		if (of_property_read_bool(node, "dma-coherent")) {
+			of_node_put(node);
+			return true;
+		}
+		node = of_get_next_parent(node);
+	}
+	of_node_put(node);
+	return false;
+}
+EXPORT_SYMBOL_GPL(of_dma_is_coherent);
\ No newline at end of file
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 4d7b325..839a352 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -65,6 +65,7 @@ extern struct of_pci_range *of_pci_range_parser_one(
 					struct of_pci_range *range);
 extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
 				u64 *paddr, u64 *size);
+extern bool of_dma_is_coherent(struct device_node *np);
 #else /* CONFIG_OF_ADDRESS */
 static inline struct device_node *of_find_matching_node_by_address(
 					struct device_node *from,
@@ -98,6 +99,11 @@ static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
 {
 	return -ENODEV;
 }
+
+static inline bool of_dma_is_coherent(struct device_node *np)
+{
+	return false;
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_OF
-- 
1.7.9.5

[PATCH v3 3/7] of: introduce of_dma_is_coherent() helper

[Rob Herring]

On Mon, May 5, 2014 at 4:45 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Thursday 01 May 2014 08:56 PM, Rob Herring wrote:
>> On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:

>>>  drivers/of/platform.c       |   23 +++++++++++++++++++++++
>>>  include/linux/of_platform.h |    6 ++++++
>>
>> I thought I said this already, but this does not belong in these files
>> as the function does not deal with platform devices. Probably
>> address.c/of_address.h would be the best place.
>>
> Updated patch with functions now moved to of_address.h/address.c
>
> From 08fb70715afe4adf203d24f1737dba7123c6713b Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Thu, 24 Apr 2014 11:30:03 -0400
> Subject: [PATCH v3 3/7] of: introduce of_dma_is_coherent() helper
>
> The of_dma_is_coherent() helper parses the given DT device
> node to see if the "dma-coherent" property is supported and
> returns true or false accordingly.
>
> If the arch is always coherent or always noncoherent, then the default
> DMA ops has to be specified accordingly.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
>  drivers/of/address.c       |   23 +++++++++++++++++++++++
>  include/linux/of_address.h |    6 ++++++
>  2 files changed, 29 insertions(+)

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

Retrieve DMA configuration from DT and setup platform device's DMA
parameters. The DMA configuration in DT has to be specified using
"dma-ranges" and "dma-coherent" properties if supported.

We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
using "dma-coherent" device tree properties.

The set_arch_dma_coherent_ops macro has to be defined by arch if
it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
declared as nop.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/of/platform.c       |   48 ++++++++++++++++++++++++++++++++++++++++---
 include/linux/dma-mapping.h |    7 +++++++
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 48de98f..270c0b9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -187,6 +187,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_dma_configure - Setup DMA configuration
+ * @dev:	Device to apply DMA configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * In case if platform code need to use own special DMA configuration,it
+ * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
+ * to fix up DMA configuration.
+ */
+static void of_dma_configure(struct device *dev)
+{
+	u64 dma_addr, paddr, size;
+	int ret;
+
+	dev->coherent_dma_mask = DMA_BIT_MASK(32);
+	if (!dev->dma_mask)
+		dev->dma_mask = &dev->coherent_dma_mask;
+
+	/*
+	 * if dma-coherent property exist, call arch hook to setup
+	 * dma coherent operations.
+	 */
+	if (of_dma_is_coherent(dev->of_node)) {
+		set_arch_dma_coherent_ops(dev);
+		dev_dbg(dev, "device is dma coherent\n");
+	}
+
+	/*
+	 * if dma-ranges property doesn't exist - just return else
+	 * setup the dma offset
+	 */
+	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
+	if ((ret == -ENODEV) || (ret < 0)) {
+		dev_dbg(dev, "no dma range information to setup\n");
+		return;
+	}
+
+	/* DMA ranges found. Calculate and set dma_pfn_offset */
+	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
+	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -214,9 +258,7 @@ static struct platform_device *of_platform_device_create_pdata(
 #if defined(CONFIG_MICROBLAZE)
 	dev->archdata.dma_mask = 0xffffffffUL;
 #endif
-	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-	if (!dev->dev.dma_mask)
-		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+	of_dma_configure(&dev->dev);
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index fd4aee2..c7d9b1b 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -123,6 +123,13 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 
 extern u64 dma_get_required_mask(struct device *dev);
 
+#ifndef set_arch_dma_coherent_ops
+static inline int set_arch_dma_coherent_ops(struct device *dev)
+{
+	return 0;
+}
+#endif
+
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
 {
 	return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
-- 
1.7.9.5

[PATCH v3 4/7] of: configure the platform device dma parameters

[Grant Likely]

On Thu, 24 Apr 2014 11:30:04 -0400, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> Retrieve DMA configuration from DT and setup platform device's DMA
> parameters. The DMA configuration in DT has to be specified using
> "dma-ranges" and "dma-coherent" properties if supported.
> 
> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
> using "dma-coherent" device tree properties.
> 
> The set_arch_dma_coherent_ops macro has to be defined by arch if
> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
> declared as nop.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  drivers/of/platform.c       |   48 ++++++++++++++++++++++++++++++++++++++++---
>  include/linux/dma-mapping.h |    7 +++++++
>  2 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 48de98f..270c0b9 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -187,6 +187,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  EXPORT_SYMBOL(of_device_alloc);
>  
>  /**
> + * of_dma_configure - Setup DMA configuration
> + * @dev:	Device to apply DMA configuration
> + *
> + * Try to get devices's DMA configuration from DT and update it
> + * accordingly.
> + *
> + * In case if platform code need to use own special DMA configuration,it
> + * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
> + * to fix up DMA configuration.
> + */
> +static void of_dma_configure(struct device *dev)
> +{
> +	u64 dma_addr, paddr, size;
> +	int ret;
> +
> +	dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +	if (!dev->dma_mask)
> +		dev->dma_mask = &dev->coherent_dma_mask;
> +
> +	/*
> +	 * if dma-coherent property exist, call arch hook to setup
> +	 * dma coherent operations.
> +	 */
> +	if (of_dma_is_coherent(dev->of_node)) {
> +		set_arch_dma_coherent_ops(dev);
> +		dev_dbg(dev, "device is dma coherent\n");
> +	}
> +
> +	/*
> +	 * if dma-ranges property doesn't exist - just return else
> +	 * setup the dma offset
> +	 */
> +	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> +	if ((ret == -ENODEV) || (ret < 0)) {
> +		dev_dbg(dev, "no dma range information to setup\n");
> +		return;
> +	}
> +
> +	/* DMA ranges found. Calculate and set dma_pfn_offset */
> +	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);

I've got two concerns here. of_dma_get_range() retrieves only the first
tuple from the dma-ranges property, but it is perfectly valid for
dma-ranges to contain multiple tuples. How should we handle it if a
device has multiple ranges it can DMA from?

Second, while the pfn offset is being determined, I don't see anything
making use of either the base address or size. How is the device
constrained to only getting DMA buffers from within that range? Is the
driver expected to manage that directly?

g.

> +}
> +
> +/**
>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>   * @np: pointer to node to create device for
>   * @bus_id: name to assign device
> @@ -214,9 +258,7 @@ static struct platform_device *of_platform_device_create_pdata(
>  #if defined(CONFIG_MICROBLAZE)
>  	dev->archdata.dma_mask = 0xffffffffUL;
>  #endif
> -	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> -	if (!dev->dev.dma_mask)
> -		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> +	of_dma_configure(&dev->dev);
>  	dev->dev.bus = &platform_bus_type;
>  	dev->dev.platform_data = platform_data;
>  
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index fd4aee2..c7d9b1b 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -123,6 +123,13 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
>  
>  extern u64 dma_get_required_mask(struct device *dev);
>  
> +#ifndef set_arch_dma_coherent_ops
> +static inline int set_arch_dma_coherent_ops(struct device *dev)
> +{
> +	return 0;
> +}
> +#endif
> +
>  static inline unsigned int dma_get_max_seg_size(struct device *dev)
>  {
>  	return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
> -- 
> 1.7.9.5
> 

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

Hi Grant,

On Tuesday 29 April 2014 10:41 AM, Grant Likely wrote:
> On Thu, 24 Apr 2014 11:30:04 -0400, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> Retrieve DMA configuration from DT and setup platform device's DMA
>> parameters. The DMA configuration in DT has to be specified using
>> "dma-ranges" and "dma-coherent" properties if supported.
>>
>> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
>> using "dma-coherent" device tree properties.
>>
>> The set_arch_dma_coherent_ops macro has to be defined by arch if
>> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
>> declared as nop.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Olof Johansson <olof@lixom.net>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>>  drivers/of/platform.c       |   48 ++++++++++++++++++++++++++++++++++++++++---
>>  include/linux/dma-mapping.h |    7 +++++++
>>  2 files changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 48de98f..270c0b9 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -187,6 +187,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>>  EXPORT_SYMBOL(of_device_alloc);
>>  
>>  /**
>> + * of_dma_configure - Setup DMA configuration
>> + * @dev:	Device to apply DMA configuration
>> + *
>> + * Try to get devices's DMA configuration from DT and update it
>> + * accordingly.
>> + *
>> + * In case if platform code need to use own special DMA configuration,it
>> + * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
>> + * to fix up DMA configuration.
>> + */
>> +static void of_dma_configure(struct device *dev)
>> +{
>> +	u64 dma_addr, paddr, size;
>> +	int ret;
>> +
>> +	dev->coherent_dma_mask = DMA_BIT_MASK(32);
>> +	if (!dev->dma_mask)
>> +		dev->dma_mask = &dev->coherent_dma_mask;
>> +
>> +	/*
>> +	 * if dma-coherent property exist, call arch hook to setup
>> +	 * dma coherent operations.
>> +	 */
>> +	if (of_dma_is_coherent(dev->of_node)) {
>> +		set_arch_dma_coherent_ops(dev);
>> +		dev_dbg(dev, "device is dma coherent\n");
>> +	}
>> +
>> +	/*
>> +	 * if dma-ranges property doesn't exist - just return else
>> +	 * setup the dma offset
>> +	 */
>> +	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>> +	if ((ret == -ENODEV) || (ret < 0)) {
>> +		dev_dbg(dev, "no dma range information to setup\n");
>> +		return;
>> +	}
>> +
>> +	/* DMA ranges found. Calculate and set dma_pfn_offset */
>> +	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> +	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> 
> I've got two concerns here. of_dma_get_range() retrieves only the first
> tuple from the dma-ranges property, but it is perfectly valid for
> dma-ranges to contain multiple tuples. How should we handle it if a
> device has multiple ranges it can DMA from?
> 

We've not found any cases in current Linux where more than one dma-ranges
would be used. Moreover, The MM (definitely for ARM) isn't supported such
cases at all (if i understand everything right).
- there are only one arm_dma_pfn_limit
- there is only one MM zone is used for ARM
- some arches like x86,mips can support 2 zones (per arch - not per device or bus)
  DMA & DMA32, but they configured once and forever per arch.

Example:
static void *loongson_dma_alloc_coherent(struct device *dev, size_t size,
		dma_addr_t *dma_handle, gfp_t gfp, struct dma_attrs *attrs)
{
...

	/* ignore region specifiers */
	gfp &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);

#ifdef CONFIG_ISA
	if (dev == NULL)
		gfp |= __GFP_DMA;
	else
#endif
#ifdef CONFIG_ZONE_DMA
	if (dev->coherent_dma_mask < DMA_BIT_MASK(32))
		gfp |= __GFP_DMA;
	else
#endif
#ifdef CONFIG_ZONE_DMA32
	if (dev->coherent_dma_mask < DMA_BIT_MASK(40))
		gfp |= __GFP_DMA32;
	else
#endif
...
}

Any ways, it can be added later if we have an usecase for
that.

> Second, while the pfn offset is being determined, I don't see anything
> making use of either the base address or size. How is the device
> constrained to only getting DMA buffers from within that range? Is the
> driver expected to manage that directly?
> 
Drivers don't have to do anything special apart from setting
the correct mask. The pfn_offset case, we use DMA_ZONE which takes
care of masks already. Size is suppose to be used for dma_mask
setup which we discussed in previous threads.

Regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Grant Likely]

On Wed, 30 Apr 2014 10:19:15 -0400, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> Hi Grant,
> 
> On Tuesday 29 April 2014 10:41 AM, Grant Likely wrote:
> > On Thu, 24 Apr 2014 11:30:04 -0400, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> >> Retrieve DMA configuration from DT and setup platform device's DMA
> >> parameters. The DMA configuration in DT has to be specified using
> >> "dma-ranges" and "dma-coherent" properties if supported.
> >>
> >> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
> >> using "dma-coherent" device tree properties.
> >>
> >> The set_arch_dma_coherent_ops macro has to be defined by arch if
> >> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
> >> declared as nop.
> >>
> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Cc: Russell King <linux@arm.linux.org.uk>
> >> Cc: Arnd Bergmann <arnd@arndb.de>
> >> Cc: Olof Johansson <olof@lixom.net>
> >> Cc: Grant Likely <grant.likely@linaro.org>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Linus Walleij <linus.walleij@linaro.org>
> >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> ---
> >>  drivers/of/platform.c       |   48 ++++++++++++++++++++++++++++++++++++++++---
> >>  include/linux/dma-mapping.h |    7 +++++++
> >>  2 files changed, 52 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >> index 48de98f..270c0b9 100644
> >> --- a/drivers/of/platform.c
> >> +++ b/drivers/of/platform.c
> >> @@ -187,6 +187,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
> >>  EXPORT_SYMBOL(of_device_alloc);
> >>  
> >>  /**
> >> + * of_dma_configure - Setup DMA configuration
> >> + * @dev:	Device to apply DMA configuration
> >> + *
> >> + * Try to get devices's DMA configuration from DT and update it
> >> + * accordingly.
> >> + *
> >> + * In case if platform code need to use own special DMA configuration,it
> >> + * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
> >> + * to fix up DMA configuration.
> >> + */
> >> +static void of_dma_configure(struct device *dev)
> >> +{
> >> +	u64 dma_addr, paddr, size;
> >> +	int ret;
> >> +
> >> +	dev->coherent_dma_mask = DMA_BIT_MASK(32);
> >> +	if (!dev->dma_mask)
> >> +		dev->dma_mask = &dev->coherent_dma_mask;
> >> +
> >> +	/*
> >> +	 * if dma-coherent property exist, call arch hook to setup
> >> +	 * dma coherent operations.
> >> +	 */
> >> +	if (of_dma_is_coherent(dev->of_node)) {
> >> +		set_arch_dma_coherent_ops(dev);
> >> +		dev_dbg(dev, "device is dma coherent\n");
> >> +	}
> >> +
> >> +	/*
> >> +	 * if dma-ranges property doesn't exist - just return else
> >> +	 * setup the dma offset
> >> +	 */
> >> +	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> >> +	if ((ret == -ENODEV) || (ret < 0)) {
> >> +		dev_dbg(dev, "no dma range information to setup\n");
> >> +		return;
> >> +	}
> >> +
> >> +	/* DMA ranges found. Calculate and set dma_pfn_offset */
> >> +	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> >> +	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> > 
> > I've got two concerns here. of_dma_get_range() retrieves only the first
> > tuple from the dma-ranges property, but it is perfectly valid for
> > dma-ranges to contain multiple tuples. How should we handle it if a
> > device has multiple ranges it can DMA from?
> > 
> 
> We've not found any cases in current Linux where more than one dma-ranges
> would be used. Moreover, The MM (definitely for ARM) isn't supported such
> cases at all (if i understand everything right).
> - there are only one arm_dma_pfn_limit
> - there is only one MM zone is used for ARM
> - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
>   DMA & DMA32, but they configured once and forever per arch.

Okay. If anyone ever does implement multiple ranges then this code will
need to be revisited.

> > Second, while the pfn offset is being determined, I don't see anything
> > making use of either the base address or size. How is the device
> > constrained to only getting DMA buffers from within that range? Is the
> > driver expected to manage that directly?
> > 
> Drivers don't have to do anything special apart from setting
> the correct mask. The pfn_offset case, we use DMA_ZONE which takes
> care of masks already. Size is suppose to be used for dma_mask
> setup which we discussed in previous threads.

okay.

g.

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Thursday 01 May 2014 09:12 AM, Grant Likely wrote:
> On Wed, 30 Apr 2014 10:19:15 -0400, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> Hi Grant,
>>
>> On Tuesday 29 April 2014 10:41 AM, Grant Likely wrote:
>>> On Thu, 24 Apr 2014 11:30:04 -0400, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>>>> Retrieve DMA configuration from DT and setup platform device's DMA
>>>> parameters. The DMA configuration in DT has to be specified using
>>>> "dma-ranges" and "dma-coherent" properties if supported.
>>>>
>>>> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
>>>> using "dma-coherent" device tree properties.
>>>>
>>>> The set_arch_dma_coherent_ops macro has to be defined by arch if
>>>> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
>>>> declared as nop.
>>>>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>> Cc: Olof Johansson <olof@lixom.net>
>>>> Cc: Grant Likely <grant.likely@linaro.org>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> ---
>>>>  drivers/of/platform.c       |   48 ++++++++++++++++++++++++++++++++++++++++---
>>>>  include/linux/dma-mapping.h |    7 +++++++
>>>>  2 files changed, 52 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>>> index 48de98f..270c0b9 100644
>>>> --- a/drivers/of/platform.c
>>>> +++ b/drivers/of/platform.c
>>>> @@ -187,6 +187,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>>>>  EXPORT_SYMBOL(of_device_alloc);
>>>>  
>>>>  /**
>>>> + * of_dma_configure - Setup DMA configuration
>>>> + * @dev:	Device to apply DMA configuration
>>>> + *
>>>> + * Try to get devices's DMA configuration from DT and update it
>>>> + * accordingly.
>>>> + *
>>>> + * In case if platform code need to use own special DMA configuration,it
>>>> + * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
>>>> + * to fix up DMA configuration.
>>>> + */
>>>> +static void of_dma_configure(struct device *dev)
>>>> +{
>>>> +	u64 dma_addr, paddr, size;
>>>> +	int ret;
>>>> +
>>>> +	dev->coherent_dma_mask = DMA_BIT_MASK(32);
>>>> +	if (!dev->dma_mask)
>>>> +		dev->dma_mask = &dev->coherent_dma_mask;
>>>> +
>>>> +	/*
>>>> +	 * if dma-coherent property exist, call arch hook to setup
>>>> +	 * dma coherent operations.
>>>> +	 */
>>>> +	if (of_dma_is_coherent(dev->of_node)) {
>>>> +		set_arch_dma_coherent_ops(dev);
>>>> +		dev_dbg(dev, "device is dma coherent\n");
>>>> +	}
>>>> +
>>>> +	/*
>>>> +	 * if dma-ranges property doesn't exist - just return else
>>>> +	 * setup the dma offset
>>>> +	 */
>>>> +	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>>>> +	if ((ret == -ENODEV) || (ret < 0)) {
>>>> +		dev_dbg(dev, "no dma range information to setup\n");
>>>> +		return;
>>>> +	}
>>>> +
>>>> +	/* DMA ranges found. Calculate and set dma_pfn_offset */
>>>> +	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>>>> +	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
>>>
>>> I've got two concerns here. of_dma_get_range() retrieves only the first
>>> tuple from the dma-ranges property, but it is perfectly valid for
>>> dma-ranges to contain multiple tuples. How should we handle it if a
>>> device has multiple ranges it can DMA from?
>>>
>>
>> We've not found any cases in current Linux where more than one dma-ranges
>> would be used. Moreover, The MM (definitely for ARM) isn't supported such
>> cases at all (if i understand everything right).
>> - there are only one arm_dma_pfn_limit
>> - there is only one MM zone is used for ARM
>> - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
>>   DMA & DMA32, but they configured once and forever per arch.
> 
> Okay. If anyone ever does implement multiple ranges then this code will
> need to be revisited.
>
Sure. Thanks for the review !!
 
Regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Thursday 01 May 2014 14:12:10 Grant Likely wrote:
> > > I've got two concerns here. of_dma_get_range() retrieves only the first
> > > tuple from the dma-ranges property, but it is perfectly valid for
> > > dma-ranges to contain multiple tuples. How should we handle it if a
> > > device has multiple ranges it can DMA from?
> > > 
> > 
> > We've not found any cases in current Linux where more than one dma-ranges
> > would be used. Moreover, The MM (definitely for ARM) isn't supported such
> > cases at all (if i understand everything right).
> > - there are only one arm_dma_pfn_limit
> > - there is only one MM zone is used for ARM
> > - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
> >   DMA & DMA32, but they configured once and forever per arch.
> 
> Okay. If anyone ever does implement multiple ranges then this code will
> need to be revisited.

I wonder if it's needed for platforms implementing the standard "ARM memory map" [1].
The document only talks about addresses as seen from the CPU, and I can see
two logical interpretations how the RAM is supposed to be visible from a device:
either all RAM would be visible contiguously at DMA address zero, or everything
would be visible at the same physical address as the CPU sees it.

If anyone picks the first interpretation, we will have to implement that
in Linux. We can of course hope that all hardware designs follow the second
interpretation, which would be more convenient for us here.

	Arnd

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Friday 02 May 2014 05:58 AM, Arnd Bergmann wrote:
> On Thursday 01 May 2014 14:12:10 Grant Likely wrote:
>>>> I've got two concerns here. of_dma_get_range() retrieves only the first
>>>> tuple from the dma-ranges property, but it is perfectly valid for
>>>> dma-ranges to contain multiple tuples. How should we handle it if a
>>>> device has multiple ranges it can DMA from?
>>>>
>>>
>>> We've not found any cases in current Linux where more than one dma-ranges
>>> would be used. Moreover, The MM (definitely for ARM) isn't supported such
>>> cases at all (if i understand everything right).
>>> - there are only one arm_dma_pfn_limit
>>> - there is only one MM zone is used for ARM
>>> - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
>>>   DMA & DMA32, but they configured once and forever per arch.
>>
>> Okay. If anyone ever does implement multiple ranges then this code will
>> need to be revisited.
> 
> I wonder if it's needed for platforms implementing the standard "ARM memory map" [1].
> The document only talks about addresses as seen from the CPU, and I can see
> two logical interpretations how the RAM is supposed to be visible from a device:
> either all RAM would be visible contiguously at DMA address zero, or everything
> would be visible at the same physical address as the CPU sees it.
> 
> If anyone picks the first interpretation, we will have to implement that
> in Linux. We can of course hope that all hardware designs follow the second
> interpretation, which would be more convenient for us here.
>
not sure if I got your point correctly but DMA address 0 isn't used as DRAM start in
any of the ARM SOC today, mainly because of the boot architecture where address 0 is
typically used by ROM code. RAM start will be at some offset always and hence I
believe ARM SOCs will follow second interpretation. This was one of the main reason
we ended up fixing the max*pfn stuff. 
26ba47b {ARM: 7805/1: mm: change max*pfn to include the physical offset of memory}

> 
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf
> 
 
Regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Friday 02 May 2014 09:13:48 Santosh Shilimkar wrote:
> On Friday 02 May 2014 05:58 AM, Arnd Bergmann wrote:
> > On Thursday 01 May 2014 14:12:10 Grant Likely wrote:
> >>>> I've got two concerns here. of_dma_get_range() retrieves only the first
> >>>> tuple from the dma-ranges property, but it is perfectly valid for
> >>>> dma-ranges to contain multiple tuples. How should we handle it if a
> >>>> device has multiple ranges it can DMA from?
> >>>>
> >>>
> >>> We've not found any cases in current Linux where more than one dma-ranges
> >>> would be used. Moreover, The MM (definitely for ARM) isn't supported such
> >>> cases at all (if i understand everything right).
> >>> - there are only one arm_dma_pfn_limit
> >>> - there is only one MM zone is used for ARM
> >>> - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
> >>>   DMA & DMA32, but they configured once and forever per arch.
> >>
> >> Okay. If anyone ever does implement multiple ranges then this code will
> >> need to be revisited.
> > 
> > I wonder if it's needed for platforms implementing the standard "ARM memory map" [1].
> > The document only talks about addresses as seen from the CPU, and I can see
> > two logical interpretations how the RAM is supposed to be visible from a device:
> > either all RAM would be visible contiguously at DMA address zero, or everything
> > would be visible at the same physical address as the CPU sees it.
> > 
> > If anyone picks the first interpretation, we will have to implement that
> > in Linux. We can of course hope that all hardware designs follow the second
> > interpretation, which would be more convenient for us here.
> >
> not sure if I got your point correctly but DMA address 0 isn't used as DRAM start in
> any of the ARM SOC today, mainly because of the boot architecture where address 0 is
> typically used by ROM code. RAM start will be at some offset always and hence I
> believe ARM SOCs will follow second interpretation. This was one of the main reason
> we ended up fixing the max*pfn stuff. 
> 26ba47b {ARM: 7805/1: mm: change max*pfn to include the physical offset of memory}

Marvell normally has memory starting at physical address zero.

Even if RAM starts elsewhere, I don't think that is a reason to have
the DMA address do the same. The memory controller internally obviously
starts at zero, and it wouldn't be unreasonable to have the DMA space
match what the memory controller sees rather than have it match what
the CPU sees.

If you look at the table 3.1.4, you have both addresses listed:

	  Physical Addresses in SoC	Offset	 		Internal DRAM address

2 GBytes	0x00 8000 0000 ?	-0x00 8000 0000		0x00 0000 0000 ?
		0x00 FFFF FFFF			 		0x00 7FFF FFFF

30 GBytes	0x08 8000 0000 ? 	-0x08 0000 0000		0x00 8000 0000 ?
		0x0F FFFF FFFF					0x07 FFFF FFFF

32 GBytes	0x88 0000 0000 -	-0x80 0000 0000	 	0x08 0000 0000 -
		0x8F FFFF FFFF					0x0F FFFF FFFF

The wording "Physical Addresses in SoC" would indeed suggest that the
same address is used for DMA, but I would trust everybody to do that.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Grant Likely]

On Fri, 02 May 2014 11:58:30 +0200, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 01 May 2014 14:12:10 Grant Likely wrote:
> > > > I've got two concerns here. of_dma_get_range() retrieves only the first
> > > > tuple from the dma-ranges property, but it is perfectly valid for
> > > > dma-ranges to contain multiple tuples. How should we handle it if a
> > > > device has multiple ranges it can DMA from?
> > > > 
> > > 
> > > We've not found any cases in current Linux where more than one dma-ranges
> > > would be used. Moreover, The MM (definitely for ARM) isn't supported such
> > > cases at all (if i understand everything right).
> > > - there are only one arm_dma_pfn_limit
> > > - there is only one MM zone is used for ARM
> > > - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
> > >   DMA & DMA32, but they configured once and forever per arch.
> > 
> > Okay. If anyone ever does implement multiple ranges then this code will
> > need to be revisited.
> 
> I wonder if it's needed for platforms implementing the standard "ARM memory map" [1].
> The document only talks about addresses as seen from the CPU, and I can see
> two logical interpretations how the RAM is supposed to be visible from a device:
> either all RAM would be visible contiguously at DMA address zero, or everything
> would be visible at the same physical address as the CPU sees it.
> 
> If anyone picks the first interpretation, we will have to implement that
> in Linux. We can of course hope that all hardware designs follow the second
> interpretation, which would be more convenient for us here.

Indeed. Hope though we might, I would not be surprised to see a platform
that does the first. In that case we could probably handle it with a
ranges property that is DMA-controller facing instead of device facing.
That would be able to handle the translation between CPU addressing and
DMA addressing.

Come to think of it, doesn't PCI DMA have to deal with that situation if
the PCI window is not 1:1 mapped into the CPU address space?

g.

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Tuesday 27 May 2014 13:56:55 Grant Likely wrote:
> On Fri, 02 May 2014 11:58:30 +0200, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 01 May 2014 14:12:10 Grant Likely wrote:
> > > > > I've got two concerns here. of_dma_get_range() retrieves only the first
> > > > > tuple from the dma-ranges property, but it is perfectly valid for
> > > > > dma-ranges to contain multiple tuples. How should we handle it if a
> > > > > device has multiple ranges it can DMA from?
> > > > > 
> > > > 
> > > > We've not found any cases in current Linux where more than one dma-ranges
> > > > would be used. Moreover, The MM (definitely for ARM) isn't supported such
> > > > cases at all (if i understand everything right).
> > > > - there are only one arm_dma_pfn_limit
> > > > - there is only one MM zone is used for ARM
> > > > - some arches like x86,mips can support 2 zones (per arch - not per device or bus)
> > > >   DMA & DMA32, but they configured once and forever per arch.
> > > 
> > > Okay. If anyone ever does implement multiple ranges then this code will
> > > need to be revisited.
> > 
> > I wonder if it's needed for platforms implementing the standard "ARM memory map" [1].
> > The document only talks about addresses as seen from the CPU, and I can see
> > two logical interpretations how the RAM is supposed to be visible from a device:
> > either all RAM would be visible contiguously at DMA address zero, or everything
> > would be visible at the same physical address as the CPU sees it.
> > 
> > If anyone picks the first interpretation, we will have to implement that
> > in Linux. We can of course hope that all hardware designs follow the second
> > interpretation, which would be more convenient for us here.
> 
> Indeed. Hope though we might, I would not be surprised to see a platform
> that does the first. In that case we could probably handle it with a
> ranges property that is DMA-controller facing instead of device facing.
> That would be able to handle the translation between CPU addressing and
> DMA addressing.
> 
> Come to think of it, doesn't PCI DMA have to deal with that situation if
> the PCI window is not 1:1 mapped into the CPU address space?

I think all PCI buses we support so far only need a single entry in the
dma-ranges property.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Linus Walleij]

On Tue, May 27, 2014 at 3:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 27 May 2014 13:56:55 Grant Likely wrote:

>> Come to think of it, doesn't PCI DMA have to deal with that situation if
>> the PCI window is not 1:1 mapped into the CPU address space?
>
> I think all PCI buses we support so far only need a single entry in the
> dma-ranges property.

Here is the patch I've cooked for the Integrator (PCIv3), identical
to the keystone:

commit b326b94a58ff476fca2b57cf7912b00bec1363c0
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Feb 14 10:26:15 2014 +0100

    ARM: integrator: get rid of <mach/memory.h>

    The Integrator has a custom <mach/memory.h> header defining the
    BUS_OFFSET for *_to_bus and bus_to_* operations as offset from
    0x80000000.

    This switches the Integrator over to using the mechanism
    introduced for the Keystone to provide the same offset using
    the device tree, deletes <mach/memory.h> and augments the
    Integrator device tree to provide the bus offset.

    Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Cc: Grygorii Strashko <grygorii.strashko@ti.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Jonathan Austin <jonathan.austin@arm.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ab438cb5af55..2b29a1a7f26f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -329,7 +329,6 @@ config ARCH_INTEGRATOR
        select HAVE_TCM
        select ICST
        select MULTI_IRQ_HANDLER
-       select NEED_MACH_MEMORY_H
        select PLAT_VERSATILE
        select SPARSE_IRQ
        select USE_OF
diff --git a/arch/arm/boot/dts/integratorap.dts
b/arch/arm/boot/dts/integratorap.dts
index b10e6351da53..f0c397fd45c5 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -8,6 +8,7 @@
 / {
        model = "ARM Integrator/AP";
        compatible = "arm,integrator-ap";
+       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;

        aliases {
                arm,timer-primary = &timer2;
diff --git a/arch/arm/mach-integrator/include/mach/memory.h
b/arch/arm/mach-integrator/include/mach/memory.h
deleted file mode 100644
index 334d5e271889..000000000000
--- a/arch/arm/mach-integrator/include/mach/memory.h
+++ /dev/null
(...)

Yours,
Linus Walleij

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Wednesday 28 May 2014 10:23:09 Linus Walleij wrote:
> diff --git a/arch/arm/boot/dts/integratorap.dts
> b/arch/arm/boot/dts/integratorap.dts
> index b10e6351da53..f0c397fd45c5 100644
> --- a/arch/arm/boot/dts/integratorap.dts
> +++ b/arch/arm/boot/dts/integratorap.dts
> @@ -8,6 +8,7 @@
>  / {
>         model = "ARM Integrator/AP";
>         compatible = "arm,integrator-ap";
> +       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
> 
>         aliases {
>                 arm,timer-primary = &timer2;
> 

It looks like you accidentally copied the ranges from keystone, even
though that has a 64-bit root bus and you only have 32-bit.

I suspect what you want is

	dma-ranges = <0x80000000 0 0x80000000>;

to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
rather than phys_addr_t 0x800000000-0x87fffffff.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Linus Walleij]

On Wed, May 28, 2014 at 3:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 28 May 2014 10:23:09 Linus Walleij wrote:

>>         model = "ARM Integrator/AP";
>>         compatible = "arm,integrator-ap";
>> +       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
>>
>>         aliases {
>>                 arm,timer-primary = &timer2;
>>
>
> It looks like you accidentally copied the ranges from keystone, even
> though that has a 64-bit root bus and you only have 32-bit.

Nah it was no accident, just good old incompetence ;-)

> I suspect what you want is
>
>         dma-ranges = <0x80000000 0 0x80000000>;
>
> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
> rather than phys_addr_t 0x800000000-0x87fffffff.

Thanks, I'll fix up my patch.

Yours,
Linus Walleij

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
> On Wed, May 28, 2014 at 3:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday 28 May 2014 10:23:09 Linus Walleij wrote:
> 
>>>         model = "ARM Integrator/AP";
>>>         compatible = "arm,integrator-ap";
>>> +       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
>>>
>>>         aliases {
>>>                 arm,timer-primary = &timer2;
>>>
>>
>> It looks like you accidentally copied the ranges from keystone, even
>> though that has a 64-bit root bus and you only have 32-bit.
> 
> Nah it was no accident, just good old incompetence ;-)
> 
>> I suspect what you want is
>>
>>         dma-ranges = <0x80000000 0 0x80000000>;
>>
>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>> rather than phys_addr_t 0x800000000-0x87fffffff.
>
Interesting. Where does the ROM address space resides on integrator then considering
address 0 is used for DMA.
 
> Thanks, I'll fix up my patch.
> 
Feel free to add my ack after the fixup if you need one.

regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Linus Walleij]

On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:

>>> I suspect what you want is
>>>
>>>         dma-ranges = <0x80000000 0 0x80000000>;
>>>
>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>>> rather than phys_addr_t 0x800000000-0x87fffffff.
>>
> Interesting. Where does the ROM address space resides on integrator then considering
> address 0 is used for DMA.

The ROM is at physical address 0x20000000, don't ask me
why :-)

The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
tiles, i.e. up to four completely independent CPUs are booted off the
same ROM and using a set of shared peripherals.

>> Thanks, I'll fix up my patch.
>>
> Feel free to add my ack after the fixup if you need one.

Thanks!

Yours,
Linus Walleij

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Thursday 29 May 2014 10:01 AM, Linus Walleij wrote:
> On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
> 
>>>> I suspect what you want is
>>>>
>>>>         dma-ranges = <0x80000000 0 0x80000000>;
>>>>
>>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>>>> rather than phys_addr_t 0x800000000-0x87fffffff.
>>>
>> Interesting. Where does the ROM address space resides on integrator then considering
>> address 0 is used for DMA.
> 
> The ROM is at physical address 0x20000000, don't ask me
> why :-)
> 
> The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
> tiles, i.e. up to four completely independent CPUs are booted off the
> same ROM and using a set of shared peripherals.
> 
The reason I asked the question because most of the ARM SOC I came across
aren't using the RAM phys address 0 and thought was because of boot architecture
with ROM occupying that address with reset vector starting at address 0.

That was one of the main reason we had description on max_*pfn on ARM w.r.t
to other acrhes.

Will corner ARM guys to understand bit more about it in some conference ;-)

Thanks for clarification.

Regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Thursday 29 May 2014 10:08:10 Santosh Shilimkar wrote:
> On Thursday 29 May 2014 10:01 AM, Linus Walleij wrote:
> > On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> >> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
> > 
> >>>> I suspect what you want is
> >>>>
> >>>>         dma-ranges = <0x80000000 0 0x80000000>;
> >>>>
> >>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
> >>>> rather than phys_addr_t 0x800000000-0x87fffffff.
> >>>
> >> Interesting. Where does the ROM address space resides on integrator then considering
> >> address 0 is used for DMA.
> > 
> > The ROM is at physical address 0x20000000, don't ask me
> > why 
> > 
> > The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
> > tiles, i.e. up to four completely independent CPUs are booted off the
> > same ROM and using a set of shared peripherals.
> > 
> The reason I asked the question because most of the ARM SOC I came across
> aren't using the RAM phys address 0 and thought was because of boot architecture
> with ROM occupying that address with reset vector starting at address 0.
> 
> That was one of the main reason we had description on max_*pfn on ARM w.r.t
> to other acrhes.
> 
> Will corner ARM guys to understand bit more about it in some conference 

If this is anything like the versatile express, the reason it works is probably
because there is another microcontroller in the system that does the bootstrap
and is able to load code into RAM before turning on the main CPU.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Thursday 29 May 2014 03:24 PM, Arnd Bergmann wrote:
> On Thursday 29 May 2014 10:08:10 Santosh Shilimkar wrote:
>> On Thursday 29 May 2014 10:01 AM, Linus Walleij wrote:
>>> On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
>>> <santosh.shilimkar@ti.com> wrote:
>>>> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
>>>
>>>>>> I suspect what you want is
>>>>>>
>>>>>>         dma-ranges = <0x80000000 0 0x80000000>;
>>>>>>
>>>>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>>>>>> rather than phys_addr_t 0x800000000-0x87fffffff.
>>>>>
>>>> Interesting. Where does the ROM address space resides on integrator then considering
>>>> address 0 is used for DMA.
>>>
>>> The ROM is at physical address 0x20000000, don't ask me
>>> why 
>>>
>>> The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
>>> tiles, i.e. up to four completely independent CPUs are booted off the
>>> same ROM and using a set of shared peripherals.
>>>
>> The reason I asked the question because most of the ARM SOC I came across
>> aren't using the RAM phys address 0 and thought was because of boot architecture
>> with ROM occupying that address with reset vector starting at address 0.
>>
>> That was one of the main reason we had description on max_*pfn on ARM w.r.t
>> to other acrhes.
>>
>> Will corner ARM guys to understand bit more about it in some conference 
> 
> If this is anything like the versatile express, the reason it works is probably
> because there is another microcontroller in the system that does the bootstrap
> and is able to load code into RAM before turning on the main CPU.
> 
That make sense now. Thanks for those extra bits.

Regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Rob Herring]

On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Retrieve DMA configuration from DT and setup platform device's DMA
> parameters. The DMA configuration in DT has to be specified using
> "dma-ranges" and "dma-coherent" properties if supported.
>
> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
> using "dma-coherent" device tree properties.
>
> The set_arch_dma_coherent_ops macro has to be defined by arch if
> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
> declared as nop.
>

[...]

> +       /*
> +        * if dma-ranges property doesn't exist - just return else
> +        * setup the dma offset
> +        */
> +       ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> +       if ((ret == -ENODEV) || (ret < 0)) {

The 1st condition is redundant.

> +               dev_dbg(dev, "no dma range information to setup\n");
> +               return;
> +       }
> +
> +       /* DMA ranges found. Calculate and set dma_pfn_offset */
> +       dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +       dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> +}
> +
> +/**
>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>   * @np: pointer to node to create device for
>   * @bus_id: name to assign device
> @@ -214,9 +258,7 @@ static struct platform_device *of_platform_device_create_pdata(
>  #if defined(CONFIG_MICROBLAZE)
>         dev->archdata.dma_mask = 0xffffffffUL;
>  #endif

This is also dma related setup. Please move *all* dma setup into the function.

> -       dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> -       if (!dev->dev.dma_mask)
> -               dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> +       of_dma_configure(&dev->dev);
>         dev->dev.bus = &platform_bus_type;
>         dev->dev.platform_data = platform_data;
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index fd4aee2..c7d9b1b 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -123,6 +123,13 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
>
>  extern u64 dma_get_required_mask(struct device *dev);
>
> +#ifndef set_arch_dma_coherent_ops
> +static inline int set_arch_dma_coherent_ops(struct device *dev)
> +{
> +       return 0;
> +}
> +#endif
> +
>  static inline unsigned int dma_get_max_seg_size(struct device *dev)
>  {
>         return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
> --
> 1.7.9.5
>

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Thursday 01 May 2014 08:49 PM, Rob Herring wrote:
> On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> Retrieve DMA configuration from DT and setup platform device's DMA
>> parameters. The DMA configuration in DT has to be specified using
>> "dma-ranges" and "dma-coherent" properties if supported.
>>
>> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
>> using "dma-coherent" device tree properties.
>>
>> The set_arch_dma_coherent_ops macro has to be defined by arch if
>> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
>> declared as nop.
>>
> 
> [...]
> 
>> +       /*
>> +        * if dma-ranges property doesn't exist - just return else
>> +        * setup the dma offset
>> +        */
>> +       ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>> +       if ((ret == -ENODEV) || (ret < 0)) {
> 
> The 1st condition is redundant.
> 
>> +               dev_dbg(dev, "no dma range information to setup\n");
>> +               return;
>> +       }
>> +
>> +       /* DMA ranges found. Calculate and set dma_pfn_offset */
>> +       dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> +       dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
>> +}
>> +
>> +/**
>>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>>   * @np: pointer to node to create device for
>>   * @bus_id: name to assign device
>> @@ -214,9 +258,7 @@ static struct platform_device *of_platform_device_create_pdata(
>>  #if defined(CONFIG_MICROBLAZE)
>>         dev->archdata.dma_mask = 0xffffffffUL;
>>  #endif
> 
> This is also dma related setup. Please move *all* dma setup into the function.
> 
Updated patch with above minor updates.

>From 80a9f06a09a90801d8ee337d9b2d155c43da8f23 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 24 Apr 2014 11:30:04 -0400
Subject: [PATCH v3 4/7] of: configure the platform device dma parameters

Retrieve DMA configuration from DT and setup platform device's DMA
parameters. The DMA configuration in DT has to be specified using
"dma-ranges" and "dma-coherent" properties if supported.

We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
using "dma-coherent" device tree properties.

The set_arch_dma_coherent_ops macro has to be defined by arch if
it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
declared as nop.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/of/platform.c       |   55 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/dma-mapping.h |    7 ++++++
 2 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..b71e089 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -187,6 +187,54 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_dma_configure - Setup DMA configuration
+ * @dev:	Device to apply DMA configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * In case if platform code need to use own special DMA configuration,it
+ * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
+ * to fix up DMA configuration.
+ */
+static void of_dma_configure(struct platform_device *pdev)
+{
+	u64 dma_addr, paddr, size;
+	int ret;
+	struct device *dev = &pdev->dev;
+
+#if defined(CONFIG_MICROBLAZE)
+	pdev->archdata.dma_mask = 0xffffffffUL;
+#endif
+	dev->coherent_dma_mask = DMA_BIT_MASK(32);
+	if (!dev->dma_mask)
+		dev->dma_mask = &dev->coherent_dma_mask;
+
+	/*
+	 * if dma-coherent property exist, call arch hook to setup
+	 * dma coherent operations.
+	 */
+	if (of_dma_is_coherent(dev->of_node)) {
+		set_arch_dma_coherent_ops(dev);
+		dev_dbg(dev, "device is dma coherent\n");
+	}
+
+	/*
+	 * if dma-ranges property doesn't exist - just return else
+	 * setup the dma offset
+	 */
+	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
+	if (ret < 0) {
+		dev_dbg(dev, "no dma range information to setup\n");
+		return;
+	}
+
+	/* DMA ranges found. Calculate and set dma_pfn_offset */
+	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
+	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -211,12 +259,7 @@ static struct platform_device *of_platform_device_create_pdata(
 	if (!dev)
 		return NULL;
 
-#if defined(CONFIG_MICROBLAZE)
-	dev->archdata.dma_mask = 0xffffffffUL;
-#endif
-	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-	if (!dev->dev.dma_mask)
-		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+	of_dma_configure(dev);
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index fd4aee2..c7d9b1b 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -123,6 +123,13 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 
 extern u64 dma_get_required_mask(struct device *dev);
 
+#ifndef set_arch_dma_coherent_ops
+static inline int set_arch_dma_coherent_ops(struct device *dev)
+{
+	return 0;
+}
+#endif
+
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
 {
 	return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
-- 
1.7.9.5

[PATCH v3 4/7] of: configure the platform device dma parameters

[Rob Herring]

On Mon, May 5, 2014 at 4:47 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Thursday 01 May 2014 08:49 PM, Rob Herring wrote:
>> On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> wrote:

> Updated patch with above minor updates.
>
> From 80a9f06a09a90801d8ee337d9b2d155c43da8f23 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Thu, 24 Apr 2014 11:30:04 -0400
> Subject: [PATCH v3 4/7] of: configure the platform device dma parameters
>
> Retrieve DMA configuration from DT and setup platform device's DMA
> parameters. The DMA configuration in DT has to be specified using
> "dma-ranges" and "dma-coherent" properties if supported.
>
> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
> using "dma-coherent" device tree properties.
>
> The set_arch_dma_coherent_ops macro has to be defined by arch if
> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
> declared as nop.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Reviewed-by: Rob Herring <robh@kernel.org>

> ---
>  drivers/of/platform.c       |   55 ++++++++++++++++++++++++++++++++++++++-----
>  include/linux/dma-mapping.h |    7 ++++++
>  2 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 404d1da..b71e089 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -187,6 +187,54 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  EXPORT_SYMBOL(of_device_alloc);
>
>  /**
> + * of_dma_configure - Setup DMA configuration
> + * @dev:       Device to apply DMA configuration
> + *
> + * Try to get devices's DMA configuration from DT and update it
> + * accordingly.
> + *
> + * In case if platform code need to use own special DMA configuration,it
> + * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
> + * to fix up DMA configuration.
> + */
> +static void of_dma_configure(struct platform_device *pdev)
> +{
> +       u64 dma_addr, paddr, size;
> +       int ret;
> +       struct device *dev = &pdev->dev;
> +
> +#if defined(CONFIG_MICROBLAZE)
> +       pdev->archdata.dma_mask = 0xffffffffUL;
> +#endif
> +       dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +       if (!dev->dma_mask)
> +               dev->dma_mask = &dev->coherent_dma_mask;
> +
> +       /*
> +        * if dma-coherent property exist, call arch hook to setup
> +        * dma coherent operations.
> +        */
> +       if (of_dma_is_coherent(dev->of_node)) {
> +               set_arch_dma_coherent_ops(dev);
> +               dev_dbg(dev, "device is dma coherent\n");
> +       }
> +
> +       /*
> +        * if dma-ranges property doesn't exist - just return else
> +        * setup the dma offset
> +        */
> +       ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> +       if (ret < 0) {
> +               dev_dbg(dev, "no dma range information to setup\n");
> +               return;
> +       }
> +
> +       /* DMA ranges found. Calculate and set dma_pfn_offset */
> +       dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +       dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> +}
> +
> +/**
>   * of_platform_device_create_pdata - Alloc, initialize and register an of_device
>   * @np: pointer to node to create device for
>   * @bus_id: name to assign device
> @@ -211,12 +259,7 @@ static struct platform_device *of_platform_device_create_pdata(
>         if (!dev)
>                 return NULL;
>
> -#if defined(CONFIG_MICROBLAZE)
> -       dev->archdata.dma_mask = 0xffffffffUL;
> -#endif
> -       dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> -       if (!dev->dev.dma_mask)
> -               dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> +       of_dma_configure(dev);
>         dev->dev.bus = &platform_bus_type;
>         dev->dev.platform_data = platform_data;
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index fd4aee2..c7d9b1b 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -123,6 +123,13 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
>
>  extern u64 dma_get_required_mask(struct device *dev);
>
> +#ifndef set_arch_dma_coherent_ops
> +static inline int set_arch_dma_coherent_ops(struct device *dev)
> +{
> +       return 0;
> +}
> +#endif
> +
>  static inline unsigned int dma_get_max_seg_size(struct device *dev)
>  {
>         return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
> --
> 1.7.9.5
>
>

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Monday 05 May 2014 17:47:32 Santosh Shilimkar wrote:

> +       dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +       if (!dev->dma_mask)
> +               dev->dma_mask = &dev->coherent_dma_mask;
> +
> +       /*
> +        * if dma-ranges property doesn't exist - just return else
> +        * setup the dma offset
> +        */
> +       ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> +       if (ret < 0) {
> +               dev_dbg(dev, "no dma range information to setup\n");
> +               return;
> +       }
> +
> +       /* DMA ranges found. Calculate and set dma_pfn_offset */
> +       dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +       dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> +}

I think there should at least be a comment about why we are computing
the correct DMA mask here and then ignore that and just use DMA_BIT_MASK(32)
instead. I understand that Russell and Rob prefer it that way and I'm not
going to argue, but I find it counterintuitive and I think it deserves
an explanation in the source code for anybody who is trying to figure
out how things fit together.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Tuesday 06 May 2014 05:40 AM, Arnd Bergmann wrote:
> On Monday 05 May 2014 17:47:32 Santosh Shilimkar wrote:
> 
>> +       dev->coherent_dma_mask = DMA_BIT_MASK(32);
>> +       if (!dev->dma_mask)
>> +               dev->dma_mask = &dev->coherent_dma_mask;
>> +
>> +       /*
>> +        * if dma-ranges property doesn't exist - just return else
>> +        * setup the dma offset
>> +        */
>> +       ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>> +       if (ret < 0) {
>> +               dev_dbg(dev, "no dma range information to setup\n");
>> +               return;
>> +       }
>> +
>> +       /* DMA ranges found. Calculate and set dma_pfn_offset */
>> +       dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> +       dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
>> +}
> 
> I think there should at least be a comment about why we are computing
> the correct DMA mask here and then ignore that and just use DMA_BIT_MASK(32)
> instead. I understand that Russell and Rob prefer it that way and I'm not
> going to argue, but I find it counterintuitive and I think it deserves
> an explanation in the source code for anybody who is trying to figure
> out how things fit together.
> 
In this patch, the dma_mask related code is just moved. We are not calculating
dma_mask either. I was looking for the history of how DMA_BIT_MASK(32)
landed up but couldn't trace it down apart from the fact that the code was
carried from powerPC. May be Rob knows.

How about below comment ? I didn't delibratly added point about bus
intercepting drivers dma_set_*mask() call etc.

/*
 * Set default dma-mask to 32 bit. Drivers are expected to setup
 * the correct supported dma_mask.
 */  
+       dev->coherent_dma_mask = DMA_BIT_MASK(32);
+       if (!dev->dma_mask)
+               dev->dma_mask = &dev->coherent_dma_mask;

Regards,
Santosh

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Tuesday 06 May 2014 04:44 PM, Santosh Shilimkar wrote:
> On Tuesday 06 May 2014 05:40 AM, Arnd Bergmann wrote:
>> On Monday 05 May 2014 17:47:32 Santosh Shilimkar wrote:
>>
>>> +       dev->coherent_dma_mask = DMA_BIT_MASK(32);
>>> +       if (!dev->dma_mask)
>>> +               dev->dma_mask = &dev->coherent_dma_mask;
>>> +
>>> +       /*
>>> +        * if dma-ranges property doesn't exist - just return else
>>> +        * setup the dma offset
>>> +        */
>>> +       ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>>> +       if (ret < 0) {
>>> +               dev_dbg(dev, "no dma range information to setup\n");
>>> +               return;
>>> +       }
>>> +
>>> +       /* DMA ranges found. Calculate and set dma_pfn_offset */
>>> +       dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>>> +       dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
>>> +}
>>
>> I think there should at least be a comment about why we are computing
>> the correct DMA mask here and then ignore that and just use DMA_BIT_MASK(32)
>> instead. I understand that Russell and Rob prefer it that way and I'm not
>> going to argue, but I find it counterintuitive and I think it deserves
>> an explanation in the source code for anybody who is trying to figure
>> out how things fit together.
>>
> In this patch, the dma_mask related code is just moved. We are not calculating
> dma_mask either. I was looking for the history of how DMA_BIT_MASK(32)
> landed up but couldn't trace it down apart from the fact that the code was
> carried from powerPC. May be Rob knows.
> 
> How about below comment ? I didn't delibratly added point about bus
> intercepting drivers dma_set_*mask() call etc.
> 
> /*
>  * Set default dma-mask to 32 bit. Drivers are expected to setup
>  * the correct supported dma_mask.
>  */  
> +       dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +       if (!dev->dma_mask)
> +               dev->dma_mask = &dev->coherent_dma_mask;
> 
Updated patch below for records.

>From 591c1ee465ce5372385dbc41e7d3e36cbb477bd8 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 24 Apr 2014 11:30:04 -0400
Subject: [PATCH v3 4/7] of: configure the platform device dma parameters

Retrieve DMA configuration from DT and setup platform device's DMA
parameters. The DMA configuration in DT has to be specified using
"dma-ranges" and "dma-coherent" properties if supported.

We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
using "dma-coherent" device tree properties.

The set_arch_dma_coherent_ops macro has to be defined by arch if
it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
declared as nop.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 drivers/of/platform.c       |   65 +++++++++++++++++++++++++++++++++++++++----
 include/linux/dma-mapping.h |    7 +++++
 2 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..91fa983 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -187,6 +187,64 @@ struct platform_device *of_device_alloc(struct device_node *np,
 EXPORT_SYMBOL(of_device_alloc);
 
 /**
+ * of_dma_configure - Setup DMA configuration
+ * @dev:	Device to apply DMA configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * In case if platform code need to use own special DMA configuration,it
+ * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
+ * to fix up DMA configuration.
+ */
+static void of_dma_configure(struct platform_device *pdev)
+{
+	u64 dma_addr, paddr, size;
+	int ret;
+	struct device *dev = &pdev->dev;
+
+#if defined(CONFIG_MICROBLAZE)
+	pdev->archdata.dma_mask = 0xffffffffUL;
+#endif
+
+	/*
+	 * Set default dma-mask to 32 bit. Drivers are expected to setup
+	 * the correct supported dma_mask.
+	 */
+	dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+	/*
+	 * Set it to coherent_dma_mask by default if the architecture
+	 * code has not set it.
+	 */
+	if (!dev->dma_mask)
+		dev->dma_mask = &dev->coherent_dma_mask;
+
+	/*
+	 * if dma-coherent property exist, call arch hook to setup
+	 * dma coherent operations.
+	 */
+	if (of_dma_is_coherent(dev->of_node)) {
+		set_arch_dma_coherent_ops(dev);
+		dev_dbg(dev, "device is dma coherent\n");
+	}
+
+	/*
+	 * if dma-ranges property doesn't exist - just return else
+	 * setup the dma offset
+	 */
+	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
+	if (ret < 0) {
+		dev_dbg(dev, "no dma range information to setup\n");
+		return;
+	}
+
+	/* DMA ranges found. Calculate and set dma_pfn_offset */
+	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
+	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
+}
+
+/**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
  * @bus_id: name to assign device
@@ -211,12 +269,7 @@ static struct platform_device *of_platform_device_create_pdata(
 	if (!dev)
 		return NULL;
 
-#if defined(CONFIG_MICROBLAZE)
-	dev->archdata.dma_mask = 0xffffffffUL;
-#endif
-	dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-	if (!dev->dev.dma_mask)
-		dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+	of_dma_configure(dev);
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index fd4aee2..c7d9b1b 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -123,6 +123,13 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
 
 extern u64 dma_get_required_mask(struct device *dev);
 
+#ifndef set_arch_dma_coherent_ops
+static inline int set_arch_dma_coherent_ops(struct device *dev)
+{
+	return 0;
+}
+#endif
+
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
 {
 	return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
-- 
1.7.9.5


 

[PATCH v3 4/7] of: configure the platform device dma parameters

[Bjorn Helgaas]

On Thu, Apr 24, 2014 at 11:30:04AM -0400, Santosh Shilimkar wrote:
> Retrieve DMA configuration from DT and setup platform device's DMA
> parameters. The DMA configuration in DT has to be specified using
> "dma-ranges" and "dma-coherent" properties if supported.
> 
> We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops
> using "dma-coherent" device tree properties.
> 
> The set_arch_dma_coherent_ops macro has to be defined by arch if
> it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is
> declared as nop.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  drivers/of/platform.c       |   48 ++++++++++++++++++++++++++++++++++++++++---
>  include/linux/dma-mapping.h |    7 +++++++
>  2 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 48de98f..270c0b9 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -187,6 +187,50 @@ struct platform_device *of_device_alloc(struct device_node *np,
>  EXPORT_SYMBOL(of_device_alloc);
>  
>  /**
> + * of_dma_configure - Setup DMA configuration
> + * @dev:	Device to apply DMA configuration
> + *
> + * Try to get devices's DMA configuration from DT and update it
> + * accordingly.
> + *
> + * In case if platform code need to use own special DMA configuration,it
> + * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
> + * to fix up DMA configuration.
> + */
> +static void of_dma_configure(struct device *dev)
> +{
> +	u64 dma_addr, paddr, size;
> +	int ret;
> +
> +	dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +	if (!dev->dma_mask)
> +		dev->dma_mask = &dev->coherent_dma_mask;
> +
> +	/*
> +	 * if dma-coherent property exist, call arch hook to setup
> +	 * dma coherent operations.
> +	 */
> +	if (of_dma_is_coherent(dev->of_node)) {
> +		set_arch_dma_coherent_ops(dev);
> +		dev_dbg(dev, "device is dma coherent\n");
> +	}
> +
> +	/*
> +	 * if dma-ranges property doesn't exist - just return else
> +	 * setup the dma offset
> +	 */
> +	ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> +	if ((ret == -ENODEV) || (ret < 0)) {
> +		dev_dbg(dev, "no dma range information to setup\n");
> +		return;
> +	}
> +
> +	/* DMA ranges found. Calculate and set dma_pfn_offset */
> +	dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +	dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);

Is this effectively the same as an IOMMU that applies a constant offset
to the bus address?  Could or should this be done by adding a simple IOMMU
driver instead of adding dma_pfn_offset to struct device?

If we had both dma-ranges (and we set dma_pfn_offset as you do here) and an
IOMMU, how would the combination work?  If the IOMMU driver managed
dma_pfn_offset internally, it seems like we'd have two entities dealing
with it.  If the IOMMU driver doesn't use dma_pfn_offset, it seems like
it would be exposing a weird intermediate address space that's not usable
by either CPU or device.

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Friday 02 May 2014 10:54:59 Bjorn Helgaas wrote:
> > +static void of_dma_configure(struct device *dev)
> > +{
> > +     u64 dma_addr, paddr, size;
> > +     int ret;
> > +
> > +     dev->coherent_dma_mask = DMA_BIT_MASK(32);
> > +     if (!dev->dma_mask)
> > +             dev->dma_mask = &dev->coherent_dma_mask;
> > +
> > +     /*
> > +      * if dma-coherent property exist, call arch hook to setup
> > +      * dma coherent operations.
> > +      */
> > +     if (of_dma_is_coherent(dev->of_node)) {
> > +             set_arch_dma_coherent_ops(dev);
> > +             dev_dbg(dev, "device is dma coherent\n");
> > +     }
> > +
> > +     /*
> > +      * if dma-ranges property doesn't exist - just return else
> > +      * setup the dma offset
> > +      */
> > +     ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> > +     if ((ret == -ENODEV) || (ret < 0)) {
> > +             dev_dbg(dev, "no dma range information to setup\n");
> > +             return;
> > +     }
> > +
> > +     /* DMA ranges found. Calculate and set dma_pfn_offset */
> > +     dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> > +     dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> 
> Is this effectively the same as an IOMMU that applies a constant offset
> to the bus address?  Could or should this be done by adding a simple IOMMU
> driver instead of adding dma_pfn_offset to struct device?

We currently have two dma_map_ops variants on ARM (plus another set for
coherent/noncoherent differences, but we can ignore that for the sake
of this discussion): one that handles linear mappings and one that
handles IOMMUs by calling into the linux/iommu.h APIs.

I guess what you mean by 'a simple IOMMU driver' would be another
dma_map_ops implementation that is separate from real IOMMUs, right?

That could certainly be done, but in effect it is almost the same as
the linear mapping we already have.

> If we had both dma-ranges (and we set dma_pfn_offset as you do here) and an
> IOMMU, how would the combination work?  If the IOMMU driver managed
> dma_pfn_offset internally, it seems like we'd have two entities dealing
> with it.  If the IOMMU driver doesn't use dma_pfn_offset, it seems like
> it would be exposing a weird intermediate address space that's not usable
> by either CPU or device.

The iommu dma_map_ops implementation does not need to worry about the
dma_pfn_offset. We are still debating how to represent IOMMUs in DT
at the moment, so it's not clear yet if we would consider a device node
with both a dma-ranges property and an iommu reference as valid.

What we will probably need is a way to represent the valid bus addresses
that can be used for transfers from the DMA master through the IOMMU.
This could be done through dma-ranges, or some other property, we will
have to decide that soon.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Bjorn Helgaas]

[+cc Ben, Chris]

On Fri, May 2, 2014 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 02 May 2014 10:54:59 Bjorn Helgaas wrote:
>> > +static void of_dma_configure(struct device *dev)
>> > +{
>> > +     u64 dma_addr, paddr, size;
>> > +     int ret;
>> > +
>> > +     dev->coherent_dma_mask = DMA_BIT_MASK(32);
>> > +     if (!dev->dma_mask)
>> > +             dev->dma_mask = &dev->coherent_dma_mask;
>> > +
>> > +     /*
>> > +      * if dma-coherent property exist, call arch hook to setup
>> > +      * dma coherent operations.
>> > +      */
>> > +     if (of_dma_is_coherent(dev->of_node)) {
>> > +             set_arch_dma_coherent_ops(dev);
>> > +             dev_dbg(dev, "device is dma coherent\n");
>> > +     }
>> > +
>> > +     /*
>> > +      * if dma-ranges property doesn't exist - just return else
>> > +      * setup the dma offset
>> > +      */
>> > +     ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>> > +     if ((ret == -ENODEV) || (ret < 0)) {
>> > +             dev_dbg(dev, "no dma range information to setup\n");
>> > +             return;
>> > +     }
>> > +
>> > +     /* DMA ranges found. Calculate and set dma_pfn_offset */
>> > +     dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> > +     dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
>>
>> Is this effectively the same as an IOMMU that applies a constant offset
>> to the bus address?  Could or should this be done by adding a simple IOMMU
>> driver instead of adding dma_pfn_offset to struct device?
>
> We currently have two dma_map_ops variants on ARM (plus another set for
> coherent/noncoherent differences, but we can ignore that for the sake
> of this discussion): one that handles linear mappings and one that
> handles IOMMUs by calling into the linux/iommu.h APIs.
>
> I guess what you mean by 'a simple IOMMU driver' would be another
> dma_map_ops implementation that is separate from real IOMMUs, right?

I suppose so; it seems like the offset could be managed inside
arm_dma_ops.  My idea of an IOMMU is something that maps bus addresses
to physical memory addresses.  That's what we're doing here; it's just
that the mapping function is very simple.  So why add something new in
struct device for it?

I think powerpc and tile do something similar in dma_direct_map_page()
and tile_pci_dma_map_page() (they store the offset in struct
dev_archdata).

Bjorn

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Monday 05 May 2014 14:45:21 Bjorn Helgaas wrote:
> [+cc Ben, Chris]
> 
> On Fri, May 2, 2014 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 02 May 2014 10:54:59 Bjorn Helgaas wrote:
> >> > +static void of_dma_configure(struct device *dev)
> >> > +{
> >> > +     u64 dma_addr, paddr, size;
> >> > +     int ret;
> >> > +
> >> > +     dev->coherent_dma_mask = DMA_BIT_MASK(32);
> >> > +     if (!dev->dma_mask)
> >> > +             dev->dma_mask = &dev->coherent_dma_mask;
> >> > +
> >> > +     /*
> >> > +      * if dma-coherent property exist, call arch hook to setup
> >> > +      * dma coherent operations.
> >> > +      */
> >> > +     if (of_dma_is_coherent(dev->of_node)) {
> >> > +             set_arch_dma_coherent_ops(dev);
> >> > +             dev_dbg(dev, "device is dma coherent\n");
> >> > +     }
> >> > +
> >> > +     /*
> >> > +      * if dma-ranges property doesn't exist - just return else
> >> > +      * setup the dma offset
> >> > +      */
> >> > +     ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> >> > +     if ((ret == -ENODEV) || (ret < 0)) {
> >> > +             dev_dbg(dev, "no dma range information to setup\n");
> >> > +             return;
> >> > +     }
> >> > +
> >> > +     /* DMA ranges found. Calculate and set dma_pfn_offset */
> >> > +     dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> >> > +     dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
> >>
> >> Is this effectively the same as an IOMMU that applies a constant offset
> >> to the bus address?  Could or should this be done by adding a simple IOMMU
> >> driver instead of adding dma_pfn_offset to struct device?
> >
> > We currently have two dma_map_ops variants on ARM (plus another set for
> > coherent/noncoherent differences, but we can ignore that for the sake
> > of this discussion): one that handles linear mappings and one that
> > handles IOMMUs by calling into the linux/iommu.h APIs.
> >
> > I guess what you mean by 'a simple IOMMU driver' would be another
> > dma_map_ops implementation that is separate from real IOMMUs, right?
> 
> I suppose so; it seems like the offset could be managed inside
> arm_dma_ops.  My idea of an IOMMU is something that maps bus addresses
> to physical memory addresses.  That's what we're doing here; it's just
> that the mapping function is very simple.  So why add something new in
> struct device for it?
> 
> I think powerpc and tile do something similar in dma_direct_map_page()
> and tile_pci_dma_map_page() (they store the offset in struct
> dev_archdata).

Ah, so the only question is whether to store it in dev_archdata or
in device. I think the argument for using struct device directly
was that it lets us access this field from architecture independent
code. It's not important to the overall design though: we could easily
put it in dev_archdata and call an architecture specific function to
set it, if there are good reasons for keeping it out of the generic
device structure.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Bjorn Helgaas]

On Mon, May 5, 2014 at 2:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 05 May 2014 14:45:21 Bjorn Helgaas wrote:
>> [+cc Ben, Chris]
>>
>> On Fri, May 2, 2014 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 02 May 2014 10:54:59 Bjorn Helgaas wrote:
>> >> > +static void of_dma_configure(struct device *dev)
>> >> > +{
>> >> > +     u64 dma_addr, paddr, size;
>> >> > +     int ret;
>> >> > +
>> >> > +     dev->coherent_dma_mask = DMA_BIT_MASK(32);
>> >> > +     if (!dev->dma_mask)
>> >> > +             dev->dma_mask = &dev->coherent_dma_mask;
>> >> > +
>> >> > +     /*
>> >> > +      * if dma-coherent property exist, call arch hook to setup
>> >> > +      * dma coherent operations.
>> >> > +      */
>> >> > +     if (of_dma_is_coherent(dev->of_node)) {
>> >> > +             set_arch_dma_coherent_ops(dev);
>> >> > +             dev_dbg(dev, "device is dma coherent\n");
>> >> > +     }
>> >> > +
>> >> > +     /*
>> >> > +      * if dma-ranges property doesn't exist - just return else
>> >> > +      * setup the dma offset
>> >> > +      */
>> >> > +     ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
>> >> > +     if ((ret == -ENODEV) || (ret < 0)) {
>> >> > +             dev_dbg(dev, "no dma range information to setup\n");
>> >> > +             return;
>> >> > +     }
>> >> > +
>> >> > +     /* DMA ranges found. Calculate and set dma_pfn_offset */
>> >> > +     dev->dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> >> > +     dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", dev->dma_pfn_offset);
>> >>
>> >> Is this effectively the same as an IOMMU that applies a constant offset
>> >> to the bus address?  Could or should this be done by adding a simple IOMMU
>> >> driver instead of adding dma_pfn_offset to struct device?
>> >
>> > We currently have two dma_map_ops variants on ARM (plus another set for
>> > coherent/noncoherent differences, but we can ignore that for the sake
>> > of this discussion): one that handles linear mappings and one that
>> > handles IOMMUs by calling into the linux/iommu.h APIs.
>> >
>> > I guess what you mean by 'a simple IOMMU driver' would be another
>> > dma_map_ops implementation that is separate from real IOMMUs, right?
>>
>> I suppose so; it seems like the offset could be managed inside
>> arm_dma_ops.  My idea of an IOMMU is something that maps bus addresses
>> to physical memory addresses.  That's what we're doing here; it's just
>> that the mapping function is very simple.  So why add something new in
>> struct device for it?
>>
>> I think powerpc and tile do something similar in dma_direct_map_page()
>> and tile_pci_dma_map_page() (they store the offset in struct
>> dev_archdata).
>
> Ah, so the only question is whether to store it in dev_archdata or
> in device. I think the argument for using struct device directly
> was that it lets us access this field from architecture independent
> code. It's not important to the overall design though: we could easily
> put it in dev_archdata and call an architecture specific function to
> set it, if there are good reasons for keeping it out of the generic
> device structure.

Well, it wasn't my *only* question, since I didn't know about the
powerpc and tile usage originally :).  Putting it in dev_archdata does
seem better because it's a similar solution to a similar problem, and
it's less public.

I still wonder whether arm, powerpc, and tile (and I just noticed
microblaze also has a similar dma_direct_map_page()) could all be
handled by attaching devices to a generic trivial IOMMU driver
parameterized with the appropriate constant offset.

What arch-independent code would access this data?  I expect that
drivers will use dma_map_page(), etc., so they should already have
both the bus and the physical address and wouldn't need it.  Shouldn't
generic code just rely on the DMA API, which might use an IOMMU or
this dma_pfn_offset internally?

Bjorn

[PATCH v3 4/7] of: configure the platform device dma parameters

[Benjamin Herrenschmidt]

On Mon, 2014-05-05 at 16:28 -0600, Bjorn Helgaas wrote:
> I still wonder whether arm, powerpc, and tile (and I just noticed
> microblaze also has a similar dma_direct_map_page()) could all be
> handled by attaching devices to a generic trivial IOMMU driver
> parameterized with the appropriate constant offset.

On powerpc, the offset is not constant, it can be per-device

Cheers,
Ben.

[PATCH v3 4/7] of: configure the platform device dma parameters

[Arnd Bergmann]

On Tuesday 06 May 2014 13:44:38 Benjamin Herrenschmidt wrote:
> On Mon, 2014-05-05 at 16:28 -0600, Bjorn Helgaas wrote:
> > I still wonder whether arm, powerpc, and tile (and I just noticed
> > microblaze also has a similar dma_direct_map_page()) could all be
> > handled by attaching devices to a generic trivial IOMMU driver
> > parameterized with the appropriate constant offset.

It gets complex at that point, but it can be done. We are going to
need support for IOMMU and swiotlb in the same place, as well
as coherent and noncoherent ops, so the code here will be something
like

	/* default is noncoherent, non-offset, no iommu */
	if (offset) {
		if (coherent)
			set_arch_dma_coherent_offset_ops(dev);
		else
			set_arch_dma_offset_ops(dev);
	} else if (coherent)
		set_arch_dma_coherent_ops(dev);

	if (iommu) {
		if (coherent)
			set_arch_dma_coherent_iommu_ops(dev);
		else
			set_arch_dma_iommu_ops(dev);
	}

Doing it in the default ops would reduce the number of cases
from 5 to 3.

It may be easier to replace set_arch_dma_coherent_ops() with
a generic function that handles all cases:

int set_arch_dma_ops(struct device *dev, bool coherent,
		phys_addr_t offset, struct device_node *iommu);

and let the architecture handle the cases it needs.

> On powerpc, the offset is not constant, it can be per-device.

I think that's the case on all of them. The code under review here
is what parses the dma-ranges property in order to put the correct
value into the per-device structure.

	Arnd

[PATCH v3 4/7] of: configure the platform device dma parameters

[Santosh Shilimkar]

On Tuesday 06 May 2014 05:54 AM, Arnd Bergmann wrote:
> On Tuesday 06 May 2014 13:44:38 Benjamin Herrenschmidt wrote:
>> On Mon, 2014-05-05 at 16:28 -0600, Bjorn Helgaas wrote:
>>> I still wonder whether arm, powerpc, and tile (and I just noticed
>>> microblaze also has a similar dma_direct_map_page()) could all be
>>> handled by attaching devices to a generic trivial IOMMU driver
>>> parameterized with the appropriate constant offset.
> 

[..]

> It may be easier to replace set_arch_dma_coherent_ops() with
> a generic function that handles all cases:
> 
> int set_arch_dma_ops(struct device *dev, bool coherent,
> 		phys_addr_t offset, struct device_node *iommu);
> 
> and let the architecture handle the cases it needs.
> 
>> On powerpc, the offset is not constant, it can be per-device.
> 
> I think that's the case on all of them. The code under review here
> is what parses the dma-ranges property in order to put the correct
> value into the per-device structure.
> 
Yep. The per-device property need is one of the reason, we added the
information to struct device. The constant need not be same though
on keystone it is same for all devices.

Regards,
Santosh

[PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Santosh Shilimkar]

From: Grygorii Strashko <grygorii.strashko@ti.com>

In most of cases DMA addresses can be performed using offset value of
 Bus address space relatively to physical address space as following:

PFN->DMA:
 __pfn_to_phys(pfn + [-]dma_pfn_offset)

DMA->PFN:
 __phys_to_pfn(dma_addr) + [-]dma_pfn_offset

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/include/asm/dma-mapping.h |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index e701a4d..424fda9 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -58,22 +58,35 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return (dma_addr_t)__pfn_to_bus(pfn);
+	if (!dev)
+		return (dma_addr_t)__pfn_to_bus(pfn);
+	else
+		return (dma_addr_t)__pfn_to_bus(pfn - dev->dma_pfn_offset);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __bus_to_pfn(addr);
+	if (!dev)
+		return __bus_to_pfn(addr);
+	else
+		return __bus_to_pfn(addr) + dev->dma_pfn_offset;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
 {
-	return (void *)__bus_to_virt((unsigned long)addr);
+	if (!dev)
+		return (void *)__bus_to_virt((unsigned long)addr);
+	else
+		return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
 }
 
 static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 {
-	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
+	if (!dev)
+		return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
+	else
+		return pfn_to_dma(dev,
+				__bus_to_pfn(__virt_to_bus((unsigned long)(addr))));
 }
 
 #else
-- 
1.7.9.5

[PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Rob Herring]

On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> In most of cases DMA addresses can be performed using offset value of
>  Bus address space relatively to physical address space as following:
>
> PFN->DMA:
>  __pfn_to_phys(pfn + [-]dma_pfn_offset)
>
> DMA->PFN:
>  __phys_to_pfn(dma_addr) + [-]dma_pfn_offset
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Reviewed-by: Rob Herring <robh@kernel.org>

> ---
>  arch/arm/include/asm/dma-mapping.h |   21 +++++++++++++++++----
>  1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index e701a4d..424fda9 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -58,22 +58,35 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>  #ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -       return (dma_addr_t)__pfn_to_bus(pfn);
> +       if (!dev)
> +               return (dma_addr_t)__pfn_to_bus(pfn);
> +       else
> +               return (dma_addr_t)__pfn_to_bus(pfn - dev->dma_pfn_offset);
>  }
>
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -       return __bus_to_pfn(addr);
> +       if (!dev)
> +               return __bus_to_pfn(addr);
> +       else
> +               return __bus_to_pfn(addr) + dev->dma_pfn_offset;
>  }
>
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>  {
> -       return (void *)__bus_to_virt((unsigned long)addr);
> +       if (!dev)
> +               return (void *)__bus_to_virt((unsigned long)addr);
> +       else
> +               return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
>  }
>
>  static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  {
> -       return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> +       if (!dev)
> +               return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> +       else
> +               return pfn_to_dma(dev,
> +                               __bus_to_pfn(__virt_to_bus((unsigned long)(addr))));
>  }
>
>  #else
> --
> 1.7.9.5
>

[PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Russell King - ARM Linux]

On Thu, Apr 24, 2014 at 11:30:05AM -0400, Santosh Shilimkar wrote:
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index e701a4d..424fda9 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -58,22 +58,35 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>  #ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return (dma_addr_t)__pfn_to_bus(pfn);
> +	if (!dev)
> +		return (dma_addr_t)__pfn_to_bus(pfn);
> +	else
> +		return (dma_addr_t)__pfn_to_bus(pfn - dev->dma_pfn_offset);

I really don't trust gcc to do this right, so I think it would be better
to make life easier on the compiler:

	if (dev)
		pfn -= dev->dma_pfn_offset;
	return (dma_addr_t)__pfn_to_bus(pfn);

>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __bus_to_pfn(addr);
> +	if (!dev)
> +		return __bus_to_pfn(addr);
> +	else
> +		return __bus_to_pfn(addr) + dev->dma_pfn_offset;

and:

	unsigned long pfn = __bus_to_pfn(addr);

	if (dev)
		pfn += dev->dma_pfn_offset;

	return pfn;

>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>  {
> -	return (void *)__bus_to_virt((unsigned long)addr);
> +	if (!dev)
> +		return (void *)__bus_to_virt((unsigned long)addr);
> +	else
> +		return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));

This is quite horrendous.  There's easier ways to do this...  I assume
you haven't looked at the assembler resulting from this at all with
stuff like the p2v patching enabled?

>  }
>  
>  static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  {
> -	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> +	if (!dev)
> +		return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> +	else
> +		return pfn_to_dma(dev,
> +				__bus_to_pfn(__virt_to_bus((unsigned long)(addr))));

Same here.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Santosh Shilimkar]

On Friday 02 May 2014 10:58 AM, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 11:30:05AM -0400, Santosh Shilimkar wrote:
>> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
>> index e701a4d..424fda9 100644
>> --- a/arch/arm/include/asm/dma-mapping.h
>> +++ b/arch/arm/include/asm/dma-mapping.h
>> @@ -58,22 +58,35 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>>  #ifndef __arch_pfn_to_dma
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return (dma_addr_t)__pfn_to_bus(pfn);
>> +	if (!dev)
>> +		return (dma_addr_t)__pfn_to_bus(pfn);
>> +	else
>> +		return (dma_addr_t)__pfn_to_bus(pfn - dev->dma_pfn_offset);
> 
> I really don't trust gcc to do this right, so I think it would be better
> to make life easier on the compiler:
> 
> 	if (dev)
> 		pfn -= dev->dma_pfn_offset;
> 	return (dma_addr_t)__pfn_to_bus(pfn);
> 
This looks better. Will udpate with above.

>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __bus_to_pfn(addr);
>> +	if (!dev)
>> +		return __bus_to_pfn(addr);
>> +	else
>> +		return __bus_to_pfn(addr) + dev->dma_pfn_offset;
> 
> and:
> 
> 	unsigned long pfn = __bus_to_pfn(addr);
> 
> 	if (dev)
> 		pfn += dev->dma_pfn_offset;
> 
> 	return pfn;
> 
Ok..

>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>>  {
>> -	return (void *)__bus_to_virt((unsigned long)addr);
>> +	if (!dev)
>> +		return (void *)__bus_to_virt((unsigned long)addr);
>> +	else
>> +		return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
> 
> This is quite horrendous.  There's easier ways to do this...  I assume
> you haven't looked at the assembler resulting from this at all with
> stuff like the p2v patching enabled?
> 
I haven't. Will check.

>>  }
>>  
>>  static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  {
>> -	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>> +	if (!dev)
>> +		return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>> +	else
>> +		return pfn_to_dma(dev,
>> +				__bus_to_pfn(__virt_to_bus((unsigned long)(addr))));
> 
> Same here.
> 
ok.

Thanks !!

Regards,
Santosh

[PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Russell King - ARM Linux]

On Fri, May 02, 2014 at 11:05:16AM -0400, Santosh Shilimkar wrote:
> On Friday 02 May 2014 10:58 AM, Russell King - ARM Linux wrote:
> > On Thu, Apr 24, 2014 at 11:30:05AM -0400, Santosh Shilimkar wrote:
> >>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> >>  {
> >> -	return (void *)__bus_to_virt((unsigned long)addr);
> >> +	if (!dev)
> >> +		return (void *)__bus_to_virt((unsigned long)addr);
> >> +	else
> >> +		return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
> > 
> > This is quite horrendous.  There's easier ways to do this...  I assume
> > you haven't looked at the assembler resulting from this at all with
> > stuff like the p2v patching enabled?
> > 
> I haven't. Will check.

	if (dev) {
		unsigned long pfn = dma_to_pfn(dev, addr);

		return phys_to_virt(__pfn_to_phys(pfn));
	}

	return (void *)__bus_to_virt((unsigned long)addr);

> >>  static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
> >>  {
> >> -	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> >> +	if (!dev)
> >> +		return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> >> +	else
> >> +		return pfn_to_dma(dev,
> >> +				__bus_to_pfn(__virt_to_bus((unsigned long)(addr))));
> > 
> > Same here.
> > 
> ok.


	if (dev)
		return pfn_to_dma(dev, virt_to_pfn(addr));

	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Santosh Shilimkar]

On Monday 05 May 2014 03:50 PM, Russell King - ARM Linux wrote:
> On Fri, May 02, 2014 at 11:05:16AM -0400, Santosh Shilimkar wrote:
>> On Friday 02 May 2014 10:58 AM, Russell King - ARM Linux wrote:
>>> On Thu, Apr 24, 2014 at 11:30:05AM -0400, Santosh Shilimkar wrote:
>>>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>>>>  {
>>>> -	return (void *)__bus_to_virt((unsigned long)addr);
>>>> +	if (!dev)
>>>> +		return (void *)__bus_to_virt((unsigned long)addr);
>>>> +	else
>>>> +		return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
>>>
>>> This is quite horrendous.  There's easier ways to do this...  I assume
>>> you haven't looked at the assembler resulting from this at all with
>>> stuff like the p2v patching enabled?
>>>
>> I haven't. Will check.
> 
> 	if (dev) {
> 		unsigned long pfn = dma_to_pfn(dev, addr);
> 
> 		return phys_to_virt(__pfn_to_phys(pfn));
> 	}
> 
> 	return (void *)__bus_to_virt((unsigned long)addr);
> 
Thanks a lot Russell. Updated patch below for archive records.

>From 97a6f063270265d03ffcb010b9dc156b274631e7 Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Thu, 24 Apr 2014 11:30:05 -0400
Subject: [PATCH v3 5/7] ARM: dma: Use dma_pfn_offset for dma address
 translation

In most of cases DMA addresses can be performed using offset value of
 Bus address space relatively to physical address space as following:

PFN->DMA:
 __pfn_to_phys(pfn + [-]dma_pfn_offset)

DMA->PFN:
 __phys_to_pfn(dma_addr) + [-]dma_pfn_offset

Thanks to Russell King for suggesting the optimised macro's for
conversion.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/include/asm/dma-mapping.h |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index e701a4d..b0c79fd 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -58,21 +58,37 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
+	if (dev)
+		pfn -= dev->dma_pfn_offset;
 	return (dma_addr_t)__pfn_to_bus(pfn);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __bus_to_pfn(addr);
+	unsigned long pfn = __bus_to_pfn(addr);
+
+	if (dev)
+		pfn += dev->dma_pfn_offset;
+
+	return pfn;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
 {
+	if (dev) {
+		unsigned long pfn = dma_to_pfn(dev, addr);
+
+		return phys_to_virt(__pfn_to_phys(pfn));
+	}
+
 	return (void *)__bus_to_virt((unsigned long)addr);
 }
 
 static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 {
+	if (dev)
+		return pfn_to_dma(dev, virt_to_pfn(addr));
+
 	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
 }
 
-- 
1.7.9.5

[PATCH v3 6/7] ARM: dma: implement set_arch_dma_coherent_ops()

[Santosh Shilimkar]

Implement the set_arch_dma_coherent_ops() for ARM architecture.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/include/asm/dma-mapping.h |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 424fda9..1965cd8 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -118,6 +118,13 @@ static inline unsigned long dma_max_pfn(struct device *dev)
 }
 #define dma_max_pfn(dev) dma_max_pfn(dev)
 
+static inline int set_arch_dma_coherent_ops(struct device *dev)
+{
+	set_dma_ops(dev, &arm_coherent_dma_ops);
+	return 0;
+}
+#define set_arch_dma_coherent_ops(dev)	set_arch_dma_coherent_ops(dev)
+
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
 	unsigned int offset = paddr & ~PAGE_MASK;
-- 
1.7.9.5

[PATCH v3 6/7] ARM: dma: implement set_arch_dma_coherent_ops()

[Rob Herring]

On Thu, Apr 24, 2014 at 10:30 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Implement the set_arch_dma_coherent_ops() for ARM architecture.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Reviewed-by: Rob Herring <robh@kernel.org>

> ---
>  arch/arm/include/asm/dma-mapping.h |    7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 424fda9..1965cd8 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -118,6 +118,13 @@ static inline unsigned long dma_max_pfn(struct device *dev)
>  }
>  #define dma_max_pfn(dev) dma_max_pfn(dev)
>
> +static inline int set_arch_dma_coherent_ops(struct device *dev)
> +{
> +       set_dma_ops(dev, &arm_coherent_dma_ops);
> +       return 0;
> +}
> +#define set_arch_dma_coherent_ops(dev) set_arch_dma_coherent_ops(dev)
> +
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>  {
>         unsigned int offset = paddr & ~PAGE_MASK;
> --
> 1.7.9.5
>

[PATCH v3 7/7] ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]

[Santosh Shilimkar]

On a 32 bit ARM architecture with LPAE extension physical addresses
cannot fit into unsigned long variable.

So fix it by using phys_addr_t instead of unsigned long.

Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mm/dma-mapping.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f62aa06..5260f43 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -885,7 +885,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
 static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
 	size_t size, enum dma_data_direction dir)
 {
-	unsigned long paddr;
+	phys_addr_t paddr;
 
 	dma_cache_maint_page(page, off, size, dir, dmac_map_area);
 
@@ -901,7 +901,7 @@ static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
 static void __dma_page_dev_to_cpu(struct page *page, unsigned long off,
 	size_t size, enum dma_data_direction dir)
 {
-	unsigned long paddr = page_to_phys(page) + off;
+	phys_addr_t paddr = page_to_phys(page) + off;
 
 	/* FIXME: non-speculating: not required */
 	/* don't bother invalidating if DMA to device */
-- 
1.7.9.5

[PATCH v3 7/7] ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]

[Will Deacon]

On Thu, Apr 24, 2014 at 04:30:07PM +0100, Santosh Shilimkar wrote:
> On a 32 bit ARM architecture with LPAE extension physical addresses
> cannot fit into unsigned long variable.
> 
> So fix it by using phys_addr_t instead of unsigned long.
> 
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  arch/arm/mm/dma-mapping.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Will Deacon <will.deacon@arm.com>

Will

> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index f62aa06..5260f43 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -885,7 +885,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
>  static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
>  	size_t size, enum dma_data_direction dir)
>  {
> -	unsigned long paddr;
> +	phys_addr_t paddr;
>  
>  	dma_cache_maint_page(page, off, size, dir, dmac_map_area);
>  
> @@ -901,7 +901,7 @@ static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
>  static void __dma_page_dev_to_cpu(struct page *page, unsigned long off,
>  	size_t size, enum dma_data_direction dir)
>  {
> -	unsigned long paddr = page_to_phys(page) + off;
> +	phys_addr_t paddr = page_to_phys(page) + off;
>  
>  	/* FIXME: non-speculating: not required */
>  	/* don't bother invalidating if DMA to device */
> -- 
> 1.7.9.5
> 
> 

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

Rob, Russell,

On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
> Here is an updated v3 of the series. Series introduces support for setting up
> dma parameters based on device tree properties like 'dma-ranges' and
> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
> series can be found here [3], [2] and [1].
> 
> The 'dma-ranges' helps to take care of few DMAable system memory restrictions
> by use of dma_pfn_offset which we maintain now per device. Arch code then
> uses it for dma address translations for such cases. We update the
> dma_pfn_offset accordingly during DT the device creation process.The
> 'dma-coherent' property is used to setup arch's coherent dma_ops.
> 
> Hopefully with acks, tested-by this version can get into 3.16 queue. I will
> post a followup series for Keystone SOC which will use this infrastructure.
> Linus W also wants to use this for ARM integrator platform dma offset issue.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> 
> Grygorii Strashko (2):
>   of: introduce of_dma_get_range() helper
>   ARM: dma: Use dma_pfn_offset for dma address translation
> 
> Santosh Shilimkar (5):
>   device: introduce per device dma_pfn_offset
>   of: introduce of_dma_is_coherent() helper
>   of: configure the platform device dma parameters
>   ARM: dma: implement set_arch_dma_coherent_ops()
>   ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
> 
>  arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
>  arch/arm/mm/dma-mapping.c          |    4 +-
>  drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
>  drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
>  include/linux/device.h             |    2 +
>  include/linux/dma-mapping.h        |    7 +++
>  include/linux/of_address.h         |    8 ++++
>  include/linux/of_platform.h        |    6 +++
>  8 files changed, 204 insertions(+), 9 deletions(-)
> 
How do we go about merging this series ? There is a dependency
between the patches and hence the question.

> 
> [1] http://www.spinics.net/lists/arm-kernel/msg311678.html
> [2] https://lkml.org/lkml/2014/3/6/186
> [3] https://lkml.org/lkml/2014/4/19/80
> 

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Russell King - ARM Linux]

On Thu, May 01, 2014 at 09:19:18AM -0400, Santosh Shilimkar wrote:
> Rob, Russell,
> 
> On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
> > Here is an updated v3 of the series. Series introduces support for setting up
> > dma parameters based on device tree properties like 'dma-ranges' and
> > 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
> > series can be found here [3], [2] and [1].
> > 
> > The 'dma-ranges' helps to take care of few DMAable system memory restrictions
> > by use of dma_pfn_offset which we maintain now per device. Arch code then
> > uses it for dma address translations for such cases. We update the
> > dma_pfn_offset accordingly during DT the device creation process.The
> > 'dma-coherent' property is used to setup arch's coherent dma_ops.
> > 
> > Hopefully with acks, tested-by this version can get into 3.16 queue. I will
> > post a followup series for Keystone SOC which will use this infrastructure.
> > Linus W also wants to use this for ARM integrator platform dma offset issue.
> > 
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> > 
> > Grygorii Strashko (2):
> >   of: introduce of_dma_get_range() helper
> >   ARM: dma: Use dma_pfn_offset for dma address translation
> > 
> > Santosh Shilimkar (5):
> >   device: introduce per device dma_pfn_offset
> >   of: introduce of_dma_is_coherent() helper
> >   of: configure the platform device dma parameters
> >   ARM: dma: implement set_arch_dma_coherent_ops()
> >   ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
> > 
> >  arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
> >  arch/arm/mm/dma-mapping.c          |    4 +-
> >  drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
> >  drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
> >  include/linux/device.h             |    2 +
> >  include/linux/dma-mapping.h        |    7 +++
> >  include/linux/of_address.h         |    8 ++++
> >  include/linux/of_platform.h        |    6 +++
> >  8 files changed, 204 insertions(+), 9 deletions(-)
> > 
> How do we go about merging this series ? There is a dependency
> between the patches and hence the question.

I don't know anymore.  People today want to assert exclusive rights over
parts of the kernel tree, which makes this kind of cross-patching rather
impossible.

The only workable solution I can see is the long winded way to split the
series up, merge the first set of dependencies in one merge window, and
hold the rest back for the following merge window.  Not ideal, but it
stops the arguments.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

On Thursday 01 May 2014 09:25 AM, Russell King - ARM Linux wrote:
> On Thu, May 01, 2014 at 09:19:18AM -0400, Santosh Shilimkar wrote:
>> Rob, Russell,
>>
>> On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
>>> Here is an updated v3 of the series. Series introduces support for setting up
>>> dma parameters based on device tree properties like 'dma-ranges' and
>>> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
>>> series can be found here [3], [2] and [1].
>>>
>>> The 'dma-ranges' helps to take care of few DMAable system memory restrictions
>>> by use of dma_pfn_offset which we maintain now per device. Arch code then
>>> uses it for dma address translations for such cases. We update the
>>> dma_pfn_offset accordingly during DT the device creation process.The
>>> 'dma-coherent' property is used to setup arch's coherent dma_ops.
>>>
>>> Hopefully with acks, tested-by this version can get into 3.16 queue. I will
>>> post a followup series for Keystone SOC which will use this infrastructure.
>>> Linus W also wants to use this for ARM integrator platform dma offset issue.
>>>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> Cc: Grant Likely <grant.likely@linaro.org>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
>>>
>>> Grygorii Strashko (2):
>>>   of: introduce of_dma_get_range() helper
>>>   ARM: dma: Use dma_pfn_offset for dma address translation
>>>
>>> Santosh Shilimkar (5):
>>>   device: introduce per device dma_pfn_offset
>>>   of: introduce of_dma_is_coherent() helper
>>>   of: configure the platform device dma parameters
>>>   ARM: dma: implement set_arch_dma_coherent_ops()
>>>   ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
>>>
>>>  arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
>>>  arch/arm/mm/dma-mapping.c          |    4 +-
>>>  drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
>>>  drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
>>>  include/linux/device.h             |    2 +
>>>  include/linux/dma-mapping.h        |    7 +++
>>>  include/linux/of_address.h         |    8 ++++
>>>  include/linux/of_platform.h        |    6 +++
>>>  8 files changed, 204 insertions(+), 9 deletions(-)
>>>
>> How do we go about merging this series ? There is a dependency
>> between the patches and hence the question.
> 
> I don't know anymore.  People today want to assert exclusive rights over
> parts of the kernel tree, which makes this kind of cross-patching rather
> impossible.
> 
> The only workable solution I can see is the long winded way to split the
> series up, merge the first set of dependencies in one merge window, and
> hold the rest back for the following merge window.  Not ideal, but it
> stops the arguments.
> 
I really hope we don't have to go this route. I think since the changes
as such used for ARM arch for now, if we get this series via your tree
or arm-soc which pulls your tree, things should work. I also have small
series on the list on top of $subject series which enables coherency
for Keystone.

Regards,
Santosh

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Rob Herring]

On Thu, May 1, 2014 at 8:25 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 01, 2014 at 09:19:18AM -0400, Santosh Shilimkar wrote:
>> Rob, Russell,
>>
>> On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
>> > Here is an updated v3 of the series. Series introduces support for setting up
>> > dma parameters based on device tree properties like 'dma-ranges' and
>> > 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
>> > series can be found here [3], [2] and [1].
>> >
>> > The 'dma-ranges' helps to take care of few DMAable system memory restrictions
>> > by use of dma_pfn_offset which we maintain now per device. Arch code then
>> > uses it for dma address translations for such cases. We update the
>> > dma_pfn_offset accordingly during DT the device creation process.The
>> > 'dma-coherent' property is used to setup arch's coherent dma_ops.
>> >
>> > Hopefully with acks, tested-by this version can get into 3.16 queue. I will
>> > post a followup series for Keystone SOC which will use this infrastructure.
>> > Linus W also wants to use this for ARM integrator platform dma offset issue.
>> >
>> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > Cc: Russell King <linux@arm.linux.org.uk>
>> > Cc: Arnd Bergmann <arnd@arndb.de>
>> > Cc: Olof Johansson <olof@lixom.net>
>> > Cc: Grant Likely <grant.likely@linaro.org>
>> > Cc: Rob Herring <robh+dt@kernel.org>
>> > Cc: Catalin Marinas <catalin.marinas@arm.com>
>> > Cc: Linus Walleij <linus.walleij@linaro.org>
>> > Cc: Grygorii Strashko <grygorii.strashko@ti.com>
>> >
>> > Grygorii Strashko (2):
>> >   of: introduce of_dma_get_range() helper
>> >   ARM: dma: Use dma_pfn_offset for dma address translation
>> >
>> > Santosh Shilimkar (5):
>> >   device: introduce per device dma_pfn_offset
>> >   of: introduce of_dma_is_coherent() helper
>> >   of: configure the platform device dma parameters
>> >   ARM: dma: implement set_arch_dma_coherent_ops()
>> >   ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
>> >
>> >  arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
>> >  arch/arm/mm/dma-mapping.c          |    4 +-
>> >  drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
>> >  drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
>> >  include/linux/device.h             |    2 +
>> >  include/linux/dma-mapping.h        |    7 +++
>> >  include/linux/of_address.h         |    8 ++++
>> >  include/linux/of_platform.h        |    6 +++
>> >  8 files changed, 204 insertions(+), 9 deletions(-)
>> >
>> How do we go about merging this series ? There is a dependency
>> between the patches and hence the question.
>
> I don't know anymore.  People today want to assert exclusive rights over
> parts of the kernel tree, which makes this kind of cross-patching rather
> impossible.

I can take this series or provide an ack for the DT parts. Either way
it does not matter to me.

> The only workable solution I can see is the long winded way to split the
> series up, merge the first set of dependencies in one merge window, and
> hold the rest back for the following merge window.  Not ideal, but it
> stops the arguments.

That should not be necessary. We should be able to sort this out as it
is not a difficult problem.

Rob

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

On Friday 02 May 2014 10:41 AM, Rob Herring wrote:
> On Thu, May 1, 2014 at 8:25 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Thu, May 01, 2014 at 09:19:18AM -0400, Santosh Shilimkar wrote:
>>> Rob, Russell,
>>>
>>> On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
>>>> Here is an updated v3 of the series. Series introduces support for setting up
>>>> dma parameters based on device tree properties like 'dma-ranges' and
>>>> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
>>>> series can be found here [3], [2] and [1].
>>>>
>>>> The 'dma-ranges' helps to take care of few DMAable system memory restrictions
>>>> by use of dma_pfn_offset which we maintain now per device. Arch code then
>>>> uses it for dma address translations for such cases. We update the
>>>> dma_pfn_offset accordingly during DT the device creation process.The
>>>> 'dma-coherent' property is used to setup arch's coherent dma_ops.
>>>>
>>>> Hopefully with acks, tested-by this version can get into 3.16 queue. I will
>>>> post a followup series for Keystone SOC which will use this infrastructure.
>>>> Linus W also wants to use this for ARM integrator platform dma offset issue.
>>>>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>> Cc: Olof Johansson <olof@lixom.net>
>>>> Cc: Grant Likely <grant.likely@linaro.org>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
>>>>
>>>> Grygorii Strashko (2):
>>>>   of: introduce of_dma_get_range() helper
>>>>   ARM: dma: Use dma_pfn_offset for dma address translation
>>>>
>>>> Santosh Shilimkar (5):
>>>>   device: introduce per device dma_pfn_offset
>>>>   of: introduce of_dma_is_coherent() helper
>>>>   of: configure the platform device dma parameters
>>>>   ARM: dma: implement set_arch_dma_coherent_ops()
>>>>   ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
>>>>
>>>>  arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
>>>>  arch/arm/mm/dma-mapping.c          |    4 +-
>>>>  drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
>>>>  drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
>>>>  include/linux/device.h             |    2 +
>>>>  include/linux/dma-mapping.h        |    7 +++
>>>>  include/linux/of_address.h         |    8 ++++
>>>>  include/linux/of_platform.h        |    6 +++
>>>>  8 files changed, 204 insertions(+), 9 deletions(-)
>>>>
>>> How do we go about merging this series ? There is a dependency
>>> between the patches and hence the question.
>>
>> I don't know anymore.  People today want to assert exclusive rights over
>> parts of the kernel tree, which makes this kind of cross-patching rather
>> impossible.
> 
> I can take this series or provide an ack for the DT parts. Either way
> it does not matter to me.
> 
>> The only workable solution I can see is the long winded way to split the
>> series up, merge the first set of dependencies in one merge window, and
>> hold the rest back for the following merge window.  Not ideal, but it
>> stops the arguments.
> 
> That should not be necessary. We should be able to sort this out as it
> is not a difficult problem.
> 
yeah. After addressing those few minor comments, I will create a pull
request for both RMK and arm-soc to pull from with your ack. That way
I can also add keystone specific parts on top of this series to arm-soc.

Regards,
Santosh  

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Grant Likely]

On Thu, 1 May 2014 14:25:16 +0100, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, May 01, 2014 at 09:19:18AM -0400, Santosh Shilimkar wrote:
> > Rob, Russell,
> > 
> > On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
> > > Here is an updated v3 of the series. Series introduces support for setting up
> > > dma parameters based on device tree properties like 'dma-ranges' and
> > > 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
> > > series can be found here [3], [2] and [1].
> > > 
> > > The 'dma-ranges' helps to take care of few DMAable system memory restrictions
> > > by use of dma_pfn_offset which we maintain now per device. Arch code then
> > > uses it for dma address translations for such cases. We update the
> > > dma_pfn_offset accordingly during DT the device creation process.The
> > > 'dma-coherent' property is used to setup arch's coherent dma_ops.
> > > 
> > > Hopefully with acks, tested-by this version can get into 3.16 queue. I will
> > > post a followup series for Keystone SOC which will use this infrastructure.
> > > Linus W also wants to use this for ARM integrator platform dma offset issue.
> > > 
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Olof Johansson <olof@lixom.net>
> > > Cc: Grant Likely <grant.likely@linaro.org>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> > > 
> > > Grygorii Strashko (2):
> > >   of: introduce of_dma_get_range() helper
> > >   ARM: dma: Use dma_pfn_offset for dma address translation
> > > 
> > > Santosh Shilimkar (5):
> > >   device: introduce per device dma_pfn_offset
> > >   of: introduce of_dma_is_coherent() helper
> > >   of: configure the platform device dma parameters
> > >   ARM: dma: implement set_arch_dma_coherent_ops()
> > >   ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
> > > 
> > >  arch/arm/include/asm/dma-mapping.h |   28 ++++++++++--
> > >  arch/arm/mm/dma-mapping.c          |    4 +-
> > >  drivers/of/address.c               |   87 ++++++++++++++++++++++++++++++++++++
> > >  drivers/of/platform.c              |   71 +++++++++++++++++++++++++++--
> > >  include/linux/device.h             |    2 +
> > >  include/linux/dma-mapping.h        |    7 +++
> > >  include/linux/of_address.h         |    8 ++++
> > >  include/linux/of_platform.h        |    6 +++
> > >  8 files changed, 204 insertions(+), 9 deletions(-)
> > > 
> > How do we go about merging this series ? There is a dependency
> > between the patches and hence the question.
> 
> I don't know anymore.  People today want to assert exclusive rights over
> parts of the kernel tree, which makes this kind of cross-patching rather
> impossible.

And you can tell those people to go-perch. (I have no idea what that
actually means. something my mother always says).

If everyone is okay then I would be fine with taking the whole series
through my tree, or you can put my ack on it and send it through the ARM tree.

g.
> 
> The only workable solution I can see is the long winded way to split the
> series up, merge the first set of dependencies in one merge window, and
> hold the rest back for the following merge window.  Not ideal, but it
> stops the arguments.
> 
> -- 
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Shawn Guo]

On Thu, Apr 24, 2014 at 11:30:00AM -0400, Santosh Shilimkar wrote:
> Here is an updated v3 of the series. Series introduces support for setting up
> dma parameters based on device tree properties like 'dma-ranges' and
> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
> series can be found here [3], [2] and [1].

Are these two generic device tree properties documented somewhere under
Documentation/devicetree/bindings?

Shawn

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

On Monday 02 June 2014 02:37 AM, Shawn Guo wrote:
> On Thu, Apr 24, 2014 at 11:30:00AM -0400, Santosh Shilimkar wrote:
>> Here is an updated v3 of the series. Series introduces support for setting up
>> dma parameters based on device tree properties like 'dma-ranges' and
>> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
>> series can be found here [3], [2] and [1].
> 
> Are these two generic device tree properties documented somewhere under
> Documentation/devicetree/bindings?
> 
These bindings have been already in use before this series. But looks like
they have not been documented. I will do a patch to add description for those
couple of parameters.

Regards,
Santosh

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Arnd Bergmann]

On Monday 02 June 2014 09:24:50 Santosh Shilimkar wrote:
> On Monday 02 June 2014 02:37 AM, Shawn Guo wrote:
> > On Thu, Apr 24, 2014 at 11:30:00AM -0400, Santosh Shilimkar wrote:
> >> Here is an updated v3 of the series. Series introduces support for setting up
> >> dma parameters based on device tree properties like 'dma-ranges' and
> >> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
> >> series can be found here [3], [2] and [1].
> > 
> > Are these two generic device tree properties documented somewhere under
> > Documentation/devicetree/bindings?
> > 
> These bindings have been already in use before this series. But looks like
> they have not been documented. I will do a patch to add description for those
> couple of parameters.

dma-ranges is part of ePAPR, and was documented in some ieee-1275 addenda
before that, but I agree it would be nice to have something in kernel as
well, at the minimum something pointing to the relevant documents.

	Arnd

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

Arnd,

On Monday 02 June 2014 11:06 AM, Arnd Bergmann wrote:
> On Monday 02 June 2014 09:24:50 Santosh Shilimkar wrote:
>> On Monday 02 June 2014 02:37 AM, Shawn Guo wrote:
>>> On Thu, Apr 24, 2014 at 11:30:00AM -0400, Santosh Shilimkar wrote:
>>>> Here is an updated v3 of the series. Series introduces support for setting up
>>>> dma parameters based on device tree properties like 'dma-ranges' and
>>>> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
>>>> series can be found here [3], [2] and [1].
>>>
>>> Are these two generic device tree properties documented somewhere under
>>> Documentation/devicetree/bindings?
>>>
>> These bindings have been already in use before this series. But looks like
>> they have not been documented. I will do a patch to add description for those
>> couple of parameters.
> 
> dma-ranges is part of ePAPR, and was documented in some ieee-1275 addenda
> before that, but I agree it would be nice to have something in kernel as
> well, at the minimum something pointing to the relevant documents.
> 
We are thinking of updating 'Documentation/devicetree/bindings/dma/dma.txt'
to add the information for these extra two parameters.

Is that fine or any other suggestion ?

Regards,
Santosh

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Arnd Bergmann]

On Monday 02 June 2014 11:54:36 Santosh Shilimkar wrote:
> 
> On Monday 02 June 2014 11:06 AM, Arnd Bergmann wrote:
> > On Monday 02 June 2014 09:24:50 Santosh Shilimkar wrote:
> >> On Monday 02 June 2014 02:37 AM, Shawn Guo wrote:
> >>> On Thu, Apr 24, 2014 at 11:30:00AM -0400, Santosh Shilimkar wrote:
> >>>> Here is an updated v3 of the series. Series introduces support for setting up
> >>>> dma parameters based on device tree properties like 'dma-ranges' and
> >>>> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
> >>>> series can be found here [3], [2] and [1].
> >>>
> >>> Are these two generic device tree properties documented somewhere under
> >>> Documentation/devicetree/bindings?
> >>>
> >> These bindings have been already in use before this series. But looks like
> >> they have not been documented. I will do a patch to add description for those
> >> couple of parameters.
> > 
> > dma-ranges is part of ePAPR, and was documented in some ieee-1275 addenda
> > before that, but I agree it would be nice to have something in kernel as
> > well, at the minimum something pointing to the relevant documents.
> > 
> We are thinking of updating 'Documentation/devicetree/bindings/dma/dma.txt'
> to add the information for these extra two parameters.
> 
> Is that fine or any other suggestion ?

I think that's the wrong place. That entire directory currently deals with
the specific case of DMA engines, as opposed to the more DMA bus mastering
in general. We could rename that to
Documentation/devicetree/bindings/dmaengine, but renames tend to cause
extra patch conficts, so I'd prefer finding another location for this.

How about a section in the top-level
Documentation/devicetree/booting-without-of.txt file? After all, this
is very generic and can impact any device that acts as a bus master.

	Arnd

[PATCH v3 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Santosh Shilimkar]

On Monday 02 June 2014 03:00 PM, Arnd Bergmann wrote:
> On Monday 02 June 2014 11:54:36 Santosh Shilimkar wrote:
>>
>> On Monday 02 June 2014 11:06 AM, Arnd Bergmann wrote:
>>> On Monday 02 June 2014 09:24:50 Santosh Shilimkar wrote:
>>>> On Monday 02 June 2014 02:37 AM, Shawn Guo wrote:
>>>>> On Thu, Apr 24, 2014 at 11:30:00AM -0400, Santosh Shilimkar wrote:
>>>>>> Here is an updated v3 of the series. Series introduces support for setting up
>>>>>> dma parameters based on device tree properties like 'dma-ranges' and
>>>>>> 'dma-coherent' and also update to ARM 32 bit port. Earlier version of the
>>>>>> series can be found here [3], [2] and [1].
>>>>>
>>>>> Are these two generic device tree properties documented somewhere under
>>>>> Documentation/devicetree/bindings?
>>>>>
>>>> These bindings have been already in use before this series. But looks like
>>>> they have not been documented. I will do a patch to add description for those
>>>> couple of parameters.
>>>
>>> dma-ranges is part of ePAPR, and was documented in some ieee-1275 addenda
>>> before that, but I agree it would be nice to have something in kernel as
>>> well, at the minimum something pointing to the relevant documents.
>>>
>> We are thinking of updating 'Documentation/devicetree/bindings/dma/dma.txt'
>> to add the information for these extra two parameters.
>>
>> Is that fine or any other suggestion ?
> 
> I think that's the wrong place. That entire directory currently deals with
> the specific case of DMA engines, as opposed to the more DMA bus mastering
> in general. We could rename that to
> Documentation/devicetree/bindings/dmaengine, but renames tend to cause
> extra patch conficts, so I'd prefer finding another location for this.
> 
ok.

> How about a section in the top-level
> Documentation/devicetree/booting-without-of.txt file? After all, this
> is very generic and can impact any device that acts as a bus master.
> 
Sounds good. I can add it a section there with heading something like below.

VIII - Specifying dma bus information

Regards,
Santosh