Message ID | 1413986972-621-1-git-send-email-Emilian.Medve@Freescale.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Scott Wood |
Headers | show |
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,
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>; + };
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