[PATCH v3 0/4] dt/bindings: Introduce the FSL QorIQ DPAA B/QMan

[PATCH v3 0/4] dt/bindings: Introduce the FSL QorIQ DPAA B/QMan

[Emil Medve]

Outstanding topics:
	- Scott's reserved-memory updates proposal
	- Some LIODN loose ends
	- Private memory sizing

v3: Address feedback from Kumar Gala
	- Move bindings from Documentation/devicetree/bindings/powerpc/fsl to
	  Documentation/devicetree/bindings/soc/fsl to support ARM based SoC(s)
	- Add phandles to link the reserved-memory to the B/QMan nodes to support
	  multiple B/QMan nodes per SoC
	- Better handle acronyms
    Address feedback from Scott Wood
    	- Spelling error
	- Extra phandles to reflect DPAA blocks links to the B/QMan nodes in
	  order to support multiple B/QMan nodes per SoC
	- Add version register(s) information to highlight differences in the
	  programming model
	- Detail LIODN types/usage
	- Update nodes names without a 'reg' property

v2: Incorporate feedback from Mark Rutland
	- Remove "subject to change" notes
	- Add/document the 'interrupts' properties
	- Make multiple windows 'reg' properties more readable
	- Improve portal description

Emil Medve (4):
  dt/bindings: Introduce the FSL QorIQ DPAA BMan
  dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
  dt/bindings: Introduce the FSL QorIQ DPAA QMan
  dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)

 .../devicetree/bindings/soc/fsl/bman-portals.txt   |  56 +++++++
 Documentation/devicetree/bindings/soc/fsl/bman.txt | 125 ++++++++++++++++
 .../devicetree/bindings/soc/fsl/qman-portals.txt   | 154 +++++++++++++++++++
 Documentation/devicetree/bindings/soc/fsl/qman.txt | 165 +++++++++++++++++++++
 4 files changed, 500 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman-portals.txt
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman.txt
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/qman.txt

-- 
2.1.3

[PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Emil Medve]

The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
 Documentation/devicetree/bindings/soc/fsl/bman.txt | 125 +++++++++++++++++++++
 1 file changed, 125 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman.txt

diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.txt b/Documentation/devicetree/bindings/soc/fsl/bman.txt
new file mode 100644
index 0000000..9f80bf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/bman.txt
@@ -0,0 +1,125 @@
+QorIQ DPAA Buffer Manager Device Tree Bindings
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- BMan Node
+	- BMan Private Memory Node
+	- Example
+
+BMan Node
+
+The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
+BMan supports hardware allocation and deallocation of buffers belonging to pools
+originally created by software with configurable depletion thresholds. This
+binding covers the CCSR space programming model
+
+PROPERTIES
+
+- compatible
+	Usage:		Required
+	Value type:	<stringlist>
+	Definition:	Must include "fsl,bman"
+			May include "fsl,<SoC>-bman"
+
+- reg
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Registers region within the CCSR address space
+
+The BMan revision information is located in the BMAN_IP_REV_1/2 registers which
+are located at offsets 0xbf8 and 0xbfc
+
+- interrupts
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Standard property. The error interrupt
+
+- fsl,liodn
+	Usage:		See pamu.txt
+	Value type:	<prop-encoded-array>
+	Definition:	PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+	Usage:		See pamu.txt
+	Value type:	<phandle>
+	Definition:	PAMU property used for dynamic LIODN assignment
+
+	For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
+to the respective BMan instance
+
+- fsl,bman
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Description:	List of phandle and DCP index pairs, to the BMan instance
+			to which this device is connected via the DCP
+
+BMan Private Memory Node
+
+BMan requires a contiguous range of physical memory used for the backing store
+for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated as a
+node under the /reserved-memory node
+
+The BMan FBPR memory node must be named "bman-fbpr"
+
+PROPERTIES
+
+- compatible
+	Usage:		required
+	Value type:	<stringlist>
+	Definition:	Must inclide "fsl,bman-fbpr"
+
+The following constraints are relevant to the FBPR private memory:
+	- The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
+	  16 GiB
+	- The alignment must be a muliptle of the memory size
+
+The size of the FBPR must be chosen by observing the hardware features configured
+via the Reset Configuration Word (RCW) and that are relevant to a specific board
+(e.g. number of MAC(s) pinned-out, number of offline/host command FMan ports,
+etc.). The size configured in the DT must reflect the hardware capabilities and
+not the specific needs of an application
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a BMan FBPR dynamic allocation memory node
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		bman_fbpr: bman-fbpr {
+			compatible = "fsl,bman-fbpr";
+			alloc-ranges = <0 0 0xf 0xffffffff>;
+			size = <0 0x1000000>;
+			alignment = <0 0x1000000>;
+		};
+	};
+
+The example below shows a (P4080) BMan CCSR-space node
+
+	crypto@300000 {
+		...
+		fsl,bman = <&bman, 2>;
+		...
+	};
+
+	bman: bman@31a000 {
+		compatible = "fsl,bman";
+		reg = <0x31a000 0x1000>;
+		interrupts = <16 2 1 2>;
+		fsl,liodn = <0x17>;
+		memory-region = <&bman_fbpr>;
+	};
+
+	fman@400000 {
+		...
+		fsl,bman = <&bman, 0>;
+		...
+	};
-- 
2.1.3

[PATCH v3 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

[Emil Medve]

Portals are memory mapped interfaces to BMan that allow low-latency,
lock-less interaction by software running on processor cores, accelerators
and network interfaces with the BMan

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
---
 .../devicetree/bindings/soc/fsl/bman-portals.txt   | 56 ++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman-portals.txt

diff --git a/Documentation/devicetree/bindings/soc/fsl/bman-portals.txt b/Documentation/devicetree/bindings/soc/fsl/bman-portals.txt
new file mode 100644
index 0000000..2a00e14
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/bman-portals.txt
@@ -0,0 +1,56 @@
+QorIQ DPAA Buffer Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- BMan Portal
+	- Example
+
+BMan Portal Node
+
+Portals are memory mapped interfaces to BMan that allow low-latency, lock-less
+interaction by software running on processor cores, accelerators and network
+interfaces with the BMan
+
+PROPERTIES
+
+- compatible
+	Usage:		Required
+	Value type:	<stringlist>
+	Definition:	Must include "fsl,bman-portal-<hardware revision>"
+			May include "fsl,<SoC>-bman-portal" or "fsl,bman-portal"
+
+- reg
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Two regions. The first is the cache-enabled region of
+			the portal. The second is the cache-inhibited region of
+			the portal
+
+- interrupts
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Standard property
+
+EXAMPLE
+
+The example below shows a (P4080) BMan portals container/bus node with two portals
+
+	bman-portals@ff4000000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges = <0 0xf 0xf4000000 0x200000>;
+
+		bman-portal@0 {
+			compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
+			reg = <0x0 0x4000>, <0x100000 0x1000>;
+			interrupts = <105 2 0 0>;
+		};
+		bman-portal@4000 {
+			compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
+			reg = <0x4000 0x4000>, <0x101000 0x1000>;
+			interrupts = <107 2 0 0>;
+		};
+	};
-- 
2.1.3

[PATCH v3 3/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan

[Emil Medve]

The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA).
QMan supports queuing and QoS scheduling of frames to CPUs, network interfaces
and DPAA logic modules, maintains packet ordering within flows. Besides
providing flow-level queuing, is also responsible for congestion management
functions such as RED/WRED, congestion notifications and tail discards. This
binding covers the CCSR space programming model

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Change-Id: I3acb223893e42003d6c9dc061db568ec0b10d29b
---
 Documentation/devicetree/bindings/soc/fsl/qman.txt | 165 +++++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/qman.txt

diff --git a/Documentation/devicetree/bindings/soc/fsl/qman.txt b/Documentation/devicetree/bindings/soc/fsl/qman.txt
new file mode 100644
index 0000000..063e3a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/qman.txt
@@ -0,0 +1,165 @@
+QorIQ DPAA Queue Manager Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- QMan Node
+	- QMan Private Memory Nodes
+	- Example
+
+QMan Node
+
+The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA). QMan
+supports queuing and QoS scheduling of frames to CPUs, network interfaces and
+DPAA logic modules, maintains packet ordering within flows. Besides providing
+flow-level queuing, is also responsible for congestion management functions such
+as RED/WRED, congestion notifications and tail discards. This binding covers the
+CCSR space programming model
+
+PROPERTIES
+
+- compatible
+	Usage:		Required
+	Value type:	<stringlist>
+	Definition:	Must include "fsl,qman"
+			May include "fsl,<SoC>-qman"
+
+- reg
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Registers region within the CCSR address space
+
+The QMan revision information is located in the QMAN_IP_REV_1/2 registers which
+are located at offsets 0xbf8 and 0xbfc
+
+- interrupts
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Standard property. The error interrupt
+
+- fsl,liodn
+	Usage:		See pamu.txt
+	Value type:	<prop-encoded-array>
+	Definition:	PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+	Usage:		See pamu.txt
+	Value type:	<phandle>
+	Definition:	PAMU property used for dynamic LIODN assignment
+
+	For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+- clocks
+	Usage:		See clock-bindings.txt and qoriq-clock.txt
+	Value type:	<prop-encoded-array>
+	Definition:	Reference input clock. Its frequency is half of the
+			platform clock
+
+Devices connected to a QMan instance via Direct Connect Portals (DCP) must link
+to the respective QMan instance
+
+- fsl,qman
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Description:	List of phandle and DCP index pairs, to the QMan instance
+			to which this device is connected via the DCP
+
+QMan Private Memory Nodes
+
+QMan requires two contiguous range of physical memory used for the backing store
+for QMan Frame Queue Descriptor (FQD) and Packed Frame Descriptor Record (PFDR).
+This memory is reserved/allocated as a nodes under the /reserved-memory node
+
+The QMan FQD memory node must be named "qman-fqd"
+
+PROPERTIES
+
+- compatible
+	Usage:		required
+	Value type:	<stringlist>
+	Definition:	Must inclide "fsl,qman-fqd"
+
+The QMan PFDR memory node must be named "qman-pfdr"
+
+PROPERTIES
+
+- compatible
+	Usage:		required
+	Value type:	<stringlist>
+	Definition:	Must inclide "fsl,qman-pfdr"
+
+The following constraints are relevant to the FQD and PFDR private memory:
+	- The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to
+	  1 GiB
+	- The alignment must be a muliptle of the memory size
+
+The size of the FQD and PFDP must be chosen by observing the hardware features
+configured via the Reset Configuration Word (RCW) and that are relevant to a
+specific board (e.g. number of MAC(s) pinned-out, number of offline/host command
+FMan ports, etc.). The size configured in the DT must reflect the hardware
+capabilities and not the specific needs of an application
+
+For additional details about reserved memory regions see reserved-memory.txt
+
+EXAMPLE
+
+The example below shows a QMan FQD and a PFDR dynamic allocation memory nodes
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		qman_fqd: qman-fqd {
+			compatible = "fsl,qman-fqd";
+			alloc-ranges = <0 0 0xf 0xffffffff>;
+			size = <0 0x400000>;
+			alignment = <0 0x400000>;
+		};
+		qman_pfdr: qman-pfdr {
+			compatible = "fsl,qman-pfdr";
+			alloc-ranges = <0 0 0xf 0xffffffff>;
+			size = <0 0x2000000>;
+			alignment = <0 0x2000000>;
+		};
+	};
+
+The example below shows a (P4080) QMan CCSR-space node
+
+	clockgen: global-utilities@e1000 {
+		...
+		sysclk: sysclk {
+			...
+		};
+		...
+		platform_pll: platform-pll@c00 {
+			#clock-cells = <1>;
+			reg = <0xc00 0x4>;
+			compatible = "fsl,qoriq-platform-pll-1.0";
+			clocks = <&sysclk>;
+			clock-output-names = "platform-pll", "platform-pll-div2";
+		};
+		...
+	};
+
+	crypto@300000 {
+		...
+		fsl,qman = <&qman, 2>;
+		...
+	};
+
+	qman: qman@318000 {
+		compatible = "fsl,qman";
+		reg = <0x318000 0x1000>;
+		interrupts = <16 2 1 3>
+		fsl,liodn = <0x16>;
+		memory-region = <&qman_fqd &qman_pfdr>;
+		clocks = <&platform_pll 1>;
+	};
+
+	fman@400000 {
+		...
+		fsl,qman = <&qman, 0>;
+		...
+	};
-- 
2.1.3

[PATCH v3 4/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)

[Emil Medve]

Portals are memory mapped interfaces to QMan that allow low-latency,
lock-less interaction by software running on processor cores,
accelerators and network interfaces with the QMan

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Change-Id: I29764fa8093b5ce65460abc879446795c50d7185
---
 .../devicetree/bindings/soc/fsl/qman-portals.txt   | 154 +++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/qman-portals.txt

diff --git a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
new file mode 100644
index 0000000..48c4dae
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
@@ -0,0 +1,154 @@
+QorIQ DPAA Queue Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- QMan Portal
+	- QMan Pool Channel
+	- Example
+
+QMan Portal Node
+
+Portals are memory mapped interfaces to QMan that allow low-latency, lock-less
+interaction by software running on processor cores, accelerators and network
+interfaces with the QMan
+
+PROPERTIES
+
+- compatible
+	Usage:		Required
+	Value type:	<stringlist>
+	Definition:	Must include "fsl,qman-portal-<hardware revision>"
+			May include "fsl,<SoC>-qman-portal" or "fsl,qman-portal"
+
+- reg
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Two regions. The first is the cache-enabled region of
+			the portal. The second is the cache-inhibited region of
+			the portal
+
+- interrupts
+	Usage:		Required
+	Value type:	<prop-encoded-array>
+	Definition:	Standard property
+
+- fsl,liodn
+	Usage:		See pamu.txt
+	Value type:	<prop-encoded-array>
+	Definition:	Two LIODN(s). DQRR LIODN (DLIODN) and Frame LIODN
+			(FLIODN)
+
+- fsl,iommu-parent
+	Usage:		See pamu.txt
+	Value type:	<phandle>
+	Definition:	PAMU property used for dynamic LIODN assignment
+
+	For additional details about the PAMU/LIODN binding(s) see pamu.txt
+
+- fsl,qman-channel-id
+	Usage:		Required
+	Value type:	<u32>
+	Definition:	The hardware index of the channel. This can also be
+			determined by dividing any of the channel's 8 work queue
+			IDs by 8
+
+In addition to these properties the qman-portals should have sub-nodes to
+represent the HW devices/portals that are connected to the software portal
+described here
+
+The currently supported sub-nodes are:
+	* fman0
+	* fman1
+	* pme
+	* crypto
+
+These subnodes should have the following properties:
+
+- fsl,liodn
+	Usage:		See pamu.txt
+	Value type:	<prop-encoded-array>
+	Definition:	PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+	Usage:		See pamu.txt
+	Value type:	<phandle>
+	Definition:	PAMU property used for dynamic LIODN assignment
+
+- dev-handle
+	Usage:		Required
+	Value type:	<phandle>
+	Definition:	The phandle to the particular hardware device that this
+			portal is connected to.
+
+DPAA QMan Pool Channel Nodes
+
+Pool Channels are defined with the following properties.
+
+PROPERTIES
+
+- compatible
+	Usage:		Required
+	Value type:	<stringlist>
+	Definition:	Must include "fsl,qman-pool-channel"
+			May include "fsl,<SoC>-qman-pool-channel"
+
+- fsl,qman-channel-id
+	Usage:		Required
+	Value type:	<u32>
+	Definition:	The hardware index of the channel. This can also be
+			determined by dividing any of the channel's 8 work queue
+			IDs by 8
+
+EXAMPLE
+
+The example below shows a (P4080) QMan portals container/bus node with two portals
+
+	qman-portals@ff4200000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges = <0 0xf 0xf4200000 0x200000>;
+
+		qman-portal@0 {
+			compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
+			reg = <0 0x4000>, <0x100000 0x1000>;
+			interrupts = <104 2 0 0>;
+			fsl,liodn = <1 2>;
+			fsl,qman-channel-id = <0>;
+
+			fman0 {
+				fsl,liodn = <0x21>;
+				dev-handle = <&fman0>;
+			};
+			fman1 {
+				fsl,liodn = <0xa1>;
+				dev-handle = <&fman1>;
+			};
+			crypto {
+				fsl,liodn = <0x41 0x66>;
+				dev-handle = <&crypto>;
+			};
+		};
+		qman-portal@4000 {
+			compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
+			reg = <0x4000 0x4000>, <0x101000 0x1000>;
+			interrupts = <106 2 0 0>;
+			fsl,liodn = <3 4>;
+			fsl,qman-channel-id = <1>;
+
+			fman0 {
+				fsl,liodn = <0x22>;
+				dev-handle = <&fman0>;
+			};
+			fman1 {
+				fsl,liodn = <0xa2>;
+				dev-handle = <&fman1>;
+			};
+			crypto {
+				fsl,liodn = <0x42 0x67>;
+				dev-handle = <&crypto>;
+			};
+		};
+	};
-- 
2.1.3

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Scott Wood]

On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
> +to the respective BMan instance
> +
> +- fsl,bman
> +	Usage:		Required
> +	Value type:	<prop-encoded-array>
> +	Description:	List of phandle and DCP index pairs, to the BMan instance
> +			to which this device is connected via the DCP

Does software need the DCP index (though for QMan there do seem to be a
few registers associated with each DCP)?  Where can I find that info in
the manual?

-Scott

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Emil Medve]

Hello Scott,


On 11/06/2014 03:49 PM, Scott Wood wrote:
> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
>> +to the respective BMan instance
>> +
>> +- fsl,bman
>> +	Usage:		Required
>> +	Value type:	<prop-encoded-array>
>> +	Description:	List of phandle and DCP index pairs, to the BMan instance
>> +			to which this device is connected via the DCP
> 
> Does software need the DCP index (though for QMan there do seem to be a
> few registers associated with each DCP)?  Where can I find that info in
> the manual?

The DCP index helps describe the topology of the devices connected to
the B/QMan. One might be tempted to use some address to reference said
DCP, unfortunately the pertinent registers/bits for said DCP(s) are not
into a compact region. Look at the CCSR memory map for B/QMan

In the QMan case things are marginally better. For each hardware portal
there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers
(configuration, performance monitoring and debugging). However, still
registers and bits spread here and there

In the BMan case things are a bit worse as the registers names are less
friendly and still spread around

Do you need specific names/offsets?


Cheers,

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Scott Wood]

On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 11/06/2014 03:49 PM, Scott Wood wrote:
> > On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
> >> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
> >> +to the respective BMan instance
> >> +
> >> +- fsl,bman
> >> +	Usage:		Required
> >> +	Value type:	<prop-encoded-array>
> >> +	Description:	List of phandle and DCP index pairs, to the BMan instance
> >> +			to which this device is connected via the DCP
> > 
> > Does software need the DCP index (though for QMan there do seem to be a
> > few registers associated with each DCP)?  Where can I find that info in
> > the manual?
> 
> The DCP index helps describe the topology of the devices connected to
> the B/QMan. One might be tempted to use some address to reference said
> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not
> into a compact region. Look at the CCSR memory map for B/QMan
> 
> In the QMan case things are marginally better. For each hardware portal
> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers
> (configuration, performance monitoring and debugging). However, still
> registers and bits spread here and there
> 
> In the BMan case things are a bit worse as the registers names are less
> friendly and still spread around
> 
> Do you need specific names/offsets?

My question about the manual wasn't rhetorical -- I tried to find this
information and couldn't.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Emil Medve]

Hello Scott,


On 11/07/2014 01:34 AM, Scott Wood wrote:
> On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/06/2014 03:49 PM, Scott Wood wrote:
>>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
>>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
>>>> +to the respective BMan instance
>>>> +
>>>> +- fsl,bman
>>>> +	Usage:		Required
>>>> +	Value type:	<prop-encoded-array>
>>>> +	Description:	List of phandle and DCP index pairs, to the BMan instance
>>>> +			to which this device is connected via the DCP
>>>
>>> Does software need the DCP index (though for QMan there do seem to be a
>>> few registers associated with each DCP)?  Where can I find that info in
>>> the manual?
>>
>> The DCP index helps describe the topology of the devices connected to
>> the B/QMan. One might be tempted to use some address to reference said
>> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not
>> into a compact region. Look at the CCSR memory map for B/QMan
>>
>> In the QMan case things are marginally better. For each hardware portal
>> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers
>> (configuration, performance monitoring and debugging). However, still
>> registers and bits spread here and there
>>
>> In the BMan case things are a bit worse as the registers names are less
>> friendly and still spread around
>>
>> Do you need specific names/offsets?
> 
> My question about the manual wasn't rhetorical -- I tried to find this
> information and couldn't.

I get that. As I said, the registers/bits are spread around in the CCSR
space of each block and not named excessively friendly. As such I hinted
for some search patterns to make it easier to find them. In order to
progress the review I'm willing to prepare a list. Just let me know


Cheers,

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Scott Wood]

On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 11/07/2014 01:34 AM, Scott Wood wrote:
> > On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 11/06/2014 03:49 PM, Scott Wood wrote:
> >>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
> >>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
> >>>> +to the respective BMan instance
> >>>> +
> >>>> +- fsl,bman
> >>>> +	Usage:		Required
> >>>> +	Value type:	<prop-encoded-array>
> >>>> +	Description:	List of phandle and DCP index pairs, to the BMan instance
> >>>> +			to which this device is connected via the DCP
> >>>
> >>> Does software need the DCP index (though for QMan there do seem to be a
> >>> few registers associated with each DCP)?  Where can I find that info in
> >>> the manual?
> >>
> >> The DCP index helps describe the topology of the devices connected to
> >> the B/QMan. One might be tempted to use some address to reference said
> >> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not
> >> into a compact region. Look at the CCSR memory map for B/QMan
> >>
> >> In the QMan case things are marginally better. For each hardware portal
> >> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers
> >> (configuration, performance monitoring and debugging). However, still
> >> registers and bits spread here and there
> >>
> >> In the BMan case things are a bit worse as the registers names are less
> >> friendly and still spread around
> >>
> >> Do you need specific names/offsets?
> > 
> > My question about the manual wasn't rhetorical -- I tried to find this
> > information and couldn't.
> 
> I get that. As I said, the registers/bits are spread around in the CCSR
> space of each block and not named excessively friendly. As such I hinted
> for some search patterns to make it easier to find them. In order to
> progress the review I'm willing to prepare a list. Just let me know

Could you point me to the section of the manual where this information
is -- friendly or otherwise?  I saw the QMan direct connect portal
registers.  I didn't see how to tell which <i> in DCPi_xxx goes with
which device.

-Scott

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Emil Medve]

Hello Scott,


On 11/07/2014 02:19 AM, Scott Wood wrote:
> On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/07/2014 01:34 AM, Scott Wood wrote:
>>> On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 11/06/2014 03:49 PM, Scott Wood wrote:
>>>>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
>>>>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
>>>>>> +to the respective BMan instance
>>>>>> +
>>>>>> +- fsl,bman
>>>>>> +	Usage:		Required
>>>>>> +	Value type:	<prop-encoded-array>
>>>>>> +	Description:	List of phandle and DCP index pairs, to the BMan instance
>>>>>> +			to which this device is connected via the DCP
>>>>>
>>>>> Does software need the DCP index (though for QMan there do seem to be a
>>>>> few registers associated with each DCP)?  Where can I find that info in
>>>>> the manual?
>>>>
>>>> The DCP index helps describe the topology of the devices connected to
>>>> the B/QMan. One might be tempted to use some address to reference said
>>>> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not
>>>> into a compact region. Look at the CCSR memory map for B/QMan
>>>>
>>>> In the QMan case things are marginally better. For each hardware portal
>>>> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers
>>>> (configuration, performance monitoring and debugging). However, still
>>>> registers and bits spread here and there
>>>>
>>>> In the BMan case things are a bit worse as the registers names are less
>>>> friendly and still spread around
>>>>
>>>> Do you need specific names/offsets?
>>>
>>> My question about the manual wasn't rhetorical -- I tried to find this
>>> information and couldn't.
>>
>> I get that. As I said, the registers/bits are spread around in the CCSR
>> space of each block and not named excessively friendly. As such I hinted
>> for some search patterns to make it easier to find them. In order to
>> progress the review I'm willing to prepare a list. Just let me know
> 
> Could you point me to the section of the manual where this information
> is -- friendly or otherwise?  I saw the QMan direct connect portal
> registers.  I didn't see how to tell which <i> in DCPi_xxx goes with
> which device.

For QMan look into section '6.3.10 Direct Connect Portals (DCPs)'. The
BMan DCP assignment is the same


Cheers,

Re: [PATCH v3 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan

[Scott Wood]

On Fri, 2014-11-07 at 03:38 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 11/07/2014 02:19 AM, Scott Wood wrote:
> > On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 11/07/2014 01:34 AM, Scott Wood wrote:
> >>> On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote:
> >>>> Hello Scott,
> >>>>
> >>>>
> >>>> On 11/06/2014 03:49 PM, Scott Wood wrote:
> >>>>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote:
> >>>>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
> >>>>>> +to the respective BMan instance
> >>>>>> +
> >>>>>> +- fsl,bman
> >>>>>> +	Usage:		Required
> >>>>>> +	Value type:	<prop-encoded-array>
> >>>>>> +	Description:	List of phandle and DCP index pairs, to the BMan instance
> >>>>>> +			to which this device is connected via the DCP
> >>>>>
> >>>>> Does software need the DCP index (though for QMan there do seem to be a
> >>>>> few registers associated with each DCP)?  Where can I find that info in
> >>>>> the manual?
> >>>>
> >>>> The DCP index helps describe the topology of the devices connected to
> >>>> the B/QMan. One might be tempted to use some address to reference said
> >>>> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not
> >>>> into a compact region. Look at the CCSR memory map for B/QMan
> >>>>
> >>>> In the QMan case things are marginally better. For each hardware portal
> >>>> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers
> >>>> (configuration, performance monitoring and debugging). However, still
> >>>> registers and bits spread here and there
> >>>>
> >>>> In the BMan case things are a bit worse as the registers names are less
> >>>> friendly and still spread around
> >>>>
> >>>> Do you need specific names/offsets?
> >>>
> >>> My question about the manual wasn't rhetorical -- I tried to find this
> >>> information and couldn't.
> >>
> >> I get that. As I said, the registers/bits are spread around in the CCSR
> >> space of each block and not named excessively friendly. As such I hinted
> >> for some search patterns to make it easier to find them. In order to
> >> progress the review I'm willing to prepare a list. Just let me know
> > 
> > Could you point me to the section of the manual where this information
> > is -- friendly or otherwise?  I saw the QMan direct connect portal
> > registers.  I didn't see how to tell which <i> in DCPi_xxx goes with
> > which device.
> 
> For QMan look into section '6.3.10 Direct Connect Portals (DCPs)'. The
> BMan DCP assignment is the same

Thanks, I'm not sure how I missed that.

-Scott