[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

This series update SPI flash supported read commands per datasheet
in the flash params table, and change flash sector size to 4KiB as
long as flash supports sector erase (20h) command, to ensure
'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
given SECT_4K.

Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/


Bin Meng (9):
  sf: Update SST flash params
  sf: Update Atmel flash params
  sf: Update EON flash params
  sf: Update GigaDevice flash params
  sf: Update Macronix flash params
  sf: Update Spansion flash params
  sf: Update Micron flash params
  sf: Update Winbond flash params
  sf: Give proper spacing between flash table params

 drivers/mtd/spi/sf_internal.h |   5 ++
 drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
 drivers/mtd/spi/sf_probe.c    |   4 +
 3 files changed, 104 insertions(+), 90 deletions(-)

-- 
1.8.2.1

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Update SST25VF064C read command to RD_EXTN per datasheet.
Also change flash sector size to 4KiB to match SECT_4K.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 30875b3..5482700 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"N25Q1024A",	   0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SST		/* SST */
-	{"SST25VF040B",	   0xbf258d, 0x0,	64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
-	{"SST25VF080B",	   0xbf258e, 0x0,	64 * 1024,    16, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25VF016B",	   0xbf2541, 0x0,	64 * 1024,    32, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25VF032B",	   0xbf254a, 0x0,	64 * 1024,    64, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25VF064C",	   0xbf254b, 0x0,	64 * 1024,   128, RD_NORM,		     SECT_4K},
-	{"SST25WF512",	   0xbf2501, 0x0,	64 * 1024,     1, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25WF010",	   0xbf2502, 0x0,	64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
-	{"SST25WF020",	   0xbf2503, 0x0,	64 * 1024,     4, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25WF040",	   0xbf2504, 0x0,	64 * 1024,     8, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25WF080",	   0xbf2505, 0x0,	64 * 1024,    16, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25VF040B",	   0xbf258d, 0x0,	 4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
+	{"SST25VF080B",	   0xbf258e, 0x0,	 4 * 1024,   256, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25VF016B",	   0xbf2541, 0x0,	 4 * 1024,   512, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25VF032B",	   0xbf254a, 0x0,	 4 * 1024,  1024, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25VF064C",	   0xbf254b, 0x0,	 4 * 1024,  2048, RD_EXTN,		     SECT_4K},
+	{"SST25WF512",	   0xbf2501, 0x0,	 4 * 1024,    16, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25WF010",	   0xbf2502, 0x0,	 4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
+	{"SST25WF020",	   0xbf2503, 0x0,	 4 * 1024,    64, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25WF040",	   0xbf2504, 0x0,	 4 * 1024,   128, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25WF080",	   0xbf2505, 0x0,	 4 * 1024,   256, RD_NORM,	    SECT_4K | SST_WR},
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND		/* WINBOND */
 	{"W25P80",	   0xef2014, 0x0,	64 * 1024,    16, RD_NORM,		           0},
-- 
1.8.2.1

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

I think you have a different interpretation of sector size here-

/* The size listed here is what works with SPINOR_OP_SE, which isn't
 * necessarily called a "sector" by the vendor.
 */
Say for example SST25VF040B has 8 sectors of which each sector size is
64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
64K sector erase through flags.

Linux does follow the same-
        /* SST -- large erase sizes are "overlays", "sectors" are 4K */
        { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
SST_WRITE) },
        { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
SST_WRITE) },
        { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
SST_WRITE) },
        { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
SST_WRITE) },

Please check it.

On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> Update SST25VF064C read command to RD_EXTN per datasheet.
> Also change flash sector size to 4KiB to match SECT_4K.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 30875b3..5482700 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
>         {"N25Q1024A",      0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
>  #endif
>  #ifdef CONFIG_SPI_FLASH_SST            /* SST */
> -       {"SST25VF040B",    0xbf258d, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25VF080B",    0xbf258e, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25VF016B",    0xbf2541, 0x0,       64 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25VF032B",    0xbf254a, 0x0,       64 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25VF064C",    0xbf254b, 0x0,       64 * 1024,   128, RD_NORM,                   SECT_4K},
> -       {"SST25WF512",     0xbf2501, 0x0,       64 * 1024,     1, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25WF010",     0xbf2502, 0x0,       64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25WF020",     0xbf2503, 0x0,       64 * 1024,     4, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25WF040",     0xbf2504, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
> -       {"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25VF040B",    0xbf258d, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25VF080B",    0xbf258e, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25VF016B",    0xbf2541, 0x0,        4 * 1024,   512, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25VF032B",    0xbf254a, 0x0,        4 * 1024,  1024, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25VF064C",    0xbf254b, 0x0,        4 * 1024,  2048, RD_EXTN,                   SECT_4K},
> +       {"SST25WF512",     0xbf2501, 0x0,        4 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25WF010",     0xbf2502, 0x0,        4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25WF020",     0xbf2503, 0x0,        4 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25WF040",     0xbf2504, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
> +       {"SST25WF080",     0xbf2505, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
>  #endif
>  #ifdef CONFIG_SPI_FLASH_WINBOND                /* WINBOND */
>         {"W25P80",         0xef2014, 0x0,       64 * 1024,    16, RD_NORM,                         0},
> --
> 1.8.2.1
>

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Hi Jagan,

On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> I think you have a different interpretation of sector size here-
>
> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>  * necessarily called a "sector" by the vendor.
>  */
> Say for example SST25VF040B has 8 sectors of which each sector size is
> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
> 64K sector erase through flags.
>
> Linux does follow the same-
>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
> SST_WRITE) },
>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
> SST_WRITE) },
>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
> SST_WRITE) },
>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
> SST_WRITE) },
>
> Please check it.


Yes, I know this pretty well. And I want to change this behavior, as
my cover letter says.

Currently the 'sf erase' command operates on a 64KB granularity, while
the actual erase command is 4KB granularity, which is inconsistent and
causes confusion.

> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Update SST25VF064C read command to RD_EXTN per datasheet.
>> Also change flash sector size to 4KiB to match SECT_4K.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index 30875b3..5482700 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
>>         {"N25Q1024A",      0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
>>  #endif
>>  #ifdef CONFIG_SPI_FLASH_SST            /* SST */
>> -       {"SST25VF040B",    0xbf258d, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25VF080B",    0xbf258e, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25VF016B",    0xbf2541, 0x0,       64 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25VF032B",    0xbf254a, 0x0,       64 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25VF064C",    0xbf254b, 0x0,       64 * 1024,   128, RD_NORM,                   SECT_4K},
>> -       {"SST25WF512",     0xbf2501, 0x0,       64 * 1024,     1, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25WF010",     0xbf2502, 0x0,       64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25WF020",     0xbf2503, 0x0,       64 * 1024,     4, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25WF040",     0xbf2504, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
>> -       {"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25VF040B",    0xbf258d, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25VF080B",    0xbf258e, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25VF016B",    0xbf2541, 0x0,        4 * 1024,   512, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25VF032B",    0xbf254a, 0x0,        4 * 1024,  1024, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25VF064C",    0xbf254b, 0x0,        4 * 1024,  2048, RD_EXTN,                   SECT_4K},
>> +       {"SST25WF512",     0xbf2501, 0x0,        4 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25WF010",     0xbf2502, 0x0,        4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25WF020",     0xbf2503, 0x0,        4 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25WF040",     0xbf2504, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
>> +       {"SST25WF080",     0xbf2505, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
>>  #endif
>>  #ifdef CONFIG_SPI_FLASH_WINBOND                /* WINBOND */
>>         {"W25P80",         0xef2014, 0x0,       64 * 1024,    16, RD_NORM,                         0},
>> --

Regards,
Bin

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> I think you have a different interpretation of sector size here-
>>
>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>  * necessarily called a "sector" by the vendor.
>>  */
>> Say for example SST25VF040B has 8 sectors of which each sector size is
>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>> 64K sector erase through flags.
>>
>> Linux does follow the same-
>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>> SST_WRITE) },
>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>> SST_WRITE) },
>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>> SST_WRITE) },
>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>> SST_WRITE) },
>>
>> Please check it.
>
>
> Yes, I know this pretty well. And I want to change this behavior, as
> my cover letter says.
>
> Currently the 'sf erase' command operates on a 64KB granularity, while
> the actual erase command is 4KB granularity, which is inconsistent and
> causes confusion.

It never related to 'sf erase' instead based on the 'params->flags'
sf_probe will decide which erase_cmd with erase_size will use.
        /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096 << flash->shift;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768 << flash->shift;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

And to be honest, these flashes were tested with lowest ie 4KB so even if they
do support 64KB, we mentioned on 4KB on 'params->flags' as we tested
well with that
and it works consistently.

>
>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Update SST25VF064C read command to RD_EXTN per datasheet.
>>> Also change flash sector size to 4KiB to match SECT_4K.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>>  drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
>>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>>> index 30875b3..5482700 100644
>>> --- a/drivers/mtd/spi/sf_params.c
>>> +++ b/drivers/mtd/spi/sf_params.c
>>> @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
>>>         {"N25Q1024A",      0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
>>>  #endif
>>>  #ifdef CONFIG_SPI_FLASH_SST            /* SST */
>>> -       {"SST25VF040B",    0xbf258d, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25VF080B",    0xbf258e, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25VF016B",    0xbf2541, 0x0,       64 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25VF032B",    0xbf254a, 0x0,       64 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25VF064C",    0xbf254b, 0x0,       64 * 1024,   128, RD_NORM,                   SECT_4K},
>>> -       {"SST25WF512",     0xbf2501, 0x0,       64 * 1024,     1, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25WF010",     0xbf2502, 0x0,       64 * 1024,     2, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25WF020",     0xbf2503, 0x0,       64 * 1024,     4, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25WF040",     0xbf2504, 0x0,       64 * 1024,     8, RD_NORM,          SECT_4K | SST_WR},
>>> -       {"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25VF040B",    0xbf258d, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25VF080B",    0xbf258e, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25VF016B",    0xbf2541, 0x0,        4 * 1024,   512, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25VF032B",    0xbf254a, 0x0,        4 * 1024,  1024, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25VF064C",    0xbf254b, 0x0,        4 * 1024,  2048, RD_EXTN,                   SECT_4K},
>>> +       {"SST25WF512",     0xbf2501, 0x0,        4 * 1024,    16, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25WF010",     0xbf2502, 0x0,        4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25WF020",     0xbf2503, 0x0,        4 * 1024,    64, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25WF040",     0xbf2504, 0x0,        4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
>>> +       {"SST25WF080",     0xbf2505, 0x0,        4 * 1024,   256, RD_NORM,          SECT_4K | SST_WR},
>>>  #endif
>>>  #ifdef CONFIG_SPI_FLASH_WINBOND                /* WINBOND */
>>>         {"W25P80",         0xef2014, 0x0,       64 * 1024,    16, RD_NORM,                         0},
>>> --


thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Hi Jagan,

On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> I think you have a different interpretation of sector size here-
>>>
>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>  * necessarily called a "sector" by the vendor.
>>>  */
>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>> 64K sector erase through flags.
>>>
>>> Linux does follow the same-
>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>> SST_WRITE) },
>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>> SST_WRITE) },
>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>> SST_WRITE) },
>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>> SST_WRITE) },
>>>
>>> Please check it.
>>
>>
>> Yes, I know this pretty well. And I want to change this behavior, as
>> my cover letter says.
>>
>> Currently the 'sf erase' command operates on a 64KB granularity, while
>> the actual erase command is 4KB granularity, which is inconsistent and
>> causes confusion.
>
> It never related to 'sf erase' instead based on the 'params->flags'
> sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

static int sf_parse_len_arg(char *arg, ulong *len)
{
    char *ep;
    char round_up_len; /* indicates if the "+length" form used */
    ulong len_arg;

    round_up_len = 0;
    if (*arg == '+') {
        round_up_len = 1;
        ++arg;
    }

    len_arg = simple_strtoul(arg, &ep, 16);
    if (ep == arg || *ep != '\0')
        return -1;

    if (round_up_len && flash->sector_size > 0)
        *len = ROUND(len_arg, flash->sector_size);
    else
        *len = len_arg;

    return 1;
}

So even you are passing 4KB in the flash params, the 'sf erase'
command WILL erase 64KB.

>         /* Compute erase sector and command */
>         if (params->flags & SECT_4K) {
>                 flash->erase_cmd = CMD_ERASE_4K;
>                 flash->erase_size = 4096 << flash->shift;
>         } else if (params->flags & SECT_32K) {
>                 flash->erase_cmd = CMD_ERASE_32K;
>                 flash->erase_size = 32768 << flash->shift;
>         } else {
>                 flash->erase_cmd = CMD_ERASE_64K;
>                 flash->erase_size = flash->sector_size;
>         }
>
> And to be honest, these flashes were tested with lowest ie 4KB so even if they
> do support 64KB, we mentioned on 4KB on 'params->flags' as we tested
> well with that
> and it works consistently.
>
>>

Regards,
Bin

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> I think you have a different interpretation of sector size here-
>>>>
>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>  * necessarily called a "sector" by the vendor.
>>>>  */
>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>> 64K sector erase through flags.
>>>>
>>>> Linux does follow the same-
>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>> SST_WRITE) },
>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>> SST_WRITE) },
>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>> SST_WRITE) },
>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>> SST_WRITE) },
>>>>
>>>> Please check it.
>>>
>>>
>>> Yes, I know this pretty well. And I want to change this behavior, as
>>> my cover letter says.
>>>
>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>> the actual erase command is 4KB granularity, which is inconsistent and
>>> causes confusion.
>>
>> It never related to 'sf erase' instead based on the 'params->flags'
>> sf_probe will decide which erase_cmd with erase_size will use.
>
> No, it is related. See cmd_sf.c:

I'm not getting your point- how could it erase use 64K sector size
instead of 4K.

Suppose the sector size is 4K

flash->sector_size = 0x1000
1.  erase 4K  len flash (it's total erase length)

# sf erase 0x0 0x1000

  len_arg = simple_strtoul(arg, &ep, 16);
 gives - 0x1000

   *len becomes 0x1000

2.  erase 4K+1 len flash

# sf erase 0x0 +0x1001

  len_arg = simple_strtoul(arg, &ep, 16);
 gives - 0x1001

 *len becomes 0x2000

All the way when it goes to sf_ops.c erase will take by means of
erase_size which is assigned in sf_probe.c based on flags like 4K
32K or 64K.

>
> static int sf_parse_len_arg(char *arg, ulong *len)
> {
>     char *ep;
>     char round_up_len; /* indicates if the "+length" form used */
>     ulong len_arg;
>
>     round_up_len = 0;
>     if (*arg == '+') {
>         round_up_len = 1;
>         ++arg;
>     }
>
>     len_arg = simple_strtoul(arg, &ep, 16);
>     if (ep == arg || *ep != '\0')
>         return -1;
>
>     if (round_up_len && flash->sector_size > 0)
>         *len = ROUND(len_arg, flash->sector_size);
>     else
>         *len = len_arg;
>
>     return 1;
> }
>
> So even you are passing 4KB in the flash params, the 'sf erase'
> command WILL erase 64KB.
>
>>         /* Compute erase sector and command */
>>         if (params->flags & SECT_4K) {
>>                 flash->erase_cmd = CMD_ERASE_4K;
>>                 flash->erase_size = 4096 << flash->shift;
>>         } else if (params->flags & SECT_32K) {
>>                 flash->erase_cmd = CMD_ERASE_32K;
>>                 flash->erase_size = 32768 << flash->shift;
>>         } else {
>>                 flash->erase_cmd = CMD_ERASE_64K;
>>                 flash->erase_size = flash->sector_size;
>>         }
>>
>> And to be honest, these flashes were tested with lowest ie 4KB so even if they
>> do support 64KB, we mentioned on 4KB on 'params->flags' as we tested
>> well with that
>> and it works consistently.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Hi Jagan,

On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> I think you have a different interpretation of sector size here-
>>>>>
>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>  * necessarily called a "sector" by the vendor.
>>>>>  */
>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>> 64K sector erase through flags.
>>>>>
>>>>> Linux does follow the same-
>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>> SST_WRITE) },
>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>> SST_WRITE) },
>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>> SST_WRITE) },
>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>> SST_WRITE) },
>>>>>
>>>>> Please check it.
>>>>
>>>>
>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>> my cover letter says.
>>>>
>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>> causes confusion.
>>>
>>> It never related to 'sf erase' instead based on the 'params->flags'
>>> sf_probe will decide which erase_cmd with erase_size will use.
>>
>> No, it is related. See cmd_sf.c:
>
> I'm not getting your point- how could it erase use 64K sector size
> instead of 4K.

It indeed erases 64K sector size. You need check the logic in
spi_flash_validate_params().

> Suppose the sector size is 4K
>
> flash->sector_size = 0x1000
> 1.  erase 4K  len flash (it's total erase length)
>
> # sf erase 0x0 0x1000
>
>   len_arg = simple_strtoul(arg, &ep, 16);
>  gives - 0x1000
>
>    *len becomes 0x1000
>
> 2.  erase 4K+1 len flash
>
> # sf erase 0x0 +0x1001
>
>   len_arg = simple_strtoul(arg, &ep, 16);
>  gives - 0x1001
>
>  *len becomes 0x2000
>
> All the way when it goes to sf_ops.c erase will take by means of
> erase_size which is assigned in sf_probe.c based on flags like 4K
> 32K or 64K.

Regards,
Bin

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> I think you have a different interpretation of sector size here-
>>>>>>
>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>  */
>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>> 64K sector erase through flags.
>>>>>>
>>>>>> Linux does follow the same-
>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>> SST_WRITE) },
>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>> SST_WRITE) },
>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>> SST_WRITE) },
>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>> SST_WRITE) },
>>>>>>
>>>>>> Please check it.
>>>>>
>>>>>
>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>> my cover letter says.
>>>>>
>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>> causes confusion.
>>>>
>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>
>>> No, it is related. See cmd_sf.c:
>>
>> I'm not getting your point- how could it erase use 64K sector size
>> instead of 4K.
>
> It indeed erases 64K sector size. You need check the logic in
> spi_flash_validate_params().

We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
and for these erase_size becomes direct values, please check this.

       /* Compute erase sector and command */
        if (params->flags & SECT_4K) {
                flash->erase_cmd = CMD_ERASE_4K;
                flash->erase_size = 4096;
        } else if (params->flags & SECT_32K) {
                flash->erase_cmd = CMD_ERASE_32K;
                flash->erase_size = 32768;
        } else {
                flash->erase_cmd = CMD_ERASE_64K;
                flash->erase_size = flash->sector_size;
        }

>
>> Suppose the sector size is 4K
>>
>> flash->sector_size = 0x1000
>> 1.  erase 4K  len flash (it's total erase length)
>>
>> # sf erase 0x0 0x1000
>>
>>   len_arg = simple_strtoul(arg, &ep, 16);
>>  gives - 0x1000
>>
>>    *len becomes 0x1000
>>
>> 2.  erase 4K+1 len flash
>>
>> # sf erase 0x0 +0x1001
>>
>>   len_arg = simple_strtoul(arg, &ep, 16);
>>  gives - 0x1001
>>
>>  *len becomes 0x2000
>>
>> All the way when it goes to sf_ops.c erase will take by means of
>> erase_size which is assigned in sf_probe.c based on flags like 4K
>> 32K or 64K.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Hi Jagan,

On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> I think you have a different interpretation of sector size here-
>>>>>>>
>>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>>  */
>>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>>> 64K sector erase through flags.
>>>>>>>
>>>>>>> Linux does follow the same-
>>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>>> SST_WRITE) },
>>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>>> SST_WRITE) },
>>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>>> SST_WRITE) },
>>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>>> SST_WRITE) },
>>>>>>>
>>>>>>> Please check it.
>>>>>>
>>>>>>
>>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>>> my cover letter says.
>>>>>>
>>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>>> causes confusion.
>>>>>
>>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>>
>>>> No, it is related. See cmd_sf.c:
>>>
>>> I'm not getting your point- how could it erase use 64K sector size
>>> instead of 4K.
>>
>> It indeed erases 64K sector size. You need check the logic in
>> spi_flash_validate_params().
>
> We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
> and for these erase_size becomes direct values, please check this.

You previous email already said: the 'sf erase' command depends on
*flash->sector_size*

>        /* Compute erase sector and command */
>         if (params->flags & SECT_4K) {
>                 flash->erase_cmd = CMD_ERASE_4K;
>                 flash->erase_size = 4096;
>         } else if (params->flags & SECT_32K) {
>                 flash->erase_cmd = CMD_ERASE_32K;
>                 flash->erase_size = 32768;
>         } else {
>                 flash->erase_cmd = CMD_ERASE_64K;
>                 flash->erase_size = flash->sector_size;
>         }

Here the codes says: *flash->erase_size*

So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

>>
>>> Suppose the sector size is 4K
>>>
>>> flash->sector_size = 0x1000
>>> 1.  erase 4K  len flash (it's total erase length)
>>>
>>> # sf erase 0x0 0x1000
>>>
>>>   len_arg = simple_strtoul(arg, &ep, 16);
>>>  gives - 0x1000
>>>
>>>    *len becomes 0x1000
>>>
>>> 2.  erase 4K+1 len flash
>>>
>>> # sf erase 0x0 +0x1001
>>>
>>>   len_arg = simple_strtoul(arg, &ep, 16);
>>>  gives - 0x1001
>>>
>>>  *len becomes 0x2000
>>>
>>> All the way when it goes to sf_ops.c erase will take by means of
>>> erase_size which is assigned in sf_probe.c based on flags like 4K
>>> 32K or 64K.
>
> thanks!
> --

Regards,
Bin

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

On 22 April 2015 at 12:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> I think you have a different interpretation of sector size here-
>>>>>>>>
>>>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>>>  */
>>>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>>>> 64K sector erase through flags.
>>>>>>>>
>>>>>>>> Linux does follow the same-
>>>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>>>> SST_WRITE) },
>>>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>>>> SST_WRITE) },
>>>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>>>> SST_WRITE) },
>>>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>>>> SST_WRITE) },
>>>>>>>>
>>>>>>>> Please check it.
>>>>>>>
>>>>>>>
>>>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>>>> my cover letter says.
>>>>>>>
>>>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>>>> causes confusion.
>>>>>>
>>>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>>>
>>>>> No, it is related. See cmd_sf.c:
>>>>
>>>> I'm not getting your point- how could it erase use 64K sector size
>>>> instead of 4K.
>>>
>>> It indeed erases 64K sector size. You need check the logic in
>>> spi_flash_validate_params().
>>
>> We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
>> and for these erase_size becomes direct values, please check this.
>
> You previous email already said: the 'sf erase' command depends on
> *flash->sector_size*
>
>>        /* Compute erase sector and command */
>>         if (params->flags & SECT_4K) {
>>                 flash->erase_cmd = CMD_ERASE_4K;
>>                 flash->erase_size = 4096;
>>         } else if (params->flags & SECT_32K) {
>>                 flash->erase_cmd = CMD_ERASE_32K;
>>                 flash->erase_size = 32768;
>>         } else {
>>                 flash->erase_cmd = CMD_ERASE_64K;
>>                 flash->erase_size = flash->sector_size;
>>         }
>
> Here the codes says: *flash->erase_size*
>
> So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.

Example:
"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
    SECT_4K | SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 4096

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
"SF: Erase offset/length not multiple of erase size"

Example:
"SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
    SST_WR},

sf probe gives
sector_size = 64 * 1024 and erase_size = 64 * 1024

sf erase 0 100
sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
"SF: Erase offset/length not multiple of erase size"

Still have any concerns, please come to IRC for more discussion

>
>>>
>>>> Suppose the sector size is 4K
>>>>
>>>> flash->sector_size = 0x1000
>>>> 1.  erase 4K  len flash (it's total erase length)
>>>>
>>>> # sf erase 0x0 0x1000
>>>>
>>>>   len_arg = simple_strtoul(arg, &ep, 16);
>>>>  gives - 0x1000
>>>>
>>>>    *len becomes 0x1000
>>>>
>>>> 2.  erase 4K+1 len flash
>>>>
>>>> # sf erase 0x0 +0x1001
>>>>
>>>>   len_arg = simple_strtoul(arg, &ep, 16);
>>>>  gives - 0x1001
>>>>
>>>>  *len becomes 0x2000
>>>>
>>>> All the way when it goes to sf_ops.c erase will take by means of
>>>> erase_size which is assigned in sf_probe.c based on flags like 4K
>>>> 32K or 64K.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Hi Jagan,

On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 22 April 2015 at 12:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Bin,
>>>>>>>>>
>>>>>>>>> I think you have a different interpretation of sector size here-
>>>>>>>>>
>>>>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>>>>  */
>>>>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>>>>> 64K sector erase through flags.
>>>>>>>>>
>>>>>>>>> Linux does follow the same-
>>>>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>>>>> SST_WRITE) },
>>>>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>>>>> SST_WRITE) },
>>>>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>>>>> SST_WRITE) },
>>>>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>>>>> SST_WRITE) },
>>>>>>>>>
>>>>>>>>> Please check it.
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>>>>> my cover letter says.
>>>>>>>>
>>>>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>>>>> causes confusion.
>>>>>>>
>>>>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>>>>
>>>>>> No, it is related. See cmd_sf.c:
>>>>>
>>>>> I'm not getting your point- how could it erase use 64K sector size
>>>>> instead of 4K.
>>>>
>>>> It indeed erases 64K sector size. You need check the logic in
>>>> spi_flash_validate_params().
>>>
>>> We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
>>> and for these erase_size becomes direct values, please check this.
>>
>> You previous email already said: the 'sf erase' command depends on
>> *flash->sector_size*
>>
>>>        /* Compute erase sector and command */
>>>         if (params->flags & SECT_4K) {
>>>                 flash->erase_cmd = CMD_ERASE_4K;
>>>                 flash->erase_size = 4096;
>>>         } else if (params->flags & SECT_32K) {
>>>                 flash->erase_cmd = CMD_ERASE_32K;
>>>                 flash->erase_size = 32768;
>>>         } else {
>>>                 flash->erase_cmd = CMD_ERASE_64K;
>>>                 flash->erase_size = flash->sector_size;
>>>         }
>>
>> Here the codes says: *flash->erase_size*
>>
>> So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
>
> Example:
> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>     SECT_4K | SST_WR},
>
> sf probe gives
> sector_size = 64 * 1024 and erase_size = 4096
>
> sf erase 0 100
> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
> "SF: Erase offset/length not multiple of erase size"

sf erase 0 +100. Sorry for the typo. But looks like you are not really
reading the codes.

=> sf probe
SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB,
total 2 MiB, mapped at ffe00000

=> sf erase 0 +100
SF: 65536 bytes @ 0x0 Erased: OK

Tested on two boards, and both shows 64K was erased.

> Example:
> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>     SST_WR},
>
> sf probe gives
> sector_size = 64 * 1024 and erase_size = 64 * 1024
>
> sf erase 0 100
> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
> "SF: Erase offset/length not multiple of erase size"
>
> Still have any concerns, please come to IRC for more discussion
>

Regards,
Bin

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

On 22 April 2015 at 14:13, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 22 April 2015 at 12:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> I think you have a different interpretation of sector size here-
>>>>>>>>>>
>>>>>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>>>>>  */
>>>>>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>>>>>> 64K sector erase through flags.
>>>>>>>>>>
>>>>>>>>>> Linux does follow the same-
>>>>>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>
>>>>>>>>>> Please check it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>>>>>> my cover letter says.
>>>>>>>>>
>>>>>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>>>>>> causes confusion.
>>>>>>>>
>>>>>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>>>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>>>>>
>>>>>>> No, it is related. See cmd_sf.c:
>>>>>>
>>>>>> I'm not getting your point- how could it erase use 64K sector size
>>>>>> instead of 4K.
>>>>>
>>>>> It indeed erases 64K sector size. You need check the logic in
>>>>> spi_flash_validate_params().
>>>>
>>>> We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
>>>> and for these erase_size becomes direct values, please check this.
>>>
>>> You previous email already said: the 'sf erase' command depends on
>>> *flash->sector_size*
>>>
>>>>        /* Compute erase sector and command */
>>>>         if (params->flags & SECT_4K) {
>>>>                 flash->erase_cmd = CMD_ERASE_4K;
>>>>                 flash->erase_size = 4096;
>>>>         } else if (params->flags & SECT_32K) {
>>>>                 flash->erase_cmd = CMD_ERASE_32K;
>>>>                 flash->erase_size = 32768;
>>>>         } else {
>>>>                 flash->erase_cmd = CMD_ERASE_64K;
>>>>                 flash->erase_size = flash->sector_size;
>>>>         }
>>>
>>> Here the codes says: *flash->erase_size*
>>>
>>> So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
>>
>> Example:
>> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>>     SECT_4K | SST_WR},
>>
>> sf probe gives
>> sector_size = 64 * 1024 and erase_size = 4096
>>
>> sf erase 0 100
>> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
>> "SF: Erase offset/length not multiple of erase size"
>
> sf erase 0 +100. Sorry for the typo. But looks like you are not really
> reading the codes.
>

Worked on too-many overclocked issue, sorry for that.

So, something fixed in sf_probe.c will fix this I guess.

> => sf probe
> SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB,
> total 2 MiB, mapped at ffe00000
>
> => sf erase 0 +100
> SF: 65536 bytes @ 0x0 Erased: OK
>
> Tested on two boards, and both shows 64K was erased.
>
>> Example:
>> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>>     SST_WR},
>>
>> sf probe gives
>> sector_size = 64 * 1024 and erase_size = 64 * 1024
>>
>> sf erase 0 100
>> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
>> "SF: Erase offset/length not multiple of erase size"
>>
>> Still have any concerns, please come to IRC for more discussion

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Bin Meng]

Hi Jagan,

On Wed, Apr 22, 2015 at 5:15 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 22 April 2015 at 14:13, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On 22 April 2015 at 12:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Bin,
>>>>>>>>>
>>>>>>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>> Hi Jagan,
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>> Hi Bin,
>>>>>>>>>>>
>>>>>>>>>>> I think you have a different interpretation of sector size here-
>>>>>>>>>>>
>>>>>>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>>>>>>  */
>>>>>>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>>>>>>> 64K sector erase through flags.
>>>>>>>>>>>
>>>>>>>>>>> Linux does follow the same-
>>>>>>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>
>>>>>>>>>>> Please check it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>>>>>>> my cover letter says.
>>>>>>>>>>
>>>>>>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>>>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>>>>>>> causes confusion.
>>>>>>>>>
>>>>>>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>>>>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>>>>>>
>>>>>>>> No, it is related. See cmd_sf.c:
>>>>>>>
>>>>>>> I'm not getting your point- how could it erase use 64K sector size
>>>>>>> instead of 4K.
>>>>>>
>>>>>> It indeed erases 64K sector size. You need check the logic in
>>>>>> spi_flash_validate_params().
>>>>>
>>>>> We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
>>>>> and for these erase_size becomes direct values, please check this.
>>>>
>>>> You previous email already said: the 'sf erase' command depends on
>>>> *flash->sector_size*
>>>>
>>>>>        /* Compute erase sector and command */
>>>>>         if (params->flags & SECT_4K) {
>>>>>                 flash->erase_cmd = CMD_ERASE_4K;
>>>>>                 flash->erase_size = 4096;
>>>>>         } else if (params->flags & SECT_32K) {
>>>>>                 flash->erase_cmd = CMD_ERASE_32K;
>>>>>                 flash->erase_size = 32768;
>>>>>         } else {
>>>>>                 flash->erase_cmd = CMD_ERASE_64K;
>>>>>                 flash->erase_size = flash->sector_size;
>>>>>         }
>>>>
>>>> Here the codes says: *flash->erase_size*
>>>>
>>>> So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
>>>
>>> Example:
>>> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>>>     SECT_4K | SST_WR},
>>>
>>> sf probe gives
>>> sector_size = 64 * 1024 and erase_size = 4096
>>>
>>> sf erase 0 100
>>> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
>>> "SF: Erase offset/length not multiple of erase size"
>>
>> sf erase 0 +100. Sorry for the typo. But looks like you are not really
>> reading the codes.
>>
>
> Worked on too-many overclocked issue, sorry for that.
>
> So, something fixed in sf_probe.c will fix this I guess.

Good, you finally got it! So you prefer fixing this inconsistency in
sf_probe.c? I guess by overriding flash->sector_size and
flash->nr_sectors if SECT_4K?

>> => sf probe
>> SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB,
>> total 2 MiB, mapped at ffe00000
>>
>> => sf erase 0 +100
>> SF: 65536 bytes @ 0x0 Erased: OK
>>
>> Tested on two boards, and both shows 64K was erased.
>>
>>> Example:
>>> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>>>     SST_WR},
>>>
>>> sf probe gives
>>> sector_size = 64 * 1024 and erase_size = 64 * 1024
>>>
>>> sf erase 0 100
>>> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
>>> "SF: Erase offset/length not multiple of erase size"
>>>
>>> Still have any concerns, please come to IRC for more discussion
>

As you see I have rebased this patch once for v2/v3 and lots of effort
were spent on this series. I remember you said this patch series needs
some testing on your side, but this comment shows that you may want to
do it in another way. I really hope such comments could be sent months
ago. Today I can't even remember all of the details in this series.
Luckily I don't lose interest to get this upstream so I kept asking
for an update.

Regards,
Bin

[U-Boot] [PATCH v3 1/9] sf: Update SST flash params

[Jagan Teki]

Hi Bin,

On 22 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Apr 22, 2015 at 5:15 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 22 April 2015 at 14:13, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 22 April 2015 at 12:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 22 April 2015 at 12:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>> Hi Bin,
>>>>>>>>>>>>
>>>>>>>>>>>> I think you have a different interpretation of sector size here-
>>>>>>>>>>>>
>>>>>>>>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>>>>>>>>>>  * necessarily called a "sector" by the vendor.
>>>>>>>>>>>>  */
>>>>>>>>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>>>>>>>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>>>>>>>>>>> 64K sector erase through flags.
>>>>>>>>>>>>
>>>>>>>>>>>> Linux does follow the same-
>>>>>>>>>>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>>>>>>>>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>>>>>>>>>>> SST_WRITE) },
>>>>>>>>>>>>
>>>>>>>>>>>> Please check it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, I know this pretty well. And I want to change this behavior, as
>>>>>>>>>>> my cover letter says.
>>>>>>>>>>>
>>>>>>>>>>> Currently the 'sf erase' command operates on a 64KB granularity, while
>>>>>>>>>>> the actual erase command is 4KB granularity, which is inconsistent and
>>>>>>>>>>> causes confusion.
>>>>>>>>>>
>>>>>>>>>> It never related to 'sf erase' instead based on the 'params->flags'
>>>>>>>>>> sf_probe will decide which erase_cmd with erase_size will use.
>>>>>>>>>
>>>>>>>>> No, it is related. See cmd_sf.c:
>>>>>>>>
>>>>>>>> I'm not getting your point- how could it erase use 64K sector size
>>>>>>>> instead of 4K.
>>>>>>>
>>>>>>> It indeed erases 64K sector size. You need check the logic in
>>>>>>> spi_flash_validate_params().
>>>>>>
>>>>>> We're assigning erase_size to sector_size only when SECT_4K and SECT_32K
>>>>>> and for these erase_size becomes direct values, please check this.
>>>>>
>>>>> You previous email already said: the 'sf erase' command depends on
>>>>> *flash->sector_size*
>>>>>
>>>>>>        /* Compute erase sector and command */
>>>>>>         if (params->flags & SECT_4K) {
>>>>>>                 flash->erase_cmd = CMD_ERASE_4K;
>>>>>>                 flash->erase_size = 4096;
>>>>>>         } else if (params->flags & SECT_32K) {
>>>>>>                 flash->erase_cmd = CMD_ERASE_32K;
>>>>>>                 flash->erase_size = 32768;
>>>>>>         } else {
>>>>>>                 flash->erase_cmd = CMD_ERASE_64K;
>>>>>>                 flash->erase_size = flash->sector_size;
>>>>>>         }
>>>>>
>>>>> Here the codes says: *flash->erase_size*
>>>>>
>>>>> So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
>>>>
>>>> Example:
>>>> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>>>>     SECT_4K | SST_WR},
>>>>
>>>> sf probe gives
>>>> sector_size = 64 * 1024 and erase_size = 4096
>>>>
>>>> sf erase 0 100
>>>> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
>>>> "SF: Erase offset/length not multiple of erase size"
>>>
>>> sf erase 0 +100. Sorry for the typo. But looks like you are not really
>>> reading the codes.
>>>
>>
>> Worked on too-many overclocked issue, sorry for that.
>>
>> So, something fixed in sf_probe.c will fix this I guess.
>
> Good, you finally got it! So you prefer fixing this inconsistency in
> sf_probe.c? I guess by overriding flash->sector_size and
> flash->nr_sectors if SECT_4K?

I'm posting patch.

>
>>> => sf probe
>>> SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB,
>>> total 2 MiB, mapped at ffe00000
>>>
>>> => sf erase 0 +100
>>> SF: 65536 bytes @ 0x0 Erased: OK
>>>
>>> Tested on two boards, and both shows 64K was erased.
>>>
>>>> Example:
>>>> "SST25WF080",     0xbf2505, 0x0,       64 * 1024,    16, RD_NORM,
>>>>     SST_WR},
>>>>
>>>> sf probe gives
>>>> sector_size = 64 * 1024 and erase_size = 64 * 1024
>>>>
>>>> sf erase 0 100
>>>> sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns
>>>> "SF: Erase offset/length not multiple of erase size"
>>>>
>>>> Still have any concerns, please come to IRC for more discussion
>>
>
> As you see I have rebased this patch once for v2/v3 and lots of effort
> were spent on this series. I remember you said this patch series needs
> some testing on your side, but this comment shows that you may want to
> do it in another way. I really hope such comments could be sent months
> ago. Today I can't even remember all of the details in this series.
> Luckily I don't lose interest to get this upstream so I kept asking
> for an update.

Yes - I did some testing for Micron patch at-least and even I post the comment
for the same. I have a plan to test the remaining patches as well and
in-fact these
questions I got it from sst patch(this patch). I agree some delay in
my side but as
these are core changes and I need to see each and test them
respectively, that is
my main Job. I'm very much thankful to you for keeping me updates.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 2/9] sf: Update Atmel flash params

[Bin Meng]

Update flash sector size to 4KiB as long as flash supports sector
erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase
command to 50h instead of D8h. Also add AT25DF321A params per
datasheet.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_internal.h |  5 +++++
 drivers/mtd/spi/sf_params.c   | 17 +++++++++--------
 drivers/mtd/spi/sf_probe.c    |  4 ++++
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 785f7a9..8010fc5 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -106,6 +106,11 @@ enum {
 #define SPI_FLASH_PAGE_ERASE_TIMEOUT		(5 * CONFIG_SYS_HZ)
 #define SPI_FLASH_SECTOR_ERASE_TIMEOUT	(10 * CONFIG_SYS_HZ)
 
+/* Atmel specific */
+#ifdef CONFIG_SPI_FLASH_ATMEL
+# define CMD_ATMEL_BLK_ERASE	0x50
+#endif
+
 /* SST specific */
 #ifdef CONFIG_SPI_FLASH_SST
 # define CMD_SST_BP		0x02    /* Byte Program */
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5482700..cc4cd60 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -15,14 +15,15 @@
 /* SPI/QSPI flash device params structure */
 const struct spi_flash_params spi_flash_params_table[] = {
 #ifdef CONFIG_SPI_FLASH_ATMEL		/* ATMEL */
-	{"AT45DB011D",	   0x1f2200, 0x0,	64 * 1024,     4, RD_NORM,		    SECT_4K},
-	{"AT45DB021D",	   0x1f2300, 0x0,	64 * 1024,     8, RD_NORM,		    SECT_4K},
-	{"AT45DB041D",	   0x1f2400, 0x0,	64 * 1024,     8, RD_NORM,		    SECT_4K},
-	{"AT45DB081D",	   0x1f2500, 0x0,	64 * 1024,    16, RD_NORM,		    SECT_4K},
-	{"AT45DB161D",	   0x1f2600, 0x0,	64 * 1024,    32, RD_NORM,		    SECT_4K},
-	{"AT45DB321D",	   0x1f2700, 0x0,	64 * 1024,    64, RD_NORM,		    SECT_4K},
-	{"AT45DB641D",	   0x1f2800, 0x0,	64 * 1024,   128, RD_NORM,		    SECT_4K},
-	{"AT25DF321",      0x1f4701, 0x0,	64 * 1024,    64, RD_NORM,		    SECT_4K},
+	{"AT45DB011D",	   0x1f2200, 0x0,	 2 * 1024,    64, RD_NORM,		          0},
+	{"AT45DB021D",	   0x1f2300, 0x0,	 2 * 1024,   128, RD_NORM,		          0},
+	{"AT45DB041D",	   0x1f2400, 0x0,	 2 * 1024,   256, RD_NORM,		          0},
+	{"AT45DB081D",	   0x1f2500, 0x0,	 2 * 1024,   512, RD_NORM,		          0},
+	{"AT45DB161D",	   0x1f2600, 0x0,	 4 * 1024,   512, RD_NORM,		          0},
+	{"AT45DB321D",	   0x1f2700, 0x0,	 4 * 1024,  1024, RD_NORM,		          0},
+	{"AT45DB641D",	   0x1f2800, 0x0,	 2 * 1024,  4096, RD_NORM,		          0},
+	{"AT25DF321",      0x1f4700, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
+	{"AT25DF321A",     0x1f4701, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON		/* EON */
 	{"EN25Q32B",	   0x1c3016, 0x0,	64 * 1024,    64, RD_NORM,			  0},
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index ce9987f..13fda44 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -179,7 +179,11 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode,
 		flash->erase_cmd = CMD_ERASE_32K;
 		flash->erase_size = 32768 << flash->shift;
 	} else {
+#ifdef CONFIG_SPI_FLASH_ATMEL
+		flash->erase_cmd = CMD_ATMEL_BLK_ERASE;
+#else
 		flash->erase_cmd = CMD_ERASE_64K;
+#endif
 		flash->erase_size = flash->sector_size;
 	}
 
-- 
1.8.2.1

[U-Boot] [PATCH v3 2/9] sf: Update Atmel flash params

[Bo Shen]

Hi Meng,

On 12/10/2014 08:51 PM, Bin Meng wrote:
> Update flash sector size to 4KiB as long as flash supports sector
> erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase
> command to 50h instead of D8h. Also add AT25DF321A params per
> datasheet.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>   drivers/mtd/spi/sf_internal.h |  5 +++++
>   drivers/mtd/spi/sf_params.c   | 17 +++++++++--------
>   drivers/mtd/spi/sf_probe.c    |  4 ++++
>   3 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 785f7a9..8010fc5 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -106,6 +106,11 @@ enum {
>   #define SPI_FLASH_PAGE_ERASE_TIMEOUT		(5 * CONFIG_SYS_HZ)
>   #define SPI_FLASH_SECTOR_ERASE_TIMEOUT	(10 * CONFIG_SYS_HZ)
>
> +/* Atmel specific */
> +#ifdef CONFIG_SPI_FLASH_ATMEL
> +# define CMD_ATMEL_BLK_ERASE	0x50
> +#endif
> +
>   /* SST specific */
>   #ifdef CONFIG_SPI_FLASH_SST
>   # define CMD_SST_BP		0x02    /* Byte Program */
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 5482700..cc4cd60 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -15,14 +15,15 @@
>   /* SPI/QSPI flash device params structure */
>   const struct spi_flash_params spi_flash_params_table[] = {
>   #ifdef CONFIG_SPI_FLASH_ATMEL		/* ATMEL */
> -	{"AT45DB011D",	   0x1f2200, 0x0,	64 * 1024,     4, RD_NORM,		    SECT_4K},
> -	{"AT45DB021D",	   0x1f2300, 0x0,	64 * 1024,     8, RD_NORM,		    SECT_4K},
> -	{"AT45DB041D",	   0x1f2400, 0x0,	64 * 1024,     8, RD_NORM,		    SECT_4K},
> -	{"AT45DB081D",	   0x1f2500, 0x0,	64 * 1024,    16, RD_NORM,		    SECT_4K},
> -	{"AT45DB161D",	   0x1f2600, 0x0,	64 * 1024,    32, RD_NORM,		    SECT_4K},
> -	{"AT45DB321D",	   0x1f2700, 0x0,	64 * 1024,    64, RD_NORM,		    SECT_4K},
> -	{"AT45DB641D",	   0x1f2800, 0x0,	64 * 1024,   128, RD_NORM,		    SECT_4K},
> -	{"AT25DF321",      0x1f4701, 0x0,	64 * 1024,    64, RD_NORM,		    SECT_4K},
> +	{"AT45DB011D",	   0x1f2200, 0x0,	 2 * 1024,    64, RD_NORM,		          0},
> +	{"AT45DB021D",	   0x1f2300, 0x0,	 2 * 1024,   128, RD_NORM,		          0},
> +	{"AT45DB041D",	   0x1f2400, 0x0,	 2 * 1024,   256, RD_NORM,		          0},
> +	{"AT45DB081D",	   0x1f2500, 0x0,	 2 * 1024,   512, RD_NORM,		          0},
> +	{"AT45DB161D",	   0x1f2600, 0x0,	 4 * 1024,   512, RD_NORM,		          0},
> +	{"AT45DB321D",	   0x1f2700, 0x0,	 4 * 1024,  1024, RD_NORM,		          0},

In datasheet, the id is 0x1f2701. Doc number is: 3597Q-DFLASH-6/11. I 
can not find any new datasheet.

And I test on at91sam9m10g45ek board, it also read as this ID (0x1f2701).

So, if you plan to send new version, can you help add this ID? If not, 
maybe follow up patch will be better.

Thanks.

> +	{"AT45DB641D",	   0x1f2800, 0x0,	 2 * 1024,  4096, RD_NORM,		          0},
> +	{"AT25DF321",      0x1f4700, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
> +	{"AT25DF321A",     0x1f4701, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
>   #endif
>   #ifdef CONFIG_SPI_FLASH_EON		/* EON */
>   	{"EN25Q32B",	   0x1c3016, 0x0,	64 * 1024,    64, RD_NORM,			  0},
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index ce9987f..13fda44 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -179,7 +179,11 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode,
>   		flash->erase_cmd = CMD_ERASE_32K;
>   		flash->erase_size = 32768 << flash->shift;
>   	} else {
> +#ifdef CONFIG_SPI_FLASH_ATMEL
> +		flash->erase_cmd = CMD_ATMEL_BLK_ERASE;
> +#else
>   		flash->erase_cmd = CMD_ERASE_64K;
> +#endif
>   		flash->erase_size = flash->sector_size;
>   	}
>
>

Best Regards,
Bo Shen

[U-Boot] [PATCH v3 2/9] sf: Update Atmel flash params

[Bin Meng]

Hi Bo,

On Fri, Jan 9, 2015 at 5:27 PM, Bo Shen <voice.shen@atmel.com> wrote:
> Hi Meng,
>
>
> On 12/10/2014 08:51 PM, Bin Meng wrote:
>>
>> Update flash sector size to 4KiB as long as flash supports sector
>> erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase
>> command to 50h instead of D8h. Also add AT25DF321A params per
>> datasheet.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>   drivers/mtd/spi/sf_internal.h |  5 +++++
>>   drivers/mtd/spi/sf_params.c   | 17 +++++++++--------
>>   drivers/mtd/spi/sf_probe.c    |  4 ++++
>>   3 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
>> index 785f7a9..8010fc5 100644
>> --- a/drivers/mtd/spi/sf_internal.h
>> +++ b/drivers/mtd/spi/sf_internal.h
>> @@ -106,6 +106,11 @@ enum {
>>   #define SPI_FLASH_PAGE_ERASE_TIMEOUT          (5 * CONFIG_SYS_HZ)
>>   #define SPI_FLASH_SECTOR_ERASE_TIMEOUT        (10 * CONFIG_SYS_HZ)
>>
>> +/* Atmel specific */
>> +#ifdef CONFIG_SPI_FLASH_ATMEL
>> +# define CMD_ATMEL_BLK_ERASE   0x50
>> +#endif
>> +
>>   /* SST specific */
>>   #ifdef CONFIG_SPI_FLASH_SST
>>   # define CMD_SST_BP           0x02    /* Byte Program */
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index 5482700..cc4cd60 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -15,14 +15,15 @@
>>   /* SPI/QSPI flash device params structure */
>>   const struct spi_flash_params spi_flash_params_table[] = {
>>   #ifdef CONFIG_SPI_FLASH_ATMEL         /* ATMEL */
>> -       {"AT45DB011D",     0x1f2200, 0x0,       64 * 1024,     4, RD_NORM,
>> SECT_4K},
>> -       {"AT45DB021D",     0x1f2300, 0x0,       64 * 1024,     8, RD_NORM,
>> SECT_4K},
>> -       {"AT45DB041D",     0x1f2400, 0x0,       64 * 1024,     8, RD_NORM,
>> SECT_4K},
>> -       {"AT45DB081D",     0x1f2500, 0x0,       64 * 1024,    16, RD_NORM,
>> SECT_4K},
>> -       {"AT45DB161D",     0x1f2600, 0x0,       64 * 1024,    32, RD_NORM,
>> SECT_4K},
>> -       {"AT45DB321D",     0x1f2700, 0x0,       64 * 1024,    64, RD_NORM,
>> SECT_4K},
>> -       {"AT45DB641D",     0x1f2800, 0x0,       64 * 1024,   128, RD_NORM,
>> SECT_4K},
>> -       {"AT25DF321",      0x1f4701, 0x0,       64 * 1024,    64, RD_NORM,
>> SECT_4K},
>> +       {"AT45DB011D",     0x1f2200, 0x0,        2 * 1024,    64, RD_NORM,
>> 0},
>> +       {"AT45DB021D",     0x1f2300, 0x0,        2 * 1024,   128, RD_NORM,
>> 0},
>> +       {"AT45DB041D",     0x1f2400, 0x0,        2 * 1024,   256, RD_NORM,
>> 0},
>> +       {"AT45DB081D",     0x1f2500, 0x0,        2 * 1024,   512, RD_NORM,
>> 0},
>> +       {"AT45DB161D",     0x1f2600, 0x0,        4 * 1024,   512, RD_NORM,
>> 0},
>> +       {"AT45DB321D",     0x1f2700, 0x0,        4 * 1024,  1024, RD_NORM,
>> 0},
>
>
> In datasheet, the id is 0x1f2701. Doc number is: 3597Q-DFLASH-6/11. I can
> not find any new datasheet.
>
> And I test on at91sam9m10g45ek board, it also read as this ID (0x1f2701).
>
> So, if you plan to send new version, can you help add this ID? If not, maybe
> follow up patch will be better.
>

Yes, I do plan to send a new version. However I am still waiting for
Jagan's testing results of this patch series. I checked the AT45DB321D
datasheet, the flash ID is indeed 0x1f2701. So the original value on
the params table is wrong. I will fix this in the v4 patch.

[snip]

Regards,
Bin

[U-Boot] [PATCH v3 3/9] sf: Update EON flash params

[Bin Meng]

Update supported read commands for EON flash parts to RD_EXTN and
QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB
as long as flash supports sector erase (20h) command.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index cc4cd60..3e5c6e0 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"AT25DF321A",     0x1f4701, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON		/* EON */
-	{"EN25Q32B",	   0x1c3016, 0x0,	64 * 1024,    64, RD_NORM,			  0},
-	{"EN25Q64",	   0x1c3017, 0x0,	64 * 1024,   128, RD_NORM,		    SECT_4K},
-	{"EN25Q128B",	   0x1c3018, 0x0,       64 * 1024,   256, RD_NORM,			  0},
-	{"EN25S64",	   0x1c3817, 0x0,	64 * 1024,   128, RD_NORM,			  0},
+	{"EN25Q32B",	   0x1c3016, 0x0,	 4 * 1024,  1024, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+	{"EN25Q64",	   0x1c3017, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+	{"EN25Q128B",	   0x1c3018, 0x0,        4 * 1024,  4096, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+	{"EN25S64",	   0x1c3817, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_GIGADEVICE	/* GIGADEVICE */
 	{"GD25Q64B",	   0xc84017, 0x0,	64 * 1024,   128, RD_NORM,		    SECT_4K},
-- 
1.8.2.1

[U-Boot] [PATCH v3 3/9] sf: Update EON flash params

[Jagan Teki]

Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> Update supported read commands for EON flash parts to RD_EXTN and
> QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB
> as long as flash supports sector erase (20h) command.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/mtd/spi/sf_params.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index cc4cd60..3e5c6e0 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = {
>         {"AT25DF321A",     0x1f4701, 0x0,        4 * 1024,  1024, RD_NORM,                  SECT_4K},
>  #endif
>  #ifdef CONFIG_SPI_FLASH_EON            /* EON */
> -       {"EN25Q32B",       0x1c3016, 0x0,       64 * 1024,    64, RD_NORM,                        0},
> -       {"EN25Q64",        0x1c3017, 0x0,       64 * 1024,   128, RD_NORM,                  SECT_4K},
> -       {"EN25Q128B",      0x1c3018, 0x0,       64 * 1024,   256, RD_NORM,                        0},
> -       {"EN25S64",        0x1c3817, 0x0,       64 * 1024,   128, RD_NORM,                        0},
> +       {"EN25Q32B",       0x1c3016, 0x0,        4 * 1024,  1024, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
> +       {"EN25Q64",        0x1c3017, 0x0,        4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
> +       {"EN25Q128B",      0x1c3018, 0x0,        4 * 1024,  4096, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
> +       {"EN25S64",        0x1c3817, 0x0,        4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},

Did you test this QUAD_IO_FAST ?

>  #endif
>  #ifdef CONFIG_SPI_FLASH_GIGADEVICE     /* GIGADEVICE */
>         {"GD25Q64B",       0xc84017, 0x0,       64 * 1024,   128, RD_NORM,                  SECT_4K},
> --
> 1.8.2.1
>

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 3/9] sf: Update EON flash params

[Bin Meng]

Hi Jagan,

On Thu, Dec 11, 2014 at 2:31 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Update supported read commands for EON flash parts to RD_EXTN and
>> QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB
>> as long as flash supports sector erase (20h) command.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/mtd/spi/sf_params.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index cc4cd60..3e5c6e0 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = {
>>         {"AT25DF321A",     0x1f4701, 0x0,        4 * 1024,  1024, RD_NORM,                  SECT_4K},
>>  #endif
>>  #ifdef CONFIG_SPI_FLASH_EON            /* EON */
>> -       {"EN25Q32B",       0x1c3016, 0x0,       64 * 1024,    64, RD_NORM,                        0},
>> -       {"EN25Q64",        0x1c3017, 0x0,       64 * 1024,   128, RD_NORM,                  SECT_4K},
>> -       {"EN25Q128B",      0x1c3018, 0x0,       64 * 1024,   256, RD_NORM,                        0},
>> -       {"EN25S64",        0x1c3817, 0x0,       64 * 1024,   128, RD_NORM,                        0},
>> +       {"EN25Q32B",       0x1c3016, 0x0,        4 * 1024,  1024, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
>> +       {"EN25Q64",        0x1c3017, 0x0,        4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
>> +       {"EN25Q128B",      0x1c3018, 0x0,        4 * 1024,  4096, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
>> +       {"EN25S64",        0x1c3817, 0x0,        4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
>
> Did you test this QUAD_IO_FAST ?
>

No because I don't have a board running U-Boot which has an EON flash
mounted. These updates are purely based on the flash datasheet.

[snip]

Regards,
Bin

[U-Boot] [PATCH v3 4/9] sf: Update GigaDevice flash params

[Bin Meng]

Update supported read commands for GigaDevice flash parts to RD_FULL
per datasheet. Also update flash sector size to 4KiB as long as flash
supports sector erase (20h) command.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 3e5c6e0..de5d438 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -32,8 +32,8 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"EN25S64",	   0x1c3817, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_GIGADEVICE	/* GIGADEVICE */
-	{"GD25Q64B",	   0xc84017, 0x0,	64 * 1024,   128, RD_NORM,		    SECT_4K},
-	{"GD25LQ32",	   0xc86016, 0x0,	64 * 1024,    64, RD_NORM,		    SECT_4K},
+	{"GD25Q64B",	   0xc84017, 0x0,	 4 * 1024,  2048, RD_FULL,		    SECT_4K},
+	{"GD25LQ32",	   0xc86016, 0x0,	 4 * 1024,  1024, RD_FULL,		    SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX	/* MACRONIX */
 	{"MX25L2006E",	   0xc22012, 0x0,	64 * 1024,     4, RD_NORM,			  0},
-- 
1.8.2.1

[U-Boot] [PATCH v3 5/9] sf: Update Macronix flash params

[Bin Meng]

Update supported read commands for Macronix flash parts per datasheet.
Also update flash sector size to 4KiB as long as flash supports sector
erase (20h) command.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index de5d438..77aa95b 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -36,16 +36,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"GD25LQ32",	   0xc86016, 0x0,	 4 * 1024,  1024, RD_FULL,		    SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX	/* MACRONIX */
-	{"MX25L2006E",	   0xc22012, 0x0,	64 * 1024,     4, RD_NORM,			  0},
-	{"MX25L4005",	   0xc22013, 0x0,	64 * 1024,     8, RD_NORM,			  0},
-	{"MX25L8005",	   0xc22014, 0x0,	64 * 1024,    16, RD_NORM,			  0},
-	{"MX25L1605D",	   0xc22015, 0x0,	64 * 1024,    32, RD_NORM,			  0},
-	{"MX25L3205D",	   0xc22016, 0x0,	64 * 1024,    64, RD_NORM,			  0},
-	{"MX25L6405D",	   0xc22017, 0x0,	64 * 1024,   128, RD_NORM,			  0},
-	{"MX25L12805",	   0xc22018, 0x0,	64 * 1024,   256, RD_FULL,		     WR_QPP},
-	{"MX25L25635F",	   0xc22019, 0x0,	64 * 1024,   512, RD_FULL,		     WR_QPP},
-	{"MX25L51235F",	   0xc2201a, 0x0,	64 * 1024,  1024, RD_FULL,		     WR_QPP},
-	{"MX25L12855E",	   0xc22618, 0x0,	64 * 1024,   256, RD_FULL,		     WR_QPP},
+	{"MX25L2006E",	   0xc22012, 0x0,	 4 * 1024,    64, RD_NORM | DUAL_OUTPUT_FAST, 			  SECT_4K},
+	{"MX25L4005",	   0xc22013, 0x0,	 4 * 1024,   128, RD_NORM, 					  SECT_4K},
+	{"MX25L8005",	   0xc22014, 0x0,	 4 * 1024,   256, RD_NORM, 					  SECT_4K},
+	{"MX25L1605D",	   0xc22015, 0x0,	 4 * 1024,   512, RD_NORM, 					  SECT_4K},
+	{"MX25L3205D",	   0xc22016, 0x0,	 4 * 1024,  1024, RD_NORM, 					  SECT_4K},
+	{"MX25L6405D",	   0xc22017, 0x0,	 4 * 1024,  2048, RD_NORM, 					  SECT_4K},
+	{"MX25L12805",	   0xc22018, 0x0,	 4 * 1024,  4096, RD_NORM, 					  SECT_4K},
+	{"MX25L25635F",	   0xc22019, 0x0,	 4 * 1024,  8192, RD_FULL, 				 WR_QPP | SECT_4K},
+	{"MX25L51235F",	   0xc2201a, 0x0,	 4 * 1024, 16384, RD_FULL, 				 WR_QPP | SECT_4K},
+	{"MX25L12855E",	   0xc22618, 0x0,	 4 * 1024,  4096, RD_NORM | DUAL_IO_FAST | QUAD_IO_FAST, WR_QPP | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SPANSION	/* SPANSION */
 	{"S25FL008A",	   0x010213, 0x0,	64 * 1024,    16, RD_NORM,			  0},
-- 
1.8.2.1

[U-Boot] [PATCH v3 6/9] sf: Update Spansion flash params

[Bin Meng]

Update supported read commands for Spansion flash parts per datasheet.
Also update flash sector size to 4KiB as long as flash supports sector
erase (20h) command.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 77aa95b..5a3a434 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"S25FL016A",	   0x010214, 0x0,	64 * 1024,    32, RD_NORM,			  0},
 	{"S25FL032A",	   0x010215, 0x0,	64 * 1024,    64, RD_NORM,			  0},
 	{"S25FL064A",	   0x010216, 0x0,	64 * 1024,   128, RD_NORM,			  0},
-	{"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_FULL,		     WR_QPP},
-	{"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_FULL,		     WR_QPP},
-	{"S25FL032P",	   0x010215, 0x4d00,    64 * 1024,    64, RD_FULL,		     WR_QPP},
-	{"S25FL064P",	   0x010216, 0x4d00,    64 * 1024,   128, RD_FULL,		     WR_QPP},
+	{"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_NORM,			  0},
+	{"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_NORM,			  0},
+	{"S25FL032P",	   0x010215, 0x4d00,     4 * 1024,  1024, RD_FULL,	   WR_QPP | SECT_4K},
+	{"S25FL064P",	   0x010216, 0x4d00,     4 * 1024,  2048, RD_FULL,	   WR_QPP | SECT_4K},
 	{"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,    64, RD_FULL,		     WR_QPP},
-	{"S25FL128S_64K",  0x012018, 0x4d01,    64 * 1024,   256, RD_FULL,		     WR_QPP},
+	{"S25FL128S_64K",  0x012018, 0x4d01,     4 * 1024,  4096, RD_FULL,	   WR_QPP | SECT_4K},
 	{"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,		     WR_QPP},
-	{"S25FL256S_64K",  0x010219, 0x4d01,	64 * 1024,   512, RD_FULL,		     WR_QPP},
+	{"S25FL256S_64K",  0x010219, 0x4d01,     4 * 1024,  8192, RD_FULL,	   WR_QPP | SECT_4K},
 	{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,		     WR_QPP},
 	{"S25FL512S_64K",  0x010220, 0x4d01,    64 * 1024,  1024, RD_FULL,		     WR_QPP},
 	{"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,		     WR_QPP},
-- 
1.8.2.1

[U-Boot] [PATCH v3 6/9] sf: Update Spansion flash params

[Jagan Teki]

Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> Update supported read commands for Spansion flash parts per datasheet.
> Also update flash sector size to 4KiB as long as flash supports sector
> erase (20h) command.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/mtd/spi/sf_params.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 77aa95b..5a3a434 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = {
>         {"S25FL016A",      0x010214, 0x0,       64 * 1024,    32, RD_NORM,                        0},
>         {"S25FL032A",      0x010215, 0x0,       64 * 1024,    64, RD_NORM,                        0},
>         {"S25FL064A",      0x010216, 0x0,       64 * 1024,   128, RD_NORM,                        0},
> -       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_FULL,                   WR_QPP},
> -       {"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_FULL,                   WR_QPP},
> -       {"S25FL032P",      0x010215, 0x4d00,    64 * 1024,    64, RD_FULL,                   WR_QPP},
> -       {"S25FL064P",      0x010216, 0x4d00,    64 * 1024,   128, RD_FULL,                   WR_QPP},
> +       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_NORM,                        0},
> +       {"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_NORM,                        0},
> +       {"S25FL032P",      0x010215, 0x4d00,     4 * 1024,  1024, RD_FULL,         WR_QPP | SECT_4K},
> +       {"S25FL064P",      0x010216, 0x4d00,     4 * 1024,  2048, RD_FULL,         WR_QPP | SECT_4K},
>         {"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,    64, RD_FULL,                   WR_QPP},
> -       {"S25FL128S_64K",  0x012018, 0x4d01,    64 * 1024,   256, RD_FULL,                   WR_QPP},
> +       {"S25FL128S_64K",  0x012018, 0x4d01,     4 * 1024,  4096, RD_FULL,         WR_QPP | SECT_4K},

This is incorrect - 64 is the sector size and it should be 64 * 1024
and 4 * 1024 is not working
on my latest test - please verify the same.

>         {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,                   WR_QPP},
> -       {"S25FL256S_64K",  0x010219, 0x4d01,    64 * 1024,   512, RD_FULL,                   WR_QPP},
> +       {"S25FL256S_64K",  0x010219, 0x4d01,     4 * 1024,  8192, RD_FULL,         WR_QPP | SECT_4K},
>         {"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
>         {"S25FL512S_64K",  0x010220, 0x4d01,    64 * 1024,  1024, RD_FULL,                   WR_QPP},
>         {"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
> --
> 1.8.2.1
>

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 6/9] sf: Update Spansion flash params

[Bin Meng]

Hi Jagan,

On Thu, Dec 11, 2014 at 4:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Update supported read commands for Spansion flash parts per datasheet.
>> Also update flash sector size to 4KiB as long as flash supports sector
>> erase (20h) command.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/mtd/spi/sf_params.c | 12 ++++++------
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index 77aa95b..5a3a434 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = {
>>         {"S25FL016A",      0x010214, 0x0,       64 * 1024,    32, RD_NORM,                        0},
>>         {"S25FL032A",      0x010215, 0x0,       64 * 1024,    64, RD_NORM,                        0},
>>         {"S25FL064A",      0x010216, 0x0,       64 * 1024,   128, RD_NORM,                        0},
>> -       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_FULL,                   WR_QPP},
>> -       {"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_FULL,                   WR_QPP},
>> -       {"S25FL032P",      0x010215, 0x4d00,    64 * 1024,    64, RD_FULL,                   WR_QPP},
>> -       {"S25FL064P",      0x010216, 0x4d00,    64 * 1024,   128, RD_FULL,                   WR_QPP},
>> +       {"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_NORM,                        0},
>> +       {"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_NORM,                        0},
>> +       {"S25FL032P",      0x010215, 0x4d00,     4 * 1024,  1024, RD_FULL,         WR_QPP | SECT_4K},
>> +       {"S25FL064P",      0x010216, 0x4d00,     4 * 1024,  2048, RD_FULL,         WR_QPP | SECT_4K},
>>         {"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,    64, RD_FULL,                   WR_QPP},
>> -       {"S25FL128S_64K",  0x012018, 0x4d01,    64 * 1024,   256, RD_FULL,                   WR_QPP},
>> +       {"S25FL128S_64K",  0x012018, 0x4d01,     4 * 1024,  4096, RD_FULL,         WR_QPP | SECT_4K},
>
> This is incorrect - 64 is the sector size and it should be 64 * 1024
> and 4 * 1024 is not working
> on my latest test - please verify the same.

Good catch! I must have been too tired to go through so many flash
datasheets and made a mistake. I will resend v4 to correct
S25FL128S_64K and S25FL256S_64K.

>
>>         {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,                   WR_QPP},
>> -       {"S25FL256S_64K",  0x010219, 0x4d01,    64 * 1024,   512, RD_FULL,                   WR_QPP},
>> +       {"S25FL256S_64K",  0x010219, 0x4d01,     4 * 1024,  8192, RD_FULL,         WR_QPP | SECT_4K},
>>         {"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
>>         {"S25FL512S_64K",  0x010220, 0x4d01,    64 * 1024,  1024, RD_FULL,                   WR_QPP},
>>         {"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,                   WR_QPP},
>> --
>> 1.8.2.1
>>
>
> thanks!
> --
> Jagan.

Regards,
Bin

[U-Boot] [PATCH v3 7/9] sf: Update Micron flash params

[Bin Meng]

Update supported read commands for Micron flash parts per datasheet.
Also update flash sector size to 4KiB as long as flash supports sector
erase (20h) command.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 46 ++++++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5a3a434..034d092 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -65,29 +65,29 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,		     WR_QPP},
 #endif
 #ifdef CONFIG_SPI_FLASH_STMICRO		/* STMICRO */
-	{"M25P10",	   0x202011, 0x0,	32 * 1024,     4, RD_NORM,			  0},
-	{"M25P20",	   0x202012, 0x0,       64 * 1024,     4, RD_NORM,			  0},
-	{"M25P40",	   0x202013, 0x0,       64 * 1024,     8, RD_NORM,			  0},
-	{"M25P80",	   0x202014, 0x0,       64 * 1024,    16, RD_NORM,			  0},
-	{"M25P16",	   0x202015, 0x0,       64 * 1024,    32, RD_NORM,			  0},
-	{"M25PE16",	   0x208015, 0x1000,    64 * 1024,    32, RD_NORM,			  0},
-	{"M25PX16",	   0x207115, 0x1000,    64 * 1024,    32, RD_EXTN,			  0},
-	{"M25P32",	   0x202016, 0x0,       64 * 1024,    64, RD_NORM,			  0},
-	{"M25P64",	   0x202017, 0x0,       64 * 1024,   128, RD_NORM,			  0},
-	{"M25P128",	   0x202018, 0x0,      256 * 1024,    64, RD_NORM,			  0},
-	{"M25PX64",	   0x207117, 0x0,       64 * 1024,   128, RD_NORM,		    SECT_4K},
-	{"N25Q32",	   0x20ba16, 0x0,       64 * 1024,    64, RD_FULL,	   WR_QPP | SECT_4K},
-	{"N25Q32A",	   0x20bb16, 0x0,       64 * 1024,    64, RD_FULL,	   WR_QPP | SECT_4K},
-	{"N25Q64",	   0x20ba17, 0x0,       64 * 1024,   128, RD_FULL,	   WR_QPP | SECT_4K},
-	{"N25Q64A",	   0x20bb17, 0x0,       64 * 1024,   128, RD_FULL,	   WR_QPP | SECT_4K},
-	{"N25Q128",	   0x20ba18, 0x0,       64 * 1024,   256, RD_FULL,		     WR_QPP},
-	{"N25Q128A",	   0x20bb18, 0x0,       64 * 1024,   256, RD_FULL,		     WR_QPP},
-	{"N25Q256",	   0x20ba19, 0x0,       64 * 1024,   512, RD_FULL,	   WR_QPP | SECT_4K},
-	{"N25Q256A",	   0x20bb19, 0x0,       64 * 1024,   512, RD_FULL,	   WR_QPP | SECT_4K},
-	{"N25Q512",	   0x20ba20, 0x0,       64 * 1024,  1024, RD_FULL, WR_QPP | E_FSR | SECT_4K},
-	{"N25Q512A",	   0x20bb20, 0x0,       64 * 1024,  1024, RD_FULL, WR_QPP | E_FSR | SECT_4K},
-	{"N25Q1024",	   0x20ba21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
-	{"N25Q1024A",	   0x20bb21, 0x0,       64 * 1024,  2048, RD_FULL, WR_QPP | E_FSR | SECT_4K},
+	{"M25P10",	   0x202011, 0x0,	32 * 1024,     4, RD_NORM,					      0},
+	{"M25P20",	   0x202012, 0x0,       64 * 1024,     4, RD_NORM,					      0},
+	{"M25P40",	   0x202013, 0x0,       64 * 1024,     8, RD_NORM,					      0},
+	{"M25P80",	   0x202014, 0x0,       64 * 1024,    16, RD_NORM,					      0},
+	{"M25P16",	   0x202015, 0x0,       64 * 1024,    32, RD_NORM,					      0},
+	{"M25PE16",	   0x208015, 0x1000,     4 * 1024,   512, RD_NORM,				        SECT_4K},
+	{"M25PX16",	   0x207115, 0x1000,     4 * 1024,   512, RD_NORM | DUAL_OUTPUT_FAST,		        SECT_4K},
+	{"M25P32",	   0x202016, 0x0,       64 * 1024,    64, RD_NORM,					      0},
+	{"M25P64",	   0x202017, 0x0,       64 * 1024,   128, RD_NORM,					      0},
+	{"M25P128",	   0x202018, 0x0,      256 * 1024,    64, RD_NORM,					      0},
+	{"M25PX64",	   0x207117, 0x0,        4 * 1024,  2048, RD_NORM | DUAL_OUTPUT_FAST,		        SECT_4K},
+	{"N25Q32",	   0x20ba16, 0x0,        4 * 1024,  1024, RD_FULL,			       WR_QPP | SECT_4K},
+	{"N25Q32A",	   0x20bb16, 0x0,        4 * 1024,  1024, RD_FULL,			       WR_QPP | SECT_4K},
+	{"N25Q64",	   0x20ba17, 0x0,        4 * 1024,  2048, RD_FULL,			       WR_QPP | SECT_4K},
+	{"N25Q64A",	   0x20bb17, 0x0,        4 * 1024,  2048, RD_FULL,			       WR_QPP | SECT_4K},
+	{"N25Q128",	   0x20ba18, 0x0,       64 * 1024,   256, RD_FULL,					 WR_QPP},
+	{"N25Q128A",	   0x20bb18, 0x0,       64 * 1024,   256, RD_FULL,					 WR_QPP},
+	{"N25Q256",	   0x20ba19, 0x0,        4 * 1024,  8192, RD_FULL,			       WR_QPP | SECT_4K},
+	{"N25Q256A",	   0x20bb19, 0x0,        4 * 1024,  8192, RD_FULL,			       WR_QPP | SECT_4K},
+	{"N25Q512",	   0x20ba20, 0x0,        4 * 1024, 16384, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
+	{"N25Q512A",	   0x20bb20, 0x0,        4 * 1024, 16384, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
+	{"N25Q1024",	   0x20ba21, 0x0,        4 * 1024, 32768, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
+	{"N25Q1024A",	   0x20bb21, 0x0,        4 * 1024, 32768, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SST		/* SST */
 	{"SST25VF040B",	   0xbf258d, 0x0,	 4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
-- 
1.8.2.1

[U-Boot] [PATCH v3 8/9] sf: Update Winbond flash params

[Bin Meng]

Update supported read commands for Winbond flash parts per datasheet.
Also update flash sector size to 4KiB as long as flash supports sector
erase (20h) command. Add W25X10, W25X20, W25X80 params per datasheet.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/mtd/spi/sf_params.c | 39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 034d092..735dd54 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -102,24 +102,27 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"SST25WF080",	   0xbf2505, 0x0,	 4 * 1024,   256, RD_NORM,	    SECT_4K | SST_WR},
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND		/* WINBOND */
-	{"W25P80",	   0xef2014, 0x0,	64 * 1024,    16, RD_NORM,		           0},
-	{"W25P16",	   0xef2015, 0x0,	64 * 1024,    32, RD_NORM,		           0},
-	{"W25P32",	   0xef2016, 0x0,	64 * 1024,    64, RD_NORM,		           0},
-	{"W25X40",	   0xef3013, 0x0,	64 * 1024,     8, RD_NORM,		     SECT_4K},
-	{"W25X16",	   0xef3015, 0x0,	64 * 1024,    32, RD_NORM,		     SECT_4K},
-	{"W25X32",	   0xef3016, 0x0,	64 * 1024,    64, RD_NORM,		     SECT_4K},
-	{"W25X64",	   0xef3017, 0x0,	64 * 1024,   128, RD_NORM,		     SECT_4K},
-	{"W25Q80BL",	   0xef4014, 0x0,	64 * 1024,    16, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q16CL",	   0xef4015, 0x0,	64 * 1024,    32, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q32BV",	   0xef4016, 0x0,	64 * 1024,    64, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q64CV",	   0xef4017, 0x0,	64 * 1024,   128, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q128BV",	   0xef4018, 0x0,	64 * 1024,   256, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q256",	   0xef4019, 0x0,	64 * 1024,   512, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q80BW",	   0xef5014, 0x0,	64 * 1024,    16, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q16DW",	   0xef6015, 0x0,	64 * 1024,    32, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q32DW",	   0xef6016, 0x0,	64 * 1024,    64, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q64DW",	   0xef6017, 0x0,	64 * 1024,   128, RD_FULL,	    WR_QPP | SECT_4K},
-	{"W25Q128FW",	   0xef6018, 0x0,	64 * 1024,   256, RD_FULL,	    WR_QPP | SECT_4K},
+	{"W25P80",	   0xef2014, 0x0,	64 * 1024,    16, RD_NORM,				       0},
+	{"W25P16",	   0xef2015, 0x0,	64 * 1024,    32, RD_NORM,				       0},
+	{"W25P32",	   0xef2016, 0x0,	64 * 1024,    64, RD_NORM,				       0},
+	{"W25X10",	   0xef3011, 0x0,	 4 * 1024,    32, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25X20",	   0xef3012, 0x0,	 4 * 1024,    64, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25X40",	   0xef3013, 0x0,	 4 * 1024,   128, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25X80",	   0xef3014, 0x0,	 4 * 1024,   256, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25X16",	   0xef3015, 0x0,	 4 * 1024,   512, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25X32",	   0xef3016, 0x0,	 4 * 1024,  1024, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25X64",	   0xef3017, 0x0,	 4 * 1024,  2048, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
+	{"W25Q80BL",	   0xef4014, 0x0,	 4 * 1024,   256, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q16CL",	   0xef4015, 0x0,	 4 * 1024,   512, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q32BV",	   0xef4016, 0x0,	 4 * 1024,  1024, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q64CV",	   0xef4017, 0x0,	 4 * 1024,  2048, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q128BV",	   0xef4018, 0x0,	 4 * 1024,  4096, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q256",	   0xef4019, 0x0,	 4 * 1024,  8192, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q80BW",	   0xef5014, 0x0,	 4 * 1024,   256, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q16DW",	   0xef6015, 0x0,	 4 * 1024,   512, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q32DW",	   0xef6016, 0x0,	 4 * 1024,  1024, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q64DW",	   0xef6017, 0x0,	 4 * 1024,  2048, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25Q128FW",	   0xef6018, 0x0,	 4 * 1024,  4096, RD_FULL,			WR_QPP | SECT_4K},
 #endif
 	{},	/* Empty entry to terminate the list */
 	/*
-- 
1.8.2.1

[U-Boot] [PATCH v3 9/9] sf: Give proper spacing between flash table params

[Bin Meng]

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

---

 drivers/mtd/spi/sf_params.c | 169 ++++++++++++++++++++++----------------------
 1 file changed, 85 insertions(+), 84 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 735dd54..b5177ad 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -2,6 +2,7 @@
  * SPI flash Params table
  *
  * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc.
+ * Copyright (C) 2014 Bin Meng <bmeng.cn@gmail.com>
  *
  * SPDX-License-Identifier:	GPL-2.0+
  */
@@ -15,25 +16,25 @@
 /* SPI/QSPI flash device params structure */
 const struct spi_flash_params spi_flash_params_table[] = {
 #ifdef CONFIG_SPI_FLASH_ATMEL		/* ATMEL */
-	{"AT45DB011D",	   0x1f2200, 0x0,	 2 * 1024,    64, RD_NORM,		          0},
-	{"AT45DB021D",	   0x1f2300, 0x0,	 2 * 1024,   128, RD_NORM,		          0},
-	{"AT45DB041D",	   0x1f2400, 0x0,	 2 * 1024,   256, RD_NORM,		          0},
-	{"AT45DB081D",	   0x1f2500, 0x0,	 2 * 1024,   512, RD_NORM,		          0},
-	{"AT45DB161D",	   0x1f2600, 0x0,	 4 * 1024,   512, RD_NORM,		          0},
-	{"AT45DB321D",	   0x1f2700, 0x0,	 4 * 1024,  1024, RD_NORM,		          0},
-	{"AT45DB641D",	   0x1f2800, 0x0,	 2 * 1024,  4096, RD_NORM,		          0},
-	{"AT25DF321",      0x1f4700, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
-	{"AT25DF321A",     0x1f4701, 0x0,	 4 * 1024,  1024, RD_NORM,		    SECT_4K},
+	{"AT45DB011D",	   0x1f2200, 0x0,	 2 * 1024,    64, RD_NORM,						0},
+	{"AT45DB021D",	   0x1f2300, 0x0,	 2 * 1024,   128, RD_NORM,						0},
+	{"AT45DB041D",	   0x1f2400, 0x0,	 2 * 1024,   256, RD_NORM,						0},
+	{"AT45DB081D",	   0x1f2500, 0x0,	 2 * 1024,   512, RD_NORM,						0},
+	{"AT45DB161D",	   0x1f2600, 0x0,	 4 * 1024,   512, RD_NORM,						0},
+	{"AT45DB321D",	   0x1f2700, 0x0,	 4 * 1024,  1024, RD_NORM,						0},
+	{"AT45DB641D",	   0x1f2800, 0x0,	 2 * 1024,  4096, RD_NORM,						0},
+	{"AT25DF321",	   0x1f4700, 0x0,	 4 * 1024,  1024, RD_NORM,					  SECT_4K},
+	{"AT25DF321A",	   0x1f4701, 0x0,	 4 * 1024,  1024, RD_NORM,					  SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON		/* EON */
-	{"EN25Q32B",	   0x1c3016, 0x0,	 4 * 1024,  1024, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
-	{"EN25Q64",	   0x1c3017, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
-	{"EN25Q128B",	   0x1c3018, 0x0,        4 * 1024,  4096, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
-	{"EN25S64",	   0x1c3817, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,   SECT_4K},
+	{"EN25Q32B",	   0x1c3016, 0x0,	 4 * 1024,  1024, RD_EXTN | QUAD_IO_FAST,			  SECT_4K},
+	{"EN25Q64",	   0x1c3017, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,			  SECT_4K},
+	{"EN25Q128B",	   0x1c3018, 0x0,	 4 * 1024,  4096, RD_EXTN | QUAD_IO_FAST,			  SECT_4K},
+	{"EN25S64",	   0x1c3817, 0x0,	 4 * 1024,  2048, RD_EXTN | QUAD_IO_FAST,			  SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_GIGADEVICE	/* GIGADEVICE */
-	{"GD25Q64B",	   0xc84017, 0x0,	 4 * 1024,  2048, RD_FULL,		    SECT_4K},
-	{"GD25LQ32",	   0xc86016, 0x0,	 4 * 1024,  1024, RD_FULL,		    SECT_4K},
+	{"GD25Q64B",	   0xc84017, 0x0,	 4 * 1024,  2048, RD_FULL,					  SECT_4K},
+	{"GD25LQ32",	   0xc86016, 0x0,	 4 * 1024,  1024, RD_FULL,					  SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX	/* MACRONIX */
 	{"MX25L2006E",	   0xc22012, 0x0,	 4 * 1024,    64, RD_NORM | DUAL_OUTPUT_FAST, 			  SECT_4K},
@@ -48,81 +49,81 @@ const struct spi_flash_params spi_flash_params_table[] = {
 	{"MX25L12855E",	   0xc22618, 0x0,	 4 * 1024,  4096, RD_NORM | DUAL_IO_FAST | QUAD_IO_FAST, WR_QPP | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SPANSION	/* SPANSION */
-	{"S25FL008A",	   0x010213, 0x0,	64 * 1024,    16, RD_NORM,			  0},
-	{"S25FL016A",	   0x010214, 0x0,	64 * 1024,    32, RD_NORM,			  0},
-	{"S25FL032A",	   0x010215, 0x0,	64 * 1024,    64, RD_NORM,			  0},
-	{"S25FL064A",	   0x010216, 0x0,	64 * 1024,   128, RD_NORM,			  0},
-	{"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_NORM,			  0},
-	{"S25FL128P_64K",  0x012018, 0x0301,    64 * 1024,   256, RD_NORM,			  0},
-	{"S25FL032P",	   0x010215, 0x4d00,     4 * 1024,  1024, RD_FULL,	   WR_QPP | SECT_4K},
-	{"S25FL064P",	   0x010216, 0x4d00,     4 * 1024,  2048, RD_FULL,	   WR_QPP | SECT_4K},
-	{"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,    64, RD_FULL,		     WR_QPP},
-	{"S25FL128S_64K",  0x012018, 0x4d01,     4 * 1024,  4096, RD_FULL,	   WR_QPP | SECT_4K},
-	{"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,		     WR_QPP},
-	{"S25FL256S_64K",  0x010219, 0x4d01,     4 * 1024,  8192, RD_FULL,	   WR_QPP | SECT_4K},
-	{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,		     WR_QPP},
-	{"S25FL512S_64K",  0x010220, 0x4d01,    64 * 1024,  1024, RD_FULL,		     WR_QPP},
-	{"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,		     WR_QPP},
+	{"S25FL008A",	   0x010213, 0x0,	64 * 1024,    16, RD_NORM,						0},
+	{"S25FL016A",	   0x010214, 0x0,	64 * 1024,    32, RD_NORM,						0},
+	{"S25FL032A",	   0x010215, 0x0,	64 * 1024,    64, RD_NORM,						0},
+	{"S25FL064A",	   0x010216, 0x0,	64 * 1024,   128, RD_NORM,						0},
+	{"S25FL128P_256K", 0x012018, 0x0300,   256 * 1024,    64, RD_NORM,						0},
+	{"S25FL128P_64K",  0x012018, 0x0301,	64 * 1024,   256, RD_NORM,						0},
+	{"S25FL032P",	   0x010215, 0x4d00,	 4 * 1024,  1024, RD_FULL,				 WR_QPP | SECT_4K},
+	{"S25FL064P",	   0x010216, 0x4d00,	 4 * 1024,  2048, RD_FULL,				 WR_QPP | SECT_4K},
+	{"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,    64, RD_FULL,					   WR_QPP},
+	{"S25FL128S_64K",  0x012018, 0x4d01,	 4 * 1024,  4096, RD_FULL,				 WR_QPP | SECT_4K},
+	{"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,					   WR_QPP},
+	{"S25FL256S_64K",  0x010219, 0x4d01,	 4 * 1024,  8192, RD_FULL,				 WR_QPP | SECT_4K},
+	{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,					   WR_QPP},
+	{"S25FL512S_64K",  0x010220, 0x4d01,	64 * 1024,  1024, RD_FULL,					   WR_QPP},
+	{"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,					   WR_QPP},
 #endif
 #ifdef CONFIG_SPI_FLASH_STMICRO		/* STMICRO */
-	{"M25P10",	   0x202011, 0x0,	32 * 1024,     4, RD_NORM,					      0},
-	{"M25P20",	   0x202012, 0x0,       64 * 1024,     4, RD_NORM,					      0},
-	{"M25P40",	   0x202013, 0x0,       64 * 1024,     8, RD_NORM,					      0},
-	{"M25P80",	   0x202014, 0x0,       64 * 1024,    16, RD_NORM,					      0},
-	{"M25P16",	   0x202015, 0x0,       64 * 1024,    32, RD_NORM,					      0},
-	{"M25PE16",	   0x208015, 0x1000,     4 * 1024,   512, RD_NORM,				        SECT_4K},
-	{"M25PX16",	   0x207115, 0x1000,     4 * 1024,   512, RD_NORM | DUAL_OUTPUT_FAST,		        SECT_4K},
-	{"M25P32",	   0x202016, 0x0,       64 * 1024,    64, RD_NORM,					      0},
-	{"M25P64",	   0x202017, 0x0,       64 * 1024,   128, RD_NORM,					      0},
-	{"M25P128",	   0x202018, 0x0,      256 * 1024,    64, RD_NORM,					      0},
-	{"M25PX64",	   0x207117, 0x0,        4 * 1024,  2048, RD_NORM | DUAL_OUTPUT_FAST,		        SECT_4K},
-	{"N25Q32",	   0x20ba16, 0x0,        4 * 1024,  1024, RD_FULL,			       WR_QPP | SECT_4K},
-	{"N25Q32A",	   0x20bb16, 0x0,        4 * 1024,  1024, RD_FULL,			       WR_QPP | SECT_4K},
-	{"N25Q64",	   0x20ba17, 0x0,        4 * 1024,  2048, RD_FULL,			       WR_QPP | SECT_4K},
-	{"N25Q64A",	   0x20bb17, 0x0,        4 * 1024,  2048, RD_FULL,			       WR_QPP | SECT_4K},
-	{"N25Q128",	   0x20ba18, 0x0,       64 * 1024,   256, RD_FULL,					 WR_QPP},
-	{"N25Q128A",	   0x20bb18, 0x0,       64 * 1024,   256, RD_FULL,					 WR_QPP},
-	{"N25Q256",	   0x20ba19, 0x0,        4 * 1024,  8192, RD_FULL,			       WR_QPP | SECT_4K},
-	{"N25Q256A",	   0x20bb19, 0x0,        4 * 1024,  8192, RD_FULL,			       WR_QPP | SECT_4K},
-	{"N25Q512",	   0x20ba20, 0x0,        4 * 1024, 16384, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
-	{"N25Q512A",	   0x20bb20, 0x0,        4 * 1024, 16384, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
-	{"N25Q1024",	   0x20ba21, 0x0,        4 * 1024, 32768, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
-	{"N25Q1024A",	   0x20bb21, 0x0,        4 * 1024, 32768, RD_FULL,		       WR_QPP | E_FSR | SECT_4K},
+	{"M25P10",	   0x202011, 0x0,	32 * 1024,     4, RD_NORM,						0},
+	{"M25P20",	   0x202012, 0x0,	64 * 1024,     4, RD_NORM,						0},
+	{"M25P40",	   0x202013, 0x0,	64 * 1024,     8, RD_NORM,						0},
+	{"M25P80",	   0x202014, 0x0,	64 * 1024,    16, RD_NORM,						0},
+	{"M25P16",	   0x202015, 0x0,	64 * 1024,    32, RD_NORM,						0},
+	{"M25PE16",	   0x208015, 0x1000,	 4 * 1024,   512, RD_NORM,					  SECT_4K},
+	{"M25PX16",	   0x207115, 0x1000,	 4 * 1024,   512, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"M25P32",	   0x202016, 0x0,	64 * 1024,    64, RD_NORM,						0},
+	{"M25P64",	   0x202017, 0x0,	64 * 1024,   128, RD_NORM,						0},
+	{"M25P128",	   0x202018, 0x0,      256 * 1024,    64, RD_NORM,						0},
+	{"M25PX64",	   0x207117, 0x0,	 4 * 1024,  2048, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"N25Q32",	   0x20ba16, 0x0,	 4 * 1024,  1024, RD_FULL,				 WR_QPP | SECT_4K},
+	{"N25Q32A",	   0x20bb16, 0x0,	 4 * 1024,  1024, RD_FULL,				 WR_QPP | SECT_4K},
+	{"N25Q64",	   0x20ba17, 0x0,	 4 * 1024,  2048, RD_FULL,				 WR_QPP | SECT_4K},
+	{"N25Q64A",	   0x20bb17, 0x0,	 4 * 1024,  2048, RD_FULL,				 WR_QPP | SECT_4K},
+	{"N25Q128",	   0x20ba18, 0x0,	64 * 1024,   256, RD_FULL,					   WR_QPP},
+	{"N25Q128A",	   0x20bb18, 0x0,	64 * 1024,   256, RD_FULL,					   WR_QPP},
+	{"N25Q256",	   0x20ba19, 0x0,	 4 * 1024,  8192, RD_FULL,				 WR_QPP | SECT_4K},
+	{"N25Q256A",	   0x20bb19, 0x0,	 4 * 1024,  8192, RD_FULL,				 WR_QPP | SECT_4K},
+	{"N25Q512",	   0x20ba20, 0x0,	 4 * 1024, 16384, RD_FULL,			 WR_QPP | E_FSR | SECT_4K},
+	{"N25Q512A",	   0x20bb20, 0x0,	 4 * 1024, 16384, RD_FULL,			 WR_QPP | E_FSR | SECT_4K},
+	{"N25Q1024",	   0x20ba21, 0x0,	 4 * 1024, 32768, RD_FULL,			 WR_QPP | E_FSR | SECT_4K},
+	{"N25Q1024A",	   0x20bb21, 0x0,	 4 * 1024, 32768, RD_FULL,			 WR_QPP | E_FSR | SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_SST		/* SST */
-	{"SST25VF040B",	   0xbf258d, 0x0,	 4 * 1024,   128, RD_NORM,          SECT_4K | SST_WR},
-	{"SST25VF080B",	   0xbf258e, 0x0,	 4 * 1024,   256, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25VF016B",	   0xbf2541, 0x0,	 4 * 1024,   512, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25VF032B",	   0xbf254a, 0x0,	 4 * 1024,  1024, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25VF064C",	   0xbf254b, 0x0,	 4 * 1024,  2048, RD_EXTN,		     SECT_4K},
-	{"SST25WF512",	   0xbf2501, 0x0,	 4 * 1024,    16, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25WF010",	   0xbf2502, 0x0,	 4 * 1024,    32, RD_NORM,          SECT_4K | SST_WR},
-	{"SST25WF020",	   0xbf2503, 0x0,	 4 * 1024,    64, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25WF040",	   0xbf2504, 0x0,	 4 * 1024,   128, RD_NORM,	    SECT_4K | SST_WR},
-	{"SST25WF080",	   0xbf2505, 0x0,	 4 * 1024,   256, RD_NORM,	    SECT_4K | SST_WR},
+	{"SST25VF040B",	   0xbf258d, 0x0,	 4 * 1024,   128, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25VF080B",	   0xbf258e, 0x0,	 4 * 1024,   256, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25VF016B",	   0xbf2541, 0x0,	 4 * 1024,   512, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25VF032B",	   0xbf254a, 0x0,	 4 * 1024,  1024, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25VF064C",	   0xbf254b, 0x0,	 4 * 1024,  2048, RD_EXTN,					  SECT_4K},
+	{"SST25WF512",	   0xbf2501, 0x0,	 4 * 1024,    16, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25WF010",	   0xbf2502, 0x0,	 4 * 1024,    32, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25WF020",	   0xbf2503, 0x0,	 4 * 1024,    64, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25WF040",	   0xbf2504, 0x0,	 4 * 1024,   128, RD_NORM,				 SECT_4K | SST_WR},
+	{"SST25WF080",	   0xbf2505, 0x0,	 4 * 1024,   256, RD_NORM,				 SECT_4K | SST_WR},
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND		/* WINBOND */
-	{"W25P80",	   0xef2014, 0x0,	64 * 1024,    16, RD_NORM,				       0},
-	{"W25P16",	   0xef2015, 0x0,	64 * 1024,    32, RD_NORM,				       0},
-	{"W25P32",	   0xef2016, 0x0,	64 * 1024,    64, RD_NORM,				       0},
-	{"W25X10",	   0xef3011, 0x0,	 4 * 1024,    32, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25X20",	   0xef3012, 0x0,	 4 * 1024,    64, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25X40",	   0xef3013, 0x0,	 4 * 1024,   128, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25X80",	   0xef3014, 0x0,	 4 * 1024,   256, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25X16",	   0xef3015, 0x0,	 4 * 1024,   512, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25X32",	   0xef3016, 0x0,	 4 * 1024,  1024, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25X64",	   0xef3017, 0x0,	 4 * 1024,  2048, RD_NORM | DUAL_OUTPUT_FAST,		 SECT_4K},
-	{"W25Q80BL",	   0xef4014, 0x0,	 4 * 1024,   256, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q16CL",	   0xef4015, 0x0,	 4 * 1024,   512, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q32BV",	   0xef4016, 0x0,	 4 * 1024,  1024, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q64CV",	   0xef4017, 0x0,	 4 * 1024,  2048, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q128BV",	   0xef4018, 0x0,	 4 * 1024,  4096, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q256",	   0xef4019, 0x0,	 4 * 1024,  8192, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q80BW",	   0xef5014, 0x0,	 4 * 1024,   256, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q16DW",	   0xef6015, 0x0,	 4 * 1024,   512, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q32DW",	   0xef6016, 0x0,	 4 * 1024,  1024, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q64DW",	   0xef6017, 0x0,	 4 * 1024,  2048, RD_FULL,			WR_QPP | SECT_4K},
-	{"W25Q128FW",	   0xef6018, 0x0,	 4 * 1024,  4096, RD_FULL,			WR_QPP | SECT_4K},
+	{"W25P80",	   0xef2014, 0x0,	64 * 1024,    16, RD_NORM,						0},
+	{"W25P16",	   0xef2015, 0x0,	64 * 1024,    32, RD_NORM,						0},
+	{"W25P32",	   0xef2016, 0x0,	64 * 1024,    64, RD_NORM,						0},
+	{"W25X10",	   0xef3011, 0x0,	 4 * 1024,    32, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25X20",	   0xef3012, 0x0,	 4 * 1024,    64, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25X40",	   0xef3013, 0x0,	 4 * 1024,   128, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25X80",	   0xef3014, 0x0,	 4 * 1024,   256, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25X16",	   0xef3015, 0x0,	 4 * 1024,   512, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25X32",	   0xef3016, 0x0,	 4 * 1024,  1024, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25X64",	   0xef3017, 0x0,	 4 * 1024,  2048, RD_NORM | DUAL_OUTPUT_FAST,			  SECT_4K},
+	{"W25Q80BL",	   0xef4014, 0x0,	 4 * 1024,   256, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q16CL",	   0xef4015, 0x0,	 4 * 1024,   512, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q32BV",	   0xef4016, 0x0,	 4 * 1024,  1024, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q64CV",	   0xef4017, 0x0,	 4 * 1024,  2048, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q128BV",	   0xef4018, 0x0,	 4 * 1024,  4096, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q256",	   0xef4019, 0x0,	 4 * 1024,  8192, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q80BW",	   0xef5014, 0x0,	 4 * 1024,   256, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q16DW",	   0xef6015, 0x0,	 4 * 1024,   512, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q32DW",	   0xef6016, 0x0,	 4 * 1024,  1024, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q64DW",	   0xef6017, 0x0,	 4 * 1024,  2048, RD_FULL,				 WR_QPP | SECT_4K},
+	{"W25Q128FW",	   0xef6018, 0x0,	 4 * 1024,  4096, RD_FULL,				 WR_QPP | SECT_4K},
 #endif
 	{},	/* Empty entry to terminate the list */
 	/*
-- 
1.8.2.1

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

Hi Bin,

On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> This series update SPI flash supported read commands per datasheet
> in the flash params table, and change flash sector size to 4KiB as
> long as flash supports sector erase (20h) command, to ensure
> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
> given SECT_4K.
>
> Changes in v3:
> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>
>
> Bin Meng (9):
>   sf: Update SST flash params
>   sf: Update Atmel flash params
>   sf: Update EON flash params
>   sf: Update GigaDevice flash params
>   sf: Update Macronix flash params
>   sf: Update Spansion flash params
>   sf: Update Micron flash params
>   sf: Update Winbond flash params
>   sf: Give proper spacing between flash table params

Thanks for the updates - have you verified these changes?

>
>  drivers/mtd/spi/sf_internal.h |   5 ++
>  drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
>  drivers/mtd/spi/sf_probe.c    |   4 +
>  3 files changed, 104 insertions(+), 90 deletions(-)
>
> --
> 1.8.2.1
>

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> This series update SPI flash supported read commands per datasheet
>> in the flash params table, and change flash sector size to 4KiB as
>> long as flash supports sector erase (20h) command, to ensure
>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>> given SECT_4K.
>>
>> Changes in v3:
>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>
>>
>> Bin Meng (9):
>>   sf: Update SST flash params
>>   sf: Update Atmel flash params
>>   sf: Update EON flash params
>>   sf: Update GigaDevice flash params
>>   sf: Update Macronix flash params
>>   sf: Update Spansion flash params
>>   sf: Update Micron flash params
>>   sf: Update Winbond flash params
>>   sf: Give proper spacing between flash table params
>
> Thanks for the updates - have you verified these changes?

I verified some, but not all of these flash parts. The update is based
on flash datasheet, so if something is broken, eg before this series
the flash advertises only READ_NORM and after my series it is changed
to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
likely that the SPI controller driver has some bugs when supporting
QUAD_IO_FAST.

>>
>>  drivers/mtd/spi/sf_internal.h |   5 ++
>>  drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
>>  drivers/mtd/spi/sf_probe.c    |   4 +
>>  3 files changed, 104 insertions(+), 90 deletions(-)
>>
>> --
>> 1.8.2.1
>>
>
> thanks!
> --
> Jagan.

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

Hi Bin,

On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> This series update SPI flash supported read commands per datasheet
>>> in the flash params table, and change flash sector size to 4KiB as
>>> long as flash supports sector erase (20h) command, to ensure
>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>> given SECT_4K.
>>>
>>> Changes in v3:
>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>
>>>
>>> Bin Meng (9):
>>>   sf: Update SST flash params
>>>   sf: Update Atmel flash params
>>>   sf: Update EON flash params
>>>   sf: Update GigaDevice flash params
>>>   sf: Update Macronix flash params
>>>   sf: Update Spansion flash params
>>>   sf: Update Micron flash params
>>>   sf: Update Winbond flash params
>>>   sf: Give proper spacing between flash table params
>>
>> Thanks for the updates - have you verified these changes?
>
> I verified some, but not all of these flash parts. The update is based
> on flash datasheet, so if something is broken, eg before this series
> the flash advertises only READ_NORM and after my series it is changed
> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
> likely that the SPI controller driver has some bugs when supporting
> QUAD_IO_FAST.

Since these updates were tested before, I will skip these for this PR.
Will test all the rest (except these) and send the PR soon.

Let me know your inputs?

>
>>>
>>>  drivers/mtd/spi/sf_internal.h |   5 ++
>>>  drivers/mtd/spi/sf_params.c   | 185 ++++++++++++++++++++++--------------------
>>>  drivers/mtd/spi/sf_probe.c    |   4 +
>>>  3 files changed, 104 insertions(+), 90 deletions(-)


thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> This series update SPI flash supported read commands per datasheet
>>>> in the flash params table, and change flash sector size to 4KiB as
>>>> long as flash supports sector erase (20h) command, to ensure
>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>> given SECT_4K.
>>>>
>>>> Changes in v3:
>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>
>>>>
>>>> Bin Meng (9):
>>>>   sf: Update SST flash params
>>>>   sf: Update Atmel flash params
>>>>   sf: Update EON flash params
>>>>   sf: Update GigaDevice flash params
>>>>   sf: Update Macronix flash params
>>>>   sf: Update Spansion flash params
>>>>   sf: Update Micron flash params
>>>>   sf: Update Winbond flash params
>>>>   sf: Give proper spacing between flash table params
>>>
>>> Thanks for the updates - have you verified these changes?
>>
>> I verified some, but not all of these flash parts. The update is based
>> on flash datasheet, so if something is broken, eg before this series
>> the flash advertises only READ_NORM and after my series it is changed
>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>> likely that the SPI controller driver has some bugs when supporting
>> QUAD_IO_FAST.
>
> Since these updates were tested before, I will skip these for this PR.
> Will test all the rest (except these) and send the PR soon.
>
> Let me know your inputs?

I am fine, as long as this PR will not contains other commits which
modify the same sf_params.c to introduce more flash support. We can
test these updates and if everything looks fine, apply these first and
ask other commits to rebase on this series to introduce more flash
support.

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Bin,
>>
>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> This series update SPI flash supported read commands per datasheet
>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>> given SECT_4K.
>>>>>
>>>>> Changes in v3:
>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>
>>>>>
>>>>> Bin Meng (9):
>>>>>   sf: Update SST flash params
>>>>>   sf: Update Atmel flash params
>>>>>   sf: Update EON flash params
>>>>>   sf: Update GigaDevice flash params
>>>>>   sf: Update Macronix flash params
>>>>>   sf: Update Spansion flash params
>>>>>   sf: Update Micron flash params
>>>>>   sf: Update Winbond flash params
>>>>>   sf: Give proper spacing between flash table params
>>>>
>>>> Thanks for the updates - have you verified these changes?
>>>
>>> I verified some, but not all of these flash parts. The update is based
>>> on flash datasheet, so if something is broken, eg before this series
>>> the flash advertises only READ_NORM and after my series it is changed
>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>> likely that the SPI controller driver has some bugs when supporting
>>> QUAD_IO_FAST.
>>
>> Since these updates were tested before, I will skip these for this PR.
>> Will test all the rest (except these) and send the PR soon.
>>
>> Let me know your inputs?
>
> I am fine, as long as this PR will not contains other commits which
> modify the same sf_params.c to introduce more flash support. We can
> test these updates and if everything looks fine, apply these first and
> ask other commits to rebase on this series to introduce more flash
> support.
>

Do you have any additional comments about this patch series besides
the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
the v4.

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>> given SECT_4K.
>>>>>>
>>>>>> Changes in v3:
>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>
>>>>>>
>>>>>> Bin Meng (9):
>>>>>>   sf: Update SST flash params
>>>>>>   sf: Update Atmel flash params
>>>>>>   sf: Update EON flash params
>>>>>>   sf: Update GigaDevice flash params
>>>>>>   sf: Update Macronix flash params
>>>>>>   sf: Update Spansion flash params
>>>>>>   sf: Update Micron flash params
>>>>>>   sf: Update Winbond flash params
>>>>>>   sf: Give proper spacing between flash table params
>>>>>
>>>>> Thanks for the updates - have you verified these changes?
>>>>
>>>> I verified some, but not all of these flash parts. The update is based
>>>> on flash datasheet, so if something is broken, eg before this series
>>>> the flash advertises only READ_NORM and after my series it is changed
>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>> likely that the SPI controller driver has some bugs when supporting
>>>> QUAD_IO_FAST.
>>>
>>> Since these updates were tested before, I will skip these for this PR.
>>> Will test all the rest (except these) and send the PR soon.
>>>
>>> Let me know your inputs?
>>
>> I am fine, as long as this PR will not contains other commits which
>> modify the same sf_params.c to introduce more flash support. We can
>> test these updates and if everything looks fine, apply these first and
>> ask other commits to rebase on this series to introduce more flash
>> support.
>>
>
> Do you have any additional comments about this patch series besides
> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
> the v4.

I'm thinking about the other flashes too,  since these params were taken from
previous working and Linux mtd.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>> given SECT_4K.
>>>>>>>
>>>>>>> Changes in v3:
>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>
>>>>>>>
>>>>>>> Bin Meng (9):
>>>>>>>   sf: Update SST flash params
>>>>>>>   sf: Update Atmel flash params
>>>>>>>   sf: Update EON flash params
>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>   sf: Update Macronix flash params
>>>>>>>   sf: Update Spansion flash params
>>>>>>>   sf: Update Micron flash params
>>>>>>>   sf: Update Winbond flash params
>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>
>>>>>> Thanks for the updates - have you verified these changes?
>>>>>
>>>>> I verified some, but not all of these flash parts. The update is based
>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>> QUAD_IO_FAST.
>>>>
>>>> Since these updates were tested before, I will skip these for this PR.
>>>> Will test all the rest (except these) and send the PR soon.
>>>>
>>>> Let me know your inputs?
>>>
>>> I am fine, as long as this PR will not contains other commits which
>>> modify the same sf_params.c to introduce more flash support. We can
>>> test these updates and if everything looks fine, apply these first and
>>> ask other commits to rebase on this series to introduce more flash
>>> support.
>>>
>>
>> Do you have any additional comments about this patch series besides
>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>> the v4.
>
> I'm thinking about the other flashes too,  since these params were taken from
> previous working and Linux mtd.
>

You mean 'thinking about' or 'testing'? I should say previously they
might not be 100% working as per datasheet some flash params currently
are apparently wrong.

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>>> given SECT_4K.
>>>>>>>>
>>>>>>>> Changes in v3:
>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>>
>>>>>>>>
>>>>>>>> Bin Meng (9):
>>>>>>>>   sf: Update SST flash params
>>>>>>>>   sf: Update Atmel flash params
>>>>>>>>   sf: Update EON flash params
>>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>>   sf: Update Macronix flash params
>>>>>>>>   sf: Update Spansion flash params
>>>>>>>>   sf: Update Micron flash params
>>>>>>>>   sf: Update Winbond flash params
>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>>
>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>>
>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>> QUAD_IO_FAST.
>>>>>
>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>
>>>>> Let me know your inputs?
>>>>
>>>> I am fine, as long as this PR will not contains other commits which
>>>> modify the same sf_params.c to introduce more flash support. We can
>>>> test these updates and if everything looks fine, apply these first and
>>>> ask other commits to rebase on this series to introduce more flash
>>>> support.
>>>>
>>>
>>> Do you have any additional comments about this patch series besides
>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>> the v4.
>>
>> I'm thinking about the other flashes too,  since these params were taken from
>> previous working and Linux mtd.
>>
>
> You mean 'thinking about' or 'testing'? I should say previously they
> might not be 100% working as per datasheet some flash params currently
> are apparently wrong.

Yes - about testing.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>>>> given SECT_4K.
>>>>>>>>>
>>>>>>>>> Changes in v3:
>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bin Meng (9):
>>>>>>>>>   sf: Update SST flash params
>>>>>>>>>   sf: Update Atmel flash params
>>>>>>>>>   sf: Update EON flash params
>>>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>>>   sf: Update Macronix flash params
>>>>>>>>>   sf: Update Spansion flash params
>>>>>>>>>   sf: Update Micron flash params
>>>>>>>>>   sf: Update Winbond flash params
>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>>>
>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>>>
>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>>> QUAD_IO_FAST.
>>>>>>
>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>>
>>>>>> Let me know your inputs?
>>>>>
>>>>> I am fine, as long as this PR will not contains other commits which
>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>> test these updates and if everything looks fine, apply these first and
>>>>> ask other commits to rebase on this series to introduce more flash
>>>>> support.
>>>>>
>>>>
>>>> Do you have any additional comments about this patch series besides
>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>> the v4.
>>>
>>> I'm thinking about the other flashes too,  since these params were taken from
>>> previous working and Linux mtd.
>>>
>>
>> You mean 'thinking about' or 'testing'? I should say previously they
>> might not be 100% working as per datasheet some flash params currently
>> are apparently wrong.
>
> Yes - about testing.
>

Ping? What about your test results about this patch series?

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Bin,
>>>>>>>>>
>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>>>>> given SECT_4K.
>>>>>>>>>>
>>>>>>>>>> Changes in v3:
>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Bin Meng (9):
>>>>>>>>>>   sf: Update SST flash params
>>>>>>>>>>   sf: Update Atmel flash params
>>>>>>>>>>   sf: Update EON flash params
>>>>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>>>>   sf: Update Macronix flash params
>>>>>>>>>>   sf: Update Spansion flash params
>>>>>>>>>>   sf: Update Micron flash params
>>>>>>>>>>   sf: Update Winbond flash params
>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>>>>
>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>>>>
>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>>>> QUAD_IO_FAST.
>>>>>>>
>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>>>
>>>>>>> Let me know your inputs?
>>>>>>
>>>>>> I am fine, as long as this PR will not contains other commits which
>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>>> test these updates and if everything looks fine, apply these first and
>>>>>> ask other commits to rebase on this series to introduce more flash
>>>>>> support.
>>>>>>
>>>>>
>>>>> Do you have any additional comments about this patch series besides
>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>>> the v4.
>>>>
>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>> previous working and Linux mtd.
>>>>
>>>
>>> You mean 'thinking about' or 'testing'? I should say previously they
>>> might not be 100% working as per datasheet some flash params currently
>>> are apparently wrong.
>>
>> Yes - about testing.
>>
>
> Ping? What about your test results about this patch series?

Some were pending - Will comment, pls- wait.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>>>>>> given SECT_4K.
>>>>>>>>>>>
>>>>>>>>>>> Changes in v3:
>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Bin Meng (9):
>>>>>>>>>>>   sf: Update SST flash params
>>>>>>>>>>>   sf: Update Atmel flash params
>>>>>>>>>>>   sf: Update EON flash params
>>>>>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>>>>>   sf: Update Macronix flash params
>>>>>>>>>>>   sf: Update Spansion flash params
>>>>>>>>>>>   sf: Update Micron flash params
>>>>>>>>>>>   sf: Update Winbond flash params
>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>>>>>
>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>>>>>
>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>>>>> QUAD_IO_FAST.
>>>>>>>>
>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>>>>
>>>>>>>> Let me know your inputs?
>>>>>>>
>>>>>>> I am fine, as long as this PR will not contains other commits which
>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>>>> test these updates and if everything looks fine, apply these first and
>>>>>>> ask other commits to rebase on this series to introduce more flash
>>>>>>> support.
>>>>>>>
>>>>>>
>>>>>> Do you have any additional comments about this patch series besides
>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>>>> the v4.
>>>>>
>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>>> previous working and Linux mtd.
>>>>>
>>>>
>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>>> might not be 100% working as per datasheet some flash params currently
>>>> are apparently wrong.
>>>
>>> Yes - about testing.
>>>
>>
>> Ping? What about your test results about this patch series?
>
> Some were pending - Will comment, pls- wait.
>
> thanks!
> --

I still don't see any additional comments. Looking at the history this
patch series has been sitting there for months. Would you please let
me know what you think about this series?

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Bin,
>>>>>>>>>
>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>> Hi Jagan,
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>> Hi Bin,
>>>>>>>>>>>
>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>>>>>>> given SECT_4K.
>>>>>>>>>>>>
>>>>>>>>>>>> Changes in v3:
>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Bin Meng (9):
>>>>>>>>>>>>   sf: Update SST flash params
>>>>>>>>>>>>   sf: Update Atmel flash params
>>>>>>>>>>>>   sf: Update EON flash params
>>>>>>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>>>>>>   sf: Update Macronix flash params
>>>>>>>>>>>>   sf: Update Spansion flash params
>>>>>>>>>>>>   sf: Update Micron flash params
>>>>>>>>>>>>   sf: Update Winbond flash params
>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>>>>>>
>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>>>>>> QUAD_IO_FAST.
>>>>>>>>>
>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>>>>>
>>>>>>>>> Let me know your inputs?
>>>>>>>>
>>>>>>>> I am fine, as long as this PR will not contains other commits which
>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>>>>> test these updates and if everything looks fine, apply these first and
>>>>>>>> ask other commits to rebase on this series to introduce more flash
>>>>>>>> support.
>>>>>>>>
>>>>>>>
>>>>>>> Do you have any additional comments about this patch series besides
>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>>>>> the v4.
>>>>>>
>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>>>> previous working and Linux mtd.
>>>>>>
>>>>>
>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>>>> might not be 100% working as per datasheet some flash params currently
>>>>> are apparently wrong.
>>>>
>>>> Yes - about testing.
>>>>
>>>
>>> Ping? What about your test results about this patch series?
>>
>> Some were pending - Will comment, pls- wait.
>>
>> thanks!
>> --
>
> I still don't see any additional comments. Looking at the history this
> patch series has been sitting there for months. Would you please let
> me know what you think about this series?
>

Could you respond this? I wonder if this series could be merged in
before MW is closed.

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

+Tom

Hi Jagan,

On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>> Hi Bin,
>>>>>>>>>>>>
>>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>>>>>>>>> given SECT_4K.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Changes in v3:
>>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bin Meng (9):
>>>>>>>>>>>>>   sf: Update SST flash params
>>>>>>>>>>>>>   sf: Update Atmel flash params
>>>>>>>>>>>>>   sf: Update EON flash params
>>>>>>>>>>>>>   sf: Update GigaDevice flash params
>>>>>>>>>>>>>   sf: Update Macronix flash params
>>>>>>>>>>>>>   sf: Update Spansion flash params
>>>>>>>>>>>>>   sf: Update Micron flash params
>>>>>>>>>>>>>   sf: Update Winbond flash params
>>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>>>>>>>
>>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>>>>>>> QUAD_IO_FAST.
>>>>>>>>>>
>>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>>>>>>
>>>>>>>>>> Let me know your inputs?
>>>>>>>>>
>>>>>>>>> I am fine, as long as this PR will not contains other commits which
>>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>>>>>> test these updates and if everything looks fine, apply these first and
>>>>>>>>> ask other commits to rebase on this series to introduce more flash
>>>>>>>>> support.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Do you have any additional comments about this patch series besides
>>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>>>>>> the v4.
>>>>>>>
>>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>>>>> previous working and Linux mtd.
>>>>>>>
>>>>>>
>>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>>>>> might not be 100% working as per datasheet some flash params currently
>>>>>> are apparently wrong.
>>>>>
>>>>> Yes - about testing.
>>>>>
>>>>
>>>> Ping? What about your test results about this patch series?
>>>
>>> Some were pending - Will comment, pls- wait.
>>>
>>> thanks!
>>> --
>>
>> I still don't see any additional comments. Looking at the history this
>> patch series has been sitting there for months. Would you please let
>> me know what you think about this series?
>>
>
> Could you respond this? I wonder if this series could be merged in
> before MW is closed.
>

I feel that you did not work on this. Can you please respond with any comments?

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Tom Rini]

On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
> +Tom
> 
> Hi Jagan,
> 
> On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> > Hi Jagan,
> >
> > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> Hi Jagan,
> >>
> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> >>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>> Hi Jagan,
> >>>>
> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> >>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>> Hi Jagan,
> >>>>>>
> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> >>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>>> Hi Jagan,
> >>>>>>>>
> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>>>> Hi Jagan,
> >>>>>>>>>
> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> >>>>>>>>>> Hi Bin,
> >>>>>>>>>>
> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>>>>>> Hi Jagan,
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> >>>>>>>>>>>> Hi Bin,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
> >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
> >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
> >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
> >>>>>>>>>>>>> given SECT_4K.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Changes in v3:
> >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Bin Meng (9):
> >>>>>>>>>>>>>   sf: Update SST flash params
> >>>>>>>>>>>>>   sf: Update Atmel flash params
> >>>>>>>>>>>>>   sf: Update EON flash params
> >>>>>>>>>>>>>   sf: Update GigaDevice flash params
> >>>>>>>>>>>>>   sf: Update Macronix flash params
> >>>>>>>>>>>>>   sf: Update Spansion flash params
> >>>>>>>>>>>>>   sf: Update Micron flash params
> >>>>>>>>>>>>>   sf: Update Winbond flash params
> >>>>>>>>>>>>>   sf: Give proper spacing between flash table params
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for the updates - have you verified these changes?
> >>>>>>>>>>>
> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
> >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
> >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
> >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
> >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
> >>>>>>>>>>> QUAD_IO_FAST.
> >>>>>>>>>>
> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
> >>>>>>>>>> Will test all the rest (except these) and send the PR soon.
> >>>>>>>>>>
> >>>>>>>>>> Let me know your inputs?
> >>>>>>>>>
> >>>>>>>>> I am fine, as long as this PR will not contains other commits which
> >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
> >>>>>>>>> test these updates and if everything looks fine, apply these first and
> >>>>>>>>> ask other commits to rebase on this series to introduce more flash
> >>>>>>>>> support.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Do you have any additional comments about this patch series besides
> >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
> >>>>>>>> the v4.
> >>>>>>>
> >>>>>>> I'm thinking about the other flashes too,  since these params were taken from
> >>>>>>> previous working and Linux mtd.
> >>>>>>>
> >>>>>>
> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they
> >>>>>> might not be 100% working as per datasheet some flash params currently
> >>>>>> are apparently wrong.
> >>>>>
> >>>>> Yes - about testing.
> >>>>>
> >>>>
> >>>> Ping? What about your test results about this patch series?
> >>>
> >>> Some were pending - Will comment, pls- wait.
> >>>
> >>> thanks!
> >>> --
> >>
> >> I still don't see any additional comments. Looking at the history this
> >> patch series has been sitting there for months. Would you please let
> >> me know what you think about this series?
> >>
> >
> > Could you respond this? I wonder if this series could be merged in
> > before MW is closed.
> >
> 
> I feel that you did not work on this. Can you please respond with any comments?

Indeed.  This looks like a fairly trivial sync-up, can you shoot me all
of the patchwork links and I'll take a look?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150303/ce9d6c44/attachment.sig>

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Tom,

On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
>> +Tom
>>
>> Hi Jagan,
>>
>> On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> > Hi Jagan,
>> >
>> > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> Hi Jagan,
>> >>
>> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> >>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>> Hi Jagan,
>> >>>>
>> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> >>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>>> Hi Jagan,
>> >>>>>>
>> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> >>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>>>>> Hi Jagan,
>> >>>>>>>>
>> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>>>>>> Hi Jagan,
>> >>>>>>>>>
>> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> >>>>>>>>>> Hi Bin,
>> >>>>>>>>>>
>> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>>>>>>>> Hi Jagan,
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> >>>>>>>>>>>> Hi Bin,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>> >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>> >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>> >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>> >>>>>>>>>>>>> given SECT_4K.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Changes in v3:
>> >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Bin Meng (9):
>> >>>>>>>>>>>>>   sf: Update SST flash params
>> >>>>>>>>>>>>>   sf: Update Atmel flash params
>> >>>>>>>>>>>>>   sf: Update EON flash params
>> >>>>>>>>>>>>>   sf: Update GigaDevice flash params
>> >>>>>>>>>>>>>   sf: Update Macronix flash params
>> >>>>>>>>>>>>>   sf: Update Spansion flash params
>> >>>>>>>>>>>>>   sf: Update Micron flash params
>> >>>>>>>>>>>>>   sf: Update Winbond flash params
>> >>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>> >>>>>>>>>>>
>> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>> >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>> >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>> >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>> >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>> >>>>>>>>>>> QUAD_IO_FAST.
>> >>>>>>>>>>
>> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>> >>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>> >>>>>>>>>>
>> >>>>>>>>>> Let me know your inputs?
>> >>>>>>>>>
>> >>>>>>>>> I am fine, as long as this PR will not contains other commits which
>> >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>> >>>>>>>>> test these updates and if everything looks fine, apply these first and
>> >>>>>>>>> ask other commits to rebase on this series to introduce more flash
>> >>>>>>>>> support.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Do you have any additional comments about this patch series besides
>> >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>> >>>>>>>> the v4.
>> >>>>>>>
>> >>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>> >>>>>>> previous working and Linux mtd.
>> >>>>>>>
>> >>>>>>
>> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>> >>>>>> might not be 100% working as per datasheet some flash params currently
>> >>>>>> are apparently wrong.
>> >>>>>
>> >>>>> Yes - about testing.
>> >>>>>
>> >>>>
>> >>>> Ping? What about your test results about this patch series?
>> >>>
>> >>> Some were pending - Will comment, pls- wait.
>> >>>
>> >>> thanks!
>> >>> --
>> >>
>> >> I still don't see any additional comments. Looking at the history this
>> >> patch series has been sitting there for months. Would you please let
>> >> me know what you think about this series?
>> >>
>> >
>> > Could you respond this? I wonder if this series could be merged in
>> > before MW is closed.
>> >
>>
>> I feel that you did not work on this. Can you please respond with any comments?
>
> Indeed.  This looks like a fairly trivial sync-up, can you shoot me all
> of the patchwork links and I'll take a look?  Thanks!
>
> --

Thanks for checking. Here you are:

http://patchwork.ozlabs.org/patch/419633/
http://patchwork.ozlabs.org/patch/419634/
http://patchwork.ozlabs.org/patch/419635/
http://patchwork.ozlabs.org/patch/419636/
http://patchwork.ozlabs.org/patch/419637/
http://patchwork.ozlabs.org/patch/419638/
http://patchwork.ozlabs.org/patch/419639/
http://patchwork.ozlabs.org/patch/419640/
http://patchwork.ozlabs.org/patch/419641/

They might not be applied cleanly now due to the significant delay
since it was originally posted to the mailing list. So far Jagan
pointed out only one issue and he said he would continue looking into
the patches but I did not receive any feedback for months.

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

On 4 March 2015 at 09:02, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Tom,
>
> On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini <trini@konsulko.com> wrote:
>> On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
>>> +Tom
>>>
>>> Hi Jagan,
>>>
>>> On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> > Hi Jagan,
>>> >
>>> > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >> Hi Jagan,
>>> >>
>>> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> >>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >>>> Hi Jagan,
>>> >>>>
>>> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> >>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >>>>>> Hi Jagan,
>>> >>>>>>
>>> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> >>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >>>>>>>> Hi Jagan,
>>> >>>>>>>>
>>> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >>>>>>>>> Hi Jagan,
>>> >>>>>>>>>
>>> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> >>>>>>>>>> Hi Bin,
>>> >>>>>>>>>>
>>> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >>>>>>>>>>> Hi Jagan,
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> >>>>>>>>>>>> Hi Bin,
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>> >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>> >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>> >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>> >>>>>>>>>>>>> given SECT_4K.
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Changes in v3:
>>> >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Bin Meng (9):
>>> >>>>>>>>>>>>>   sf: Update SST flash params
>>> >>>>>>>>>>>>>   sf: Update Atmel flash params
>>> >>>>>>>>>>>>>   sf: Update EON flash params
>>> >>>>>>>>>>>>>   sf: Update GigaDevice flash params
>>> >>>>>>>>>>>>>   sf: Update Macronix flash params
>>> >>>>>>>>>>>>>   sf: Update Spansion flash params
>>> >>>>>>>>>>>>>   sf: Update Micron flash params
>>> >>>>>>>>>>>>>   sf: Update Winbond flash params
>>> >>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>> >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>> >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>> >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>> >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>> >>>>>>>>>>> QUAD_IO_FAST.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>> >>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Let me know your inputs?
>>> >>>>>>>>>
>>> >>>>>>>>> I am fine, as long as this PR will not contains other commits which
>>> >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>> >>>>>>>>> test these updates and if everything looks fine, apply these first and
>>> >>>>>>>>> ask other commits to rebase on this series to introduce more flash
>>> >>>>>>>>> support.
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Do you have any additional comments about this patch series besides
>>> >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>> >>>>>>>> the v4.
>>> >>>>>>>
>>> >>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>> >>>>>>> previous working and Linux mtd.
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>> >>>>>> might not be 100% working as per datasheet some flash params currently
>>> >>>>>> are apparently wrong.
>>> >>>>>
>>> >>>>> Yes - about testing.
>>> >>>>>
>>> >>>>
>>> >>>> Ping? What about your test results about this patch series?
>>> >>>
>>> >>> Some were pending - Will comment, pls- wait.
>>> >>>
>>> >>> thanks!
>>> >>> --
>>> >>
>>> >> I still don't see any additional comments. Looking at the history this
>>> >> patch series has been sitting there for months. Would you please let
>>> >> me know what you think about this series?
>>> >>
>>> >
>>> > Could you respond this? I wonder if this series could be merged in
>>> > before MW is closed.
>>> >
>>>
>>> I feel that you did not work on this. Can you please respond with any comments?
>>
>> Indeed.  This looks like a fairly trivial sync-up, can you shoot me all
>> of the patchwork links and I'll take a look?  Thanks!
>>
>> --
>
> Thanks for checking. Here you are:
>
> http://patchwork.ozlabs.org/patch/419633/
> http://patchwork.ozlabs.org/patch/419634/
> http://patchwork.ozlabs.org/patch/419635/
> http://patchwork.ozlabs.org/patch/419636/
> http://patchwork.ozlabs.org/patch/419637/
> http://patchwork.ozlabs.org/patch/419638/
> http://patchwork.ozlabs.org/patch/419639/
> http://patchwork.ozlabs.org/patch/419640/
> http://patchwork.ozlabs.org/patch/419641/
>
> They might not be applied cleanly now due to the significant delay
> since it was originally posted to the mailing list. So far Jagan
> pointed out only one issue and he said he would continue looking into
> the patches but I did not receive any feedback for months.

Sorry that I'm in long vacations which is less possible in mailing.
As these changes are very crucial, I keep waiting the same.

I will be back on March, end - if still need an urgent sync-up on these changes
Tom or Simon please look at the same.

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Fri, Mar 6, 2015 at 1:43 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 4 March 2015 at 09:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Tom,
>>
>> On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini <trini@konsulko.com> wrote:
>>> On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
>>>> +Tom
>>>>
>>>> Hi Jagan,
>>>>
>>>> On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> > Hi Jagan,
>>>> >
>>>> > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >> Hi Jagan,
>>>> >>
>>>> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> >>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >>>> Hi Jagan,
>>>> >>>>
>>>> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> >>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >>>>>> Hi Jagan,
>>>> >>>>>>
>>>> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> >>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >>>>>>>> Hi Jagan,
>>>> >>>>>>>>
>>>> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >>>>>>>>> Hi Jagan,
>>>> >>>>>>>>>
>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> >>>>>>>>>> Hi Bin,
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >>>>>>>>>>> Hi Jagan,
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> >>>>>>>>>>>> Hi Bin,
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>> >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>> >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>> >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>> >>>>>>>>>>>>> given SECT_4K.
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Changes in v3:
>>>> >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Bin Meng (9):
>>>> >>>>>>>>>>>>>   sf: Update SST flash params
>>>> >>>>>>>>>>>>>   sf: Update Atmel flash params
>>>> >>>>>>>>>>>>>   sf: Update EON flash params
>>>> >>>>>>>>>>>>>   sf: Update GigaDevice flash params
>>>> >>>>>>>>>>>>>   sf: Update Macronix flash params
>>>> >>>>>>>>>>>>>   sf: Update Spansion flash params
>>>> >>>>>>>>>>>>>   sf: Update Micron flash params
>>>> >>>>>>>>>>>>>   sf: Update Winbond flash params
>>>> >>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>> >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>> >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>> >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>> >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>> >>>>>>>>>>> QUAD_IO_FAST.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>> >>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Let me know your inputs?
>>>> >>>>>>>>>
>>>> >>>>>>>>> I am fine, as long as this PR will not contains other commits which
>>>> >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>> >>>>>>>>> test these updates and if everything looks fine, apply these first and
>>>> >>>>>>>>> ask other commits to rebase on this series to introduce more flash
>>>> >>>>>>>>> support.
>>>> >>>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>> Do you have any additional comments about this patch series besides
>>>> >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>> >>>>>>>> the v4.
>>>> >>>>>>>
>>>> >>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>> >>>>>>> previous working and Linux mtd.
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>>> >>>>>> might not be 100% working as per datasheet some flash params currently
>>>> >>>>>> are apparently wrong.
>>>> >>>>>
>>>> >>>>> Yes - about testing.
>>>> >>>>>
>>>> >>>>
>>>> >>>> Ping? What about your test results about this patch series?
>>>> >>>
>>>> >>> Some were pending - Will comment, pls- wait.
>>>> >>>
>>>> >>> thanks!
>>>> >>> --
>>>> >>
>>>> >> I still don't see any additional comments. Looking at the history this
>>>> >> patch series has been sitting there for months. Would you please let
>>>> >> me know what you think about this series?
>>>> >>
>>>> >
>>>> > Could you respond this? I wonder if this series could be merged in
>>>> > before MW is closed.
>>>> >
>>>>
>>>> I feel that you did not work on this. Can you please respond with any comments?
>>>
>>> Indeed.  This looks like a fairly trivial sync-up, can you shoot me all
>>> of the patchwork links and I'll take a look?  Thanks!
>>>
>>> --
>>
>> Thanks for checking. Here you are:
>>
>> http://patchwork.ozlabs.org/patch/419633/
>> http://patchwork.ozlabs.org/patch/419634/
>> http://patchwork.ozlabs.org/patch/419635/
>> http://patchwork.ozlabs.org/patch/419636/
>> http://patchwork.ozlabs.org/patch/419637/
>> http://patchwork.ozlabs.org/patch/419638/
>> http://patchwork.ozlabs.org/patch/419639/
>> http://patchwork.ozlabs.org/patch/419640/
>> http://patchwork.ozlabs.org/patch/419641/
>>
>> They might not be applied cleanly now due to the significant delay
>> since it was originally posted to the mailing list. So far Jagan
>> pointed out only one issue and he said he would continue looking into
>> the patches but I did not receive any feedback for months.
>
> Sorry that I'm in long vacations which is less possible in mailing.
> As these changes are very crucial, I keep waiting the same.

What are you waiting for? Do you mean you have some sort of testing
out there in the background and you don't have complete test result
yet?

> I will be back on March, end - if still need an urgent sync-up on these changes
> Tom or Simon please look at the same.
>

OK, so this series will for sure miss the v2015.04 release (it already
missed the v2015.01 release before)

Regards,
Bin

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Jagan Teki]

On 6 March 2015 at 06:30, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Fri, Mar 6, 2015 at 1:43 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> On 4 March 2015 at 09:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Tom,
>>>
>>> On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini <trini@konsulko.com> wrote:
>>>> On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
>>>>> +Tom
>>>>>
>>>>> Hi Jagan,
>>>>>
>>>>> On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> > Hi Jagan,
>>>>> >
>>>>> > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >> Hi Jagan,
>>>>> >>
>>>>> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> >>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >>>> Hi Jagan,
>>>>> >>>>
>>>>> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> >>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >>>>>> Hi Jagan,
>>>>> >>>>>>
>>>>> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> >>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >>>>>>>> Hi Jagan,
>>>>> >>>>>>>>
>>>>> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >>>>>>>>> Hi Jagan,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> >>>>>>>>>> Hi Bin,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >>>>>>>>>>> Hi Jagan,
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> >>>>>>>>>>>> Hi Bin,
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>> >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>> >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>> >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>> >>>>>>>>>>>>> given SECT_4K.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Changes in v3:
>>>>> >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Bin Meng (9):
>>>>> >>>>>>>>>>>>>   sf: Update SST flash params
>>>>> >>>>>>>>>>>>>   sf: Update Atmel flash params
>>>>> >>>>>>>>>>>>>   sf: Update EON flash params
>>>>> >>>>>>>>>>>>>   sf: Update GigaDevice flash params
>>>>> >>>>>>>>>>>>>   sf: Update Macronix flash params
>>>>> >>>>>>>>>>>>>   sf: Update Spansion flash params
>>>>> >>>>>>>>>>>>>   sf: Update Micron flash params
>>>>> >>>>>>>>>>>>>   sf: Update Winbond flash params
>>>>> >>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>> >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>> >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>> >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>> >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>> >>>>>>>>>>> QUAD_IO_FAST.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>> >>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Let me know your inputs?
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I am fine, as long as this PR will not contains other commits which
>>>>> >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>> >>>>>>>>> test these updates and if everything looks fine, apply these first and
>>>>> >>>>>>>>> ask other commits to rebase on this series to introduce more flash
>>>>> >>>>>>>>> support.
>>>>> >>>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> Do you have any additional comments about this patch series besides
>>>>> >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>>> >>>>>>>> the v4.
>>>>> >>>>>>>
>>>>> >>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>>> >>>>>>> previous working and Linux mtd.
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>>>> >>>>>> might not be 100% working as per datasheet some flash params currently
>>>>> >>>>>> are apparently wrong.
>>>>> >>>>>
>>>>> >>>>> Yes - about testing.
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>> Ping? What about your test results about this patch series?
>>>>> >>>
>>>>> >>> Some were pending - Will comment, pls- wait.
>>>>> >>>
>>>>> >>> thanks!
>>>>> >>> --
>>>>> >>
>>>>> >> I still don't see any additional comments. Looking at the history this
>>>>> >> patch series has been sitting there for months. Would you please let
>>>>> >> me know what you think about this series?
>>>>> >>
>>>>> >
>>>>> > Could you respond this? I wonder if this series could be merged in
>>>>> > before MW is closed.
>>>>> >
>>>>>
>>>>> I feel that you did not work on this. Can you please respond with any comments?
>>>>
>>>> Indeed.  This looks like a fairly trivial sync-up, can you shoot me all
>>>> of the patchwork links and I'll take a look?  Thanks!
>>>>
>>>> --
>>>
>>> Thanks for checking. Here you are:
>>>
>>> http://patchwork.ozlabs.org/patch/419633/
>>> http://patchwork.ozlabs.org/patch/419634/
>>> http://patchwork.ozlabs.org/patch/419635/
>>> http://patchwork.ozlabs.org/patch/419636/
>>> http://patchwork.ozlabs.org/patch/419637/
>>> http://patchwork.ozlabs.org/patch/419638/
>>> http://patchwork.ozlabs.org/patch/419639/
>>> http://patchwork.ozlabs.org/patch/419640/
>>> http://patchwork.ozlabs.org/patch/419641/
>>>
>>> They might not be applied cleanly now due to the significant delay
>>> since it was originally posted to the mailing list. So far Jagan
>>> pointed out only one issue and he said he would continue looking into
>>> the patches but I did not receive any feedback for months.
>>
>> Sorry that I'm in long vacations which is less possible in mailing.
>> As these changes are very crucial, I keep waiting the same.
>
> What are you waiting for? Do you mean you have some sort of testing
> out there in the background and you don't have complete test result
> yet?

I mean I did some testing, and moved my wedding vacations(currently IN)
I will look at it after 25 March, if still you feel these are urgent.

Please test it all possible flashes (atleast once) then may be Tom/Simon will
look those (if possible I will comment on testings).

I do have some flashes on my hand to verify but currently I'm busy
with my vacations,
once I switch back to work may be will look at and finalize the same.

>
>> I will be back on March, end - if still need an urgent sync-up on these changes
>> Tom or Simon please look at the same.
>>
>
> OK, so this series will for sure miss the v2015.04 release (it already
> missed the v2015.01 release before)

thanks!
-- 
Jagan.

[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

[Bin Meng]

Hi Jagan,

On Fri, Mar 6, 2015 at 6:21 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 6 March 2015 at 06:30, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Fri, Mar 6, 2015 at 1:43 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> On 4 March 2015 at 09:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Tom,
>>>>
>>>> On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini <trini@konsulko.com> wrote:
>>>>> On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
>>>>>> +Tom
>>>>>>
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> > Hi Jagan,
>>>>>> >
>>>>>> > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >> Hi Jagan,
>>>>>> >>
>>>>>> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> >>> On 12 January 2015 at 09:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >>>> Hi Jagan,
>>>>>> >>>>
>>>>>> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> >>>>> On 17 December 2014 at 13:32, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >>>>>> Hi Jagan,
>>>>>> >>>>>>
>>>>>> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> >>>>>>> On 15 December 2014 at 19:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >>>>>>>> Hi Jagan,
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >>>>>>>>> Hi Jagan,
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> >>>>>>>>>> Hi Bin,
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >>>>>>>>>>> Hi Jagan,
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> >>>>>>>>>>>> Hi Bin,
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet
>>>>>> >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as
>>>>>> >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure
>>>>>> >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
>>>>>> >>>>>>>>>>>>> given SECT_4K.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Changes in v3:
>>>>>> >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Bin Meng (9):
>>>>>> >>>>>>>>>>>>>   sf: Update SST flash params
>>>>>> >>>>>>>>>>>>>   sf: Update Atmel flash params
>>>>>> >>>>>>>>>>>>>   sf: Update EON flash params
>>>>>> >>>>>>>>>>>>>   sf: Update GigaDevice flash params
>>>>>> >>>>>>>>>>>>>   sf: Update Macronix flash params
>>>>>> >>>>>>>>>>>>>   sf: Update Spansion flash params
>>>>>> >>>>>>>>>>>>>   sf: Update Micron flash params
>>>>>> >>>>>>>>>>>>>   sf: Update Winbond flash params
>>>>>> >>>>>>>>>>>>>   sf: Give proper spacing between flash table params
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Thanks for the updates - have you verified these changes?
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based
>>>>>> >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series
>>>>>> >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed
>>>>>> >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
>>>>>> >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting
>>>>>> >>>>>>>>>>> QUAD_IO_FAST.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR.
>>>>>> >>>>>>>>>> Will test all the rest (except these) and send the PR soon.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Let me know your inputs?
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> I am fine, as long as this PR will not contains other commits which
>>>>>> >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can
>>>>>> >>>>>>>>> test these updates and if everything looks fine, apply these first and
>>>>>> >>>>>>>>> ask other commits to rebase on this series to introduce more flash
>>>>>> >>>>>>>>> support.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Do you have any additional comments about this patch series besides
>>>>>> >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
>>>>>> >>>>>>>> the v4.
>>>>>> >>>>>>>
>>>>>> >>>>>>> I'm thinking about the other flashes too,  since these params were taken from
>>>>>> >>>>>>> previous working and Linux mtd.
>>>>>> >>>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they
>>>>>> >>>>>> might not be 100% working as per datasheet some flash params currently
>>>>>> >>>>>> are apparently wrong.
>>>>>> >>>>>
>>>>>> >>>>> Yes - about testing.
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>> Ping? What about your test results about this patch series?
>>>>>> >>>
>>>>>> >>> Some were pending - Will comment, pls- wait.
>>>>>> >>>
>>>>>> >>> thanks!
>>>>>> >>> --
>>>>>> >>
>>>>>> >> I still don't see any additional comments. Looking at the history this
>>>>>> >> patch series has been sitting there for months. Would you please let
>>>>>> >> me know what you think about this series?
>>>>>> >>
>>>>>> >
>>>>>> > Could you respond this? I wonder if this series could be merged in
>>>>>> > before MW is closed.
>>>>>> >
>>>>>>
>>>>>> I feel that you did not work on this. Can you please respond with any comments?
>>>>>
>>>>> Indeed.  This looks like a fairly trivial sync-up, can you shoot me all
>>>>> of the patchwork links and I'll take a look?  Thanks!
>>>>>
>>>>> --
>>>>
>>>> Thanks for checking. Here you are:
>>>>
>>>> http://patchwork.ozlabs.org/patch/419633/
>>>> http://patchwork.ozlabs.org/patch/419634/
>>>> http://patchwork.ozlabs.org/patch/419635/
>>>> http://patchwork.ozlabs.org/patch/419636/
>>>> http://patchwork.ozlabs.org/patch/419637/
>>>> http://patchwork.ozlabs.org/patch/419638/
>>>> http://patchwork.ozlabs.org/patch/419639/
>>>> http://patchwork.ozlabs.org/patch/419640/
>>>> http://patchwork.ozlabs.org/patch/419641/
>>>>
>>>> They might not be applied cleanly now due to the significant delay
>>>> since it was originally posted to the mailing list. So far Jagan
>>>> pointed out only one issue and he said he would continue looking into
>>>> the patches but I did not receive any feedback for months.
>>>
>>> Sorry that I'm in long vacations which is less possible in mailing.
>>> As these changes are very crucial, I keep waiting the same.
>>
>> What are you waiting for? Do you mean you have some sort of testing
>> out there in the background and you don't have complete test result
>> yet?
>
> I mean I did some testing, and moved my wedding vacations(currently IN)
> I will look at it after 25 March, if still you feel these are urgent.
>
> Please test it all possible flashes (atleast once) then may be Tom/Simon will
> look those (if possible I will comment on testings).
>
> I do have some flashes on my hand to verify but currently I'm busy
> with my vacations,
> once I switch back to work may be will look at and finalize the same.
>
>>
>>> I will be back on March, end - if still need an urgent sync-up on these changes
>>> Tom or Simon please look at the same.
>>>
>>
>> OK, so this series will for sure miss the v2015.04 release (it already
>> missed the v2015.01 release before)
>

I see you are back. Any further comments before I rebase and give another spin?

Regards,
Bin