linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christophe KERELLO <christophe.kerello@st.com>
To: Huang Shijie <b32955@freescale.com>
Cc: marex@denx.de, angus.clark@st.com, computersforpeace@gmail.com,
	dwmw2@infradead.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: spi-nor: read 6 bytes for the ID
Date: Wed, 28 May 2014 18:27:34 +0200	[thread overview]
Message-ID: <53860E76.5010306@st.com> (raw)
In-Reply-To: <20140528052237.GA7984@shlinux1.ap.freescale.net>


On 05/28/2014 07:22 AM, Huang Shijie wrote:
> On Tue, May 27, 2014 at 05:57:31PM +0200, Christophe KERELLO wrote:
>> Hello Huang,
>>
>> I have one remark on this patch.
>>
>> S25FL128S flash has 2 variants:
>>   - Uniform 256-kB sectors (ext_id = 0x4D00)
>>   - 4-kB parameter sectors with uniform 64-kB sectors (ext_id = 0x4D01)
>>
>> If i would like to distinguish these 2 variants in spi_nor_ids
>> array, i replace:
>> { "s25fl128s", INFO(0x012018, 0x4d0180, 64 * 1024, 256,
>> SPI_NOR_QUAD_READ) },
>> with
>> { "s25fl128s0", INFO(0x012018, 0x4d0080, 256 * 1024, 64,
>> SPI_NOR_QUAD_READ) },
>> { "s25fl128s1", INFO(0x012018, 0x4d0180, 64 * 1024, 256,
>> SPI_NOR_QUAD_READ) },
>>
>> In this case, i fail to find s25fl128s1 device.
>>
>> The problem is coming from ext_jedec calculation.
>> first try:
>>      - jedec = 0x012018,
>>      - ext_jedec = 0x4d0180,
>>      - info->ext_id = 0x4d0080,
>>      =>s25fl128s0 doesn't match
>>
>> second try:
>>      - jedec = 0x012018,
>>      - ext_jedec = 0x4d018080,
>>      - info->ext_id = 0x4d0180,
>>      => s25fl128s1 doesn't match
>>
>> I think there is similar issue with s25fl129p1 (if i use this patch
>> without modifying it).
>> first try:
>>      - jedec = 0x012018,
>>      - ext_jedec = 0x4d01xx, (xx = probably 0x00 or 0xff)
>>      - info->ext_id = 0x4d0180,
>>      =>s25fl128s doesn't match
>>
>> second try:
>>      - jedec = 0x012018,
>>      - ext_jedec = 0x4d01xx,
>>      - info->ext_id = 0x4d01,
>>      => s25fl129p1 doesn't match
>>
>> If I reset ext_jedec after each try, it works.
>>
>> ext_jedec = ext_jedec << 8 | id[5];
>> if (info->ext_id == ext_jedec)
>>      return &spi_nor_ids[tmp];
>> else
>>      /* reset ext_jdec for next try */
>>      ext_jedec = ext_jedec >> 8;
>>
> hi Christophe:
>    thanks for pointing this!
>
>    Please try the new version.
>
> thanks
> Huang Shijie
Hello Huang,

Thanks.
Patch v2 works fine.

Regards,
Christophe Kerello.
>
> ---------------------------------------
>  From 7b920141899e4e7249bd23792dc8d5f1558cb7ca Mon Sep 17 00:00:00 2001
> From: Huang Shijie <b32955@freescale.com>
> Date: Mon, 14 Apr 2014 18:09:34 +0800
> Subject: [PATCH v2] mtd: spi-nor: read 6 bytes for the ID
>
> Currently, we read 5 bytes for ID, but s25fl128s has the same ext_id(0x4d01)
> with s25fl129p1. The s25fl128s can support the DDR Quad read, while s25fl129p1
> does not. So we have to distinguish the two NOR flashs.
>
> This patch reads out 6 bytes for the ID, and use the 6 bytes ID to search the
> right flash_info.
>
> The detail of the patch is:
>    [1] change the "ext_id" from u16 to u32.
>        We can store two bytes or three bytes with the @ext_id now.
>
>    [2] search the right flash_info with the 6byte ID and the new @ext_id.
>        We use "matched" variable to track the legacy two bytes @ext_id.
>        If the flash_info's @ext_id is three bytes, we will use the
>        sixth byte of the ID to check it.
>
>    [3] add the new item to spi_nor_ids for s25fl128s.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>   drivers/mtd/spi-nor/spi-nor.c |   30 +++++++++++++++++++++++++-----
>   1 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index c713c86..f21d3ef 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -383,7 +383,7 @@ struct flash_info {
>   	 * then a two byte device id.
>   	 */
>   	u32		jedec_id;
> -	u16             ext_id;
> +	u32		ext_id;
>   
>   	/* The size listed here is what works with SPINOR_OP_SE, which isn't
>   	 * necessarily called a "sector" by the vendor.
> @@ -505,6 +505,7 @@ const struct spi_device_id spi_nor_ids[] = {
>   	{ "s70fl01gs",  INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
>   	{ "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
>   	{ "s25sl12801", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
> +	{ "s25fl128s",	INFO(0x012018, 0x4d0180, 64 * 1024, 256, SPI_NOR_QUAD_READ) },
>   	{ "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024,  64, 0) },
>   	{ "s25fl129p1", INFO(0x012018, 0x4d01,  64 * 1024, 256, 0) },
>   	{ "s25sl004a",  INFO(0x010212,      0,  64 * 1024,   8, 0) },
> @@ -593,12 +594,13 @@ EXPORT_SYMBOL_GPL(spi_nor_ids);
>   static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
>   {
>   	int			tmp;
> -	u8			id[5];
> +	u8			id[6];
>   	u32			jedec;
> -	u16                     ext_jedec;
> +	u32                     ext_jedec;
>   	struct flash_info	*info;
> +	int			matched = -1;
>   
> -	tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 5);
> +	tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, 6);
>   	if (tmp < 0) {
>   		dev_dbg(nor->dev, " error %d reading JEDEC ID\n", tmp);
>   		return ERR_PTR(tmp);
> @@ -614,8 +616,26 @@ static const struct spi_device_id *spi_nor_read_id(struct spi_nor *nor)
>   	for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
>   		info = (void *)spi_nor_ids[tmp].driver_data;
>   		if (info->jedec_id == jedec) {
> -			if (info->ext_id == 0 || info->ext_id == ext_jedec)
> +			if (info->ext_id == 0)
>   				return &spi_nor_ids[tmp];
> +
> +			/* the legacy two bytes ext_id */
> +			if ((info->ext_id >> 16) == 0) {
> +				if (info->ext_id == ext_jedec)
> +					matched = tmp;
> +			} else {
> +				/* check the sixth byte now */
> +				ext_jedec = ext_jedec << 8 | id[5];
> +				if (info->ext_id == ext_jedec)
> +					return &spi_nor_ids[tmp];
> +
> +				/* reset back the ext_jedec */
> +				ext_jedec >>= 8;
> +			}
> +		} else {
> +			/* shortcut */
> +			if (matched != -1)
> +				return &spi_nor_ids[matched];
>   		}
>   	}
>   	dev_err(nor->dev, "unrecognized JEDEC id %06x\n", jedec);

  reply	other threads:[~2014-05-28 16:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 10:09 [PATCH] mtd: spi-nor: read 6 bytes for the ID Huang Shijie
2014-04-14 11:53 ` Marek Vasut
2014-04-14 14:44   ` Huang Shijie
2014-04-14 18:23     ` Marek Vasut
2014-04-15  5:22       ` Huang Shijie
2014-04-15 13:35         ` Marek Vasut
2014-04-15 16:04           ` Huang Shijie
2014-04-15 18:48             ` Marek Vasut
2014-04-16  1:52               ` Huang Shijie
2014-04-16 10:18                 ` Marek Vasut
2014-04-16 13:56                   ` Huang Shijie
2014-04-16 23:23                     ` Marek Vasut
2014-04-17  4:55                       ` Huang Shijie
2014-04-22  8:19           ` Huang Shijie
2014-05-27  1:12 ` Huang Shijie
2014-05-27 15:57   ` Christophe KERELLO
2014-05-28  5:22     ` Huang Shijie
2014-05-28 16:27       ` Christophe KERELLO [this message]
2014-05-29 20:58       ` Marek Vasut
2014-05-30  0:49         ` Huang Shijie
2014-06-03 14:23           ` Marek Vasut
2014-08-04 23:24       ` Brian Norris
2014-08-05  0:52         ` Huang Shijie
2014-08-05  7:14           ` Marek Vasut
2014-08-06  0:23             ` Huang Shijie

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=53860E76.5010306@st.com \
    --to=christophe.kerello@st.com \
    --cc=angus.clark@st.com \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).