Hello Kumar,
Thanks for taking the time to review this
On 10/28/2014 09:39 AM, Kumar Gala wrote:
> On Oct 28, 2014, at 4:15 AM, Emil Medve <Emilian.Medve@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
>> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
>> ---
>> .../devicetree/bindings/powerpc/fsl/bman.txt | 95 ++++++++++++++++++++++
>> 1 file changed, 95 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?
We do, however, I didn't have any exposure yet to how the DPAA was
integrated there. From what I hear the biggest difference is in the
IOMMU area. Upstreaming the DPAA has been long overdue and I'd like to
make some progress with it as is on the PowerPC SoC(s)
> I can’t remember if the TI guys had a HW allocator as part of their
> similar HW. If so, possibly worth while to see where they have their
> binding.
Seems their data-path bindings are in
Documentation/devicetree/bindings/soc. I can move the B/QMan there and
it would level the way for the ARM SoC(s) with the DPAA
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>> new file mode 100644
>> index 0000000..d3fd1e3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>> @@ -0,0 +1,95 @@
>> +QorIQ DPAA Buffer Manager Device Tree Bindings
>> +
>> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
>> +
>> +CONTENTS
>> +
>> + - BMan Node
>> + - BMan Private Memory Node
>> + - Example
>> +
>> +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
>> +
>> +- interrupts
>> + Usage: Required
>> + Value type: <prop-encoded-array>
>> + Definition: Standard property. The error interrupt
>> +
>> +- fsl,liodn
>> + Usage: See pamu.txt
>> + Value type: <prop-encoded-array>
>> + Definition: PAMU property used for static LIODN assignment
>> +
>> +- fsl,iommu-parent
>> + Usage: See pamu.txt
>> + Value type: <phandle>
>> + Definition: PAMU property used for dynamic LIODN assignment
>> +
>> + For additional details about the PAMU/LIODN binding(s) see pamu.txt
>> +
>> +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
>
> … Proxy Records (FBPR). This
>
> [ so we get context for the acronym used later ]
Will do
>> +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
Will expand it
>> +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?
Using the PAMU/IOMMU topology (for dynamic LIODN allocation) is not
working yet in the PAMU driver (not even programming only the parent
PAMU with the static LIODN from the node) so I'm not quite in the habit
of sprinkling those around. I'll add them into the examples
>> + };
>
> Do you not need a phandle between the bman and the memory node?
Nope. And I'm thinking two reasons: (1) (if it gets to it) unique
compatible(s) for the reserved-memory nodes and (2)
RESERVEDMEM_OF_DECLARE() takes care to connect the dots based on said
compatible(s)
Cheers,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
