| Message ID | 1415200734-6978-2-git-send-email-Emilian.Medve@Freescale.com |
|---|---|
| State | Accepted, archived |
| Commit | 31ceb157f294843563330658c3ad6e3b5a1c4fe2 |
| Headers | show |
On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: > +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link > +to the respective BMan instance > + > +- fsl,bman > + Usage: Required > + Value type: <prop-encoded-array> > + Description: List of phandle and DCP index pairs, to the BMan instance > + to which this device is connected via the DCP Does software need the DCP index (though for QMan there do seem to be a few registers associated with each DCP)? Where can I find that info in the manual? -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Scott, On 11/06/2014 03:49 PM, Scott Wood wrote: > On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: >> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link >> +to the respective BMan instance >> + >> +- fsl,bman >> + Usage: Required >> + Value type: <prop-encoded-array> >> + Description: List of phandle and DCP index pairs, to the BMan instance >> + to which this device is connected via the DCP > > Does software need the DCP index (though for QMan there do seem to be a > few registers associated with each DCP)? Where can I find that info in > the manual? The DCP index helps describe the topology of the devices connected to the B/QMan. One might be tempted to use some address to reference said DCP, unfortunately the pertinent registers/bits for said DCP(s) are not into a compact region. Look at the CCSR memory map for B/QMan In the QMan case things are marginally better. For each hardware portal there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers (configuration, performance monitoring and debugging). However, still registers and bits spread here and there In the BMan case things are a bit worse as the registers names are less friendly and still spread around Do you need specific names/offsets? Cheers, -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: > Hello Scott, > > > On 11/06/2014 03:49 PM, Scott Wood wrote: > > On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: > >> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link > >> +to the respective BMan instance > >> + > >> +- fsl,bman > >> + Usage: Required > >> + Value type: <prop-encoded-array> > >> + Description: List of phandle and DCP index pairs, to the BMan instance > >> + to which this device is connected via the DCP > > > > Does software need the DCP index (though for QMan there do seem to be a > > few registers associated with each DCP)? Where can I find that info in > > the manual? > > The DCP index helps describe the topology of the devices connected to > the B/QMan. One might be tempted to use some address to reference said > DCP, unfortunately the pertinent registers/bits for said DCP(s) are not > into a compact region. Look at the CCSR memory map for B/QMan > > In the QMan case things are marginally better. For each hardware portal > there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers > (configuration, performance monitoring and debugging). However, still > registers and bits spread here and there > > In the BMan case things are a bit worse as the registers names are less > friendly and still spread around > > Do you need specific names/offsets? My question about the manual wasn't rhetorical -- I tried to find this information and couldn't. -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Scott, On 11/07/2014 01:34 AM, Scott Wood wrote: > On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: >> Hello Scott, >> >> >> On 11/06/2014 03:49 PM, Scott Wood wrote: >>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: >>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link >>>> +to the respective BMan instance >>>> + >>>> +- fsl,bman >>>> + Usage: Required >>>> + Value type: <prop-encoded-array> >>>> + Description: List of phandle and DCP index pairs, to the BMan instance >>>> + to which this device is connected via the DCP >>> >>> Does software need the DCP index (though for QMan there do seem to be a >>> few registers associated with each DCP)? Where can I find that info in >>> the manual? >> >> The DCP index helps describe the topology of the devices connected to >> the B/QMan. One might be tempted to use some address to reference said >> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not >> into a compact region. Look at the CCSR memory map for B/QMan >> >> In the QMan case things are marginally better. For each hardware portal >> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers >> (configuration, performance monitoring and debugging). However, still >> registers and bits spread here and there >> >> In the BMan case things are a bit worse as the registers names are less >> friendly and still spread around >> >> Do you need specific names/offsets? > > My question about the manual wasn't rhetorical -- I tried to find this > information and couldn't. I get that. As I said, the registers/bits are spread around in the CCSR space of each block and not named excessively friendly. As such I hinted for some search patterns to make it easier to find them. In order to progress the review I'm willing to prepare a list. Just let me know Cheers, -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote: > Hello Scott, > > > On 11/07/2014 01:34 AM, Scott Wood wrote: > > On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: > >> Hello Scott, > >> > >> > >> On 11/06/2014 03:49 PM, Scott Wood wrote: > >>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: > >>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link > >>>> +to the respective BMan instance > >>>> + > >>>> +- fsl,bman > >>>> + Usage: Required > >>>> + Value type: <prop-encoded-array> > >>>> + Description: List of phandle and DCP index pairs, to the BMan instance > >>>> + to which this device is connected via the DCP > >>> > >>> Does software need the DCP index (though for QMan there do seem to be a > >>> few registers associated with each DCP)? Where can I find that info in > >>> the manual? > >> > >> The DCP index helps describe the topology of the devices connected to > >> the B/QMan. One might be tempted to use some address to reference said > >> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not > >> into a compact region. Look at the CCSR memory map for B/QMan > >> > >> In the QMan case things are marginally better. For each hardware portal > >> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers > >> (configuration, performance monitoring and debugging). However, still > >> registers and bits spread here and there > >> > >> In the BMan case things are a bit worse as the registers names are less > >> friendly and still spread around > >> > >> Do you need specific names/offsets? > > > > My question about the manual wasn't rhetorical -- I tried to find this > > information and couldn't. > > I get that. As I said, the registers/bits are spread around in the CCSR > space of each block and not named excessively friendly. As such I hinted > for some search patterns to make it easier to find them. In order to > progress the review I'm willing to prepare a list. Just let me know Could you point me to the section of the manual where this information is -- friendly or otherwise? I saw the QMan direct connect portal registers. I didn't see how to tell which <i> in DCPi_xxx goes with which device. -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Scott, On 11/07/2014 02:19 AM, Scott Wood wrote: > On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote: >> Hello Scott, >> >> >> On 11/07/2014 01:34 AM, Scott Wood wrote: >>> On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: >>>> Hello Scott, >>>> >>>> >>>> On 11/06/2014 03:49 PM, Scott Wood wrote: >>>>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: >>>>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link >>>>>> +to the respective BMan instance >>>>>> + >>>>>> +- fsl,bman >>>>>> + Usage: Required >>>>>> + Value type: <prop-encoded-array> >>>>>> + Description: List of phandle and DCP index pairs, to the BMan instance >>>>>> + to which this device is connected via the DCP >>>>> >>>>> Does software need the DCP index (though for QMan there do seem to be a >>>>> few registers associated with each DCP)? Where can I find that info in >>>>> the manual? >>>> >>>> The DCP index helps describe the topology of the devices connected to >>>> the B/QMan. One might be tempted to use some address to reference said >>>> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not >>>> into a compact region. Look at the CCSR memory map for B/QMan >>>> >>>> In the QMan case things are marginally better. For each hardware portal >>>> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers >>>> (configuration, performance monitoring and debugging). However, still >>>> registers and bits spread here and there >>>> >>>> In the BMan case things are a bit worse as the registers names are less >>>> friendly and still spread around >>>> >>>> Do you need specific names/offsets? >>> >>> My question about the manual wasn't rhetorical -- I tried to find this >>> information and couldn't. >> >> I get that. As I said, the registers/bits are spread around in the CCSR >> space of each block and not named excessively friendly. As such I hinted >> for some search patterns to make it easier to find them. In order to >> progress the review I'm willing to prepare a list. Just let me know > > Could you point me to the section of the manual where this information > is -- friendly or otherwise? I saw the QMan direct connect portal > registers. I didn't see how to tell which <i> in DCPi_xxx goes with > which device. For QMan look into section '6.3.10 Direct Connect Portals (DCPs)'. The BMan DCP assignment is the same Cheers, -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2014-11-07 at 03:38 -0600, Emil Medve wrote: > Hello Scott, > > > On 11/07/2014 02:19 AM, Scott Wood wrote: > > On Fri, 2014-11-07 at 02:14 -0600, Emil Medve wrote: > >> Hello Scott, > >> > >> > >> On 11/07/2014 01:34 AM, Scott Wood wrote: > >>> On Fri, 2014-11-07 at 01:31 -0600, Emil Medve wrote: > >>>> Hello Scott, > >>>> > >>>> > >>>> On 11/06/2014 03:49 PM, Scott Wood wrote: > >>>>> On Wed, 2014-11-05 at 09:18 -0600, Emil Medve wrote: > >>>>>> +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link > >>>>>> +to the respective BMan instance > >>>>>> + > >>>>>> +- fsl,bman > >>>>>> + Usage: Required > >>>>>> + Value type: <prop-encoded-array> > >>>>>> + Description: List of phandle and DCP index pairs, to the BMan instance > >>>>>> + to which this device is connected via the DCP > >>>>> > >>>>> Does software need the DCP index (though for QMan there do seem to be a > >>>>> few registers associated with each DCP)? Where can I find that info in > >>>>> the manual? > >>>> > >>>> The DCP index helps describe the topology of the devices connected to > >>>> the B/QMan. One might be tempted to use some address to reference said > >>>> DCP, unfortunately the pertinent registers/bits for said DCP(s) are not > >>>> into a compact region. Look at the CCSR memory map for B/QMan > >>>> > >>>> In the QMan case things are marginally better. For each hardware portal > >>>> there are a handful of (vaguely named *DCx*, *DCPx* or *DCP*) registers > >>>> (configuration, performance monitoring and debugging). However, still > >>>> registers and bits spread here and there > >>>> > >>>> In the BMan case things are a bit worse as the registers names are less > >>>> friendly and still spread around > >>>> > >>>> Do you need specific names/offsets? > >>> > >>> My question about the manual wasn't rhetorical -- I tried to find this > >>> information and couldn't. > >> > >> I get that. As I said, the registers/bits are spread around in the CCSR > >> space of each block and not named excessively friendly. As such I hinted > >> for some search patterns to make it easier to find them. In order to > >> progress the review I'm willing to prepare a list. Just let me know > > > > Could you point me to the section of the manual where this information > > is -- friendly or otherwise? I saw the QMan direct connect portal > > registers. I didn't see how to tell which <i> in DCPi_xxx goes with > > which device. > > For QMan look into section '6.3.10 Direct Connect Portals (DCPs)'. The > BMan DCP assignment is the same Thanks, I'm not sure how I missed that. -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.txt b/Documentation/devicetree/bindings/soc/fsl/bman.txt new file mode 100644 index 0000000..9f80bf8 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/fsl/bman.txt @@ -0,0 +1,125 @@ +QorIQ DPAA Buffer Manager Device Tree Bindings + +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc. + +CONTENTS + + - BMan Node + - BMan Private Memory Node + - Example + +BMan Node + +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 + +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 + +The BMan revision information is located in the BMAN_IP_REV_1/2 registers which +are located at offsets 0xbf8 and 0xbfc + +- 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 + +Devices connected to a BMan instance via Direct Connect Portals (DCP) must link +to the respective BMan instance + +- fsl,bman + Usage: Required + Value type: <prop-encoded-array> + Description: List of phandle and DCP index pairs, to the BMan instance + to which this device is connected via the DCP + +BMan Private Memory Node + +BMan requires a contiguous range of physical memory used for the backing store +for BMan Free Buffer Proxy Records (FBPR). 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 Reset Configuration Word (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 + +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: 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 + + crypto@300000 { + ... + fsl,bman = <&bman, 2>; + ... + }; + + bman: bman@31a000 { + compatible = "fsl,bman"; + reg = <0x31a000 0x1000>; + interrupts = <16 2 1 2>; + fsl,liodn = <0x17>; + memory-region = <&bman_fbpr>; + }; + + fman@400000 { + ... + fsl,bman = <&bman, 0>; + ... + };
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 --- Documentation/devicetree/bindings/soc/fsl/bman.txt | 125 +++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/fsl/bman.txt