public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vwool@ru.mvista.com>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] NAND: fix reading/writing OOB for syndrome
Date: Tue, 13 Jun 2006 19:48:14 +0400	[thread overview]
Message-ID: <20060613194814.4ee01f06.vwool@ru.mvista.com> (raw)
In-Reply-To: <1150212895.5257.342.camel@localhost.localdomain>

On Tue, 13 Jun 2006 17:34:55 +0200
Thomas Gleixner <tglx@linutronix.de> wrote:

> ???? You want to read in the data area of the FLASH !

No, it becomes a requirement to the NAND chip driver to convert NAND_CMD_READOOB to what's appropriate for the chip.
If we require the chip driver to be able to convert NAND_CMD_READOOB with offset 0, why not require it to convert it properly for other offsets?
 
> > +		chip->cmdfunc(mtd, NAND_CMD_READOOB, (i + 1) * portion, page);
> 
> 		CMD_READOOB is simply wrong 
> 
> Also it ignores the prepad and postpad parts.

See above.
I read all the OOB by portions for the (data, oob+ecc) x eccsteps layout.
I don't distinguish between spare OOB and ECC so I don't need to take prepad/postpad into account.
We'll just need another couple of funcs for syndromes that imply ( (data, ecc) x eccsteps, oob) layout.
 
> > +	for (i = 0; i < chip->ecc.steps; i++) {
> > +		if (offs < portion) {
> > +			int status;
> > +			chip->cmdfunc(mtd, NAND_CMD_SEQIN,
> > +				      eccsize + i * (eccsize + portion) + offs,
> > +				      page);
> > +			len = min_t(int, length, portion - offs);
> > +			chip->write_buf(mtd, bufpoi, len);
> > +			bufpoi += len;
> > +			length -= len;
> > +			offs = 0;
> > +
> > +			if (i < chip->ecc.steps - 1) {
> > +				chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
> > +				status = chip->waitfunc(mtd, chip, FL_WRITING);
> > +
> > +				/* See if device thinks it succeeded */
> > +				if (status & NAND_STATUS_FAIL)
> > +					DEBUG(MTD_DEBUG_LEVEL0, "%s: "
> > +					      "Failed write, page 0x%08x\n",
> > +					      __FUNCTION__, page);
> > +			}
> > +		} else
> > +			offs -= portion;
> > +	}
> > +}
> > +
> 
> What about the prepad and postpad parts ?

See above.
 
> > +/**
> >   * nand_do_read_oob - [Intern] NAND read out-of-band
> >   * @mtd:	MTD device structure
> >   * @from:	offset to read from
> > @@ -1127,7 +1254,7 @@ static int nand_do_read_oob(struct mtd_i
> >  			sndcmd = 0;
> >  		}
> >  
> > -		chip->read_buf(mtd, bufpoi, bytes);
> > +		chip->ecc.read_oob(mtd, chip, bufpoi, col, bytes, page);
> >  
> >  		if (unlikely(!direct))
> >  			buf = nand_transfer_oob(chip, buf, ops);
> 
> The direct part should go away and done inside the read functions.

Hmmm... Probably.

 
> > @@ -1598,13 +1726,15 @@ static int nand_do_write_oob(struct mtd_
> >  		nand_fill_oob(chip, ops->oobbuf, ops);
> >  		chip->cmdfunc(mtd, NAND_CMD_SEQIN, mtd->writesize,
> >  			      page & chip->pagemask);
> 
> You put it unconditionally into oob area !!!

Can you please elaborate what's wrong there?

> > -		chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
> > +		chip->ecc.write_oob(mtd, chip, chip->oob_poi, 0, mtd->oobsize,
> > +				    page & chip->pagemask);
> >  		memset(chip->oob_poi, 0xff, mtd->oobsize);
> >  	} else {
> >  		chip->cmdfunc(mtd, NAND_CMD_SEQIN,
> >  			      mtd->writesize + ops->ooboffs,
> >  			      page & chip->pagemask);
> 
> Same here !

And there.


Vitaly

  reply	other threads:[~2006-06-13 15:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-13 15:01 [PATCH] NAND: fix reading/writing OOB for syndrome Vitaly Wool
2006-06-13 15:34 ` Thomas Gleixner
2006-06-13 15:48   ` Vitaly Wool [this message]
2006-06-13 15:52     ` Thomas Gleixner
2006-06-13 15:56       ` Vitaly Wool
2006-06-13 16:29         ` Vitaly Wool
  -- strict thread matches above, loose matches on Subject: below --
2006-06-07 10:39 Vitaly Wool

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=20060613194814.4ee01f06.vwool@ru.mvista.com \
    --to=vwool@ru.mvista.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox