From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <Takahiro.Kuwano@infineon.com>,
<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<Nicolas.Ferre@microchip.com>, <zhengxunli@mxic.com.tw>,
<jaimeliao@mxic.com.tw>, <Bacem.Daassi@infineon.com>
Subject: Re: [PATCH 2/3] mtd: spi-nor: micron-st: Rework spi_nor_micron_octal_dtr_enable()
Date: Fri, 25 Feb 2022 07:37:45 +0000 [thread overview]
Message-ID: <3ea0d41e-e82b-dc28-b35d-11f07809e102@microchip.com> (raw)
In-Reply-To: <20220224195139.i4kjbnhgthwtcaet@ti.com>
On 2/24/22 21:51, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi Tudor,
>
> On 10/02/22 04:33AM, Tudor Ambarus wrote:
>> Introduce template operation to remove code duplication.
>> Split spi_nor_micron_octal_dtr_enable() in spi_nor_micron_octal_dtr_en()
>> and spi_nor_micron_octal_dtr_dis() as it no longer made sense to try to
>> keep everything alltogether: too many "if (enable)" throughout the code,
>> which made the code difficult to follow.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>> drivers/mtd/spi-nor/micron-st.c | 105 +++++++++++++++++---------------
>> 1 file changed, 55 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
>> index 7f66b5943ceb..013aa6a52737 100644
>> --- a/drivers/mtd/spi-nor/micron-st.c
>> +++ b/drivers/mtd/spi-nor/micron-st.c
>> @@ -17,73 +17,72 @@
>> #define SPINOR_MT_OCT_DTR 0xe7 /* Enable Octal DTR. */
>> #define SPINOR_MT_EXSPI 0xff /* Enable Extended SPI (default) */
>>
>> -static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
>> +/* Micron ST SPI NOR flash operations. */
>> +#define SPI_NOR_MICRON_WR_ANY_REG_OP(naddr, addr, ndata, buf) \
>
> Should change function and variable names based on mwalle's patches
> (assuming you agree with that scheme). MICRON_NOR_WR_ANY_REG_OP?
yes, will do.
>
>> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 0), \
>> + SPI_MEM_OP_ADDR(naddr, addr, 0), \
>> + SPI_MEM_OP_NO_DUMMY, \
>> + SPI_MEM_OP_DATA_OUT(ndata, buf, 0))
>> +
>> +static int spi_nor_micron_octal_dtr_en(struct spi_nor *nor)
>
> micron_nor_octal_dtr_en(). Same for other functions.
>
>> {
>> struct spi_mem_op op;
>> u8 *buf = nor->bouncebuf;
>> int ret;
>>
>> - if (enable) {
>> - /* Use 20 dummy cycles for memory array reads. */
>> - ret = spi_nor_write_enable(nor);
>> - if (ret)
>> - return ret;
>> -
>> - *buf = 20;
>> - op = (struct spi_mem_op)
>> - SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
>> - SPI_MEM_OP_ADDR(3, SPINOR_REG_MT_CFR1V, 1),
>> - SPI_MEM_OP_NO_DUMMY,
>> - SPI_MEM_OP_DATA_OUT(1, buf, 1));
>> -
>> - ret = spi_mem_exec_op(nor->spimem, &op);
>> - if (ret)
>> - return ret;
>> + /* Use 20 dummy cycles for memory array reads. */
>> + *buf = 20;
>> + op = (struct spi_mem_op)
>> + SPI_NOR_MICRON_WR_ANY_REG_OP(3, SPINOR_REG_MT_CFR1V, 1, buf);
>> + ret = spi_nor_write_reg(nor, &op, nor->reg_proto);
>> + if (ret)
>> + return ret;
>> + ret = spi_nor_wait_till_ready(nor);
>> + if (ret)
>> + return ret;
>>
>> - ret = spi_nor_wait_till_ready(nor);
>> - if (ret)
>> - return ret;
>> - }
>> + buf[0] = SPINOR_MT_OCT_DTR;
>> + op = (struct spi_mem_op)
>> + SPI_NOR_MICRON_WR_ANY_REG_OP(3, SPINOR_REG_MT_CFR0V, 1, buf);
>> + ret = spi_nor_write_reg(nor, &op, nor->reg_proto);
>> + if (ret)
>> + return ret;
>>
>> - ret = spi_nor_write_enable(nor);
>> + /* Read flash ID to make sure the switch was successful. */
>> + ret = spi_nor_read_id(nor, 0, 8, buf, SNOR_PROTO_8_8_8_DTR);
>> if (ret)
>> return ret;
>>
>> - if (enable) {
>> - buf[0] = SPINOR_MT_OCT_DTR;
>> - } else {
>> - /*
>> - * The register is 1-byte wide, but 1-byte transactions are not
>> - * allowed in 8D-8D-8D mode. The next register is the dummy
>> - * cycle configuration register. Since the transaction needs to
>> - * be at least 2 bytes wide, set the next register to its
>> - * default value. This also makes sense because the value was
>> - * changed when enabling 8D-8D-8D mode, it should be reset when
>> - * disabling.
>> - */
>> - buf[0] = SPINOR_MT_EXSPI;
>> - buf[1] = SPINOR_REG_MT_CFR1V_DEF;
>> - }
>> + if (memcmp(buf, nor->info->id, nor->info->id_len))
>> + return -EINVAL;
>>
>> - op = (struct spi_mem_op)
>> - SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
>> - SPI_MEM_OP_ADDR(enable ? 3 : 4,
>> - SPINOR_REG_MT_CFR0V, 1),
>> - SPI_MEM_OP_NO_DUMMY,
>> - SPI_MEM_OP_DATA_OUT(enable ? 1 : 2, buf, 1));
>> + return 0;
>> +}
>>
>> - if (!enable)
>> - spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
>> +static int spi_nor_micron_octal_dtr_dis(struct spi_nor *nor)
>> +{
>> + struct spi_mem_op op;
>> + u8 *buf = nor->bouncebuf;
>> + int ret;
>>
>> - ret = spi_mem_exec_op(nor->spimem, &op);
>> + /*
>> + * The register is 1-byte wide, but 1-byte transactions are not allowed
>> + * in 8D-8D-8D mode. The next register is the dummy cycle configuration
>> + * register. Since the transaction needs to be at least 2 bytes wide,
>> + * set the next register to its default value. This also makes sense
>> + * because the value was changed when enabling 8D-8D-8D mode, it should
>> + * be reset when disabling.
>> + */
>> + buf[0] = SPINOR_MT_EXSPI;
>> + buf[1] = SPINOR_REG_MT_CFR1V_DEF;
>> + op = (struct spi_mem_op)
>> + SPI_NOR_MICRON_WR_ANY_REG_OP(4, SPINOR_REG_MT_CFR0V, 2, buf);
>> + ret = spi_nor_write_reg(nor, &op, SNOR_PROTO_8_8_8_DTR);
>> if (ret)
>> return ret;
>>
>> /* Read flash ID to make sure the switch was successful. */
>> - if (enable)
>> - ret = spi_nor_read_id(nor, 0, 8, buf, SNOR_PROTO_8_8_8_DTR);
>> - else
>> - ret = spi_nor_read_id(nor, 0, 0, buf, nor->reg_proto);
>> + ret = spi_nor_read_id(nor, 0, 0, buf, nor->reg_proto);
>
> nor->reg_proto is not updated yet. It will be updated _after_ this
> function completes. So you would end up calling read ID in 8D-8D-8D
> mode, which would be bogus.
>
> I tried with Micron MT35XU512ABA. Enable works fine, but disable fails
> (it succeeds in reality but the function is unable to verify that)
> because of this. Changing nor->reg_proto to SNOR_PROTO_1_1_1 fixes it.
>
> Looks like the problem is not introduced by this patch though. It seems
> to come from patch 5 of your mx66 series. I see the same with the
> Cypress flash too but I have not tested it yet.
okay, thanks, I'll take a look. Thanks for doing the testing!
Cheers,
ta
>
>> if (ret)
>> return ret;
>>
>> @@ -93,6 +92,12 @@ static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
>> return 0;
>> }
>>
>> +static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
>> +{
>> + return enable ? spi_nor_micron_octal_dtr_en(nor) :
>> + spi_nor_micron_octal_dtr_dis(nor);
>> +}
>> +
>> static void mt35xu512aba_default_init(struct spi_nor *nor)
>> {
>> nor->params->octal_dtr_enable = spi_nor_micron_octal_dtr_enable;
>> --
>> 2.25.1
>>
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <Takahiro.Kuwano@infineon.com>,
<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<Nicolas.Ferre@microchip.com>, <zhengxunli@mxic.com.tw>,
<jaimeliao@mxic.com.tw>, <Bacem.Daassi@infineon.com>
Subject: Re: [PATCH 2/3] mtd: spi-nor: micron-st: Rework spi_nor_micron_octal_dtr_enable()
Date: Fri, 25 Feb 2022 07:37:45 +0000 [thread overview]
Message-ID: <3ea0d41e-e82b-dc28-b35d-11f07809e102@microchip.com> (raw)
In-Reply-To: <20220224195139.i4kjbnhgthwtcaet@ti.com>
On 2/24/22 21:51, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi Tudor,
>
> On 10/02/22 04:33AM, Tudor Ambarus wrote:
>> Introduce template operation to remove code duplication.
>> Split spi_nor_micron_octal_dtr_enable() in spi_nor_micron_octal_dtr_en()
>> and spi_nor_micron_octal_dtr_dis() as it no longer made sense to try to
>> keep everything alltogether: too many "if (enable)" throughout the code,
>> which made the code difficult to follow.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>> drivers/mtd/spi-nor/micron-st.c | 105 +++++++++++++++++---------------
>> 1 file changed, 55 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
>> index 7f66b5943ceb..013aa6a52737 100644
>> --- a/drivers/mtd/spi-nor/micron-st.c
>> +++ b/drivers/mtd/spi-nor/micron-st.c
>> @@ -17,73 +17,72 @@
>> #define SPINOR_MT_OCT_DTR 0xe7 /* Enable Octal DTR. */
>> #define SPINOR_MT_EXSPI 0xff /* Enable Extended SPI (default) */
>>
>> -static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
>> +/* Micron ST SPI NOR flash operations. */
>> +#define SPI_NOR_MICRON_WR_ANY_REG_OP(naddr, addr, ndata, buf) \
>
> Should change function and variable names based on mwalle's patches
> (assuming you agree with that scheme). MICRON_NOR_WR_ANY_REG_OP?
yes, will do.
>
>> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 0), \
>> + SPI_MEM_OP_ADDR(naddr, addr, 0), \
>> + SPI_MEM_OP_NO_DUMMY, \
>> + SPI_MEM_OP_DATA_OUT(ndata, buf, 0))
>> +
>> +static int spi_nor_micron_octal_dtr_en(struct spi_nor *nor)
>
> micron_nor_octal_dtr_en(). Same for other functions.
>
>> {
>> struct spi_mem_op op;
>> u8 *buf = nor->bouncebuf;
>> int ret;
>>
>> - if (enable) {
>> - /* Use 20 dummy cycles for memory array reads. */
>> - ret = spi_nor_write_enable(nor);
>> - if (ret)
>> - return ret;
>> -
>> - *buf = 20;
>> - op = (struct spi_mem_op)
>> - SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
>> - SPI_MEM_OP_ADDR(3, SPINOR_REG_MT_CFR1V, 1),
>> - SPI_MEM_OP_NO_DUMMY,
>> - SPI_MEM_OP_DATA_OUT(1, buf, 1));
>> -
>> - ret = spi_mem_exec_op(nor->spimem, &op);
>> - if (ret)
>> - return ret;
>> + /* Use 20 dummy cycles for memory array reads. */
>> + *buf = 20;
>> + op = (struct spi_mem_op)
>> + SPI_NOR_MICRON_WR_ANY_REG_OP(3, SPINOR_REG_MT_CFR1V, 1, buf);
>> + ret = spi_nor_write_reg(nor, &op, nor->reg_proto);
>> + if (ret)
>> + return ret;
>> + ret = spi_nor_wait_till_ready(nor);
>> + if (ret)
>> + return ret;
>>
>> - ret = spi_nor_wait_till_ready(nor);
>> - if (ret)
>> - return ret;
>> - }
>> + buf[0] = SPINOR_MT_OCT_DTR;
>> + op = (struct spi_mem_op)
>> + SPI_NOR_MICRON_WR_ANY_REG_OP(3, SPINOR_REG_MT_CFR0V, 1, buf);
>> + ret = spi_nor_write_reg(nor, &op, nor->reg_proto);
>> + if (ret)
>> + return ret;
>>
>> - ret = spi_nor_write_enable(nor);
>> + /* Read flash ID to make sure the switch was successful. */
>> + ret = spi_nor_read_id(nor, 0, 8, buf, SNOR_PROTO_8_8_8_DTR);
>> if (ret)
>> return ret;
>>
>> - if (enable) {
>> - buf[0] = SPINOR_MT_OCT_DTR;
>> - } else {
>> - /*
>> - * The register is 1-byte wide, but 1-byte transactions are not
>> - * allowed in 8D-8D-8D mode. The next register is the dummy
>> - * cycle configuration register. Since the transaction needs to
>> - * be at least 2 bytes wide, set the next register to its
>> - * default value. This also makes sense because the value was
>> - * changed when enabling 8D-8D-8D mode, it should be reset when
>> - * disabling.
>> - */
>> - buf[0] = SPINOR_MT_EXSPI;
>> - buf[1] = SPINOR_REG_MT_CFR1V_DEF;
>> - }
>> + if (memcmp(buf, nor->info->id, nor->info->id_len))
>> + return -EINVAL;
>>
>> - op = (struct spi_mem_op)
>> - SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
>> - SPI_MEM_OP_ADDR(enable ? 3 : 4,
>> - SPINOR_REG_MT_CFR0V, 1),
>> - SPI_MEM_OP_NO_DUMMY,
>> - SPI_MEM_OP_DATA_OUT(enable ? 1 : 2, buf, 1));
>> + return 0;
>> +}
>>
>> - if (!enable)
>> - spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
>> +static int spi_nor_micron_octal_dtr_dis(struct spi_nor *nor)
>> +{
>> + struct spi_mem_op op;
>> + u8 *buf = nor->bouncebuf;
>> + int ret;
>>
>> - ret = spi_mem_exec_op(nor->spimem, &op);
>> + /*
>> + * The register is 1-byte wide, but 1-byte transactions are not allowed
>> + * in 8D-8D-8D mode. The next register is the dummy cycle configuration
>> + * register. Since the transaction needs to be at least 2 bytes wide,
>> + * set the next register to its default value. This also makes sense
>> + * because the value was changed when enabling 8D-8D-8D mode, it should
>> + * be reset when disabling.
>> + */
>> + buf[0] = SPINOR_MT_EXSPI;
>> + buf[1] = SPINOR_REG_MT_CFR1V_DEF;
>> + op = (struct spi_mem_op)
>> + SPI_NOR_MICRON_WR_ANY_REG_OP(4, SPINOR_REG_MT_CFR0V, 2, buf);
>> + ret = spi_nor_write_reg(nor, &op, SNOR_PROTO_8_8_8_DTR);
>> if (ret)
>> return ret;
>>
>> /* Read flash ID to make sure the switch was successful. */
>> - if (enable)
>> - ret = spi_nor_read_id(nor, 0, 8, buf, SNOR_PROTO_8_8_8_DTR);
>> - else
>> - ret = spi_nor_read_id(nor, 0, 0, buf, nor->reg_proto);
>> + ret = spi_nor_read_id(nor, 0, 0, buf, nor->reg_proto);
>
> nor->reg_proto is not updated yet. It will be updated _after_ this
> function completes. So you would end up calling read ID in 8D-8D-8D
> mode, which would be bogus.
>
> I tried with Micron MT35XU512ABA. Enable works fine, but disable fails
> (it succeeds in reality but the function is unable to verify that)
> because of this. Changing nor->reg_proto to SNOR_PROTO_1_1_1 fixes it.
>
> Looks like the problem is not introduced by this patch though. It seems
> to come from patch 5 of your mx66 series. I see the same with the
> Cypress flash too but I have not tested it yet.
okay, thanks, I'll take a look. Thanks for doing the testing!
Cheers,
ta
>
>> if (ret)
>> return ret;
>>
>> @@ -93,6 +92,12 @@ static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
>> return 0;
>> }
>>
>> +static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
>> +{
>> + return enable ? spi_nor_micron_octal_dtr_en(nor) :
>> + spi_nor_micron_octal_dtr_dis(nor);
>> +}
>> +
>> static void mt35xu512aba_default_init(struct spi_nor *nor)
>> {
>> nor->params->octal_dtr_enable = spi_nor_micron_octal_dtr_enable;
>> --
>> 2.25.1
>>
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
next prev parent reply other threads:[~2022-02-25 7:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 2:33 [PATCH 0/3] mtd: spi-nor: Rework Octal DTR enable methods Tudor Ambarus
2022-02-10 2:33 ` Tudor Ambarus
2022-02-10 2:33 ` [PATCH 1/3] mtd: spi-nor: core: Add helpers to read/write any register Tudor Ambarus
2022-02-10 2:33 ` Tudor Ambarus
2022-02-21 7:40 ` Takahiro Kuwano
2022-02-21 7:40 ` Takahiro Kuwano
2022-02-23 20:59 ` Pratyush Yadav
2022-02-23 20:59 ` Pratyush Yadav
2022-02-10 2:33 ` [PATCH 2/3] mtd: spi-nor: micron-st: Rework spi_nor_micron_octal_dtr_enable() Tudor Ambarus
2022-02-10 2:33 ` Tudor Ambarus
2022-02-24 19:51 ` Pratyush Yadav
2022-02-24 19:51 ` Pratyush Yadav
2022-02-25 7:37 ` Tudor.Ambarus [this message]
2022-02-25 7:37 ` Tudor.Ambarus
2022-02-10 2:33 ` [PATCH 3/3] mtd: spi-nor: spansion: Rework spi_nor_cypress_octal_dtr_enable() Tudor Ambarus
2022-02-10 2:33 ` Tudor Ambarus
2022-02-24 19:53 ` Pratyush Yadav
2022-02-24 19:53 ` Pratyush Yadav
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=3ea0d41e-e82b-dc28-b35d-11f07809e102@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=Bacem.Daassi@infineon.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Takahiro.Kuwano@infineon.com \
--cc=jaimeliao@mxic.com.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
--cc=zhengxunli@mxic.com.tw \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.