All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Ringle <jon@ringle.org>
To: Nicolas Pitre <nico@cam.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [SPAM]  Re: P30 flash left in read status mode after a write
Date: Wed, 14 Feb 2007 15:09:51 -0500	[thread overview]
Message-ID: <45D36C8F.9010102@ringle.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0702141443270.1757@xanadu.home>

Nicolas Pitre wrote:
> On Wed, 14 Feb 2007, Jon Ringle wrote:
>
>   
>> I am running Linux 2.6.16.29 and I've 
>> found that whenever a write is done to the jffs2 filesystem that flash 
>> is left in read status mode and anything trying to do a read of flash 
>> directly reads only 0x0080. Reading from an mtd device seems to fix the 
>> problem.
>>     
>
> This is done on purpose.  And as you deduced yourself this is so to 
> avoid ...
>
>   
>> taking a slight performance hit to consecutive jffs2 write operations 
>> because now each write operation will need to spend more cycles putting 
>> the flash in to a write mode.
>>
>> Any advice would be appreciated.
>>     
>
> First, why is this a problem for you?
>
>   
This is a problem on our (unusual) hardware because we have a Pentium M 
processor (not running Linux) that reads fconfig partition outside the 
context of the IXP processor that is running Linux. It does so via data 
path: Pentium -> PCI -> IXP Expansion bus -> Flash. This data path 
allows the Pentium to directly access the fconfig partition without 
needing any active code on the IXP's arm core processor to do anything 
to facilitate such access by the Pentium. However, when the mtd driver 
leaves the flash in read status mode, the Pentium just reads 0x0080 when 
trying to read the fconfig partition. With a change to have the mtd 
driver put the flash back into ready mode after a write, then I think 
that the Pentium only needs to deal with a temporary read failure if it 
happens to do a read at the same time that a write is occurring on the 
jffs2. In which case, the Pentium code simply spins retrying to do the 
read until it is successful.

Jon

  reply	other threads:[~2007-02-14 20:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-14 18:52 P30 flash left in read status mode after a write Jon Ringle
2007-02-14 19:14 ` Josh Boyer
2007-02-14 19:47 ` Nicolas Pitre
2007-02-14 20:09   ` Jon Ringle [this message]
2007-02-14 20:33     ` [SPAM] " Nicolas Pitre
2007-02-14 20:41       ` Jon Ringle
2007-02-14 20:57         ` Nicolas Pitre
2007-02-14 20:56 ` Jörn Engel
2007-02-14 21:22   ` [SPAM] " Jon Ringle
2007-02-14 21:34     ` Nicolas Pitre
2007-02-20 19:11       ` Alexey Korolev

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=45D36C8F.9010102@ringle.org \
    --to=jon@ringle.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nico@cam.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.