[PATCH v2] mtd: spi-nor: Add support for N25Q256A13 as N25Q256A

[Cyrille Pitchen]

Le 04/02/2017 à 22:32, Marek Vasut a écrit :
> On 01/31/2017 11:18 AM, Cyrille Pitchen wrote:
>> Le 30/01/2017 à 21:38, Marek Vasut a écrit :
>>> On 01/30/2017 02:29 PM, Cyrille Pitchen wrote:
>>>> Hi Nobuhiro,
>>>>
>>>> Le 27/01/2017 à 02:51, Nobuhiro Iwamatsu a écrit :
>>>>> Add new Micron N25Q256A (N25Q256A13) 256Mbit NOR Flash in the list
>>>>> of supported devices. This chip has the same structure as the N25Q256A
>>>>> but ID is different. And this fixes N25Q256A to N25Q256 to fit chip
>>>>> name to other n25q chip names.
>>>>>
>>>>> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.kw at hitachi.com>
>>>>> CC: Jagan Teki <jagan at openedev.com>
>>>>> CC: Marek Vasut <marek.vasut at gmail.com>
>>>>> ---
>>>>>  drivers/mtd/spi-nor/spi-nor.c | 3 ++-
>>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>>>> index da7cd69d4857..a2a6922e356f 100644
>>>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>>>> @@ -887,7 +887,8 @@ static const struct flash_info spi_nor_ids[] = {
>>>>>  	{ "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>>  	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>>  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>> -	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>> +	{ "n25q256",     INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>> +	{ "n25q256a",    INFO(0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>
>>>> This patch changes the association "n25q256a" <-> 20 ba 19: "n25q256a"
>>>> would be now associated to 20 bb 19.
>>>> However some device trees use the "micron,n25q256a" as compatible string:
>>>> - arch/arm/boot/dts/imx6sx-sbd.dts: compatible = "micron,n25q256a",
>>>> "jedec,spi-nor";
>>>> - arch/arm/boot/dts/socfpga_arria5_socdk.dts: compatible = "n25q256a";
>>>> - arch/arm/boot/dts/socfpga_cyclone5_socrates.dts: compatible = "n25q256a";
>>>> - arch/arm/boot/dts/imx6ul-14x14-evk.dts: compatible = "micron,n25q256a";
>>>>
>>>> If the actual JEDEC ID read from the Micron SPI memory of one of these
>>>> boards is 20 ba 19 and if you now associate the string "n25q256a" to the
>>>> different JEDEC ID 20 bb 19, then spi_nor_scan() is likely to display the
>>>> warning message during the boot:
>>>>
>>>> dev_warn(dev, "found %s, expected %s\n", jinfo->name, info->name);
>>>>
>>>>
>>>> Displaying such a warning during the boot process would be an unwanted side
>>>> effect of this patch and users may complain or ask why such warning is now
>>>> displayed in the boot log.
>>>>
>>>> You may create a new entry for the 20 bb 19 JEDEC ID but I don't think it
>>>> is totally safe to remove the old n25q256a entry.
>>>
>>> If the old DTs were lazy and are now broken, then I think the warning is
>>> justified ?
>>>
>>
>> I'm reading a Micron datasheet for n25q256*:
>> 1 - it states that the JEDEC ID is 20 BA 19.
>> 2 - it explains the part number encoding
>>
>> Device Type    N25Q: Serial NOR Flash Memory, Multiple Input/Output
>>                      (Single, Dual, Quad I/O, XIP)
>> Density        256: 256Mb
>> Technology     A: 65nm (this is the only value provided by the datasheet)
>> ...
>>
>> So this datasheet applies to Micron n25q256a memory and its JEDEC ID is 20
>> BA 19. Hence the current "n25q256a" entry in the spi_nor_ids[] array and
>> the DTs using this string for the compatible value are all correct and
>> should not be changed.
>>
>> Then, I'm sure Nobuhiro is right too when he claims that the JEDEC ID of
>> his Micron n25q256a sample is 20 BB 19 (and not 20 BA 19). This just means
>> that Micron has produced different samples of n25q256a with different JEDEC
>> ID. However this is nothing new with Micron memories.
> 
> Isn't the BA a 3V3 part and the BB a 1V8 part ? I recall something like
> that.
>

I've just looked at 2 Micron's datasheets, the first one for 3V3 and the
other for some 1V8 memory and I guess you're right.

About the part numbers, voltage and JEDEC ID:
N25Q*Ax1 -> 1V8, 20 BB __
N25Q*Ax3 -> 3V3, 20 BA __

>> We should keep the current entry as is since it is perfectly correct but we
>> can add another entry with a different name for the JEDEC ID 20 BB 19.
>>
>> If we look at the entries for the other Micron memories, we see for each
>> memory density there are 2 different ID: 20 BA xx and 20 BB xx.
>>
>> Besides the "rule" 20 BA xx -> n25q__ , 20 BB xx -> n25q__a is not always
>> respected and is not relevant to the actual hardware. I guess this is just
>> a legacy naming scheme to provide 2 different names, one for the 20 BB xx
>> entry and the other for the 20 BA xx entry but from a hardware point of
>> view, I think this naming scheme doesn't make sense.
> 
> The micron ID/naming scheme does not make sense, it's complete chaos,
> that is no news.
> 
>> So don't worry about the accuracy of the name you will choose to add a new
>> entry. For instance let's take "n25q256" since it is available.
> 
> Or we can add "n25q256ax3" ?
> 

Indeed, it sounds like a good idea, so I vote for it :)

Just a small comment: the JEDEC ID 20 BA 19 is already associated to the
string "n25q256a" and we have to keep this string for DT backward
compatibility purpose. However the JEDEC ID 20 BB 19 is not handled yet so
we can associate it to the string "n25q256ax1".

So if we all agree, let the "n25q256a" entry as is and just add a new
"n25q256ax1" entry for the JEDEC ID 20 BB 19.

In the future, for new Micron memories we could use the patterns "n25q*ax1"
for 1V8 and "n25q*ax3" for 3V3 memories.

Best regards,

Cyrille