[PATCH v5 0/6] UIO driver for APM X-Gene QMTM

[PATCH v5 0/6] UIO driver for APM X-Gene QMTM

[Ankit Jindal]

This patchset enables user space access to APM X-Gene QMTM
using UIO framework.

The patchset also introduces new type UIO_MEM_PHYS_CACHE
for mem regions because APM X-Gene QMTM device supports
cache coherency with CPU caches.

Changes since v4:
 - Fixed typos in dt-binding documentation.

Changes since v3:
 - Renamed qpool to qpool-memory in dt-binding.
 - Some cleanups in dt-binding documentation.

Changes since v2:
 - Formatting cleanups.
 - Remove qmtm_cleanup().

Changes since v1:
 - Factor-out formating related change in uio/uio.c as separate patch.
 - Use devm_xxx() APIs where appilicable.
 - Some cleanups and buggy loop fixed in qmtm_reset().
 - Removed open and release functions.
 - Use phandle for specifying QMTM qpool resource.
 - Removed "uio" from the compatible string.
 - Added more information about QMTM in binding documentation.


Ankit Jindal (6):
  uio: code style cleanup
  uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
  Documentation: Update documentation for UIO_MEM_PHYS_CACHE
  uio: Add X-Gene QMTM UIO driver
  Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO
    driver
  MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver

 Documentation/DocBook/uio-howto.tmpl               |    5 +-
 .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++
 MAINTAINERS                                        |    7 +
 drivers/uio/Kconfig                                |    8 +
 drivers/uio/Makefile                               |    1 +
 drivers/uio/uio.c                                  |   23 +-
 drivers/uio/uio_xgene_qmtm.c                       |  271 ++++++++++++++++++++
 include/linux/uio_driver.h                         |    1 +
 8 files changed, 355 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

-- 
1.7.9.5

[PATCH v5 0/6] UIO driver for APM X-Gene QMTM

[Ankit Jindal]

This patchset enables user space access to APM X-Gene QMTM
using UIO framework.

The patchset also introduces new type UIO_MEM_PHYS_CACHE
for mem regions because APM X-Gene QMTM device supports
cache coherency with CPU caches.

Changes since v4:
 - Fixed typos in dt-binding documentation.

Changes since v3:
 - Renamed qpool to qpool-memory in dt-binding.
 - Some cleanups in dt-binding documentation.

Changes since v2:
 - Formatting cleanups.
 - Remove qmtm_cleanup().

Changes since v1:
 - Factor-out formating related change in uio/uio.c as separate patch.
 - Use devm_xxx() APIs where appilicable.
 - Some cleanups and buggy loop fixed in qmtm_reset().
 - Removed open and release functions.
 - Use phandle for specifying QMTM qpool resource.
 - Removed "uio" from the compatible string.
 - Added more information about QMTM in binding documentation.


Ankit Jindal (6):
  uio: code style cleanup
  uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
  Documentation: Update documentation for UIO_MEM_PHYS_CACHE
  uio: Add X-Gene QMTM UIO driver
  Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO
    driver
  MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver

 Documentation/DocBook/uio-howto.tmpl               |    5 +-
 .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++
 MAINTAINERS                                        |    7 +
 drivers/uio/Kconfig                                |    8 +
 drivers/uio/Makefile                               |    1 +
 drivers/uio/uio.c                                  |   23 +-
 drivers/uio/uio_xgene_qmtm.c                       |  271 ++++++++++++++++++++
 include/linux/uio_driver.h                         |    1 +
 8 files changed, 355 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

-- 
1.7.9.5

[PATCH v5 1/6] uio: code style cleanup

[Ankit Jindal]

This patch fixes the indentation of switch-case block in uio driver.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 drivers/uio/uio.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index a673e5b..97e6444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -706,13 +706,13 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 	}
 
 	switch (idev->info->mem[mi].memtype) {
-		case UIO_MEM_PHYS:
-			return uio_mmap_physical(vma);
-		case UIO_MEM_LOGICAL:
-		case UIO_MEM_VIRTUAL:
-			return uio_mmap_logical(vma);
-		default:
-			return -EINVAL;
+	case UIO_MEM_PHYS:
+		return uio_mmap_physical(vma);
+	case UIO_MEM_LOGICAL:
+	case UIO_MEM_VIRTUAL:
+		return uio_mmap_logical(vma);
+	default:
+		return -EINVAL;
 	}
 }
 
-- 
1.7.9.5

[PATCH v5 1/6] uio: code style cleanup

[Ankit Jindal]

This patch fixes the indentation of switch-case block in uio driver.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 drivers/uio/uio.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index a673e5b..97e6444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -706,13 +706,13 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 	}
 
 	switch (idev->info->mem[mi].memtype) {
-		case UIO_MEM_PHYS:
-			return uio_mmap_physical(vma);
-		case UIO_MEM_LOGICAL:
-		case UIO_MEM_VIRTUAL:
-			return uio_mmap_logical(vma);
-		default:
-			return -EINVAL;
+	case UIO_MEM_PHYS:
+		return uio_mmap_physical(vma);
+	case UIO_MEM_LOGICAL:
+	case UIO_MEM_VIRTUAL:
+		return uio_mmap_logical(vma);
+	default:
+		return -EINVAL;
 	}
 }
 
-- 
1.7.9.5

[PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Ankit Jindal]

Currently, three types of mem regions are supported: UIO_MEM_PHYS,
UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
UIO driver export physcial memory to user space as non-cacheable
user memory. Typcially memory-mapped registers of a device are exported
to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
is not efficient if dma-capable devices are capable of maintaining coherency
with CPU caches.

This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
cacheable access to physical memory from user space.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 drivers/uio/uio.c          |   11 ++++++++---
 include/linux/uio_driver.h |    1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 97e6444..120a84b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
 #endif
 };
 
-static int uio_mmap_physical(struct vm_area_struct *vma)
+static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
 {
 	struct uio_device *idev = vma->vm_private_data;
 	int mi = uio_find_mem_index(vma);
@@ -659,7 +659,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 		return -EINVAL;
 
 	vma->vm_ops = &uio_physical_vm_ops;
-	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+	if (!cacheable)
+		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
 	/*
 	 * We cannot use the vm_iomap_memory() helper here,
@@ -707,10 +709,13 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 
 	switch (idev->info->mem[mi].memtype) {
 	case UIO_MEM_PHYS:
-		return uio_mmap_physical(vma);
+		return uio_mmap_physical(vma, false);
 	case UIO_MEM_LOGICAL:
 	case UIO_MEM_VIRTUAL:
 		return uio_mmap_logical(vma);
+	case UIO_MEM_PHYS_CACHE:
+		return uio_mmap_physical(vma, true);
+
 	default:
 		return -EINVAL;
 	}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..40ca3f3 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
 #define UIO_MEM_PHYS	1
 #define UIO_MEM_LOGICAL	2
 #define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_PHYS_CACHE	4
 
 /* defines for uio_port->porttype */
 #define UIO_PORT_NONE	0
-- 
1.7.9.5

[PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Ankit Jindal]

Currently, three types of mem regions are supported: UIO_MEM_PHYS,
UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
UIO driver export physcial memory to user space as non-cacheable
user memory. Typcially memory-mapped registers of a device are exported
to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
is not efficient if dma-capable devices are capable of maintaining coherency
with CPU caches.

This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
cacheable access to physical memory from user space.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 drivers/uio/uio.c          |   11 ++++++++---
 include/linux/uio_driver.h |    1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 97e6444..120a84b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
 #endif
 };
 
-static int uio_mmap_physical(struct vm_area_struct *vma)
+static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
 {
 	struct uio_device *idev = vma->vm_private_data;
 	int mi = uio_find_mem_index(vma);
@@ -659,7 +659,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 		return -EINVAL;
 
 	vma->vm_ops = &uio_physical_vm_ops;
-	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+	if (!cacheable)
+		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
 	/*
 	 * We cannot use the vm_iomap_memory() helper here,
@@ -707,10 +709,13 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 
 	switch (idev->info->mem[mi].memtype) {
 	case UIO_MEM_PHYS:
-		return uio_mmap_physical(vma);
+		return uio_mmap_physical(vma, false);
 	case UIO_MEM_LOGICAL:
 	case UIO_MEM_VIRTUAL:
 		return uio_mmap_logical(vma);
+	case UIO_MEM_PHYS_CACHE:
+		return uio_mmap_physical(vma, true);
+
 	default:
 		return -EINVAL;
 	}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..40ca3f3 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
 #define UIO_MEM_PHYS	1
 #define UIO_MEM_LOGICAL	2
 #define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_PHYS_CACHE	4
 
 /* defines for uio_port->porttype */
 #define UIO_PORT_NONE	0
-- 
1.7.9.5

[PATCH v5 3/6] Documentation: Update documentation for UIO_MEM_PHYS_CACHE

[Ankit Jindal]

This patch updates UIO documentation for new mem region
type UIO_MEM_PHYS_CACHE.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 Documentation/DocBook/uio-howto.tmpl |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index bbe9c1f..baa9185 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,8 +529,9 @@ the memory region, it will show up in the corresponding sysfs node.
 <varname>int memtype</varname>: Required if the mapping is used. Set this to
 <varname>UIO_MEM_PHYS</varname> if you you have physical memory on your
 card to be mapped. Use <varname>UIO_MEM_LOGICAL</varname> for logical
-memory (e.g. allocated with <function>kmalloc()</function>). There's also
-<varname>UIO_MEM_VIRTUAL</varname> for virtual memory.
+memory (e.g. allocated with <function>kmalloc()</function>). There are also
+<varname>UIO_MEM_VIRTUAL</varname> for virtual memory, and
+<varname>UIO_MEM_PHYS_CACHE</varname> for cacheable access to physical memory.
 </para></listitem>
 
 <listitem><para>
-- 
1.7.9.5

[PATCH v5 3/6] Documentation: Update documentation for UIO_MEM_PHYS_CACHE

[Ankit Jindal]

This patch updates UIO documentation for new mem region
type UIO_MEM_PHYS_CACHE.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 Documentation/DocBook/uio-howto.tmpl |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index bbe9c1f..baa9185 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,8 +529,9 @@ the memory region, it will show up in the corresponding sysfs node.
 <varname>int memtype</varname>: Required if the mapping is used. Set this to
 <varname>UIO_MEM_PHYS</varname> if you you have physical memory on your
 card to be mapped. Use <varname>UIO_MEM_LOGICAL</varname> for logical
-memory (e.g. allocated with <function>kmalloc()</function>). There's also
-<varname>UIO_MEM_VIRTUAL</varname> for virtual memory.
+memory (e.g. allocated with <function>kmalloc()</function>). There are also
+<varname>UIO_MEM_VIRTUAL</varname> for virtual memory, and
+<varname>UIO_MEM_PHYS_CACHE</varname> for cacheable access to physical memory.
 </para></listitem>
 
 <listitem><para>
-- 
1.7.9.5

[PATCH v5 4/6] uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.

This patch allows user space access to X-Gene QMTM device.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 drivers/uio/Kconfig          |    8 ++
 drivers/uio/Makefile         |    1 +
 drivers/uio/uio_xgene_qmtm.c |  271 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 280 insertions(+)
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 5a90914..76b1858 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -135,4 +135,12 @@ config UIO_MF624
 
 	  If you compile this as a module, it will be called uio_mf624.
 
+config UIO_XGENE_QMTM
+	tristate "Applied Micro X-Gene QMTM driver"
+	depends on OF
+	help
+	  Userspace I/O interface for the X-Gene QMTM. The userspace part of
+	  this driver will be available for download from the Applied Micro
+	  web site (http://www.apm.com/).
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d3218bd..633eaa0 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
 obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
 obj-$(CONFIG_UIO_MF624)         += uio_mf624.o
+obj-$(CONFIG_UIO_XGENE_QMTM)	+= uio_xgene_qmtm.o
diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
new file mode 100644
index 0000000..0695eb2a
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,271 @@
+/*
+ * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
+ *
+ * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
+ *
+ * Copyright (C) 2014 Applied Micro - http://www.apm.com/
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uio_driver.h>
+
+#define DRV_NAME "qmtm_uio"
+#define DRV_VERSION "1.0"
+
+#define QMTM_CFG_MEM_RAM_SHUTDOWN	0x0000d070
+
+#define QMTM_DEFAULT_QSIZE		65536
+
+struct uio_qmtm_dev {
+	struct uio_info *info;
+	struct clk *qmtm_clk;
+};
+
+/* QMTM CSR read/write routine */
+static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
+		u32 data)
+{
+	void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+	writel(data, addr + offset);
+}
+
+static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
+{
+	void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+	return readl(addr + offset);
+}
+
+static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
+{
+	u32 val;
+	int wait = 1000;
+
+	/* reset the internal memory of the device */
+	qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
+
+	/* check whether device internal memory is out of reset or not */
+	while (wait--) {
+		val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
+
+		if (val != 0xffffffff)
+			return 0;
+
+		udelay(1);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int qmtm_probe(struct platform_device *pdev)
+{
+	struct uio_info *info;
+	struct uio_qmtm_dev *qmtm_dev;
+	struct resource *csr;
+	struct resource *fabric;
+	struct resource qpool;
+	unsigned int num_queues;
+	unsigned int devid;
+	phandle qpool_phandle;
+	struct device_node *qpool_node;
+	int ret;
+
+	qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
+				GFP_KERNEL);
+	if (!qmtm_dev)
+		return -ENOMEM;
+
+	qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+	if (!qmtm_dev->info)
+		return -ENOMEM;
+
+	/* Power on qmtm in case its not done as part of boot-loader */
+	qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(qmtm_dev->qmtm_clk)) {
+		dev_err(&pdev->dev, "Failed to get clock\n");
+		ret = PTR_ERR(qmtm_dev->qmtm_clk);
+		return ret;
+	}
+
+	csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!csr) {
+		ret = -ENODEV;
+		dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
+		goto out_err;
+	}
+
+	if (!csr->start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid CSR resource\n");
+		goto out_err;
+	}
+
+	fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!fabric) {
+		ret = -ENODEV;
+		dev_err(&pdev->dev, "No QMTM Fabric resource specified\n");
+		goto out_err;
+	}
+
+	if (!fabric->start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid Fabric resource\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "qpool-memory",
+					&qpool_phandle);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No qpool-memory resource specified\n");
+		goto out_err;
+	}
+
+	qpool_node = of_find_node_by_phandle(qpool_phandle);
+	if (IS_ERR_OR_NULL(qpool_node)) {
+		ret = PTR_ERR(qpool_node);
+		dev_err(&pdev->dev, "Failed to get node by phandle\n");
+		goto out_err;
+	}
+
+	ret = of_address_to_resource(qpool_node, 0, &qpool);
+
+	of_node_put(qpool_node);
+
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to get qpool resource from node\n");
+		goto out_err;
+	}
+
+	if (!qpool.start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid qpool resource\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "num-queues",
+			&num_queues);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No num-queues resource specified\n");
+		goto out_err;
+	}
+
+	/* check whether sufficient memory is provided for the given queues */
+	if (num_queues * QMTM_DEFAULT_QSIZE > resource_size(&qpool)) {
+		ret = -ENOSPC;
+		dev_err(&pdev->dev, "Insufficient Qpool for the given queues\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "devid", &devid);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No devid resource specified\n");
+		goto out_err;
+	}
+
+	info = qmtm_dev->info;
+	info->mem[0].name = "csr";
+	info->mem[0].addr = csr->start;
+	info->mem[0].size = resource_size(csr);
+	info->mem[0].memtype = UIO_MEM_PHYS;
+	info->mem[0].internal_addr = devm_ioremap_resource(&pdev->dev, csr);
+
+	if (IS_ERR(info->mem[0].internal_addr)) {
+		ret = PTR_ERR(info->mem[0].internal_addr);
+		dev_err(&pdev->dev, "Failed to ioremap CSR region\n");
+		goto out_err;
+	}
+
+	info->mem[1].name = "fabric";
+	info->mem[1].addr = fabric->start;
+	info->mem[1].size = resource_size(fabric);
+	info->mem[1].memtype = UIO_MEM_PHYS;
+
+	info->mem[2].name = "qpool";
+	info->mem[2].addr = qpool.start;
+	info->mem[2].size = resource_size(&qpool);
+	info->mem[2].memtype = UIO_MEM_PHYS_CACHE;
+
+	info->name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "qmtm%d", devid);
+	info->version = DRV_VERSION;
+
+	info->priv = qmtm_dev;
+
+	/* enable the clock */
+	clk_prepare_enable(qmtm_dev->qmtm_clk);
+
+	/* get the qmtm out of reset */
+	ret = qmtm_reset(qmtm_dev);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to reset QMTM\n");
+		goto out_clk;
+	}
+
+	/* register with uio framework */
+	ret = uio_register_device(&pdev->dev, info);
+	if (ret < 0)
+		goto out_clk;
+
+	platform_set_drvdata(pdev, qmtm_dev);
+	return 0;
+
+out_clk:
+	clk_disable_unprepare(qmtm_dev->qmtm_clk);
+
+out_err:
+	return ret;
+}
+
+static int qmtm_remove(struct platform_device *pdev)
+{
+	struct uio_qmtm_dev *qmtm_dev = platform_get_drvdata(pdev);
+	struct uio_info *info = qmtm_dev->info;
+
+	uio_unregister_device(info);
+
+	clk_disable_unprepare(qmtm_dev->qmtm_clk);
+
+	return 0;
+}
+
+static struct of_device_id qmtm_match[] = {
+	{.compatible = "apm,xgene-qmtm",},
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, qmtm_match);
+
+static struct platform_driver qmtm_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.of_match_table = qmtm_match,
+	},
+	.probe = qmtm_probe,
+	.remove = qmtm_remove,
+};
+
+module_platform_driver(qmtm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Ankit Jindal <ankit.jindal@linaro.org>");
+MODULE_AUTHOR("Tushar Jagad <tushar.jagad@linaro.org>");
-- 
1.7.9.5

[PATCH v5 4/6] uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.

This patch allows user space access to X-Gene QMTM device.

Signed-off-by: Ankit Jindal <ankit.jindal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Tushar Jagad <tushar.jagad-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/uio/Kconfig          |    8 ++
 drivers/uio/Makefile         |    1 +
 drivers/uio/uio_xgene_qmtm.c |  271 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 280 insertions(+)
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 5a90914..76b1858 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -135,4 +135,12 @@ config UIO_MF624
 
 	  If you compile this as a module, it will be called uio_mf624.
 
+config UIO_XGENE_QMTM
+	tristate "Applied Micro X-Gene QMTM driver"
+	depends on OF
+	help
+	  Userspace I/O interface for the X-Gene QMTM. The userspace part of
+	  this driver will be available for download from the Applied Micro
+	  web site (http://www.apm.com/).
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d3218bd..633eaa0 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
 obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
 obj-$(CONFIG_UIO_MF624)         += uio_mf624.o
+obj-$(CONFIG_UIO_XGENE_QMTM)	+= uio_xgene_qmtm.o
diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
new file mode 100644
index 0000000..0695eb2a
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,271 @@
+/*
+ * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
+ *
+ * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
+ *
+ * Copyright (C) 2014 Applied Micro - http://www.apm.com/
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uio_driver.h>
+
+#define DRV_NAME "qmtm_uio"
+#define DRV_VERSION "1.0"
+
+#define QMTM_CFG_MEM_RAM_SHUTDOWN	0x0000d070
+
+#define QMTM_DEFAULT_QSIZE		65536
+
+struct uio_qmtm_dev {
+	struct uio_info *info;
+	struct clk *qmtm_clk;
+};
+
+/* QMTM CSR read/write routine */
+static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
+		u32 data)
+{
+	void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+	writel(data, addr + offset);
+}
+
+static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
+{
+	void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+	return readl(addr + offset);
+}
+
+static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
+{
+	u32 val;
+	int wait = 1000;
+
+	/* reset the internal memory of the device */
+	qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
+
+	/* check whether device internal memory is out of reset or not */
+	while (wait--) {
+		val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
+
+		if (val != 0xffffffff)
+			return 0;
+
+		udelay(1);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int qmtm_probe(struct platform_device *pdev)
+{
+	struct uio_info *info;
+	struct uio_qmtm_dev *qmtm_dev;
+	struct resource *csr;
+	struct resource *fabric;
+	struct resource qpool;
+	unsigned int num_queues;
+	unsigned int devid;
+	phandle qpool_phandle;
+	struct device_node *qpool_node;
+	int ret;
+
+	qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
+				GFP_KERNEL);
+	if (!qmtm_dev)
+		return -ENOMEM;
+
+	qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+	if (!qmtm_dev->info)
+		return -ENOMEM;
+
+	/* Power on qmtm in case its not done as part of boot-loader */
+	qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(qmtm_dev->qmtm_clk)) {
+		dev_err(&pdev->dev, "Failed to get clock\n");
+		ret = PTR_ERR(qmtm_dev->qmtm_clk);
+		return ret;
+	}
+
+	csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!csr) {
+		ret = -ENODEV;
+		dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
+		goto out_err;
+	}
+
+	if (!csr->start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid CSR resource\n");
+		goto out_err;
+	}
+
+	fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!fabric) {
+		ret = -ENODEV;
+		dev_err(&pdev->dev, "No QMTM Fabric resource specified\n");
+		goto out_err;
+	}
+
+	if (!fabric->start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid Fabric resource\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "qpool-memory",
+					&qpool_phandle);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No qpool-memory resource specified\n");
+		goto out_err;
+	}
+
+	qpool_node = of_find_node_by_phandle(qpool_phandle);
+	if (IS_ERR_OR_NULL(qpool_node)) {
+		ret = PTR_ERR(qpool_node);
+		dev_err(&pdev->dev, "Failed to get node by phandle\n");
+		goto out_err;
+	}
+
+	ret = of_address_to_resource(qpool_node, 0, &qpool);
+
+	of_node_put(qpool_node);
+
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to get qpool resource from node\n");
+		goto out_err;
+	}
+
+	if (!qpool.start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid qpool resource\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "num-queues",
+			&num_queues);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No num-queues resource specified\n");
+		goto out_err;
+	}
+
+	/* check whether sufficient memory is provided for the given queues */
+	if (num_queues * QMTM_DEFAULT_QSIZE > resource_size(&qpool)) {
+		ret = -ENOSPC;
+		dev_err(&pdev->dev, "Insufficient Qpool for the given queues\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "devid", &devid);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No devid resource specified\n");
+		goto out_err;
+	}
+
+	info = qmtm_dev->info;
+	info->mem[0].name = "csr";
+	info->mem[0].addr = csr->start;
+	info->mem[0].size = resource_size(csr);
+	info->mem[0].memtype = UIO_MEM_PHYS;
+	info->mem[0].internal_addr = devm_ioremap_resource(&pdev->dev, csr);
+
+	if (IS_ERR(info->mem[0].internal_addr)) {
+		ret = PTR_ERR(info->mem[0].internal_addr);
+		dev_err(&pdev->dev, "Failed to ioremap CSR region\n");
+		goto out_err;
+	}
+
+	info->mem[1].name = "fabric";
+	info->mem[1].addr = fabric->start;
+	info->mem[1].size = resource_size(fabric);
+	info->mem[1].memtype = UIO_MEM_PHYS;
+
+	info->mem[2].name = "qpool";
+	info->mem[2].addr = qpool.start;
+	info->mem[2].size = resource_size(&qpool);
+	info->mem[2].memtype = UIO_MEM_PHYS_CACHE;
+
+	info->name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "qmtm%d", devid);
+	info->version = DRV_VERSION;
+
+	info->priv = qmtm_dev;
+
+	/* enable the clock */
+	clk_prepare_enable(qmtm_dev->qmtm_clk);
+
+	/* get the qmtm out of reset */
+	ret = qmtm_reset(qmtm_dev);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to reset QMTM\n");
+		goto out_clk;
+	}
+
+	/* register with uio framework */
+	ret = uio_register_device(&pdev->dev, info);
+	if (ret < 0)
+		goto out_clk;
+
+	platform_set_drvdata(pdev, qmtm_dev);
+	return 0;
+
+out_clk:
+	clk_disable_unprepare(qmtm_dev->qmtm_clk);
+
+out_err:
+	return ret;
+}
+
+static int qmtm_remove(struct platform_device *pdev)
+{
+	struct uio_qmtm_dev *qmtm_dev = platform_get_drvdata(pdev);
+	struct uio_info *info = qmtm_dev->info;
+
+	uio_unregister_device(info);
+
+	clk_disable_unprepare(qmtm_dev->qmtm_clk);
+
+	return 0;
+}
+
+static struct of_device_id qmtm_match[] = {
+	{.compatible = "apm,xgene-qmtm",},
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, qmtm_match);
+
+static struct platform_driver qmtm_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.of_match_table = qmtm_match,
+	},
+	.probe = qmtm_probe,
+	.remove = qmtm_remove,
+};
+
+module_platform_driver(qmtm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Ankit Jindal <ankit.jindal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
+MODULE_AUTHOR("Tushar Jagad <tushar.jagad-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/6] uio: Add X-Gene QMTM UIO driver

[Ankit Jindal]

The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.

This patch allows user space access to X-Gene QMTM device.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 drivers/uio/Kconfig          |    8 ++
 drivers/uio/Makefile         |    1 +
 drivers/uio/uio_xgene_qmtm.c |  271 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 280 insertions(+)
 create mode 100644 drivers/uio/uio_xgene_qmtm.c

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 5a90914..76b1858 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -135,4 +135,12 @@ config UIO_MF624
 
 	  If you compile this as a module, it will be called uio_mf624.
 
+config UIO_XGENE_QMTM
+	tristate "Applied Micro X-Gene QMTM driver"
+	depends on OF
+	help
+	  Userspace I/O interface for the X-Gene QMTM. The userspace part of
+	  this driver will be available for download from the Applied Micro
+	  web site (http://www.apm.com/).
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d3218bd..633eaa0 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC)	+= uio_pci_generic.o
 obj-$(CONFIG_UIO_NETX)	+= uio_netx.o
 obj-$(CONFIG_UIO_PRUSS)         += uio_pruss.o
 obj-$(CONFIG_UIO_MF624)         += uio_mf624.o
+obj-$(CONFIG_UIO_XGENE_QMTM)	+= uio_xgene_qmtm.o
diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
new file mode 100644
index 0000000..0695eb2a
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,271 @@
+/*
+ * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
+ *
+ * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
+ *
+ * Copyright (C) 2014 Applied Micro - http://www.apm.com/
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uio_driver.h>
+
+#define DRV_NAME "qmtm_uio"
+#define DRV_VERSION "1.0"
+
+#define QMTM_CFG_MEM_RAM_SHUTDOWN	0x0000d070
+
+#define QMTM_DEFAULT_QSIZE		65536
+
+struct uio_qmtm_dev {
+	struct uio_info *info;
+	struct clk *qmtm_clk;
+};
+
+/* QMTM CSR read/write routine */
+static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
+		u32 data)
+{
+	void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+	writel(data, addr + offset);
+}
+
+static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
+{
+	void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+	return readl(addr + offset);
+}
+
+static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
+{
+	u32 val;
+	int wait = 1000;
+
+	/* reset the internal memory of the device */
+	qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
+
+	/* check whether device internal memory is out of reset or not */
+	while (wait--) {
+		val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
+
+		if (val != 0xffffffff)
+			return 0;
+
+		udelay(1);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int qmtm_probe(struct platform_device *pdev)
+{
+	struct uio_info *info;
+	struct uio_qmtm_dev *qmtm_dev;
+	struct resource *csr;
+	struct resource *fabric;
+	struct resource qpool;
+	unsigned int num_queues;
+	unsigned int devid;
+	phandle qpool_phandle;
+	struct device_node *qpool_node;
+	int ret;
+
+	qmtm_dev = devm_kzalloc(&pdev->dev, sizeof(struct uio_qmtm_dev),
+				GFP_KERNEL);
+	if (!qmtm_dev)
+		return -ENOMEM;
+
+	qmtm_dev->info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+	if (!qmtm_dev->info)
+		return -ENOMEM;
+
+	/* Power on qmtm in case its not done as part of boot-loader */
+	qmtm_dev->qmtm_clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(qmtm_dev->qmtm_clk)) {
+		dev_err(&pdev->dev, "Failed to get clock\n");
+		ret = PTR_ERR(qmtm_dev->qmtm_clk);
+		return ret;
+	}
+
+	csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!csr) {
+		ret = -ENODEV;
+		dev_err(&pdev->dev, "No QMTM CSR resource specified\n");
+		goto out_err;
+	}
+
+	if (!csr->start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid CSR resource\n");
+		goto out_err;
+	}
+
+	fabric = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!fabric) {
+		ret = -ENODEV;
+		dev_err(&pdev->dev, "No QMTM Fabric resource specified\n");
+		goto out_err;
+	}
+
+	if (!fabric->start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid Fabric resource\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "qpool-memory",
+					&qpool_phandle);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No qpool-memory resource specified\n");
+		goto out_err;
+	}
+
+	qpool_node = of_find_node_by_phandle(qpool_phandle);
+	if (IS_ERR_OR_NULL(qpool_node)) {
+		ret = PTR_ERR(qpool_node);
+		dev_err(&pdev->dev, "Failed to get node by phandle\n");
+		goto out_err;
+	}
+
+	ret = of_address_to_resource(qpool_node, 0, &qpool);
+
+	of_node_put(qpool_node);
+
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to get qpool resource from node\n");
+		goto out_err;
+	}
+
+	if (!qpool.start) {
+		ret = -EINVAL;
+		dev_err(&pdev->dev, "Invalid qpool resource\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "num-queues",
+			&num_queues);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No num-queues resource specified\n");
+		goto out_err;
+	}
+
+	/* check whether sufficient memory is provided for the given queues */
+	if (num_queues * QMTM_DEFAULT_QSIZE > resource_size(&qpool)) {
+		ret = -ENOSPC;
+		dev_err(&pdev->dev, "Insufficient Qpool for the given queues\n");
+		goto out_err;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "devid", &devid);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No devid resource specified\n");
+		goto out_err;
+	}
+
+	info = qmtm_dev->info;
+	info->mem[0].name = "csr";
+	info->mem[0].addr = csr->start;
+	info->mem[0].size = resource_size(csr);
+	info->mem[0].memtype = UIO_MEM_PHYS;
+	info->mem[0].internal_addr = devm_ioremap_resource(&pdev->dev, csr);
+
+	if (IS_ERR(info->mem[0].internal_addr)) {
+		ret = PTR_ERR(info->mem[0].internal_addr);
+		dev_err(&pdev->dev, "Failed to ioremap CSR region\n");
+		goto out_err;
+	}
+
+	info->mem[1].name = "fabric";
+	info->mem[1].addr = fabric->start;
+	info->mem[1].size = resource_size(fabric);
+	info->mem[1].memtype = UIO_MEM_PHYS;
+
+	info->mem[2].name = "qpool";
+	info->mem[2].addr = qpool.start;
+	info->mem[2].size = resource_size(&qpool);
+	info->mem[2].memtype = UIO_MEM_PHYS_CACHE;
+
+	info->name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "qmtm%d", devid);
+	info->version = DRV_VERSION;
+
+	info->priv = qmtm_dev;
+
+	/* enable the clock */
+	clk_prepare_enable(qmtm_dev->qmtm_clk);
+
+	/* get the qmtm out of reset */
+	ret = qmtm_reset(qmtm_dev);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to reset QMTM\n");
+		goto out_clk;
+	}
+
+	/* register with uio framework */
+	ret = uio_register_device(&pdev->dev, info);
+	if (ret < 0)
+		goto out_clk;
+
+	platform_set_drvdata(pdev, qmtm_dev);
+	return 0;
+
+out_clk:
+	clk_disable_unprepare(qmtm_dev->qmtm_clk);
+
+out_err:
+	return ret;
+}
+
+static int qmtm_remove(struct platform_device *pdev)
+{
+	struct uio_qmtm_dev *qmtm_dev = platform_get_drvdata(pdev);
+	struct uio_info *info = qmtm_dev->info;
+
+	uio_unregister_device(info);
+
+	clk_disable_unprepare(qmtm_dev->qmtm_clk);
+
+	return 0;
+}
+
+static struct of_device_id qmtm_match[] = {
+	{.compatible = "apm,xgene-qmtm",},
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, qmtm_match);
+
+static struct platform_driver qmtm_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.of_match_table = qmtm_match,
+	},
+	.probe = qmtm_probe,
+	.remove = qmtm_remove,
+};
+
+module_platform_driver(qmtm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Ankit Jindal <ankit.jindal@linaro.org>");
+MODULE_AUTHOR("Tushar Jagad <tushar.jagad@linaro.org>");
-- 
1.7.9.5

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt

diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
new file mode 100644
index 0000000..7afe78c
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
@@ -0,0 +1,50 @@
+APM X-Gene QMTM nodes
+
+The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
+and Traffic manager). It is a device for managing hardware queues.
+It also implements QoS among hardware queues hence term "traffic"
+manager is present in its name.
+
+Required properties:
+- compatible: Should be "apm,xgene-qmtm"
+- reg: Address and length of the register set for the device. It contains the
+  information of registers in the same order as described by reg-names.
+- reg-names: Should contain the register set names
+  - "csr": QMTM control and status register address space.
+  - "fabric": QMTM memory mapped access to queue states.
+- qpool-memory: Points to the phandle of the node defining memory location for
+	 creating QMTM queues. This must point to the reserved-memory node
+	 (as-per reserved memory bindings). It is expected that size and
+	 location of qpool memory will be configurable via bootloader.
+- clocks: Reference to the clock entry.
+- num-queues: Number of queues under this QMTM device.
+- devid: QMTM identification number for the system having multiple QMTM devices.
+	 This is used to form a unique id (a tuple of queue number and
+	 device id) for the queues belonging to this device.
+
+Example:
+	qmtm1_uio_qpool: qmtm1_uio_qpool {
+		reg = <0x0 0x0 0x0 0x0>;
+	};
+
+	qmtm1clk: qmtmclk@1f20c000 {
+		compatible = "apm,xgene-device-clock";
+		clock-output-names = "qmtm1clk";
+	};
+
+	qmtm1_uio: qmtm_uio@1f200000 {
+		compatible = "apm,xgene-qmtm";
+		status = "disabled";
+		reg = <0x0 0x1f200000 0x0 0x10000>,
+		      <0x0 0x1b000000 0x0 0x400000>;
+		reg-names = "csr", "fabric";
+		qpool-memory = <&qmtm1_uio_qpool>;
+		clocks = <&qmtm1clk 0>;
+		num-queues = <0x400>;
+		devid = <1>;
+	};
+
+	/* Board-specific peripheral configurations */
+	&qmtm1_uio {
+		status = "okay";
+	};
-- 
1.7.9.5

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt

diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
new file mode 100644
index 0000000..7afe78c
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
@@ -0,0 +1,50 @@
+APM X-Gene QMTM nodes
+
+The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
+and Traffic manager). It is a device for managing hardware queues.
+It also implements QoS among hardware queues hence term "traffic"
+manager is present in its name.
+
+Required properties:
+- compatible: Should be "apm,xgene-qmtm"
+- reg: Address and length of the register set for the device. It contains the
+  information of registers in the same order as described by reg-names.
+- reg-names: Should contain the register set names
+  - "csr": QMTM control and status register address space.
+  - "fabric": QMTM memory mapped access to queue states.
+- qpool-memory: Points to the phandle of the node defining memory location for
+	 creating QMTM queues. This must point to the reserved-memory node
+	 (as-per reserved memory bindings). It is expected that size and
+	 location of qpool memory will be configurable via bootloader.
+- clocks: Reference to the clock entry.
+- num-queues: Number of queues under this QMTM device.
+- devid: QMTM identification number for the system having multiple QMTM devices.
+	 This is used to form a unique id (a tuple of queue number and
+	 device id) for the queues belonging to this device.
+
+Example:
+	qmtm1_uio_qpool: qmtm1_uio_qpool {
+		reg = <0x0 0x0 0x0 0x0>;
+	};
+
+	qmtm1clk: qmtmclk at 1f20c000 {
+		compatible = "apm,xgene-device-clock";
+		clock-output-names = "qmtm1clk";
+	};
+
+	qmtm1_uio: qmtm_uio at 1f200000 {
+		compatible = "apm,xgene-qmtm";
+		status = "disabled";
+		reg = <0x0 0x1f200000 0x0 0x10000>,
+		      <0x0 0x1b000000 0x0 0x400000>;
+		reg-names = "csr", "fabric";
+		qpool-memory = <&qmtm1_uio_qpool>;
+		clocks = <&qmtm1clk 0>;
+		num-queues = <0x400>;
+		devid = <1>;
+	};
+
+	/* Board-specific peripheral configurations */
+	&qmtm1_uio {
+		status = "okay";
+	};
-- 
1.7.9.5

[PATCH v5 6/6] MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver

[Ankit Jindal]

Add entry to maintainer list for APM X-Gene QMTM UIO driver.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 MAINTAINERS |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e7866a..138663f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -727,6 +727,13 @@ S:	Supported
 F:	drivers/net/ethernet/apm/xgene/
 F:	Documentation/devicetree/bindings/net/apm-xgene-enet.txt
 
+APPLIED MICRO (APM) X-GENE QMTM UIO DRIVER
+M:	Ankit Jindal <ankit.jindal@linaro.org>
+M:	Tushar Jagad <tushar.jagad@linaro.org>
+S:	Supported
+F:	drivers/uio/uio_xgene_qmtm.c
+F:	Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
+
 APTINA CAMERA SENSOR PLL
 M:	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
 L:	linux-media@vger.kernel.org
-- 
1.7.9.5

[PATCH v5 6/6] MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver

[Ankit Jindal]

Add entry to maintainer list for APM X-Gene QMTM UIO driver.

Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
---
 MAINTAINERS |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e7866a..138663f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -727,6 +727,13 @@ S:	Supported
 F:	drivers/net/ethernet/apm/xgene/
 F:	Documentation/devicetree/bindings/net/apm-xgene-enet.txt
 
+APPLIED MICRO (APM) X-GENE QMTM UIO DRIVER
+M:	Ankit Jindal <ankit.jindal@linaro.org>
+M:	Tushar Jagad <tushar.jagad@linaro.org>
+S:	Supported
+F:	drivers/uio/uio_xgene_qmtm.c
+F:	Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
+
 APTINA CAMERA SENSOR PLL
 M:	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
 L:	linux-media at vger.kernel.org
-- 
1.7.9.5

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Andreas Färber]

Am 17.11.2014 um 11:36 schrieb Ankit Jindal:
> This patch adds device tree binding documentation for
> X-Gene QMTM UIO driver.
> 
> Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
> Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
> ---
>  .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt

FWIW,

Reviewed-by: Andreas Färber <afaerber@suse.de>

Thanks,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Andreas Färber]

Am 17.11.2014 um 11:36 schrieb Ankit Jindal:
> This patch adds device tree binding documentation for
> X-Gene QMTM UIO driver.
> 
> Signed-off-by: Ankit Jindal <ankit.jindal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tushar Jagad <tushar.jagad-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt

FWIW,

Reviewed-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>

Thanks,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Andreas Färber]

Am 17.11.2014 um 11:36 schrieb Ankit Jindal:
> This patch adds device tree binding documentation for
> X-Gene QMTM UIO driver.
> 
> Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
> Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
> ---
>  .../devicetree/bindings/uio/uio_xgene_qmtm.txt     |   50 ++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt

FWIW,

Reviewed-by: Andreas F?rber <afaerber@suse.de>

Thanks,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 21284 AG N?rnberg

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Arnd Bergmann]

On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
> +
> +       qmtm1_uio: qmtm_uio@1f200000 {
> +               compatible = "apm,xgene-qmtm";
> +               status = "disabled";
> +               reg = <0x0 0x1f200000 0x0 0x10000>,
> +                     <0x0 0x1b000000 0x0 0x400000>;
> +               reg-names = "csr", "fabric";
> +               qpool-memory = <&qmtm1_uio_qpool>;
> +               clocks = <&qmtm1clk 0>;
> +               num-queues = <0x400>;
> +               devid = <1>;
> +       };
> +

To make my previous review comments clearer:

NAK

Do not create device nodes that are meant for a specific use case in
software and that are not usable for the common case. I don't think
it makes any sense to keep on submitting a UIO driver for this until
we have a proper network driver that uses this so we can make sure we
have a working binding.

	Arnd

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Arnd Bergmann]

On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
> +
> +       qmtm1_uio: qmtm_uio@1f200000 {
> +               compatible = "apm,xgene-qmtm";
> +               status = "disabled";
> +               reg = <0x0 0x1f200000 0x0 0x10000>,
> +                     <0x0 0x1b000000 0x0 0x400000>;
> +               reg-names = "csr", "fabric";
> +               qpool-memory = <&qmtm1_uio_qpool>;
> +               clocks = <&qmtm1clk 0>;
> +               num-queues = <0x400>;
> +               devid = <1>;
> +       };
> +

To make my previous review comments clearer:

NAK

Do not create device nodes that are meant for a specific use case in
software and that are not usable for the common case. I don't think
it makes any sense to keep on submitting a UIO driver for this until
we have a proper network driver that uses this so we can make sure we
have a working binding.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Arnd Bergmann]

On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
> +
> +       qmtm1_uio: qmtm_uio at 1f200000 {
> +               compatible = "apm,xgene-qmtm";
> +               status = "disabled";
> +               reg = <0x0 0x1f200000 0x0 0x10000>,
> +                     <0x0 0x1b000000 0x0 0x400000>;
> +               reg-names = "csr", "fabric";
> +               qpool-memory = <&qmtm1_uio_qpool>;
> +               clocks = <&qmtm1clk 0>;
> +               num-queues = <0x400>;
> +               devid = <1>;
> +       };
> +

To make my previous review comments clearer:

NAK

Do not create device nodes that are meant for a specific use case in
software and that are not usable for the common case. I don't think
it makes any sense to keep on submitting a UIO driver for this until
we have a proper network driver that uses this so we can make sure we
have a working binding.

	Arnd

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>> +
>> +       qmtm1_uio: qmtm_uio@1f200000 {
>> +               compatible = "apm,xgene-qmtm";
>> +               status = "disabled";
>> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>> +                     <0x0 0x1b000000 0x0 0x400000>;
>> +               reg-names = "csr", "fabric";
>> +               qpool-memory = <&qmtm1_uio_qpool>;
>> +               clocks = <&qmtm1clk 0>;
>> +               num-queues = <0x400>;
>> +               devid = <1>;
>> +       };
>> +
>
> To make my previous review comments clearer:
>
> NAK
>
> Do not create device nodes that are meant for a specific use case in
> software and that are not usable for the common case. I don't think
> it makes any sense to keep on submitting a UIO driver for this until
> we have a proper network driver that uses this so we can make sure we
> have a working binding.

The dataplane frameworks like OpenDataPlane etc, need to have access
to complete subsystem from the user space. Hence, we would like to
have this driver and some other UIO drivers to be the part of kernel
to have data plane frameworks working on our platform.

>
>         Arnd

Thanks,
Ankit

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 17 November 2014 16:47, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>> +
>> +       qmtm1_uio: qmtm_uio@1f200000 {
>> +               compatible = "apm,xgene-qmtm";
>> +               status = "disabled";
>> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>> +                     <0x0 0x1b000000 0x0 0x400000>;
>> +               reg-names = "csr", "fabric";
>> +               qpool-memory = <&qmtm1_uio_qpool>;
>> +               clocks = <&qmtm1clk 0>;
>> +               num-queues = <0x400>;
>> +               devid = <1>;
>> +       };
>> +
>
> To make my previous review comments clearer:
>
> NAK
>
> Do not create device nodes that are meant for a specific use case in
> software and that are not usable for the common case. I don't think
> it makes any sense to keep on submitting a UIO driver for this until
> we have a proper network driver that uses this so we can make sure we
> have a working binding.

The dataplane frameworks like OpenDataPlane etc, need to have access
to complete subsystem from the user space. Hence, we would like to
have this driver and some other UIO drivers to be the part of kernel
to have data plane frameworks working on our platform.

>
>         Arnd

Thanks,
Ankit
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>> +
>> +       qmtm1_uio: qmtm_uio at 1f200000 {
>> +               compatible = "apm,xgene-qmtm";
>> +               status = "disabled";
>> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>> +                     <0x0 0x1b000000 0x0 0x400000>;
>> +               reg-names = "csr", "fabric";
>> +               qpool-memory = <&qmtm1_uio_qpool>;
>> +               clocks = <&qmtm1clk 0>;
>> +               num-queues = <0x400>;
>> +               devid = <1>;
>> +       };
>> +
>
> To make my previous review comments clearer:
>
> NAK
>
> Do not create device nodes that are meant for a specific use case in
> software and that are not usable for the common case. I don't think
> it makes any sense to keep on submitting a UIO driver for this until
> we have a proper network driver that uses this so we can make sure we
> have a working binding.

The dataplane frameworks like OpenDataPlane etc, need to have access
to complete subsystem from the user space. Hence, we would like to
have this driver and some other UIO drivers to be the part of kernel
to have data plane frameworks working on our platform.

>
>         Arnd

Thanks,
Ankit

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Arnd Bergmann]

On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
> >> +
> >> +       qmtm1_uio: qmtm_uio@1f200000 {
> >> +               compatible = "apm,xgene-qmtm";
> >> +               status = "disabled";
> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
> >> +                     <0x0 0x1b000000 0x0 0x400000>;
> >> +               reg-names = "csr", "fabric";
> >> +               qpool-memory = <&qmtm1_uio_qpool>;
> >> +               clocks = <&qmtm1clk 0>;
> >> +               num-queues = <0x400>;
> >> +               devid = <1>;
> >> +       };
> >> +
> >
> > To make my previous review comments clearer:
> >
> > NAK
> >
> > Do not create device nodes that are meant for a specific use case in
> > software and that are not usable for the common case. I don't think
> > it makes any sense to keep on submitting a UIO driver for this until
> > we have a proper network driver that uses this so we can make sure we
> > have a working binding.
> 
> The dataplane frameworks like OpenDataPlane etc, need to have access
> to complete subsystem from the user space. Hence, we would like to
> have this driver and some other UIO drivers to be the part of kernel
> to have data plane frameworks working on our platform.

Please work with the people that do the in-kernel QMTM driver to come
up with a common binding then.

	Arnd

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Arnd Bergmann]

On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
> On 17 November 2014 16:47, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
> >> +
> >> +       qmtm1_uio: qmtm_uio@1f200000 {
> >> +               compatible = "apm,xgene-qmtm";
> >> +               status = "disabled";
> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
> >> +                     <0x0 0x1b000000 0x0 0x400000>;
> >> +               reg-names = "csr", "fabric";
> >> +               qpool-memory = <&qmtm1_uio_qpool>;
> >> +               clocks = <&qmtm1clk 0>;
> >> +               num-queues = <0x400>;
> >> +               devid = <1>;
> >> +       };
> >> +
> >
> > To make my previous review comments clearer:
> >
> > NAK
> >
> > Do not create device nodes that are meant for a specific use case in
> > software and that are not usable for the common case. I don't think
> > it makes any sense to keep on submitting a UIO driver for this until
> > we have a proper network driver that uses this so we can make sure we
> > have a working binding.
> 
> The dataplane frameworks like OpenDataPlane etc, need to have access
> to complete subsystem from the user space. Hence, we would like to
> have this driver and some other UIO drivers to be the part of kernel
> to have data plane frameworks working on our platform.

Please work with the people that do the in-kernel QMTM driver to come
up with a common binding then.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Arnd Bergmann]

On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
> >> +
> >> +       qmtm1_uio: qmtm_uio at 1f200000 {
> >> +               compatible = "apm,xgene-qmtm";
> >> +               status = "disabled";
> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
> >> +                     <0x0 0x1b000000 0x0 0x400000>;
> >> +               reg-names = "csr", "fabric";
> >> +               qpool-memory = <&qmtm1_uio_qpool>;
> >> +               clocks = <&qmtm1clk 0>;
> >> +               num-queues = <0x400>;
> >> +               devid = <1>;
> >> +       };
> >> +
> >
> > To make my previous review comments clearer:
> >
> > NAK
> >
> > Do not create device nodes that are meant for a specific use case in
> > software and that are not usable for the common case. I don't think
> > it makes any sense to keep on submitting a UIO driver for this until
> > we have a proper network driver that uses this so we can make sure we
> > have a working binding.
> 
> The dataplane frameworks like OpenDataPlane etc, need to have access
> to complete subsystem from the user space. Hence, we would like to
> have this driver and some other UIO drivers to be the part of kernel
> to have data plane frameworks working on our platform.

Please work with the people that do the in-kernel QMTM driver to come
up with a common binding then.

	Arnd

Re: [PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Greg Kroah-Hartman]

On Mon, Nov 17, 2014 at 04:06:08PM +0530, Ankit Jindal wrote:
> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
> UIO driver export physcial memory to user space as non-cacheable
> user memory. Typcially memory-mapped registers of a device are exported
> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
> is not efficient if dma-capable devices are capable of maintaining coherency
> with CPU caches.

Not efficient in what way?

> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
> cacheable access to physical memory from user space.
> 
> Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
> Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
> ---
>  drivers/uio/uio.c          |   11 ++++++++---
>  include/linux/uio_driver.h |    1 +
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 97e6444..120a84b 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
>  #endif
>  };
>  
> -static int uio_mmap_physical(struct vm_area_struct *vma)
> +static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)

I despise "bool" flags in a function, as they don't give any idea of
what is going on when you see the function being called.  Please create
a new function that does this properly, with a correct name, if it's
needed.

thanks,

greg k-h

[PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Greg Kroah-Hartman]

On Mon, Nov 17, 2014 at 04:06:08PM +0530, Ankit Jindal wrote:
> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
> UIO driver export physcial memory to user space as non-cacheable
> user memory. Typcially memory-mapped registers of a device are exported
> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
> is not efficient if dma-capable devices are capable of maintaining coherency
> with CPU caches.

Not efficient in what way?

> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
> cacheable access to physical memory from user space.
> 
> Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
> Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
> ---
>  drivers/uio/uio.c          |   11 ++++++++---
>  include/linux/uio_driver.h |    1 +
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 97e6444..120a84b 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
>  #endif
>  };
>  
> -static int uio_mmap_physical(struct vm_area_struct *vma)
> +static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)

I despise "bool" flags in a function, as they don't give any idea of
what is going on when you see the function being called.  Please create
a new function that does this properly, with a correct name, if it's
needed.

thanks,

greg k-h

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 18 November 2014 at 18:40, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>> >> +
>> >> +       qmtm1_uio: qmtm_uio@1f200000 {
>> >> +               compatible = "apm,xgene-qmtm";
>> >> +               status = "disabled";
>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>> >> +               reg-names = "csr", "fabric";
>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>> >> +               clocks = <&qmtm1clk 0>;
>> >> +               num-queues = <0x400>;
>> >> +               devid = <1>;
>> >> +       };
>> >> +
>> >
>> > To make my previous review comments clearer:
>> >
>> > NAK
>> >
>> > Do not create device nodes that are meant for a specific use case in
>> > software and that are not usable for the common case. I don't think
>> > it makes any sense to keep on submitting a UIO driver for this until
>> > we have a proper network driver that uses this so we can make sure we
>> > have a working binding.
>>
>> The dataplane frameworks like OpenDataPlane etc, need to have access
>> to complete subsystem from the user space. Hence, we would like to
>> have this driver and some other UIO drivers to be the part of kernel
>> to have data plane frameworks working on our platform.
>
> Please work with the people that do the in-kernel QMTM driver to come
> up with a common binding then.
Thanks Arnd, I have synced with them, and in future our dt bindings
for this device is going to be inline with the one mentioned in the
patchset.
>
>         Arnd
Thanks,
Ankit

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 18 November 2014 at 18:40, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>> >> +
>> >> +       qmtm1_uio: qmtm_uio at 1f200000 {
>> >> +               compatible = "apm,xgene-qmtm";
>> >> +               status = "disabled";
>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>> >> +               reg-names = "csr", "fabric";
>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>> >> +               clocks = <&qmtm1clk 0>;
>> >> +               num-queues = <0x400>;
>> >> +               devid = <1>;
>> >> +       };
>> >> +
>> >
>> > To make my previous review comments clearer:
>> >
>> > NAK
>> >
>> > Do not create device nodes that are meant for a specific use case in
>> > software and that are not usable for the common case. I don't think
>> > it makes any sense to keep on submitting a UIO driver for this until
>> > we have a proper network driver that uses this so we can make sure we
>> > have a working binding.
>>
>> The dataplane frameworks like OpenDataPlane etc, need to have access
>> to complete subsystem from the user space. Hence, we would like to
>> have this driver and some other UIO drivers to be the part of kernel
>> to have data plane frameworks working on our platform.
>
> Please work with the people that do the in-kernel QMTM driver to come
> up with a common binding then.
Thanks Arnd, I have synced with them, and in future our dt bindings
for this device is going to be inline with the one mentioned in the
patchset.
>
>         Arnd
Thanks,
Ankit

Re: [PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Ankit Jindal]

On 27 November 2014 at 05:31, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Nov 17, 2014 at 04:06:08PM +0530, Ankit Jindal wrote:
>> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
>> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
>> UIO driver export physcial memory to user space as non-cacheable
>> user memory. Typcially memory-mapped registers of a device are exported
>> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
>> is not efficient if dma-capable devices are capable of maintaining coherency
>> with CPU caches.
>
> Not efficient in what way?
Sorry, I will rephrase this.
>
>> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
>> cacheable access to physical memory from user space.
>>
>> Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
>> Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
>> ---
>>  drivers/uio/uio.c          |   11 ++++++++---
>>  include/linux/uio_driver.h |    1 +
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index 97e6444..120a84b 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
>>  #endif
>>  };
>>
>> -static int uio_mmap_physical(struct vm_area_struct *vma)
>> +static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
>
> I despise "bool" flags in a function, as they don't give any idea of
> what is going on when you see the function being called.  Please create
> a new function that does this properly, with a correct name, if it's
> needed.
Sure, will take care of this in next revision.
>
> thanks,
>
> greg k-h
Thanks,
Ankit

Re: [PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Ankit Jindal]

On 27 November 2014 at 05:31, Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Mon, Nov 17, 2014 at 04:06:08PM +0530, Ankit Jindal wrote:
>> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
>> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
>> UIO driver export physcial memory to user space as non-cacheable
>> user memory. Typcially memory-mapped registers of a device are exported
>> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
>> is not efficient if dma-capable devices are capable of maintaining coherency
>> with CPU caches.
>
> Not efficient in what way?
Sorry, I will rephrase this.
>
>> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
>> cacheable access to physical memory from user space.
>>
>> Signed-off-by: Ankit Jindal <ankit.jindal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Tushar Jagad <tushar.jagad-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>>  drivers/uio/uio.c          |   11 ++++++++---
>>  include/linux/uio_driver.h |    1 +
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index 97e6444..120a84b 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
>>  #endif
>>  };
>>
>> -static int uio_mmap_physical(struct vm_area_struct *vma)
>> +static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
>
> I despise "bool" flags in a function, as they don't give any idea of
> what is going on when you see the function being called.  Please create
> a new function that does this properly, with a correct name, if it's
> needed.
Sure, will take care of this in next revision.
>
> thanks,
>
> greg k-h
Thanks,
Ankit
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Ankit Jindal]

On 27 November 2014 at 05:31, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Nov 17, 2014 at 04:06:08PM +0530, Ankit Jindal wrote:
>> Currently, three types of mem regions are supported: UIO_MEM_PHYS,
>> UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
>> UIO driver export physcial memory to user space as non-cacheable
>> user memory. Typcially memory-mapped registers of a device are exported
>> to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
>> is not efficient if dma-capable devices are capable of maintaining coherency
>> with CPU caches.
>
> Not efficient in what way?
Sorry, I will rephrase this.
>
>> This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
>> cacheable access to physical memory from user space.
>>
>> Signed-off-by: Ankit Jindal <ankit.jindal@linaro.org>
>> Signed-off-by: Tushar Jagad <tushar.jagad@linaro.org>
>> ---
>>  drivers/uio/uio.c          |   11 ++++++++---
>>  include/linux/uio_driver.h |    1 +
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index 97e6444..120a84b 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -644,7 +644,7 @@ static const struct vm_operations_struct uio_physical_vm_ops = {
>>  #endif
>>  };
>>
>> -static int uio_mmap_physical(struct vm_area_struct *vma)
>> +static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
>
> I despise "bool" flags in a function, as they don't give any idea of
> what is going on when you see the function being called.  Please create
> a new function that does this properly, with a correct name, if it's
> needed.
Sure, will take care of this in next revision.
>
> thanks,
>
> greg k-h
Thanks,
Ankit

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Rob Herring]

On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
> On 18 November 2014 at 18:40, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>>> >> +
>>> >> +       qmtm1_uio: qmtm_uio@1f200000 {
>>> >> +               compatible = "apm,xgene-qmtm";
>>> >> +               status = "disabled";
>>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>>> >> +               reg-names = "csr", "fabric";
>>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>>> >> +               clocks = <&qmtm1clk 0>;
>>> >> +               num-queues = <0x400>;
>>> >> +               devid = <1>;
>>> >> +       };
>>> >> +
>>> >
>>> > To make my previous review comments clearer:
>>> >
>>> > NAK
>>> >
>>> > Do not create device nodes that are meant for a specific use case in
>>> > software and that are not usable for the common case. I don't think
>>> > it makes any sense to keep on submitting a UIO driver for this until
>>> > we have a proper network driver that uses this so we can make sure we
>>> > have a working binding.

+1

>>> The dataplane frameworks like OpenDataPlane etc, need to have access
>>> to complete subsystem from the user space. Hence, we would like to
>>> have this driver and some other UIO drivers to be the part of kernel
>>> to have data plane frameworks working on our platform.
>>
>> Please work with the people that do the in-kernel QMTM driver to come
>> up with a common binding then.
> Thanks Arnd, I have synced with them, and in future our dt bindings
> for this device is going to be inline with the one mentioned in the
> patchset.

What does "in the future" mean? Is there already a QMTM binding? If
so, you need to figure out how to either align with it or deprecate
it. This patch at a minimum needs to be fixed to not refer to UIO.

Rob

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Rob Herring]

On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
> On 18 November 2014 at 18:40, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>>> >> +
>>> >> +       qmtm1_uio: qmtm_uio at 1f200000 {
>>> >> +               compatible = "apm,xgene-qmtm";
>>> >> +               status = "disabled";
>>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>>> >> +               reg-names = "csr", "fabric";
>>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>>> >> +               clocks = <&qmtm1clk 0>;
>>> >> +               num-queues = <0x400>;
>>> >> +               devid = <1>;
>>> >> +       };
>>> >> +
>>> >
>>> > To make my previous review comments clearer:
>>> >
>>> > NAK
>>> >
>>> > Do not create device nodes that are meant for a specific use case in
>>> > software and that are not usable for the common case. I don't think
>>> > it makes any sense to keep on submitting a UIO driver for this until
>>> > we have a proper network driver that uses this so we can make sure we
>>> > have a working binding.

+1

>>> The dataplane frameworks like OpenDataPlane etc, need to have access
>>> to complete subsystem from the user space. Hence, we would like to
>>> have this driver and some other UIO drivers to be the part of kernel
>>> to have data plane frameworks working on our platform.
>>
>> Please work with the people that do the in-kernel QMTM driver to come
>> up with a common binding then.
> Thanks Arnd, I have synced with them, and in future our dt bindings
> for this device is going to be inline with the one mentioned in the
> patchset.

What does "in the future" mean? Is there already a QMTM binding? If
so, you need to figure out how to either align with it or deprecate
it. This patch at a minimum needs to be fixed to not refer to UIO.

Rob

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 8 December 2014 at 22:45, Rob Herring <robherring2@gmail.com> wrote:
> On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
>> On 18 November 2014 at 18:40, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>>> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>>>> >> +
>>>> >> +       qmtm1_uio: qmtm_uio@1f200000 {
>>>> >> +               compatible = "apm,xgene-qmtm";
>>>> >> +               status = "disabled";
>>>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>>>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>>>> >> +               reg-names = "csr", "fabric";
>>>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>>>> >> +               clocks = <&qmtm1clk 0>;
>>>> >> +               num-queues = <0x400>;
>>>> >> +               devid = <1>;
>>>> >> +       };
>>>> >> +
>>>> >
>>>> > To make my previous review comments clearer:
>>>> >
>>>> > NAK
>>>> >
>>>> > Do not create device nodes that are meant for a specific use case in
>>>> > software and that are not usable for the common case. I don't think
>>>> > it makes any sense to keep on submitting a UIO driver for this until
>>>> > we have a proper network driver that uses this so we can make sure we
>>>> > have a working binding.
>
> +1
>
>>>> The dataplane frameworks like OpenDataPlane etc, need to have access
>>>> to complete subsystem from the user space. Hence, we would like to
>>>> have this driver and some other UIO drivers to be the part of kernel
>>>> to have data plane frameworks working on our platform.
>>>
>>> Please work with the people that do the in-kernel QMTM driver to come
>>> up with a common binding then.
>> Thanks Arnd, I have synced with them, and in future our dt bindings
>> for this device is going to be inline with the one mentioned in the
>> patchset.
>
> What does "in the future" mean? Is there already a QMTM binding? If
> so, you need to figure out how to either align with it or deprecate
> it. This patch at a minimum needs to be fixed to not refer to UIO.

There is no QMTM dt binding as of now, and the kernel QMTM driver will
also use the same dt binding.
I will remove all references to the UIO from this patch, and move this
binding under the misc folder.

>
> Rob

Thanks,
Ankit

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 8 December 2014 at 22:45, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <ankit.jindal-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 18 November 2014 at 18:40, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>>> On 17 November 2014 16:47, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>>>> >> +
>>>> >> +       qmtm1_uio: qmtm_uio@1f200000 {
>>>> >> +               compatible = "apm,xgene-qmtm";
>>>> >> +               status = "disabled";
>>>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>>>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>>>> >> +               reg-names = "csr", "fabric";
>>>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>>>> >> +               clocks = <&qmtm1clk 0>;
>>>> >> +               num-queues = <0x400>;
>>>> >> +               devid = <1>;
>>>> >> +       };
>>>> >> +
>>>> >
>>>> > To make my previous review comments clearer:
>>>> >
>>>> > NAK
>>>> >
>>>> > Do not create device nodes that are meant for a specific use case in
>>>> > software and that are not usable for the common case. I don't think
>>>> > it makes any sense to keep on submitting a UIO driver for this until
>>>> > we have a proper network driver that uses this so we can make sure we
>>>> > have a working binding.
>
> +1
>
>>>> The dataplane frameworks like OpenDataPlane etc, need to have access
>>>> to complete subsystem from the user space. Hence, we would like to
>>>> have this driver and some other UIO drivers to be the part of kernel
>>>> to have data plane frameworks working on our platform.
>>>
>>> Please work with the people that do the in-kernel QMTM driver to come
>>> up with a common binding then.
>> Thanks Arnd, I have synced with them, and in future our dt bindings
>> for this device is going to be inline with the one mentioned in the
>> patchset.
>
> What does "in the future" mean? Is there already a QMTM binding? If
> so, you need to figure out how to either align with it or deprecate
> it. This patch at a minimum needs to be fixed to not refer to UIO.

There is no QMTM dt binding as of now, and the kernel QMTM driver will
also use the same dt binding.
I will remove all references to the UIO from this patch, and move this
binding under the misc folder.

>
> Rob

Thanks,
Ankit
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 8 December 2014 at 22:45, Rob Herring <robherring2@gmail.com> wrote:
> On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
>> On 18 November 2014 at 18:40, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>>> On 17 November 2014 16:47, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>>>> >> +
>>>> >> +       qmtm1_uio: qmtm_uio at 1f200000 {
>>>> >> +               compatible = "apm,xgene-qmtm";
>>>> >> +               status = "disabled";
>>>> >> +               reg = <0x0 0x1f200000 0x0 0x10000>,
>>>> >> +                     <0x0 0x1b000000 0x0 0x400000>;
>>>> >> +               reg-names = "csr", "fabric";
>>>> >> +               qpool-memory = <&qmtm1_uio_qpool>;
>>>> >> +               clocks = <&qmtm1clk 0>;
>>>> >> +               num-queues = <0x400>;
>>>> >> +               devid = <1>;
>>>> >> +       };
>>>> >> +
>>>> >
>>>> > To make my previous review comments clearer:
>>>> >
>>>> > NAK
>>>> >
>>>> > Do not create device nodes that are meant for a specific use case in
>>>> > software and that are not usable for the common case. I don't think
>>>> > it makes any sense to keep on submitting a UIO driver for this until
>>>> > we have a proper network driver that uses this so we can make sure we
>>>> > have a working binding.
>
> +1
>
>>>> The dataplane frameworks like OpenDataPlane etc, need to have access
>>>> to complete subsystem from the user space. Hence, we would like to
>>>> have this driver and some other UIO drivers to be the part of kernel
>>>> to have data plane frameworks working on our platform.
>>>
>>> Please work with the people that do the in-kernel QMTM driver to come
>>> up with a common binding then.
>> Thanks Arnd, I have synced with them, and in future our dt bindings
>> for this device is going to be inline with the one mentioned in the
>> patchset.
>
> What does "in the future" mean? Is there already a QMTM binding? If
> so, you need to figure out how to either align with it or deprecate
> it. This patch at a minimum needs to be fixed to not refer to UIO.

There is no QMTM dt binding as of now, and the kernel QMTM driver will
also use the same dt binding.
I will remove all references to the UIO from this patch, and move this
binding under the misc folder.

>
> Rob

Thanks,
Ankit