[PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[Roger Quadros]

Hi Tony,

These are some of the issues I found while testing v3.17-rc3.

- Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
BCH16 instead of BCH8.

- Wrong read/write wait pin monitoring setting used for NAND
resulting in "L3 application error" debug message on console.

- Pin conflict issue on am43x EPOS evm with QSPI and NAND.

Patches are available at
git@github.com:rogerq/linux.git
* [new branch]      for-v3.17/gpmc-fixes

cheers,
-roger

Roger Quadros (6):
  ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
  ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
  ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
  ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring
  ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w
    monitoring
  ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with
    GPMC-NAND

 arch/arm/boot/dts/am437x-gp-evm.dts  | 4 +---
 arch/arm/boot/dts/am43x-epos-evm.dts | 9 ++++-----
 arch/arm/mach-omap2/gpmc.c           | 7 +++----
 3 files changed, 8 insertions(+), 12 deletions(-)

-- 
1.8.3.2

[PATCH 1/6] ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8

[Roger Quadros]

am43x-epos-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.

For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index ed7dd23..f6c9898 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -441,7 +441,7 @@
 	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
 	nand@0,0 {
 		reg = <0 0 0>; /* CS0, offset 0 */
-		ti,nand-ecc-opt = "bch8";
+		ti,nand-ecc-opt = "bch16";
 		ti,elm-id = <&elm>;
 		nand-bus-width = <8>;
 		gpmc,device-width = <1>;
-- 
1.8.3.2

[PATCH 2/6] ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8

[Roger Quadros]

am437x-gp-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.

For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 646a6ea..402249e 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -424,7 +424,7 @@
 	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
 	nand@0,0 {
 		reg = <0 0 4>;		/* device IO registers */
-		ti,nand-ecc-opt = "bch8";
+		ti,nand-ecc-opt = "bch16";
 		ti,elm-id = <&elm>;
 		nand-bus-width = <8>;
 		gpmc,device-width = <1>;
-- 
1.8.3.2

[PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[Roger Quadros]

NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.

This patch also gets rid of the below warning when NAND is
accessed for the first time.

omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 402249e..ff4af7b 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -443,8 +443,6 @@
 		gpmc,rd-cycle-ns = <40>;
 		gpmc,wr-cycle-ns = <40>;
 		gpmc,wait-pin = <0>;
-		gpmc,wait-on-read;
-		gpmc,wait-on-write;
 		gpmc,bus-turnaround-ns = <0>;
 		gpmc,cycle2cycle-delay-ns = <0>;
 		gpmc,clk-activation-ns = <0>;
-- 
1.8.3.2

[PATCH 4/6] ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring

[Roger Quadros]

NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.

Add gpmc wait pin information as the NAND uses wait pin 0
for device ready indication.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index f6c9898..b489b27 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -459,8 +459,7 @@
 		gpmc,access-ns = <30>; /* tCEA + 4*/
 		gpmc,rd-cycle-ns = <40>;
 		gpmc,wr-cycle-ns = <40>;
-		gpmc,wait-on-read = "true";
-		gpmc,wait-on-write = "true";
+		gpmc,wait-pin = <0>;
 		gpmc,bus-turnaround-ns = <0>;
 		gpmc,cycle2cycle-delay-ns = <0>;
 		gpmc,clk-activation-ns = <0>;
-- 
1.8.3.2

[PATCH 5/6] ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring

[Roger Quadros]

For NAND read & write wait pin monitoring must be kept disabled as the
wait pin is only used to indicate NAND device ready status and not to
extend each read/write cycle.

So don't print a warning if wait pin is specified while read/write
monitoring is not in the device tree.

Sanity check wait pin number irrespective if read/write monitoring is
set or not.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/gpmc.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9f42d54..2f97228 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1207,8 +1207,7 @@ int gpmc_cs_program_settings(int cs, struct gpmc_settings *p)
 		}
 	}
 
-	if ((p->wait_on_read || p->wait_on_write) &&
-	    (p->wait_pin > gpmc_nr_waitpins)) {
+	if (p->wait_pin > gpmc_nr_waitpins) {
 		pr_err("%s: invalid wait-pin (%d)\n", __func__, p->wait_pin);
 		return -EINVAL;
 	}
@@ -1288,8 +1287,8 @@ void gpmc_read_settings_dt(struct device_node *np, struct gpmc_settings *p)
 		p->wait_on_write = of_property_read_bool(np,
 							 "gpmc,wait-on-write");
 		if (!p->wait_on_read && !p->wait_on_write)
-			pr_warn("%s: read/write wait monitoring not enabled!\n",
-				__func__);
+			pr_debug("%s: rd/wr wait monitoring not enabled!\n",
+				 __func__);
 	}
 }
 
-- 
1.8.3.2

[PATCH 6/6] ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND

[Roger Quadros]

Both QSPI and GPMC-NAND share the same Pin (A8) from the SoC for Chip Select
functionality. So both can't be enabled simultaneously.

Disable QSPI node to prevent the pin conflict as well as
be similar to 3.12 release.

CC: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index b489b27..ac3e485 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -435,7 +435,7 @@
 };
 
 &gpmc {
-	status = "okay";
+	status = "okay";	/* Disable QSPI when enabling GPMC (NAND) */
 	pinctrl-names = "default";
 	pinctrl-0 = <&nand_flash_x8>;
 	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
@@ -556,7 +556,7 @@
 };
 
 &qspi {
-	status = "okay";
+	status = "disabled";	/* Disable GPMC (NAND) when enabling QSPI */
 	pinctrl-names = "default";
 	pinctrl-0 = <&qspi1_default>;
 
-- 
1.8.3.2

Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[pekon]

Hi Roger,

On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
> Hi Tony,
>
> These are some of the issues I found while testing v3.17-rc3.
>
> - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
> BCH16 instead of BCH8.
>
Thanks for updating ECC scheme for AM43x EVM boards.
Just for background history, BCH16 ECC scheme was not in
mainline when AM43xx NAND DTS patches were accepted. So to
avoid any inter-dependency of patches, BCH8 was used instead.

commit f68e355c86cff91e5266cf937ea24fcba0641900
     ARM: dts: am43xx: add support for parallel NAND flash
     CommitDate: 2 March 2014

commit 9748fff96484cfc8bb382ef1436823aefe065c9c
     mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
     CommitDate: 21 May 2014

For the record, boot-loader (u-boot SPL) on AM43x-EPOS and
AM437x-GP EVM boards should be flashed in BCH16 ECC scheme
as NAND device present on this boards has
- page-size=4KiB
- OOB-size=224B

So ROM code expects BCH16 ECC scheme to load first boot-loader(SPL).


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 1/6] ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8

[pekon]

On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
> am43x-epos-evm uses a NAND chip with page size 4096 bytes
> and spare area of 225 bytes per page.
>
> For such a setup it is preferrable to use BCH16 ECC scheme over
> BCH8. This also makes it compatible with ROM code ECC scheme so
> we can boot with NAND after flashing from kernel.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>   arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
> index ed7dd23..f6c9898 100644
> --- a/arch/arm/boot/dts/am43x-epos-evm.dts
> +++ b/arch/arm/boot/dts/am43x-epos-evm.dts
> @@ -441,7 +441,7 @@
>   	ranges = <0 0 0x08000000 0x10000000>;	/* CS0: NAND */
>   	nand@0,0 {
>   		reg = <0 0 0>; /* CS0, offset 0 */
> -		ti,nand-ecc-opt = "bch8";
> +		ti,nand-ecc-opt = "bch16";
>   		ti,elm-id = <&elm>;
>   		nand-bus-width = <8>;
>   		gpmc,device-width = <1>;
>

As I have tested BCH16 on AM43x-EPOS board earlier So,
Reviewed-by: Pekon Gupta <pekon@pek-sem.com>


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 2/6] ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8

[pekon]

On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
> am437x-gp-evm uses a NAND chip with page size 4096 bytes
> and spare area of 225 bytes per page.
>
> For such a setup it is preferrable to use BCH16 ECC scheme over
> BCH8. This also makes it compatible with ROM code ECC scheme so
> we can boot with NAND after flashing from kernel.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>   arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 646a6ea..402249e 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -424,7 +424,7 @@
>   	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
>   	nand@0,0 {
>   		reg = <0 0 4>;		/* device IO registers */
> -		ti,nand-ecc-opt = "bch8";
> +		ti,nand-ecc-opt = "bch16";
>   		ti,elm-id = <&elm>;
>   		nand-bus-width = <8>;
>   		gpmc,device-width = <1>;
>
For already mentioned reason ..
Reviewed-by: Pekon Gupta <pekon@pek-sem.com>


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[pekon]

Hi Roger,


On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
> NAND uses wait pin only to indicate device readiness after
> a block/page operation. It is not use to extend individual
> read/write cycle and so read/write wait pin monitoring must
> be disabled for NAND.
>
I think this is incorrect assumption. NAND framework allows
wait-pin monitoring at end of each read/write cycle. Please
refer following code in drivers/mtd/nand/nand_base.c
	@@ void nand_wait_ready(...)

- nand_wait_ready() calls controller-driver specific call-back
   for chip->dev_ready().

- chip->dev_ready in-case of OMAP NAND drivers is set in
   drivers/mtd/nand/omap2.c  during probe.
	if (pdata->dev_ready) {
		nand_chip->dev_ready = omap_dev_ready;
		nand_chip->chip_delay = 0;
	}

Problem is we don't set pdata->dev_ready correctly as part
of platform-data dring GPMC initialization. This was what my
earlier patch for wait-pin monitoring about. But it was a
quick fix for NAND devices.

So, I suggest to fix wait-pin monitoring instead of de-scoping
it from DTS as wait-pin monitoring should boast the NAND
performance significantly.
(please see if you can find an old mail thread which had some
good feedbacks from Ezequiel and Javier about wait-pin monitoring).

[...]

> This patch also gets rid of the below warning when NAND is
> accessed for the first time.
>
> omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
>
Can you debug this further.
This warning probably comes when driver tries to access some
"reserved" addresses. Or violate read/write bits.


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 5/6] ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring

[pekon]

On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
> For NAND read & write wait pin monitoring must be kept disabled as the
> wait pin is only used to indicate NAND device ready status and not to
> extend each read/write cycle.
>
I think this description, does not fit in this patch.
And is incorrect as explained in previous patch review.


> So don't print a warning if wait pin is specified while read/write
> monitoring is not in the device tree.
>
> Sanity check wait pin number irrespective if read/write monitoring is
> set or not.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
But below mentioned checks and clean-up makes sense. So
apart from first 3 lines of commit log ..

Reviewed-by: Pekon Gupta <pekon@pek-sem.com>


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[Roger Quadros]

Hi Pekon,

On 09/02/2014 10:02 PM, pekon wrote:
> Hi Roger,
> 
> 
> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
>> NAND uses wait pin only to indicate device readiness after
>> a block/page operation. It is not use to extend individual
>> read/write cycle and so read/write wait pin monitoring must
>> be disabled for NAND.
>>
> I think this is incorrect assumption. NAND framework allows
> wait-pin monitoring at end of each read/write cycle. Please
> refer following code in drivers/mtd/nand/nand_base.c
>     @@ void nand_wait_ready(...)
> 
> - nand_wait_ready() calls controller-driver specific call-back
>   for chip->dev_ready().

It is important to note that this NAND device ready mechanism is different from
GPMC inter cycle wait state mechanism controlled by the read/write monitoring
bits. The same WAIT pin is used in both the cases.

For more details about NAND use case refer to 

AM437x TRM:
Section: 9.1.3.3.12.2 NAND Device-Ready Pin

below excerpt from there
"To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring
for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and
GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0):

> 
> - chip->dev_ready in-case of OMAP NAND drivers is set in
>   drivers/mtd/nand/omap2.c  during probe.
>     if (pdata->dev_ready) {
>         nand_chip->dev_ready = omap_dev_ready;
>         nand_chip->chip_delay = 0;
>     }
> 
> Problem is we don't set pdata->dev_ready correctly as part
> of platform-data dring GPMC initialization. This was what my
> earlier patch for wait-pin monitoring about. But it was a
> quick fix for NAND devices.
> 
> So, I suggest to fix wait-pin monitoring instead of de-scoping
> it from DTS as wait-pin monitoring should boast the NAND
> performance significantly.
> (please see if you can find an old mail thread which had some
> good feedbacks from Ezequiel and Javier about wait-pin monitoring).

This is to get the device ready mechanism work and has nothing to do with
GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
interrupt based on the WAIT pin polarity.

To monitor NAND device ready status
from TRM
"-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
OR
-Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits)"

> 
> [...]
> 
>> This patch also gets rid of the below warning when NAND is
>> accessed for the first time.
>>
>> omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
>>
> Can you debug this further.
> This warning probably comes when driver tries to access some
> "reserved" addresses. Or violate read/write bits.

It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling the
wait monitoring gets rid of this error. I don't understand what else I should debug and why.

cheers,
-roger

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[Roger Quadros]

Hi Pekon,

On 09/02/2014 10:02 PM, pekon wrote:
> Hi Roger,
> 
> 
> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
>> NAND uses wait pin only to indicate device readiness after
>> a block/page operation. It is not use to extend individual
>> read/write cycle and so read/write wait pin monitoring must
>> be disabled for NAND.
>>
> I think this is incorrect assumption. NAND framework allows
> wait-pin monitoring at end of each read/write cycle. Please
> refer following code in drivers/mtd/nand/nand_base.c
>     @@ void nand_wait_ready(...)
> 
> - nand_wait_ready() calls controller-driver specific call-back
>   for chip->dev_ready().

It is important to note that this NAND device ready mechanism is different from
GPMC inter cycle wait state mechanism controlled by the read/write monitoring
bits. The same WAIT pin is used in both the cases.

For more details about NAND use case refer to 

AM437x TRM:
Section: 9.1.3.3.12.2 NAND Device-Ready Pin

below excerpt from there
"To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring
for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and
GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0):

> 
> - chip->dev_ready in-case of OMAP NAND drivers is set in
>   drivers/mtd/nand/omap2.c  during probe.
>     if (pdata->dev_ready) {
>         nand_chip->dev_ready = omap_dev_ready;
>         nand_chip->chip_delay = 0;
>     }
> 
> Problem is we don't set pdata->dev_ready correctly as part
> of platform-data dring GPMC initialization. This was what my
> earlier patch for wait-pin monitoring about. But it was a
> quick fix for NAND devices.
> 
> So, I suggest to fix wait-pin monitoring instead of de-scoping
> it from DTS as wait-pin monitoring should boast the NAND
> performance significantly.
> (please see if you can find an old mail thread which had some
> good feedbacks from Ezequiel and Javier about wait-pin monitoring).

This is to get the device ready mechanism work and has nothing to do with
GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
interrupt based on the WAIT pin polarity.

To monitor NAND device ready status
from TRM
"-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
OR
-Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits)"

> 
> [...]
> 
>> This patch also gets rid of the below warning when NAND is
>> accessed for the first time.
>>
>> omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
>>
> Can you debug this further.
> This warning probably comes when driver tries to access some
> "reserved" addresses. Or violate read/write bits.

It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling the
wait monitoring gets rid of this error. I don't understand what else I should debug and why.

cheers,
-roger

Re: [PATCH 5/6] ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring

[Roger Quadros]

On 09/02/2014 10:12 PM, pekon wrote:
> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
>> For NAND read & write wait pin monitoring must be kept disabled as the
>> wait pin is only used to indicate NAND device ready status and not to
>> extend each read/write cycle.
>>
> I think this description, does not fit in this patch.

It fits the description because it gives the reason why wait monitoring is optional.

> And is incorrect as explained in previous patch review.

It is correct. I've pointed you to the relevant TRM sections where it is said
that GPMC read/write monitoring must be disabled for NAND case.

cheers,
-roger

> 
> 
>> So don't print a warning if wait pin is specified while read/write
>> monitoring is not in the device tree.
>>
>> Sanity check wait pin number irrespective if read/write monitoring is
>> set or not.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
> But below mentioned checks and clean-up makes sense. So
> apart from first 3 lines of commit log ..
> 
> Reviewed-by: Pekon Gupta <pekon@pek-sem.com>
> 
> 
> with regards, pekon
> 
> ------------------------
> Powered by BigRock.com
> 

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[pekon]

Hi Roger,

On Wednesday 03 September 2014 02:02 PM, Roger Quadros wrote:
> Hi Pekon,
>
> On 09/02/2014 10:02 PM, pekon wrote:
>> Hi Roger,
>>
>>
>> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
>>> NAND uses wait pin only to indicate device readiness after
>>> a block/page operation. It is not use to extend individual
>>> read/write cycle and so read/write wait pin monitoring must
>>> be disabled for NAND.
>>>
>> I think this is incorrect assumption. NAND framework allows
>> wait-pin monitoring at end of each read/write cycle. Please
>> refer following code in drivers/mtd/nand/nand_base.c
>>      @@ void nand_wait_ready(...)
>>
>> - nand_wait_ready() calls controller-driver specific call-back
>>    for chip->dev_ready().
>
> It is important to note that this NAND device ready mechanism is different from
> GPMC inter cycle wait state mechanism controlled by the read/write monitoring
> bits. The same WAIT pin is used in both the cases.
>
> For more details about NAND use case refer to
>
> AM437x TRM:
> Section: 9.1.3.3.12.2 NAND Device-Ready Pin
>
> below excerpt from there
> "To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring
> for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and
> GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0):
>

I re-read the AM437x TRM, and the section you mentioned above.

-----------------
*9.1.3.3.12.2 NAND Device-Ready Pin*
The NAND memory device provides a ready pin to indicate data 
availability after a block/page opening and to indicate that data 
programming is complete. The ready pin can be connected to one of the 
WAIT GPMC input pins; data read accesses must not be tried when the 
ready pin is sampled inactive (device is not ready) even if the 
associated chip-select WAITREADMONITORING bit field is set. The duration 
of the NAND device busy state after the block/page opening is so long 
(up to 50 μs) that accesses occurring when the ready pin is sampled 
inactive can stall GPMC access and eventually cause a system time-out.
If a read access to a NAND flash is done using the wait monitoring mode, 
the device is blocked during a page opening, and so is the GPMC. If the 
correct settings are used, other chip-selects can be used while
the memory processes the page opening command.
...
-----------------

It's clearly written that wait-pin monitoring is used for read/write 
(programs) access, and GPMC is blocked till wait signal is asserted 
during reads.
Also, on NAND there can be no read/write access except at page-level
so wait-pin monitoring is implicitly related to read/write accesses.
However, whether you use it or not is purely user's choice, but it
has performance impact.

You are probably seeing timeout condition when enabling wait-pin
monitoring, and this can be due to multiple reasons like;
(1) incorrect pin-mux configuration (like directions, pull-up etc)
(2) incorrect board-level pull-up
(3) incorrect driver setting, like though wait-pin is enabled but
     wrong wait-pin is being monitored.

I request you to fix this instead of disabling it completely,
as you should see significant NAND throughput increase once this
feature works correctly.

>>
>> - chip->dev_ready in-case of OMAP NAND drivers is set in
>>    drivers/mtd/nand/omap2.c  during probe.
>>      if (pdata->dev_ready) {
>>          nand_chip->dev_ready = omap_dev_ready;
>>          nand_chip->chip_delay = 0;
>>      }
>>
>> Problem is we don't set pdata->dev_ready correctly as part
>> of platform-data dring GPMC initialization. This was what my
>> earlier patch for wait-pin monitoring about. But it was a
>> quick fix for NAND devices.
>>
>> So, I suggest to fix wait-pin monitoring instead of de-scoping
>> it from DTS as wait-pin monitoring should boast the NAND
>> performance significantly.
>> (please see if you can find an old mail thread which had some
>> good feedbacks from Ezequiel and Javier about wait-pin monitoring).
>
> This is to get the device ready mechanism work and has nothing to do with
> GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
> interrupt based on the WAIT pin polarity.
>
> To monitor NAND device ready status
> from TRM
> "-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
> OR
> -Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits)"
>
>>
>> [...]
>>
>>> This patch also gets rid of the below warning when NAND is
>>> accessed for the first time.
>>>
>>> omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
>>>
>> Can you debug this further.
>> This warning probably comes when driver tries to access some
>> "reserved" addresses. Or violate read/write bits.
>
> It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling the
> wait monitoring gets rid of this error. I don't understand what else I should debug

I'm not sure how a NAND or GPMC feature can cause omap_l3_noc: L3 
application error ?
But now as I re-read the text, its probably the L3 interconnect timeout
error due to no response from GPMC. There is a timer in L3 which 
monitors if the L3 interconnect is stalled/blocked waiting for response
from a target. I think it's that timer which is getting timeout. (but 
just my guess).


 > and why.
 >
As there were number of users on linux-mtd list wanted to use
NAND wait-pin monitoring on OMAP devices, so I have just looped
them if they see any concerns.
Otherwise, no further concerns from me.


with regards, pekon

------------------------
Powered by BigRock.com

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

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[pekon]

Hi Roger,

On Wednesday 03 September 2014 02:02 PM, Roger Quadros wrote:
> Hi Pekon,
>
> On 09/02/2014 10:02 PM, pekon wrote:
>> Hi Roger,
>>
>>
>> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
>>> NAND uses wait pin only to indicate device readiness after
>>> a block/page operation. It is not use to extend individual
>>> read/write cycle and so read/write wait pin monitoring must
>>> be disabled for NAND.
>>>
>> I think this is incorrect assumption. NAND framework allows
>> wait-pin monitoring at end of each read/write cycle. Please
>> refer following code in drivers/mtd/nand/nand_base.c
>>      @@ void nand_wait_ready(...)
>>
>> - nand_wait_ready() calls controller-driver specific call-back
>>    for chip->dev_ready().
>
> It is important to note that this NAND device ready mechanism is different from
> GPMC inter cycle wait state mechanism controlled by the read/write monitoring
> bits. The same WAIT pin is used in both the cases.
>
> For more details about NAND use case refer to
>
> AM437x TRM:
> Section: 9.1.3.3.12.2 NAND Device-Ready Pin
>
> below excerpt from there
> "To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring
> for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and
> GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0):
>

I re-read the AM437x TRM, and the section you mentioned above.

-----------------
*9.1.3.3.12.2 NAND Device-Ready Pin*
The NAND memory device provides a ready pin to indicate data 
availability after a block/page opening and to indicate that data 
programming is complete. The ready pin can be connected to one of the 
WAIT GPMC input pins; data read accesses must not be tried when the 
ready pin is sampled inactive (device is not ready) even if the 
associated chip-select WAITREADMONITORING bit field is set. The duration 
of the NAND device busy state after the block/page opening is so long 
(up to 50 μs) that accesses occurring when the ready pin is sampled 
inactive can stall GPMC access and eventually cause a system time-out.
If a read access to a NAND flash is done using the wait monitoring mode, 
the device is blocked during a page opening, and so is the GPMC. If the 
correct settings are used, other chip-selects can be used while
the memory processes the page opening command.
...
-----------------

It's clearly written that wait-pin monitoring is used for read/write 
(programs) access, and GPMC is blocked till wait signal is asserted 
during reads.
Also, on NAND there can be no read/write access except at page-level
so wait-pin monitoring is implicitly related to read/write accesses.
However, whether you use it or not is purely user's choice, but it
has performance impact.

You are probably seeing timeout condition when enabling wait-pin
monitoring, and this can be due to multiple reasons like;
(1) incorrect pin-mux configuration (like directions, pull-up etc)
(2) incorrect board-level pull-up
(3) incorrect driver setting, like though wait-pin is enabled but
     wrong wait-pin is being monitored.

I request you to fix this instead of disabling it completely,
as you should see significant NAND throughput increase once this
feature works correctly.

>>
>> - chip->dev_ready in-case of OMAP NAND drivers is set in
>>    drivers/mtd/nand/omap2.c  during probe.
>>      if (pdata->dev_ready) {
>>          nand_chip->dev_ready = omap_dev_ready;
>>          nand_chip->chip_delay = 0;
>>      }
>>
>> Problem is we don't set pdata->dev_ready correctly as part
>> of platform-data dring GPMC initialization. This was what my
>> earlier patch for wait-pin monitoring about. But it was a
>> quick fix for NAND devices.
>>
>> So, I suggest to fix wait-pin monitoring instead of de-scoping
>> it from DTS as wait-pin monitoring should boast the NAND
>> performance significantly.
>> (please see if you can find an old mail thread which had some
>> good feedbacks from Ezequiel and Javier about wait-pin monitoring).
>
> This is to get the device ready mechanism work and has nothing to do with
> GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
> interrupt based on the WAIT pin polarity.
>
> To monitor NAND device ready status
> from TRM
> "-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
> OR
> -Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits)"
>
>>
>> [...]
>>
>>> This patch also gets rid of the below warning when NAND is
>>> accessed for the first time.
>>>
>>> omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
>>>
>> Can you debug this further.
>> This warning probably comes when driver tries to access some
>> "reserved" addresses. Or violate read/write bits.
>
> It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling the
> wait monitoring gets rid of this error. I don't understand what else I should debug

I'm not sure how a NAND or GPMC feature can cause omap_l3_noc: L3 
application error ?
But now as I re-read the text, its probably the L3 interconnect timeout
error due to no response from GPMC. There is a timer in L3 which 
monitors if the L3 interconnect is stalled/blocked waiting for response
from a target. I think it's that timer which is getting timeout. (but 
just my guess).


 > and why.
 >
As there were number of users on linux-mtd list wanted to use
NAND wait-pin monitoring on OMAP devices, so I have just looped
them if they see any concerns.
Otherwise, no further concerns from me.


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [140902 06:57]:
> Hi Tony,
> 
> These are some of the issues I found while testing v3.17-rc3.
> 
> - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
> BCH16 instead of BCH8.
> 
> - Wrong read/write wait pin monitoring setting used for NAND
> resulting in "L3 application error" debug message on console.
> 
> - Pin conflict issue on am43x EPOS evm with QSPI and NAND.

Thanks applying into omap-for-v3.17/fixes-v2.

Tony
 
> Patches are available at
> git@github.com:rogerq/linux.git
> * [new branch]      for-v3.17/gpmc-fixes
> 
> cheers,
> -roger
> 
> Roger Quadros (6):
>   ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
>   ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
>   ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
>   ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring
>   ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w
>     monitoring
>   ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with
>     GPMC-NAND
> 
>  arch/arm/boot/dts/am437x-gp-evm.dts  | 4 +---
>  arch/arm/boot/dts/am43x-epos-evm.dts | 9 ++++-----
>  arch/arm/mach-omap2/gpmc.c           | 7 +++----
>  3 files changed, 8 insertions(+), 12 deletions(-)
> 
> -- 
> 1.8.3.2
> 

Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140903 14:41]:
> * Roger Quadros <rogerq@ti.com> [140902 06:57]:
> > Hi Tony,
> > 
> > These are some of the issues I found while testing v3.17-rc3.
> > 
> > - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
> > BCH16 instead of BCH8.
> > 
> > - Wrong read/write wait pin monitoring setting used for NAND
> > resulting in "L3 application error" debug message on console.
> > 
> > - Pin conflict issue on am43x EPOS evm with QSPI and NAND.
> 
> Thanks applying into omap-for-v3.17/fixes-v2.

Sorry replied to the wrong thread, this series still seems
to have some pending comments so not applying this one.

Regards,

Tony

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[Roger Quadros]

+ Sekhar.

Hi Pekon,

On 09/03/2014 08:29 PM, pekon wrote:
> Hi Roger,
> 
> On Wednesday 03 September 2014 02:02 PM, Roger Quadros wrote:
>> Hi Pekon,
>>
>> On 09/02/2014 10:02 PM, pekon wrote:
>>> Hi Roger,
>>>
>>>
>>> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote:
>>>> NAND uses wait pin only to indicate device readiness after
>>>> a block/page operation. It is not use to extend individual
>>>> read/write cycle and so read/write wait pin monitoring must
>>>> be disabled for NAND.
>>>>
>>> I think this is incorrect assumption. NAND framework allows
>>> wait-pin monitoring at end of each read/write cycle. Please
>>> refer following code in drivers/mtd/nand/nand_base.c
>>>      @@ void nand_wait_ready(...)
>>>
>>> - nand_wait_ready() calls controller-driver specific call-back
>>>    for chip->dev_ready().
>>
>> It is important to note that this NAND device ready mechanism is different from
>> GPMC inter cycle wait state mechanism controlled by the read/write monitoring
>> bits. The same WAIT pin is used in both the cases.
>>
>> For more details about NAND use case refer to
>>
>> AM437x TRM:
>> Section: 9.1.3.3.12.2 NAND Device-Ready Pin
>>
>> below excerpt from there
>> "To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring
>> for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and
>> GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0):
>>
> 
> I re-read the AM437x TRM, and the section you mentioned above.
> 
> -----------------
> *9.1.3.3.12.2 NAND Device-Ready Pin*
> The NAND memory device provides a ready pin to indicate data availability after a block/page opening and to indicate that data programming is complete. The ready pin can be connected to one of the WAIT GPMC input pins; data read accesses must not be tried when the ready pin is sampled inactive (device is not ready) even if the associated chip-select WAITREADMONITORING bit field is set. The duration of the NAND device busy state after the block/page opening is so long (up to 50 μs) that accesses occurring when the ready pin is sampled inactive can stall GPMC access and eventually cause a system time-out.
> If a read access to a NAND flash is done using the wait monitoring mode, the device is blocked during a page opening, and so is the GPMC. If the correct settings are used, other chip-selects can be used while
> the memory processes the page opening command.
> ...
> -----------------
> 
> It's clearly written that wait-pin monitoring is used for read/write (programs) access, and GPMC is blocked till wait signal is asserted during reads.

And you cut out the most important part where it says keep read/write wait monitoring disabled for NAND.

pasting again here.

"To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring
for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and
GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0 and use one of the following methods
instead:
•Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
•Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits).

Even if the READWAITMONITORING bit is not set, the external memory nR/B pinstatus is captured in the
programmed WAIT bit in the GPMC_STS register.
The READWAITMONITORING bit method must be used for other memories than NAND flash, if they require the use of a WAIT signal."

> Also, on NAND there can be no read/write access except at page-level

And how are command/address inputs sent? ;)

> so wait-pin monitoring is implicitly related to read/write accesses.
> However, whether you use it or not is purely user's choice, but it
> has performance impact.

I don't know what you are talking about. I have tried to explain many times but you fail to understand.
Nand device ready pin is not same as the wait pin used on other memories where it is used to
extend each read/write cycle (by inserting wait state). It is only used to indicate that
the NAND device is busy during a block/page operation, so that new commands won't be sent to it
by the host processor. This is different from TI GPMC wait monitoring. You have to monitor this
device ready pin out of band like polling the status bit or using GPMC interrupt on wait pin transition.

Looks like you are getting confused because the same WAIT pin on the SoC is used to get this
device ready pin status into the SoC.

> 
> You are probably seeing timeout condition when enabling wait-pin
> monitoring, and this can be due to multiple reasons like;
> (1) incorrect pin-mux configuration (like directions, pull-up etc)
> (2) incorrect board-level pull-up
> (3) incorrect driver setting, like though wait-pin is enabled but
>     wrong wait-pin is being monitored.

No for all the 3.

> 
> I request you to fix this instead of disabling it completely,
> as you should see significant NAND throughput increase once this
> feature works correctly.
> 
>>>
>>> - chip->dev_ready in-case of OMAP NAND drivers is set in
>>>    drivers/mtd/nand/omap2.c  during probe.
>>>      if (pdata->dev_ready) {
>>>          nand_chip->dev_ready = omap_dev_ready;
>>>          nand_chip->chip_delay = 0;
>>>      }
>>>
>>> Problem is we don't set pdata->dev_ready correctly as part
>>> of platform-data dring GPMC initialization. This was what my
>>> earlier patch for wait-pin monitoring about. But it was a
>>> quick fix for NAND devices.
>>>
>>> So, I suggest to fix wait-pin monitoring instead of de-scoping
>>> it from DTS as wait-pin monitoring should boast the NAND
>>> performance significantly.
>>> (please see if you can find an old mail thread which had some
>>> good feedbacks from Ezequiel and Javier about wait-pin monitoring).

This patch is for the 3.17 bug fix cycle. Implementing NAND device ready mechanism
is a new feature (for DT case) and I will work on it for future versions.

Also I'm not de-scoping wait-pin (or more correctly device ready) mechanism for NAND.
The dts file still contains "wait-pin = <0>" property. This will be used to
monitor the NAND device ready status via GPMC status or GPMC interrupt.
But this is not for 3.17 bug fix cycle.

see omap_dev_ready()
http://lxr.free-electrons.com/source/drivers/mtd/nand/omap2.c#L1025

>>
>> This is to get the device ready mechanism work and has nothing to do with
>> GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
>> interrupt based on the WAIT pin polarity.
>>
>> To monitor NAND device ready status
>> from TRM
>> "-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
>> OR
>> -Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits)"
>>
>>>
>>> [...]
>>>
>>>> This patch also gets rid of the below warning when NAND is
>>>> accessed for the first time.
>>>>
>>>> omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
>>>>
>>> Can you debug this further.
>>> This warning probably comes when driver tries to access some
>>> "reserved" addresses. Or violate read/write bits.
>>
>> It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling the
>> wait monitoring gets rid of this error. I don't understand what else I should debug
> 
> I'm not sure how a NAND or GPMC feature can cause omap_l3_noc: L3 application error ?
> But now as I re-read the text, its probably the L3 interconnect timeout
> error due to no response from GPMC. There is a timer in L3 which monitors if the L3 interconnect is stalled/blocked waiting for response
> from a target. I think it's that timer which is getting timeout. (but just my guess).

Yes that indeed is the case.

> 
> 
>> and why.
>>
> As there were number of users on linux-mtd list wanted to use
> NAND wait-pin monitoring on OMAP devices, so I have just looped
> them if they see any concerns.


It is called NAND device ready mechanism (not wait-pin monitoring). It never worked till now with DT so it is a new feature.

> Otherwise, no further concerns from me.

Thanks.

cheers,
-roger

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[pekon]

On Thursday 04 September 2014 03:16 PM, Roger Quadros wrote:

[...]

>
> This patch is for the 3.17 bug fix cycle. Implementing NAND device ready mechanism
> is a new feature (for DT case) and I will work on it for future versions.
>
> Also I'm not de-scoping wait-pin (or more correctly device ready) mechanism for NAND.
> The dts file still contains "wait-pin = <0>" property. This will be used to
> monitor the NAND device ready status via GPMC status or GPMC interrupt.
> But this is not for 3.17 bug fix cycle.
>

Ok Thanks, that good to know. So for this whole series

Reviewed-by: Pekon Gupta <pekon@pek-sem.com>


with regards, pekon

------------------------
Powered by BigRock.com


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring

[pekon]

On Thursday 04 September 2014 03:16 PM, Roger Quadros wrote:

[...]

>
> This patch is for the 3.17 bug fix cycle. Implementing NAND device ready mechanism
> is a new feature (for DT case) and I will work on it for future versions.
>
> Also I'm not de-scoping wait-pin (or more correctly device ready) mechanism for NAND.
> The dts file still contains "wait-pin = <0>" property. This will be used to
> monitor the NAND device ready status via GPMC status or GPMC interrupt.
> But this is not for 3.17 bug fix cycle.
>

Ok Thanks, that good to know. So for this whole series

Reviewed-by: Pekon Gupta <pekon@pek-sem.com>


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[pekon]

Hi Tony,

On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140903 14:41]:
>> * Roger Quadros <rogerq@ti.com> [140902 06:57]:
>>> Hi Tony,
>>>
>>> These are some of the issues I found while testing v3.17-rc3.
>>>
>>> - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
>>> BCH16 instead of BCH8.
>>>
>>> - Wrong read/write wait pin monitoring setting used for NAND
>>> resulting in "L3 application error" debug message on console.
>>>
>>> - Pin conflict issue on am43x EPOS evm with QSPI and NAND.
>>
>> Thanks applying into omap-for-v3.17/fixes-v2.
>
> Sorry replied to the wrong thread, this series still seems
> to have some pending comments so not applying this one.
>
Only [Patch 3/6] had some pending comments, but after Roger's
clarification there are no further comments from me. So for
entire series ..

Reviewed-by: Pekon Gupta <pekon@pek-sem.com>


with regards, pekon

------------------------
Powered by BigRock.com

Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[Tony Lindgren]

* pekon <pekon@pek-sem.com> [140904 12:01]:
> Hi Tony,
> 
> On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote:
> >* Tony Lindgren <tony@atomide.com> [140903 14:41]:
> >>* Roger Quadros <rogerq@ti.com> [140902 06:57]:
> >>>Hi Tony,
> >>>
> >>>These are some of the issues I found while testing v3.17-rc3.
> >>>
> >>>- Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
> >>>BCH16 instead of BCH8.
> >>>
> >>>- Wrong read/write wait pin monitoring setting used for NAND
> >>>resulting in "L3 application error" debug message on console.
> >>>
> >>>- Pin conflict issue on am43x EPOS evm with QSPI and NAND.
> >>
> >>Thanks applying into omap-for-v3.17/fixes-v2.
> >
> >Sorry replied to the wrong thread, this series still seems
> >to have some pending comments so not applying this one.
> >
> Only [Patch 3/6] had some pending comments, but after Roger's
> clarification there are no further comments from me. So for
> entire series ..
> 
> Reviewed-by: Pekon Gupta <pekon@pek-sem.com>

OK thanks will apply all into omap-for-v3.17/fixes-v2.

Regards,

Tony

Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17

[Roger Quadros]

On 09/04/2014 10:00 PM, pekon wrote:
> Hi Tony,
> 
> On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote:
>> * Tony Lindgren <tony@atomide.com> [140903 14:41]:
>>> * Roger Quadros <rogerq@ti.com> [140902 06:57]:
>>>> Hi Tony,
>>>>
>>>> These are some of the issues I found while testing v3.17-rc3.
>>>>
>>>> - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use
>>>> BCH16 instead of BCH8.
>>>>
>>>> - Wrong read/write wait pin monitoring setting used for NAND
>>>> resulting in "L3 application error" debug message on console.
>>>>
>>>> - Pin conflict issue on am43x EPOS evm with QSPI and NAND.
>>>
>>> Thanks applying into omap-for-v3.17/fixes-v2.
>>
>> Sorry replied to the wrong thread, this series still seems
>> to have some pending comments so not applying this one.
>>
> Only [Patch 3/6] had some pending comments, but after Roger's
> clarification there are no further comments from me. So for
> entire series ..
> 
> Reviewed-by: Pekon Gupta <pekon@pek-sem.com>

Thanks for the review Pekon.

cheers,
-roger