public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

      reply	other threads:[~2006-07-26  6:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-16 17:23 [PATCH] PNX8550 NAND flash driver Vladimir A. Barinov
2005-12-20 14:28 ` Vladimir A. Barinov
2006-01-12 18:24 ` Todd Poynor
2006-02-14 13:00   ` Vladimir A. Barinov
2006-02-22  0:57     ` Todd Poynor
2006-07-10  9:53     ` Thomas Gleixner
2006-07-25 18:34       ` Jurgen
2006-07-26  7:02         ` Thomas Gleixner [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox