Re: [v2] powerpc/mpc85xx: Add DPAA Ethernet QMan support to the device tree(s)

2015-05-28 Thread Scott Wood 
On Wed, May 20, 2015 at 03:29:35PM +0300, Madalin Bucur wrote:
 From: Emil Medve emilian.me...@freescale.com
 
 Signed-off-by: Emil Medve emilian.me...@freescale.com

What does DPAA Ethernet QMan support mean?  Is it ethernet support or
qman support?  In any case the subject is too long.

 +/* These stubs are required to alloc qbman drivers to determine what ranges 
 of
 + * resources are available for dynamic allocation, primarily because there 
 are
 + * some legacy a priori assumptions in certain subsystems (eg. networking)
 + * that certain resources are reserved for their use. When those drivers 
 (and in
 + * some cases, their corresponding device-tree nodes) are updated to 
 dynamically
 + * allocate their resources, then *all* resources can be managed by the
 + * allocators and there may be no further need to define these stubs.

I thought we were doing full dynamic resource allocation for the upstream
driver and device tree binding.

 + * - Even for memory-backed resources that are software determined (FQIDs), 
 this
 + *   information may only be configured and available on the control-plane
 + *   partition that manages the device, so in AMP or hypervised scenarios 
 there
 + *   may still be need to a way to provide allocation ranges. Ie. for O/S
 + *   instances that don't know how many resources are available to hardware, 
 and
 + *   possibly even for O/S instances that do know how many are available but
 + *   that should not own all of them.

Partial device assignment under virtualization needs special handling for
any device; no need to have a big block comment about it here.

 + */
 +
 +qportals {
 + qman-fqids@0 {
 + compatible = fsl,fqid-range;
 + fsl,fqid-range = 256 256;
 + };
 + qman-fqids@1 {
 + compatible = fsl,fqid-range;
 + fsl,fqid-range = 32768 32768;
 + };
 + qman-pools@0 {
 + compatible = fsl,pool-channel-range;
 + fsl,pool-channel-range = 0x21 0xf;
 + };
 + qman-cgrids@0 {
 + compatible = fsl,cgrid-range;
 + fsl,cgrid-range = 0 256;
 + };
 +};

Where is the binding for this stuff?

 +/* The comments in qoriq-dpaa-res1.dtsi apply here too so will not be 
 repeated.
 + * This alternative file is to support p1023 which does not have the same
 + * resource ranges as other SoCs to date. */

Then put p1023 in the name instead of res2 (or if the 2 really means
something, explain).

 +/* These stubs are required to alloc qbman drivers to determine what ranges 
 of
 + * resources are available for dynamic allocation, primarily because there 
 are
 + * some legacy a priori assumptions in certain subsystems (eg. networking)
 + * that certain resources are reserved for their use. When those drivers 
 (and in
 + * some cases, their corresponding device-tree nodes) are updated to 
 dynamically
 + * allocate their resources, then *all* resources can be managed by the
 + * allocators and there may be no further need to define these stubs.
 + *
 + * A couple of qualifiers to the above statement though:
 + *
 + * - Some resource ranges are hardware-specific, rather than being defined by
 + *   software memory allocation choices. Eg. the number of available BPIDs is
 + *   baked into silicon and so will probably always need to be expressed in 
 the
 + *   device-tree, though in that case it will express all BPIDs, not just 
 those
 + *   available for dynamic allocation.
 + *
 + * - Even for memory-backed resources that are software determined (FQIDs), 
 this
 + *   information may only be configured and available on the control-plane
 + *   partition that manages the device, so in AMP or hypervised scenarios 
 there
 + *   may still be need to a way to provide allocation ranges. Ie. for O/S
 + *   instances that don't know how many resources are available to hardware, 
 and
 + *   possibly even for O/S instances that do know how many are available but
 + *   that should not own all of them.

Why is all this repeated here?

If explanation is needed about what the nodes are here for, put it in the
binding document.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH, v2] powerpc/mpc85xx: Add DPAA Ethernet QMan support to the device tree(s)

2015-05-20 Thread Madalin Bucur 
From: Emil Medve emilian.me...@freescale.com

Signed-off-by: Emil Medve emilian.me...@freescale.com
---
 arch/powerpc/boot/dts/b4qds.dtsi   |  1 +
 arch/powerpc/boot/dts/fsl/qoriq-dpaa-res1.dtsi | 77 ++
 arch/powerpc/boot/dts/fsl/qoriq-dpaa-res2.dtsi | 56 +++
 arch/powerpc/boot/dts/fsl/qoriq-dpaa-res3.dtsi | 77 ++
 arch/powerpc/boot/dts/kmcoge4.dts  |  1 +
 arch/powerpc/boot/dts/oca4080.dts  |  1 +
 arch/powerpc/boot/dts/p1023rdb.dts |  1 +
 arch/powerpc/boot/dts/p2041rdb.dts |  1 +
 arch/powerpc/boot/dts/p3041ds.dts  |  1 +
 arch/powerpc/boot/dts/p4080ds.dts  |  1 +
 arch/powerpc/boot/dts/p5020ds.dts  |  1 +
 arch/powerpc/boot/dts/p5040ds.dts  |  1 +
 arch/powerpc/boot/dts/t104xqds.dtsi|  2 +
 arch/powerpc/boot/dts/t104xrdb.dtsi|  2 +
 arch/powerpc/boot/dts/t208xqds.dtsi|  2 +
 arch/powerpc/boot/dts/t208xrdb.dtsi|  2 +
 arch/powerpc/boot/dts/t4240qds.dts |  1 +
 arch/powerpc/boot/dts/t4240rdb.dts |  1 +
 18 files changed, 229 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dpaa-res1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dpaa-res2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dpaa-res3.dtsi

diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index 24ed80d..3cd23db 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -218,3 +218,4 @@
 };
 
 /include/ fsl/b4si-post.dtsi
+/include/ fsl/qoriq-dpaa-res3.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-dpaa-res1.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-dpaa-res1.dtsi
new file mode 100644
index 000..24d83e0
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-dpaa-res1.dtsi
@@ -0,0 +1,77 @@
+/*
+ * QorIQ DPAA resources device tree stub [ FQIDs, BPIDs ]
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *  names of its contributors may be used to endorse or promote products
+ *  derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/* These stubs are required to alloc qbman drivers to determine what ranges of
+ * resources are available for dynamic allocation, primarily because there are
+ * some legacy a priori assumptions in certain subsystems (eg. networking)
+ * that certain resources are reserved for their use. When those drivers (and 
in
+ * some cases, their corresponding device-tree nodes) are updated to 
dynamically
+ * allocate their resources, then *all* resources can be managed by the
+ * allocators and there may be no further need to define these stubs.
+ *
+ * A couple of qualifiers to the above statement though:
+ *
+ * - Some resource ranges are hardware-specific, rather than being defined by
+ *   software memory allocation choices. Eg. the number of available BPIDs is
+ *   baked into silicon and so will probably always need to be expressed in the
+ *   device-tree, though in that case it will express all BPIDs, not just those
+ *   available for dynamic allocation.
+ *
+ * - Even for memory-backed resources that are software determined (FQIDs), 
this
+ *   information may only be configured and available on the control-plane
+ *   partition that manages the device, so in