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

[PATCH 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
---
 .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
new file mode 100644
index 0000000..c30bdde
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
@@ -0,0 +1,98 @@
+QorIQ DPAA Buffer Manager Device Tree Bindings
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- BMan Node
+	- BMan Private Memory Node
+	- Example
+
+NOTE:	The bindings described in this document are preliminary and subject to
+	change
+
+BMan Node
+
+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
+
+- 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
+
+BMan Private Memory Node
+
+BMan requires a contiguous range of physical memory used for the backing store
+for BMan Free Buffer Proxy Records. 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 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
+
+If the memory reserved in the device tree proves to be larger then the needs of
+the application a BMan driver may provide a method to release the extra memory
+back to the OS
+
+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 {
+			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
+
+	bman@31a000 {
+		compatible = "fsl,bman";
+		reg = <0x31a000 0x1000>;
+		interrupts = <16 2 1 2>;
+		fsl,liodn = <0x17>;
+	};
-- 
2.1.2

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

[Emil Medve]

Portals are used by software running on processor cores, accelerators and
network interfaces to communicate with the BMan

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

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
new file mode 100644
index 0000000..40e607e
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
@@ -0,0 +1,50 @@
+QorIQ DPAA Buffer Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- BMan Portal
+	- Example
+
+NOTE:	The bindings described in this document are preliminary and subject to
+	change
+
+BMan Portal Node
+
+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
+
+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.2

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

[Mark Rutland]

On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
> Portals are used by software running on processor cores, accelerators and
> network interfaces to communicate with the BMan

What exactly is a portal?

Is it a region of shared memory? A device?

I only received emails 2 and 3 of this series, so I'm lacking the
context necessary to understand the bindings.

> 
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
> ---
>  .../bindings/powerpc/fsl/bman-portals.txt          | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> new file mode 100644
> index 0000000..40e607e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> @@ -0,0 +1,50 @@
> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> +	- BMan Portal
> +	- Example
> +
> +NOTE:	The bindings described in this document are preliminary and subject to
> +	change

While we've tried that elsewhere, unstable DT bindings have been shown
to be a major source of pain. I'd feel rather uncomfortable accepting a
binding that we already believe to be insufficient to describe the
hardware.

What do you expect to change?

> +
> +BMan Portal Node
> +
> +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
> +
> +EXAMPLE
> +
> +The example below shows a (P4080) BMan portals container/bus node with two portals

Is there any particular reason to place these under a simple-bus?

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

It would be easier to read is each entry had its own set of brackets.
Initially this looked to me like a single 64-bit address/size pair.

> +			interrupts = <105 2 0 0>;
> +		};

Given the description above, surely you need to know what the portal is
used for? Or is that queried from the portal?

Thanks,
Mark.

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

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

[Emil Medve]

Hello Mark,


Thanks for having a look at this

On 10/22/2014 09:29 AM, Mark Rutland wrote:
> On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
>> Portals are used by software running on processor cores, accelerators and
>> network interfaces to communicate with the BMan
> 
> What exactly is a portal?
> 
> Is it a region of shared memory? A device?

In a nutshell a (software, i.e. processor core accessible) portal is a
memory mapped interface to the B/QMan that allows low latency, lock-less
interaction by logically separated units of software. The original
intent was to have one affine portal per core. As of now we're
sprinkling portals to use from various (core affine) contexts:
hypervisor, guests, user-space, containers, etc.

I'll make the definition more palatable in the next round

> I only received emails 2 and 3 of this series, so I'm lacking the
> context necessary to understand the bindings.

Some bubble in the pipe... As of now they all seem to have hit the
e-mail list(s), patchwork and hopefully your Inbox

>> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
>> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
>> ---
>>  .../bindings/powerpc/fsl/bman-portals.txt          | 50 ++++++++++++++++++++++
>>  1 file changed, 50 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>> new file mode 100644
>> index 0000000..40e607e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>> @@ -0,0 +1,50 @@
>> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
>> +
>> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
>> +
>> +CONTENTS
>> +
>> +	- BMan Portal
>> +	- Example
>> +
>> +NOTE:	The bindings described in this document are preliminary and subject to
>> +	change
> 
> While we've tried that elsewhere, unstable DT bindings have been shown
> to be a major source of pain.

Agreed

> I'd feel rather uncomfortable accepting a
> binding that we already believe to be insufficient to describe the
> hardware.
> 
> What do you expect to change?

Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
covers incompletely a dynamic LIODN assignment/programming model. The
current driver uses a static assignment scheme that the binding needs to
include. I also suspect that once the driver starts supporting the
dynamic LIODN assignment/programming we might find some wrinkles

>> +
>> +BMan Portal Node
>> +
>> +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
>> +
>> +EXAMPLE
>> +
>> +The example below shows a (P4080) BMan portals container/bus node with two portals
> 
> Is there any particular reason to place these under a simple-bus?

I think they fit the ePAPR definition for simple-bus container. They can
be accessed directly and can be used independently. What are you suggesting?

>> +
>> +	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>;
> 
> It would be easier to read is each entry had its own set of brackets.
> Initially this looked to me like a single 64-bit address/size pair.

Something like <>, <>? It doesn't seem widely used but I agree is more
readable. I can include it in the the next spin

>> +			interrupts = <105 2 0 0>;
>> +		};
> 
> Given the description above, surely you need to know what the portal is
> used for? Or is that queried from the portal?

We don't need/want to include such information in the DT. Portals are
"allocated" dynamically and used by the respective context


Cheers,


> Thanks,
> Mark.
> 
>> +		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.2

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

[Mark Rutland]

On Wed, Oct 22, 2014 at 09:04:54PM +0100, Emil Medve wrote:
> Hello Mark,
> 
> 
> Thanks for having a look at this
> 
> On 10/22/2014 09:29 AM, Mark Rutland wrote:
> > On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
> >> Portals are used by software running on processor cores, accelerators and
> >> network interfaces to communicate with the BMan
> > 
> > What exactly is a portal?
> > 
> > Is it a region of shared memory? A device?
> 
> In a nutshell a (software, i.e. processor core accessible) portal is a
> memory mapped interface to the B/QMan that allows low latency, lock-less
> interaction by logically separated units of software. The original
> intent was to have one affine portal per core. As of now we're
> sprinkling portals to use from various (core affine) contexts:
> hypervisor, guests, user-space, containers, etc.
> 
> I'll make the definition more palatable in the next round

Thanks,

> > I only received emails 2 and 3 of this series, so I'm lacking the
> > context necessary to understand the bindings.
> 
> Some bubble in the pipe... As of now they all seem to have hit the
> e-mail list(s), patchwork and hopefully your Inbox

They've all come through now, yes.

I'd expected to see the relevant code too -- in isolation the bindings
are somewhat difficult to grok.

> 
> >> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> >> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
> >> ---
> >>  .../bindings/powerpc/fsl/bman-portals.txt          | 50 ++++++++++++++++++++++
> >>  1 file changed, 50 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> >> new file mode 100644
> >> index 0000000..40e607e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> >> @@ -0,0 +1,50 @@
> >> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
> >> +
> >> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> >> +
> >> +CONTENTS
> >> +
> >> +	- BMan Portal
> >> +	- Example
> >> +
> >> +NOTE:	The bindings described in this document are preliminary and subject to
> >> +	change
> > 
> > While we've tried that elsewhere, unstable DT bindings have been shown
> > to be a major source of pain.
> 
> Agreed
> 
> > I'd feel rather uncomfortable accepting a
> > binding that we already believe to be insufficient to describe the
> > hardware.
> > 
> > What do you expect to change?
> 
> Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
> covers incompletely a dynamic LIODN assignment/programming model. The
> current driver uses a static assignment scheme that the binding needs to
> include. I also suspect that once the driver starts supporting the
> dynamic LIODN assignment/programming we might find some wrinkles

Ok. Given that the driver doesn't seem to be in mainline (per a quick
grep), just put "DO NOT MERGE" or something like that in the commit
message. Once this is merged you're going to need to support it.

> >> +BMan Portal Node
> >> +
> >> +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
> >> +
> >> +EXAMPLE
> >> +
> >> +The example below shows a (P4080) BMan portals container/bus node with two portals
> > 
> > Is there any particular reason to place these under a simple-bus?
> 
> I think they fit the ePAPR definition for simple-bus container. They can
> be accessed directly and can be used independently. What are you suggesting?
> 
> >> +
> >> +	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>;
> > 
> > It would be easier to read is each entry had its own set of brackets.
> > Initially this looked to me like a single 64-bit address/size pair.
> 
> Something like <>, <>?

So here we'd have:

	reg = <0x000000 0x4000>,
	      <0x100000 0x1000>;

> It doesn't seem widely used but I agree is more readable. I can
> include it in the the next spin

Thanks.

> 
> >> +			interrupts = <105 2 0 0>;
> >> +		};
> > 
> > Given the description above, surely you need to know what the portal is
> > used for? Or is that queried from the portal?
> 
> We don't need/want to include such information in the DT. Portals are
> "allocated" dynamically and used by the respective context

Ok. So they have no fixed purpose and software allocates as necessary?
There are no constraints on how each portal may be used, or which portal
another agetn might use?

Thanks,
Mark.

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

[Geoff Thorpe]

SGksDQoNCkxlYXBpbmcgaW4gaGVyZSBhIGxpdHRsZSBhZnRlciB0aGUgZmFjdCwgdG8gYWRkIGEg
Yml0IG9mIGJhY2tncm91bmQgaW5mbyBvbiB0aGUgaGFyZHdhcmUgaW4gY2FzZSBpdCBoZWxwcy4N
Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFJ1dGxhbmQgW21h
aWx0bzptYXJrLnJ1dGxhbmRAYXJtLmNvbV0NCj4gU2VudDogT2N0b2Jlci0yMy0xNCA3OjE2IEFN
DQo+IFRvOiBNZWR2ZSBFbWlsaWFuLUVNTUVEVkUxDQo+IA0KPiBPbiBXZWQsIE9jdCAyMiwgMjAx
NCBhdCAwOTowNDo1NFBNICswMTAwLCBFbWlsIE1lZHZlIHdyb3RlOg0KPiA+IEhlbGxvIE1hcmss
DQo+ID4NCj4gPg0KPiA+IFRoYW5rcyBmb3IgaGF2aW5nIGEgbG9vayBhdCB0aGlzDQo+ID4NCj4g
PiBPbiAxMC8yMi8yMDE0IDA5OjI5IEFNLCBNYXJrIFJ1dGxhbmQgd3JvdGU6DQo+ID4gPiBPbiBX
ZWQsIE9jdCAyMiwgMjAxNCBhdCAwMzowOTozMFBNICswMTAwLCBFbWlsIE1lZHZlIHdyb3RlOg0K
PiA+ID4+IFBvcnRhbHMgYXJlIHVzZWQgYnkgc29mdHdhcmUgcnVubmluZyBvbiBwcm9jZXNzb3Ig
Y29yZXMsDQo+IGFjY2VsZXJhdG9ycyBhbmQNCj4gPiA+PiBuZXR3b3JrIGludGVyZmFjZXMgdG8g
Y29tbXVuaWNhdGUgd2l0aCB0aGUgQk1hbg0KPiA+ID4NCj4gPiA+IFdoYXQgZXhhY3RseSBpcyBh
IHBvcnRhbD8NCj4gPiA+DQo+ID4gPiBJcyBpdCBhIHJlZ2lvbiBvZiBzaGFyZWQgbWVtb3J5PyBB
IGRldmljZT8NCg0KSnVzdCB0byBzdXBwbGVtZW50IHdoYXQgRW1pbCBhbHJlYWR5IG1lbnRpb25l
ZCwgdGhlIHBvcnRhbHMgZWFjaCBjb250YWluIHR3byBtZW1vcnktbWFwcGVkIHJlZ2lvbnMgYW5k
IGEgc2luZ2xlIGludGVycnVwdC4gT25lIG9mIHRoZSByZWdpb25zIGlzIGEgY29udmVudGlvbmFs
IDRLIHBhZ2Ugb2YgMzItYml0IGNhY2hlLWluaGliaXRlZCByZWdpc3RlcnMgKGFuZCB0aGlzIGlu
Y2x1ZGVzIGFsbCB0aGUgY29udHJvbHMgYW5kIHN0YXR1cyBmb3IgdGhlIHBvcnRhbCdzIGludGVy
cnVwdCBsaW5lLCB3aGljaCBjb252ZXlzIGEgdmFyaWV0eSBvZiBpbmRpdmlkdWFsbHktY29uZmln
dXJhYmxlIGludGVycnVwdCBzb3VyY2UgY29uZGl0aW9ucykuIFRoZSBvdGhlciByZWdpb24gaXMg
YSAxNksgY2FjaGUtZW5hYmxlZCBzcGFjZSwgc28gdGhlICJyZWdpc3RlcnMiIGFyZSBjYWNoZWxp
bmUgd2lkdGggLSBpbnRlcmFjdGlvbiB3aXRoIHRoaXMgcmVsaWVzIG9uIGNhY2hlbGluZSBtYW5p
cHVsYXRpb24gaW5zdHJ1Y3Rpb25zIChmbHVzaGluZywgcHJlZmV0Y2hpbmcsIGV0YyksIGFuZCBp
biBzb21lIGNvbmZpZ3VyYXRpb25zIGhhcmR3YXJlIHdpbGwgaW5pdGlhdGUgc3Rhc2hpbmcgKGNh
Y2hlLXdhcm1pbmcpIGZvciBzb21lIG9mIHRob3NlIGNhY2hlbGluZXMsIHdoaWNoIGlzIG9uZSBv
ZiB0aGUgcmVhc29ucyB0aGF0IHRoZXNlIHBvcnRhbHMgaGF2ZSAiTElPRE4iIGluZm9ybWF0aW9u
IGNvbmZpZ3VyZWQgaW50byB0aGVtIChzdGFzaGluZyB0cmFuc2FjdGlvbnMgZ28gdGhyb3VnaCB0
aGUgSU9NTVUpLiBUaGUgb3RoZXIgcmVhc29uIGZvciBMSU9ETi9JT01NVSBjb250ZXh0IGlzIHRo
YXQgYWxsIHRoZSBhY2NlbGVyYXRvciBhbmQgbmV0d29ya2luZyBmdW5jdGlvbnMgYWNjZXNzZWQg
dmlhIGEgcG9ydGFsIHdpbGwgYmUgc3ViamVjdGVkIHRvIHRoZSBJT01NVSBjb250ZXh0IGluZm8g
b2YgdGhhdCBwb3J0YWwuIEluIHRoaXMgd2F5LCBhIHBvcnRhbCB0aGF0IGlzIG1hcHBlZC91c2Vk
IGJ5IGEgZ2l2ZW4gc29mdHdhcmUgY29udGV4dCBjYW4gYmUgc2V0dXAgc3VjaCB0aGF0IERNQSBn
ZW5lcmF0ZWQgYnkgaXRzIGhhcmR3YXJlIGludGVyYWN0aW9ucyB3aWxsIHJlc3BlY3QgdGhlIHNh
bWUgZ3Vlc3QtcGh5c2ljYWwgdHJhbnNsYXRpb25zIGFuZCByZXN0cmljdGlvbnMgYXMgYXBwbHkg
dG8gdGhlIHNvZnR3YXJlIGNvbnRleHQgaXRzZWxmLg0KDQpCVFcsIGEgc3Vic2V0IG9mIHRoZSBD
Q1NSIHJlZ2lzdGVycyBmb3IgdGhlIFFNYW4gYW5kIEJNYW4gYmxvY2tzIGFyZSB1c2VkIHRvIGNv
bmZpZ3VyZSB0aGVzZSBMSU9ETi9JT01NVSBhdHRyaWJ1dGVzIG9mIHRoZSBwb3J0YWxzLCBhcyBv
cHBvc2VkIHRvIHRob3NlIGF0dHJpYnV0ZXMgYmVpbmcgZXhwb3NlZCBpbiB0aGUgcmVnaXN0ZXIg
c3BhY2Ugb2YgdGhlIHBvcnRhbHMgdGhlbXNlbHZlcy4gSW4gdGhpcyB3YXksIHRoZSB1c2VyIG9m
IGEgbWVtb3J5LW1hcHBlZCBwb3J0YWwgY2Fubm90IHNldCB0aGVpciBvd24gTElPRE4vSU9NTVUg
YXR0cmlidXRlcywgdGhhdCBkZWNpc2lvbiBiZWxvbmdzIHRvIHdob2V2ZXIgdHdpZGRsZXMgd2l0
aCBDQ1NSLg0KDQo+ID4gR2l2ZW4gdGhlIGRlc2NyaXB0aW9uIGFib3ZlLCBzdXJlbHkgeW91IG5l
ZWQgdG8ga25vdyB3aGF0IHRoZQ0KPiBwb3J0YWwgaXMNCj4gPiA+IHVzZWQgZm9yPyBPciBpcyB0
aGF0IHF1ZXJpZWQgZnJvbSB0aGUgcG9ydGFsPw0KPiA+DQo+ID4gV2UgZG9uJ3QgbmVlZC93YW50
IHRvIGluY2x1ZGUgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUgRFQuIFBvcnRhbHMNCj4gYXJlDQo+
ID4gImFsbG9jYXRlZCIgZHluYW1pY2FsbHkgYW5kIHVzZWQgYnkgdGhlIHJlc3BlY3RpdmUgY29u
dGV4dA0KPiANCj4gT2suIFNvIHRoZXkgaGF2ZSBubyBmaXhlZCBwdXJwb3NlIGFuZCBzb2Z0d2Fy
ZSBhbGxvY2F0ZXMgYXMgbmVjZXNzYXJ5Pw0KPiBUaGVyZSBhcmUgbm8gY29uc3RyYWludHMgb24g
aG93IGVhY2ggcG9ydGFsIG1heSBiZSB1c2VkLCBvciB3aGljaA0KPiBwb3J0YWwNCj4gYW5vdGhl
ciBhZ2V0biBtaWdodCB1c2U/DQoNClllcywgcHJlY2lzZWx5LiBUaGV5J3JlIGludGVyY2hhbmdl
YWJsZSB3aW5kb3dzL2NvbnRleHRzIGludG8gdGhlIGhhcmR3YXJlLCBmb3IgaXNzdWluZyB2YXJp
b3VzIGtpbmRzIG9mIGNvbW1hbmRzIGFuZCBvYnRhaW5pbmcgdmFyaW91cyBraW5kcyBvZiByZXN1
bHRzL3N0YXR1cy4gVGhlIFNvQyBwcm92aWRlcyBhIGNlcnRhaW4gbnVtYmVyIG9mIHRoZXNlIHBv
cnRhbHMsIGFuZCBzb2Z0d2FyZSBjYW4gYWxsb2NhdGUgdGhlbSBvdXQgYW5kIGNvbmZpZ3VyZSB0
aGVtIGluIHdoYXRldmVyIG1hbm5lciAoc3RhdGljLCBkeW5hbWljLCAuLi4pLiBCZWNhdXNlIG9m
IHRoZSBDQ1NSLWNvbnRyb2xsZWQgTElPRE4vSU9NTVUgcG9ydGFsIGF0dHJpYnV0ZXMsIHR3byBw
b3J0YWxzIGNhbiBiZSBzZXQgdXAgdG8gaGF2ZSBkaWZmZXJlbnQgImFjY2VzcyIgYW5kIG9wZXJh
dGUgaW4gZGlmZmVyZW50IGNvbnRleHRzIChlZy4gYXBwcywgdmlydHVhbCBtYWNoaW5lcyksIGJ1
dCB0aGF0IGlzIGRldGVybWluZWQgYnkgY29udHJvbCBzb2Z0d2FyZSAoa2VybmVsIGRyaXZlcikg
Y29uZmlndXJhdGlvbiBvZiB0aG9zZSBwb3J0YWxzIGJlZm9yZSB0aGVpciB1c2UuIEluIHNob3J0
LCB0aGVyZSdzIG5vdGhpbmcgaW50cmluc2ljIHRvIHRoZSBwb3J0YWxzIChpZS4gZnJvbSBhIGhh
cmR3YXJlIHBlcnNwZWN0aXZlKSB0aGF0IGRpc3Rpbmd1aXNoZXMgdGhlbSBvciBwcmVkZXRlcm1p
bmVzIHRoZWlyIHVzZS4NCg0KQ2hlZXJzLA0KR2VvZmYNCg0KDQo=

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

[Emil Medve]

Hello Mark,


On 10/23/2014 06:16 AM, Mark Rutland wrote:
>>>> +NOTE:	The bindings described in this document are preliminary and subject to
>>>> +	change
>>>
>>> While we've tried that elsewhere, unstable DT bindings have been shown
>>> to be a major source of pain.
>>
>> Agreed
>>
>>> I'd feel rather uncomfortable accepting a
>>> binding that we already believe to be insufficient to describe the
>>> hardware.
>>>
>>> What do you expect to change?
>>
>> Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
>> covers incompletely a dynamic LIODN assignment/programming model. The
>> current driver uses a static assignment scheme that the binding needs to
>> include. I also suspect that once the driver starts supporting the
>> dynamic LIODN assignment/programming we might find some wrinkles
> 
> Ok. Given that the driver doesn't seem to be in mainline (per a quick
> grep), just put "DO NOT MERGE" or something like that in the commit
> message. Once this is merged you're going to need to support it.

We have a driver and once the bindings get accepted we'll (update the
driver as needed and) post the code


Cheers,

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

[Scott Wood]

On Wed, 2014-10-22 at 15:04 -0500, Emil Medve wrote:
> Hello Mark,
> 
> 
> Thanks for having a look at this
> 
> On 10/22/2014 09:29 AM, Mark Rutland wrote:
> > I'd feel rather uncomfortable accepting a
> > binding that we already believe to be insufficient to describe the
> > hardware.
> > 
> > What do you expect to change?
> 
> Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
> covers incompletely a dynamic LIODN assignment/programming model. The
> current driver uses a static assignment scheme that the binding needs to
> include. I also suspect that once the driver starts supporting the
> dynamic LIODN assignment/programming we might find some wrinkles

How is this different from any of the other QorIQ bindings that have
been merged without such a disclaimer?  The static LIODN model is
already there, even if documentation is missing, and should continue to
be supported even if we eventually implement a dynamic LIODN model.

> >> +
> >> +	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>;
> > 
> > It would be easier to read is each entry had its own set of brackets.
> > Initially this looked to me like a single 64-bit address/size pair.
> 
> Something like <>, <>? It doesn't seem widely used but I agree is more
> readable. I can include it in the the next spin

The older PPC device trees haven't used it much but I think it's pretty
common in the newer ARM trees.

-Scott

[PATCH 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
---
 .../devicetree/bindings/powerpc/fsl/qman.txt       | 134 +++++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
new file mode 100644
index 0000000..b9f288f
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
@@ -0,0 +1,134 @@
+QorIQ DPAA Queue Manager Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- QMan Node
+	- QMan Private Memory Nodes
+	- Example
+
+NOTE:	The bindings described in this document are preliminary and subject to
+	change
+
+QMan Node
+
+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
+
+- 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:	Half of the platform clock
+
+QMan Private Memory Nodes
+
+QMan requires two contiguous range of physical memory used for the backing store
+for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. 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 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
+
+If the memory reserved in the device tree proves to be larger then the needs of
+the application a QMan driver may provide a method to release the extra memory
+back to the OS
+
+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 {
+			compatible = "fsl,qman-fqd";
+			alloc-ranges = <0 0 0xf 0xffffffff>;
+			size = <0 0x400000>;
+			alignment = <0 0x400000>;
+		};
+		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";
+		};
+		...
+	};
+
+	qman@318000 {
+		compatible = "fsl,qman";
+		reg = <0x318000 0x1000>;
+		interrupts = <16 2 1 3>
+		fsl,liodn = <0x16>;
+		clocks = <&platform-pll 1>;
+	};
-- 
2.1.2

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

[Mark Rutland]

On Wed, Oct 22, 2014 at 03:09:31PM +0100, Emil Medve wrote:
> 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
> ---
>  .../devicetree/bindings/powerpc/fsl/qman.txt       | 134 +++++++++++++++++++++
>  1 file changed, 134 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
> new file mode 100644
> index 0000000..b9f288f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
> @@ -0,0 +1,134 @@
> +QorIQ DPAA Queue Manager Device Tree Binding
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> +	- QMan Node
> +	- QMan Private Memory Nodes
> +	- Example
> +
> +NOTE:	The bindings described in this document are preliminary and subject to
> +	change

As with the BMan portal binding, I'm rather uncomfortable with a
preliminary binding.

> +
> +QMan Node
> +
> +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
> +
> +- 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

This is not present in the example. Is this always required?

> +
> +- clocks
> +	Usage:		See clock-bindings.txt and qoriq-clock.txt
> +	Value type:	<prop-encoded-array>
> +	Definition:	Half of the platform clock
> +

I don't understand the description here. What is the clock from the PoV
of the QMan? Which input line on the QMan is this clock attached to?

Is there only one clock input? Or jsut one that you need to manage at
the moment?

You also seem to have an interrupt in the example. How many do you
expect, and what are their their logical functions?

> +QMan Private Memory Nodes
> +
> +QMan requires two contiguous range of physical memory used for the backing store
> +for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. 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 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
> +
> +If the memory reserved in the device tree proves to be larger then the needs of
> +the application a QMan driver may provide a method to release the extra memory
> +back to the OS

Driver details should be unimportant to the binding. This sentence can
disappear.

Thanks,
Mark.

> +
> +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 {
> +			compatible = "fsl,qman-fqd";
> +			alloc-ranges = <0 0 0xf 0xffffffff>;
> +			size = <0 0x400000>;
> +			alignment = <0 0x400000>;
> +		};
> +		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";
> +		};
> +		...
> +	};
> +
> +	qman@318000 {
> +		compatible = "fsl,qman";
> +		reg = <0x318000 0x1000>;
> +		interrupts = <16 2 1 3>
> +		fsl,liodn = <0x16>;
> +		clocks = <&platform-pll 1>;
> +	};
> -- 
> 2.1.2
> 
> 

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

[Emil Medve]

Hello Mark,


On 10/22/2014 09:37 AM, Mark Rutland wrote:
> On Wed, Oct 22, 2014 at 03:09:31PM +0100, Emil Medve wrote:
>> 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
>> ---
>>  .../devicetree/bindings/powerpc/fsl/qman.txt       | 134 +++++++++++++++++++++
>>  1 file changed, 134 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/qman.txt
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman.txt b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
>> new file mode 100644
>> index 0000000..b9f288f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/qman.txt
>> @@ -0,0 +1,134 @@
>> +QorIQ DPAA Queue Manager Device Tree Binding
>> +
>> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
>> +
>> +CONTENTS
>> +
>> +	- QMan Node
>> +	- QMan Private Memory Nodes
>> +	- Example
>> +
>> +NOTE:	The bindings described in this document are preliminary and subject to
>> +	change
> 
> As with the BMan portal binding, I'm rather uncomfortable with a
> preliminary binding.

Ditto

>> +
>> +QMan Node
>> +
>> +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
>> +
>> +- 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
> 
> This is not present in the example. Is this always required?

Sort of. Initial hardware (and current documentation) programming
suggestion was to configure all the PAMU instances the same way
regardless of what devices were behind them. Given the PAMU internal
caches sizes, this proved suboptimal from a performance perspective so
we're trying to discover/describe/use the PAMU topology

fsl,liodn is part of the undocumented static LIODN assignment binding
that the current PAMU driver uses. If fsl,iommu-parent is present,
fsl,liodn can be ignored and the LIODN can be assigned dynamically
and/or programmed only in the relevant PAMU instance

>> +
>> +- clocks
>> +	Usage:		See clock-bindings.txt and qoriq-clock.txt
>> +	Value type:	<prop-encoded-array>
>> +	Definition:	Half of the platform clock
>> +
> 
> I don't understand the description here. What is the clock from the PoV
> of the QMan? Which input line on the QMan is this clock attached to?
> 
> Is there only one clock input? Or jsut one that you need to manage at
> the moment?

As part of the programming model (QoS features specifically) QMan needs
to know its clock speed. Prior to the existence of the
clock-bindings.txt, a "static" clock-frequency property was/is used
convey such information. Using clock-binding.txt to describe the
clocking hierarchy in the SoC makes it easier with DFS, power
management, etc.

The platform clock/PLL binding is part of qoriq-clock.txt

> You also seem to have an interrupt in the example. How many do you
> expect, and what are their their logical functions?

That's the error interrupt and hopefully it never triggers. I didn't add
[many] words about it as it's a standard property

>> +QMan Private Memory Nodes
>> +
>> +QMan requires two contiguous range of physical memory used for the backing store
>> +for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. 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 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
>> +
>> +If the memory reserved in the device tree proves to be larger then the needs of
>> +the application a QMan driver may provide a method to release the extra memory
>> +back to the OS
> 
> Driver details should be unimportant to the binding. This sentence can
> disappear.

I'm trying to discourage reserved-memory nodes to be used to "optimize"
the memory allocation/usage. If it comes to it, I can drop this sentence


Cheers,


> Thanks,
> Mark.
> 
>> +
>> +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 {
>> +			compatible = "fsl,qman-fqd";
>> +			alloc-ranges = <0 0 0xf 0xffffffff>;
>> +			size = <0 0x400000>;
>> +			alignment = <0 0x400000>;
>> +		};
>> +		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";
>> +		};
>> +		...
>> +	};
>> +
>> +	qman@318000 {
>> +		compatible = "fsl,qman";
>> +		reg = <0x318000 0x1000>;
>> +		interrupts = <16 2 1 3>
>> +		fsl,liodn = <0x16>;
>> +		clocks = <&platform-pll 1>;
>> +	};
>> -- 
>> 2.1.2

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

[Mark Rutland]

[...]

> >> +QMan Node
> >> +
> >> +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
> >> +
> >> +- 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
> > 
> > This is not present in the example. Is this always required?
> 
> Sort of. Initial hardware (and current documentation) programming
> suggestion was to configure all the PAMU instances the same way
> regardless of what devices were behind them. Given the PAMU internal
> caches sizes, this proved suboptimal from a performance perspective so
> we're trying to discover/describe/use the PAMU topology
> 
> fsl,liodn is part of the undocumented static LIODN assignment binding
> that the current PAMU driver uses. If fsl,iommu-parent is present,
> fsl,liodn can be ignored and the LIODN can be assigned dynamically
> and/or programmed only in the relevant PAMU instance

Ok.

> >> +
> >> +- clocks
> >> +	Usage:		See clock-bindings.txt and qoriq-clock.txt
> >> +	Value type:	<prop-encoded-array>
> >> +	Definition:	Half of the platform clock
> >> +
> > 
> > I don't understand the description here. What is the clock from the PoV
> > of the QMan? Which input line on the QMan is this clock attached to?
> > 
> > Is there only one clock input? Or jsut one that you need to manage at
> > the moment?
> 
> As part of the programming model (QoS features specifically) QMan needs
> to know its clock speed. Prior to the existence of the
> clock-bindings.txt, a "static" clock-frequency property was/is used
> convey such information. Using clock-binding.txt to describe the
> clocking hierarchy in the SoC makes it easier with DFS, power
> management, etc.

Ok. My concern is the phrase "Half of the platform clock" is meaingless.
The property contains a phandle + clock-specifier pair that describe a
single input clock by reference (some bindings just say "clock
reference" for that, which is fine). This is not "half" of any
particular clock.

The description of the clock should describe what it logically is from
the PoV of the consumer (i.e. _this_ device) rather than the provider.
To me "platform clock" sounds like a description of the provider. Is
there a name for the clock input line on this device?

Is there only a single clock input? Or just one that you care about at
the moment?

> The platform clock/PLL binding is part of qoriq-clock.txt
> 
> > You also seem to have an interrupt in the example. How many do you
> > expect, and what are their their logical functions?
> 
> That's the error interrupt and hopefully it never triggers. I didn't add
> [many] words about it as it's a standard property

While the interrupts property is standard, it is only standard in the
sense that the name and format are standard. Not every bidning has an
interrupts property, and the set of interrupts described are specific to
the binding. Please describe the set of interrupts you expect.

Does the device only have the error interrupt, or is that the only
interrupt you care about?

> >> +QMan Private Memory Nodes
> >> +
> >> +QMan requires two contiguous range of physical memory used for the backing store
> >> +for QMan Frame Queue Descriptor and Packed Frame Descriptor Record. 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 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
> >> +
> >> +If the memory reserved in the device tree proves to be larger then the needs of
> >> +the application a QMan driver may provide a method to release the extra memory
> >> +back to the OS
> > 
> > Driver details should be unimportant to the binding. This sentence can
> > disappear.
> 
> I'm trying to discourage reserved-memory nodes to be used to "optimize"
> the memory allocation/usage. If it comes to it, I can drop this sentence

I think it would be preferable to do so.

Thanks,
Mark.

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

[Geoff Thorpe]

VGhvdWdodCBJJ2QgY29tbWVudCB0b28gb24gdGhlIGludGVycnVwdCBxdWVzdGlvbiBmb3IgdGhl
IGJsb2NrLWxldmVsIChub3QgcG9ydGFsLWxldmVsKSBub2RlOw0KDQo+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmsgUnV0bGFuZCBbbWFpbHRvOm1hcmsucnV0bGFuZEBh
cm0uY29tXQ0KPiBTZW50OiBPY3RvYmVyLTIzLTE0IDc6MjYgQU0NCj4gVG86IE1lZHZlIEVtaWxp
YW4tRU1NRURWRTENCj4gDQo+IFsuLi5dDQo+IA0KPiA+ID4gWW91IGFsc28gc2VlbSB0byBoYXZl
IGFuIGludGVycnVwdCBpbiB0aGUgZXhhbXBsZS4gSG93IG1hbnkgZG8geW91DQo+ID4gPiBleHBl
Y3QsIGFuZCB3aGF0IGFyZSB0aGVpciB0aGVpciBsb2dpY2FsIGZ1bmN0aW9ucz8NCj4gPg0KPiA+
IFRoYXQncyB0aGUgZXJyb3IgaW50ZXJydXB0IGFuZCBob3BlZnVsbHkgaXQgbmV2ZXIgdHJpZ2dl
cnMuIEkgZGlkbid0DQo+IGFkZA0KPiA+IFttYW55XSB3b3JkcyBhYm91dCBpdCBhcyBpdCdzIGEg
c3RhbmRhcmQgcHJvcGVydHkNCj4gDQo+IFdoaWxlIHRoZSBpbnRlcnJ1cHRzIHByb3BlcnR5IGlz
IHN0YW5kYXJkLCBpdCBpcyBvbmx5IHN0YW5kYXJkIGluIHRoZQ0KPiBzZW5zZSB0aGF0IHRoZSBu
YW1lIGFuZCBmb3JtYXQgYXJlIHN0YW5kYXJkLiBOb3QgZXZlcnkgYmlkbmluZyBoYXMgYW4NCj4g
aW50ZXJydXB0cyBwcm9wZXJ0eSwgYW5kIHRoZSBzZXQgb2YgaW50ZXJydXB0cyBkZXNjcmliZWQg
YXJlIHNwZWNpZmljDQo+IHRvDQo+IHRoZSBiaW5kaW5nLiBQbGVhc2UgZGVzY3JpYmUgdGhlIHNl
dCBvZiBpbnRlcnJ1cHRzIHlvdSBleHBlY3QuDQo+IA0KPiBEb2VzIHRoZSBkZXZpY2Ugb25seSBo
YXZlIHRoZSBlcnJvciBpbnRlcnJ1cHQsIG9yIGlzIHRoYXQgdGhlIG9ubHkNCj4gaW50ZXJydXB0
IHlvdSBjYXJlIGFib3V0Pw0KDQpTbyBhcyB3aXRoIHRoZSBwb3J0YWxzLCB0aGUgYmxvY2tzIHRo
ZW1zZWx2ZXMgZWFjaCBoYXZlIGEgc2luZ2xlIGludGVycnVwdCBsaW5lLCBidXQgYSBudW1iZXIg
b2YgdGhlIChDQ1NSKSByZWdpc3RlcnMgYXJlIHJlbGF0ZWQgdG8gdGhhdCBpbnRlcnJ1cHQgdG8g
Y2FwdHVyZSB0aGUgY29kZXMgYW5kIGF0dHJpYnV0ZXMgb2YgdGhlIHZhcmlvdXMgZXJyb3IgY29u
ZGl0aW9ucyBiZWluZyByZXBvcnRlZCwgYmVjYXVzZSBhIHdpZGUgdmFyaWV0eSBvZiBldmVudHMg
YW5kIGluZm9ybWF0aW9uIGNhbiBiZSBjb252ZXllZCB0aHJvdWdoIHRoYXQgaW50ZXJydXB0IGxp
bmUuIEluIGdlbmVyYWwsIHllcywgdGhpcyBpbnRlcnJ1cHQgbGluZSBpcyBvbmx5IGZvciAiZXJy
b3JzIiwgYnV0IHNvbWUgZXJyb3JzIGFyZSBtb3JlIGVxdWFsIHRoYW4gb3RoZXJzLiBFZy4gdGhl
cmUgaXMgdGhlIHVzdWFsIGNsYXNzIG9mIGNhdGFzdHJvcGhpYyBETUEtZmFpbHVyZSwgRUNDLCBo
YXJkd2FyZS1pbnRlcm5hbC1pbmNvbnNpc3RlbmN5IHR5cGVzIG9mIGVycm9ycyB0aGF0IGRldmlj
ZXMgdGVuZCB0byBzaG91dCBhYm91dC4gQnV0IHRoZXJlIGFyZSBhbHNvIHRocmVzaG9sZC1iYXNl
ZCAicmVzb3VyY2Ugc3RhcnZhdGlvbiIgdHlwZXMgb2YgImVycm9ycyIgdG9vLCB3aGljaCBhcmUg
bm90IHJlYWxseSBlcnJvcnMgcGVyIHNlLCB1bmxlc3MgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9u
IGFuZCB1c2UtY2FzZSBpcyBleHBsaWNpdGx5IGVuZ2luZWVyZWQgYW5kIGNvbnN0cmFpbmVkIHN1
Y2ggdGhhdCB0aGUgdGhyZXNob2xkcyBzaG91bGRuJ3QgZXZlciBnZXQgdHJpcHBlZC4NCg0KU28g
dGhlIGhhbmRsaW5nIG9mIHRoZSBpbnRlcnJ1cHQgaW52b2x2ZXMgaW50ZXJyb2dhdGluZyByZWdp
c3RlcnMgdG8gY2xhc3NpZnkgdGhlIHdoeSwgaG93LCBhbmQgd2hhdCwgYW5kIHRoZSByZWFjdGlv
biB0byBpdCAod2hldGhlciBhIHdyaXRlLXRvLWNsZWFyIGlzIG5lZWRlZCwgd2hldGhlciBpdCBz
aG91bGQgYmUgbWFza2VkLCB3aGV0aGVyIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIGhhbHRlZCwg
Li4uKSBpcyBhbHNvIGEgZmFpcmx5IGVsYWJvcmF0ZSBxdWVzdGlvbi4NCg0KSSBkb24ndCBrbm93
IHdoYXQgdGhlIGV4cGVjdGF0aW9ucyBhcmUgZm9yIHRoZXNlICJiaW5kaW5ncyIgZG9jcywgYnV0
IHRoZSByZXF1ZXN0IHRvICJkZXNjcmliZSB0aGUgc2V0IG9mIGludGVycnVwdHMgeW91IGV4cGVj
dCIgZG9lcyByaXNrIG9wZW5pbmcgYSBmYWlybHkgZWxhYm9yYXRlIGNhbiBvZiB3b3JtcyAodGhh
dCBtYXkgYmUgYmV0dGVyIGNvbmZpbmVkIHRvIHRoZSBkcml2ZXIpLiBVbmxlc3MgSSBtaXN1bmRl
cnN0b29kIHRoZSByZXF1ZXN0LCB3aGljaCBpcyBhbHdheXMgcXVpdGUgcG9zc2libGUgYmVmb3Jl
IG15IHNlY29uZCBjb2ZmZWUuLi4NCg0KQ2hlZXJzLA0KR2VvZmYNCg0KDQo=

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

[Emil Medve]

Hello Mark,


On 10/23/2014 06:26 AM, Mark Rutland wrote:
>>>> +- clocks
>>>> +	Usage:		See clock-bindings.txt and qoriq-clock.txt
>>>> +	Value type:	<prop-encoded-array>
>>>> +	Definition:	Half of the platform clock
>>>> +
>>>
>>> I don't understand the description here. What is the clock from the PoV
>>> of the QMan? Which input line on the QMan is this clock attached to?
>>>
>>> Is there only one clock input? Or jsut one that you need to manage at
>>> the moment?
>>
>> As part of the programming model (QoS features specifically) QMan needs
>> to know its clock speed. Prior to the existence of the
>> clock-bindings.txt, a "static" clock-frequency property was/is used
>> convey such information. Using clock-binding.txt to describe the
>> clocking hierarchy in the SoC makes it easier with DFS, power
>> management, etc.
> 
> Ok. My concern is the phrase "Half of the platform clock" is meaingless.
> The property contains a phandle + clock-specifier pair that describe a
> single input clock by reference (some bindings just say "clock
> reference" for that, which is fine). This is not "half" of any
> particular clock.
> 
> The description of the clock should describe what it logically is from
> the PoV of the consumer (i.e. _this_ device) rather than the provider.
> To me "platform clock" sounds like a description of the provider. Is
> there a name for the clock input line on this device?
> 
> Is there only a single clock input? Or just one that you care about at
> the moment?

This is the reference clock for QMan and is the only input clock. It's
derived form the platform PLL/clock and its frequency/speed is half of
the platform PLL. I'll update its description


Cheers,

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

[Emil Medve]

Portals are used by software running on processor cores, accelerators and
network interfaces to communicate with the QMan

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

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt b/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
new file mode 100644
index 0000000..c4e1e98
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/qman-portals.txt
@@ -0,0 +1,151 @@
+QorIQ DPAA Queue Manager Portals Device Tree Binding
+
+Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
+
+CONTENTS
+
+	- QMan Portal
+	- QMan Pool Channel
+	- Example
+
+NOTE:	The bindings described in this document are preliminary and subject to
+	change
+
+QMan Portal Node
+
+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
+
+- 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. This is
+			an optional property. It is a valid configuration for
+			this phandle to be dangling
+
+	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 support sub-nodes are:
+	* fman@0
+	* fman@1
+	* pme@0
+	* crypto@0
+
+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) BMan 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 {
+			cell-index = <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>;
+
+			fman@0 {
+				fsl,liodn = <0x21>;
+				dev-handle = <&fman0>;
+			};
+			fman@1 {
+				fsl,liodn = <0xa1>;
+				dev-handle = <&fman1>;
+			};
+			crypto@0 {
+				fsl,liodn = <0x41 0x66>;
+				dev-handle = <&crypto>;
+			};
+		};
+		qman-portal@4000 {
+			cell-index = <1>;
+			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>;
+
+			fman@1 {
+				fsl,liodn = <0xa2>;
+				dev-handle = <&fman0>;
+			};
+			fman@0 {
+				fsl,liodn = <0x22>;
+				dev-handle = <&fman1>;
+			};
+			crypto@0 {
+				fsl,liodn = <0x42 0x67>;
+				dev-handle = <&crypto>;
+			};
+		};
+	};
-- 
2.1.2

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

[Scott Wood]

On Wed, 2014-10-22 at 09:09 -0500, Emil Medve wrote:
> +- fsl,liodn
> +	Usage:		See pamu.txt
> +	Value type:	<prop-encoded-array>
> +	Definition:	PAMU property used for static LIODN assignment

There are two LIODNs on these nodes; you need to specifiy here which is
which.  Likewise on the crypto subnode.

> +The currently support sub-nodes are:
> +	* fman@0
> +	* fman@1
> +	* pme@0
> +	* crypto@0

s/support/supported/

> +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) BMan 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 {
> +			cell-index = <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>;
> +
> +			fman@0 {
> +				fsl,liodn = <0x21>;
> +				dev-handle = <&fman0>;
> +			};
> +			fman@1 {
> +				fsl,liodn = <0xa1>;
> +				dev-handle = <&fman1>;
> +			};
> +			crypto@0 {
> +				fsl,liodn = <0x41 0x66>;
> +				dev-handle = <&crypto>;
> +			};

Shouldn't have unit address without reg; use fman0/fman1/crypto instead.

-Scott

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

[Kumar Gala]

On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> =
wrote:

> 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
>=20
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> ---
> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 =
++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/bman.txt

Should these really be in bindings/powerpc/fsl, aren=92t you guys using =
this on ARM SoCs as well?

I can=92t remember if the TI guys had a HW allocator as part of their =
similar HW.

>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt =
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 0000000..c30bdde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,98 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> +	- BMan Node
> +	- BMan Private Memory Node
> +	- Example
> +
> +NOTE:	The bindings described in this document are preliminary =
and subject to
> +	change
> +
> +BMan Node
> +
> +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
> +
> +- 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
> +

interrupts should be in this list.

> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the =
backing store
> +for BMan Free Buffer Proxy Records. 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 =3D 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 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

RCW doesn=92t have any context here

> +
> +If the memory reserved in the device tree proves to be larger then =
the needs of
> +the application a BMan driver may provide a method to release the =
extra memory
> +back to the OS
> +
> +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 =3D <2>;
> +		#size-cells =3D <2>;
> +		ranges;
> +
> +		bman-fbpr {
> +			compatible =3D "fsl,bman-fbpr";
> +			alloc-ranges =3D <0 0 0xf 0xffffffff>;
> +			size =3D <0 0x1000000>;
> +			alignment =3D <0 0x1000000>;
> +		};
> +
> +	};
> +
> +The example below shows a (P4080) BMan CCSR-space node
> +
> +	bman@31a000 {
> +		compatible =3D "fsl,bman";
> +		reg =3D <0x31a000 0x1000>;
> +		interrupts =3D <16 2 1 2>;
> +		fsl,liodn =3D <0x17>;

no fsl,iommu-parent in the example?

> +	};

Do you not need a phandle between the bman and the memory node?

- k

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

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

[Scott Wood]

On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
> 
> > 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
> > ---
> > .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
> > 1 file changed, 98 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> 
> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?

The hardware on the ARM SoCs is different enough that I'm not sure the
same binding will cover it.  That said, putting things under <arch>
should be a last resort if nowhere else fits.

-Scott

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

[Emil Medve]

Hello Scott,


On 10/28/2014 01:08 PM, Scott Wood wrote:
> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
>>
>>> 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
>>> ---
>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
>>> 1 file changed, 98 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>>
>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
> 
> The hardware on the ARM SoCs is different enough that I'm not sure the
> same binding will cover it.  That said, putting things under <arch>
> should be a last resort if nowhere else fits.

OTC started ported the driver to the the ARM SoC and the feedback has
been that the driver needed minimal changes. The IOMMU has been the only
area of concern, and a small change to the binding has been suggested


Cheers,

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

[Scott Wood]

On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 10/28/2014 01:08 PM, Scott Wood wrote:
> > On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
> >> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
> >>
> >>> 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
> >>> ---
> >>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
> >>> 1 file changed, 98 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> >>
> >> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
> > 
> > The hardware on the ARM SoCs is different enough that I'm not sure the
> > same binding will cover it.  That said, putting things under <arch>
> > should be a last resort if nowhere else fits.
> 
> OTC started ported the driver to the the ARM SoC and the feedback has
> been that the driver needed minimal changes. The IOMMU has been the only
> area of concern, and a small change to the binding has been suggested

Do we need something in the binding to indicate device endianness?

If this binding is going to continue to be relevant to future DPAA
generations, I think we really ought to deal with the possibility that
there is more than one datapath instance, by having phandles and/or a
parent container to connect the related components.

-Scott

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

[Emil Medve]

Hello Scott,


On 10/29/2014 05:16 PM, Scott Wood wrote:
> On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 10/28/2014 01:08 PM, Scott Wood wrote:
>>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
>>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
>>>>
>>>>> 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
>>>>> ---
>>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
>>>>> 1 file changed, 98 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>>>>
>>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
>>>
>>> The hardware on the ARM SoCs is different enough that I'm not sure the
>>> same binding will cover it.  That said, putting things under <arch>
>>> should be a last resort if nowhere else fits.
>>
>> OTC started ported the driver to the the ARM SoC and the feedback has
>> been that the driver needed minimal changes. The IOMMU has been the only
>> area of concern, and a small change to the binding has been suggested
> 
> Do we need something in the binding to indicate device endianness?

As I said, I didn't have enough exposure to the ARM SoC so I can't
answer that

> If this binding is going to continue to be relevant to future DPAA
> generations, I think we really ought to deal with the possibility that
> there is more than one datapath instance

I'm unsure how relevant this will be going forward. In LS2 B/QMan is
abstracted/hidden away behind the MC (firmware). I wouldn't
over-engineer this without a clear picture of what multiple data-paths
per SoC even means at this point

> by having phandles and/or a parent container to connect the related
> components.

Connecting the related components is beyond the scope of this binding.
It will soon hit the e-mail list(s) as part of upstreaming the Ethernet
driver


Cheers,

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

[Scott Wood]

On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 10/29/2014 05:16 PM, Scott Wood wrote:
> > On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 10/28/2014 01:08 PM, Scott Wood wrote:
> >>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
> >>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
> >>>>
> >>>>> 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
> >>>>> ---
> >>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
> >>>>> 1 file changed, 98 insertions(+)
> >>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> >>>>
> >>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
> >>>
> >>> The hardware on the ARM SoCs is different enough that I'm not sure the
> >>> same binding will cover it.  That said, putting things under <arch>
> >>> should be a last resort if nowhere else fits.
> >>
> >> OTC started ported the driver to the the ARM SoC and the feedback has
> >> been that the driver needed minimal changes. The IOMMU has been the only
> >> area of concern, and a small change to the binding has been suggested
> > 
> > Do we need something in the binding to indicate device endianness?
> 
> As I said, I didn't have enough exposure to the ARM SoC so I can't
> answer that
> 
> > If this binding is going to continue to be relevant to future DPAA
> > generations, I think we really ought to deal with the possibility that
> > there is more than one datapath instance
> 
> I'm unsure how relevant this will be going forward. In LS2 B/QMan is
> abstracted/hidden away behind the MC (firmware).

This is why I was wondering whether the binding would be at all the
same...

>  I wouldn't over-engineer this without a clear picture of what multiple
> data-paths per SoC even means at this point

I don't think it's over-engineering.  Assuming only one instance of
something is generally sloppy engineering.  Linux doesn't need to
actually pay attention to it until and unless it becomes necessary, but
it's good to have the information in the device tree up front.

> > by having phandles and/or a parent container to connect the related
> > components.
> 
> Connecting the related components is beyond the scope of this binding.
> It will soon hit the e-mail list(s) as part of upstreaming the Ethernet
> driver

So you want us to merge this binding without being told how this works?
Or by "soon" do you mean before this binding is accepted?

-Scott

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

[Emil Medve]

Hello Scott,


On 10/30/2014 09:51 AM, Scott Wood wrote:
> On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 10/29/2014 05:16 PM, Scott Wood wrote:
>>> On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 10/28/2014 01:08 PM, Scott Wood wrote:
>>>>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
>>>>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
>>>>>>
>>>>>>> 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
>>>>>>> ---
>>>>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
>>>>>>> 1 file changed, 98 insertions(+)
>>>>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>>>>>>
>>>>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
>>>>>
>>>>> The hardware on the ARM SoCs is different enough that I'm not sure the
>>>>> same binding will cover it.  That said, putting things under <arch>
>>>>> should be a last resort if nowhere else fits.
>>>>
>>>> OTC started ported the driver to the the ARM SoC and the feedback has
>>>> been that the driver needed minimal changes. The IOMMU has been the only
>>>> area of concern, and a small change to the binding has been suggested
>>>
>>> Do we need something in the binding to indicate device endianness?
>>
>> As I said, I didn't have enough exposure to the ARM SoC so I can't
>> answer that
>>
>>> If this binding is going to continue to be relevant to future DPAA
>>> generations, I think we really ought to deal with the possibility that
>>> there is more than one datapath instance
>>
>> I'm unsure how relevant this will be going forward. In LS2 B/QMan is
>> abstracted/hidden away behind the MC (firmware).
> 
> This is why I was wondering whether the binding would be at all the
> same...
> 
>>  I wouldn't over-engineer this without a clear picture of what multiple
>> data-paths per SoC even means at this point
> 
> I don't think it's over-engineering.  Assuming only one instance of
> something is generally sloppy engineering.  Linux doesn't need to
> actually pay attention to it until and unless it becomes necessary, but
> it's good to have the information in the device tree up front.

I asked around and the "multiple data-path SoC" seems to be at this
point a speculation. It seems unclear how would it work, what
requirements/problems it would address/solve, what programming interface
it would have. I'm not sure what do you suggest we do

In order to reduce the sloppiness of this binding. I'll add a
memory-region phandle to connect each B/QMan node to their
reserved-memory node

>>> by having phandles and/or a parent container to connect the related
>>> components.
>>
>> Connecting the related components is beyond the scope of this binding.
>> It will soon hit the e-mail list(s) as part of upstreaming the Ethernet
>> driver
> 
> So you want us to merge this binding without being told how this works?

This binding stands on its own and each block (B/QMan) can be used for
some useful purpose by itself. All other blocks/applications that use
the B/QMan use the same basic interface acquire/release a "buffer" and
enqueue/dequeue a "packet". I'm not sure what you feel I didn't share

> Or by "soon" do you mean before this binding is accepted?

No. The Ethernet driver, the QI SEC driver, RMan driver, etc. employ the
B/QMan and *other* hardware resources in some specific way. I don't
think their binding/drivers condition accepting the B/QMan binding/driver


Cheers,

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

[Scott Wood]

On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 10/30/2014 09:51 AM, Scott Wood wrote:
> > On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 10/29/2014 05:16 PM, Scott Wood wrote:
> >>> On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
> >>>> Hello Scott,
> >>>>
> >>>>
> >>>> On 10/28/2014 01:08 PM, Scott Wood wrote:
> >>>>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
> >>>>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
> >>>>>>
> >>>>>>> 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
> >>>>>>> ---
> >>>>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
> >>>>>>> 1 file changed, 98 insertions(+)
> >>>>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> >>>>>>
> >>>>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
> >>>>>
> >>>>> The hardware on the ARM SoCs is different enough that I'm not sure the
> >>>>> same binding will cover it.  That said, putting things under <arch>
> >>>>> should be a last resort if nowhere else fits.
> >>>>
> >>>> OTC started ported the driver to the the ARM SoC and the feedback has
> >>>> been that the driver needed minimal changes. The IOMMU has been the only
> >>>> area of concern, and a small change to the binding has been suggested
> >>>
> >>> Do we need something in the binding to indicate device endianness?
> >>
> >> As I said, I didn't have enough exposure to the ARM SoC so I can't
> >> answer that
> >>
> >>> If this binding is going to continue to be relevant to future DPAA
> >>> generations, I think we really ought to deal with the possibility that
> >>> there is more than one datapath instance
> >>
> >> I'm unsure how relevant this will be going forward. In LS2 B/QMan is
> >> abstracted/hidden away behind the MC (firmware).
> > 
> > This is why I was wondering whether the binding would be at all the
> > same...
> > 
> >>  I wouldn't over-engineer this without a clear picture of what multiple
> >> data-paths per SoC even means at this point
> > 
> > I don't think it's over-engineering.  Assuming only one instance of
> > something is generally sloppy engineering.  Linux doesn't need to
> > actually pay attention to it until and unless it becomes necessary, but
> > it's good to have the information in the device tree up front.
> 
> I asked around and the "multiple data-path SoC" seems to be at this
> point a speculation. It seems unclear how would it work, what
> requirements/problems it would address/solve, what programming interface
> it would have. I'm not sure what do you suggest we do
> 
> In order to reduce the sloppiness of this binding. I'll add a
> memory-region phandle to connect each B/QMan node to their
> reserved-memory node

Thanks, that's the sort of thing I was looking for.  There should also
be a connection from the portals to the relevant bqman node, though we
need to deal with the possibility that the bqman node may not be present
(e.g. in a vm guest).

> >>> by having phandles and/or a parent container to connect the related
> >>> components.
> >>
> >> Connecting the related components is beyond the scope of this binding.
> >> It will soon hit the e-mail list(s) as part of upstreaming the Ethernet
> >> driver
> > 
> > So you want us to merge this binding without being told how this works?
> 
> This binding stands on its own and each block (B/QMan) can be used for
> some useful purpose by itself. All other blocks/applications that use
> the B/QMan use the same basic interface acquire/release a "buffer" and
> enqueue/dequeue a "packet". I'm not sure what you feel I didn't share

So there's no hardware connection between the bman and qman themselves?

-Scott

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

[Emil Medve]

Hello Scott,


On 10/30/2014 11:29 AM, Scott Wood wrote:
> On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 10/30/2014 09:51 AM, Scott Wood wrote:
>>> On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 10/29/2014 05:16 PM, Scott Wood wrote:
>>>>> On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
>>>>>> Hello Scott,
>>>>>>
>>>>>>
>>>>>> On 10/28/2014 01:08 PM, Scott Wood wrote:
>>>>>>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
>>>>>>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> ---
>>>>>>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
>>>>>>>>> 1 file changed, 98 insertions(+)
>>>>>>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>>>>>>>>
>>>>>>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
>>>>>>>
>>>>>>> The hardware on the ARM SoCs is different enough that I'm not sure the
>>>>>>> same binding will cover it.  That said, putting things under <arch>
>>>>>>> should be a last resort if nowhere else fits.
>>>>>>
>>>>>> OTC started ported the driver to the the ARM SoC and the feedback has
>>>>>> been that the driver needed minimal changes. The IOMMU has been the only
>>>>>> area of concern, and a small change to the binding has been suggested
>>>>>
>>>>> Do we need something in the binding to indicate device endianness?
>>>>
>>>> As I said, I didn't have enough exposure to the ARM SoC so I can't
>>>> answer that
>>>>
>>>>> If this binding is going to continue to be relevant to future DPAA
>>>>> generations, I think we really ought to deal with the possibility that
>>>>> there is more than one datapath instance
>>>>
>>>> I'm unsure how relevant this will be going forward. In LS2 B/QMan is
>>>> abstracted/hidden away behind the MC (firmware).
>>>
>>> This is why I was wondering whether the binding would be at all the
>>> same...
>>>
>>>>  I wouldn't over-engineer this without a clear picture of what multiple
>>>> data-paths per SoC even means at this point
>>>
>>> I don't think it's over-engineering.  Assuming only one instance of
>>> something is generally sloppy engineering.  Linux doesn't need to
>>> actually pay attention to it until and unless it becomes necessary, but
>>> it's good to have the information in the device tree up front.
>>
>> I asked around and the "multiple data-path SoC" seems to be at this
>> point a speculation. It seems unclear how would it work, what
>> requirements/problems it would address/solve, what programming interface
>> it would have. I'm not sure what do you suggest we do
>>
>> In order to reduce the sloppiness of this binding. I'll add a
>> memory-region phandle to connect each B/QMan node to their
>> reserved-memory node
> 
> Thanks, that's the sort of thing I was looking for.  There should also
> be a connection from the portals to the relevant bqman node

Nothing in the current programing model requires a portal to know its
B/QMan "parent". Should I add a phandle of sorts anyway?

> though we
> need to deal with the possibility that the bqman node may not be present
> (e.g. in a vm guest).
> 
>>>>> by having phandles and/or a parent container to connect the related
>>>>> components.
>>>>
>>>> Connecting the related components is beyond the scope of this binding.
>>>> It will soon hit the e-mail list(s) as part of upstreaming the Ethernet
>>>> driver
>>>
>>> So you want us to merge this binding without being told how this works?
>>
>> This binding stands on its own and each block (B/QMan) can be used for
>> some useful purpose by itself. All other blocks/applications that use
>> the B/QMan use the same basic interface acquire/release a "buffer" and
>> enqueue/dequeue a "packet". I'm not sure what you feel I didn't share
> 
> So there's no hardware connection between the bman and qman themselves?

Not a single one


Cheers,

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

[Scott Wood]

On Thu, 2014-10-30 at 11:45 -0500, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 10/30/2014 11:29 AM, Scott Wood wrote:
> > On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 10/30/2014 09:51 AM, Scott Wood wrote:
> >>> On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote:
> >>>> Hello Scott,
> >>>>
> >>>>
> >>>> On 10/29/2014 05:16 PM, Scott Wood wrote:
> >>>>> On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
> >>>>>> Hello Scott,
> >>>>>>
> >>>>>>
> >>>>>> On 10/28/2014 01:08 PM, Scott Wood wrote:
> >>>>>>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
> >>>>>>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
> >>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> ---
> >>>>>>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
> >>>>>>>>> 1 file changed, 98 insertions(+)
> >>>>>>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> >>>>>>>>
> >>>>>>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
> >>>>>>>
> >>>>>>> The hardware on the ARM SoCs is different enough that I'm not sure the
> >>>>>>> same binding will cover it.  That said, putting things under <arch>
> >>>>>>> should be a last resort if nowhere else fits.
> >>>>>>
> >>>>>> OTC started ported the driver to the the ARM SoC and the feedback has
> >>>>>> been that the driver needed minimal changes. The IOMMU has been the only
> >>>>>> area of concern, and a small change to the binding has been suggested
> >>>>>
> >>>>> Do we need something in the binding to indicate device endianness?
> >>>>
> >>>> As I said, I didn't have enough exposure to the ARM SoC so I can't
> >>>> answer that
> >>>>
> >>>>> If this binding is going to continue to be relevant to future DPAA
> >>>>> generations, I think we really ought to deal with the possibility that
> >>>>> there is more than one datapath instance
> >>>>
> >>>> I'm unsure how relevant this will be going forward. In LS2 B/QMan is
> >>>> abstracted/hidden away behind the MC (firmware).
> >>>
> >>> This is why I was wondering whether the binding would be at all the
> >>> same...
> >>>
> >>>>  I wouldn't over-engineer this without a clear picture of what multiple
> >>>> data-paths per SoC even means at this point
> >>>
> >>> I don't think it's over-engineering.  Assuming only one instance of
> >>> something is generally sloppy engineering.  Linux doesn't need to
> >>> actually pay attention to it until and unless it becomes necessary, but
> >>> it's good to have the information in the device tree up front.
> >>
> >> I asked around and the "multiple data-path SoC" seems to be at this
> >> point a speculation. It seems unclear how would it work, what
> >> requirements/problems it would address/solve, what programming interface
> >> it would have. I'm not sure what do you suggest we do
> >>
> >> In order to reduce the sloppiness of this binding. I'll add a
> >> memory-region phandle to connect each B/QMan node to their
> >> reserved-memory node
> > 
> > Thanks, that's the sort of thing I was looking for.  There should also
> > be a connection from the portals to the relevant bqman node
> 
> Nothing in the current programing model requires a portal to know its
> B/QMan "parent". Should I add a phandle of sorts anyway?

Well, you at least have the requirement to initialize the qbman parent
before using its portals, and you need to use the portals that go with
the qbman instances that are connected to the device you want to
access...

> > So there's no hardware connection between the bman and qman themselves?
> 
> Not a single one

OK.  Please keep in mind that I haven't worked with this stuff as
closely as you have. :-)

-Scott

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

[Emil Medve]

Hello Scott,


On 10/30/2014 04:26 PM, Scott Wood wrote:
> On Thu, 2014-10-30 at 11:45 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 10/30/2014 11:29 AM, Scott Wood wrote:
>>> On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 10/30/2014 09:51 AM, Scott Wood wrote:
>>>>> On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote:
>>>>>> Hello Scott,
>>>>>>
>>>>>>
>>>>>> On 10/29/2014 05:16 PM, Scott Wood wrote:
>>>>>>> On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
>>>>>>>> Hello Scott,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/28/2014 01:08 PM, Scott Wood wrote:
>>>>>>>>> On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
>>>>>>>>>> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> ---
>>>>>>>>>>> .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
>>>>>>>>>>> 1 file changed, 98 insertions(+)
>>>>>>>>>>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>>>>>>>>>>
>>>>>>>>>> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
>>>>>>>>>
>>>>>>>>> The hardware on the ARM SoCs is different enough that I'm not sure the
>>>>>>>>> same binding will cover it.  That said, putting things under <arch>
>>>>>>>>> should be a last resort if nowhere else fits.
>>>>>>>>
>>>>>>>> OTC started ported the driver to the the ARM SoC and the feedback has
>>>>>>>> been that the driver needed minimal changes. The IOMMU has been the only
>>>>>>>> area of concern, and a small change to the binding has been suggested
>>>>>>>
>>>>>>> Do we need something in the binding to indicate device endianness?
>>>>>>
>>>>>> As I said, I didn't have enough exposure to the ARM SoC so I can't
>>>>>> answer that
>>>>>>
>>>>>>> If this binding is going to continue to be relevant to future DPAA
>>>>>>> generations, I think we really ought to deal with the possibility that
>>>>>>> there is more than one datapath instance
>>>>>>
>>>>>> I'm unsure how relevant this will be going forward. In LS2 B/QMan is
>>>>>> abstracted/hidden away behind the MC (firmware).
>>>>>
>>>>> This is why I was wondering whether the binding would be at all the
>>>>> same...
>>>>>
>>>>>>  I wouldn't over-engineer this without a clear picture of what multiple
>>>>>> data-paths per SoC even means at this point
>>>>>
>>>>> I don't think it's over-engineering.  Assuming only one instance of
>>>>> something is generally sloppy engineering.  Linux doesn't need to
>>>>> actually pay attention to it until and unless it becomes necessary, but
>>>>> it's good to have the information in the device tree up front.
>>>>
>>>> I asked around and the "multiple data-path SoC" seems to be at this
>>>> point a speculation. It seems unclear how would it work, what
>>>> requirements/problems it would address/solve, what programming interface
>>>> it would have. I'm not sure what do you suggest we do
>>>>
>>>> In order to reduce the sloppiness of this binding. I'll add a
>>>> memory-region phandle to connect each B/QMan node to their
>>>> reserved-memory node
>>>
>>> Thanks, that's the sort of thing I was looking for.  There should also
>>> be a connection from the portals to the relevant bqman node
>>
>> Nothing in the current programing model requires a portal to know its
>> B/QMan "parent". Should I add a phandle of sorts anyway?
> 
> Well, you at least have the requirement to initialize the qbman parent
> before using its portals, and you need to use the portals that go with
> the qbman instances that are connected to the device you want to
> access...
> 
>>> So there's no hardware connection between the bman and qman themselves?
>>
>> Not a single one
> 
> OK.  Please keep in mind that I haven't worked with this stuff as
> closely as you have. :-)

Huh? What do you mean?


Cheers,

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

[Varun Sethi]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFtt
YWlsdG86bGludXhwcGMtZGV2LQ0KPiBib3VuY2VzK3ZhcnVuLnNldGhpPWZyZWVzY2FsZS5jb21A
bGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mIEVtaWwNCj4gTWVkdmUNCj4gU2VudDogVGh1
cnNkYXksIE9jdG9iZXIgMzAsIDIwMTQgMzoxMCBBTQ0KPiBUbzogV29vZCBTY290dC1CMDc0MjE7
IEt1bWFyIEdhbGENCj4gQ2M6IG1hcmsucnV0bGFuZEBhcm0uY29tOyBkZXZpY2V0cmVlQHZnZXIu
a2VybmVsLm9yZzsNCj4gcGF3ZWwubW9sbEBhcm0uY29tOyBjb3JiZXRAbHduLm5ldDsgVGhvcnBl
IEdlb2ZmLVIwMTM2MTsNCj4gaWpjK2RldmljZXRyZWVAaGVsbGlvbi5vcmcudWs7IGxpbnV4LWRv
Y0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAb3psYWJzLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS80XSBkdC9iaW5kaW5nczogSW50cm9k
dWNlIHRoZSBGU0wgUW9ySVEgRFBBQSBCTWFuDQo+IA0KPiBIZWxsbyBTY290dCwNCj4gDQo+IA0K
PiBPbiAxMC8yOC8yMDE0IDAxOjA4IFBNLCBTY290dCBXb29kIHdyb3RlOg0KPiA+IE9uIFR1ZSwg
MjAxNC0xMC0yOCBhdCAwOTozNiAtMDUwMCwgS3VtYXIgR2FsYSB3cm90ZToNCj4gPj4gT24gT2N0
IDIyLCAyMDE0LCBhdCA5OjA5IEFNLCBFbWlsIE1lZHZlIDxFbWlsaWFuLk1lZHZlQGZyZWVzY2Fs
ZS5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gVGhlIEJ1ZmZlciBNYW5hZ2VyIGlzIHBhcnQg
b2YgdGhlIERhdGEtUGF0aCBBY2NlbGVyYXRpb24gQXJjaGl0ZWN0dXJlDQo+IChEUEFBKS4NCj4g
Pj4+IEJNYW4gc3VwcG9ydHMgaGFyZHdhcmUgYWxsb2NhdGlvbiBhbmQgZGVhbGxvY2F0aW9uIG9m
IGJ1ZmZlcnMNCj4gPj4+IGJlbG9uZ2luZyB0byBwb29scyBvcmlnaW5hbGx5IGNyZWF0ZWQgYnkg
c29mdHdhcmUgd2l0aCBjb25maWd1cmFibGUNCj4gZGVwbGV0aW9uIHRocmVzaG9sZHMuDQo+ID4+
PiBUaGlzIGJpbmRpbmcgY292ZXJzIHRoZSBDQ1NSIHNwYWNlIHByb2dyYW1taW5nIG1vZGVsDQo+
ID4+Pg0KPiA+Pj4gU2lnbmVkLW9mZi1ieTogRW1pbCBNZWR2ZSA8RW1pbGlhbi5NZWR2ZUBGcmVl
c2NhbGUuY29tPg0KPiA+Pj4gQ2hhbmdlLUlkOiBJM2VjNDc5YmZiM2M5MTk1MWU5NjkwMmYwOTFm
NWQ3ZDJhZGJlZjNiMg0KPiA+Pj4gLS0tDQo+ID4+PiAuLi4vZGV2aWNldHJlZS9iaW5kaW5ncy9w
b3dlcnBjL2ZzbC9ibWFuLnR4dCAgICAgICB8IDk4DQo+ICsrKysrKysrKysrKysrKysrKysrKysN
Cj4gPj4+IDEgZmlsZSBjaGFuZ2VkLCA5OCBpbnNlcnRpb25zKCspDQo+ID4+PiBjcmVhdGUgbW9k
ZSAxMDA2NDQNCj4gPj4+IERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9wb3dlcnBj
L2ZzbC9ibWFuLnR4dA0KPiA+Pg0KPiA+PiBTaG91bGQgdGhlc2UgcmVhbGx5IGJlIGluIGJpbmRp
bmdzL3Bvd2VycGMvZnNsLCBhcmVu4oCZdCB5b3UgZ3V5cyB1c2luZyB0aGlzIG9uDQo+IEFSTSBT
b0NzIGFzIHdlbGw/DQo+ID4NCj4gPiBUaGUgaGFyZHdhcmUgb24gdGhlIEFSTSBTb0NzIGlzIGRp
ZmZlcmVudCBlbm91Z2ggdGhhdCBJJ20gbm90IHN1cmUgdGhlDQo+ID4gc2FtZSBiaW5kaW5nIHdp
bGwgY292ZXIgaXQuICBUaGF0IHNhaWQsIHB1dHRpbmcgdGhpbmdzIHVuZGVyIDxhcmNoPg0KPiA+
IHNob3VsZCBiZSBhIGxhc3QgcmVzb3J0IGlmIG5vd2hlcmUgZWxzZSBmaXRzLg0KPiANCj4gT1RD
IHN0YXJ0ZWQgcG9ydGVkIHRoZSBkcml2ZXIgdG8gdGhlIHRoZSBBUk0gU29DIGFuZCB0aGUgZmVl
ZGJhY2sgaGFzIGJlZW4NCj4gdGhhdCB0aGUgZHJpdmVyIG5lZWRlZCBtaW5pbWFsIGNoYW5nZXMu
IFRoZSBJT01NVSBoYXMgYmVlbiB0aGUgb25seSBhcmVhDQo+IG9mIGNvbmNlcm4sIGFuZCBhIHNt
YWxsIGNoYW5nZSB0byB0aGUgYmluZGluZyBoYXMgYmVlbiBzdWdnZXN0ZWQNCklPTU1VIHNwZWNp
ZmljIGJpbmRpbmcgd291bGQgYmUgZGlmZmVyZW50LiBUaGUgYmluZGluZyB3b3VsZCBoYXZlIHRv
IGNvbXBseSB0byB0aGUgYXJtLXNtbXUgYmluZGluZyAod2hpY2ggbmVlZHMgdG8gYmUgdXBkYXRl
ZCkuDQoNCi1WYXJ1bg0K

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

[Scott Wood]

On Wed, 2014-10-22 at 09:09 -0500, Emil Medve wrote:
> 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
> ---
>  .../devicetree/bindings/powerpc/fsl/bman.txt       | 98 ++++++++++++++++++++++
>  1 file changed, 98 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 0000000..c30bdde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,98 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> +	- BMan Node
> +	- BMan Private Memory Node
> +	- Example
> +
> +NOTE:	The bindings described in this document are preliminary and subject to
> +	change
> +
> +BMan Node
> +
> +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

Is there a version register in reg?  It would be nice to point it out in
the binding along with an example chip for each version, similar to
Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt.  This
would make it clear that the compatible needs to be changed if the
version register moves or no longer works the same way.

> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the backing store
> +for BMan Free Buffer Proxy Records. 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 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

What about accelerators?

> +If the memory reserved in the device tree proves to be larger then the needs of
> +the application a BMan driver may provide a method to release the extra memory
> +back to the OS

What if the memory reserved in the device tree proves to be smaller than
the needs of the application?

I think we should document this size as being a sane default for the
hardware, and add a way of describing that the size is tunable.

Below is the reserved-memory extension that I suggested to you
internally:

resizable (optional) - empty property
    - Indicates that the size of the dynamic allocation is flexible.  If
resizeable is present, the size property is optional.  If both resizable
and size are present, the size property indicates a recommended default
size for this hardware.

pow2-aligned (optional) - empty property
    - Only valid if resizable is present.  Indicates that the size must
be a power of two, and the address must be aligned to its size.  If both
pow2-aligned and alignment properties are present, pow2-aligned is used
if the region is resized, and the alignment property is used if the
region is not resized.

min-size (optional) - Only valid if resizable is present.  Specifies a
minimum acceptable size.

max-size (optional) - Only valid if resizable is present.  Specifies a
maximum acceptable size.

-Scott