From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Changming Chen (changmingche)" <changmingche@micron.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"Youxin He \(youxinhe\)" <youxinhe@micron.com>,
"Frank Liu \(frankliu\)" <frankliu@micron.com>
Subject: Re: Patch MTD: increase time out value for buffer program
Date: Wed, 27 Jun 2012 06:27:14 +0300 [thread overview]
Message-ID: <1340767634.2317.1.camel@koala> (raw)
In-Reply-To: <1340726334.3119.150.camel@sauron.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4432 bytes --]
On Tue, 2012-06-26 at 18:58 +0300, Artem Bityutskiy wrote:
> On Wed, 2012-06-13 at 04:29 +0000, Changming Chen (changmingche) wrote:
> > The time out value(1ms:typical HZ defined smaller than 1000) defined for function "do_write_buffer" in "cfi_cmdset_0002.c" is not enough. Because the enlargement of buffer size, much time will cost for buffer program. It's has risk that time out will be triggered before buffer program finished and make misjudge for buffer program. we suggest that 4ms is more appropriate compare to 1ms. This change has no impact of program performance.
> >
> > diff --git a/a/drivers/mtd/chips/cfi_cmdset_0002.c b/b/drivers/mtd/chips/cfi_cmd
> > index 9d93c45..7da8fca 100755
> > --- a/a/drivers/mtd/chips/cfi_cmdset_0002.c
> > +++ b/b/drivers/mtd/chips/cfi_cmdset_0002.c
> > @@ -1312,7 +1312,7 @@ static int __xipram do_write_buffer(struct map_info *map,
> > struct cfi_private *cfi = map->fldrv_priv;
> > unsigned long timeo = jiffies + HZ;
> > /* see comments in do_write_oneword() regarding uWriteTimeo. */
> > - unsigned long uWriteTimeout = ( HZ / 1000 ) + 1;
> > + unsigned long uWriteTimeout = ( HZ / 1000 ) + 4;
>
> No, sorry, this is not a fix, this is a band-aid. The whole HZ/1000
> thing is broken. You should not use HZ at all. For this driver it looks
> like you should use ' schedule_timeout()' with the right timout instead
> of 'schedule()' and get rid of all the HZ and jiffies stuff.
What I meant is something like this (not tested, not even compiled),
which should also be done in many other places in this file:
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 22d0493..8ce3b44 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -48,6 +48,9 @@
#define SST49LF008A 0x005a
#define AT49BV6416 0x00d6
+/* Write operation timeout, ms */
+#define WRITE_TIEMEOUT 2
+
static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
@@ -1143,17 +1146,6 @@ static int cfi_amdstd_secsi_read (struct mtd_info *mtd, loff_t from, size_t len,
static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip, unsigned long adr, map_word datum)
{
struct cfi_private *cfi = map->fldrv_priv;
- unsigned long timeo = jiffies + HZ;
- /*
- * We use a 1ms + 1 jiffies generic timeout for writes (most devices
- * have a max write time of a few hundreds usec). However, we should
- * use the maximum timeout value given by the chip at probe time
- * instead. Unfortunately, struct flchip does have a field for
- * maximum timeout, only for typical which can be far too short
- * depending of the conditions. The ' + 1' is to avoid having a
- * timeout of 0 jiffies if HZ is smaller than 1000.
- */
- unsigned long uWriteTimeout = ( HZ / 1000 ) + 1;
int ret = 0;
map_word oldd;
int retry_cnt = 0;
@@ -1197,8 +1189,6 @@ static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip,
adr, map_bankwidth(map),
chip->word_write_time);
- /* See comment above for timeout value. */
- timeo = jiffies + uWriteTimeout;
for (;;) {
if (chip->state != FL_WRITING) {
/* Someone's suspended the write. Sleep */
@@ -1207,20 +1197,18 @@ static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip,
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(&chip->wq, &wait);
mutex_unlock(&chip->mutex);
- schedule();
+ ret = schedule_timeout(msecs_to_jiffies(WRITE_TIEMEOUT));
remove_wait_queue(&chip->wq, &wait);
- timeo = jiffies + (HZ / 2); /* FIXME */
mutex_lock(&chip->mutex);
+ if (!ret) {
+ xip_enable(map, chip, adr);
+ printk(KERN_WARNING "MTD %s(): software timeout\n", __func__);
+ xip_disable(map, chip, adr);
+ break;
+ }
continue;
}
- if (time_after(jiffies, timeo) && !chip_ready(map, adr)){
- xip_enable(map, chip, adr);
- printk(KERN_WARNING "MTD %s(): software timeout\n", __func__);
- xip_disable(map, chip, adr);
- break;
- }
-
if (chip_ready(map, adr))
break;
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-27 3:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.0.1338988276.11201.linux-mtd@lists.infradead.org>
2012-06-13 4:29 ` Patch MTD: increase time out value for buffer program Changming Chen (changmingche)
2012-06-26 15:58 ` Artem Bityutskiy
2012-06-27 3:27 ` Artem Bityutskiy [this message]
2012-06-27 5:23 ` Youxin He (youxinhe)
2012-06-27 10:33 ` Artem Bityutskiy
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=1340767634.2317.1.camel@koala \
--to=dedekind1@gmail.com \
--cc=changmingche@micron.com \
--cc=dwmw2@infradead.org \
--cc=frankliu@micron.com \
--cc=linux-mtd@lists.infradead.org \
--cc=youxinhe@micron.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox