All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.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: Fri, 29 Nov 2013 22:04:28 -0800	[thread overview]
Message-ID: <20131130060428.GA29397@norris.computersforpeace.net> (raw)
In-Reply-To: <20131129122018.GB2815@localhost>

Hi Ezequiel,

On Fri, Nov 29, 2013 at 09:20:19AM -0300, Ezequiel Garcia wrote:
> On Tue, Nov 26, 2013 at 11:35:12PM -0800, Brian Norris wrote:
> > + Pekon, Ezequiel
> > 
> > Can one of you see how this patch works with your BeagleBones w/ x16
> > NAND?

I see that you are pushing to straighten out the auto-buswidth part of
nand_base, and I think there may be good reasons to do so. But I think
that part of your problem can be resolved by a patch like Uwe's, where
rather than forcing the entire driver to be configured for x8 just to
use ONFI, we can fix the ONFI operations to use the lower 8 bits.

IOW, I expect that a patch like Uwe's can shed some better light on the
auto-buswidh situation. (This is why I CC'd you and Pekon.)

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?)

Brian

  reply	other threads:[~2013-11-30  6:05 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 [this message]
2013-11-30 11:19               ` Ezequiel Garcia
2013-11-30 16:35               ` Ezequiel Garcia
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=20131130060428.GA29397@norris.computersforpeace.net \
    --to=computersforpeace@gmail.com \
    --cc=b32955@freescale.com \
    --cc=ezequiel.garcia@free-electrons.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.