From: Cam <camilo@mesias.co.uk>
To: linux-mtd@lists.infradead.org
Subject: Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close
Date: Wed, 11 Feb 2004 15:17:17 +0000 [thread overview]
Message-ID: <402A477D.3020701@mesias.co.uk> (raw)
Hello,
I hope I have the right list for this question.
I'm looking into a problem with some Intel 28F640 flash on a powerPC
board. I find that the cfi_cmdset_0001 code leaves the flash in the
FL_STATUS state after MTD_close. The chips remain in this state which
leaves the memory unreadable.
I would have expected the flash to be left in the read array state when
not in use.
I think the chip status in the driver and that in the chip is in sync,
ie. the driver is deliberately leaving the chip in this state.
I found a previous reference to a similar problem:
http://lists.infradead.org/pipermail/linux-mtd/2001-November/003603.html
The problem described there is more serious in that the chip and the
driver seem to get out of step with regards to the FL_STATUS state.
Is there a reason why the chip is not left in the read array state after
an MTD_close? My first thought is to modify cfi_intelext_sync, called by
MTD_close so that the chip is left in the read array state after the
sync command, but being a newcomer to this code I might be missing
something important.
Comments?
-Cam
--
camilo@mesias.co.uk <--
next reply other threads:[~2004-02-11 15:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-11 15:17 Cam [this message]
2004-02-11 15:30 ` Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close David Woodhouse
2004-02-11 15:44 ` Cam
2004-02-11 15:49 ` David Woodhouse
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=402A477D.3020701@mesias.co.uk \
--to=camilo@mesias.co.uk \
--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