public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Stephan Linke" <Stephan.Linke@epygi.de>
To: "Linux-Mtd" <linux-mtd@lists.infradead.org>
Subject: RE: using multile partitions on one NAND chip
Date: Wed, 24 Nov 2004 19:28:14 +0100	[thread overview]
Message-ID: <NGENJJFPMHGLPILEKKAMAEAGCFAA.Stephan.Linke@epygi.de> (raw)
In-Reply-To: <NGENJJFPMHGLPILEKKAMMEAFCFAA.Stephan.Linke@epygi.de>



> -----Original Message-----
> From: Stephan Linke [mailto:Stephan.Linke@epygi.de]
> Sent: Mittwoch, 24. November 2004 19:13
> To: tglx@linutronix.de
> Subject: RE: using multile partitions on one NAND chip
> 
> 
> Hi Thomas,
> 
> already noticed the spinlocks; thanks anyway.
> 
> On erase the chip is locked in nand_get_chip() and stays locked until 
> the ERASE2
> command has been send to the chip to wait for the ready status the chip gets
> unlcoked since the nand_wait() also tries to lock the chip. 
> Additinaly nand_wait() unlocks the chip befor calling yield().
> If another task tries nand_get_chip() at this verry moment the erase will be
> interrupted by sending an RESET command. Looks like this is by 
> intention since the erase of the blockis restarted after the 
> nand_wait() returns.
> (I'm not shure if a 3rd task could start an ERASE command - after the 
> 2nd task has interrupted the 1st on - before the first nand_wait() 
> returns. This could mislead the first task.)
> 
> My real problem is this one:
> Our NAND-chips use to keep the buisy line active "for ever" when the 
> RESET command is issued at the wrong point of time. A chip in that 
> condition requires a power-on reset to reactivate the chip. Which 
> makes it a verry critical condition to us. :)
> At the moment I am fixing this problem by causing our local copy of 
> nand_command() (in maps/) to wait for the ready bit of the NAND-chip 
> (except for the STATUS commands).
> 
> To be more specific: If the RESET is issued when the ERASE is almost 
> finished a deadlock of the chips state is verry likely.
> 
> As far as I know the RESET should not do any harm to the chip by 
> definition. But unfortunately it does. :-(
> 
> Stephan
> 
> 
> > -----Original Message-----
> > From: linux-mtd-bounces@lists.infradead.org
> > [mailto:linux-mtd-bounces@lists.infradead.org]On Behalf Of Thomas
> > Gleixner
> > Sent: Mittwoch, 24. November 2004 17:29
> > To: Stephan Linke
> > Cc: Linux-Mtd
> > Subject: Re: using multile partitions on one NAND chip
> > 
> > 
> > On Wed, 2004-11-24 at 15:40 +0100, Stephan Linke wrote:
> > > Hi,
> > 
> > Please fix your mail client, to 80 characters per line.
> > Read http://david.woodhou.se/email.html
> > 
> > > anyone tried using multiple partitions on a NAND flash?
> > 
> > Ever looked into the various drivers in drivers/mtd/nand ?
> > 
> > > I can't find the protection mechanism that protects lets
> > > say an erase on one block against a read command on the
> > > other block.
> > 
> > nand_get_chip() contains the protection.
> > 
> > > efficient protection for this. It looks like nand_chip->chip_lock 
> > > should do this job but it only protects
> > 
> > chip_lock is only for SMP and the lock/unlock macros contain the
> > preemption control if CONFIG_PREEMPT=y. The lock itself is a NOOP on UP
> > systems
> > 
> > tglx
> > 
> > 
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> > 

       reply	other threads:[~2004-11-24 18:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <NGENJJFPMHGLPILEKKAMMEAFCFAA.Stephan.Linke@epygi.de>
2004-11-24 18:28 ` Stephan Linke [this message]
2004-11-24 20:05   ` using multile partitions on one NAND chip Thomas Gleixner
2004-11-24 14:40 Stephan Linke
2004-11-24 16:29 ` 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=NGENJJFPMHGLPILEKKAMAEAGCFAA.Stephan.Linke@epygi.de \
    --to=stephan.linke@epygi.de \
    --cc=linux-mtd@lists.infradead.org \
    /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