All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2002-07-12  7:57 UTC|newest]

Thread overview: 21+ 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
  -- strict thread matches above, loose matches on Subject: below --
2002-09-24  7:26 Der Herr Hofrat
2002-09-24  8:54 ` Der Herr Hofrat
2002-09-24  9:37 ` Zhonghua Dai
2005-03-21 17:59 Eric Van Hensbergen
2005-03-21 21:33 ` Bryan Henderson
2005-03-21 22:23   ` Matthew Wilcox
2005-03-21 23:18     ` Bryan Henderson
     [not found]   ` <a4e6962a05032114575776f94b@mail.gmail.com>
2005-03-21 22:57     ` Eric Van Hensbergen
2005-03-21 23:24       ` Bryan Henderson
2005-03-21 23:27       ` Bryan Henderson
2005-03-22 21:05         ` Eric Van Hensbergen
2005-03-21 23:56 ` Martin Jambor
2005-08-02 22:44 Ruslan Nikolaev

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 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.