All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: Werner Almesberger <werner@openmoko.org>
Cc: linux-mtd@lists.infradead.org, Ben Dooks <ben@trinity.fluff.org>,
	Ben Dooks <ben-linux@fluff.org>
Subject: Re: [PATCH] nand_read_subpage vs. S3C244x NAND: non-word reads
Date: Sun, 2 Nov 2008 12:27:51 +0000	[thread overview]
Message-ID: <20081102122751.GC11063@fluff.org.uk> (raw)
In-Reply-To: <20081101161148.GN31758@almesberger.net>

On Sat, Nov 01, 2008 at 02:11:48PM -0200, Werner Almesberger wrote:
> Ben Dooks wrote:
> > As noted on the openmoko list,
> 
> Sorry for starting two threads on the same topic. The joy of trying
> to do the right thing with lists that don't let you cross-post unless
> you're subscribed ...
> 
> > I think we can do 256byte subpage reads
> > as long as they are aligned to 256bytes. We could make the ECC code
> > deal with non-256 byte power-of-two aligned blocks without huge
> > changes but my belief is that we cannot support anything that isn't
> > a power of two.
> 
> In this case, the problem is a bit more subtle: the data blocks
> retrieved are perfectly normal, i.e., 256 bytes in size and
> properly aligned.
> 
> However, nand_read_subpage optimizes retrieval of the OOB data.
> So instead of retrieving, say, 64 bytes, it only retrieves 24
> (for a 2048 bytes page). Sometimes, not the entire page is
> retrieved, and then we get those accesses with an odd size.
> 
> > I think the best thing to do is to either force the caller to read
> > a power of two (pref. >4 bytes), so either we need some form of flag
> > to say this, or change the behaviour of the callers to never try this.
> 
> If it's considered generally objectionable to call read_buf for
> an amount of data that isn't a whole number of words, those two
> approaches would work as well. Making nand_read_subpage align to
> 4 bytes instead of 1/2 would be fairly simple. A flag would be a
> bit messier.

I think that if it is only a problem of reading the correct number of
bytes for stuff like the OOB, then there's no problem in adding an
fractional fixup after the readsl.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

      reply	other threads:[~2008-11-02 12:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-01  3:15 [PATCH] nand_read_subpage vs. S3C244x NAND: non-word reads Werner Almesberger
2008-11-01 12:46 ` Ben Dooks
2008-11-01 16:11   ` Werner Almesberger
2008-11-02 12:27     ` Ben Dooks [this message]

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=20081102122751.GC11063@fluff.org.uk \
    --to=ben-linux@fluff.org \
    --cc=ben@trinity.fluff.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=werner@openmoko.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.