All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Wu <josh.wu@atmel.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: hongxu.cn@gmail.com, nicolas.ferre@atmel.com,
	linux-mtd@lists.infradead.org, ivan.djelic@parrot.com,
	plagnioj@jcrosoft.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v9 3/3] MTD: at91: atmel_nand: Update driver to support Programmable Multibit ECC controller
Date: Mon, 28 May 2012 16:43:41 +0800	[thread overview]
Message-ID: <4FC33ABD.7020405@atmel.com> (raw)
In-Reply-To: <1338123053.19389.9.camel@koala>

On 5/27/2012 8:50 PM, Artem Bityutskiy wrote:
> On Sat, 2012-05-26 at 21:24 +0800, Josh Wu wrote:
>> +       while ((pmecc_readl_relaxed(host->ecc, SR)&  PMECC_SR_BUSY)) {
>> +               if (unlikely(timeout_count++>  PMECC_MAX_TIMEOUT_COUNT)) {
>> +                       dev_err(host->dev, "PMECC: Timeout to get ECC value.\n");
>> +                       return; /* Time out */
> How this error is communicated then up the the user?

If this error happened, that should mean the PMECC is not configurated 
correctly. I think I only I can do is that prompt to user and then call 
BUG() here.

>
>> +               }
>> +               cpu_relax();
>> +       }
> I see this pattern all over the place - why people consider it reliable?
> Is this code guaranteed to run on the same CPU?
>
> Why not to use loops_per_jiffie * msecs_to_jiffies(TIMOUT) instead to
> calculate how many iterations to do? Yes, due to HW register reading and
> cpu_relax() the real timeout will be larger, but this is about error
> anyway, so it does not hurt to iterate longer?
>

I will fix that in next version. thanks.

Best Regards,
Josh Wu

WARNING: multiple messages have this Message-ID (diff)
From: josh.wu@atmel.com (Josh Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 3/3] MTD: at91: atmel_nand: Update driver to support Programmable Multibit ECC controller
Date: Mon, 28 May 2012 16:43:41 +0800	[thread overview]
Message-ID: <4FC33ABD.7020405@atmel.com> (raw)
In-Reply-To: <1338123053.19389.9.camel@koala>

On 5/27/2012 8:50 PM, Artem Bityutskiy wrote:
> On Sat, 2012-05-26 at 21:24 +0800, Josh Wu wrote:
>> +       while ((pmecc_readl_relaxed(host->ecc, SR)&  PMECC_SR_BUSY)) {
>> +               if (unlikely(timeout_count++>  PMECC_MAX_TIMEOUT_COUNT)) {
>> +                       dev_err(host->dev, "PMECC: Timeout to get ECC value.\n");
>> +                       return; /* Time out */
> How this error is communicated then up the the user?

If this error happened, that should mean the PMECC is not configurated 
correctly. I think I only I can do is that prompt to user and then call 
BUG() here.

>
>> +               }
>> +               cpu_relax();
>> +       }
> I see this pattern all over the place - why people consider it reliable?
> Is this code guaranteed to run on the same CPU?
>
> Why not to use loops_per_jiffie * msecs_to_jiffies(TIMOUT) instead to
> calculate how many iterations to do? Yes, due to HW register reading and
> cpu_relax() the real timeout will be larger, but this is about error
> anyway, so it does not hurt to iterate longer?
>

I will fix that in next version. thanks.

Best Regards,
Josh Wu

  reply	other threads:[~2012-05-28  8:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-26 13:24 [PATCH v9 0/3] MTD: at91: Add PMECC support for at91 nand flash driver Josh Wu
2012-05-26 13:24 ` Josh Wu
2012-05-26 13:24 ` [PATCH v9 1/3] MTD: at91: extract hw ecc initialization to one function and use relaxed read/write Josh Wu
2012-05-26 13:24   ` Josh Wu
2012-05-27 12:44   ` Artem Bityutskiy
2012-05-27 12:44     ` Artem Bityutskiy
2012-05-28  8:50     ` Josh Wu
2012-05-28  8:50       ` Josh Wu
2012-05-26 13:24 ` [PATCH v9 2/3] MTD: at91: add dt parameters for PMECC Josh Wu
2012-05-26 13:24   ` Josh Wu
2012-05-26 13:24 ` [PATCH v9 3/3] MTD: at91: atmel_nand: Update driver to support Programmable Multibit ECC controller Josh Wu
2012-05-26 13:24   ` Josh Wu
2012-05-27 12:50   ` Artem Bityutskiy
2012-05-27 12:50     ` Artem Bityutskiy
2012-05-28  8:43     ` Josh Wu [this message]
2012-05-28  8:43       ` Josh Wu
2012-05-28  6:58   ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-28  6:58     ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-28  8:34     ` Josh Wu
2012-05-28  8:34       ` Josh Wu
2012-05-29 16:01       ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-29 16:01         ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-28  6:39 ` [PATCH v9 0/3] MTD: at91: Add PMECC support for at91 nand flash driver Jean-Christophe PLAGNIOL-VILLARD
2012-05-28  6:39   ` Jean-Christophe PLAGNIOL-VILLARD

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=4FC33ABD.7020405@atmel.com \
    --to=josh.wu@atmel.com \
    --cc=dedekind1@gmail.com \
    --cc=hongxu.cn@gmail.com \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.