diff mbox

[5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5

Message ID 1362763654-9660-6-git-send-email-jon-hunter@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Hunter, Jon March 8, 2013, 5:27 p.m. UTC
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(+)

Comments

Javier Martinez Canillas March 8, 2013, 8:25 p.m. UTC | #1
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
Hunter, Jon March 8, 2013, 9:41 p.m. UTC | #2
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
Javier Martinez Canillas March 9, 2013, 1:25 a.m. UTC | #3
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
Ezequiel Garcia March 9, 2013, 12:42 p.m. UTC | #4
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,
Hunter, Jon March 11, 2013, 5:56 p.m. UTC | #5
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
Benoit Cousson March 14, 2013, 3:45 p.m. UTC | #6
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
Hunter, Jon March 14, 2013, 3:50 p.m. UTC | #7
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
Ezequiel Garcia March 14, 2013, 3:57 p.m. UTC | #8
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.
Benoit Cousson March 14, 2013, 3:58 p.m. UTC | #9
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
Hunter, Jon March 14, 2013, 4 p.m. UTC | #10
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
Benoit Cousson March 14, 2013, 4:03 p.m. UTC | #11
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
diff mbox

Patch

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>;