[PATCH][RFC] NAND subpage read feature. Take 2.

[PATCH][RFC] NAND subpage read feature. Take 2.

[Alexey Korolev]

Hi,

This patch enables NAND subpage read functionality. 
This functionality works in case of SW ECC algorithms only. In this case
every page is split into independent ECC regions covered by own ECC code. 
Usually ECC region's size is 256 bytes and ECC code's size is 3 bytes.
If upper layer drivers are requesting to read non page aligned data NAND
subpage-read functionality reads the ECC regions which includes
requested data when original code reads whole page.

This significantly improves performance in many cases.
It doubles JFFS2 file stat performance. It increases random read
performance and sequential performance for small data shunks. 

It is a second attempt to include this feature.
What has been changed? 
1. Fixed naming. Fixed coding style. 
2. Modified registration. Now it is no need to use magic to switch on
this feature. It is enabled by default. 
3. Improved performance. The previous code read whole oob region per
every subpage read request. Now it reads only necessary ecc codes.  

As I know some of you already use this feature. I would be much
appreciate if you give me some performance numbers. It may assist to get this
feature included. 

Thanks,
Alexey


Signed-off-by Alexey Korolev <akorolev@infradead.org>
-----
diff -Naurp 1/drivers/mtd/nand/nand_base.c 2/drivers/mtd/nand/nand_base.c
--- 1/drivers/mtd/nand/nand_base.c	2008-02-11 08:51:11.000000000 +0300
+++ 2/drivers/mtd/nand/nand_base.c	2008-04-30 14:58:52.000000000 +0400
@@ -798,6 +798,89 @@ static int nand_read_page_swecc(struct m
 }
 
 /**
+ * nand_read_subpage - [REPLACABLE] software ecc based sub-page read function
+ * @mtd:	mtd info structure
+ * @chip:	nand chip info structure
+ * @dataofs	offset of requested data within the page 
+ * @readlen	data length 
+ * @buf:	buffer to store read data
+ */
+static int nand_read_subpage(struct mtd_info * mtd,struct nand_chip *chip, uint32_t data_offs, uint32_t readlen, uint8_t *bufpoi)
+{
+	int start_step, end_step, num_steps;
+	uint32_t *eccpos = chip->ecc.layout->eccpos;
+	uint8_t *p;
+	int data_col_addr, i, gaps = 0;
+	int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
+	int busw = (chip->options & NAND_BUSWIDTH_16) ? 2 : 1;
+	
+	/* Column address wihin the page aligned to ECC size (256bytes). */
+	start_step = data_offs / chip->ecc.size;
+	end_step = (data_offs + readlen - 1) / chip->ecc.size;
+	num_steps = end_step - start_step + 1;
+
+	/* Data size aligned to ECC ecc.size*/
+	datafrag_len = num_steps * chip->ecc.size;
+	eccfrag_len = num_steps * chip->ecc.bytes;
+
+	data_col_addr = start_step * chip->ecc.size;
+	/* If we read not a page aligned data */
+	if (data_col_addr != 0) {
+		chip->cmdfunc(mtd, NAND_CMD_RNDOUT, data_col_addr, -1);
+	}
+
+	p = bufpoi + data_col_addr;
+	chip->read_buf(mtd, p, datafrag_len);
+
+	/* Calculate  ECC */
+	for (i = 0; i<eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size)
+		chip->ecc.calculate(mtd, p, &chip->buffers->ecccalc[i]);
+
+	/* The performance is faster if to position offsets 
+	   according to ecc.pos. Let make sure here that 
+	   there are no gaps in ecc positions */
+	for (i = 0; i < eccfrag_len - 1; i++) {
+		if (eccpos[i + start_step * chip->ecc.bytes] + 1 != 
+			eccpos[i + start_step * chip->ecc.bytes + 1]) {
+			gaps = 1;
+			break;
+		}
+	}
+	if (gaps) {
+		chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
+		chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+	}
+	else {
+		/* send the command to read the particular ecc bytes */
+		/* take care about buswidth alignment in read_buf */
+		aligned_pos = eccpos[start_step * chip->ecc.bytes] & ~(busw - 1);
+		aligned_len = eccfrag_len;
+		if (eccpos[start_step * chip->ecc.bytes] & (busw - 1))
+			aligned_len++;
+		if (eccpos[(start_step + num_steps) * chip->ecc.bytes] & (busw - 1))
+			aligned_len++;
+
+		chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + aligned_pos, -1);
+		chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);
+	}
+	
+	for (i = 0; i < eccfrag_len; i++)
+		chip->buffers->ecccode[i] = chip->oob_poi[eccpos[i + start_step * chip->ecc.bytes]];
+
+	p = bufpoi + data_col_addr;
+	for (i = 0; i<eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size) {
+		int stat;
+
+		stat = chip->ecc.correct(mtd, p, &chip->buffers->ecccode[i], &chip->buffers->ecccalc[i]);
+		if (stat == -1)
+			mtd->ecc_stats.failed++;
+		else
+			mtd->ecc_stats.corrected += stat;
+	}
+	return 0;	
+}
+
+/**
  * nand_read_page_hwecc - [REPLACABLE] hardware ecc based page read function
  * @mtd:	mtd info structure
  * @chip:	nand chip info structure
@@ -994,14 +1077,17 @@ static int nand_do_read_ops(struct mtd_i
 			/* Now read the page into the buffer */
 			if (unlikely(ops->mode == MTD_OOB_RAW))
 				ret = chip->ecc.read_page_raw(mtd, chip, bufpoi);
-			else
+			else if ( !aligned && NAND_SUBPAGE_READ(chip) && !oob )
+				ret = chip->ecc.read_subpage(mtd, chip, col, bytes, bufpoi);
+			else 
 				ret = chip->ecc.read_page(mtd, chip, bufpoi);
 			if (ret < 0)
 				break;
 
 			/* Transfer not aligned data */
 			if (!aligned) {
-				chip->pagebuf = realpage;
+				if (!NAND_SUBPAGE_READ(chip) && !oob)
+					chip->pagebuf = realpage;
 				memcpy(buf, chip->buffers->databuf + col, bytes);
 			}
 
@@ -2496,6 +2582,7 @@ int nand_scan_tail(struct mtd_info *mtd)
 		chip->ecc.calculate = nand_calculate_ecc;
 		chip->ecc.correct = nand_correct_data;
 		chip->ecc.read_page = nand_read_page_swecc;
+		chip->ecc.read_subpage = nand_read_subpage;
 		chip->ecc.write_page = nand_write_page_swecc;
 		chip->ecc.read_oob = nand_read_oob_std;
 		chip->ecc.write_oob = nand_write_oob_std;
diff -Naurp 1/include/linux/mtd/nand.h 2/include/linux/mtd/nand.h
--- 1/include/linux/mtd/nand.h	2008-02-11 08:51:11.000000000 +0300
+++ 2/include/linux/mtd/nand.h	2008-04-30 14:56:54.000000000 +0400
@@ -179,6 +179,7 @@ typedef enum {
 #define NAND_MUST_PAD(chip) (!(chip->options & NAND_NO_PADDING))
 #define NAND_HAS_CACHEPROG(chip) ((chip->options & NAND_CACHEPRG))
 #define NAND_HAS_COPYBACK(chip) ((chip->options & NAND_COPYBACK))
+#define NAND_SUBPAGE_READ(chip) ((chip->ecc.mode == NAND_ECC_SOFT))
 
 /* Mask to zero out the chip options, which come from the id table */
 #define NAND_CHIPOPTIONS_MSK	(0x0000ffff & ~NAND_NO_AUTOINCR)
@@ -276,6 +277,10 @@ struct nand_ecc_ctrl {
 	int			(*read_page)(struct mtd_info *mtd,
 					     struct nand_chip *chip,
 					     uint8_t *buf);
+	int			(*read_subpage)(struct mtd_info *mtd,
+					     struct nand_chip *chip, 
+					     uint32_t offs, uint32_t len,
+					     uint8_t *buf);
 	void			(*write_page)(struct mtd_info *mtd,
 					      struct nand_chip *chip,
 					      const uint8_t *buf);
-----

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Hamish Moffatt]

On Wed, Apr 30, 2008 at 01:13:24PM +0100, Alexey Korolev wrote:
> This patch enables NAND subpage read functionality. 
[..]
> As I know some of you already use this feature. I would be much
> appreciate if you give me some performance numbers. It may assist to get this
> feature included. 

To attach my 512Mb NAND with UBI, with software NAND controller
(plat_nand), on a 533MHz IXP4xx, I measure:

No partial reads: 5.75 seconds
Previous partial read patch: 2.72 seconds
New subpage read patch: 2.42 seconds

Very fine. Thanks.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

MTD PARTITION

[Aneesh]

hello,
	Any body can tell me how to partition a parallel flash ?
	means how to create mtdblock1 ,mtdblock2 etc?
	i am using at91rm9200dk custom board and i am using a parallel flash
AT49BV642D

regards 
Aneesh

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Wed, 30 April 2008 13:13:24 +0100, Alexey Korolev wrote:
> 
> This patch enables NAND subpage read functionality. 

...and creates a peculiar conflict of interests in me.  I've added full
caching of the complete mtd in logfs, which gave a huge speedup to some
of my testcases.  However caching is done in page granularity, therefore
it would completely defeat this patch, which also gives a speedup.

But until I can figure out how to combine both benefits, this looks
rather promising and should clearly get in.

>  /**
> + * nand_read_subpage - [REPLACABLE] software ecc based sub-page read function
> + * @mtd:	mtd info structure
> + * @chip:	nand chip info structure
> + * @dataofs	offset of requested data within the page 
> + * @readlen	data length 
> + * @buf:	buffer to store read data
> + */
> +static int nand_read_subpage(struct mtd_info * mtd,struct nand_chip *chip, uint32_t data_offs, uint32_t readlen, uint8_t *bufpoi)
                                                 ^   ^^
A linebreak would help.  The indicated space should move five bytes to
the right.  And there are a few similar stylistic things below.  If you
feed this through checkpatch.pl, you should find them all.

buf and bufpoi should be the same name (I personally would prefer buf).
And you should document that the buffer has to be bigger than readlen.
There is just a single caller, but such a counter-intuitive detail can
easily cause bugs some years from now.

> +{
> +	int start_step, end_step, num_steps;
> +	uint32_t *eccpos = chip->ecc.layout->eccpos;
> +	uint8_t *p;
> +	int data_col_addr, i, gaps = 0;
> +	int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
> +	int busw = (chip->options & NAND_BUSWIDTH_16) ? 2 : 1;
> +	
> +	/* Column address wihin the page aligned to ECC size (256bytes). */

within

> +	start_step = data_offs / chip->ecc.size;
> +	end_step = (data_offs + readlen - 1) / chip->ecc.size;

Divisions are fairly expensive computations.  Can they be replaced by
shifts?

Rest looks good to me, apart from some checkpatch-type details.
Although I am tired and could have missed something.

Jörn

-- 
Joern's library part 9:
http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Alexander Belyakov]

On Fri, May 2, 2008 at 12:25 AM, Jörn Engel <joern@logfs.org> wrote:
> On Wed, 30 April 2008 13:13:24 +0100, Alexey Korolev wrote:
>>
>> This patch enables NAND subpage read functionality.
>
> ...and creates a peculiar conflict of interests in me.  I've added full
> caching of the complete mtd in logfs, which gave a huge speedup to some
> of my testcases.  However caching is done in page granularity, therefore
> it would completely defeat this patch, which also gives a speedup.
>

There is a special case for page aligned data where generic
read_page() is being used instead of read_subpage(). I believe logfs
caching won't suffer from this patch.

-a

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Sun, 4 May 2008 12:46:31 +0400, Alexander Belyakov wrote:
> On Fri, May 2, 2008 at 12:25 AM, Jörn Engel <joern@logfs.org> wrote:
> >
> > ...and creates a peculiar conflict of interests in me.  I've added full
> > caching of the complete mtd in logfs, which gave a huge speedup to some
> > of my testcases.  However caching is done in page granularity, therefore
> > it would completely defeat this patch, which also gives a speedup.
> 
> There is a special case for page aligned data where generic
> read_page() is being used instead of read_subpage(). I believe logfs
> caching won't suffer from this patch.

Actually, logfs caching would help jffs2 as well, as soon as you have
several parallel readers.  It should be made generic mtd caching.  And
when made generic, it would effectively defeat this patch, as all reads
would be (DRAM-) pagesized.

We could theoretically use buggerheads and do the caching in smaller
granularities.

Jörn

-- 
All models are wrong. Some models are useful.
-- George Box

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Alexander Belyakov]

On Mon, May 5, 2008 at 11:37 AM, Jörn Engel <joern@logfs.org> wrote:
>
> Actually, logfs caching would help jffs2 as well, as soon as you have
> several parallel readers.  It should be made generic mtd caching.  And
> when made generic, it would effectively defeat this patch, as all reads
> would be (DRAM-) pagesized.
>
> We could theoretically use buggerheads and do the caching in smaller
> granularities.
>

We'd like to look at this new mtd caching layer. Have you working
prototype to play with?

-a

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Mon, 5 May 2008 16:10:46 +0400, Alexander Belyakov wrote:
> On Mon, May 5, 2008 at 11:37 AM, Jörn Engel <joern@logfs.org> wrote:
> >
> > Actually, logfs caching would help jffs2 as well, as soon as you have
> > several parallel readers.  It should be made generic mtd caching.  And
> > when made generic, it would effectively defeat this patch, as all reads
> > would be (DRAM-) pagesized.
> >
> > We could theoretically use buggerheads and do the caching in smaller
> > granularities.
> 
> We'd like to look at this new mtd caching layer. Have you working
> prototype to play with?

Take a look into fs/logfs/dev_mtd.c in the logfs patch or git tree:
http://lazybastard.org/~joern/patches/logfs.patch.773
http://git.kernel.org/?p=linux/kernel/git/joern/logfs.git;a=summary

It is currently part of logfs, but moving it over to
drivers/mtd/mtdcore.c shouldn't be too hard.

Jörn

-- 
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Hamish Moffatt]

On Mon, May 05, 2008 at 09:37:45AM +0200, Jörn Engel wrote:
> On Sun, 4 May 2008 12:46:31 +0400, Alexander Belyakov wrote:
> > On Fri, May 2, 2008 at 12:25 AM, Jörn Engel <joern@logfs.org> wrote:
> > >
> > > ...and creates a peculiar conflict of interests in me.  I've added full
> > > caching of the complete mtd in logfs, which gave a huge speedup to some
> > > of my testcases.  However caching is done in page granularity, therefore
> > > it would completely defeat this patch, which also gives a speedup.
> > 
> > There is a special case for page aligned data where generic
> > read_page() is being used instead of read_subpage(). I believe logfs
> > caching won't suffer from this patch.
> 
> Actually, logfs caching would help jffs2 as well, as soon as you have
> several parallel readers.  It should be made generic mtd caching.  And
> when made generic, it would effectively defeat this patch, as all reads
> would be (DRAM-) pagesized.

.. and therefore performance would be worse for UBI attach, for example.
Caching only makes sense when you can read extra data at no cost. Unless
you can find some way to cache while idle but abort if it is delaying
another read?


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Tue, 6 May 2008 10:15:15 +1000, Hamish Moffatt wrote:
> 
> Caching only makes sense when you can read extra data at no cost.

Not true.  Caching makes sense when the benefits outweigh the costs,
just like everything else.  "No cost" is just a special case where even
minimal benefits suffice.

Nand already does caching, it just limits itself to a single page.  If
two consecutive reads hit the single page, it is only read once.  Which
easily fits your definition and just as easily helps single-threaded
users.  But two threads bouncing back and forth can already nullify the
gains.  It would be useful to keep as much old data around as there is
DRAM for.

However DRAM page granularity is bigger, therefore some data will be
read and not used.  In the case of ubi attach that is a lot of data.
And there are no benefits in caching the ubi headers, as they are read
only once.  So the solution is to have NAND page granularity or so for
the cache, which means buggerheads.

[ Also, even ubi attach may benefit from caching under special
circumstances.  If you have just written an image and have enough ram,
there is no reason to go back to flash.  But that hardly matters in real
life. ]

Jörn

-- 
tglx1 thinks that joern should get a (TM) for "Thinking Is Hard"
-- Thomas Gleixner

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Alexander Belyakov]

On Mon, May 5, 2008 at 7:39 PM, Jörn Engel <joern@logfs.org> wrote:
> On Mon, 5 May 2008 16:10:46 +0400, Alexander Belyakov wrote:
>>
>> We'd like to look at this new mtd caching layer. Have you working
>> prototype to play with?
>
> Take a look into fs/logfs/dev_mtd.c in the logfs patch or git tree:

Thanks. I believe mtd caching deserves separate discussion, because
too many mtd things are going to be affected.

As for subpage read, Alexey will proceed with patch submission next week.

-a

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Hamish Moffatt]

On Tue, May 06, 2008 at 08:15:31AM +0200, Jörn Engel wrote:
> On Tue, 6 May 2008 10:15:15 +1000, Hamish Moffatt wrote:
> > 
> > Caching only makes sense when you can read extra data at no cost.
> 
> Not true.  Caching makes sense when the benefits outweigh the costs,
> just like everything else.  "No cost" is just a special case where even
> minimal benefits suffice.
> 
> Nand already does caching, it just limits itself to a single page.  If
> two consecutive reads hit the single page, it is only read once.  Which
> easily fits your definition and just as easily helps single-threaded
> users.  But two threads bouncing back and forth can already nullify the
> gains.  It would be useful to keep as much old data around as there is
> DRAM for.

It makes sense to keep data that you had to read anyway, but with the
subpage read patch that's less than a whole page.

> [ Also, even ubi attach may benefit from caching under special
> circumstances.  If you have just written an image and have enough ram,
> there is no reason to go back to flash.  But that hardly matters in real
> life. ]

I agree. So are we talking about caching of data which we've read
anyway, or speculative reads? Because reading more than the user
requested is speculation afaict. If LogFS (for example) reads a whole 
page even when it doesn't need it, that will degrade performance in some
cases.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Tue, 6 May 2008 19:42:49 +1000, Hamish Moffatt wrote:
> 
> It makes sense to keep data that you had to read anyway, but with the
> subpage read patch that's less than a whole page.

Then make the granularity a subpage.

> I agree. So are we talking about caching of data which we've read
> anyway, or speculative reads? Because reading more than the user
> requested is speculation afaict. If LogFS (for example) reads a whole 
> page even when it doesn't need it, that will degrade performance in some
> cases.

Sure, that's true for any caching.  Unless you have some locality of
access, it won't help.  Ubi scan is the perfect counter-example with
zero locality, both temporal and spacial.

Jörn

-- 
Do not stop an army on its way home.
-- Sun Tzu

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Tue, 6 May 2008 13:29:09 +0400, Alexander Belyakov wrote:
> 
> Thanks. I believe mtd caching deserves separate discussion, because
> too many mtd things are going to be affected.

Indeed.  For that very reason I've kept the caching part of logfs for
now.  It is not a trivial decision to make and regressions can show up
in surprising places.

Jörn

-- 
Joern's library part 10:
http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Artem Bityutskiy]

On Thu, 2008-05-08 at 17:30 +0200, Jörn Engel wrote:
> On Tue, 6 May 2008 13:29:09 +0400, Alexander Belyakov wrote:
> > 
> > Thanks. I believe mtd caching deserves separate discussion, because
> > too many mtd things are going to be affected.
> 
> Indeed.  For that very reason I've kept the caching part of logfs for
> now.  It is not a trivial decision to make and regressions can show up
> in surprising places.

We could provide a possibility to explicitly enable/disable it I guess.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Jörn Engel]

On Thu, 8 May 2008 18:33:41 +0300, Artem Bityutskiy wrote:
> 
> We could provide a possibility to explicitly enable/disable it I guess.

I've thought about that as well, but didn't like the idea too much.  It
would be better to spend the extra work and make sure we don't have
regressions.

Jörn

-- 
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Alexey Korolev]

Hi Hamish,

> On Wed, Apr 30, 2008 at 01:13:24PM +0100, Alexey Korolev wrote:
> > This patch enables NAND subpage read functionality. 
> [..]
> > As I know some of you already use this feature. I would be much
> > appreciate if you give me some performance numbers. It may assist to get this
> > feature included. 
> 
> To attach my 512Mb NAND with UBI, with software NAND controller
> (plat_nand), on a 533MHz IXP4xx, I measure:
> 
> No partial reads: 5.75 seconds
> Previous partial read patch: 2.72 seconds
> New subpage read patch: 2.42 seconds
>
Oh nice digits. Thank you very much for you asistance and for the data. 
I will add it to patch description. 

Alexey
 

Re: [PATCH][RFC] NAND subpage read feature. Take 2.

[Alexey Korolev]

Hi,

> >  /**
> > + * nand_read_subpage - [REPLACABLE] software ecc based sub-page read function
> > + * @mtd:	mtd info structure
> > + * @chip:	nand chip info structure
> > + * @dataofs	offset of requested data within the page 
> > + * @readlen	data length 
> > + * @buf:	buffer to store read data
> > + */
> > +static int nand_read_subpage(struct mtd_info * mtd,struct nand_chip *chip, uint32_t data_offs, uint32_t readlen, uint8_t *bufpoi)
>                                                  ^   ^^
> A linebreak would help.  The indicated space should move five bytes to
> the right.  And there are a few similar stylistic things below.  If you
> feed this through checkpatch.pl, you should find them all.
> 
> buf and bufpoi should be the same name (I personally would prefer buf).
> And you should document that the buffer has to be bigger than readlen.
> There is just a single caller, but such a counter-intuitive detail can
> easily cause bugs some years from now.
>
Oops. You are right. Wrong styling will be fixed. Thanks.
> > +{
> > +	int start_step, end_step, num_steps;
> > +	uint32_t *eccpos = chip->ecc.layout->eccpos;
> > +	uint8_t *p;
> > +	int data_col_addr, i, gaps = 0;
> > +	int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
> > +	int busw = (chip->options & NAND_BUSWIDTH_16) ? 2 : 1;
> > +	
> > +	/* Column address wihin the page aligned to ECC size (256bytes). */
> 
> within
> 
> > +	start_step = data_offs / chip->ecc.size;
> > +	end_step = (data_offs + readlen - 1) / chip->ecc.size;
> 
> Divisions are fairly expensive computations.  Can they be replaced by
> shifts?
> 
I've thought about it. In current desing we assume that ecc.size may
vary. So substitution division  with shift will be related to extension
of the structures. 
If it make sence to do it, it should be done in separate patch. As it is
another thing. 


Alexey