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

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

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

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

[...]

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

Thought I'd comment too on the interrupt question for the block-level (not portal-level) node;

> -----Original Message-----

> From: Mark Rutland [mailto:mark.rutland@arm.com]

> Sent: October-23-14 7:26 AM

> To: Medve Emilian-EMMEDVE1

> 

> [...]

> 

> > > 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?


So as with the portals, the blocks themselves each have a single interrupt line, but a number of the (CCSR) registers are related to that interrupt to capture the codes and attributes of the various error conditions being reported, because a wide variety of events and information can be conveyed through that interrupt line. In general, yes, this interrupt line is only for "errors", but some errors are more equal than others. Eg. there is the usual class of catastrophic DMA-failure, ECC, hardware-internal-inconsistency types of errors that devices tend to shout about. But there are also threshold-based "resource starvation" types of "errors" too, which are not really errors per se, unless the system configuration and use-case is explicitly engineered and constrained such that the thresholds shouldn't ever get tripped.

So the handling of the interrupt involves interrogating registers to classify the why, how, and what, and the reaction to it (whether a write-to-clear is needed, whether it should be masked, whether functionality should be halted, ...) is also a fairly elaborate question.

I don't know what the expectations are for these "bindings" docs, but the request to "describe the set of interrupts you expect" does risk opening a fairly elaborate can of worms (that may be better confined to the driver). Unless I misunderstood the request, which is always quite possible before my second coffee...

Cheers,
Geoff

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,

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?

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

> 
> 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 = 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’t 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 = <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>;

no fsl,iommu-parent in the example?

> +	};

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

- k

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

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

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,

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

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,

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

> -----Original Message-----

> From: Linuxppc-dev [mailto:linuxppc-dev-

> bounces+varun.sethi=freescale.com@lists.ozlabs.org] On Behalf Of Emil

> Medve

> Sent: Thursday, October 30, 2014 3:10 AM

> To: Wood Scott-B07421; Kumar Gala

> Cc: mark.rutland@arm.com; devicetree@vger.kernel.org;

> pawel.moll@arm.com; corbet@lwn.net; Thorpe Geoff-R01361;

> ijc+devicetree@hellion.org.uk; linux-doc@vger.kernel.org; linuxppc-

> dev@ozlabs.org; robh+dt@kernel.org

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

> 

> 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

IOMMU specific binding would be different. The binding would have to comply to the arm-smmu binding (which needs to be updated).

-Varun

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,

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

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,

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

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,