public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Sergei Shtylylov <sshtylyov@ru.mvista.com>
To: Leif Lindholm <leif.lindholm@i3micro.com>, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
Date: Tue, 01 Nov 2005 18:29:39 +0300	[thread overview]
Message-ID: <436789E3.6010706@ru.mvista.com> (raw)
In-Reply-To: <1130856543.16267.38.camel@localhost>

Hello.

Leif Lindholm wrote:

> On Mon, 2005-10-31 at 08:00 -0800, Pete Popov wrote:
> 
>>>Just a comment (forgot to post this last time around):
>>>At least one of the chips we're using - identified as
>>>"NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)"
>>>seems to also need the CS manually asserted during a READID operation.
>>>
>>>This made the if-statements ridicilously long, so I added a case
>>>statement and a variable keeping track of wether or not to force-enable
>>>CS to the au1550_command function.
>>>
>>>If there is any interest, I could post a patch, but am unsure of the
>>>correct way. Should I send a new patch against cvs HEAD containing my
>>>trivial tweak as well as Sergeis modifications, or...?
>>
>>Send an incremental patch on top of Sergey's patch if you can.
> 
> 
> Attached is an incremental patch on top of Sergeys latest patch
> (yesterday). Is that's ok, or should I do the same for the old one?

    Alas, I have to NAK your patch.

> ------------------------------------------------------------------------
> 
> --- mtd/drivers/mtd/nand/au1550nd.c	2005-10-31 18:37:29.000000000 +0100
> +++ mtd-new/drivers/mtd/nand/au1550nd.c	2005-11-01 15:39:43.000000000 +0100
> @@ -343,6 +343,16 @@ static void au1550_command(struct mtd_in
>  	int ce_override = 0, i;
>  	ulong flags;
>  
> +	/* Decide wether command needs to force-enable CE or not */
> +	switch (command) {
> +	case NAND_CMD_READ0:
> +	case NAND_CMD_READ1:
> +	case NAND_CMD_READOOB:
> +	case NAND_CMD_READID:
> +		ce_override = 1;
> +		break;
> +	}
> +
>  	/* Begin command latch cycle */
>  	this->hwcontrol(mtd, NAND_CTL_SETCLE);
>  	/*
> @@ -382,9 +392,7 @@ static void au1550_command(struct mtd_in
>  		if (page_addr != -1) {
>  			this->write_byte(mtd, (u8)(page_addr & 0xff));
>  
> -			if (command == NAND_CMD_READ0 ||
> -			    command == NAND_CMD_READ1 ||
> -			    command == NAND_CMD_READOOB) {
> +			if (ce_override) {

    Note, that with NAND_CMD_READID page_addr of -1 is always passed (so we 
only write out the 1-byte column address) on the address phase, and we just 
won't get there for READID command....

>  				/*
>  				 * NAND controller will release -CE after
>  				 * the last address byte is written, so we'll
> @@ -393,7 +401,6 @@ static void au1550_command(struct mtd_in
>  				 * want the NOR flash or PCMCIA drivers to
>  				 * steal our precious bytes of data...
>  				 */
> -				ce_override = 1;
>  				local_irq_save(flags);

    Therefore, neither -CE wil be overridden nor local_irq_save() be executed 
for READID case...

>  				this->hwcontrol(mtd, NAND_CTL_SETNCE);
>  			}
> @@ -412,25 +419,7 @@ static void au1550_command(struct mtd_in
>  	 * Program and erase have their own busy handlers.
>  	 * Status and sequential in need no delay.
>  	 */
> -	switch (command) {
> -
> -	case NAND_CMD_PAGEPROG:
> -	case NAND_CMD_ERASE1:
> -	case NAND_CMD_ERASE2:
> -	case NAND_CMD_SEQIN:
> -	case NAND_CMD_STATUS:
> -		return;
> -
> -	case NAND_CMD_RESET:
> -		break;
> -
> -	case NAND_CMD_READ0:
> -	case NAND_CMD_READ1:
> -	case NAND_CMD_READOOB:
> -		/* Check if we're really driving -CE low (just in case) */
> -		if (unlikely(!ce_override))
> -			break;
> -
> +	if (ce_override) {
>  		/* Apply a short delay always to ensure that we do wait tWB. */
>  		ndelay(100);
>  		/* Wait for a chip to become ready... */
> @@ -442,6 +431,19 @@ static void au1550_command(struct mtd_in
>  		local_irq_restore(flags);

    ... and later you get the CPU flags corrupted.

>  		return;
>  	}
> +
> +	switch (command) {
> +
> +	case NAND_CMD_PAGEPROG:
> +	case NAND_CMD_ERASE1:
> +	case NAND_CMD_ERASE2:
> +	case NAND_CMD_SEQIN:
> +	case NAND_CMD_STATUS:
> +		return;
> +		
> +	case NAND_CMD_RESET:
> +		break;
> +	}
>  	/* Apply this short delay always to ensure that we do wait tWB. */
>  	ndelay(100);

    Has your READID problem arisen with or without my patch?

WBR, Sergei

  reply	other threads:[~2005-11-01 15:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-29 20:44 [PATCH] NAND: Fix NAND ECC errors on AMD Au1550 Sergei Shtylylov
2005-10-30  4:36 ` Pete Popov
2005-10-31  7:58 ` Pete Popov
2005-10-31 14:39   ` Leif Lindholm
2005-10-31 16:00     ` Pete Popov
2005-11-01 14:49       ` Leif Lindholm
2005-11-01 15:29         ` Sergei Shtylylov [this message]
2005-11-01 15:50           ` Leif Lindholm
2005-11-01 16:31             ` Sergei Shtylylov
2005-10-31 17:55     ` Sergei Shtylylov
2005-11-01  8:53 ` Pantelis Antoniou
2005-11-01 12:49   ` Sergei Shtylylov
2005-11-01 13:00     ` Pantelis Antoniou

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=436789E3.6010706@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=leif.lindholm@i3micro.com \
    --cc=linux-mtd@lists.infradead.org \
    /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