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
This patch fixes the indentation of switch-case block in uio driver.
Signed-off-by: Ankit Jindal <[email protected]>
Signed-off-by: Tushar Jagad <[email protected]>
---
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
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 <[email protected]>
Signed-off-by: Tushar Jagad <[email protected]>
---
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
This patch updates UIO documentation for new mem region
type UIO_MEM_PHYS_CACHE.
Signed-off-by: Ankit Jindal <[email protected]>
Signed-off-by: Tushar Jagad <[email protected]>
---
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
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 <[email protected]>
Signed-off-by: Tushar Jagad <[email protected]>
---
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 <[email protected]>");
+MODULE_AUTHOR("Tushar Jagad <[email protected]>");
--
1.7.9.5
Add entry to maintainer list for APM X-Gene QMTM UIO driver.
Signed-off-by: Ankit Jindal <[email protected]>
Signed-off-by: Tushar Jagad <[email protected]>
---
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 <[email protected]>
+M: Tushar Jagad <[email protected]>
+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 <[email protected]>
L: [email protected]
--
1.7.9.5
This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.
Signed-off-by: Ankit Jindal <[email protected]>
Signed-off-by: Tushar Jagad <[email protected]>
---
.../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
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 <[email protected]>
> Signed-off-by: Tushar Jagad <[email protected]>
> ---
> .../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 <[email protected]>
Thanks,
Andreas
--
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 21284 AG N?rnberg
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
On 17 November 2014 16:47, Arnd Bergmann <[email protected]> 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
On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
> On 17 November 2014 16:47, Arnd Bergmann <[email protected]> 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
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 <[email protected]>
> Signed-off-by: Tushar Jagad <[email protected]>
> ---
> 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
On 18 November 2014 at 18:40, Arnd Bergmann <[email protected]> wrote:
> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>> On 17 November 2014 16:47, Arnd Bergmann <[email protected]> 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
On 27 November 2014 at 05:31, Greg Kroah-Hartman
<[email protected]> 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 <[email protected]>
>> Signed-off-by: Tushar Jagad <[email protected]>
>> ---
>> 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
On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <[email protected]> wrote:
> On 18 November 2014 at 18:40, Arnd Bergmann <[email protected]> wrote:
>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>> On 17 November 2014 16:47, Arnd Bergmann <[email protected]> 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
On 8 December 2014 at 22:45, Rob Herring <[email protected]> wrote:
> On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal <[email protected]> wrote:
>> On 18 November 2014 at 18:40, Arnd Bergmann <[email protected]> wrote:
>>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>>> On 17 November 2014 16:47, Arnd Bergmann <[email protected]> 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