[v8,5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

Commit Message

Daniel Mack Dec. 14, 2012, 10:36 a.m. UTC

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.

Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.

Successfully tested on an AM33xx board.

Signed-off-by: Daniel Mack <[e-mail]>
---
 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  84 ++++++++++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
 arch/arm/mach-omap2/gpmc.c                         | 173 +++++++++++++++++++++
 3 files changed, 333 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

Comments

Grant Likely Dec. 15, 2012, 7:27 a.m. UTC | #1

On Fri, 14 Dec 2012 11:36:44 +0100, Daniel Mack <[e-mail]> wrote:
> This patch adds basic DT bindings for OMAP GPMC.
> 
> The actual peripherals are instantiated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
> 
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
> 
> Successfully tested on an AM33xx board.
> 
> Signed-off-by: Daniel Mack <[e-mail]>

For all patches in this series:
Acked-by: Grant Likely <[e-mail]>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ezequiel Garcia Dec. 23, 2012, 9:46 p.m. UTC | #2

Hi Daniel,

Nice job!

On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
> This patch adds basic DT bindings for OMAP GPMC.
>
> The actual peripherals are instantiated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
>
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
>
> Signed-off-by: Daniel Mack <[e-mail]>
> ---
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  84 ++++++++++
>  .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
>  arch/arm/mach-omap2/gpmc.c                         | 173 +++++++++++++++++++++
>  3 files changed, 333 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
>  create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> new file mode 100644
> index 0000000..5ddb2e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> @@ -0,0 +1,84 @@
> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
> +
> +The actual devices are instantiated from the child nodes of a GPMC node.
> +
> +Required properties:
> +
> + - compatible:         Should be set to one of the following:
> +
> +                       ti,omap2420-gpmc (omap2420)
> +                       ti,omap2430-gpmc (omap2430)
> +                       ti,omap3430-gpmc (omap3430 & omap3630)
> +                       ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
> +                       ti,am3352-gpmc   (am335x devices)
> +
> + - reg:                        A resource specifier for the register space
> +                       (see the example below)
> + - ti,hwmods:          Should be set to "ti,gpmc" until the DT transition is
> +                       completed.
> + - #address-cells:     Must be set to 2 to allow memory address translation
> + - #size-cells:                Must be set to 1 to allow CS address passing
> + - gpmc,num-cs:                The maximum number of chip-select lines that controller
> +                       can support.
> + - gpmc,num-waitpins:  The maximum number of wait pins that controller can
> +                       support.
> + - ranges:             Must be set up to reflect the memory layout with four
> +                       integer values for each chip-select line in use:
> +
> +                          <cs-number> 0 <physical address of mapping> <size>
> +
> +                       Currently, calculated values derived from the contents
> +                       of the per-CS register GPMC_CONFIG7 (as set up by the
> +                       bootloader) are used for the physical address decoding.
> +                       As this will change in the future, filling correct
> +                       values here is a requirement.
> +
> +Timing properties for child nodes. All are optional and default to 0.
> +
> + - gpmc,sync-clk:      Minimum clock period for synchronous mode, in picoseconds
> +
> + Chip-select signal timings corresponding to GPMC_CONFIG2:
> + - gpmc,cs-on:         Assertion time
> + - gpmc,cs-rd-off:     Read deassertion time
> + - gpmc,cs-wr-off:     Write deassertion time
> +
> + ADV signal timings corresponding to GPMC_CONFIG3:
> + - gpmc,adv-on:                Assertion time
> + - gpmc,adv-rd-off:    Read deassertion time
> + - gpmc,adv-wr-off:    Write deassertion time
> +
> + WE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,we-on:         Assertion time
> + - gpmc,we-off:                Deassertion time
> +
> + OE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,oe-on:         Assertion time
> + - gpmc,oe-off:                Deassertion time
> +
> + Access time and cycle time timings corresponding to GPMC_CONFIG5:
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access:                Start-cycle to first data valid delay
> + - gpmc,rd-cycle:      Total read cycle time
> + - gpmc,wr-cycle:      Total write cycle time
> +
> +The following are only applicable to OMAP3+ and AM335x:
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus
> +
> +
> +Example for an AM33xx board:
> +
> +       gpmc: gpmc@50000000 {
> +               compatible = "ti,am3352-gpmc";
> +               ti,hwmods = "gpmc";
> +               reg = <0x50000000 0x2000>;
> +               interrupts = <100>;
> +
> +               gpmc,num-cs = <8>;
> +               gpmc,num-waitpins = <2>;
> +               #address-cells = <2>;
> +               #size-cells = <1>;
> +               ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
> +
> +               /* child nodes go here */
> +       };
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> new file mode 100644
> index 0000000..9f464f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -0,0 +1,76 @@
> +Device tree bindings for GPMC connected NANDs
> +
> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
> +the GPMC controller with a name of "nand".
> +
> +All timing relevant properties as well as generic gpmc child properties are
> +explained in a separate documents - please refer to
> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +
> +For NAND specific properties such as ECC modes or bus width, please refer to
> +Documentation/devicetree/bindings/mtd/nand.txt
> +
> +
> +Required properties:
> +
> + - reg:                The CS line the peripheral is connected to
> +
> +Optional properties:
> +
> + - nand-bus-width:             Set this numeric value to 16 if the hardware
> +                               is wired that way. If not specified, a bus
> +                               width of 8 is assumed.
> +
> + - ti,nand-ecc-opt:            A string setting the ECC layout to use. One of:
> +
> +               "sw"            Software method (default)
> +               "hw"            Hardware method
> +               "hw-romcode"    gpmc hamming mode method & romcode layout
> +               "bch4"          4-bit BCH ecc code
> +               "bch8"          8-bit BCH ecc code
> +
> +For inline partiton table parsing (optional):
> +
> + - #address-cells: should be set to 1
> + - #size-cells: should be set to 1
> +
> +Example for an AM33xx board:
> +
> +       gpmc: gpmc@50000000 {
> +               compatible = "ti,am3352-gpmc";
> +               ti,hwmods = "gpmc";
> +               reg = <0x50000000 0x1000000>;
> +               interrupts = <100>;
> +               gpmc,num-cs = <8>;
> +               gpmc,num-waitpins = <2>;
> +               #address-cells = <2>;
> +               #size-cells = <1>;
> +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND */
> +
> +               nand@0,0 {
> +                       reg = <0 0 0>; /* CS0, offset 0 */

I'm a bit confused by this: what are the other two values in "reg"?
I see you've only added a binding for CS.

I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.

I might send some patches in case anyone wants to give it a try.

Thanks,

    Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Daniel Mack Dec. 24, 2012, 1:07 a.m. UTC | #3

On 12/15/2012 03:27 PM, Grant Likely wrote:
> On Fri, 14 Dec 2012 11:36:44 +0100, Daniel Mack <[e-mail]> wrote:
>> This patch adds basic DT bindings for OMAP GPMC.
>>
>> The actual peripherals are instantiated from child nodes within the GPMC
>> node, and the only type of device that is currently supported is NAND.
>>
>> Code was added to parse the generic GPMC timing parameters and some
>> documentation with examples on how to use them.
>>
>> Successfully tested on an AM33xx board.
>>
>> Signed-off-by: Daniel Mack <[e-mail]>
> 
> For all patches in this series:
> Acked-by: Grant Likely <[e-mail]>

Thanks Grant!

Tony, could you apply these patches somewhere so others can base upon
them? As I said, I'm now travelling and can't continue my work, so I
would much like to know these series at a safe place :)


Again thanks to everyone,
Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren Jan. 14, 2013, 6:06 p.m. UTC | #4

* Ezequiel Garcia <[e-mail]> [121223 13:49]:
> On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
> > +
> > +Example for an AM33xx board:
> > +
> > +       gpmc: gpmc@50000000 {
> > +               compatible = "ti,am3352-gpmc";
> > +               ti,hwmods = "gpmc";
> > +               reg = <0x50000000 0x1000000>;
> > +               interrupts = <100>;
> > +               gpmc,num-cs = <8>;
> > +               gpmc,num-waitpins = <2>;
> > +               #address-cells = <2>;
> > +               #size-cells = <1>;
> > +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND */
> > +
> > +               nand@0,0 {
> > +                       reg = <0 0 0>; /* CS0, offset 0 */
> 
> I'm a bit confused by this: what are the other two values in "reg"?
> I see you've only added a binding for CS.
> 
> I've extended a bit on your work and added a binding to enable OneNAND
> device on my IGEP board.
> 
> I might send some patches in case anyone wants to give it a try.

Daniel, should this be updated to just pass the CS?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren Jan. 15, 2013, 6:03 p.m. UTC | #5

* Daniel Mack <[e-mail]> [130114 15:30]:
> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <[e-mail]> wrote:
> >
> > * Ezequiel Garcia <[e-mail]> [121223 13:49]:
> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
> > > > +
> > > > +Example for an AM33xx board:
> > > > +
> > > > +       gpmc: gpmc@50000000 {
> > > > +               compatible = "ti,am3352-gpmc";
> > > > +               ti,hwmods = "gpmc";
> > > > +               reg = <0x50000000 0x1000000>;
> > > > +               interrupts = <100>;
> > > > +               gpmc,num-cs = <8>;
> > > > +               gpmc,num-waitpins = <2>;
> > > > +               #address-cells = <2>;
> > > > +               #size-cells = <1>;
> > > > +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND
> */
> > > > +
> > > > +               nand@0,0 {
> > > > +                       reg = <0 0 0>; /* CS0, offset 0 */
> > >
> > > I'm a bit confused by this: what are the other two values in "reg"?
> > > I see you've only added a binding for CS.
> > >
> > > I've extended a bit on your work and added a binding to enable OneNAND
> > > device on my IGEP board.
> > >
> > > I might send some patches in case anyone wants to give it a try.
> >
> > Daniel, should this be updated to just pass the CS?
> 
> No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
> feature will help doing the math for the offset calculation eventually, so
> we need to pass all three values.

OK thanks. Applying this set into omap-for-v3.9/gpmc.

Also sounds like Ezequiel needs to update his follow up patches accordingly.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ezequiel Garcia Jan. 15, 2013, 6:10 p.m. UTC | #6

On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <[e-mail]> wrote:
> * Daniel Mack <[e-mail]> [130114 15:30]:
>> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <[e-mail]> wrote:
>> >
>> > * Ezequiel Garcia <[e-mail]> [121223 13:49]:
>> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
>> > > > +
>> > > > +Example for an AM33xx board:
>> > > > +
>> > > > +       gpmc: gpmc@50000000 {
>> > > > +               compatible = "ti,am3352-gpmc";
>> > > > +               ti,hwmods = "gpmc";
>> > > > +               reg = <0x50000000 0x1000000>;
>> > > > +               interrupts = <100>;
>> > > > +               gpmc,num-cs = <8>;
>> > > > +               gpmc,num-waitpins = <2>;
>> > > > +               #address-cells = <2>;
>> > > > +               #size-cells = <1>;
>> > > > +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND
>> */
>> > > > +
>> > > > +               nand@0,0 {
>> > > > +                       reg = <0 0 0>; /* CS0, offset 0 */
>> > >
>> > > I'm a bit confused by this: what are the other two values in "reg"?
>> > > I see you've only added a binding for CS.
>> > >
>> > > I've extended a bit on your work and added a binding to enable OneNAND
>> > > device on my IGEP board.
>> > >
>> > > I might send some patches in case anyone wants to give it a try.
>> >
>> > Daniel, should this be updated to just pass the CS?
>>
>> No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
>> feature will help doing the math for the offset calculation eventually, so
>> we need to pass all three values.
>
> OK thanks. Applying this set into omap-for-v3.9/gpmc.
>
> Also sounds like Ezequiel needs to update his follow up patches accordingly.
>

Ok, I'll do that anytime this week.

Thanks,

Tony Lindgren Jan. 15, 2013, 6:56 p.m. UTC | #7

* Ezequiel Garcia <[e-mail]> [130115 10:13]:
> On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <[e-mail]> wrote:
> > * Daniel Mack <[e-mail]> [130114 15:30]:
> >
> > OK thanks. Applying this set into omap-for-v3.9/gpmc.

Looks like we need ack from for one of the patches Artem before
I can push them out, replied to that patch with Artem in Cc.

> > Also sounds like Ezequiel needs to update his follow up patches accordingly.
> >
> 
> Ok, I'll do that anytime this week.

OK thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ezequiel Garcia Jan. 18, 2013, 7:39 p.m. UTC | #8

Tony,

On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <[e-mail]> wrote:
> * Daniel Mack <[e-mail]> [130114 15:30]:
>> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <[e-mail]> wrote:
>> >
>> > * Ezequiel Garcia <[e-mail]> [121223 13:49]:
>> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
>> > > > +
>> > > > +Example for an AM33xx board:
>> > > > +
>> > > > +       gpmc: gpmc@50000000 {
>> > > > +               compatible = "ti,am3352-gpmc";
>> > > > +               ti,hwmods = "gpmc";
>> > > > +               reg = <0x50000000 0x1000000>;
>> > > > +               interrupts = <100>;
>> > > > +               gpmc,num-cs = <8>;
>> > > > +               gpmc,num-waitpins = <2>;
>> > > > +               #address-cells = <2>;
>> > > > +               #size-cells = <1>;
>> > > > +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND
>> */
>> > > > +
>> > > > +               nand@0,0 {
>> > > > +                       reg = <0 0 0>; /* CS0, offset 0 */
>> > >
>> > > I'm a bit confused by this: what are the other two values in "reg"?
>> > > I see you've only added a binding for CS.
>> > >
>> > > I've extended a bit on your work and added a binding to enable OneNAND
>> > > device on my IGEP board.
>> > >
>> > > I might send some patches in case anyone wants to give it a try.
>> >
>> > Daniel, should this be updated to just pass the CS?
>>
>> No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
>> feature will help doing the math for the offset calculation eventually, so
>> we need to pass all three values.
>
> OK thanks. Applying this set into omap-for-v3.9/gpmc.
>
> Also sounds like Ezequiel needs to update his follow up patches accordingly.
>

The patches for OneNAND that were posted on the ML apply cleanly
on top omap-for-v3.9/gpmc.

What do you want me to update?

Tony Lindgren Jan. 18, 2013, 9:11 p.m. UTC | #9

* Ezequiel Garcia <[e-mail]> [130118 11:43]:
> Tony,
> 
> On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <[e-mail]> wrote:
> > * Daniel Mack <[e-mail]> [130114 15:30]:
> >> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <[e-mail]> wrote:
> >> >
> >> > * Ezequiel Garcia <[e-mail]> [121223 13:49]:
> >> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
> >> > > > +
> >> > > > +Example for an AM33xx board:
> >> > > > +
> >> > > > +       gpmc: gpmc@50000000 {
> >> > > > +               compatible = "ti,am3352-gpmc";
> >> > > > +               ti,hwmods = "gpmc";
> >> > > > +               reg = <0x50000000 0x1000000>;
> >> > > > +               interrupts = <100>;
> >> > > > +               gpmc,num-cs = <8>;
> >> > > > +               gpmc,num-waitpins = <2>;
> >> > > > +               #address-cells = <2>;
> >> > > > +               #size-cells = <1>;
> >> > > > +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND
> >> */
> >> > > > +
> >> > > > +               nand@0,0 {
> >> > > > +                       reg = <0 0 0>; /* CS0, offset 0 */
> >> > >
> >> > > I'm a bit confused by this: what are the other two values in "reg"?
> >> > > I see you've only added a binding for CS.
> >> > >
> >> > > I've extended a bit on your work and added a binding to enable OneNAND
> >> > > device on my IGEP board.
> >> > >
> >> > > I might send some patches in case anyone wants to give it a try.
> >> >
> >> > Daniel, should this be updated to just pass the CS?
> >>
> >> No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
> >> feature will help doing the math for the offset calculation eventually, so
> >> we need to pass all three values.
> >
> > OK thanks. Applying this set into omap-for-v3.9/gpmc.
> >
> > Also sounds like Ezequiel needs to update his follow up patches accordingly.
> >
> 
> The patches for OneNAND that were posted on the ML apply cleanly
> on top omap-for-v3.9/gpmc.
> 
> What do you want me to update?

Oh I though you need to update the binding for the reg for your patches
based on the comments above?

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ezequiel Garcia Jan. 18, 2013, 10:12 p.m. UTC | #10

On Fri, Jan 18, 2013 at 6:11 PM, Tony Lindgren <[e-mail]> wrote:
> * Ezequiel Garcia <[e-mail]> [130118 11:43]:
>> Tony,
>>
>> On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <[e-mail]> wrote:
>> > * Daniel Mack <[e-mail]> [130114 15:30]:
>> >> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <[e-mail]> wrote:
>> >> >
>> >> > * Ezequiel Garcia <[e-mail]> [121223 13:49]:
>> >> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <[e-mail]> wrote:
>> >> > > > +
>> >> > > > +Example for an AM33xx board:
>> >> > > > +
>> >> > > > +       gpmc: gpmc@50000000 {
>> >> > > > +               compatible = "ti,am3352-gpmc";
>> >> > > > +               ti,hwmods = "gpmc";
>> >> > > > +               reg = <0x50000000 0x1000000>;
>> >> > > > +               interrupts = <100>;
>> >> > > > +               gpmc,num-cs = <8>;
>> >> > > > +               gpmc,num-waitpins = <2>;
>> >> > > > +               #address-cells = <2>;
>> >> > > > +               #size-cells = <1>;
>> >> > > > +               ranges = <0 0 0x08000000 0x2000>;       /* CS0: NAND
>> >> */
>> >> > > > +
>> >> > > > +               nand@0,0 {
>> >> > > > +                       reg = <0 0 0>; /* CS0, offset 0 */
>> >> > >
>> >> > > I'm a bit confused by this: what are the other two values in "reg"?
>> >> > > I see you've only added a binding for CS.
>> >> > >
>> >> > > I've extended a bit on your work and added a binding to enable OneNAND
>> >> > > device on my IGEP board.
>> >> > >
>> >> > > I might send some patches in case anyone wants to give it a try.
>> >> >
>> >> > Daniel, should this be updated to just pass the CS?
>> >>
>> >> No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
>> >> feature will help doing the math for the offset calculation eventually, so
>> >> we need to pass all three values.
>> >
>> > OK thanks. Applying this set into omap-for-v3.9/gpmc.
>> >
>> > Also sounds like Ezequiel needs to update his follow up patches accordingly.
>> >
>>
>> The patches for OneNAND that were posted on the ML apply cleanly
>> on top omap-for-v3.9/gpmc.
>>
>> What do you want me to update?
>
> Oh I though you need to update the binding for the reg for your patches
> based on the comments above?
>

Mmm... I believe there isn't anything to update (feel free to correct me).
Actually, if you take a look at my patches you'll see they're almost
identical to Daniel's NAND patches, adapted for OneNAND.

I'll re-send them, to fix a tiny typo in the added Documentation.

Thanks,

Patch

diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 0000000..5ddb2e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,84 @@ 
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible:		Should be set to one of the following:
+
+			ti,omap2420-gpmc (omap2420)
+			ti,omap2430-gpmc (omap2430)
+			ti,omap3430-gpmc (omap3430 & omap3630)
+			ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
+			ti,am3352-gpmc   (am335x devices)
+
+ - reg:			A resource specifier for the register space
+			(see the example below)
+ - ti,hwmods:		Should be set to "ti,gpmc" until the DT transition is
+			completed.
+ - #address-cells:	Must be set to 2 to allow memory address translation
+ - #size-cells:		Must be set to 1 to allow CS address passing
+ - gpmc,num-cs:		The maximum number of chip-select lines that controller
+			can support.
+ - gpmc,num-waitpins:	The maximum number of wait pins that controller can
+			support.
+ - ranges:		Must be set up to reflect the memory layout with four
+			integer values for each chip-select line in use:
+
+			   <cs-number> 0 <physical address of mapping> <size>
+
+			Currently, calculated values derived from the contents
+			of the per-CS register GPMC_CONFIG7 (as set up by the
+			bootloader) are used for the physical address decoding.
+			As this will change in the future, filling correct
+			values here is a requirement.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk:	Minimum clock period for synchronous mode, in picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on:		Assertion time
+ - gpmc,cs-rd-off:	Read deassertion time
+ - gpmc,cs-wr-off:	Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on:		Assertion time
+ - gpmc,adv-rd-off:	Read deassertion time
+ - gpmc,adv-wr-off:	Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on:		Assertion time
+ - gpmc,we-off:		Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on:		Assertion time
+ - gpmc,oe-off:		Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5:
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:		Start-cycle to first data valid delay
+ - gpmc,rd-cycle:	Total read cycle time
+ - gpmc,wr-cycle:	Total write cycle time
+
+The following are only applicable to OMAP3+ and AM335x:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+	gpmc: gpmc@50000000 {
+		compatible = "ti,am3352-gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x2000>;
+		interrupts = <100>;
+
+		gpmc,num-cs = <8>;
+		gpmc,num-waitpins = <2>;
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+
+		/* child nodes go here */
+	};
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 0000000..9f464f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,76 @@ 
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "nand".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg:		The CS line the peripheral is connected to
+
+Optional properties:
+
+ - nand-bus-width: 		Set this numeric value to 16 if the hardware
+				is wired that way. If not specified, a bus
+				width of 8 is assumed.
+
+ - ti,nand-ecc-opt:		A string setting the ECC layout to use. One of:
+
+		"sw"		Software method (default)
+		"hw"		Hardware method
+		"hw-romcode"	gpmc hamming mode method & romcode layout
+		"bch4"		4-bit BCH ecc code
+		"bch8"		8-bit BCH ecc code
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+	gpmc: gpmc@50000000 {
+		compatible = "ti,am3352-gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x1000000>;
+		interrupts = <100>;
+		gpmc,num-cs = <8>;
+		gpmc,num-waitpins = <2>;
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0x08000000 0x2000>;	/* CS0: NAND */
+
+		nand@0,0 {
+			reg = <0 0 0>; /* CS0, offset 0 */
+			nand-bus-width = <16>;
+			ti,nand-ecc-opt = "bch8";
+
+			gpmc,sync-clk = <0>;
+			gpmc,cs-on = <0>;
+			gpmc,cs-rd-off = <44>;
+			gpmc,cs-wr-off = <44>;
+			gpmc,adv-on = <6>;
+			gpmc,adv-rd-off = <34>;
+			gpmc,adv-wr-off = <44>;
+			gpmc,we-off = <40>;
+			gpmc,oe-off = <54>;
+			gpmc,access = <64>;
+			gpmc,rd-cycle = <82>;
+			gpmc,wr-cycle = <82>;
+			gpmc,wr-access = <40>;
+			gpmc,wr-data-mux-bus = <0>;
+
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/* partitions go here */
+		};
+	};
+
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d5cbd29..cbf4e0d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -25,6 +25,10 @@ 
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_mtd.h>
+#include <linux/of_device.h>
+#include <linux/mtd/nand.h>
 
 #include <linux/platform_data/mtd-nand-omap2.h>
 
@@ -34,6 +38,7 @@ 
 #include "common.h"
 #include "omap_device.h"
 #include "gpmc.h"
+#include "gpmc-nand.h"
 
 #define	DEVICE_NAME		"omap-gpmc"
 
@@ -1121,6 +1126,165 @@  int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static struct of_device_id gpmc_dt_ids[] = {
+	{ .compatible = "ti,omap2420-gpmc" },
+	{ .compatible = "ti,omap2430-gpmc" },
+	{ .compatible = "ti,omap3430-gpmc" },	/* omap3430 & omap3630 */
+	{ .compatible = "ti,omap4430-gpmc" },	/* omap4430 & omap4460 & omap543x */
+	{ .compatible = "ti,am3352-gpmc" },	/* am335x devices */
+	{ }
+};
+MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+
+static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
+						struct gpmc_timings *gpmc_t)
+{
+	u32 val;
+
+	memset(gpmc_t, 0, sizeof(*gpmc_t));
+
+	/* minimum clock period for syncronous mode */
+	if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
+		gpmc_t->sync_clk = val;
+
+	/* chip select timtings */
+	if (!of_property_read_u32(np, "gpmc,cs-on", &val))
+		gpmc_t->cs_on = val;
+
+	if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
+		gpmc_t->cs_rd_off = val;
+
+	if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
+		gpmc_t->cs_wr_off = val;
+
+	/* ADV signal timings */
+	if (!of_property_read_u32(np, "gpmc,adv-on", &val))
+		gpmc_t->adv_on = val;
+
+	if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
+		gpmc_t->adv_rd_off = val;
+
+	if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
+		gpmc_t->adv_wr_off = val;
+
+	/* WE signal timings */
+	if (!of_property_read_u32(np, "gpmc,we-on", &val))
+		gpmc_t->we_on = val;
+
+	if (!of_property_read_u32(np, "gpmc,we-off", &val))
+		gpmc_t->we_off = val;
+
+	/* OE signal timings */
+	if (!of_property_read_u32(np, "gpmc,oe-on", &val))
+		gpmc_t->oe_on = val;
+
+	if (!of_property_read_u32(np, "gpmc,oe-off", &val))
+		gpmc_t->oe_off = val;
+
+	/* access and cycle timings */
+	if (!of_property_read_u32(np, "gpmc,page-burst-access", &val))
+		gpmc_t->page_burst_access = val;
+
+	if (!of_property_read_u32(np, "gpmc,access", &val))
+		gpmc_t->access = val;
+
+	if (!of_property_read_u32(np, "gpmc,rd-cycle", &val))
+		gpmc_t->rd_cycle = val;
+
+	if (!of_property_read_u32(np, "gpmc,wr-cycle", &val))
+		gpmc_t->wr_cycle = val;
+
+	/* only for OMAP3430 */
+	if (!of_property_read_u32(np, "gpmc,wr-access", &val))
+		gpmc_t->wr_access = val;
+
+	if (!of_property_read_u32(np, "gpmc,wr-data-mux-bus", &val))
+		gpmc_t->wr_data_mux_bus = val;
+}
+
+#ifdef CONFIG_MTD_NAND
+
+static const char *nand_ecc_opts[] = {
+	[OMAP_ECC_HAMMING_CODE_DEFAULT]		= "sw",
+	[OMAP_ECC_HAMMING_CODE_HW]		= "hw",
+	[OMAP_ECC_HAMMING_CODE_HW_ROMCODE]	= "hw-romcode",
+	[OMAP_ECC_BCH4_CODE_HW]			= "bch4",
+	[OMAP_ECC_BCH8_CODE_HW]			= "bch8",
+};
+
+static int gpmc_probe_nand_child(struct platform_device *pdev,
+				 struct device_node *child)
+{
+	u32 val;
+	const char *s;
+	struct gpmc_timings gpmc_t;
+	struct omap_nand_platform_data *gpmc_nand_data;
+
+	if (of_property_read_u32(child, "reg", &val) < 0) {
+		dev_err(&pdev->dev, "%s has no 'reg' property\n",
+			child->full_name);
+		return -ENODEV;
+	}
+
+	gpmc_nand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_nand_data),
+				      GFP_KERNEL);
+	if (!gpmc_nand_data)
+		return -ENOMEM;
+
+	gpmc_nand_data->cs = val;
+	gpmc_nand_data->of_node = child;
+
+	if (!of_property_read_string(child, "ti,nand-ecc-opt", &s))
+		for (val = 0; val < ARRAY_SIZE(nand_ecc_opts); val++)
+			if (!strcasecmp(s, nand_ecc_opts[val])) {
+				gpmc_nand_data->ecc_opt = val;
+				break;
+			}
+
+	val = of_get_nand_bus_width(child);
+	if (val == 16)
+		gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
+
+	gpmc_read_timings_dt(child, &gpmc_t);
+	gpmc_nand_init(gpmc_nand_data, &gpmc_t);
+
+	return 0;
+}
+#else
+static int gpmc_probe_nand_child(struct platform_device *pdev,
+				 struct device_node *child)
+{
+	return 0;
+}
+#endif
+
+static int gpmc_probe_dt(struct platform_device *pdev)
+{
+	int ret;
+	struct device_node *child;
+	const struct of_device_id *of_id =
+		of_match_device(gpmc_dt_ids, &pdev->dev);
+
+	if (!of_id)
+		return 0;
+
+	for_each_node_by_name(child, "nand") {
+		ret = gpmc_probe_nand_child(pdev, child);
+		of_node_put(child);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+#else
+static int gpmc_probe_dt(struct platform_device *pdev)
+{
+	return 0;
+}
+#endif
+
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
 	int rc;
@@ -1174,6 +1338,14 @@  static __devinit int gpmc_probe(struct platform_device *pdev)
 	if (IS_ERR_VALUE(gpmc_setup_irq()))
 		dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
 
+	rc = gpmc_probe_dt(pdev);
+	if (rc < 0) {
+		clk_disable_unprepare(gpmc_l3_clk);
+		clk_put(gpmc_l3_clk);
+		dev_err(gpmc_dev, "failed to probe DT parameters\n");
+		return rc;
+	}
+
 	return 0;
 }
 
@@ -1191,6 +1363,7 @@  static struct platform_driver gpmc_driver = {
 	.driver		= {
 		.name	= DEVICE_NAME,
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(gpmc_dt_ids),
 	},
 };