linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dedekind1@gmail.com (Artem Bityutskiy)
To: linux-arm-kernel@lists.infradead.org
Subject: NAND: failure reported with mtd_oobtest(read delay violated)
Date: Fri, 13 Nov 2009 10:37:02 +0200	[thread overview]
Message-ID: <1258101422.21596.1191.camel@localhost> (raw)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC35608702FA5CC012@dbde02.ent.ti.com>

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 (????? ????????)

      parent reply	other threads:[~2009-11-13  8:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1258101422.21596.1191.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).