[PATCH v8 0/5] OMAP GPMC DT bindings

[PATCH v8 0/5] OMAP GPMC DT bindings

[Daniel Mack]

This is a series of patches to support GPMC peripherals on OMAP boards.

Tested on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)

Generated from linux-next as of today, resolving one trivial include
file rebase conflict.

The only supported peripheral for now is NAND, but other types would be
easy to add.

Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed
and Rob Herring:

 - add "reg" and "ti,hwmod" properties to Documentation
 - use generic of_mtd functions and the property names defined by them,
   namely "nand-bus-width" and "nand-ecc-mode"
 - reduce the default register space size in the Documentation to 8K,
   as found in the hwmod code
 - switch to a DT layout based on ranges and address translation.
   Although this property is not currently looked at as long as the
   handling code still uses the runtime calculation methods, we now
   have these values in the bindings, eventually allowing us to
   switch the implementation with less pain.

Version 3 includes fixes pointed out by Jon Hunter:

 - better documentation of the 'ranges' property to describe the
   fact that it's representing the CS lines
 - GPMC_CS_CONFIGx -> GPMC_CONFIGx in comments
 - drop interrupt-parent from example bindings
 - add of_node_put() at the end of the child iteration

Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more
details from Jon Hunter and Avinash, Philip:

 - Add "num-cs" and "num-waitpins" properties, which will eventually
   be used to get rid of GPMC_CS_NUM
 - Better description of generic nand DT properties
 - Dropped patch 3/4 as an equivalent fix was already merged
 - Added ti,nand-ecc-use-elm property

Version 5 with regards to Avinash, Philip and Peter Korsgaard:

 - Re-add accidentially forgotten
   Documentation/devicetree/bindings/bus/ti-gpmc.txt
 - Rename "software" ecc mode to "sw"
 - Initialize gpmc_nand_data->is_elm_used to 'true' rather than 1
 - Drop ti,nand-ecc-use-elm binding in favor of a new ecc mode
   named "bch8-am335xrbl-compatible"
 - Add two more patches for section mismatch fixups

Version 6:

 - Dropped "bch8-am335xrbl-compatible" mode again. As discussed with
   Avinash, the ELM issue will be solved subsequently in s separate
   series.
 - re-added a patch to bail out of automatic GPMC instanciation in
   case of DT boot.
 - re-added the "of_node" addition in mtd_nand_omap2.h in 2/5

Version 7: comments from Jon Hunter, all affecting the documentation:

 - add num-wait pins properties as they are marked 'required'
 - make reg sizes consistent
 - AM335x only has 2 wait-pins

Version 8: comments from Grant, thanks to Jon for the summary of all
the derivates:

 - Added specific compatible strings for different derivates of OMAPs
 - Renamed num-cs to gpmc,num-cs
 - Renamed num-waitpins to gpmc,num-waitpins


Daniel Mack (5):
  ARM: OMAP: gpmc: don't create devices from initcall on DT
  mtd: omap-nand: pass device_node in platform data
  ARM: OMAP: gpmc-nand: drop __init annotation
  ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
  ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  84 ++++++++++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
 arch/arm/mach-omap2/gpmc-nand.c                    |  15 +-
 arch/arm/mach-omap2/gpmc.c                         | 182 ++++++++++++++++++++-
 drivers/mtd/nand/omap2.c                           |   4 +-
 include/linux/platform_data/mtd-nand-omap2.h       |   4 +-
 6 files changed, 355 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

-- 
1.7.11.7

[PATCH v8 1/5] ARM: OMAP: gpmc: don't create devices from initcall on DT

[Daniel Mack]

On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-omap2/gpmc.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65468f6..d5cbd29 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1214,6 +1214,13 @@ static int __init omap_gpmc_init(void)
 	struct platform_device *pdev;
 	char *oh_name = "gpmc";
 
+	/*
+	 * if the board boots up with a populated DT, do not
+	 * manually add the device from this initcall
+	 */
+	if (of_have_populated_dt())
+		return -ENODEV;
+
 	oh = omap_hwmod_lookup(oh_name);
 	if (!oh) {
 		pr_err("Could not look up %s\n", oh_name);
-- 
1.7.11.7

[PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data

[Daniel Mack]

Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.

For non-DT boards, this change has no effect.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 drivers/mtd/nand/omap2.c                     | 4 +++-
 include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0002d5e..1d333497c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1332,6 +1332,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 	dma_cap_mask_t mask;
 	unsigned sig;
 	struct resource			*res;
+	struct mtd_part_parser_data	ppdata = {};
 
 	pdata = pdev->dev.platform_data;
 	if (pdata == NULL) {
@@ -1557,7 +1558,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto out_release_mem_region;
 	}
 
-	mtd_device_parse_register(&info->mtd, NULL, NULL, pdata->parts,
+	ppdata.of_node = pdata->of_node;
+	mtd_device_parse_register(&info->mtd, NULL, &ppdata, pdata->parts,
 				  pdata->nr_parts);
 
 	platform_set_drvdata(pdev, &info->mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..6bf9ef4 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
 	int			devsize;
 	enum omap_ecc           ecc_opt;
 	struct gpmc_nand_regs	reg;
-};
 
+	/* for passing the partitions */
+	struct device_node	*of_node;
+};
 #endif
-- 
1.7.11.7

[PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data

[Tony Lindgren]

Artem,

Looks like this patch related to making GPMC work with DT was
never sent to linux-mtd or to you so adding to cc.

Is this OK to apply along with the GPMC patches, or do you want to
take this separately with the MTD patches?

Regards,

Tony

* Daniel Mack <zonque@gmail.com> [121214 02:39]:
> Pass an optional device_node pointer in the platform data, which in turn
> will be put into a mtd_part_parser_data. This way, code that sets up the
> platform devices can pass along the node from DT so that the partitions
> can be parsed.
> 
> For non-DT boards, this change has no effect.
> 
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
>  drivers/mtd/nand/omap2.c                     | 4 +++-
>  include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 0002d5e..1d333497c 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1332,6 +1332,7 @@ static int omap_nand_probe(struct platform_device *pdev)
>  	dma_cap_mask_t mask;
>  	unsigned sig;
>  	struct resource			*res;
> +	struct mtd_part_parser_data	ppdata = {};
>  
>  	pdata = pdev->dev.platform_data;
>  	if (pdata == NULL) {
> @@ -1557,7 +1558,8 @@ static int omap_nand_probe(struct platform_device *pdev)
>  		goto out_release_mem_region;
>  	}
>  
> -	mtd_device_parse_register(&info->mtd, NULL, NULL, pdata->parts,
> +	ppdata.of_node = pdata->of_node;
> +	mtd_device_parse_register(&info->mtd, NULL, &ppdata, pdata->parts,
>  				  pdata->nr_parts);
>  
>  	platform_set_drvdata(pdev, &info->mtd);
> diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
> index 24d32ca..6bf9ef4 100644
> --- a/include/linux/platform_data/mtd-nand-omap2.h
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -60,6 +60,8 @@ struct omap_nand_platform_data {
>  	int			devsize;
>  	enum omap_ecc           ecc_opt;
>  	struct gpmc_nand_regs	reg;
> -};
>  
> +	/* for passing the partitions */
> +	struct device_node	*of_node;
> +};
>  #endif
> -- 
> 1.7.11.7
> 

[PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data

[Artem Bityutskiy]

On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote:
> Artem,
> 
> Looks like this patch related to making GPMC work with DT was
> never sent to linux-mtd or to you so adding to cc.
> 
> Is this OK to apply along with the GPMC patches, or do you want to
> take this separately with the MTD patches?

Please, go ahead!

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/b2da5b95/attachment-0001.sig>

[PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data

[Tony Lindgren]

* Artem Bityutskiy <dedekind1@gmail.com> [130115 11:12]:
> On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote:
> > Artem,
> > 
> > Looks like this patch related to making GPMC work with DT was
> > never sent to linux-mtd or to you so adding to cc.
> > 
> > Is this OK to apply along with the GPMC patches, or do you want to
> > take this separately with the MTD patches?
> 
> Please, go ahead!

OK thanks. Can I add your Acked-by too?

Tony

[PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data

[Artem Bityutskiy]

On Tue, 2013-01-15 at 11:26 -0800, Tony Lindgren wrote:
> * Artem Bityutskiy <dedekind1@gmail.com> [130115 11:12]:
> > On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote:
> > > Artem,
> > > 
> > > Looks like this patch related to making GPMC work with DT was
> > > never sent to linux-mtd or to you so adding to cc.
> > > 
> > > Is this OK to apply along with the GPMC patches, or do you want to
> > > take this separately with the MTD patches?
> > 
> > Please, go ahead!
> 
> OK thanks. Can I add your Acked-by too?

Yes Tony, please, do:

Acked-by: Artem Bityutskiy <dedekind1@gmail.com>

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/b7b40c11/attachment-0001.sig>

[PATCH v8 3/5] ARM: OMAP: gpmc-nand: drop __init annotation

[Daniel Mack]

gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index db969a5..3059f5e 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -89,7 +89,7 @@ static int omap2_nand_gpmc_retime(
 	return 0;
 }
 
-static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
+static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
 	/* support only OMAP3 class */
 	if (!cpu_is_omap34xx()) {
@@ -110,8 +110,8 @@ static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 	return 1;
 }
 
-int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
-			  struct gpmc_timings *gpmc_t)
+int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
+		   struct gpmc_timings *gpmc_t)
 {
 	int err	= 0;
 	struct device *dev = &gpmc_nand_device.dev;
-- 
1.7.11.7

[PATCH v8 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs

[Daniel Mack]

The am33xx is capable of handling bch error correction modes, so
enable that feature in the driver.

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 arch/arm/mach-omap2/gpmc-nand.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 3059f5e..afc1e8c 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,17 +92,18 @@ static int omap2_nand_gpmc_retime(
 static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
 	/* support only OMAP3 class */
-	if (!cpu_is_omap34xx()) {
+	if (!cpu_is_omap34xx() && !soc_is_am33xx()) {
 		pr_err("BCH ecc is not supported on this CPU\n");
 		return 0;
 	}
 
 	/*
-	 * For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x>=1.
-	 * Other chips may be added if confirmed to work.
+	 * For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x>=1
+	 * and AM33xx derivates. Other chips may be added if confirmed to work.
 	 */
 	if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW) &&
-	    (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
+	    (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0)) &&
+	    (!soc_is_am33xx())) {
 		pr_err("BCH 4-bit mode is not supported on this CPU\n");
 		return 0;
 	}
-- 
1.7.11.7

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

[Daniel Mack]

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 <zonque@gmail.com>
---
 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 at 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 at 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 at 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),
 	},
 };
 
-- 
1.7.11.7

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

[Grant Likely]

On Fri, 14 Dec 2012 11:36:44 +0100, Daniel Mack <zonque@gmail.com> 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 <zonque@gmail.com>

For all patches in this series:
Acked-by: Grant Likely <grant.likely@secretlab.ca>

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

[Daniel Mack]

On 12/15/2012 03:27 PM, Grant Likely wrote:
> On Fri, 14 Dec 2012 11:36:44 +0100, Daniel Mack <zonque@gmail.com> 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 <zonque@gmail.com>
> 
> For all patches in this series:
> Acked-by: Grant Likely <grant.likely@secretlab.ca>

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

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

[Ezequiel Garcia]

Hi Daniel,

Nice job!

On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> 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 <zonque@gmail.com>
> ---
>  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 at 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 at 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 at 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

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

[Tony Lindgren]

* Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
> On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
> > +
> > +Example for an AM33xx board:
> > +
> > +       gpmc: gpmc at 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 at 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

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

[Daniel Mack]

On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
>
> * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
> > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
> > > +
> > > +Example for an AM33xx board:
> > > +
> > > +       gpmc: gpmc at 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 at 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.

Regards,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130114/c232814c/attachment.html>

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

[Tony Lindgren]

* Daniel Mack <zonque@gmail.com> [130114 15:30]:
> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
> >
> > * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
> > > > +
> > > > +Example for an AM33xx board:
> > > > +
> > > > +       gpmc: gpmc at 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 at 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

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

[Ezequiel Garcia]

On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Daniel Mack <zonque@gmail.com> [130114 15:30]:
>> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
>> >
>> > * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
>> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
>> > > > +
>> > > > +Example for an AM33xx board:
>> > > > +
>> > > > +       gpmc: gpmc at 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 at 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,

-- 
    Ezequiel

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

[Tony Lindgren]

* Ezequiel Garcia <elezegarcia@gmail.com> [130115 10:13]:
> On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Daniel Mack <zonque@gmail.com> [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

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

[Ezequiel Garcia]

Tony,

On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Daniel Mack <zonque@gmail.com> [130114 15:30]:
>> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
>> >
>> > * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
>> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
>> > > > +
>> > > > +Example for an AM33xx board:
>> > > > +
>> > > > +       gpmc: gpmc at 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 at 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?

-- 
    Ezequiel

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

[Tony Lindgren]

* Ezequiel Garcia <elezegarcia@gmail.com> [130118 11:43]:
> Tony,
> 
> On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Daniel Mack <zonque@gmail.com> [130114 15:30]:
> >> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
> >> >
> >> > * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
> >> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
> >> > > > +
> >> > > > +Example for an AM33xx board:
> >> > > > +
> >> > > > +       gpmc: gpmc at 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 at 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

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

[Ezequiel Garcia]

On Fri, Jan 18, 2013 at 6:11 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Ezequiel Garcia <elezegarcia@gmail.com> [130118 11:43]:
>> Tony,
>>
>> On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Daniel Mack <zonque@gmail.com> [130114 15:30]:
>> >> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
>> >> >
>> >> > * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
>> >> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
>> >> > > > +
>> >> > > > +Example for an AM33xx board:
>> >> > > > +
>> >> > > > +       gpmc: gpmc at 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 at 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,

-- 
    Ezequiel