All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: Pekon Gupta <pekon@ti.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org, balbi@ti.com,
	ezequiel.garcia@free-electrons.com,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH] mtd: nand: auto-detection of NAND bus-width from ONFI param or nand_id[]
Date: Tue, 26 Nov 2013 15:31:17 +0800	[thread overview]
Message-ID: <52944E45.6070803@freescale.com> (raw)
In-Reply-To: <1385382728-7913-1-git-send-email-pekon@ti.com>

于 2013年11月25日 20:32, Pekon Gupta 写道:
> This patch is alternative implementation for following commit which introduced
> NAND_BUSWIDTH_AUTO for detection of bus-width during device probe
>     commit 64b37b2a63eb2f80b65c7185f0013f8ffc637ae3
>     Author:     Matthieu CASTET<matthieu.castet@parrot.com>
>     AuthorDate: 2012-11-06
>
> As NAND device is identified only during nand_scan_ident(), so this patch
> assumes that NAND driver may un-initialized or partially congigured while
> calling nand_scan_ident(). Hence, this patch does following:
>
> (1) Temporarily configures 'bus-width=x8' mode before reading ONFI parameters,
>   (as required by ONFI spec Refer[*]), and then reverts to original bus-width.
>   This allows nand_flash_detect_onfi() to read ONFI paramers page even if
>   bus-width was un-initialized or incorrectly configured.
>
> (2) reconfigures driver with correct bus-width determined by:
>   - either by reading ONFI param OR
>   - as found in nand_flash_id[] table
>   So, any driver-specific callback overrides should be done post nand_scan_ident.
>
> This patch removes any dependency on either 'DT binding' or 'platform data' to
> for determining NAND device bus-width.
>
> [*] Reference: ONFI spec version 3.1 (section 3.5.3. Target Initialization)
>      "The Read ID and Read Parameter Page commands only use the lower 8-bits
>       of the data bus. The host shall not issue commands that use a word
>       data width on x16 devices until the host determines the device supports
>       a 16-bit data bus width in the parameter page."
>
>
> Signed-off-by: Pekon Gupta<pekon@ti.com>
> ---
>   drivers/mtd/nand/nand_base.c | 43 ++++++++++++++++++-------------------------
>   include/linux/mtd/nand.h     |  7 -------
>   2 files changed, 18 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index bd39f7b..3d581a4 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2942,14 +2942,9 @@ 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;
> -	}
> +	/* ONFI must be probed in 8-bit mode only, so switch to x8 mode */
> +	if (chip->options&  NAND_BUSWIDTH_16)
> +		nand_set_defaults(chip, 0);
>
>   	chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
>   	for (i = 0; i<  3; i++) {
> @@ -2962,7 +2957,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
>
>   	if (i == 3) {
>   		pr_err("Could not find valid ONFI parameter page; aborting\n");
> -		return 0;
> +		goto return_error;
>   	}
>
>   	/* Check version */
> @@ -2980,7 +2975,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
>
>   	if (!chip->onfi_version) {
>   		pr_info("%s: unsupported ONFI version: %d\n", __func__, val);
> -		return 0;
> +		goto return_error;
>   	}
>
>   	sanitize_string(p->manufacturer, sizeof(p->manufacturer));
> @@ -3033,6 +3028,12 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
>   	}
If it is 16bit bus, could we reconfigure the bus width in here?
it's better to limit the influence only in the ONFI code.

thanks
Huang Shijie


>
>   	return 1;

  parent reply	other threads:[~2013-11-26  7:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 12:32 [PATCH] mtd: nand: auto-detection of NAND bus-width from ONFI param or nand_id[] Pekon Gupta
2013-11-25 12:56 ` Ezequiel Garcia
2013-11-25 13:26   ` Gupta, Pekon
2013-11-25 13:32     ` Gupta, Pekon
2013-11-25 14:52     ` Ezequiel Garcia
2013-11-26  7:59       ` Gupta, Pekon
2013-11-26 12:42         ` Ezequiel Garcia
2013-11-27  6:03           ` Gupta, Pekon
2013-11-26  7:31 ` Huang Shijie [this message]
2013-11-26  7:49   ` Gupta, Pekon
2013-11-26  9:22     ` Huang Shijie
2013-11-26 12:45       ` Ezequiel Garcia
2013-11-29 12:18 ` Ezequiel Garcia
2013-11-29 12:28   ` Gupta, Pekon

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=52944E45.6070803@freescale.com \
    --to=b32955@freescale.com \
    --cc=balbi@ti.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    /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.