| Message ID | 1416220572-13381-6-git-send-email-ankit.jindal@linaro.org |
|---|---|
| State | Needs Review / ACK, archived |
| Headers | show |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | warning | total: 1 errors, 0 warnings, 0 lines checked |
| robh/patch-applied | success |
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
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
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
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
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
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
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 --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"; + };