From: Anton Vorontsov <avorontsov@ru•mvista.com>
To: Wolfgang Grandegger <wg@grandegger•com>
Cc: Linuxppc-dev@ozlabs•org
Subject: Re: [PATCH] [NAND] driver extension to support NAND on TQM85xx modules
Date: Wed, 4 Jun 2008 15:58:19 +0400 [thread overview]
Message-ID: <20080604115819.GA2281@polina.dev.rtsoft.ru> (raw)
In-Reply-To: <484665EC.30001@grandegger.com>
On Wed, Jun 04, 2008 at 11:52:44AM +0200, Wolfgang Grandegger wrote:
> Hi Anton,
>
> Anton Vorontsov wrote:
> > On Fri, May 30, 2008 at 08:36:32AM +0200, Wolfgang Grandegger wrote:
> >> This patch extends the FSL UPM NAND driver from Anton Vorontsov to
> >> support for the TQM85xx modules. Unfortunately, the hardware does
> >> not support the R/B pins of the NAND chip and therefore the specified
> >> maximum delay time must used. It therefore re-introduces the chip-delay
> >> property.
> >>
> >> Note: this patch is based on a patch Anton Vorontsov posted to this list:
> >> See http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html.
> >> It should show up mainstream soon.
> >
> > Personally, I like this patch. But OF people should approve "chip-delay"
> > property. Though, the whole UPM NAND bindings are in the air still.
> >
> >> --- a/include/linux/of_gpio.h
> >> +++ b/include/linux/of_gpio.h
> >> @@ -15,7 +15,7 @@
> >> #define __LINUX_OF_GPIO_H
> >>
> >> #include <linux/errno.h>
> >> -#include <asm/gpio.h>
> >> +#include <linux/gpio.h>
> >
> > This should be done separately.
>
> I have a technical question.
> Do you understand
Nope. According to NAND specs (Samsung and HYNIX), NAND should not
assert "busy" when we're sending seq data. We should poll the R/B pin
only after final "programm command".
But I saw a chip that was asserting it in seqinput phase anyway, and not
polling R/B did cause write errors. I can't recall if it was Samsung or
HYNIX chip, surely not ST Micro though.
> why the Linux NAND FSL UPM
> driver needs polling the R/B pin when writing out a sequence of bytes:
>
> static void fun_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
> {
> struct fsl_upm_nand *fun = to_fsl_upm_nand(mtd);
> int i;
>
> for (i = 0; i < len; i++) {
> out_8(fun->chip.IO_ADDR_W, buf[i]);
> fun_wait_rnb(fun);
> }
> }
>
> We do not need that in the corresponding U-Boot driver.
This is probably because I "optimized" the driver without further
testing it on other NAND chips.
> On my board (not
> having the R/B pin connected) I need a small delay of approx. 100 ns
> instead to get it working properly.
This proves that we indeed need some R/B waiting (or delays in case of
no R/B pin) in the write_buf.
p.s. Other possibility though is that MTD subsystem issues some
commands inbetween seqinput, for example, "read status" command is
permitted, but NAND should not assert R/B pin for this command anyway.
:-/
--
Anton Vorontsov
email: cbouatmailru@gmail•com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2008-06-04 11:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-30 6:36 [PATCH] [NAND] driver extension to support NAND on TQM85xx modules Wolfgang Grandegger
2008-05-30 12:50 ` Anton Vorontsov
2008-06-04 9:52 ` Wolfgang Grandegger
2008-06-04 11:58 ` Anton Vorontsov [this message]
2008-05-30 13:07 ` Kumar Gala
2008-05-30 13:57 ` Wolfgang Grandegger
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=20080604115819.GA2281@polina.dev.rtsoft.ru \
--to=avorontsov@ru$(echo .)mvista.com \
--cc=Linuxppc-dev@ozlabs$(echo .)org \
--cc=wg@grandegger$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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