diff mbox

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

Message ID 1416220572-13381-6-git-send-email-ankit.jindal@linaro.org
State New, archived
Headers show

Commit Message

Ankit Jindal Nov. 17, 2014, 10:36 a.m. UTC
This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.

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

Comments

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

FWIW,

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

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

To make my previous review comments clearer:

NAK

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

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

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

>
>         Arnd

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

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

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

+1

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

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

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

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

>
> Rob

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

Patch

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