linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 06/11] mtd: rawnand: denali: use more precise timeout for NAND_OP_WAITRDT_INSTR
Date: Fri, 8 Feb 2019 23:05:11 +0100	[thread overview]
Message-ID: <20190208230511.5ee7c0f1@xps13> (raw)
In-Reply-To: <1549613335-30319-7-git-send-email-yamada.masahiro@socionext.com>

Hi Masahiro,

Masahiro Yamada <yamada.masahiro@socionext.com> wrote on Fri,  8 Feb
2019 17:08:50 +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 I just chose it 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 to bail out earlier in error case.

I'm not sure using 10ms instead of 1000ms is relevant in the below
cases, 10ms is rather short for an IRQ, if your system is under load
you might end up with a timeout, not because the right IRQ did not
fire, but because the handler was not executed yet (it happened to me
in the marvell_nand.c driver recently).

Also, would you mind using a define instead of hardcoding '1000'?
 
> 
> 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>


Thanks,
Miquèl

  reply	other threads:[~2019-02-08 22:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  8:08 [PATCH 00/11] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups Masahiro Yamada
2019-02-08  8:08 ` [PATCH 01/11] mtd: rawnand: denali: use nand_chip pointer more for internal functions Masahiro Yamada
2019-02-08  8:08 ` [PATCH 02/11] mtd: rawnand: denali: refactor syndrome layout handling for raw access Masahiro Yamada
2019-02-08  8:08 ` [PATCH 03/11] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio Masahiro Yamada
2019-02-08  8:08 ` [PATCH 04/11] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks Masahiro Yamada
2019-02-08  9:49   ` Masahiro Yamada
2019-02-08  8:08 ` [PATCH 05/11] mtd: rawnand: denali: rename irq_status to irq_stat Masahiro Yamada
2019-02-08 21:57   ` Miquel Raynal
2019-02-11  1:15     ` Masahiro Yamada
2019-02-08  8:08 ` [PATCH 06/11] mtd: rawnand: denali: use more precise timeout for NAND_OP_WAITRDT_INSTR Masahiro Yamada
2019-02-08 22:05   ` Miquel Raynal [this message]
2019-02-11  1:26     ` Masahiro Yamada
2019-02-08  8:08 ` [PATCH 07/11] mtd: rawnand: denali: use bool type instead of int where appropriate Masahiro Yamada
2019-02-08  9:23   ` Joe Perches
2019-02-08  9:33     ` Masahiro Yamada
2019-02-08 22:11     ` Miquel Raynal
2019-02-08  8:08 ` [PATCH 08/11] mtd: rawnand: denali_pci: rename goto labels Masahiro Yamada
2019-02-08  8:08 ` [PATCH 09/11] mtd: rawnand: denali: decouple controller and NAND chips Masahiro Yamada
2019-02-08  8:08 ` [PATCH 10/11] mtd: rawnand: denali: remove DENALI_NR_BANKS macro Masahiro Yamada
2019-02-08  8:08 ` [PATCH 11/11] mtd: rawnand: denali: clean up coding style Masahiro Yamada
2019-02-08 21:55 ` [PATCH 00/11] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups Miquel Raynal

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=20190208230511.5ee7c0f1@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 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).