All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v2 05/10] mtd: rawnand: denali: use more precise timeout for NAND_OP_WAITRDT_INSTR
Date: Mon, 4 Mar 2019 09:43:46 +0100	[thread overview]
Message-ID: <20190304094346.3b62e6cd@xps13> (raw)
In-Reply-To: <1549955582-30346-6-git-send-email-yamada.masahiro@socionext.com>

Hi Masahiro,

Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Feb
2019 16:12:57 +0900:

> Currently, wait_for_completion_timeout() is always passed in the
> hard-coded msec_to_jiffies(1000). There is no specific reason for
> 1000 msec, but it was chosen to be long enough.
> 
> With the exec_op() conversion, NAND_OP_WAITRDY_INSTR provides more
> precise timeout value, depending on the preceding command. Let's use
> it (+ 100 msec) to bail out earlier in error case. The 100 msec extra
> is in case the heavy load on the system.
> 
> I am still keeping the hard-coded values for other higher level hooks
> such as page_read, page_write, etc. We know the value of tR, tPROG, but
> we have unknowledge about the data transfer speed of the DMA engine.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

I really am not convinced by this change. Please just define a timeout
big enough for most cases (1000 is okay) and use it systematically.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-mtd@lists.infradead.org,
	Boris Brezillon <bbrezillon@kernel.org>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v2 05/10] mtd: rawnand: denali: use more precise timeout for NAND_OP_WAITRDT_INSTR
Date: Mon, 4 Mar 2019 09:43:46 +0100	[thread overview]
Message-ID: <20190304094346.3b62e6cd@xps13> (raw)
In-Reply-To: <1549955582-30346-6-git-send-email-yamada.masahiro@socionext.com>

Hi Masahiro,

Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Tue, 12 Feb
2019 16:12:57 +0900:

> Currently, wait_for_completion_timeout() is always passed in the
> hard-coded msec_to_jiffies(1000). There is no specific reason for
> 1000 msec, but it was chosen to be long enough.
> 
> With the exec_op() conversion, NAND_OP_WAITRDY_INSTR provides more
> precise timeout value, depending on the preceding command. Let's use
> it (+ 100 msec) to bail out earlier in error case. The 100 msec extra
> is in case the heavy load on the system.
> 
> I am still keeping the hard-coded values for other higher level hooks
> such as page_read, page_write, etc. We know the value of tR, tPROG, but
> we have unknowledge about the data transfer speed of the DMA engine.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

I really am not convinced by this change. Please just define a timeout
big enough for most cases (1000 is okay) and use it systematically.

Thanks,
Miquèl

  reply	other threads:[~2019-03-04  8:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12  7:12 [PATCH v2 00/10] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups Masahiro Yamada
2019-02-12  7:12 ` Masahiro Yamada
2019-02-12  7:12 ` [PATCH v2 01/10] mtd: rawnand: denali: use nand_chip pointer more for internal functions Masahiro Yamada
2019-02-12  7:12   ` Masahiro Yamada
2019-02-12  7:12 ` [PATCH v2 02/10] mtd: rawnand: denali: refactor syndrome layout handling for raw access Masahiro Yamada
2019-02-12  7:12   ` Masahiro Yamada
2019-03-04  9:01   ` Miquel Raynal
2019-03-04  9:01     ` Miquel Raynal
2019-03-05  9:20     ` Masahiro Yamada
2019-03-05  9:20       ` Masahiro Yamada
2019-03-05 17:55       ` Miquel Raynal
2019-03-05 17:55         ` Miquel Raynal
2019-02-12  7:12 ` [PATCH v2 03/10] mtd: rawnand: denali: remove unneeded casts in denali_{read, write}_pio Masahiro Yamada
2019-02-12  7:12   ` [PATCH v2 03/10] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio Masahiro Yamada
2019-02-12  7:12 ` [PATCH v2 04/10] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks Masahiro Yamada
2019-02-12  7:12   ` Masahiro Yamada
2019-03-04  9:30   ` Miquel Raynal
2019-03-04  9:30     ` Miquel Raynal
2019-03-05  7:13     ` Masahiro Yamada
2019-03-05  7:13       ` Masahiro Yamada
2019-02-12  7:12 ` [PATCH v2 05/10] mtd: rawnand: denali: use more precise timeout for NAND_OP_WAITRDT_INSTR Masahiro Yamada
2019-02-12  7:12   ` Masahiro Yamada
2019-03-04  8:43   ` Miquel Raynal [this message]
2019-03-04  8:43     ` Miquel Raynal
2019-03-05  6:36     ` Masahiro Yamada
2019-03-05  6:36       ` Masahiro Yamada
2019-02-12  7:12 ` [PATCH v2 06/10] mtd: rawnand: denali: use bool type instead of int where appropriate Masahiro Yamada
2019-02-12  7:12   ` Masahiro Yamada
2019-02-12  7:12 ` [PATCH v2 07/10] mtd: rawnand: denali_pci: rename goto labels Masahiro Yamada
2019-02-12  7:12   ` Masahiro Yamada
2019-02-12  7:13 ` [PATCH v2 08/10] mtd: rawnand: denali: decouple controller and NAND chips Masahiro Yamada
2019-02-12  7:13   ` Masahiro Yamada
2019-02-18 20:01   ` Rob Herring
2019-02-18 20:01     ` Rob Herring
2019-02-12  7:13 ` [PATCH v2 09/10] mtd: rawnand: denali: remove DENALI_NR_BANKS macro Masahiro Yamada
2019-02-12  7:13   ` Masahiro Yamada
2019-02-12  7:13 ` [PATCH v2 10/10] mtd: rawnand: denali: clean up coding style Masahiro Yamada
2019-02-12  7:13   ` Masahiro Yamada

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=20190304094346.3b62e6cd@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    --cc=yamada.masahiro@socionext.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.