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/
> >
next parent 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 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.