public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vipin Kumar <vipin.kumar@st.com>
To: "Artem.Bityutskiy@nokia.com" <Artem.Bityutskiy@nokia.com>
Cc: Viresh KUMAR <viresh.kumar@st.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"David.Woodhouse@intel.com" <David.Woodhouse@intel.com>
Subject: Re: [PATCH] Newly erased page read workaround
Date: Fri, 1 Apr 2011 11:58:26 +0530	[thread overview]
Message-ID: <4D95708A.7080204@st.com> (raw)
In-Reply-To: <1301579475.2828.82.camel@localhost>

On 3/31/2011 7:21 PM, Artem Bityutskiy wrote:
> Hi,
> 

Hello Artem,

> sorry for late reply, was too busy and also missed your patch somehow.
> 
> On Thu, 2011-02-24 at 11:40 +0530, Viresh Kumar wrote:
>> From: Vipin Kumar <vipin.kumar@st.com>
>>
>> A newly erased page contains ff in data as well as spare area. While reading an
>> erased page, the read out ecc from spare area does not match the ecc generated
>> by fsmc ecc hardware accelarator. This is because ecc of data ff ff is not ff
>> ff. This leads to errors when jffs2 fs erases and reads back the pages to
>> ensure consistency.
>>
>> This patch adds a software workaround to ensure that the ecc check is not
>> performed for erased pages. An erased page is checked by checking data as ff ff.
>>
>> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
> 
> ...
> 
>> +		/*
>> +		 * This is a temporary erase check. A newly erased page read
>> +		 * would result in an ecc error because the oob data is also
>> +		 * erased to FF and the calculated ecc for an FF data is not
>> +		 * FF..FF.
>> +		 * This is a workaround to skip performing correction in case
>> +		 * data is FF..FF
>> +		 */
>> +		for (k = 0; k < eccsize; k++) {
>> +			if (*(p + k) != 0xff)
>> +				break;
>> +		}
>> +
> 
> So eccsize is 512, and you are going to compare 512 bytes on every read?
> Isn't it a very bad and wasteful solution? May be you could invent
> something less straight-forward but more optimal?
> 
> Let's suppose ECC corresponding to all 0xFFs is P. May be you could do
> this wasteful check only if ECC == P, not all the time?
> 

Basically, the hardware only reports the flipped bit offset and not the actual ecc 
at the time of reading. It reports ecc only at the time of writing. So, comparing 
ECCs is not a possibility while reading.

The other solution can be to write P into OOB every time a page is erased. In that 
case we put a hook in erase. But since the read implementation was anyway specific 
for fsmc bch ecc4 scheme, this implementation was more convinient...

> Also, Ivan pointed you the right thing - you might have bit-flips on an
> erased eraseblock. If not on freshly, then on an erasblock which was
> erased and then not used for long time. If this is not of your concern,

In that case an ecc error would be reported since the ecc wont match the stored 
ecc i.e FFFF and the driver would mark it as a normal corrupted page

> then at least write this in the comments and tell that you know about
> this issue but for reasons X and Y you do not handle them.
> 

OK. I would add this in the patch comments

> Thanks!
> 

Regards
Vipin

  reply	other threads:[~2011-04-01  6:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24  6:10 [PATCH] Newly erased page read workaround Viresh Kumar
2011-02-24  9:38 ` Ivan Djelic
2011-02-24 10:20   ` Vipin Kumar
2011-02-24 11:10     ` Ivan Djelic
2011-02-24 11:36       ` Vipin Kumar
2011-03-22  4:36 ` viresh kumar
2011-03-31 13:51 ` Artem Bityutskiy
2011-04-01  6:28   ` Vipin Kumar [this message]
2011-04-01  6:51     ` Artem Bityutskiy
2011-04-01  8:33       ` Vipin Kumar
2011-04-01  8:39         ` Artem Bityutskiy
2011-04-01  9:06           ` Vipin Kumar
2011-04-01  9:42             ` Artem Bityutskiy
2011-04-01 12:14             ` Ivan Djelic
2011-04-01 13:04               ` Artem Bityutskiy
2011-04-01 14:04                 ` Ivan Djelic
2011-04-01 14:16                   ` Artem Bityutskiy
2011-04-01 14:49                     ` Ivan Djelic
2011-04-01 14:58                       ` Ricard Wanderlof
2011-04-01 15:46                         ` Ivan Djelic
2011-04-01 16:09                     ` Ivan Djelic
2011-04-01 16:16                       ` Artem Bityutskiy

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=4D95708A.7080204@st.com \
    --to=vipin.kumar@st.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=David.Woodhouse@intel.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=viresh.kumar@st.com \
    /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