Linux-mtd Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable
@ 2019-07-26 21:08 Roman Yeryomin
  2019-07-28  5:48 ` Tudor.Ambarus
  2019-07-28  8:47 ` Sergei Shtylyov
  0 siblings, 2 replies; 5+ messages in thread
From: Roman Yeryomin @ 2019-07-26 21:08 UTC (permalink / raw)
  To: linux-mtd; +Cc: Marek Vasut

According to datasheets all GD devices are capable of quad mode, which
is enabled via Status Register-2, bit 1 (S9). This corresponds to
Spansion SR/CR operations. Unfortunately only gd25q256 datasheet is
clear about Quad Enable Requirements (QER), others have no such
information in datasheets.
So define quad_enable for all GD devices to be sure.
Also gd25q256 is an exception. There are two versions: C and D.
First one uses S6 bit (like described in e27072851bf7d) but the latter
uses S9 bit like others. To add support for D this should be handled
differently, so, to retain compatibility, leave gd25q256 quad_enable
callback intact.

Signed-off-by: Roman Yeryomin <roman@advem.lv>
---
 drivers/mtd/spi-nor/spi-nor.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6e13bbd1aaa5..d598efb57f20 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1764,31 +1764,37 @@ static const struct flash_info spi_nor_ids[] = {
 		"gd25q16", INFO(0xc84015, 0, 64 * 1024,  32,
 			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+			.quad_enable = spansion_read_cr_quad_enable,
 	},
 	{
 		"gd25q32", INFO(0xc84016, 0, 64 * 1024,  64,
 			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+			.quad_enable = spansion_read_cr_quad_enable,
 	},
 	{
 		"gd25lq32", INFO(0xc86016, 0, 64 * 1024, 64,
 			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+			.quad_enable = spansion_read_cr_quad_enable,
 	},
 	{
 		"gd25q64", INFO(0xc84017, 0, 64 * 1024, 128,
 			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+			.quad_enable = spansion_read_cr_quad_enable,
 	},
 	{
 		"gd25lq64c", INFO(0xc86017, 0, 64 * 1024, 128,
 			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+			.quad_enable = spansion_read_cr_quad_enable,
 	},
 	{
 		"gd25q128", INFO(0xc84018, 0, 64 * 1024, 256,
 			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+			.quad_enable = spansion_read_cr_quad_enable,
 	},
 	{
 		"gd25q256", INFO(0xc84019, 0, 64 * 1024, 512,
-- 
2.20.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable
  2019-07-26 21:08 [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable Roman Yeryomin
@ 2019-07-28  5:48 ` Tudor.Ambarus
  2019-07-28  6:21   ` Tudor.Ambarus
  2019-07-28  8:47 ` Sergei Shtylyov
  1 sibling, 1 reply; 5+ messages in thread
From: Tudor.Ambarus @ 2019-07-28  5:48 UTC (permalink / raw)
  To: roman, linux-mtd; +Cc: marek.vasut

Hi, Roman,

On 07/27/2019 12:08 AM, Roman Yeryomin wrote:
> External E-Mail
> 
> 
> According to datasheets all GD devices are capable of quad mode, which

Does any of these flashes implement the Basic Flash Parameter Table? Can't we
determine the QE Requirements by parsing BFPT?

> is enabled via Status Register-2, bit 1 (S9). This corresponds to
> Spansion SR/CR operations. Unfortunately only gd25q256 datasheet is
> clear about Quad Enable Requirements (QER), others have no such
> information in datasheets.
> So define quad_enable for all GD devices to be sure.

Which flash did you test?

Cheers,
ta

> Also gd25q256 is an exception. There are two versions: C and D.
> First one uses S6 bit (like described in e27072851bf7d) but the latter
> uses S9 bit like others. To add support for D this should be handled
> differently, so, to retain compatibility, leave gd25q256 quad_enable
> callback intact.
> 
> Signed-off-by: Roman Yeryomin <roman@advem.lv>
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable
  2019-07-28  5:48 ` Tudor.Ambarus
@ 2019-07-28  6:21   ` Tudor.Ambarus
  2019-08-07 20:10     ` Roman Yeryomin
  0 siblings, 1 reply; 5+ messages in thread
From: Tudor.Ambarus @ 2019-07-28  6:21 UTC (permalink / raw)
  To: roman, linux-mtd; +Cc: marek.vasut



On 07/28/2019 08:48 AM, Tudor.Ambarus@microchip.com wrote:
> External E-Mail
> 
> 
> Hi, Roman,
> 
> On 07/27/2019 12:08 AM, Roman Yeryomin wrote:
>> External E-Mail
>>
>>
>> According to datasheets all GD devices are capable of quad mode, which
> 
> Does any of these flashes implement the Basic Flash Parameter Table? Can't we
> determine the QE Requirements by parsing BFPT?

GD25Q256D can retrieve the QE requirements from BFPT dword 15. No need to set
the quad_enable pointer when declaring this flash, it will be overwritten when
parsing BFPT.

GD25Q256C implements JESD216A - just the first 9 dwords of BFPT, and it can't
determine the QE Requirements by parsing the BFPT. That's way we explicitly set
the quad_enable function pointer at flash declaration.

> 
>> is enabled via Status Register-2, bit 1 (S9). This corresponds to
>> Spansion SR/CR operations. Unfortunately only gd25q256 datasheet is
>> clear about Quad Enable Requirements (QER), others have no such
>> information in datasheets.
>> So define quad_enable for all GD devices to be sure.
> 
> Which flash did you test?

What you can do is to check which of these flashes can't determine the QE
requirements by parsing BFPT and set the quad_enable just for those who can't.
And it would be preferable to do this just for the flashes that you can test.

> 
> Cheers,
> ta
> 
>> Also gd25q256 is an exception. There are two versions: C and D.
>> First one uses S6 bit (like described in e27072851bf7d) but the latter
>> uses S9 bit like others. To add support for D this should be handled
>> differently, so, to retain compatibility, leave gd25q256 quad_enable
>> callback intact.
>>
>> Signed-off-by: Roman Yeryomin <roman@advem.lv>
>> ---
>>  drivers/mtd/spi-nor/spi-nor.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable
  2019-07-26 21:08 [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable Roman Yeryomin
  2019-07-28  5:48 ` Tudor.Ambarus
@ 2019-07-28  8:47 ` Sergei Shtylyov
  1 sibling, 0 replies; 5+ messages in thread
From: Sergei Shtylyov @ 2019-07-28  8:47 UTC (permalink / raw)
  To: Roman Yeryomin, linux-mtd; +Cc: Marek Vasut

Hello!

On 27.07.2019 0:08, Roman Yeryomin wrote:

> According to datasheets all GD devices are capable of quad mode, which
> is enabled via Status Register-2, bit 1 (S9). This corresponds to
> Spansion SR/CR operations. Unfortunately only gd25q256 datasheet is
> clear about Quad Enable Requirements (QER), others have no such
> information in datasheets.
> So define quad_enable for all GD devices to be sure.
> Also gd25q256 is an exception. There are two versions: C and D.
> First one uses S6 bit (like described in e27072851bf7d) but the latter

     When citing a commit ID, you need to also specify its summary enclosed in
("").

> uses S9 bit like others. To add support for D this should be handled
> differently, so, to retain compatibility, leave gd25q256 quad_enable
> callback intact.
> 
> Signed-off-by: Roman Yeryomin <roman@advem.lv>
[...]

MBR, Sergei

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable
  2019-07-28  6:21   ` Tudor.Ambarus
@ 2019-08-07 20:10     ` Roman Yeryomin
  0 siblings, 0 replies; 5+ messages in thread
From: Roman Yeryomin @ 2019-08-07 20:10 UTC (permalink / raw)
  To: Tudor.Ambarus; +Cc: marek.vasut, linux-mtd

On 2019-07-28 09:21, Tudor.Ambarus@microchip.com wrote:
> On 07/28/2019 08:48 AM, Tudor.Ambarus@microchip.com wrote:
>> External E-Mail
>> 
>> 
>> Hi, Roman,
>> 
>> On 07/27/2019 12:08 AM, Roman Yeryomin wrote:
>>> External E-Mail
>>> 
>>> 
>>> According to datasheets all GD devices are capable of quad mode, 
>>> which
>> 
>> Does any of these flashes implement the Basic Flash Parameter Table? 
>> Can't we
>> determine the QE Requirements by parsing BFPT?
> 
> GD25Q256D can retrieve the QE requirements from BFPT dword 15. No need 
> to set
> the quad_enable pointer when declaring this flash, it will be 
> overwritten when
> parsing BFPT.

ok, I see, thanks for the pointer, didn't see that

> GD25Q256C implements JESD216A - just the first 9 dwords of BFPT, and it 
> can't
> determine the QE Requirements by parsing the BFPT. That's way we 
> explicitly set
> the quad_enable function pointer at flash declaration.
> 
>> 
>>> is enabled via Status Register-2, bit 1 (S9). This corresponds to
>>> Spansion SR/CR operations. Unfortunately only gd25q256 datasheet is
>>> clear about Quad Enable Requirements (QER), others have no such
>>> information in datasheets.
>>> So define quad_enable for all GD devices to be sure.
>> 
>> Which flash did you test?
> 
> What you can do is to check which of these flashes can't determine the 
> QE
> requirements by parsing BFPT and set the quad_enable just for those who 
> can't.
> And it would be preferable to do this just for the flashes that you can 
> test.

Unfortunately I don't have the devices. I only studied the datasheets.
Though I do have gd25q512 (the second patch) somewhere. I used it on one 
of embedded board prototypes.
I will try to find it and test the BFPT parsing.

>> 
>> Cheers,
>> ta
>> 
>>> Also gd25q256 is an exception. There are two versions: C and D.
>>> First one uses S6 bit (like described in e27072851bf7d) but the 
>>> latter
>>> uses S9 bit like others. To add support for D this should be handled
>>> differently, so, to retain compatibility, leave gd25q256 quad_enable
>>> callback intact.
>>> 
>>> Signed-off-by: Roman Yeryomin <roman@advem.lv>
>>> ---
>>>  drivers/mtd/spi-nor/spi-nor.c | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>> 
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>> 
>> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-26 21:08 [PATCH 1/2] mtd: spi-nor: fix GigaDevice quad_enable Roman Yeryomin
2019-07-28  5:48 ` Tudor.Ambarus
2019-07-28  6:21   ` Tudor.Ambarus
2019-08-07 20:10     ` Roman Yeryomin
2019-07-28  8:47 ` Sergei Shtylyov

Linux-mtd Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mtd/0 linux-mtd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mtd linux-mtd/ https://lore.kernel.org/linux-mtd \
		linux-mtd@lists.infradead.org linux-mtd@archiver.kernel.org
	public-inbox-index linux-mtd


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-mtd


AGPL code for this site: git clone https://public-inbox.org/ public-inbox