RFC: [PATCH] MTD OneNAND: multiblock erase support

Hi,

I wrote an initial support for OneNAND multiblock erase feature.  When
done in maximum 64 eraseblock batches multiblock erase is up to 30x
faster than block-by-block erase (not including erase verify, though).

However, I only had possibility to test this with an OMAP board, so I
don't know if e.g. the default onenand_wait needs adjustment. Also for
Flex-OneNAND the support goes off. Does Flex even have mb erase?

What do you think?

br,
Mika

On Mon, 2009-06-15 at 10:03 +0300, Mika Korhonen wrote:
> Hi,
> 
> I wrote an initial support for OneNAND multiblock erase feature.  When
> done in maximum 64 eraseblock batches multiblock erase is up to 30x
> faster than block-by-block erase (not including erase verify, though).
> 
> However, I only had possibility to test this with an OMAP board, so I
> don't know if e.g. the default onenand_wait needs adjustment. Also for
> Flex-OneNAND the support goes off. Does Flex even have mb erase?
> 
> What do you think?

Would it be please possible to send the patch inlined?

Also, I suggest you to CC:

Adrian Hunter <adrian.hunter@nokia.com>
Kyungmin Park <kyungmin.park@samsung.com>
Amul Saha <amul.saha@samsung.com>

because they are OneNAND-relevent.

On Mon, Jun 15, 2009 at 4:03 PM, Mika Korhonen<mika.j.korhonen@gmail.com> wrote:
> Hi,
>
> I wrote an initial support for OneNAND multiblock erase feature.  When
> done in maximum 64 eraseblock batches multiblock erase is up to 30x
> faster than block-by-block erase (not including erase verify, though).
>
> However, I only had possibility to test this with an OMAP board, so I
> don't know if e.g. the default onenand_wait needs adjustment. Also for
> Flex-OneNAND the support goes off. Does Flex even have mb erase?
>
> What do you think?
>

Hi,

I think you should also modify onenand_wait. and Flex-OneNAND supports
the multi-block erase.

Do you consider the exception case if the multi-block erase failed?

I think you don't consider the bad block handling in case of multi-block erase

You first check the there's no bad block in multi-block erase. the
following code only exit. it means we never erase if we have bad
block.

+	while (do_mb_erase && len > block_size) {
+		/* Check if we have a bad block, we do not erase bad blocks */
+		if (onenand_block_isbad_nolock(mtd, addr, 0)) {
+			printk(KERN_WARNING "onenand_erase: attempt to erase "
+			       "a bad block at addr 0x%08x\n", (unsigned int) addr);
+			instr->state = MTD_ERASE_FAILED;
+			goto erase_exit;
+		}
+
+		this->command(mtd, ONENAND_CMD_MULTIBLOCK_ERASE, addr, block_size);
+
+		onenand_invalidate_bufferram(mtd, addr, block_size);
+
+		ret = this->wait(mtd, FL_PREPARING_ERASE);
+		/* Check, if it is write protected */
+		if (ret) {
+			printk(KERN_ERR "onenand_erase: Failed multiblock erase, "
+                               "block %d\n", (unsigned) (addr >>
this->erase_shift));
+			instr->state = MTD_ERASE_FAILED;
+			instr->fail_addr = addr;
+			goto erase_exit;
+		}
+		len -= block_size;
+		addr += block_size;
+	}

Thank you,
Kyungmin Park

2009/6/15 Kyungmin Park <kyungmin78@gmail.com>:
> On Mon, Jun 15, 2009 at 4:03 PM, Mika Korhonen<mika.j.korhonen@gmail.com> wrote:
>> Hi,
>>
>> I wrote an initial support for OneNAND multiblock erase feature.  When
>> done in maximum 64 eraseblock batches multiblock erase is up to 30x
>> faster than block-by-block erase (not including erase verify, though).
>>
>> However, I only had possibility to test this with an OMAP board, so I
>> don't know if e.g. the default onenand_wait needs adjustment. Also for
>> Flex-OneNAND the support goes off. Does Flex even have mb erase?
>>
>> What do you think?
>>
>
> Hi,
>
> I think you should also modify onenand_wait. and Flex-OneNAND supports
> the multi-block erase.

Ok, could I actually test the default onenand_wait() by not overriding
them in OMAP-specific side? Is there anything special that should be
considered with Flex? Likely just removing the if condition would not
work, would it? :)

> Do you consider the exception case if the multi-block erase failed?
>
> I think you don't consider the bad block handling in case of multi-block erase
>
> You first check the there's no bad block in multi-block erase. the
> following code only exit. it means we never erase if we have bad
> block.

You're right but that's also how the current implementation works in
case the area to be erased contains multiple eraseblocks and a bad one
is encountered. I tried to keep the behaviour the same. To change that
for better would require some way to inform the caller which eb's were
bad. New ioctl()?

Thank you for the good comments!
Mika

Mika Korhonen wrote:
> I wrote an initial support for OneNAND multiblock erase feature.  When
> done in maximum 64 eraseblock batches multiblock erase is up to 30x
> faster than block-by-block erase (not including erase verify, though).
> 
> However, I only had possibility to test this with an OMAP board, so I
> don't know if e.g. the default onenand_wait needs adjustment. Also for
> Flex-OneNAND the support goes off. Does Flex even have mb erase?
> 
> What do you think?

I expect all OneNAND support multiblock erase, so the config should
go away.  Kyungmin can probably comment on that.

Waiting for multiblock-erase, you should probably spin, not use the
interrupt line.  You should change the wait function in
onenand_base and omap2.c.

You should handle multiple multiblock erases.

You should check for bad blocks *before* doing command 0x95

Waiting for erase-verify, you should probably spin too.

2009/6/15 Adrian Hunter <adrian.hunter@nokia.com>:
> Mika Korhonen wrote:
>>
>> I wrote an initial support for OneNAND multiblock erase feature.  When
>> done in maximum 64 eraseblock batches multiblock erase is up to 30x
>> faster than block-by-block erase (not including erase verify, though).
>>
>> However, I only had possibility to test this with an OMAP board, so I
>> don't know if e.g. the default onenand_wait needs adjustment. Also for
>> Flex-OneNAND the support goes off. Does Flex even have mb erase?
>>
>> What do you think?
>
> I expect all OneNAND support multiblock erase, so the config should
> go away.  Kyungmin can probably comment on that.

Yes, I was thinking about that as well. Is it included in all chips?

> Waiting for multiblock-erase, you should probably spin, not use the
> interrupt line.  You should change the wait function in
> onenand_base and omap2.c.
>
> You should handle multiple multiblock erases.
>
> You should check for bad blocks *before* doing command 0x95

Ok

> Waiting for erase-verify, you should probably spin too.
>
I just tried that and it looks like spinning in verify read makes a
difference as I got 30% faster total time for 1600 block erase.

Thanks for good advice!
Mika

On Mon, Jun 15, 2009 at 8:02 PM, Mika Korhonen<mika.j.korhonen@gmail.com> wrote:
> 2009/6/15 Adrian Hunter <adrian.hunter@nokia.com>:
>> Mika Korhonen wrote:
>>>
>>> I wrote an initial support for OneNAND multiblock erase feature.  When
>>> done in maximum 64 eraseblock batches multiblock erase is up to 30x
>>> faster than block-by-block erase (not including erase verify, though).
>>>
>>> However, I only had possibility to test this with an OMAP board, so I
>>> don't know if e.g. the default onenand_wait needs adjustment. Also for
>>> Flex-OneNAND the support goes off. Does Flex even have mb erase?
>>>
>>> What do you think?
>>
>> I expect all OneNAND support multiblock erase, so the config should
>> go away.  Kyungmin can probably comment on that.
>
> Yes, I was thinking about that as well. Is it included in all chips?

So I got mistake, the Flex-OneNAND don't support the multi-block
erase. Instead it support the erase suspend & resume

Thank you,
Kyungmin Park