[PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

[PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

[Sascha Hauer]

The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
Add support for them to the spi-nor driver.

The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
six times the continuation code 7f followed by c2 for Ramtron.
Unfortunately the chip sends the Device ID in reversed order, so the
continuation code is not at the beginning, but instead at the end. Even
more unfortunate is that when reading further the chip sends more 7f
codes which means we are not even able to count the continuation codes.
We can only hope that this reversed Device ID will never match any other
devices ID.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

Changes since v2:
- Add explanation of the reversed order of the Device ID to the commit message
Changes since v1:
- Instead of specifying 1024 sectors with a sector size of 512 specify
  512 * 1024 sectos with a sector size of 1. The device has no idea of
  sectors and is not erasable, so a sector size of 1 seems to better
  reflect reality.

 drivers/mtd/spi-nor/spansion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 6756202ace4b..3e8ac602e36b 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -70,6 +70,7 @@ static const struct flash_info spansion_parts[] = {
 	{ "s25fl256l",  INFO(0x016019,      0,  64 * 1024, 512,
 			     SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
 			     SPI_NOR_4B_OPCODES) },
+	{ "cy15x104q",  INFO6(0x042cc2, 0x7f7f7f, 512 * 1024, 1, SPI_NOR_NO_ERASE) },
 };
 
 static void spansion_post_sfdp_fixups(struct spi_nor *nor)
-- 
2.26.1


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

Re: [PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

[Sascha Hauer]

On Fri, Apr 24, 2020 at 08:56:26AM +0200, Sascha Hauer wrote:
> The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
> Add support for them to the spi-nor driver.
> 
> The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
> six times the continuation code 7f followed by c2 for Ramtron.
> Unfortunately the chip sends the Device ID in reversed order, so the
> continuation code is not at the beginning, but instead at the end. Even
> more unfortunate is that when reading further the chip sends more 7f
> codes which means we are not even able to count the continuation codes.
> We can only hope that this reversed Device ID will never match any other
> devices ID.

Any idea how to continue here? The patch is wrong, I know that, but I
have no idea what to do instead. Should we just skip support for this
chip?

Sascha

> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> 
> Changes since v2:
> - Add explanation of the reversed order of the Device ID to the commit message
> Changes since v1:
> - Instead of specifying 1024 sectors with a sector size of 512 specify
>   512 * 1024 sectos with a sector size of 1. The device has no idea of
>   sectors and is not erasable, so a sector size of 1 seems to better
>   reflect reality.
> 
>  drivers/mtd/spi-nor/spansion.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index 6756202ace4b..3e8ac602e36b 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -70,6 +70,7 @@ static const struct flash_info spansion_parts[] = {
>  	{ "s25fl256l",  INFO(0x016019,      0,  64 * 1024, 512,
>  			     SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
>  			     SPI_NOR_4B_OPCODES) },
> +	{ "cy15x104q",  INFO6(0x042cc2, 0x7f7f7f, 512 * 1024, 1, SPI_NOR_NO_ERASE) },
>  };
>  
>  static void spansion_post_sfdp_fixups(struct spi_nor *nor)
> -- 
> 2.26.1
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

Re: [PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

[Tudor.Ambarus]

On Friday, April 24, 2020 9:56:26 AM EEST Sascha Hauer wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
> Add support for them to the spi-nor driver.
> 
> The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
> six times the continuation code 7f followed by c2 for Ramtron.
> Unfortunately the chip sends the Device ID in reversed order, so the
> continuation code is not at the beginning, but instead at the end. Even
> more unfortunate is that when reading further the chip sends more 7f
> codes which means we are not even able to count the continuation codes.
> We can only hope that this reversed Device ID will never match any other
> devices ID.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Collisions are improbable as of now, the solution from above is good
enough. In case of future collisions one can introduce an INFO9 macro,
with the downsize that struct flash_info would grow and we have lots of
flashes. A more elegant solution would be to introduce dedicated
flash ID tables for each bank in JESP106BA.

Amended commit description with the above text and applied. Thanks.


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

Re: [PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

[Tim Harvey]

On Thu, May 28, 2020 at 1:13 AM <Tudor.Ambarus@microchip.com> wrote:
>
> On Friday, April 24, 2020 9:56:26 AM EEST Sascha Hauer wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
> > Add support for them to the spi-nor driver.
> >
> > The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
> > six times the continuation code 7f followed by c2 for Ramtron.
> > Unfortunately the chip sends the Device ID in reversed order, so the
> > continuation code is not at the beginning, but instead at the end. Even
> > more unfortunate is that when reading further the chip sends more 7f
> > codes which means we are not even able to count the continuation codes.
> > We can only hope that this reversed Device ID will never match any other
> > devices ID.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Collisions are improbable as of now, the solution from above is good
> enough. In case of future collisions one can introduce an INFO9 macro,
> with the downsize that struct flash_info would grow and we have lots of
> flashes. A more elegant solution would be to introduce dedicated
> flash ID tables for each bank in JESP106BA.
>
> Amended commit description with the above text and applied. Thanks.
>

Greetings,

I've got a board with a  CY15B104Q-LHXI on it and I found that it's id
reads as  7f 7f 7f 7f 7f 7f c2 26 08 so it fails the match added above
in a2644d5f36: mtd: spi-nor: Add support for Cypress cy15x104q

I also found a reference in
https://community.cypress.com/docs/DOC-14647 that states "that newer
1.8 V devices have the 9 device ID bytes coming out in the other order
which requires a minor change in the ID entry" which would explain the
situation you encountered.

Adding '{ "cy15x104q",  INFO(0x7f7f7f, 0, 512 * 1024, 1,
SPI_NOR_NO_ERASE) },' works for the part I have.

Would it be wrong to add additional parts with the same name and
different id's? It seems to me duplicate names would break
spi_nor_scan when passed a name but work fine for scanning by id. I
also think that '{ "cy15x104q",  INFO6(0x042cc2, 0x7f7f7f, 512 * 1024,
1, SPI_NOR_NO_ERASE) },' is way too specific for 'cy15x104q' because
it is won't match any of the other identified parts:

CY15B104Q-PZXI     7F7F7F7F7F7FC22C03 51-85075 8-pin PDIP Industrial
CY15B104QN-50SXA   7F7F7F7F7F7FC22C40 001-85261 8-pin SOIC (EIAJ) Automotive
CY15V104QN-50SXI   7F7F7F7F7F7FC22C04 002-18131 8-pin GQFN Industrial
CY15B104QN-20LPXC  7F7F7F7F7F7FC22CA1 002-18131 8-pin GQFN Commercial
CY15B104QN-20LPXI  7F7F7F7F7F7FC22C01 002-18131 8-pin GQFN Industrial
CY15V104QN-20LPXC  7F7F7F7F7F7FC22CA5 002-18131 8-pin GQFN Commercial
CY15V104QN-20LPXI  7F7F7F7F7F7FC22C05 002-18131 8-pin GQFN Industrial
CY15B104QN-50LPXI  7F7F7F7F7F7FC22C00 002-18131 8-pin GQFN Industrial

Best Regards,

Tim

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

Re: [PATCH v3] mtd: spi-nor: Add support for Cypress cy15x104q

[Vignesh Raghavendra]

Hi,

On 11/6/20 12:24 AM, Tim Harvey wrote:
> On Thu, May 28, 2020 at 1:13 AM <Tudor.Ambarus@microchip.com> wrote:
>>
>> On Friday, April 24, 2020 9:56:26 AM EEST Sascha Hauer wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>>> content is safe
>>>
>>> The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
>>> Add support for them to the spi-nor driver.
>>>
>>> The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
>>> six times the continuation code 7f followed by c2 for Ramtron.
>>> Unfortunately the chip sends the Device ID in reversed order, so the
>>> continuation code is not at the beginning, but instead at the end. Even
>>> more unfortunate is that when reading further the chip sends more 7f
>>> codes which means we are not even able to count the continuation codes.
>>> We can only hope that this reversed Device ID will never match any other
>>> devices ID.
>>>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> Collisions are improbable as of now, the solution from above is good
>> enough. In case of future collisions one can introduce an INFO9 macro,
>> with the downsize that struct flash_info would grow and we have lots of
>> flashes. A more elegant solution would be to introduce dedicated
>> flash ID tables for each bank in JESP106BA.
>>
>> Amended commit description with the above text and applied. Thanks.
>>
> 
> Greetings,
> 
> I've got a board with a  CY15B104Q-LHXI on it and I found that it's id
> reads as  7f 7f 7f 7f 7f 7f c2 26 08 so it fails the match added above
> in a2644d5f36: mtd: spi-nor: Add support for Cypress cy15x104q
> 
> I also found a reference in
> https://community.cypress.com/docs/DOC-14647 that states "that newer
> 1.8 V devices have the 9 device ID bytes coming out in the other order
> which requires a minor change in the ID entry" which would explain the
> situation you encountered.
> 

So, Cypress seems to have fixed ID table to follow JEP106BA standard.

> Adding '{ "cy15x104q",  INFO(0x7f7f7f, 0, 512 * 1024, 1,
> SPI_NOR_NO_ERASE) },' works for the part I have.
> 

NACK, 0x7F is continuation code and not actual flash ID code. See JEDEC
standard JEP106BA for more details. In short, driver should just keep
looking at next byte in the sequence for manf ID when it reads a value
of 0x7F.

You will have to extend spi_nor_read_id() function to
take care of continuation code and read more bytes in order to get the
actual Manuf/device ID. And then walk through
spi_nor_manufacturer->parts table looking for the corresponding entry.

Would need to store bank number (implied by number of continuation
codes) as part of flash_info struct for cross reference during lookup


> Would it be wrong to add additional parts with the same name and
> different id's? It seems to me duplicate names would break
> spi_nor_scan when passed a name but work fine for scanning by id. 


Ideally yes, but in case of cy15x104q there are two revisions of flash,
one with correct ID code and other with ID code reversed and
unfortunately, would need to make an exception here.

> I also think that '{ "cy15x104q",  INFO6(0x042cc2, 0x7f7f7f, 512 * 1024,
> 1, SPI_NOR_NO_ERASE) },' is way too specific for 'cy15x104q' because
> it is won't match any of the other identified parts:
> 
> CY15B104Q-PZXI     7F7F7F7F7F7FC22C03 51-85075 8-pin PDIP Industrial
> CY15B104QN-50SXA   7F7F7F7F7F7FC22C40 001-85261 8-pin SOIC (EIAJ) Automotive
> CY15V104QN-50SXI   7F7F7F7F7F7FC22C04 002-18131 8-pin GQFN Industrial
> CY15B104QN-20LPXC  7F7F7F7F7F7FC22CA1 002-18131 8-pin GQFN Commercial
> CY15B104QN-20LPXI  7F7F7F7F7F7FC22C01 002-18131 8-pin GQFN Industrial
> CY15V104QN-20LPXC  7F7F7F7F7F7FC22CA5 002-18131 8-pin GQFN Commercial
> CY15V104QN-20LPXI  7F7F7F7F7F7FC22C05 002-18131 8-pin GQFN Industrial
> CY15B104QN-50LPXI  7F7F7F7F7F7FC22C00 002-18131 8-pin GQFN Industrial
> 

Indeed.. A patch fixing the same would be very much appreciated. Thanks!

Regards
Vignesh

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