All of lore.kernel.org
 help / color / mirror / Atom feed
From: Troy Kisky <troy.kisky@boundarydevices.com>
To: David Brownell <david-b@pacbell.net>
Cc: tglx@linutronix.de, linux-mtd@lists.infradead.org
Subject: Re: [PATCH V4 2/3] mtd: nand: Calculate better default ecc layout
Date: Mon, 13 Jul 2009 16:04:25 -0700	[thread overview]
Message-ID: <4A5BBD79.4020400@boundarydevices.com> (raw)
In-Reply-To: <200907131456.19881.david-b@pacbell.net>

David Brownell wrote:
> On Friday 26 June 2009, Troy Kisky wrote:
>> Looking through the code, I can only see that
>> Davinci is effected this way when using 512 bytes
>> x 4 steps with hardware ecc.
> 
> You mean, with *single-bit* hardware ECC.

Yes. I do.

> 
> Currently each step needs just three bytes,
> but it's using the default ECC layout which
> allocates six bytes per step.
> 
> 
>> It has its ecc 
>> bytes moved from oob 40-63 to oob 52-63.
> 
> More correctly:  40-42, 46-48, 52-54, 58-60
> to 52-63.

No. More correctly,
40-42  -> 52-54
43-45  -> 55-57
46-48  -> 58-60
49-51  -> 61-63
52-63  -> free space 40-51

> 
> 
>> So a Davinci authority will need to ack this,
>> or request a change.
> 
> Actually I'd just stick with the standard policy
> and not make such an incompatible change in the
> first place.  You can't guarantee that the change
> won't cause regressions...
> 
> It would have been nice if the MTD layer were
> doing this ECC layout before, but in this specific
> case I can't say I think an extra 12 bytes of OOB
> data will matter to anyone.

That was only a side benefit, not the main reason for the patch.

> 
> - Dave


I am perfectly willing to add platform data to the current
evm's to maintain current behavior. As for regressions, could
the next tree help find these?? I have looked fairly closely,
but I definitely could have missed something.


I thank you very much for taking the time to comment upon this.
I'd much rather have a nak than silence.


If anyone ever wants me to post an updated version of the patch
give me a shout. Otherwise, I won't waste anymore of the lists time.


Thanks
Troy

      reply	other threads:[~2009-07-13 23:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1246055086-7357-1-git-send-email-troy.kisky@boundarydevices.com>
     [not found] ` <1246055086-7357-2-git-send-email-troy.kisky@boundarydevices.com>
2009-07-13 21:56   ` [PATCH V4 2/3] mtd: nand: Calculate better default ecc layout David Brownell
2009-07-13 23:04     ` Troy Kisky [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=4A5BBD79.4020400@boundarydevices.com \
    --to=troy.kisky@boundarydevices.com \
    --cc=david-b@pacbell.net \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /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.