public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Takahiro Kuwano <tkuw584924@gmail.com>
To: Michael Walle <michael@walle.cc>
Cc: linux-mtd@lists.infradead.org, tudor.ambarus@linaro.org,
	pratyush@kernel.org, miquel.raynal@bootlin.com, richard@nod.at,
	vigneshr@ti.com, Bacem.Daassi@infineon.com,
	Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Subject: Re: [PATCH] mtd: spi-nor: spansion: Add support for Infineon S25FS256T
Date: Tue, 20 Dec 2022 17:31:08 +0900	[thread overview]
Message-ID: <5f6ec3f7-9d5d-dbb5-2e16-6ea0e6fafe6e@gmail.com> (raw)
In-Reply-To: <511703b7a86075387b5bf07434077724@walle.cc>

On 12/19/2022 4:29 PM, Michael Walle wrote:
> Hi,
> 
Hi Michael,

> Am 2022-12-19 02:55, schrieb tkuw584924@gmail.com:
>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
>>
>> Infineon S25FS256T is 256Mbit Quad SPI NOR flash. The key features and
>> differences comparing to other Spansion/Cypress flash familes are:
>>   - 4-byte address mode by factory default
>>   - Quad mode is enabled by factory default
>>   - Supports mixture of 128KB and 64KB sectors by OTP configuration
>>     (this patch supports uniform 128KB only due to complexity of
>>      non-uniform layout)
>>
>> Tested on Xilinx Zynq-7000 FPGA board.
>>
>> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
>> ---
>> Datasheet:
>> fileId=8ac78c8c80027ecd0180740c5a46707https://www.infineon.com/dgdlac/Infineon-S25FS256T_256Mb_SEMPER_Nano_Flash_Quad_SPI_1.8V-DataSheet-v12_00-EN.pdf?a
>>
>> zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
>> s25fs256t
>> zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
>> 342b190f0890
>> zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
>> spansion
>> zynq> xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
>> 53464450080101ff00000114000100ff84000102500100ffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> ffffffffffffffffffffffffffffffffe7ffe2ffffffff0f48eb086bffff
>> ffffeeffffffffff00ffffff00ff11d810d800ff00ff321cfeff71e9ffe1
>> ec031c607a757a75f766805c00d65dfff938c0a100000000000000000000
>> 0000ffffffff710600fedcdcffff
>> zynq> md5sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
>> 13ecce2f195c4c71648e90d4a7e4a0df  /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
>> zynq> test_qspi.sh
>> random: crng init done
>> 6+0 records in
>> 6+0 records out
>> 6291456 bytes (6.0MB) copied, 2.787435 seconds, 2.2MB/s
>> Copied 6291456 bytes from qspi_test to address 0x00000000 in flash
>> Erased 6291456 bytes from address 0x00000000 in flash
>> Copied 6291456 bytes from address 0x00000000 in flash to qspi_read
>> 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
>> *
>> 0600000
>> Copied 6291456 bytes from qspi_test to address 0x00000000 in flash
>> Copied 6291456 bytes from address 0x00000000 in flash to qspi_read
>> 2c6e12c0a2346cab755ef72cdf2a72f827241d35  qspi_test
>> 2c6e12c0a2346cab755ef72cdf2a72f827241d35  qspi_read
>> ---
>>  drivers/mtd/spi-nor/spansion.c | 64 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
>> index b621cdfd506f..7d1d2c27ad71 100644
>> --- a/drivers/mtd/spi-nor/spansion.c
>> +++ b/drivers/mtd/spi-nor/spansion.c
>> @@ -24,6 +24,7 @@
>>  #define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN    0x3
>>  #define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS    0
>>  #define SPINOR_OP_CYPRESS_RD_FAST        0xee
>> +#define SPINOR_REG_CYPRESS_ARCFN        0x00000006
>>
>>  /* Cypress SPI NOR flash operations. */
>>  #define CYPRESS_NOR_WR_ANY_REG_OP(naddr, addr, ndata, buf)        \
>> @@ -213,6 +214,66 @@ static int cypress_nor_set_page_size(struct spi_nor *nor)
>>      return 0;
>>  }
>>
>> +static int
>> +s25fs256t_post_bfpt_fixup(struct spi_nor *nor,
>> +              const struct sfdp_parameter_header *bfpt_header,
>> +              const struct sfdp_bfpt *bfpt)
>> +{
>> +    struct spi_mem_op op;
>> +    int ret;
>> +
>> +    /* 4-byte address mode is enabled by default */
>> +    nor->params->addr_mode_nbytes = 4;
> 
> Shouldn't this already be set in spi_nor_parse_4bait()?
> 
No, params->addr_mode_nbytes is initialized in spi_nor_parse_bfpt().
In spi_nor_parse_4bait(), params->addr_nbytes is set to 4.

>> +
>> +    /* Read Architecture Configuration Register (ARCFN) */
>> +    op = (struct spi_mem_op)
>> +        CYPRESS_NOR_RD_ANY_REG_OP(nor->params->addr_mode_nbytes,
>> +                      SPINOR_REG_CYPRESS_ARCFN,
>> +                      nor->bouncebuf);
>> +    op.dummy.nbytes = 1;
>> +    ret = spi_nor_read_any_reg(nor, &op, nor->reg_proto);
>> +    if (ret)
>> +        return ret;
>> +
>> +    /* ARCFN value must be 0 if uniform sector is selected  */
>> +    if (nor->bouncebuf[0])
>> +        return -EOPNOTSUPP;
> 
> EOPNOTSUPP is wrong here. I'd say ENODEV.
> 
OK.

>> +
>> +    return cypress_nor_set_page_size(nor);
>> +}
>> +
>> +static void s25fs256t_post_sfdp_fixup(struct spi_nor *nor)
>> +{
>> +    struct spi_nor_flash_parameter *params = nor->params;
>> +
>> +    /*
>> +     * READ_FAST is omitted in 4BAIT parse since OP_READ_FAST_4B(0Ch) is not
>> +     * supported. Enable OP_READ_FAST(0Bh) that can work in 4-byte address
>> +     * mode.
>> +     */
>> +    params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
>> +    spi_nor_set_read_settings(&params->reads[SNOR_CMD_READ_FAST], 0, 8,
>> +                  SPINOR_OP_READ_FAST, SNOR_PROTO_1_1_1);
> 
> Mh, this requires mode switching, the advantage of the opcodes in
> the 4bait table are that they don't require mode switching.
> OP_READ_FAST doesn't work here if the address mode is set to 3. (I
> know this flash defaults to 1, but there is also a non-volatile
> setting for this).
> 
> Regarding mode switching, I guess this is wrong for this flash, because
> it is set to spansion_set_4byte_addr_mode() by default while it should
> really be set to spi_nor_set_4byte_addr_mode().
> 
Let me just drop fast read support so far and mention this in commit
description.

> Also I'm not sure when set_4byte_addr_mode() is called during init.
> It seems slightly wrong to me because it will check wether
> SNOR_F_4B_OPCODES is set. But in the restore path, it is checked for
> !SNOR_F_4B_OPCODES before 3 byte mode is enabled again. Mhh.
> 
>> +
>> +    /* PP_1_1_4_4B is supported but missing in SFDP. */
>> +    params->hwcaps.mask |= SNOR_HWCAPS_PP_1_1_4;
>> +    spi_nor_set_pp_settings(&params->page_programs[SNOR_CMD_PP_1_1_4],
>> +                SPINOR_OP_PP_1_1_4_4B,
>> +                SNOR_PROTO_1_1_4);
>> +}
>> +
>> +static void s25fs256t_late_init(struct spi_nor *nor)
>> +{
>> +    /* The writesize should be ECC data unit size */
>> +    nor->params->writesize = 16;
> 
> The datasheets mentions, a PP should be either 128 or 256 (for best
> performance). So why 16?
> 
writesize is used as minimum IO size in UBI.
Please see:
https://lore.kernel.org/linux-mtd/20201118182459.18197-1-p.yadav@ti.com/

>> +}
>> +
>> +static struct spi_nor_fixups s25fs256t_fixups = {
>> +    .post_bfpt = s25fs256t_post_bfpt_fixup,
>> +    .post_sfdp = s25fs256t_post_sfdp_fixup,
>> +    .late_init = s25fs256t_late_init,
>> +};
>> +
>>  static int
>>  s25hx_t_post_bfpt_fixup(struct spi_nor *nor,
>>              const struct sfdp_parameter_header *bfpt_header,
>> @@ -441,6 +502,9 @@ static const struct flash_info spansion_nor_parts[] = {
>>      { "s25fl256l",  INFO(0x016019,      0,  64 * 1024, 512)
>>          NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
>>          FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
>> +    { "s25fs256t",  INFO6(0x342b19, 0x0f0890, 128 * 1024, 256)
> 
> Does INFO6(0x342b19, 0x0f0890, 0, 0) work for you?
> 
Yes, it works.

>> +        PARSE_SFDP
>> +        .fixups = &s25fs256t_fixups },
>>      { "s25hl512t",  INFO6(0x342a1a, 0x0f0390, 256 * 1024, 256)
>>          PARSE_SFDP
>>          MFR_FLAGS(USE_CLSR)

Thanks,
Takahiro

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

  parent reply	other threads:[~2022-12-20  8:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-19  1:55 [PATCH] mtd: spi-nor: spansion: Add support for Infineon S25FS256T tkuw584924
2022-12-19  7:29 ` Michael Walle
2022-12-19  8:27   ` Michael Walle
2022-12-20  8:33     ` Takahiro Kuwano
2022-12-20  8:31   ` Takahiro Kuwano [this message]
2022-12-20 10:01     ` Michael Walle
2022-12-22 10:32       ` Takahiro Kuwano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5f6ec3f7-9d5d-dbb5-2e16-6ea0e6fafe6e@gmail.com \
    --to=tkuw584924@gmail.com \
    --cc=Bacem.Daassi@infineon.com \
    --cc=Takahiro.Kuwano@infineon.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox