headers
Kyungmin Park | 1 Feb 2007 02:49
Favicon

[PATCH] OneNAND: Reduce internal bufferram operation

[PATCH] OneNAND: Reduce internal bufferram operation

It use blockpage instead of a pair (block, page). It can also cover a small
chunk access. 0x00, 0x20, 0x40 and so on.

And in JFFS2 behavior, sometimes it reads two pages alternatively.
e.g., It first reads A page, B page and A page.
So we check another bufferram to find requested page.

Any comments are welcome.

Thank you,
Kyungmin Park

--

diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 67efbc7..5c0d55f 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
 <at>  <at>  -577,19 +577,22  <at>  <at>  static int onenand_write_bufferram(struct mtd_info
*mtd, int area,
 static int onenand_check_bufferram(struct mtd_info *mtd, loff_t addr)
 {
 	struct onenand_chip *this = mtd->priv;
-	int block, page;
-	int i;
+	int blockpage;
+	unsigned int i;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyungmin Park | 1 Feb 2007 03:26
Favicon

RE: [PATCH] [MTD] OneNAND: Add support for auto-placementofout-of-banddata

I'll push it.

But with JFFS2 patch, there's one bug (see below)

I'l fix it and commit it.

Thank you,
Kyungmin Park

> +static int onenand_fill_auto_oob(struct mtd_info *mtd, 
> u_char *oob_buf,
> +				  const u_char *buf, int 
> column, int thislen) {
> +	struct onenand_chip *this = mtd->priv;
> +	struct nand_oobfree *free;
> +	int writecol = column;
> +	int writeend = column + thislen;
> +	int lastgap = 0;
> +
> +	for (free = this->ecclayout->oobfree; free->length; ++free) {
> +		if (writecol >= lastgap)
> +			writecol += free->offset - lastgap;
> +		if (writeend >= lastgap)
> +			writeend += free->offset - lastgap;
> +		lastgap = free->offset + free->length;
> +	}

> +	writeend = mtd->oobsize;

We don't re-assign the 'writeend'. It cause the block is not clean. Since
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kyungmin Park | 1 Feb 2007 04:13
Favicon

RE: [PATCH] [MTD] OneNAND: Add support for auto-placementofout-of-banddata


>  /**
> + * onenand_transfer_auto_oob - [Internal] oob auto-placement transfer
> + *  <at> param mtd		MTD device structure
> + *  <at> param buf		destination address
> + *  <at> param column	oob offset to read from
> + *  <at> param thislen	oob length to read
> + */
> +static int onenand_transfer_auto_oob(struct mtd_info *mtd, 
> uint8_t *buf, int column,
> +				int thislen)
> +{
> +	struct onenand_chip *this = mtd->priv;
> +	struct nand_oobfree *free;
> +	int readcol = column;
> +	int readend = column + thislen;
> +	int lastgap = 0;
> +	uint8_t *oob_buf = this->page_buf + mtd->writesize;
> +
> +	for (free = this->ecclayout->oobfree; free->length; ++free) {
> +		if (readcol >= lastgap)
> +			readcol += free->offset - lastgap;
> +		if (readend >= lastgap)
> +			readend += free->offset - lastgap;
> +		lastgap = free->offset + free->length;
> +	}
> +	this->read_bufferram(mtd, ONENAND_SPARERAM, oob_buf + readcol,
> +			     readcol, readend - readcol);

How about to read full oobsize? since 32 bytes memcpy is optimized.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gavin Lambert | 1 Feb 2007 04:30

Driver-specific ioctls

I came across a situation the other day where I wanted to get some more
esoteric data from an MTD chip driver into userspace (mostly for
debugging purposes).  Sadly (at least in 2.6.15) mtdchar doesn't pass
any unrecognised ioctls to the MTD driver, which seems like the cleanest
way to do that sort of thing.

Any chance that this could get added?  Or is there a similar mechanism
already that I have somehow missed?

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 1 comment |
headers
Kyungmin Park | 1 Feb 2007 06:15
Favicon

RE: [RFC] [PATCH] JFFS2: use MTD_OOB_AUTO

Hi Artem,

> 
> Here is a patch which teaches JFFS2 to use MTD_OOB_AUTO 
> option which makes much more sense then using MTD_OOB_PLACE. 
> The original motivation was that JFFS2 does not work on 
> OneNAND which has tricky location of free bytes at OOB.
> 
> The patch was not well tested yet, just a brief test with 
> nandsim. So it is just an RFC now.

After a minor MTD_OOB_AUTO in OneNAND, it's running.

I'll check and test it more. 

I think that it changes the previous jffs2 format. it means it brakes the
jffs2 backward compatibility.
So how about adding new configuration e.g., CONFIG_JFFS2_AUTOOOB or another
approache
then user choose the oob policy (OOB_PLACE or OOB_AUTO) or runtime
dectection???
I'm not sure what is the best one

And one more.
Please re-place the 'oob_cleanmarker' initialization like this. It's almost
constant variable.
We don't need to re-init at every jffs2 mount time.

% in fs/jffs2/wbuf.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
Artem Bityutskiy | 1 Feb 2007 08:14
Favicon

Re: Driver-specific ioctls

On Thu, 2007-02-01 at 16:30 +1300, Gavin Lambert wrote:
> I came across a situation the other day where I wanted to get some more
> esoteric data from an MTD chip driver into userspace (mostly for
> debugging purposes).  Sadly (at least in 2.6.15) mtdchar doesn't pass
> any unrecognised ioctls to the MTD driver, which seems like the cleanest
> way to do that sort of thing.

Add sysfs support to mtd and export nearly any data outside.

--

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Adrian Hunter | 1 Feb 2007 08:43
Picon

Re: [PATCH] [MTD] OneNAND: Add support for auto-placementofout-of-banddata

ext Kyungmin Park wrote:
>> +	writeend = mtd->oobsize;
> 
> We don't re-assign the 'writeend'. It cause the block is not clean. Since
> JFFS2 send only 12 bytes but onenand writes until oobsize, actually 20
> bytes with zero.
> So this statement will be removed.

Yes, that was a typo.  The line should have been deleted when the previous
line was deleted.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 3 comments |
headers
Artem Bityutskiy | 1 Feb 2007 08:56
Favicon

RE: [RFC] [PATCH] JFFS2: use MTD_OOB_AUTO

Hi Kyungmin,

On Thu, 2007-02-01 at 14:15 +0900, Kyungmin Park wrote:
> After a minor MTD_OOB_AUTO in OneNAND, it's running.
> I'll check and test it more. 
Thank you.

> I think that it changes the previous jffs2 format. it means it brakes the
> jffs2 backward compatibility.
Yes, but I suspect this should not be a problem. The worst thing that
should happen is that JFFS2 will just re-erase empty eraseblocks once.
We will test this.

> And one more.
> Please re-place the 'oob_cleanmarker' initialization like this. It's almost
> constant variable.
> We don't need to re-init at every jffs2 mount time.
Good point, thanks. I'll re-send the patch.

--

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 1 Feb 2007 08:57
Favicon

[RFC] [PATCH take 2] JFFS2: use MTD_OOB_AUTO

From: Artem Bityutskiy <Artem.Bityutskiy <at> nokia.com>
Date: Wed, 31 Jan 2007 11:38:53 +0200
Subject: [PATCH] [JFFS2] use MTD_OOB_AUTO

Nowadays MTD supports an MTD_OOB_AUTO option which allows users
to access free bytes in NAND's OOB as a contiguous buffer, although
it may be highly discontinuous.

This patch teaches JFFS2 to use this nice feature instead of the
old MTD_OOB_PLACE option. This for example caused problems with
OneNAND. Now JFFS2 does not care how are the free bytes situated.

This may change position of the clean marker on some flashes,
but this is not a problem. JFFS2 will just re-erase the empty
eraseblocks and write the new (correct) clean marker.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy <at> nokia.com>
---
 fs/jffs2/jffs2_fs_sb.h |   12 +--
 fs/jffs2/scan.c        |   10 ++-
 fs/jffs2/wbuf.c        |  206 +++++++++++++++++-------------------------------
 3 files changed, 84 insertions(+), 144 deletions(-)

Index: dedekind-mtd-2.6.git/fs/jffs2/jffs2_fs_sb.h
===================================================================
--- dedekind-mtd-2.6.git.orig/fs/jffs2/jffs2_fs_sb.h
+++ dedekind-mtd-2.6.git/fs/jffs2/jffs2_fs_sb.h
 <at>  <at>  -98,20 +98,14  <at>  <at>  struct jffs2_sb_info {
 	uint32_t wbuf_pagesize; /* 0 for NOR and other flashes with no wbuf */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian Hunter | 1 Feb 2007 09:02
Picon

Re: [PATCH] [MTD] OneNAND: Add support for auto-placementofout-of-banddata

ext Adrian Hunter wrote:
> ext Kyungmin Park wrote:
>>> +	writeend = mtd->oobsize;
>> We don't re-assign the 'writeend'. It cause the block is not clean. Since
>> JFFS2 send only 12 bytes but onenand writes until oobsize, actually 20
>> bytes with zero.
>> So this statement will be removed.
> 
> Yes, that was a typo.  The line should have been deleted when the previous
> line was deleted.

The statement still seems to be in the onenand tree.  Here is a patch to remove it.

>From 397419987d744ed971c74cfabae2eeac705f2fe0 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <ext-adrian.hunter <at> nokia.com>
Date: Thu, 1 Feb 2007 09:59:41 +0200
Subject: [MTD] OneNAND: Remove line of code that was meant to be deleted

Iterations of the patch to add oob auto-placement support to
OneNAND left a line of code that was meant to have been deleted.

Signed-off-by: Adrian Hunter <ext-adrian.hunter <at> nokia.com>
---
 drivers/mtd/onenand/onenand_base.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 67efbc7..9ec28bb 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
(Continue reading)

Permalink | Reply | 2 comments |

Gmane