| Message ID | 1362763654-9660-6-git-send-email-jon-hunter@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter <jon-hunter@ti.com> wrote: > Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices. > > Signed-off-by: Jon Hunter <jon-hunter@ti.com> > --- > arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++ > arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++ > arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++ > arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++ > 4 files changed, 44 insertions(+) > > diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi > index af65609..d4ce6c2 100644 > --- a/arch/arm/boot/dts/omap2420.dtsi > +++ b/arch/arm/boot/dts/omap2420.dtsi > @@ -29,6 +29,17 @@ > pinctrl-single,function-mask = <0x3f>; > }; > > + gpmc: gpmc@6800a000 { > + compatible = "ti,omap2420-gpmc"; > + reg = <0x6800a000 0x1000>; > + #address-cells = <2>; > + #size-cells = <1>; > + interrupts = <20>; > + gpmc,num-cs = <8>; > + gpmc,num-waitpins = <4>; > + ti,hwmods = "gpmc"; > + }; > + > mcbsp1: mcbsp@48074000 { > compatible = "ti,omap2420-mcbsp"; > reg = <0x48074000 0xff>; > diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi > index c392445..832f184 100644 > --- a/arch/arm/boot/dts/omap2430.dtsi > +++ b/arch/arm/boot/dts/omap2430.dtsi > @@ -29,6 +29,17 @@ > pinctrl-single,function-mask = <0x3f>; > }; > > + gpmc: gpmc@6e000000 { > + compatible = "ti,omap2430-gpmc"; > + reg = <0x6e000000 0x1000>; > + #address-cells = <2>; > + #size-cells = <1>; > + interrupts = <20>; > + gpmc,num-cs = <8>; > + gpmc,num-waitpins = <4>; > + ti,hwmods = "gpmc"; > + }; > + > mcbsp1: mcbsp@48074000 { > compatible = "ti,omap2430-mcbsp"; > reg = <0x48074000 0xff>; > diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi > index 827f6f3..726ef11 100644 > --- a/arch/arm/boot/dts/omap4.dtsi > +++ b/arch/arm/boot/dts/omap4.dtsi > @@ -196,6 +196,17 @@ > #interrupt-cells = <1>; > }; > > + gpmc: gpmc@50000000 { > + compatible = "ti,omap4430-gpmc"; > + reg = <0x50000000 0x1000>; Hi Jon, By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x Technical Reference Manuals I see that the GPMC register address space is only 720 bytes length. From base address + 0x0 to base address + 0x02d0. So shouldn't the regs property be <0x50000000 0x2d0> instead? Of course are only a few kilobytes but still I wonder if it makes sense to map them when they are not going to be used. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote: > On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter <jon-hunter@ti.com> wrote: >> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices. >> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com> >> --- >> arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++ >> arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++ >> arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++ >> arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++ >> 4 files changed, 44 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi >> index af65609..d4ce6c2 100644 >> --- a/arch/arm/boot/dts/omap2420.dtsi >> +++ b/arch/arm/boot/dts/omap2420.dtsi >> @@ -29,6 +29,17 @@ >> pinctrl-single,function-mask = <0x3f>; >> }; >> >> + gpmc: gpmc@6800a000 { >> + compatible = "ti,omap2420-gpmc"; >> + reg = <0x6800a000 0x1000>; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + interrupts = <20>; >> + gpmc,num-cs = <8>; >> + gpmc,num-waitpins = <4>; >> + ti,hwmods = "gpmc"; >> + }; >> + >> mcbsp1: mcbsp@48074000 { >> compatible = "ti,omap2420-mcbsp"; >> reg = <0x48074000 0xff>; >> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi >> index c392445..832f184 100644 >> --- a/arch/arm/boot/dts/omap2430.dtsi >> +++ b/arch/arm/boot/dts/omap2430.dtsi >> @@ -29,6 +29,17 @@ >> pinctrl-single,function-mask = <0x3f>; >> }; >> >> + gpmc: gpmc@6e000000 { >> + compatible = "ti,omap2430-gpmc"; >> + reg = <0x6e000000 0x1000>; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + interrupts = <20>; >> + gpmc,num-cs = <8>; >> + gpmc,num-waitpins = <4>; >> + ti,hwmods = "gpmc"; >> + }; >> + >> mcbsp1: mcbsp@48074000 { >> compatible = "ti,omap2430-mcbsp"; >> reg = <0x48074000 0xff>; >> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi >> index 827f6f3..726ef11 100644 >> --- a/arch/arm/boot/dts/omap4.dtsi >> +++ b/arch/arm/boot/dts/omap4.dtsi >> @@ -196,6 +196,17 @@ >> #interrupt-cells = <1>; >> }; >> >> + gpmc: gpmc@50000000 { >> + compatible = "ti,omap4430-gpmc"; >> + reg = <0x50000000 0x1000>; > > Hi Jon, > > By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x > Technical Reference Manuals I see that the GPMC register address space > is only 720 bytes length. From base address + 0x0 to base address + > 0x02d0. > > So shouldn't the regs property be <0x50000000 0x2d0> instead? > > Of course are only a few kilobytes but still I wonder if it makes > sense to map them when they are not going to be used. Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: > > On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote: >> On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices. >>> >>> Signed-off-by: Jon Hunter <jon-hunter@ti.com> >>> --- >>> arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++ >>> arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++ >>> arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++ >>> arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++ >>> 4 files changed, 44 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi >>> index af65609..d4ce6c2 100644 >>> --- a/arch/arm/boot/dts/omap2420.dtsi >>> +++ b/arch/arm/boot/dts/omap2420.dtsi >>> @@ -29,6 +29,17 @@ >>> pinctrl-single,function-mask = <0x3f>; >>> }; >>> >>> + gpmc: gpmc@6800a000 { >>> + compatible = "ti,omap2420-gpmc"; >>> + reg = <0x6800a000 0x1000>; >>> + #address-cells = <2>; >>> + #size-cells = <1>; >>> + interrupts = <20>; >>> + gpmc,num-cs = <8>; >>> + gpmc,num-waitpins = <4>; >>> + ti,hwmods = "gpmc"; >>> + }; >>> + >>> mcbsp1: mcbsp@48074000 { >>> compatible = "ti,omap2420-mcbsp"; >>> reg = <0x48074000 0xff>; >>> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi >>> index c392445..832f184 100644 >>> --- a/arch/arm/boot/dts/omap2430.dtsi >>> +++ b/arch/arm/boot/dts/omap2430.dtsi >>> @@ -29,6 +29,17 @@ >>> pinctrl-single,function-mask = <0x3f>; >>> }; >>> >>> + gpmc: gpmc@6e000000 { >>> + compatible = "ti,omap2430-gpmc"; >>> + reg = <0x6e000000 0x1000>; >>> + #address-cells = <2>; >>> + #size-cells = <1>; >>> + interrupts = <20>; >>> + gpmc,num-cs = <8>; >>> + gpmc,num-waitpins = <4>; >>> + ti,hwmods = "gpmc"; >>> + }; >>> + >>> mcbsp1: mcbsp@48074000 { >>> compatible = "ti,omap2430-mcbsp"; >>> reg = <0x48074000 0xff>; >>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi >>> index 827f6f3..726ef11 100644 >>> --- a/arch/arm/boot/dts/omap4.dtsi >>> +++ b/arch/arm/boot/dts/omap4.dtsi >>> @@ -196,6 +196,17 @@ >>> #interrupt-cells = <1>; >>> }; >>> >>> + gpmc: gpmc@50000000 { >>> + compatible = "ti,omap4430-gpmc"; >>> + reg = <0x50000000 0x1000>; >> >> Hi Jon, >> >> By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x >> Technical Reference Manuals I see that the GPMC register address space >> is only 720 bytes length. From base address + 0x0 to base address + >> 0x02d0. >> >> So shouldn't the regs property be <0x50000000 0x2d0> instead? >> >> Of course are only a few kilobytes but still I wonder if it makes >> sense to map them when they are not going to be used. > > Yes you are correct. In general, I have been trying to stay some-what > consistent with what hwmod was doing as this was being auto-generated by > some hardware design specs and I believe they wanted to eventually get > to the point where DT files would be auto-generated too for OMAP. > Furthermore my understanding is that the smallest page that can be > mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or > 0x1000 it will map a 4kB page (I could be wrong here). > > I don't have any strong feelings here but will do what the consensus > prefers. > Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> > Cheers > Jon Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas <javier@dowhile0.org> wrote: > On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >> >> Yes you are correct. In general, I have been trying to stay some-what >> consistent with what hwmod was doing as this was being auto-generated by >> some hardware design specs and I believe they wanted to eventually get >> to the point where DT files would be auto-generated too for OMAP. >> Furthermore my understanding is that the smallest page that can be >> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >> 0x1000 it will map a 4kB page (I could be wrong here). >> >> I don't have any strong feelings here but will do what the consensus >> prefers. >> > > Yes, you are right here. > > I forget that ioremap() does a page-aligned mapping and since the > minimum page size for ARM is 4KB as you said, there is no difference > between using 0x2d0 and 0x1000. Sorry for the noise. > Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a "minimal" address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. Somehow, I feel this is almost a nitpick, so don't take this too seriously. Regards,
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: > On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas > <javier@dowhile0.org> wrote: >> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>> >>> Yes you are correct. In general, I have been trying to stay some-what >>> consistent with what hwmod was doing as this was being auto-generated by >>> some hardware design specs and I believe they wanted to eventually get >>> to the point where DT files would be auto-generated too for OMAP. >>> Furthermore my understanding is that the smallest page that can be >>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>> 0x1000 it will map a 4kB page (I could be wrong here). >>> >>> I don't have any strong feelings here but will do what the consensus >>> prefers. >>> >> >> Yes, you are right here. >> >> I forget that ioremap() does a page-aligned mapping and since the >> minimum page size for ARM is 4KB as you said, there is no difference >> between using 0x2d0 and 0x1000. Sorry for the noise. >> > > Certainly, I don't have strong feelings about this. > FWIW, mvebu maintainers imposes a "minimal" address space request > policy. > > On the other side, it seems to me we shouldn't look at internal kernel > implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. > Somehow, I feel this is almost a nitpick, so don't take this too seriously. No problem. Probably good to align on something sooner rather than later. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/11/2013 06:56 PM, Jon Hunter wrote: > > On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: >> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas >> <javier@dowhile0.org> wrote: >>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>>> >>>> Yes you are correct. In general, I have been trying to stay some-what >>>> consistent with what hwmod was doing as this was being auto-generated by >>>> some hardware design specs and I believe they wanted to eventually get >>>> to the point where DT files would be auto-generated too for OMAP. >>>> Furthermore my understanding is that the smallest page that can be >>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>>> 0x1000 it will map a 4kB page (I could be wrong here). >>>> >>>> I don't have any strong feelings here but will do what the consensus >>>> prefers. >>>> >>> >>> Yes, you are right here. >>> >>> I forget that ioremap() does a page-aligned mapping and since the >>> minimum page size for ARM is 4KB as you said, there is no difference >>> between using 0x2d0 and 0x1000. Sorry for the noise. >>> >> >> Certainly, I don't have strong feelings about this. >> FWIW, mvebu maintainers imposes a "minimal" address space request >> policy. >> >> On the other side, it seems to me we shouldn't look at internal kernel >> implementation (i.e. ioremap page-alignment) to make this decision. > > I agree with that. I am not sure if Tony/Benoit have any comments on > what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/14/2013 10:45 AM, Benoit Cousson wrote: > On 03/11/2013 06:56 PM, Jon Hunter wrote: >> >> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: >>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas >>> <javier@dowhile0.org> wrote: >>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>>>> >>>>> Yes you are correct. In general, I have been trying to stay some-what >>>>> consistent with what hwmod was doing as this was being auto-generated by >>>>> some hardware design specs and I believe they wanted to eventually get >>>>> to the point where DT files would be auto-generated too for OMAP. >>>>> Furthermore my understanding is that the smallest page that can be >>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>>>> 0x1000 it will map a 4kB page (I could be wrong here). >>>>> >>>>> I don't have any strong feelings here but will do what the consensus >>>>> prefers. >>>>> >>>> >>>> Yes, you are right here. >>>> >>>> I forget that ioremap() does a page-aligned mapping and since the >>>> minimum page size for ARM is 4KB as you said, there is no difference >>>> between using 0x2d0 and 0x1000. Sorry for the noise. >>>> >>> >>> Certainly, I don't have strong feelings about this. >>> FWIW, mvebu maintainers imposes a "minimal" address space request >>> policy. >>> >>> On the other side, it seems to me we shouldn't look at internal kernel >>> implementation (i.e. ioremap page-alignment) to make this decision. >> >> I agree with that. I am not sure if Tony/Benoit have any comments on >> what they would like to do here to be consistent for the omap bindings. > > Yes, I full agree with that as well. The size should be purely HW > related. So we should not take any assumption about the page size / > alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter <jon-hunter@ti.com> wrote: >> Yes, I full agree with that as well. The size should be purely HW >> related. So we should not take any assumption about the page size / >> alignment. > > Ok, what is best to use? The size from hwmod structures or the size from > the documentation? > My personal vote is: according to hardware documentation is the right thing, and it's what we're doing in mvebu.
On 03/14/2013 04:50 PM, Jon Hunter wrote: > > On 03/14/2013 10:45 AM, Benoit Cousson wrote: >> On 03/11/2013 06:56 PM, Jon Hunter wrote: >>> >>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: >>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas >>>> <javier@dowhile0.org> wrote: >>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>>>>> >>>>>> Yes you are correct. In general, I have been trying to stay some-what >>>>>> consistent with what hwmod was doing as this was being auto-generated by >>>>>> some hardware design specs and I believe they wanted to eventually get >>>>>> to the point where DT files would be auto-generated too for OMAP. >>>>>> Furthermore my understanding is that the smallest page that can be >>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>>>>> 0x1000 it will map a 4kB page (I could be wrong here). >>>>>> >>>>>> I don't have any strong feelings here but will do what the consensus >>>>>> prefers. >>>>>> >>>>> >>>>> Yes, you are right here. >>>>> >>>>> I forget that ioremap() does a page-aligned mapping and since the >>>>> minimum page size for ARM is 4KB as you said, there is no difference >>>>> between using 0x2d0 and 0x1000. Sorry for the noise. >>>>> >>>> >>>> Certainly, I don't have strong feelings about this. >>>> FWIW, mvebu maintainers imposes a "minimal" address space request >>>> policy. >>>> >>>> On the other side, it seems to me we shouldn't look at internal kernel >>>> implementation (i.e. ioremap page-alignment) to make this decision. >>> >>> I agree with that. I am not sure if Tony/Benoit have any comments on >>> what they would like to do here to be consistent for the omap bindings. >> >> Yes, I full agree with that as well. The size should be purely HW >> related. So we should not take any assumption about the page size / >> alignment. > > Ok, what is best to use? The size from hwmod structures or the size from > the documentation? Well, in theory both are supposed to be identical :-) I'm just applying a rounding to the closet power of two, that's why it cannot be 0x2d0. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/14/2013 10:58 AM, Benoit Cousson wrote: > On 03/14/2013 04:50 PM, Jon Hunter wrote: >> >> On 03/14/2013 10:45 AM, Benoit Cousson wrote: >>> On 03/11/2013 06:56 PM, Jon Hunter wrote: >>>> >>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: >>>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas >>>>> <javier@dowhile0.org> wrote: >>>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>>>>>> >>>>>>> Yes you are correct. In general, I have been trying to stay some-what >>>>>>> consistent with what hwmod was doing as this was being auto-generated by >>>>>>> some hardware design specs and I believe they wanted to eventually get >>>>>>> to the point where DT files would be auto-generated too for OMAP. >>>>>>> Furthermore my understanding is that the smallest page that can be >>>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>>>>>> 0x1000 it will map a 4kB page (I could be wrong here). >>>>>>> >>>>>>> I don't have any strong feelings here but will do what the consensus >>>>>>> prefers. >>>>>>> >>>>>> >>>>>> Yes, you are right here. >>>>>> >>>>>> I forget that ioremap() does a page-aligned mapping and since the >>>>>> minimum page size for ARM is 4KB as you said, there is no difference >>>>>> between using 0x2d0 and 0x1000. Sorry for the noise. >>>>>> >>>>> >>>>> Certainly, I don't have strong feelings about this. >>>>> FWIW, mvebu maintainers imposes a "minimal" address space request >>>>> policy. >>>>> >>>>> On the other side, it seems to me we shouldn't look at internal kernel >>>>> implementation (i.e. ioremap page-alignment) to make this decision. >>>> >>>> I agree with that. I am not sure if Tony/Benoit have any comments on >>>> what they would like to do here to be consistent for the omap bindings. >>> >>> Yes, I full agree with that as well. The size should be purely HW >>> related. So we should not take any assumption about the page size / >>> alignment. >> >> Ok, what is best to use? The size from hwmod structures or the size from >> the documentation? > > Well, in theory both are supposed to be identical :-) > I'm just applying a rounding to the closet power of two, that's why it > cannot be 0x2d0. Ok I understand. However, still not clear what you want me to use :-( Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/14/2013 05:00 PM, Jon Hunter wrote: > > > On 03/14/2013 10:58 AM, Benoit Cousson wrote: >> On 03/14/2013 04:50 PM, Jon Hunter wrote: >>> >>> On 03/14/2013 10:45 AM, Benoit Cousson wrote: >>>> On 03/11/2013 06:56 PM, Jon Hunter wrote: >>>>> >>>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: >>>>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas >>>>>> <javier@dowhile0.org> wrote: >>>>>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter <jon-hunter@ti.com> wrote: >>>>>>>> >>>>>>>> Yes you are correct. In general, I have been trying to stay some-what >>>>>>>> consistent with what hwmod was doing as this was being auto-generated by >>>>>>>> some hardware design specs and I believe they wanted to eventually get >>>>>>>> to the point where DT files would be auto-generated too for OMAP. >>>>>>>> Furthermore my understanding is that the smallest page that can be >>>>>>>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>>>>>>> 0x1000 it will map a 4kB page (I could be wrong here). >>>>>>>> >>>>>>>> I don't have any strong feelings here but will do what the consensus >>>>>>>> prefers. >>>>>>>> >>>>>>> >>>>>>> Yes, you are right here. >>>>>>> >>>>>>> I forget that ioremap() does a page-aligned mapping and since the >>>>>>> minimum page size for ARM is 4KB as you said, there is no difference >>>>>>> between using 0x2d0 and 0x1000. Sorry for the noise. >>>>>>> >>>>>> >>>>>> Certainly, I don't have strong feelings about this. >>>>>> FWIW, mvebu maintainers imposes a "minimal" address space request >>>>>> policy. >>>>>> >>>>>> On the other side, it seems to me we shouldn't look at internal kernel >>>>>> implementation (i.e. ioremap page-alignment) to make this decision. >>>>> >>>>> I agree with that. I am not sure if Tony/Benoit have any comments on >>>>> what they would like to do here to be consistent for the omap bindings. >>>> >>>> Yes, I full agree with that as well. The size should be purely HW >>>> related. So we should not take any assumption about the page size / >>>> alignment. >>> >>> Ok, what is best to use? The size from hwmod structures or the size from >>> the documentation? >> >> Well, in theory both are supposed to be identical :-) >> I'm just applying a rounding to the closet power of two, that's why it >> cannot be 0x2d0. > > Ok I understand. However, still not clear what you want me to use :-( That's on purpose :-) Take 0x2d0, we could always remove the rounding in the generation part to stick to the HW documentation. Regards Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi index af65609..d4ce6c2 100644 --- a/arch/arm/boot/dts/omap2420.dtsi +++ b/arch/arm/boot/dts/omap2420.dtsi @@ -29,6 +29,17 @@ pinctrl-single,function-mask = <0x3f>; }; + gpmc: gpmc@6800a000 { + compatible = "ti,omap2420-gpmc"; + reg = <0x6800a000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + interrupts = <20>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + ti,hwmods = "gpmc"; + }; + mcbsp1: mcbsp@48074000 { compatible = "ti,omap2420-mcbsp"; reg = <0x48074000 0xff>; diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index c392445..832f184 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -29,6 +29,17 @@ pinctrl-single,function-mask = <0x3f>; }; + gpmc: gpmc@6e000000 { + compatible = "ti,omap2430-gpmc"; + reg = <0x6e000000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + interrupts = <20>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + ti,hwmods = "gpmc"; + }; + mcbsp1: mcbsp@48074000 { compatible = "ti,omap2430-mcbsp"; reg = <0x48074000 0xff>; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 827f6f3..726ef11 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -196,6 +196,17 @@ #interrupt-cells = <1>; }; + gpmc: gpmc@50000000 { + compatible = "ti,omap4430-gpmc"; + reg = <0x50000000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + interrupts = <0 20 0x4>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + ti,hwmods = "gpmc"; + }; + uart1: serial@4806a000 { compatible = "ti,omap4-uart"; reg = <0x4806a000 0x100>; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 06d21d6..34f41ad 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -208,6 +208,17 @@ #interrupt-cells = <1>; }; + gpmc: gpmc@50000000 { + compatible = "ti,omap4430-gpmc"; + reg = <0x50000000 0x1000>; + #address-cells = <2>; + #size-cells = <1>; + interrupts = <0 20 0x4>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + ti,hwmods = "gpmc"; + }; + i2c1: i2c@48070000 { compatible = "ti,omap4-i2c"; reg = <0x48070000 0x100>;
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices. Signed-off-by: Jon Hunter <jon-hunter@ti.com> --- arch/arm/boot/dts/omap2420.dtsi | 11 +++++++++++ arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++ arch/arm/boot/dts/omap4.dtsi | 11 +++++++++++ arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++ 4 files changed, 44 insertions(+)