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: Sat, 30 Nov 2013 10:53:08 -0800	[thread overview]
Message-ID: <20131130185308.GG29397@norris.computersforpeace.net> (raw)
In-Reply-To: <20131130163535.GB2402@localhost>

On Sat, Nov 30, 2013 at 01:35:36PM -0300, Ezequiel Garcia wrote:
> 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;
>  	}

Hmm, that does seem like a hack. What command is giving you problems, by
the way? And is the NAND operational after this hack?

It looks like those two lines are there so that we can always specify
'column' in bytes, and nand_command() will do the byte/word translation
automatically. But we don't want this for certain commands, I think, so
maybe a "hack" is necessary...

> 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.

Yeah, it's a complement. At first, I though Uwe's patch included this,
but I was wrong.

Brian

  parent reply	other threads:[~2013-11-30 18:53 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
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 [this message]
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=20131130185308.GG29397@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.