[PATCH v6 0/5] OMAP GPMC DT bindings

[PATCH v6 0/5] OMAP GPMC DT bindings

[Daniel Mack]

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

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

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

Again, many thanks to everybody, in particular Avinash, for the long
disussion about how to the these details right in the first place.


Daniel

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  |  76 +++++++++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
 arch/arm/mach-omap2/gpmc-nand.c                    |  15 +-
 arch/arm/mach-omap2/gpmc.c                         | 178 ++++++++++++++++++++-
 drivers/mtd/nand/omap2.c                           |   4 +-
 include/linux/platform_data/mtd-nand-omap2.h       |   4 +-
 6 files changed, 343 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 v6 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 60f1cce..1dcb30c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -844,6 +844,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

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

[Jon Hunter]

On 11/29/2012 10:01 AM, Daniel Mack wrote:
> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  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 60f1cce..1dcb30c 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -844,6 +844,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);

Acked-by: Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org>

Thanks
Jon

[PATCH v6 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 3282b15..a733f15 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1331,6 +1331,7 @@ static int __devinit 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) {
@@ -1556,7 +1557,8 @@ static int __devinit 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 v6 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 8607735..f9f23a2 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 v6 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 f9f23a2..c8a72ba 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

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

[Jon Hunter]

On 11/29/2012 10:01 AM, Daniel Mack wrote:
> 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 f9f23a2..c8a72ba 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;
>  	}

Sorry I should have seen this earlier. Ideally, this type of thing
should be reflected by the device-tree/platform-data and we should get
away from these cpu_is_xxxx macros for hardware features (where we can).
Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
the single zImage work (I see the omap nand driver is including gpmc.h).

Tony, should this be addressed now or can we live this for the minute
and fix-up later?

Cheers
Jon

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

[Jon Hunter]

On 11/29/2012 01:59 PM, Jon Hunter wrote:
> 
> On 11/29/2012 10:01 AM, Daniel Mack wrote:
>> 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 f9f23a2..c8a72ba 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;
>>  	}
> 
> Sorry I should have seen this earlier. Ideally, this type of thing
> should be reflected by the device-tree/platform-data and we should get
> away from these cpu_is_xxxx macros for hardware features (where we can).
> Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
> the single zImage work (I see the omap nand driver is including gpmc.h).
> 
> Tony, should this be addressed now or can we live this for the minute
> and fix-up later?

Actually, I see that you do read the ecc mode from DT, so is this really
needed? It would be good to eliminate this.

Cheers
Jon

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

[Daniel Mack]

On 29.11.2012 21:32, Jon Hunter wrote:
> 
> On 11/29/2012 01:59 PM, Jon Hunter wrote:
>>
>> On 11/29/2012 10:01 AM, Daniel Mack wrote:
>>> 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 f9f23a2..c8a72ba 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;
>>>  	}
>>
>> Sorry I should have seen this earlier. Ideally, this type of thing
>> should be reflected by the device-tree/platform-data and we should get
>> away from these cpu_is_xxxx macros for hardware features (where we can).
>> Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
>> the single zImage work (I see the omap nand driver is including gpmc.h).
>>
>> Tony, should this be addressed now or can we live this for the minute
>> and fix-up later?
> 
> Actually, I see that you do read the ecc mode from DT, so is this really
> needed? It would be good to eliminate this.

The ecc mode is read from DT, right. But the gpmc bindings can be used
for many OMAP derivates in the future, and this check is there to make
sure the configured settings are supported by the hardware after all,
just like if the ecc mode would have been passed as static platform
data. So what is it exactly that you want to get rid of?

I agree though that we could solve this with via the of_device_id's data
pointer of the matching driver. But as you said yourself, this can well
be done later, and the problem here is that we still need the
cpu_is_xxx() macros for older platforms, right?


Thanks,
Daniel

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

[Jon Hunter]

On 11/29/2012 02:42 PM, Daniel Mack wrote:
> On 29.11.2012 21:32, Jon Hunter wrote:
>>
>> On 11/29/2012 01:59 PM, Jon Hunter wrote:
>>>
>>> On 11/29/2012 10:01 AM, Daniel Mack wrote:
>>>> 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 f9f23a2..c8a72ba 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;
>>>>  	}
>>>
>>> Sorry I should have seen this earlier. Ideally, this type of thing
>>> should be reflected by the device-tree/platform-data and we should get
>>> away from these cpu_is_xxxx macros for hardware features (where we can).
>>> Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
>>> the single zImage work (I see the omap nand driver is including gpmc.h).
>>>
>>> Tony, should this be addressed now or can we live this for the minute
>>> and fix-up later?
>>
>> Actually, I see that you do read the ecc mode from DT, so is this really
>> needed? It would be good to eliminate this.
> 
> The ecc mode is read from DT, right. But the gpmc bindings can be used
> for many OMAP derivates in the future, and this check is there to make
> sure the configured settings are supported by the hardware after all,
> just like if the ecc mode would have been passed as static platform
> data. So what is it exactly that you want to get rid of?

The above function.

If there is a hardware bug that prevents us from using the hw-ecc mode
that is supported (which is the case for omap3630 es1.0), then we should
have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
flags should be populated at probe.

> I agree though that we could solve this with via the of_device_id's data
> pointer of the matching driver. But as you said yourself, this can well
> be done later, and the problem here is that we still need the
> cpu_is_xxx() macros for older platforms, right?

Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
driver code. Ok, here we can calling a platform function that is calling
the macro, but for single zImage we cannot do that either. We cannot
include platform headers in drivers for single zImage. We have to get
away from that. Therefore, such information needs to be passed by
platform data, device tree, etc.

I will let Tony decide on how he wants us to handle this.

Cheers
Jon

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

[Daniel Mack]

On 29.11.2012 21:59, Jon Hunter wrote:
> On 11/29/2012 02:42 PM, Daniel Mack wrote:
>> On 29.11.2012 21:32, Jon Hunter wrote:
>>>
>>> On 11/29/2012 01:59 PM, Jon Hunter wrote:
>>>>
>>>> On 11/29/2012 10:01 AM, Daniel Mack wrote:
>>>>> 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 f9f23a2..c8a72ba 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;
>>>>>  	}
>>>>
>>>> Sorry I should have seen this earlier. Ideally, this type of thing
>>>> should be reflected by the device-tree/platform-data and we should get
>>>> away from these cpu_is_xxxx macros for hardware features (where we can).
>>>> Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
>>>> the single zImage work (I see the omap nand driver is including gpmc.h).
>>>>
>>>> Tony, should this be addressed now or can we live this for the minute
>>>> and fix-up later?
>>>
>>> Actually, I see that you do read the ecc mode from DT, so is this really
>>> needed? It would be good to eliminate this.
>>
>> The ecc mode is read from DT, right. But the gpmc bindings can be used
>> for many OMAP derivates in the future, and this check is there to make
>> sure the configured settings are supported by the hardware after all,
>> just like if the ecc mode would have been passed as static platform
>> data. So what is it exactly that you want to get rid of?
> 
> The above function.
> 
> If there is a hardware bug that prevents us from using the hw-ecc mode
> that is supported (which is the case for omap3630 es1.0), then we should
> have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
> flags should be populated at probe.
> 
>> I agree though that we could solve this with via the of_device_id's data
>> pointer of the matching driver. But as you said yourself, this can well
>> be done later, and the problem here is that we still need the
>> cpu_is_xxx() macros for older platforms, right?
> 
> Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
> driver code. Ok, here we can calling a platform function that is calling
> the macro, but for single zImage we cannot do that either. We cannot
> include platform headers in drivers for single zImage. We have to get
> away from that. Therefore, such information needs to be passed by
> platform data, device tree, etc.
> 
> I will let Tony decide on how he wants us to handle this.

Any idea yet about this detail? The other small Documentation changes
you brought up are fixed in my tree and ready for resubmission.


Daniel

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

[Tony Lindgren]

* Daniel Mack <zonque@gmail.com> [121205 05:07]:
> On 29.11.2012 21:59, Jon Hunter wrote:
> > On 11/29/2012 02:42 PM, Daniel Mack wrote:
> >> On 29.11.2012 21:32, Jon Hunter wrote:
> >>>
> >>> On 11/29/2012 01:59 PM, Jon Hunter wrote:
> >>>>
> >>>> On 11/29/2012 10:01 AM, Daniel Mack wrote:
> >>>>> 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 f9f23a2..c8a72ba 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;
> >>>>>  	}
> >>>>
> >>>> Sorry I should have seen this earlier. Ideally, this type of thing
> >>>> should be reflected by the device-tree/platform-data and we should get
> >>>> away from these cpu_is_xxxx macros for hardware features (where we can).
> >>>> Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
> >>>> the single zImage work (I see the omap nand driver is including gpmc.h).
> >>>>
> >>>> Tony, should this be addressed now or can we live this for the minute
> >>>> and fix-up later?
> >>>
> >>> Actually, I see that you do read the ecc mode from DT, so is this really
> >>> needed? It would be good to eliminate this.
> >>
> >> The ecc mode is read from DT, right. But the gpmc bindings can be used
> >> for many OMAP derivates in the future, and this check is there to make
> >> sure the configured settings are supported by the hardware after all,
> >> just like if the ecc mode would have been passed as static platform
> >> data. So what is it exactly that you want to get rid of?
> > 
> > The above function.
> > 
> > If there is a hardware bug that prevents us from using the hw-ecc mode
> > that is supported (which is the case for omap3630 es1.0), then we should
> > have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
> > flags should be populated at probe.
> > 
> >> I agree though that we could solve this with via the of_device_id's data
> >> pointer of the matching driver. But as you said yourself, this can well
> >> be done later, and the problem here is that we still need the
> >> cpu_is_xxx() macros for older platforms, right?
> > 
> > Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
> > driver code. Ok, here we can calling a platform function that is calling
> > the macro, but for single zImage we cannot do that either. We cannot
> > include platform headers in drivers for single zImage. We have to get
> > away from that. Therefore, such information needs to be passed by
> > platform data, device tree, etc.
> > 
> > I will let Tony decide on how he wants us to handle this.
> 
> Any idea yet about this detail? The other small Documentation changes
> you brought up are fixed in my tree and ready for resubmission.

The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use cpu_is_omap macros.

For legacy booting systems, this flag should be just passed in the
platform_data from the platform init code. Then device tree can
deal with it based on the compatible flag.

Regards,

Tony

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

[Daniel Mack]

Hi Tony,

On 05.12.2012 18:19, Tony Lindgren wrote:
> * Daniel Mack <zonque@gmail.com> [121205 05:07]:
>> On 29.11.2012 21:59, Jon Hunter wrote:
>>> On 11/29/2012 02:42 PM, Daniel Mack wrote:
>>>> On 29.11.2012 21:32, Jon Hunter wrote:
>>>>>
>>>>> On 11/29/2012 01:59 PM, Jon Hunter wrote:
>>>>>>
>>>>>> On 11/29/2012 10:01 AM, Daniel Mack wrote:
>>>>>>> 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 f9f23a2..c8a72ba 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;
>>>>>>>  	}
>>>>>>
>>>>>> Sorry I should have seen this earlier. Ideally, this type of thing
>>>>>> should be reflected by the device-tree/platform-data and we should get
>>>>>> away from these cpu_is_xxxx macros for hardware features (where we can).
>>>>>> Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
>>>>>> the single zImage work (I see the omap nand driver is including gpmc.h).
>>>>>>
>>>>>> Tony, should this be addressed now or can we live this for the minute
>>>>>> and fix-up later?
>>>>>
>>>>> Actually, I see that you do read the ecc mode from DT, so is this really
>>>>> needed? It would be good to eliminate this.
>>>>
>>>> The ecc mode is read from DT, right. But the gpmc bindings can be used
>>>> for many OMAP derivates in the future, and this check is there to make
>>>> sure the configured settings are supported by the hardware after all,
>>>> just like if the ecc mode would have been passed as static platform
>>>> data. So what is it exactly that you want to get rid of?
>>>
>>> The above function.
>>>
>>> If there is a hardware bug that prevents us from using the hw-ecc mode
>>> that is supported (which is the case for omap3630 es1.0), then we should
>>> have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
>>> flags should be populated at probe.
>>>
>>>> I agree though that we could solve this with via the of_device_id's data
>>>> pointer of the matching driver. But as you said yourself, this can well
>>>> be done later, and the problem here is that we still need the
>>>> cpu_is_xxx() macros for older platforms, right?
>>>
>>> Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
>>> driver code. Ok, here we can calling a platform function that is calling
>>> the macro, but for single zImage we cannot do that either. We cannot
>>> include platform headers in drivers for single zImage. We have to get
>>> away from that. Therefore, such information needs to be passed by
>>> platform data, device tree, etc.
>>>
>>> I will let Tony decide on how he wants us to handle this.
>>
>> Any idea yet about this detail? The other small Documentation changes
>> you brought up are fixed in my tree and ready for resubmission.
> 
> The plat/cpu.h file will disappear after the merge window, which means
> omap2+ related drivers cannot use cpu_is_omap macros.
>
> For legacy booting systems, this flag should be just passed in the
> platform_data from the platform init code. Then device tree can
> deal with it based on the compatible flag.
>

Ok, thanks for explaining.

Does that mean this patch series should be postponed until after the
merge window and then build upon that change or should we merge the
patch in question here as is and then care for the cleanups after the
window?

I can also rebase this set on top of the removal patches if they exist
already somewhere.


Daniel

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

[Tony Lindgren]

* Daniel Mack <zonque@gmail.com> [121205 09:29]:
> On 05.12.2012 18:19, Tony Lindgren wrote:
> > 
> > The plat/cpu.h file will disappear after the merge window, which means
> > omap2+ related drivers cannot use cpu_is_omap macros.
> >
> > For legacy booting systems, this flag should be just passed in the
> > platform_data from the platform init code. Then device tree can
> > deal with it based on the compatible flag.
> >
> 
> Ok, thanks for explaining.
> 
> Does that mean this patch series should be postponed until after the
> merge window and then build upon that change or should we merge the
> patch in question here as is and then care for the cleanups after the
> window?

Well to me it seems that you only have cpu_is_omap usage in
arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code
under drivers/* needs to be fixed for that. So your patches may
be OK, but..

> I can also rebase this set on top of the removal patches if they exist
> already somewhere.

..please check that your patches work with current linux next.

It's too late to queue thing for v3.8 merge window at this point,
as we want the patches sitting in linux next for a week at least
before they get pulled.

And we still need the acks for the device tree binding as well.

So let's plan on queueing these after -rc1.

Regards,

Tony

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

[Jon Hunter]

On 12/05/2012 11:41 AM, Tony Lindgren wrote:
> * Daniel Mack <zonque@gmail.com> [121205 09:29]:
>> On 05.12.2012 18:19, Tony Lindgren wrote:
>>>
>>> The plat/cpu.h file will disappear after the merge window, which means
>>> omap2+ related drivers cannot use cpu_is_omap macros.
>>>
>>> For legacy booting systems, this flag should be just passed in the
>>> platform_data from the platform init code. Then device tree can
>>> deal with it based on the compatible flag.
>>>
>>
>> Ok, thanks for explaining.
>>
>> Does that mean this patch series should be postponed until after the
>> merge window and then build upon that change or should we merge the
>> patch in question here as is and then care for the cleanups after the
>> window?
> 
> Well to me it seems that you only have cpu_is_omap usage in
> arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code
> under drivers/* needs to be fixed for that. So your patches may
> be OK, but..

The real problem here is that drivers/mtd/nand/omap2.c is including
plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So
although Daniel's patches are not introducing any new problems for
single zImage, they do highlight a problem that we have with the omap2
nand driver that needs to be addressed for single zImage.

So either we fix this now or after merging Daniel's changes. Either is
fine with me.

Cheers
Jon

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

[Tony Lindgren]

* Jon Hunter <jon-hunter@ti.com> [121205 10:22]:
> 
> On 12/05/2012 11:41 AM, Tony Lindgren wrote:
> > * Daniel Mack <zonque@gmail.com> [121205 09:29]:
> >> On 05.12.2012 18:19, Tony Lindgren wrote:
> >>>
> >>> The plat/cpu.h file will disappear after the merge window, which means
> >>> omap2+ related drivers cannot use cpu_is_omap macros.
> >>>
> >>> For legacy booting systems, this flag should be just passed in the
> >>> platform_data from the platform init code. Then device tree can
> >>> deal with it based on the compatible flag.
> >>>
> >>
> >> Ok, thanks for explaining.
> >>
> >> Does that mean this patch series should be postponed until after the
> >> merge window and then build upon that change or should we merge the
> >> patch in question here as is and then care for the cleanups after the
> >> window?
> > 
> > Well to me it seems that you only have cpu_is_omap usage in
> > arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code
> > under drivers/* needs to be fixed for that. So your patches may
> > be OK, but..
> 
> The real problem here is that drivers/mtd/nand/omap2.c is including
> plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So
> although Daniel's patches are not introducing any new problems for
> single zImage, they do highlight a problem that we have with the omap2
> nand driver that needs to be addressed for single zImage.
>
> So either we fix this now or after merging Daniel's changes. Either is
> fine with me.

Ah I see. Yes it would be good to fix that issue first to avoid
adding any new blockers for multiplatform build.

Regards,

Tony

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

[Daniel Mack]

On 05.12.2012 19:33, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121205 10:22]:
>>
>> On 12/05/2012 11:41 AM, Tony Lindgren wrote:
>>> * Daniel Mack <zonque@gmail.com> [121205 09:29]:
>>>> On 05.12.2012 18:19, Tony Lindgren wrote:
>>>>>
>>>>> The plat/cpu.h file will disappear after the merge window, which means
>>>>> omap2+ related drivers cannot use cpu_is_omap macros.
>>>>>
>>>>> For legacy booting systems, this flag should be just passed in the
>>>>> platform_data from the platform init code. Then device tree can
>>>>> deal with it based on the compatible flag.
>>>>>
>>>>
>>>> Ok, thanks for explaining.
>>>>
>>>> Does that mean this patch series should be postponed until after the
>>>> merge window and then build upon that change or should we merge the
>>>> patch in question here as is and then care for the cleanups after the
>>>> window?
>>>
>>> Well to me it seems that you only have cpu_is_omap usage in
>>> arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code
>>> under drivers/* needs to be fixed for that. So your patches may
>>> be OK, but..
>>
>> The real problem here is that drivers/mtd/nand/omap2.c is including
>> plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So
>> although Daniel's patches are not introducing any new problems for
>> single zImage, they do highlight a problem that we have with the omap2
>> nand driver that needs to be addressed for single zImage.
>>
>> So either we fix this now or after merging Daniel's changes. Either is
>> fine with me.
> 
> Ah I see. Yes it would be good to fix that issue first to avoid
> adding any new blockers for multiplatform build.

Already fixed by Afzal here:

https://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=2ef9f3dd

... which is also in linux-next.



Daniel

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

[Jon Hunter]

On 12/05/2012 12:40 PM, Daniel Mack wrote:
> On 05.12.2012 19:33, Tony Lindgren wrote:
>> * Jon Hunter <jon-hunter@ti.com> [121205 10:22]:
>>>
>>> On 12/05/2012 11:41 AM, Tony Lindgren wrote:
>>>> * Daniel Mack <zonque@gmail.com> [121205 09:29]:
>>>>> On 05.12.2012 18:19, Tony Lindgren wrote:
>>>>>>
>>>>>> The plat/cpu.h file will disappear after the merge window, which means
>>>>>> omap2+ related drivers cannot use cpu_is_omap macros.
>>>>>>
>>>>>> For legacy booting systems, this flag should be just passed in the
>>>>>> platform_data from the platform init code. Then device tree can
>>>>>> deal with it based on the compatible flag.
>>>>>>
>>>>>
>>>>> Ok, thanks for explaining.
>>>>>
>>>>> Does that mean this patch series should be postponed until after the
>>>>> merge window and then build upon that change or should we merge the
>>>>> patch in question here as is and then care for the cleanups after the
>>>>> window?
>>>>
>>>> Well to me it seems that you only have cpu_is_omap usage in
>>>> arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code
>>>> under drivers/* needs to be fixed for that. So your patches may
>>>> be OK, but..
>>>
>>> The real problem here is that drivers/mtd/nand/omap2.c is including
>>> plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So
>>> although Daniel's patches are not introducing any new problems for
>>> single zImage, they do highlight a problem that we have with the omap2
>>> nand driver that needs to be addressed for single zImage.
>>>
>>> So either we fix this now or after merging Daniel's changes. Either is
>>> fine with me.
>>
>> Ah I see. Yes it would be good to fix that issue first to avoid
>> adding any new blockers for multiplatform build.
> 
> Already fixed by Afzal here:
> 
> https://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=2ef9f3dd
> 
> ... which is also in linux-next.

Great! So we can drop this change.

Cheers
Jon

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

[Daniel Mack]

On 05.12.2012 18:41, Tony Lindgren wrote:
> * Daniel Mack <zonque@gmail.com> [121205 09:29]:
>> On 05.12.2012 18:19, Tony Lindgren wrote:
>>>
>>> The plat/cpu.h file will disappear after the merge window, which means
>>> omap2+ related drivers cannot use cpu_is_omap macros.
>>>
>>> For legacy booting systems, this flag should be just passed in the
>>> platform_data from the platform init code. Then device tree can
>>> deal with it based on the compatible flag.
>>>
>>
>> Ok, thanks for explaining.
>>
>> Does that mean this patch series should be postponed until after the
>> merge window and then build upon that change or should we merge the
>> patch in question here as is and then care for the cleanups after the
>> window?
> 
> Well to me it seems that you only have cpu_is_omap usage in
> arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code
> under drivers/* needs to be fixed for that. So your patches may
> be OK, but..
> 
>> I can also rebase this set on top of the removal patches if they exist
>> already somewhere.
> 
> ..please check that your patches work with current linux next.
> 
> It's too late to queue thing for v3.8 merge window at this point,
> as we want the patches sitting in linux next for a week at least
> before they get pulled.
> 
> And we still need the acks for the device tree binding as well.

Ok, I'll resubmit a v7 with the nits fixed that Jon pointed out, and
then hope for the maintainer's Acks.

> So let's plan on queueing these after -rc1.

No problem really. The only thing is that I'll be on vacation when the
merge window closes, hence I'd appreciate if you could already queue
them up on your side, so they'll be taken care for :)


Daniel

[PATCH v6 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  |  76 +++++++++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
 arch/arm/mach-omap2/gpmc.c                         | 171 ++++++++++++++++++++-
 3 files changed, 322 insertions(+), 1 deletion(-)
 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..ba3d6a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,76 @@
+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 "ti,gpmc"
+ - 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
+ - num-cs:		The maximum number of chip-select lines that controller
+			can support.
+ - 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>
+
+			Note that this property is not currently parsed.
+			Calculated values derived from the contents of the
+			per-CS register GPMC_CONFIG7 (as set up by the
+			bootloader) are used. That will change in the future,
+			so be sure to fill the correct values here.
+
+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 on OMAP3430:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+	gpmc: gpmc@50000000 {
+		compatible = "ti,gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x2000>;
+		interrupts = <100>;
+
+		num-cs = <8>;
+		#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..58c876f
--- /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,gpmc";
+		ti,hwmods = "gpmc";
+		reg = <0x50000000 0x1000000>;
+		interrupts = <100>;
+		num-cs = <8>;
+		num-waitpins = <8>;
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0x08000000 0x10000000>;	/* 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 1dcb30c..a9638b4 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>
 
@@ -37,6 +41,7 @@
 #include "soc.h"
 #include "common.h"
 #include "gpmc.h"
+#include "gpmc-nand.h"
 
 #define	DEVICE_NAME		"omap-gpmc"
 
@@ -751,7 +756,162 @@ static int __devinit gpmc_mem_init(void)
 	return 0;
 }
 
-static __devinit int gpmc_probe(struct platform_device *pdev)
+#ifdef CONFIG_OF
+static struct of_device_id gpmc_dt_ids[] = {
+	{ .compatible = "ti,gpmc" },
+	{ }
+};
+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 int __devinit gpmc_probe(struct platform_device *pdev)
 {
 	int rc;
 	u32 l;
@@ -804,6 +964,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;
 }
 
@@ -821,6 +989,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

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

[Jon Hunter]

On 11/29/2012 10:01 AM, Daniel Mack 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +++++++++
>  .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
>  arch/arm/mach-omap2/gpmc.c                         | 171 ++++++++++++++++++++-
>  3 files changed, 322 insertions(+), 1 deletion(-)
>  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..ba3d6a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> @@ -0,0 +1,76 @@
> +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 "ti,gpmc"
> + - 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
> + - num-cs:		The maximum number of chip-select lines that controller
> +			can support.
> + - 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>
> +
> +			Note that this property is not currently parsed.
> +			Calculated values derived from the contents of the
> +			per-CS register GPMC_CONFIG7 (as set up by the
> +			bootloader) are used. That will change in the future,
> +			so be sure to fill the correct values here.
> +
> +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 on OMAP3430:
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus

Actually, these are applicable to AM335x as well. I believe that the
comment should be "applicable to OMAP3+ and AM335x". The gpmc driver was
updated to set the flags for these features based upon gpmc version ID.

> +
> +
> +Example for an AM33xx board:
> +
> +	gpmc: gpmc@50000000 {
> +		compatible = "ti,gpmc";
> +		ti,hwmods = "gpmc";
> +		reg = <0x50000000 0x2000>;
> +		interrupts = <100>;
> +
> +		num-cs = <8>;
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +		ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */

Nit, you have num-wait pins as a required property but not shown here in
the example.

> +
> +		/* 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..58c876f
> --- /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,gpmc";
> +		ti,hwmods = "gpmc";
> +		reg = <0x50000000 0x1000000>;

Nit, good to make reg size consistent with the above example.

> +		interrupts = <100>;
> +		num-cs = <8>;
> +		num-waitpins = <8>;

Nit, AM335x only has 2 wait-pins. Number of wait-pins is typically less
than number of CS pins.

Other than these minor comments, looks good to me. Thanks for updating.

Cheers
Jon

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

[Daniel Mack]

On 29.11.2012 21:28, Jon Hunter wrote:
> 
> On 11/29/2012 10:01 AM, Daniel Mack 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  |  76 +++++++++
>>  .../devicetree/bindings/mtd/gpmc-nand.txt          |  76 +++++++++
>>  arch/arm/mach-omap2/gpmc.c                         | 171 ++++++++++++++++++++-
>>  3 files changed, 322 insertions(+), 1 deletion(-)
>>  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..ba3d6a5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> @@ -0,0 +1,76 @@
>> +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 "ti,gpmc"
>> + - 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
>> + - num-cs:		The maximum number of chip-select lines that controller
>> +			can support.
>> + - 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>
>> +
>> +			Note that this property is not currently parsed.
>> +			Calculated values derived from the contents of the
>> +			per-CS register GPMC_CONFIG7 (as set up by the
>> +			bootloader) are used. That will change in the future,
>> +			so be sure to fill the correct values here.
>> +
>> +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 on OMAP3430:
>> + - gpmc,wr-access
>> + - gpmc,wr-data-mux-bus
> 
> Actually, these are applicable to AM335x as well. I believe that the
> comment should be "applicable to OMAP3+ and AM335x". The gpmc driver was
> updated to set the flags for these features based upon gpmc version ID.
> 
>> +
>> +
>> +Example for an AM33xx board:
>> +
>> +	gpmc: gpmc@50000000 {
>> +		compatible = "ti,gpmc";
>> +		ti,hwmods = "gpmc";
>> +		reg = <0x50000000 0x2000>;
>> +		interrupts = <100>;
>> +
>> +		num-cs = <8>;
>> +		#address-cells = <2>;
>> +		#size-cells = <1>;
>> +		ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
> 
> Nit, you have num-wait pins as a required property but not shown here in
> the example.
> 
>> +
>> +		/* 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..58c876f
>> --- /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,gpmc";
>> +		ti,hwmods = "gpmc";
>> +		reg = <0x50000000 0x1000000>;
> 
> Nit, good to make reg size consistent with the above example.
> 
>> +		interrupts = <100>;
>> +		num-cs = <8>;
>> +		num-waitpins = <8>;
> 
> Nit, AM335x only has 2 wait-pins. Number of wait-pins is typically less
> than number of CS pins.
> 
> Other than these minor comments, looks good to me. Thanks for updating.

Thanks for these remarks! All fixed locally. I can send out a v7 tomorrow.


Best,
Daniel