diff mbox

[1/2] ARM: dts: OMAP3: Add GPMC controller

Message ID 1359395648-2137-2-git-send-email-florian.vaussard@epfl.ch (mailing list archive)
State New, archived
Headers show

Commit Message

Florian Vaussard Jan. 28, 2013, 5:54 p.m. UTC
Add device-tree support for the GPMC controller on the OMAP3.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

Comments

Javier Martinez Canillas Feb. 4, 2013, 9:27 a.m. UTC | #1
Hi Florian,

On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 6c63118..2ddae38 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -403,5 +403,16 @@
>                         ti,timer-alwon;
>                         ti,timer-secure;
>                 };
> +
> +               gpmc: gpmc@6e000000 {
> +                       compatible = "ti,omap3430-gpmc";
> +                       ti,hwmods = "gpmc";
> +                       reg = <0x6e000000 0x1000000>;
> +                       interrupts = <20>;
> +                       gpmc,num-cs = <8>;
> +                       gpmc,num-waitpins = <4>;
> +                       #address-cells = <2>;
> +                       #size-cells = <1>;
> +               };
>         };
>  };

I had the same patch on a tree I was working on to add DT support for
gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches
to hit mainline before sending the RFC. So please feel free to add:

Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Best regards,
Javier
Florian Vaussard Feb. 4, 2013, 10:36 a.m. UTC | #2
Hi Javier,

On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote:
> Hi Florian,
>
> On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
> <florian.vaussard@epfl.ch> wrote:
>> Add device-tree support for the GPMC controller on the OMAP3.
>>
>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>> ---
>>   arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>>   1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 6c63118..2ddae38 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -403,5 +403,16 @@
>>                          ti,timer-alwon;
>>                          ti,timer-secure;
>>                  };
>> +
>> +               gpmc: gpmc@6e000000 {
>> +                       compatible = "ti,omap3430-gpmc";
>> +                       ti,hwmods = "gpmc";
>> +                       reg = <0x6e000000 0x1000000>;
>> +                       interrupts = <20>;
>> +                       gpmc,num-cs = <8>;
>> +                       gpmc,num-waitpins = <4>;
>> +                       #address-cells = <2>;
>> +                       #size-cells = <1>;
>> +               };
>>          };
>>   };
>
> I had the same patch on a tree I was working on to add DT support for
> gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches
> to hit mainline before sending the RFC. So please feel free to add:
>
> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>

Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
do you have a public git for this, so I can test your work on my setup?

For the GPMC support, I will have to make a few more more as discussed with
Tony, and as I will be away for more than 2 weeks, feel free to go ahead
before me. This patchset was only at an RFC stage.

Regards,

Florian
Javier Martinez Canillas Feb. 4, 2013, 11:57 a.m. UTC | #3
On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Hi Javier,
>
>

Hi Florian,

> On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote:
>>
>> Hi Florian,
>>
>> On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
>> <florian.vaussard@epfl.ch> wrote:
>>>
>>> Add device-tree support for the GPMC controller on the OMAP3.
>>>
>>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>>> ---
>>>   arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>>>   1 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>>> index 6c63118..2ddae38 100644
>>> --- a/arch/arm/boot/dts/omap3.dtsi
>>> +++ b/arch/arm/boot/dts/omap3.dtsi
>>> @@ -403,5 +403,16 @@
>>>                          ti,timer-alwon;
>>>                          ti,timer-secure;
>>>                  };
>>> +
>>> +               gpmc: gpmc@6e000000 {
>>> +                       compatible = "ti,omap3430-gpmc";
>>> +                       ti,hwmods = "gpmc";
>>> +                       reg = <0x6e000000 0x1000000>;
>>> +                       interrupts = <20>;
>>> +                       gpmc,num-cs = <8>;
>>> +                       gpmc,num-waitpins = <4>;
>>> +                       #address-cells = <2>;
>>> +                       #size-cells = <1>;
>>> +               };
>>>          };
>>>   };
>>
>>
>> I had the same patch on a tree I was working on to add DT support for
>> gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches
>> to hit mainline before sending the RFC. So please feel free to add:
>>
>> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>
>
> Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
> do you have a public git for this, so I can test your work on my setup?
>

Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1]

That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc +
linux-omap-dt/for_3.9/dts

plus these patches:

Javier Martinez Canillas (4):
      ARM: OMAP: gpmc-smsc911x: add DT dev node init function
      ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
      ARM: dts: OMAP: Add an GPMC node for OMAP3
      ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

You can browse these patches here [2].

With these patches I have ethernet working on my IGEPv2 but this board
uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a
mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on
poll mode.

For some reasons I still couldn't figure out (I'm still learning about
Device Trees) adding:

       pinctrl = devm_pinctrl_get_select_default(&pdev->dev);

to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt)
didn't have a functional effect and I had to initialize the defined
pinctrl-single pins for the smsc911x in the omap3_pmx_core device node
instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc).

So I just removed the devm_pinctrl_get_select_default() call in
gpmc_smsc911x_init_dt() in for this RFC.

I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is
not a real platform driver (is just a wrapper/helper function) and
doesn't have a probe function.

Which brings me to the question if my approach of adding a binding for
gpmc-smsc911x is correct or if we should extend/use the binding that
already exist for smsc911x
(Documentation/devicetree/bindings/net/smsc911x.txt).

> For the GPMC support, I will have to make a few more more as discussed with
> Tony, and as I will be away for more than 2 weeks, feel free to go ahead
> before me. This patchset was only at an RFC stage.
>
> Regards,
>
> Florian
>

Yes, I saw on the list that Tony asked you too extend the GPMC DT
support. Flash support is on my TODO list too but I don't know if I'm
going to have time to work on this in the next few weeks.

Since you are thinking to change the binding, there is something I
want to discuss with you.

We have two different version for each IGEP board, one that uses NAND
memory and another that has OneNAND.

With board files this is easy because the flash memory type is
hardcoded (in hardware) using sysboot pins [3]. So we check the
sysboot value and call board_nand_init() or board_onenand_init()
accordingly and pass the same static struct mtd_partition
igep_flash_partitions[] in both cases.

But with DT this is a little bit trickier since you have to define
either a nand@0 or onenand@0 child node for the gpmc device node. So,
we will have to create lots of dts and dtsi to handle each combination
(IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc).

I wonder if we could just have a generic gpmc-flash binding and maybe
use a "gpmc, flash_type" property or something like that to decide if
gpmc_onenand_init() or gpmc_nand_init() has to be called.

Thanks a lot and best regards,
Javier

[1]: git://github.com/martinezjavier/linux.git
[2]: https://github.com/martinezjavier/linux/commits/gpmc-smsc911x-wip
[3]: http://omappedia.org/wiki/Bootloader_Project#SYSBOOT_Pins
Tony Lindgren Feb. 4, 2013, 5:32 p.m. UTC | #4
* Javier Martinez Canillas <javier@dowhile0.org> [130204 04:00]:
> On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
> > Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
> > do you have a public git for this, so I can test your work on my setup?
> >
> 
> Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1]
> 
> That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc +
> linux-omap-dt/for_3.9/dts
> 
> plus these patches:
> 
> Javier Martinez Canillas (4):
>       ARM: OMAP: gpmc-smsc911x: add DT dev node init function
>       ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
>       ARM: dts: OMAP: Add an GPMC node for OMAP3
>       ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
> 
> You can browse these patches here [2].
> 
> With these patches I have ethernet working on my IGEPv2 but this board
> uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a
> mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on
> poll mode.

Great, that's good news :)

> For some reasons I still couldn't figure out (I'm still learning about
> Device Trees) adding:
> 
>        pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> 
> to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt)
> didn't have a functional effect and I had to initialize the defined
> pinctrl-single pins for the smsc911x in the omap3_pmx_core device node
> instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc).

Maybe this is related to the initcall ordering..
 
> So I just removed the devm_pinctrl_get_select_default() call in
> gpmc_smsc911x_init_dt() in for this RFC.
> 
> I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is
> not a real platform driver (is just a wrapper/helper function) and
> doesn't have a probe function.

..that function just initializes the pdata for smsc911x driver, and
should not be a driver. You need to add devm_pinctrl_get_select_default()
to the probe of smsc911x or the GPMC probe.
 
> Which brings me to the question if my approach of adding a binding for
> gpmc-smsc911x is correct or if we should extend/use the binding that
> already exist for smsc911x
> (Documentation/devicetree/bindings/net/smsc911x.txt).

We should use the existing smsc911x binding, then have a separate GPMC
binding for the GPMC driver.

Regards,

Tony 
 
> [1]: git://github.com/martinezjavier/linux.git
> [2]: https://github.com/martinezjavier/linux/commits/gpmc-smsc911x-wip
> [3]: http://omappedia.org/wiki/Bootloader_Project#SYSBOOT_Pins
Javier Martinez Canillas Feb. 4, 2013, 6:15 p.m. UTC | #5
On Mon, Feb 4, 2013 at 6:32 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Javier Martinez Canillas <javier@dowhile0.org> [130204 04:00]:
>> On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
>> > Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
>> > do you have a public git for this, so I can test your work on my setup?
>> >
>>
>> Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1]
>>
>> That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc +
>> linux-omap-dt/for_3.9/dts
>>
>> plus these patches:
>>
>> Javier Martinez Canillas (4):
>>       ARM: OMAP: gpmc-smsc911x: add DT dev node init function
>>       ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
>>       ARM: dts: OMAP: Add an GPMC node for OMAP3
>>       ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
>>
>> You can browse these patches here [2].
>>
>> With these patches I have ethernet working on my IGEPv2 but this board
>> uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a
>> mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on
>> poll mode.
>
> Great, that's good news :)
>

it's a start at least :-)

>> For some reasons I still couldn't figure out (I'm still learning about
>> Device Trees) adding:
>>
>>        pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
>>
>> to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt)
>> didn't have a functional effect and I had to initialize the defined
>> pinctrl-single pins for the smsc911x in the omap3_pmx_core device node
>> instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc).
>
> Maybe this is related to the initcall ordering..
>

I don't think so since I added the gpmc@6e000000 device node as the
last child node for ocp in omap3.dtsi. So, is way after omap3_pmx_core
child node is defined.

Btw, there is a way to specify the initialization order or the
dependencies between device nodes (e.g: gpmc depends on
omap3_pmx_core) or is just because of the position inside the DT?

>> So I just removed the devm_pinctrl_get_select_default() call in
>> gpmc_smsc911x_init_dt() in for this RFC.
>>
>> I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is
>> not a real platform driver (is just a wrapper/helper function) and
>> doesn't have a probe function.
>
> ..that function just initializes the pdata for smsc911x driver, and
> should not be a driver. You need to add devm_pinctrl_get_select_default()
> to the probe of smsc911x or the GPMC probe.
>

Yes, that's what I meant. In that case I would have something like
this on my board dts:

&gpmc {
	pinctrl-names = "default";
	pinctrl-0 = <&smsc911x_pins>;
	gpmc_smsc911x@0 {
		gpmc,cs = <5>; /* IGEP2_SMSC911X_CS */
		gpmc,gpio_irq = <176>; /* IGEP2_SMSC911X_GPIO */
		gpmc,flags = <18>; /* SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS */
		vmmc-supply = <&vddvario>;
		vmmc_aux-supply = <&vdd33a>;
      };
};

Are you ok with tha approach?

Certainly is better than initializing in omap3_pmx_core node but still
is not consistent with other devices where the pinctrl pins are
defined inside the node of the device that requires them.

>> Which brings me to the question if my approach of adding a binding for
>> gpmc-smsc911x is correct or if we should extend/use the binding that
>> already exist for smsc911x
>> (Documentation/devicetree/bindings/net/smsc911x.txt).
>
> We should use the existing smsc911x binding, then have a separate GPMC
> binding for the GPMC driver.
>

You mean a binding for GPMC or a binding for gpmc-smsc911x?

I don't think that we can use the smsc911x binding directly since
gpmc_smsc911x_init() not only initializes the platform data but also
does some setup such as requesting a memory range for a specific chip
select (gpmc_cs_request), claiming a GPIO and configuring as input
(gpio_request_one), etc.

You can't just calculate the I/O space address for the GPMC cs your
peripheral is connected to and set it on the reg property of the
current smsc911x binding, right?. The same can be said for the nic
IRQ.

Or did I get wrong?

> Regards,
>
> Tony
>

Thanks a lot and best regards,
Javier
Florian Vaussard Feb. 5, 2013, 5:23 p.m. UTC | #6
Hi Javier,

On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote:

[...]

>
> Yes, I saw on the list that Tony asked you too extend the GPMC DT
> support. Flash support is on my TODO list too but I don't know if I'm
> going to have time to work on this in the next few weeks.
>
> Since you are thinking to change the binding, there is something I
> want to discuss with you.
>
> We have two different version for each IGEP board, one that uses NAND
> memory and another that has OneNAND.
>
> With board files this is easy because the flash memory type is
> hardcoded (in hardware) using sysboot pins [3]. So we check the
> sysboot value and call board_nand_init() or board_onenand_init()
> accordingly and pass the same static struct mtd_partition
> igep_flash_partitions[] in both cases.
>
> But with DT this is a little bit trickier since you have to define
> either a nand@0 or onenand@0 child node for the gpmc device node. So,
> we will have to create lots of dts and dtsi to handle each combination
> (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc).
>
> I wonder if we could just have a generic gpmc-flash binding and maybe
> use a "gpmc, flash_type" property or something like that to decide if
> gpmc_onenand_init() or gpmc_nand_init() has to be called.
>

This boils down to the problem where you have an "if" statement in
your board file, and I think no general solution exists.

In your suggestion, having a property will force you anyway to write
distinct DT files to account for the two versions, so it won't really
help if I understand correctly. We would need conditional
section inside device trees, at least to test for simple parameters.
Or a way to generate several DT blobs based on a single DT source file.

Another hackish solution would be to write a meta component, whose
probe section would do your test. But this is just a stripped down version
of the board file, far from being generic...

I will think on it during my holidays :)

Regards,

Florian
Javier Martinez Canillas Feb. 5, 2013, 7:40 p.m. UTC | #7
On Tue, Feb 5, 2013 at 6:23 PM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Hi Javier,
>

Hi Florian,

> On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote:
>
> [...]
>
>
>>
>> Yes, I saw on the list that Tony asked you too extend the GPMC DT
>> support. Flash support is on my TODO list too but I don't know if I'm
>> going to have time to work on this in the next few weeks.
>>
>> Since you are thinking to change the binding, there is something I
>> want to discuss with you.
>>
>> We have two different version for each IGEP board, one that uses NAND
>> memory and another that has OneNAND.
>>
>> With board files this is easy because the flash memory type is
>> hardcoded (in hardware) using sysboot pins [3]. So we check the
>> sysboot value and call board_nand_init() or board_onenand_init()
>> accordingly and pass the same static struct mtd_partition
>> igep_flash_partitions[] in both cases.
>>
>> But with DT this is a little bit trickier since you have to define
>> either a nand@0 or onenand@0 child node for the gpmc device node. So,
>> we will have to create lots of dts and dtsi to handle each combination
>> (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc).
>>
>> I wonder if we could just have a generic gpmc-flash binding and maybe
>> use a "gpmc, flash_type" property or something like that to decide if
>> gpmc_onenand_init() or gpmc_nand_init() has to be called.
>>
>
> This boils down to the problem where you have an "if" statement in
> your board file, and I think no general solution exists.
>

Yes, this is a general issue since DT uses a declarative paradigm.

I was just pointing out that I found that particular issue with the flash
memory type on IGEP boards.

> In your suggestion, having a property will force you anyway to write
> distinct DT files to account for the two versions, so it won't really
> help if I understand correctly. We would need conditional
> section inside device trees, at least to test for simple parameters.
> Or a way to generate several DT blobs based on a single DT source file.
>

Well you will still need a different dtb for each <board,flash type> combination
but it could make your device trees smaller and simpler since you can define
your GPMC flash child node on a dtsi where you set all the partition and sizes
and export that device node to your boards dts that only set the
"gpmc, flash_type"
property to nand or onenand (assuming both your NAND and OneNAND version
have the same partition layout and sizes).

Otherwise you would have to define the complete onenand or nand child node
on your board dts having duplicated definition for your flash partition layouts.

> Another hackish solution would be to write a meta component, whose
> probe section would do your test. But this is just a stripped down version
> of the board file, far from being generic...
>

Yes, and that doesn't fit on the DT model too well. I still don't know what's
the best way to do it.

> I will think on it during my holidays :)
>

great, I hope you enjoy your holidays :-)

> Regards,
>
> Florian
>

Thanks a lot and best regards,
Javier
Anil Kumar Feb. 16, 2013, 1:09 p.m. UTC | #8
Hi Florian,

On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 6c63118..2ddae38 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -403,5 +403,16 @@
>                         ti,timer-alwon;
>                         ti,timer-secure;
>                 };
> +
> +               gpmc: gpmc@6e000000 {
> +                       compatible = "ti,omap3430-gpmc";
> +                       ti,hwmods = "gpmc";
> +                       reg = <0x6e000000 0x1000000>;
> +                       interrupts = <20>;
> +                       gpmc,num-cs = <8>;
> +                       gpmc,num-waitpins = <4>;
> +                       #address-cells = <2>;
> +                       #size-cells = <1>;
> +               };
>         };
>  };

Tested on devkit8000 (omap3 based board)

Please take my Tested-by: Anil Kumar <anilk4.v@gmail.com>

Thanks,
Anil
Javier Martinez Canillas Feb. 16, 2013, 4:44 p.m. UTC | #9
On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar <anilkumar880@gmail.com> wrote:
> Hi Florian,
>
> On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
> <florian.vaussard@epfl.ch> wrote:
>> Add device-tree support for the GPMC controller on the OMAP3.
>>
>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>> ---
>>  arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>>  1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 6c63118..2ddae38 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -403,5 +403,16 @@
>>                         ti,timer-alwon;
>>                         ti,timer-secure;
>>                 };
>> +
>> +               gpmc: gpmc@6e000000 {
>> +                       compatible = "ti,omap3430-gpmc";
>> +                       ti,hwmods = "gpmc";
>> +                       reg = <0x6e000000 0x1000000>;
>> +                       interrupts = <20>;
>> +                       gpmc,num-cs = <8>;
>> +                       gpmc,num-waitpins = <4>;
>> +                       #address-cells = <2>;
>> +                       #size-cells = <1>;
>> +               };
>>         };
>>  };
>
> Tested on devkit8000 (omap3 based board)
>
> Please take my Tested-by: Anil Kumar <anilk4.v@gmail.com>
>
> Thanks,
> Anil
>

Hello Tony and Benoit,

Could this patch be merged to one of your branches?

It has already my Reviewed-by and now Anil's Tested-by.

Now that Daniel's OMAP GPMC binding were merged, there seems to be
many people working on adding support on their boards DT for
peripherals connected through the GPMC (NAND, OneNAND, SMSC LAN, etc).

I think it will be easier if people can base their work on top of this
patch instead of duplicating the work and sending the same patch to
add a GPMC device node to omap3.dtsi on each patch-set.

Thanks a lot and best regards,
Javier
Benoit Cousson Feb. 18, 2013, 12:26 p.m. UTC | #10
Hi Javier,

On 2/16/2013 5:44 PM, Javier Martinez Canillas wrote:
> On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar <anilkumar880@gmail.com> wrote:
>> Hi Florian,
>>
>> On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
>> <florian.vaussard@epfl.ch> wrote:
>>> Add device-tree support for the GPMC controller on the OMAP3.
>>>
>>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>>> ---
>>>   arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>>>   1 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>>> index 6c63118..2ddae38 100644
>>> --- a/arch/arm/boot/dts/omap3.dtsi
>>> +++ b/arch/arm/boot/dts/omap3.dtsi
>>> @@ -403,5 +403,16 @@
>>>                          ti,timer-alwon;
>>>                          ti,timer-secure;
>>>                  };
>>> +
>>> +               gpmc: gpmc@6e000000 {
>>> +                       compatible = "ti,omap3430-gpmc";
>>> +                       ti,hwmods = "gpmc";
>>> +                       reg = <0x6e000000 0x1000000>;
>>> +                       interrupts = <20>;
>>> +                       gpmc,num-cs = <8>;
>>> +                       gpmc,num-waitpins = <4>;
>>> +                       #address-cells = <2>;
>>> +                       #size-cells = <1>;
>>> +               };
>>>          };
>>>   };
>>
>> Tested on devkit8000 (omap3 based board)
>>
>> Please take my Tested-by: Anil Kumar <anilk4.v@gmail.com>
>>
>> Thanks,
>> Anil
>>
>
> Hello Tony and Benoit,
>
> Could this patch be merged to one of your branches?

I'll take it.

> It has already my Reviewed-by and now Anil's Tested-by.
>
> Now that Daniel's OMAP GPMC binding were merged, there seems to be
> many people working on adding support on their boards DT for
> peripherals connected through the GPMC (NAND, OneNAND, SMSC LAN, etc).
>
> I think it will be easier if people can base their work on top of this
> patch instead of duplicating the work and sending the same patch to
> add a GPMC device node to omap3.dtsi on each patch-set.

Regards,
Benoit
Hunter, Jon Feb. 19, 2013, 1 a.m. UTC | #11
On 01/28/2013 11:54 AM, Florian Vaussard wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
> 
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  arch/arm/boot/dts/omap3.dtsi |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 6c63118..2ddae38 100644
> --- a/arch/arm/boot/dts/omap3.dtsi 
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -403,5 +403,16 @@
>  			ti,timer-alwon;
>  			ti,timer-secure;
>  		};
> +
> +		gpmc: gpmc@6e000000 {
> +			compatible = "ti,omap3430-gpmc";
> +			ti,hwmods = "gpmc";
> +			reg = <0x6e000000 0x1000000>;

Can you make this size smaller? Although the reference manual states
16MB, the registers use less than 1KB of address space. Hence, it is
pointless mapping all this address space for the gpmc registers.

> +			interrupts = <20>;
> +			gpmc,num-cs = <8>;
> +			gpmc,num-waitpins = <4>;
> +			#address-cells = <2>;
> +			#size-cells = <1>;
> +		};
>  	};
>  };

Otherwise ...

Reviewed-by: Jon Hunter <jon-hunter@ti.com>

Cheers
Jon
Benoit Cousson March 14, 2013, 4:01 p.m. UTC | #12
Hi Florian,

On 01/28/2013 06:54 PM, Florian Vaussard wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
> 
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>

Applied and pushed.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts

Regards,
Benoit
diff mbox

Patch

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@ 
 			ti,timer-alwon;
 			ti,timer-secure;
 		};
+
+		gpmc: gpmc@6e000000 {
+			compatible = "ti,omap3430-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x6e000000 0x1000000>;
+			interrupts = <20>;
+			gpmc,num-cs = <8>;
+			gpmc,num-waitpins = <4>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
 	};
 };