From: Thomas Gleixner <tglx@linutronix.de>
To: Jurgen <jurgen.parmentier@telenet.be>
Cc: linux-mtd@lists.infradead.org,
"Vladimir A. Barinov" <vbarinov@ru.mvista.com>,
Todd Poynor <tpoynor@mvista.com>,
linux-mips@linux-mips.org
Subject: Re: [PATCH] PNX8550 NAND flash driver
Date: Wed, 26 Jul 2006 09:02:53 +0200 [thread overview]
Message-ID: <1153897373.26845.77.camel@localhost.localdomain> (raw)
In-Reply-To: <44C66437.9030402@telenet.be>
On Tue, 2006-07-25 at 20:34 +0200, Jurgen wrote:
> Root cause of the problem lies within the early implementation of the
> low-level NAND commands. There was a severe risk that the PCI accesses
> were stalled because of a Read Status command for the NAND Flash. This
> Read Status was launched immediately after program/erase command. The
> hardware itself will wait for the Ready/Busy to be high and only then
> launch the Read Status command. This behavior caused timeout on the
> internal bus because PCI was unable to use the pins during this wait.
The hardware design is broken. Status Read can be requested while R/B is
low. See NAND datasheets.
> If this problem was coinciding with an ISR that tried to perform a PCI
> status register, then this PCI access could possibly timeout (because
> the PCI pins were already claimed for the XIO access that is depending
> on the RBY signal).
>
> Since the problem only showed during the PCI device ISR, the
> quick'n'dirty hack was to disable interrupts during XIO accesses.
>
> A better fix that should be available somewhere, is to improve the
> low-level NAND driver that will first check the status of the Ready/Busy
> line and only THEN launch the Read NAND Status command...
Thats not an improvement. Thats a hack for your broken hardware. You'd
burden the R/B check on every sane hardware out there.
You can add the R/B check to the chip->cmd_ctrl() function of your board
driver.
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Jurgen <jurgen.parmentier@telenet.be>
Cc: Todd Poynor <tpoynor@mvista.com>,
"Vladimir A. Barinov" <vbarinov@ru.mvista.com>,
linux-mtd@lists.infradead.org, linux-mips@linux-mips.org
Subject: Re: [PATCH] PNX8550 NAND flash driver
Date: Wed, 26 Jul 2006 09:02:53 +0200 [thread overview]
Message-ID: <1153897373.26845.77.camel@localhost.localdomain> (raw)
In-Reply-To: <44C66437.9030402@telenet.be>
On Tue, 2006-07-25 at 20:34 +0200, Jurgen wrote:
> Root cause of the problem lies within the early implementation of the
> low-level NAND commands. There was a severe risk that the PCI accesses
> were stalled because of a Read Status command for the NAND Flash. This
> Read Status was launched immediately after program/erase command. The
> hardware itself will wait for the Ready/Busy to be high and only then
> launch the Read Status command. This behavior caused timeout on the
> internal bus because PCI was unable to use the pins during this wait.
The hardware design is broken. Status Read can be requested while R/B is
low. See NAND datasheets.
> If this problem was coinciding with an ISR that tried to perform a PCI
> status register, then this PCI access could possibly timeout (because
> the PCI pins were already claimed for the XIO access that is depending
> on the RBY signal).
>
> Since the problem only showed during the PCI device ISR, the
> quick'n'dirty hack was to disable interrupts during XIO accesses.
>
> A better fix that should be available somewhere, is to improve the
> low-level NAND driver that will first check the status of the Ready/Busy
> line and only THEN launch the Read NAND Status command...
Thats not an improvement. Thats a hack for your broken hardware. You'd
burden the R/B check on every sane hardware out there.
You can add the R/B check to the chip->cmd_ctrl() function of your board
driver.
tglx
next prev parent reply other threads:[~2006-07-26 6:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-16 17:23 [PATCH] PNX8550 NAND flash driver Vladimir A. Barinov
2005-12-16 17:23 ` Vladimir A. Barinov
2005-12-20 14:27 ` Vladimir A. Barinov
2005-12-20 14:28 ` Vladimir A. Barinov
2006-01-12 18:24 ` Todd Poynor
2006-01-12 18:24 ` Todd Poynor
2006-02-14 12:59 ` Vladimir A. Barinov
2006-02-14 13:00 ` Vladimir A. Barinov
2006-02-22 0:57 ` Todd Poynor
2006-02-22 0:57 ` Todd Poynor
2006-07-10 9:53 ` Thomas Gleixner
2006-07-10 9:53 ` Thomas Gleixner
2006-07-25 18:34 ` Jurgen
2006-07-25 18:34 ` Jurgen
2006-07-26 7:02 ` Thomas Gleixner [this message]
2006-07-26 7:02 ` Thomas Gleixner
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=1153897373.26845.77.camel@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=jurgen.parmentier@telenet.be \
--cc=linux-mips@linux-mips.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tpoynor@mvista.com \
--cc=vbarinov@ru.mvista.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.