On Oct 22, 2014, at 9:09 AM, Emil Medve <emilian.me...@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.me...@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
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
