From: Frederic Gobry <frederic.gobry@smartdata.ch>
To: linux-mtd@lists.infradead.org
Subject: Re: mmap question
Date: Fri, 12 Jul 2002 09:57:16 +0200 [thread overview]
Message-ID: <20020712075715.GA9952@rhin> (raw)
In-Reply-To: <20020711191540.GA16466@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
> 0x80 is the status register, you are reading. The command set (Intel
> or Amd, I suppose) can read it, handle any errors (0x80 mean no errors
> on intel) and return to read mode by writing 0xff to the flash.
Mmmm, this enlightens the situation. I was fearing some cache problem...
> My guess is that you command set has a bug. Fix it or provide a spec
> and some beer and pizza. ;-)
The base code uses cfi_probe: it seemed to me the command set is
determined and provided automatically, isn't it ?
I think it's more because I interfere with the "canonical" way MTD
handles the flash: I access directly the memory after the erase or
write operation (via mmap, *not* via a read system call), but from the
code in do_read_onechip (cfi_cmdset_0001.c), it seems the flash is set
to read mode not when the erase or write operation is finished, but
before an actual read must be performed (which makes sense).
I can work around this for my program (I just tested, performing a
simple read just after the write restores what is seen in the mmapped
memory), but I still would like to know if the MTD API could be
augmented in order to handle read-only memory mapped areas (when
available) in a cleaner way as what I currently do? I don't think
this would imply lots of changes:
- a flag indicating if the flash can be mmapped
- the implementation of mmap (which probably would need a call
similar to 'point' but with an explicit semantic toward
mmapping.
- possibly another flag to indicate that an area is currently
mmapped, so that the erase / write operations set the flash in
read mode once they have finished their duty
Frédéric
PS : where can I send the beer and pizza ? :-)
--
Frédéric Gobry SMARTDATA
--- http://www.smartdata.ch
Software Engineer Lausanne - Switzerland
+41 21 693 84 98
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2002-07-12 7:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-04 13:22 mmap question Frederic Gobry
2002-07-01 13:14 ` Frederic Gobry
2002-07-11 16:19 ` Frederic Gobry
2002-07-11 19:15 ` Jörn Engel
2002-07-12 7:57 ` Frederic Gobry [this message]
2002-07-12 15:08 ` Jörn Engel
2002-07-15 7:41 ` Frederic Gobry
2002-07-12 15:21 ` 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=20020712075715.GA9952@rhin \
--to=frederic.gobry@smartdata.ch \
--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