From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-mtd@lists.infradead.org,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Marek Vasut <marek.vasut@gmail.com>,
Brian Norris <computersforpeace@gmail.com>,
Richard Weinberger <richard@nod.at>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali
Date: Fri, 29 Sep 2017 16:29:35 +0200 [thread overview]
Message-ID: <20170929162935.597f4fb8@bbrezillon> (raw)
In-Reply-To: <CAK7LNASh=wLuyzGQEVQaNaNi=f-imKn1ybDx36L702c9WD_zvQ@mail.gmail.com>
On Fri, 29 Sep 2017 23:06:42 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> 2017-09-29 21:26 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
> > On Fri, 29 Sep 2017 19:38:38 +0900
> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >
> >> 1/2 : add NAND_WAIT_TWHR and nand_whr_delay().
> >> You can set this new flag if you want nand_command(_lp)
> >> to insert tWHR delay where needed.
> >>
> >> 2/2 : Fix Denali setup_data_interface.
> >> Boris' suggestion in v1 was a good reminder that
> >> made me realize tCCS was missing in the driver. Fix it now.
> >>
> >>
> >> Changes in v2:
> >> - Add nand_whr_delay() helper
> >> Wait for tWHR only for drivers that explicitly set NAND_WAIT_TWHR flag
> >> - newly added
> >>
> >> Masahiro Yamada (2):
> >> mtd: nand: wait for tWHR after NAND_CMD_STATUS / NAND_CMD_READID
> >
> > Hm, I thought you were introducing this to then use it in the denali
> > driver. Sorry, but I don't want to apply something that nobody needs.
> > If someone ever complains about a missing delay I'll point him to your
> > patch, but until then I'll keep the core unchanged.
>
>
> At first, I thought this was necessary for me,
> but I realized it was my misunderstanding.
>
>
> Please let me explain one more.
>
> See commit 3158fa0e739615769cc047d2428f30f4c3b6640e.
>
> Prior to that commit, READID waited for #R/B transition,
> it was wrong, so I fixed it.
>
> However, it dropped the delay completely.
> If somebody was implicitly relying on the delay of chip->dev_ready,
> the first byte might be read out before the valid data
> is available.
>
> This was motivation of v1, where inserted ndelay(200)
> unconditionally.
Okay. Anyway, this extra delay is activated with an opt-in flag (I
know, I'm the one who asked that), and noone set this flag in
chip->options, so, if there's a bug, it's still here even after
applying "mtd: nand: wait for tWHR after NAND_CMD_STATUS /
NAND_CMD_READID".
Honestly, I think all advanced controllers have the tWHR/tRHW timings
enforced in the HW logic (configurable through a reg). This leaves
basic controllers like the nand-gpio one, and even for these ones, the
delay between the chip->cmd_ctrl(ADDR) and chip->read_buf() calls is
probably long enough to hide the problem.
Note that I'm absolutely not against this patch, it's just that I'd
like to have a real user before merging this logic.
>
>
>
>
>
> >> mtd: nand: denali: fix setup_data_interface to meet tCCS delay
> >
> > This one is valid. I'll queue it to nand/next soon.
>
> If you drop 1/2, please let me do v3.
>
> V2 mentions NAND_WAIT_TWHR, this is strange.
>
Sure.
>
>
next prev parent reply other threads:[~2017-09-29 14:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 10:38 [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali Masahiro Yamada
2017-09-29 10:38 ` [PATCH v2 1/2] mtd: nand: wait for tWHR after NAND_CMD_STATUS / NAND_CMD_READID Masahiro Yamada
2017-09-29 10:38 ` [PATCH v2 2/2] mtd: nand: denali: fix setup_data_interface to meet tCCS delay Masahiro Yamada
2017-09-29 12:26 ` [PATCH v2 0/2] mtd: nand: wait for tWHR, and fix the setup_data_interface of Denali Boris Brezillon
2017-09-29 14:06 ` Masahiro Yamada
2017-09-29 14:29 ` Boris Brezillon [this message]
2017-09-29 14:33 ` Masahiro Yamada
2017-10-04 11:05 ` Marc Gonzalez
2017-10-13 8:34 ` Masahiro Yamada
2017-10-19 14:58 ` Marc Gonzalez
2017-10-25 17:04 ` 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=20170929162935.597f4fb8@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--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.