* NAND: failure reported with mtd_oobtest(read delay violated)
@ 2009-11-12 15:58 Govindarajan, Sriramakrishnan
2009-11-12 20:59 ` Russell King - ARM Linux
2009-11-13 8:37 ` Artem Bityutskiy
0 siblings, 2 replies; 4+ messages in thread
From: Govindarajan, Sriramakrishnan @ 2009-11-12 15:58 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On the OMAP3 EVM platform we are seeing failures when we run the mtd_oobtest repeatedly (overnight). Usually the failures are reported after 40-45 iterations.
Further analysis with logic analyzer seems to indicate that for the specific instance where failure is observed, the time delay between dispatching the READ0 command and the start of read operation is violated. (udelay loop would start even before the write is reflected on the HW)
OMAP3EVM implementation relies on command delay(chip_delay set to 50ms) and doesn't use wait pin monitoring. By adding a data memory barrier dmb() instruction right after the command phase the issue seems to be resolved.
Have we seen similar behavior on other platforms that rely on command delay and do we specifically require a dmb() after the command is written?
DIFF Details:(will post this a patch once I hear your review comments)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 2211386..8df3780 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -651,6 +651,7 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
chip->cmd_ctrl(mtd, NAND_CMD_NONE,
NAND_NCE | NAND_CTRL_CHANGE);
+ dmb();
/* This applies to read commands */
default:
Regards
Sriram
^ permalink raw reply related [flat|nested] 4+ messages in thread
* NAND: failure reported with mtd_oobtest(read delay violated)
2009-11-12 15:58 NAND: failure reported with mtd_oobtest(read delay violated) Govindarajan, Sriramakrishnan
@ 2009-11-12 20:59 ` Russell King - ARM Linux
2009-11-13 11:04 ` Govindarajan, Sriramakrishnan
2009-11-13 8:37 ` Artem Bityutskiy
1 sibling, 1 reply; 4+ messages in thread
From: Russell King - ARM Linux @ 2009-11-12 20:59 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Nov 12, 2009 at 09:28:58PM +0530, Govindarajan, Sriramakrishnan wrote:
> OMAP3EVM implementation relies on command delay(chip_delay set to 50ms)
> and doesn't use wait pin monitoring. By adding a data memory barrier
> dmb() instruction right after the command phase the issue seems to be
> resolved.
Clearly adding ARM specific calls into generic code is the wrong thing
to do... Why can't this dmb() go into whatever NAND driver OMAP is using?
^ permalink raw reply [flat|nested] 4+ messages in thread
* NAND: failure reported with mtd_oobtest(read delay violated)
2009-11-12 15:58 NAND: failure reported with mtd_oobtest(read delay violated) Govindarajan, Sriramakrishnan
2009-11-12 20:59 ` Russell King - ARM Linux
@ 2009-11-13 8:37 ` Artem Bityutskiy
1 sibling, 0 replies; 4+ messages in thread
From: Artem Bityutskiy @ 2009-11-13 8:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2009-11-12 at 21:28 +0530, Govindarajan, Sriramakrishnan wrote:
> Hello,
> On the OMAP3 EVM platform we are seeing failures when we run the mtd_oobtest repeatedly (overnight). Usually the failures are reported after 40-45 iterations.
>
> Further analysis with logic analyzer seems to indicate that for the specific instance where failure is observed, the time delay between dispatching the READ0 command and the start of read operation is violated. (udelay loop would start even before the write is reflected on the HW)
>
> OMAP3EVM implementation relies on command delay(chip_delay set to 50ms) and doesn't use wait pin monitoring. By adding a data memory barrier dmb() instruction right after the command phase the issue seems to be resolved.
>
> Have we seen similar behavior on other platforms that rely on command delay and do we specifically require a dmb() after the command is written?
>
> DIFF Details:(will post this a patch once I hear your review comments)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 2211386..8df3780 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -651,6 +651,7 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
> NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
> chip->cmd_ctrl(mtd, NAND_CMD_NONE,
> NAND_NCE | NAND_CTRL_CHANGE);
> + dmb();
Did you try using 'wmb()' instead? Not 100% sure, but it looks like the
barrier you need. However, if you read
'Documentation/memory-barriers.txt', you will probably find the right
way to go.
--
Best Regards,
Artem Bityutskiy (????? ????????)
^ permalink raw reply [flat|nested] 4+ messages in thread
* NAND: failure reported with mtd_oobtest(read delay violated)
2009-11-12 20:59 ` Russell King - ARM Linux
@ 2009-11-13 11:04 ` Govindarajan, Sriramakrishnan
0 siblings, 0 replies; 4+ messages in thread
From: Govindarajan, Sriramakrishnan @ 2009-11-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Friday, November 13, 2009 2:29 AM
> To: Govindarajan, Sriramakrishnan
> Cc: 'linux-mtd at lists.infradead.org'; 'linux-arm-
> kernel at lists.infradead.org'
> Subject: Re: NAND: failure reported with mtd_oobtest(read delay violated)
>
> On Thu, Nov 12, 2009 at 09:28:58PM +0530, Govindarajan, Sriramakrishnan
> wrote:
> > OMAP3EVM implementation relies on command delay(chip_delay set to 50ms)
> > and doesn't use wait pin monitoring. By adding a data memory barrier
> > dmb() instruction right after the command phase the issue seems to be
> > resolved.
>
> Clearly adding ARM specific calls into generic code is the wrong thing
> to do... Why can't this dmb() go into whatever NAND driver OMAP is using?
Russell, thanks for the comments. But I posed this question
assuming that this a more generic problem that may show up on other
rchitectures/platforms where the NAND driver is using delay loop
instead of wait pin monitoring. Is there a more generic alternative?
Also, the time delay is implemented in the nand(nand_base.c) core file itself - there aren't platform specific hooks for us to override/customize for OMAP specifically. I am also looking at the other alternative of using wait pin monitoring instead
Regards
Sriram
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-11-13 11:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-12 15:58 NAND: failure reported with mtd_oobtest(read delay violated) Govindarajan, Sriramakrishnan
2009-11-12 20:59 ` Russell King - ARM Linux
2009-11-13 11:04 ` Govindarajan, Sriramakrishnan
2009-11-13 8:37 ` Artem Bityutskiy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).