| Message ID | 1375094944-3343-3-git-send-email-hongbo.zhang@freescale.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On 07/29/2013 05:49:03 AM, hongbo.zhang@freescale.com wrote: > From: Hongbo Zhang <hongbo.zhang@freescale.com> > > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this > patch adds > the device tree nodes for them. > > Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com> > --- > .../devicetree/bindings/powerpc/fsl/dma.txt | 66 > ++++++++++++++++ > arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +- > arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 > ++++++++++++++++++++ > arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 > ++++++++++++++++++++ > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +- > 5 files changed, 232 insertions(+), 4 deletions(-) > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi ACK -Scott
On 07/30/2013 06:10 AM, Scott Wood wrote: > On 07/29/2013 05:49:03 AM, hongbo.zhang@freescale.com wrote: >> From: Hongbo Zhang <hongbo.zhang@freescale.com> >> >> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this >> patch adds >> the device tree nodes for them. >> >> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com> >> --- >> .../devicetree/bindings/powerpc/fsl/dma.txt | 66 >> ++++++++++++++++ >> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +- >> arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 >> ++++++++++++++++++++ >> arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 >> ++++++++++++++++++++ >> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +- >> 5 files changed, 232 insertions(+), 4 deletions(-) >> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi >> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi > > ACK Thank you Scott for all the review comments. > > -Scott
On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds > the device tree nodes for them. > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt > +** Freescale Elo3 DMA Controller > + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx > + series chips, such as t1040, t4240, b4860. > + > +Required properties: > + > +- compatible : must include "fsl,elo3-dma" This should probably list all the SoC-specific compatible values too. > +- ranges : describes the mapping between the address space of the > + DMA channels and the address space of the DMA controller Oh, so looking at the example, this is simply about being able to write the reg value in the child nodes more easily without having to write out the full based address of the controller in each child node. I don't think the binding document should require this; all the binding document should care about is that the child nodes have a valid reg value. Whether that reg value is <0x100100 0x80> without a ranges in the top-level DMA nor or whether that reg value is <0x0 0x80> with a ranges value in the top-level DMA node isn't something that the binding should specify. Either way will work equally without affecting a driver for the DMA controller; the parsing of reg with/without a ranges property is more of a core part of DT than anything to do with this binding. > +- DMA channel nodes: > + - compatible : must include "fsl,eloplus-dma-channel" Why do the channel nodes even need a compatible value? Presumably the driver for the top-level DMA node will scan these dma-channel nodes to extract the information it needs and will simply assume that all these nodes are DMA channel nodes rather than something else? I suppose this doesn't hurt, it just seems unnecessary unless you foresee other child nodes types existing in the future and hence a need to differentiate different types of nodes. > + - reg : <registers mapping for channel> > + - interrupts : <interrupt mapping for DMA channel IRQ> s/interrupts/specifier/ > +Example: > +dma@100300 { > + #address-cells = <1>; > + #size-cells = <1>; Those weren't mentioned in the required properties list above. Perhaps they're considered such a core part of DT functionality that it's not necessary, yet some other binding documents do include these properties in the list of required properties.
On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: > On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: > > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds > > the device tree nodes for them. > > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt > > > +** Freescale Elo3 DMA Controller > > + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx > > + series chips, such as t1040, t4240, b4860. > > + > > +Required properties: > > + > > +- compatible : must include "fsl,elo3-dma" > > This should probably list all the SoC-specific compatible values too. We're not going to specify them in the device tree (see my comment on patch 1/3), so we probably shouldn't lie about them in the binding like eloplus currently does. :-) > > +- ranges : describes the mapping between the address space of the > > + DMA channels and the address space of the DMA controller > > Oh, so looking at the example, this is simply about being able to write > the reg value in the child nodes more easily without having to write out > the full based address of the controller in each child node. > > I don't think the binding document should require this; It doesn't. It just requires that there be a mapping; it doesn't have to be any particular mapping. > all the binding document should care about is that the child nodes have a valid reg > value. Whether that reg value is <0x100100 0x80> without a ranges in the > top-level DMA Without a ranges property there is no translation and the registers would not be memory mappable. Linux may treat the absence of ranges as an identity mapping for compatibility with some broken OF trees, but it's not standard. > nor or whether that reg value is <0x0 0x80> with a ranges > value in the top-level DMA node isn't something that the binding should > specify. Either way will work equally without affecting a driver for the > DMA controller; the parsing of reg with/without a ranges property is > more of a core part of DT than anything to do with this binding. > > > +- DMA channel nodes: > > + - compatible : must include "fsl,eloplus-dma-channel" > > Why do the channel nodes even need a compatible value? Presumably the > driver for the top-level DMA node will scan these dma-channel nodes to > extract the information it needs and will simply assume that all these > nodes are DMA channel nodes rather than something else? I suppose this > doesn't hurt, it just seems unnecessary unless you foresee other child > nodes types existing in the future and hence a need to differentiate > different types of nodes. Other than "this is how the existing binding works and we're not going to break compatibility", it allows the OS more flexibility to choose whether to bind to controllers or directly to the channels. Sometimes a channel will be labelled with a different compatible if it has a fixed purpose such as being connected to audio hardware (e.g. mpc8610_hpcd.dts where some channels are "fsl,ssi-dma-channel"). The channels are mostly independent. Only an interrupt is shared on elo, and only an IOMMU device number on eloplus/elo3 -- plus a shared status register that doesn't have to be used and doesn't make sense to use without a shared interrupt. > > + - reg : <registers mapping for channel> > > + - interrupts : <interrupt mapping for DMA channel IRQ> > > s/interrupts/specifier/ > > > +Example: > > +dma@100300 { > > + #address-cells = <1>; > > + #size-cells = <1>; > > Those weren't mentioned in the required properties list above. It's inherent in the existence of child nodes with reg (unless you rely on the default of 2/1, which is discouraged). The binding should mention it if it has particular requirements for the value of either property, but I don't think we care here (much like we don't care what sort of translation is used in ranges). > Perhaps they're considered such a core part of DT functionality that it's not > necessary, yet some other binding documents do include these properties > in the list of required properties. Some bindings even try to repeat the definition of standard properties -- often incorrectly. We should avoid that. -Scott
On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: > On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: > > + - reg : <registers mapping for channel> > > + - interrupts : <interrupt mapping for DMA channel IRQ> > > s/interrupts/specifier/ Do you mean s/interrupt mapping/interrupt specifier/? And probably s/registers mapping/register specifier/ as well. -Scott
On 08/21/2013 04:57 PM, Scott Wood wrote: > On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: >> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: >>> +- ranges : describes the mapping between the address space of the >>> + DMA channels and the address space of the DMA controller >> >> Oh, so looking at the example, this is simply about being able to write >> the reg value in the child nodes more easily without having to write out >> the full based address of the controller in each child node. >> >> I don't think the binding document should require this; > > It doesn't. It just requires that there be a mapping; it doesn't have > to be any particular mapping. > >> all the binding document should care about is that the child nodes have a valid reg >> value. Whether that reg value is <0x100100 0x80> without a ranges in the >> top-level DMA > > Without a ranges property there is no translation and the registers > would not be memory mappable. Linux may treat the absence of ranges as > an identity mapping for compatibility with some broken OF trees, but > it's not standard. I would argue that missing ranges meaning 1:1 translation is now a standard, given that it must be true to support some DTs, it therefore can now be assumed? >> nor or whether that reg value is <0x0 0x80> with a ranges >> value in the top-level DMA node isn't something that the binding should >> specify. Either way will work equally without affecting a driver for the >> DMA controller; the parsing of reg with/without a ranges property is >> more of a core part of DT than anything to do with this binding. >> >>> +- DMA channel nodes: >>> + - compatible : must include "fsl,eloplus-dma-channel" >> >> Why do the channel nodes even need a compatible value? Presumably the >> driver for the top-level DMA node will scan these dma-channel nodes to >> extract the information it needs and will simply assume that all these >> nodes are DMA channel nodes rather than something else? I suppose this >> doesn't hurt, it just seems unnecessary unless you foresee other child >> nodes types existing in the future and hence a need to differentiate >> different types of nodes. > > Other than "this is how the existing binding works and we're not going > to break compatibility", it allows the OS more flexibility to choose > whether to bind to controllers or directly to the channels. Sometimes a > channel will be labelled with a different compatible if it has a fixed > purpose such as being connected to audio hardware (e.g. mpc8610_hpcd.dts > where some channels are "fsl,ssi-dma-channel"). That sounds terribly like encoding policy into DT rather than it being a HW description.
On 08/21/2013 05:00 PM, Scott Wood wrote: > On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: >> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: >>> + - reg : <registers mapping for channel> >>> + - interrupts : <interrupt mapping for DMA channel IRQ> >> >> s/interrupts/specifier/ > > Do you mean s/interrupt mapping/interrupt specifier/? > > And probably s/registers mapping/register specifier/ as well. Yup.
On Wed, 2013-08-21 at 17:15 -0600, Stephen Warren wrote: > On 08/21/2013 04:57 PM, Scott Wood wrote: > > On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: > >> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: > > >>> +- ranges : describes the mapping between the address space of the > >>> + DMA channels and the address space of the DMA controller > >> > >> Oh, so looking at the example, this is simply about being able to write > >> the reg value in the child nodes more easily without having to write out > >> the full based address of the controller in each child node. > >> > >> I don't think the binding document should require this; > > > > It doesn't. It just requires that there be a mapping; it doesn't have > > to be any particular mapping. > > > >> all the binding document should care about is that the child nodes have a valid reg > >> value. Whether that reg value is <0x100100 0x80> without a ranges in the > >> top-level DMA > > > > Without a ranges property there is no translation and the registers > > would not be memory mappable. Linux may treat the absence of ranges as > > an identity mapping for compatibility with some broken OF trees, but > > it's not standard. > > I would argue that missing ranges meaning 1:1 translation is now a > standard, given that it must be true to support some DTs, it therefore > can now be assumed? "Some broken tree does it therefore it's fine for everyone to do it" is awful. We have standards documents for a reason. Plus, not all OSes need to run on hardware with that broken firmware. For example, the Freescale Embedded Hypervisor will not accept a missing ranges in that way. U-Boot does accept it, but only because the code was copied from Linux (including the comment that says it's not supposed to work that way). If anything, we should remove the hack from U-Boot, and fix Linux to only apply it in situations where it's known to be needed. > >> Why do the channel nodes even need a compatible value? Presumably the > >> driver for the top-level DMA node will scan these dma-channel nodes to > >> extract the information it needs and will simply assume that all these > >> nodes are DMA channel nodes rather than something else? I suppose this > >> doesn't hurt, it just seems unnecessary unless you foresee other child > >> nodes types existing in the future and hence a need to differentiate > >> different types of nodes. > > > > Other than "this is how the existing binding works and we're not going > > to break compatibility", it allows the OS more flexibility to choose > > whether to bind to controllers or directly to the channels. Sometimes a > > channel will be labelled with a different compatible if it has a fixed > > purpose such as being connected to audio hardware (e.g. mpc8610_hpcd.dts > > where some channels are "fsl,ssi-dma-channel"). > > That sounds terribly like encoding policy into DT rather than it being a > HW description. It is hardware description. Those DMA channels are physically wired into the audio hardware. Other DMA channels in the same system aren't. The only thing that's even slightly policy is that it assumes you aren't going to ignore the audio device altogether, and use it as an extra generic DMA channel. I'm not sure that it's worthwhile to care in this case. If you want to be 100% policy-free then we shouldn't be specifying a lot of the addresses we currently do, since that's actually just how U-Boot configured things. Sometimes simplifying assumptions get made, when what the hardware people actually came up with is too awkward to be worth describing directly. In any case, this is not new, nor is it relevant to the hardware we're currently adding support for, and we're not going to break compatibility now. -Scott
On Wed, Aug 21, 2013 at 6:31 PM, Scott Wood <scottwood@freescale.com> wrote: > >> > Other than "this is how the existing binding works and we're not going >> > to break compatibility", it allows the OS more flexibility to choose >> > whether to bind to controllers or directly to the channels. Sometimes a >> > channel will be labelled with a different compatible if it has a fixed >> > purpose such as being connected to audio hardware (e.g. mpc8610_hpcd.dts >> > where some channels are "fsl,ssi-dma-channel"). >> >> That sounds terribly like encoding policy into DT rather than it being a >> HW description. > > It is hardware description. Those DMA channels are physically wired > into the audio hardware. Other DMA channels in the same system aren't. Well, not quite. Technically the DMA channel can be dynamically assigned to the SSI, but there are limits. At the time the code was written, there was no way to reserve a DMA channel from the generic DMA driver, and I didn't want to have to depend on that driver either. Using the device tree forced a specific pair of channels to be assigned to each SSI. The audio driver has code to program the SoC to route whichever DMA channels are assigned, but it assumes that the device tree has a valid assignment. I believe the generic DMA driver can now accept DMA channel reservations, but I don't think it works both ways. That is, if the audio driver loads first, I don't think there's a clean way to tell the DMA driver which channels have already been taken by the audio driver.
On 08/22/2013 07:16 AM, Stephen Warren wrote: > On 08/21/2013 05:00 PM, Scott Wood wrote: >> On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: >>> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: >>>> + - reg : <registers mapping for channel> >>>> + - interrupts : <interrupt mapping for DMA channel IRQ> >>> s/interrupts/specifier/ >> Do you mean s/interrupt mapping/interrupt specifier/? >> >> And probably s/registers mapping/register specifier/ as well. > Yup. > OK, I will update these descriptions.
On 08/23/2013 11:17 AM, Hongbo Zhang wrote: > On 08/22/2013 07:16 AM, Stephen Warren wrote: >> On 08/21/2013 05:00 PM, Scott Wood wrote: >>> On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote: >>>> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote: >>>>> + - reg : <registers mapping for channel> >>>>> + - interrupts : <interrupt mapping for DMA channel >>>>> IRQ> >>>> s/interrupts/specifier/ >>> Do you mean s/interrupt mapping/interrupt specifier/? >>> >>> And probably s/registers mapping/register specifier/ as well. >> Yup. >> > OK, I will update these descriptions. > Since Scott has clarified all the doubts, and no further comment till now, so my next iteration will include this s/mapping/specifier only. I will sent it out this Tuesday, if there is still any comment/doubt, please let me know.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 6e9384b..2e66c3d 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -126,6 +126,72 @@ Example: }; }; +** Freescale Elo3 DMA Controller + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx + series chips, such as t1040, t4240, b4860. + +Required properties: + +- compatible : must include "fsl,elo3-dma" +- reg : <registers mapping for DMA general status reg> +- ranges : describes the mapping between the address space of the + DMA channels and the address space of the DMA controller + +- DMA channel nodes: + - compatible : must include "fsl,eloplus-dma-channel" + - reg : <registers mapping for channel> + - interrupts : <interrupt mapping for DMA channel IRQ> + - interrupt-parent : optional, if needed for interrupt mapping + +Example: +dma@100300 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,elo3-dma"; + reg = <0x100300 0x4 0x100600 0x4>; + ranges = <0x0 0x100100 0x500>; + dma-channel@0 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x0 0x80>; + interrupts = <28 2 0 0>; + }; + dma-channel@80 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x80 0x80>; + interrupts = <29 2 0 0>; + }; + dma-channel@100 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x100 0x80>; + interrupts = <30 2 0 0>; + }; + dma-channel@180 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x180 0x80>; + interrupts = <31 2 0 0>; + }; + dma-channel@300 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x300 0x80>; + interrupts = <76 2 0 0>; + }; + dma-channel@380 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x380 0x80>; + interrupts = <77 2 0 0>; + }; + dma-channel@400 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x400 0x80>; + interrupts = <78 2 0 0>; + }; + dma-channel@480 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x480 0x80>; + interrupts = <79 2 0 0>; + }; +}; + Note on DMA channel compatible properties: The compatible property must say "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA driver (fsldma). Any DMA channel used by fsldma cannot be used by another diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi index 7399154..ea53ea1 100644 --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi @@ -223,13 +223,13 @@ reg = <0xe2000 0x1000>; }; -/include/ "qoriq-dma-0.dtsi" +/include/ "elo3-dma-0.dtsi" dma@100300 { fsl,iommu-parent = <&pamu0>; fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */ }; -/include/ "qoriq-dma-1.dtsi" +/include/ "elo3-dma-1.dtsi" dma@101300 { fsl,iommu-parent = <&pamu0>; fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */ diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi new file mode 100644 index 0000000..69a3277 --- /dev/null +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi @@ -0,0 +1,81 @@ +/* + * QorIQ DMA device tree stub [ controller @ offset 0x100000 ] + * + * Copyright 2013 Freescale Semiconductor Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of Freescale Semiconductor nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * GNU General Public License ("GPL") as published by the Free Software + * Foundation, either version 2 of that License or (at your option) any + * later version. + * + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +dma0: dma@100300 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,elo3-dma"; + reg = <0x100300 0x4 0x100600 0x4>; + ranges = <0x0 0x100100 0x500>; + dma-channel@0 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x0 0x80>; + interrupts = <28 2 0 0>; + }; + dma-channel@80 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x80 0x80>; + interrupts = <29 2 0 0>; + }; + dma-channel@100 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x100 0x80>; + interrupts = <30 2 0 0>; + }; + dma-channel@180 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x180 0x80>; + interrupts = <31 2 0 0>; + }; + dma-channel@300 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x300 0x80>; + interrupts = <76 2 0 0>; + }; + dma-channel@380 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x380 0x80>; + interrupts = <77 2 0 0>; + }; + dma-channel@400 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x400 0x80>; + interrupts = <78 2 0 0>; + }; + dma-channel@480 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x480 0x80>; + interrupts = <79 2 0 0>; + }; +}; diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi new file mode 100644 index 0000000..d410948 --- /dev/null +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi @@ -0,0 +1,81 @@ +/* + * QorIQ DMA device tree stub [ controller @ offset 0x101000 ] + * + * Copyright 2013 Freescale Semiconductor Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of Freescale Semiconductor nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * GNU General Public License ("GPL") as published by the Free Software + * Foundation, either version 2 of that License or (at your option) any + * later version. + * + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +dma1: dma@101300 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,elo3-dma"; + reg = <0x101300 0x4 0x101600 0x4>; + ranges = <0x0 0x101100 0x500>; + dma-channel@0 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x0 0x80>; + interrupts = <32 2 0 0>; + }; + dma-channel@80 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x80 0x80>; + interrupts = <33 2 0 0>; + }; + dma-channel@100 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x100 0x80>; + interrupts = <34 2 0 0>; + }; + dma-channel@180 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x180 0x80>; + interrupts = <35 2 0 0>; + }; + dma-channel@300 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x300 0x80>; + interrupts = <80 2 0 0>; + }; + dma-channel@380 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x380 0x80>; + interrupts = <81 2 0 0>; + }; + dma-channel@400 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x400 0x80>; + interrupts = <82 2 0 0>; + }; + dma-channel@480 { + compatible = "fsl,eloplus-dma-channel"; + reg = <0x480 0x80>; + interrupts = <83 2 0 0>; + }; +}; diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi index bd611a9..ec95c60 100644 --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi @@ -387,8 +387,8 @@ reg = <0xea000 0x4000>; }; -/include/ "qoriq-dma-0.dtsi" -/include/ "qoriq-dma-1.dtsi" +/include/ "elo3-dma-0.dtsi" +/include/ "elo3-dma-1.dtsi" /include/ "qoriq-espi-0.dtsi" spi@110000 {