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
next prev parent 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.