All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: "Huang Shijie" <b32955@freescale.com>,
	linux-mtd@lists.infradead.org, "Pekon Gupta" <pekon@ti.com>,
	kernel@pengutronix.de,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH v3] mtd/nand: don't use {read,write}_buf for 8-bit transfers
Date: Sat, 30 Nov 2013 13:35:36 -0300	[thread overview]
Message-ID: <20131130163535.GB2402@localhost> (raw)
In-Reply-To: <20131130060428.GA29397@norris.computersforpeace.net>

On Fri, Nov 29, 2013 at 10:04:28PM -0800, Brian Norris wrote:
> 
> Unfortunately, I realized that Uwe's patch doesn't go far enough, I
> don't think. It looks like it needs something like the following diff
> (only compile-tested).
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index bd39f7b67906..1ab264457d94 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2933,7 +2933,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
>  					int *busw)
>  {
>  	struct nand_onfi_params *p = &chip->onfi_params;
> -	int i;
> +	int i, j;
>  	int val;
>  
>  	/* Try ONFI for unknown chip or LP */
> @@ -2942,18 +2942,10 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
>  		chip->read_byte(mtd) != 'F' || chip->read_byte(mtd) != 'I')
>  		return 0;
>  
> -	/*
> -	 * ONFI must be probed in 8-bit mode or with NAND_BUSWIDTH_AUTO, not
> -	 * with NAND_BUSWIDTH_16
> -	 */
> -	if (chip->options & NAND_BUSWIDTH_16) {
> -		pr_err("ONFI cannot be probed in 16-bit mode; aborting\n");
> -		return 0;
> -	}
> -
>  	chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
>  	for (i = 0; i < 3; i++) {
> -		chip->read_buf(mtd, (uint8_t *)p, sizeof(*p));
> +		for (j = 0; j < sizeof(*p); j++)
> +			*(uint8_t *)p = chip->read_byte(mtd);
>  		if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
>  				le16_to_cpu(p->crc)) {
>  			break;
> 
> What do you think? (And more importantly, how does this test out for
> you?)
> 

Your proposal would work (fixing a minor typo for incrementing 'p'),
except the nand_command() implementation messes with the buswith.
Therefore, after a long debugging session, I could make it work using
this hack:

@@ -542,8 +545,8 @@ static void nand_command(struct mtd_info *mtd, unsigned int command,
 	/* Serially input address */
 	if (column != -1) {
 		/* Adjust columns for 16 bit buswidth */
-		if (chip->options & NAND_BUSWIDTH_16)
-			column >>= 1;
+//		if (chip->options & NAND_BUSWIDTH_16)
+//			column >>= 1;
 		chip->cmd_ctrl(mtd, column, ctrl);
 		ctrl &= ~NAND_CTRL_CHANGE;
 	}

Now, IMHO, the solution of setting the defaults to x8 during the device
detection phase, is far simpler.

BTW: this is not really related to Uwe's patch, right? It's just a complement
to his work, as far as I can see.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

  parent reply	other threads:[~2013-11-30 16:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 10:19 [PATCH] mtdchar: handle chips that have user otp but no factory otp Uwe Kleine-König
2013-03-02 15:41 ` Artem Bityutskiy
2013-03-02 21:08   ` Uwe Kleine-König
2013-03-04 16:35 ` [PATCH v2] " Uwe Kleine-König
2013-03-04 16:47   ` [PATCH v2] mtd/nand: don't use {read,write}_buf for 8-bit transfers Uwe Kleine-König
2013-03-04 16:50     ` Uwe Kleine-König
2013-03-05  2:00       ` [PATCH v2] mtd/nand: don't use {read, write}_buf " Huang Shijie
2013-03-13  9:33     ` [PATCH v2] mtd/nand: don't use {read,write}_buf " Artem Bityutskiy
2013-11-26 21:03       ` Uwe Kleine-König
2013-11-27  6:59         ` Brian Norris
2013-03-13 10:26     ` Artem Bityutskiy
2013-04-05 12:13     ` David Woodhouse
2013-11-26 21:15       ` [PATCH v3] " Uwe Kleine-König
2013-11-27  7:35         ` Brian Norris
2013-11-29 12:20           ` Ezequiel Garcia
2013-11-30  6:04             ` Brian Norris
2013-11-30 11:19               ` Ezequiel Garcia
2013-11-30 16:35               ` Ezequiel Garcia [this message]
2013-11-30 16:51                 ` Ezequiel Garcia
2013-11-30 19:01                   ` Brian Norris
2013-11-30 21:06                     ` Ezequiel Garcia
2013-12-02 19:40                       ` Gupta, Pekon
2013-11-30 18:53                 ` Brian Norris
2013-11-30 20:57                   ` Ezequiel Garcia
2013-12-05 21:22           ` [PATCH v4] " Uwe Kleine-König
2013-12-17  5:48             ` Brian Norris
2013-12-17 21:46               ` Ezequiel Garcia
2013-12-19  7:39                 ` Brian Norris
2014-01-14  8:12             ` Brian Norris
2014-01-14  8:29               ` Uwe Kleine-König
2013-03-06  8:47   ` [PATCH v2] mtdchar: handle chips that have user otp but no factory otp Artem Bityutskiy
2013-03-06  8:51     ` Uwe Kleine-König

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=20131130163535.GB2402@localhost \
    --to=ezequiel.garcia@free-electrons.com \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    --cc=u.kleine-koenig@pengutronix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.