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

[PATCH v3 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 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     |   53 ++++
 MAINTAINERS                                        |    7 +
 drivers/uio/Kconfig                                |    8 +
 drivers/uio/Makefile                               |    1 +
 drivers/uio/uio.c                                  |   23 +-
 drivers/uio/uio_xgene_qmtm.c                       |  270 ++++++++++++++++++++
 include/linux/uio_driver.h                         |    1 +
 8 files changed, 357 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 v3 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 v3 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 v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions

[Kumar Gala]

On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@linaro.org> 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.
> 
> 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(-)

Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don?t need to keep adding types for various different cache attributions in the future.

- k

> 
> 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
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Ankit Jindal]

Hi Kumar,

On 21 October 2014 12:08, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@linaro.org> 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.
>>
>> 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(-)
>
> Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don?t need to keep adding types for various different cache attributions in the future.

Do you mean to add a new field pgprot_t in the memtype structure and
uio_mmap_physical will set vma->vm_page_prot to this value provided by
driver ? If this is the case then we will need to change all the
current uio based drivers which was the reason I preferred to have a
new mem type.

Please let me know if I have misunderstood anything.

Thanks,
Ankit

>
> - k
>
>>
>> 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
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

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

[Kumar Gala]

On Oct 31, 2014, at 4:30 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:

> Hi Kumar,
> 
> On 21 October 2014 12:08, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@linaro.org> 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.
>>> 
>>> 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(-)
>> 
>> Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don?t need to keep adding types for various different cache attributions in the future.
> 
> Do you mean to add a new field pgprot_t in the memtype structure and
> uio_mmap_physical will set vma->vm_page_prot to this value provided by
> driver ? If this is the case then we will need to change all the
> current uio based drivers which was the reason I preferred to have a
> new mem type.
> 
> Please let me know if I have misunderstood anything.

I?m suggeting in uio_mmap_physical to do something like:

if (idev->info->set_pgprot)
	idev->info->set_pgprot(vma->vm_page_prot)
else
	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

And add a set_prprot callback to 'struct uio_info?.

Here?s patch from several years ago:

http://patchwork.ozlabs.org/patch/119224/

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Ankit Jindal]

Hi Kumar,

On 31 October 2014 19:09, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Oct 31, 2014, at 4:30 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
>
>> Hi Kumar,
>>
>> On 21 October 2014 12:08, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@linaro.org> 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.
>>>>
>>>> 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(-)
>>>
>>> Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don?t need to keep adding types for various different cache attributions in the future.
>>
>> Do you mean to add a new field pgprot_t in the memtype structure and
>> uio_mmap_physical will set vma->vm_page_prot to this value provided by
>> driver ? If this is the case then we will need to change all the
>> current uio based drivers which was the reason I preferred to have a
>> new mem type.
>>
>> Please let me know if I have misunderstood anything.
>
> I?m suggeting in uio_mmap_physical to do something like:
>
> if (idev->info->set_pgprot)
>         idev->info->set_pgprot(vma->vm_page_prot)
> else
>         vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> And add a set_prprot callback to 'struct uio_info?.
>
> Here?s patch from several years ago:
>
> http://patchwork.ozlabs.org/patch/119224/

The suggested solution looks okey but not sure whether there is any
available drivers using different combinations. Also, I looked at the
available pgprot routines, looks like only pgprot_noncached and
pgprot_writecombine are the available ones. So if we are not going to
use these pgprot routines then driver might have architecture
dependent switches, which we should avoid.

Thanks,
Ankit
>
> - k
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

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

[Kumar Gala]

On Nov 5, 2014, at 6:55 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:

> Hi Kumar,
> 
> On 31 October 2014 19:09, Kumar Gala <galak@codeaurora.org> wrote:
>> 
>> On Oct 31, 2014, at 4:30 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
>> 
>>> Hi Kumar,
>>> 
>>> On 21 October 2014 12:08, Kumar Gala <galak@codeaurora.org> wrote:
>>>> 
>>>> On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@linaro.org> 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.
>>>>> 
>>>>> 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(-)
>>>> 
>>>> Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don?t need to keep adding types for various different cache attributions in the future.
>>> 
>>> Do you mean to add a new field pgprot_t in the memtype structure and
>>> uio_mmap_physical will set vma->vm_page_prot to this value provided by
>>> driver ? If this is the case then we will need to change all the
>>> current uio based drivers which was the reason I preferred to have a
>>> new mem type.
>>> 
>>> Please let me know if I have misunderstood anything.
>> 
>> I?m suggeting in uio_mmap_physical to do something like:
>> 
>> if (idev->info->set_pgprot)
>>        idev->info->set_pgprot(vma->vm_page_prot)
>> else
>>        vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> 
>> And add a set_prprot callback to 'struct uio_info?.
>> 
>> Here?s patch from several years ago:
>> 
>> http://patchwork.ozlabs.org/patch/119224/
> 
> The suggested solution looks okey but not sure whether there is any
> available drivers using different combinations. Also, I looked at the
> available pgprot routines, looks like only pgprot_noncached and
> pgprot_writecombine are the available ones. So if we are not going to
> use these pgprot routines then driver might have architecture
> dependent switches, which we should avoid.

There are cases that are arch/driver specific that do not fall into pgprot_noncached or pgprot_writecombine.  So I don?t see why we should limit them.  For example the Freescale networking guys need cacheable-noncoherent for some of their UIO work.

We can deal with arch specific issues during review of the UIO driver themselves.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Ankit Jindal]

On 5 November 2014 20:39, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Nov 5, 2014, at 6:55 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
>
>> Hi Kumar,
>>
>> On 31 October 2014 19:09, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Oct 31, 2014, at 4:30 AM, Ankit Jindal <ankit.jindal@linaro.org> wrote:
>>>
>>>> Hi Kumar,
>>>>
>>>> On 21 October 2014 12:08, Kumar Gala <galak@codeaurora.org> wrote:
>>>>>
>>>>> On Oct 21, 2014, at 7:56 AM, Ankit Jindal <ankit.jindal@linaro.org> 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.
>>>>>>
>>>>>> 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(-)
>>>>>
>>>>> Rather than adding a new type, why not allow the driver to set the pgprot value, this way one has full control and we don?t need to keep adding types for various different cache attributions in the future.
>>>>
>>>> Do you mean to add a new field pgprot_t in the memtype structure and
>>>> uio_mmap_physical will set vma->vm_page_prot to this value provided by
>>>> driver ? If this is the case then we will need to change all the
>>>> current uio based drivers which was the reason I preferred to have a
>>>> new mem type.
>>>>
>>>> Please let me know if I have misunderstood anything.
>>>
>>> I?m suggeting in uio_mmap_physical to do something like:
>>>
>>> if (idev->info->set_pgprot)
>>>        idev->info->set_pgprot(vma->vm_page_prot)
>>> else
>>>        vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>>
>>> And add a set_prprot callback to 'struct uio_info?.
>>>
>>> Here?s patch from several years ago:
>>>
>>> http://patchwork.ozlabs.org/patch/119224/
>>
>> The suggested solution looks okey but not sure whether there is any
>> available drivers using different combinations. Also, I looked at the
>> available pgprot routines, looks like only pgprot_noncached and
>> pgprot_writecombine are the available ones. So if we are not going to
>> use these pgprot routines then driver might have architecture
>> dependent switches, which we should avoid.
>
> There are cases that are arch/driver specific that do not fall into pgprot_noncached or pgprot_writecombine.  So I don?t see why we should limit them.  For example the Freescale networking guys need cacheable-noncoherent for some of their UIO work.
>
> We can deal with arch specific issues during review of the UIO driver themselves.

Ok. But, in our case we do not want to set any special attribute,
instead just want to avoid setting non-cacheable attribute. So if we
go by the approach as in your patch, then I need to register a dummy
routine which does nothing.

I think another approach could be to have new mem type as in this
patch and add something like this to this patch:

if (cacheable) {
        /* check if driver want to set any special cacheable attribute
combination */
        if (idev->info->set_pgprot)
                idev->info->set_pgprot(vma->vm_page_prot)
} else {
        vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
}

Please let me know your view.
> - k
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Thanks,
Ankit

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

[Russell King - ARM Linux]

On Tue, Oct 21, 2014 at 08:38:23AM +0200, Kumar Gala wrote:
> Rather than adding a new type, why not allow the driver to set the

Please wrap your message.

That doesn't work.  A pgprot_t contains more than just memory type
information.  It also contains access permissions.  In other words,
if the user requested read-only or a read-write mapping, the
permissions will be different.

If you always use your stored pgprot_t, then you will override the
users requested permissions.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v3 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 v3 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 |  270 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 279 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..65467a1
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,270 @@
+/*
+ * 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", &qpool_phandle);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "No qpool 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 v3 4/6] uio: Add X-Gene QMTM UIO driver

[Varka Bhadram]

On 10/21/2014 11:26 AM, Ankit Jindal wrote:
> 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>

(...)

> +
> +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;
> +	}
> +

This error check is not required. *csr* is checked in devm_ioremap_resource().

> +	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;
> +	}
> +

same

> +	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", &qpool_phandle);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "No qpool 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;
> +}
>


-- 
Regards,
Varka Bhadram.

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

[Ankit Jindal]

On 21 October 2014 11:34, Varka Bhadram <varkabhadram@gmail.com> wrote:
> On 10/21/2014 11:26 AM, Ankit Jindal wrote:
>>
>> 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>
>
>
> (...)
>
>
>> +
>> +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;
>> +       }
>> +
>
>
> This error check is not required. *csr* is checked in
> devm_ioremap_resource().

I think its better to do sanity check before calling any function.

>
>> +       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;
>> +       }
>> +
>
>
> same

We do not ioremap this address.

>
>
>> +       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",
>> &qpool_phandle);
>> +       if (ret < 0) {
>> +               dev_err(&pdev->dev, "No qpool 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;
>> +}
>>
>
>
> --
> Regards,
> Varka Bhadram.
>
Thanks,
Ankit

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

[Varka Bhadram]

On 10/21/2014 11:46 AM, Ankit Jindal wrote:
> On 21 October 2014 11:34, Varka Bhadram <varkabhadram@gmail.com> wrote:
>> On 10/21/2014 11:26 AM, Ankit Jindal wrote:
>>> 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>
>>
>> (...)
>>
>>
>>> +
>>> +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;
>>> +       }
>>> +
>>
>> This error check is not required. *csr* is checked in
>> devm_ioremap_resource().
> I think its better to do sanity check before calling any function.

It will be the duplication of code for sanity check. This sanity check is happening
with devm_ioremap_resource(). No need to check it explicitly.

>>> +       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;
>>> +       }
>>> +
>>
>> same
> We do not ioremap this address.

Ok..

-- 
Regards,
Varka Bhadram.

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

[Ankit Jindal]

On 21 October 2014 11:47, Varka Bhadram <varkabhadram@gmail.com> wrote:
> On 10/21/2014 11:46 AM, Ankit Jindal wrote:
>>
>> On 21 October 2014 11:34, Varka Bhadram <varkabhadram@gmail.com> wrote:
>>>
>>> On 10/21/2014 11:26 AM, Ankit Jindal wrote:
>>>>
>>>> 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>
>>>
>>>
>>> (...)
>>>
>>>
>>>> +
>>>> +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;
>>>> +       }
>>>> +
>>>
>>>
>>> This error check is not required. *csr* is checked in
>>> devm_ioremap_resource().
>>
>> I think its better to do sanity check before calling any function.
>
>
> It will be the duplication of code for sanity check. This sanity check is
> happening
> with devm_ioremap_resource(). No need to check it explicitly.

Okie, will remove it in next revision.

>
>>>> +       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;
>>>> +       }
>>>> +
>>>
>>>
>>> same
>>
>> We do not ioremap this address.
>
>
> Ok..
>
> --
> Regards,
> Varka Bhadram.
>
Thanks,
Ankit

[PATCH v3 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     |   53 ++++++++++++++++++++
 1 file changed, 53 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..288ed92
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
@@ -0,0 +1,53 @@
+APM X-Gene QMTM UIO 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. QMTM UIO nodes are defined for user
+space access to this device using UIO framework.
+
+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: Points to the phandle of the node defining memory location for
+	 creating QMTM queues. This could point either to the reserved-memory
+	 node (as-per reserved memory bindings) or to the node of on-chip
+	 SRAM etc. 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";
+		status = "ok";
+	};
+
+	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 = <&qmtm1_uio_qpool>;
+		clocks = <&qmtm1clk 0>;
+		num-queues = <0x400>;
+		devid = <1>;
+	};
+
+	/* Board-specific peripheral configurations */
+	&qmtm1_uio {
+		status = "ok";
+	};
-- 
1.7.9.5

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

[Mark Rutland]

On Tue, Oct 21, 2014 at 06:56:49AM +0100, Ankit Jindal wrote:
> 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     |   53 ++++++++++++++++++++
>  1 file changed, 53 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..288ed92
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
> @@ -0,0 +1,53 @@
> +APM X-Gene QMTM UIO nodes

The "UIO" can go.

> +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. QMTM UIO nodes are defined for user
> +space access to this device using UIO framework.

The binding should describe the hardware, not the software. Please drop
mention of UIO, userspace, etc.

> +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: Points to the phandle of the node defining memory location for
> +	 creating QMTM queues. This could point either to the reserved-memory
> +	 node (as-per reserved memory bindings) or to the node of on-chip
> +	 SRAM etc. It is expected that size and location of qpool memory will
> +	 be configurable via bootloader.

Is that on-chip SRAM part of the QMTM, or is that a shared part of the
SoC?

It feels odd to have a phandle that can go to completely different
classes of node, especially as you will need to use a different API to
acquire the memory region within Linux.

> +- clocks: Reference to the clock entry.

Just the one clock? Does the clock input to the QMTM have a name?

> +- 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.

Is this just an arbitrary unique ID, or is this a non-probeable property
of the HW? If the former, isn't the base address sufficient as a unique
identifier?

Thanks,
Mark.

> +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";
> +		status = "ok";
> +	};
> +
> +	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 = <&qmtm1_uio_qpool>;
> +		clocks = <&qmtm1clk 0>;
> +		num-queues = <0x400>;
> +		devid = <1>;
> +	};
> +
> +	/* Board-specific peripheral configurations */
> +	&qmtm1_uio {
> +		status = "ok";
> +	};
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Arnd Bergmann]

On Tuesday 21 October 2014 10:14:12 Mark Rutland wrote:
> 
> > +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. QMTM UIO nodes are defined for user
> > +space access to this device using UIO framework.
> 
> The binding should describe the hardware, not the software. Please drop
> mention of UIO, userspace, etc.

I have a bad feeling about the entire idea of doing the UIO driver first,
there are too many unknowns here and we should not break the binding
when the proper driver gets added.

The X-Gene is meant for server workloads, so the UIO approach is not
a good longterm solution anyway. My impression is that it would be
better to first get the kernel driver for this hardware merged and
the binding fixed, and then a UIO stub could get added to that driver,
taking over the hardware by user space. This would also solve the
arbitration between the two driver implementations. It's also possible
that by that time, we will have a functional VFIO framework for
platform devices.

	Arnd

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

[Ankit Jindal]

Hi Mark,

On 21 October 2014 14:44, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Oct 21, 2014 at 06:56:49AM +0100, Ankit Jindal wrote:
>> 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     |   53 ++++++++++++++++++++
>>  1 file changed, 53 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..288ed92
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
>> @@ -0,0 +1,53 @@
>> +APM X-Gene QMTM UIO nodes
>
> The "UIO" can go.
Sure.

>
>> +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. QMTM UIO nodes are defined for user
>> +space access to this device using UIO framework.
>
> The binding should describe the hardware, not the software. Please drop
> mention of UIO, userspace, etc.
Sure.

>
>> +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: Points to the phandle of the node defining memory location for
>> +      creating QMTM queues. This could point either to the reserved-memory
>> +      node (as-per reserved memory bindings) or to the node of on-chip
>> +      SRAM etc. It is expected that size and location of qpool memory will
>> +      be configurable via bootloader.
>
> Is that on-chip SRAM part of the QMTM, or is that a shared part of the
> SoC?
Its not part of QMTM.

>
> It feels odd to have a phandle that can go to completely different
> classes of node, especially as you will need to use a different API to
> acquire the memory region within Linux.
It is expected that phandle will point to a node whose first reg
property will be only for qpool memory.

>
>> +- clocks: Reference to the clock entry.
>
> Just the one clock? Does the clock input to the QMTM have a name?
Just one input clock. There is no specific name of it.

>
>> +- 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.
>
> Is this just an arbitrary unique ID, or is this a non-probeable property
> of the HW? If the former, isn't the base address sufficient as a unique
> identifier?
Its a non-probeable property of the HW.

Thanks,
Ankit
>
> Thanks,
> Mark.
>
>> +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";
>> +             status = "ok";
>> +     };
>> +
>> +     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 = <&qmtm1_uio_qpool>;
>> +             clocks = <&qmtm1clk 0>;
>> +             num-queues = <0x400>;
>> +             devid = <1>;
>> +     };
>> +
>> +     /* Board-specific peripheral configurations */
>> +     &qmtm1_uio {
>> +             status = "ok";
>> +     };
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

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

[Mark Rutland]

> >> +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: Points to the phandle of the node defining memory location for
> >> +      creating QMTM queues. This could point either to the reserved-memory
> >> +      node (as-per reserved memory bindings) or to the node of on-chip
> >> +      SRAM etc. It is expected that size and location of qpool memory will
> >> +      be configurable via bootloader.
> >
> > Is that on-chip SRAM part of the QMTM, or is that a shared part of the
> > SoC?
> Its not part of QMTM.
> 
> >
> > It feels odd to have a phandle that can go to completely different
> > classes of node, especially as you will need to use a different API to
> > acquire the memory region within Linux.
> It is expected that phandle will point to a node whose first reg
> property will be only for qpool memory.

Even if that's true you will need to use completely different APIs for
accessing that memory (so that the kernel can account the use of
reserved-memory correctly), so this might not be the best design. It
might be better to have qpool-sram and qpool-memory properties that
point at an sram node or a reserved-memory node respectively.

> >
> >> +- clocks: Reference to the clock entry.
> >
> > Just the one clock? Does the clock input to the QMTM have a name?
> Just one input clock. There is no specific name of it.

Ok.

> 
> >
> >> +- 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.
> >
> > Is this just an arbitrary unique ID, or is this a non-probeable property
> > of the HW? If the former, isn't the base address sufficient as a unique
> > identifier?
> Its a non-probeable property of the HW.

Ok. That sounds fine then.

Thanks,
Mark.

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

[Ankit Jindal]

On 31 October 2014 15:39, Mark Rutland <mark.rutland@arm.com> wrote:
>> >> +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: Points to the phandle of the node defining memory location for
>> >> +      creating QMTM queues. This could point either to the reserved-memory
>> >> +      node (as-per reserved memory bindings) or to the node of on-chip
>> >> +      SRAM etc. It is expected that size and location of qpool memory will
>> >> +      be configurable via bootloader.
>> >
>> > Is that on-chip SRAM part of the QMTM, or is that a shared part of the
>> > SoC?
>> Its not part of QMTM.
>>
>> >
>> > It feels odd to have a phandle that can go to completely different
>> > classes of node, especially as you will need to use a different API to
>> > acquire the memory region within Linux.
>> It is expected that phandle will point to a node whose first reg
>> property will be only for qpool memory.
>
> Even if that's true you will need to use completely different APIs for
> accessing that memory (so that the kernel can account the use of
> reserved-memory correctly), so this might not be the best design. It
> might be better to have qpool-sram and qpool-memory properties that
> point at an sram node or a reserved-memory node respectively.
Thanks, I will go as per your suggestion. I will add two properties
qpool-sram and qpool-memory to tackle this.
>
>> >
>> >> +- clocks: Reference to the clock entry.
>> >
>> > Just the one clock? Does the clock input to the QMTM have a name?
>> Just one input clock. There is no specific name of it.
>
> Ok.
>
>>
>> >
>> >> +- 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.
>> >
>> > Is this just an arbitrary unique ID, or is this a non-probeable property
>> > of the HW? If the former, isn't the base address sufficient as a unique
>> > identifier?
>> Its a non-probeable property of the HW.
>
> Ok. That sounds fine then.
>

Thanks,
Ankit
> Thanks,
> Mark.

[PATCH v3 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