| Message ID | 20220720154237.GG2049@begut |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | mtd: spi: spi-nor: rk3399: rock-pi-4: u-boot/next Support SPI NOR Flash in Rock Pi 4 (XTX xt25f32b) | expand |
On 20/07/22 05:42PM, Xavier Drudis Ferran wrote: > XTX25F32B does not use octal mode and accepts soft reset, despite its > SFDP tables. Soft reset at U-Boot exit seems to be required to write > to /dev/mtd0 from flashrom in linux. Soft reset at U-Boot start seems > to help booting from SPI (at least with the dts properties I'm using). > > The first soft reset is done before the flash id is read and the > fixups can be called, and v1 of this patch would now fail in Rock Pi 4 > because of unsupported operation if tried with > SNOR_PROTO_8_8_8_DTR. This was since commit 5752d6ae8daa ("spi: > spi-mem: add spi_mem_dtr_supports_op()") by Pratyush Yadav. > > So try a few modes until SNOR_PROTO_1_1_1 works and then remember the > reset_proto. This tries to be useful for other boards, but I still > don't know any other that needs it and what would work there. > > Changed since v2: > > - none (rebase) > > Changed since v1: > > - Generalization. First soft reset with SNOR_PROTO_8_8_8_DTR stopped > working since the improvement by Pratyush Yadav. > Instead of trying 8_8_8_DTR always at first reset, and force > 1_1_1 once XTX25F32B is detected (so, for last reset) do > a generic loop for any chip trying protocols until one is > supported and starting by the 8_8_8_DTR protocol (the one previously > used). This leverages the fixed supports_op() to take into account > controller and device. Please don't put the changelog in the commit message. Put it below the 3 dashed lines below. > > fixups can be called, and it would now fail in Rock Pi 4 because of > unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. So try a few > modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. > This tries to be useful for other boards, but I still don't know any > other that needs it and what would work there. > > Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat> > > Cc: Jagan Teki <jagan@amarulasolutions.com> > Cc: Vignesh R <vigneshr@ti.com> > > --- > drivers/mtd/spi/spi-nor-core.c | 98 ++++++++++++++++++++++++++++++---- > include/linux/mtd/spi-nor.h | 5 ++ > 2 files changed, 92 insertions(+), 11 deletions(-) > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index 8a226a7af5..17f0cb51fb 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -3575,6 +3575,18 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { > }; > #endif /* CONFIG_SPI_FLASH_MT35XU */ > > +#ifdef CONFIG_SPI_FLASH_XTX > +static void xtx25f32b_post_sfdp_fixup(struct spi_nor *nor, > + struct spi_nor_flash_parameter *params) > +{ > + nor->flags |= SNOR_F_SOFT_RESET; > +} > + > +static struct spi_nor_fixups xtx25f32b_fixups = { > + .post_sfdp = xtx25f32b_post_sfdp_fixup, > +}; > +#endif > + > #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) > /** > * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes. > @@ -3733,6 +3745,53 @@ static int spi_nor_init(struct spi_nor *nor) > } > > #ifdef CONFIG_SPI_FLASH_SOFT_RESET > +/** > + * spi_nor_soft_reset_setup_op() - Initial setup of op for soft > + * reset. Initializes nor->reset_proto iff needed. > + * > + * @nor: the spi_nor structure nor->reset_proto will be used or if > + * null, it'll be assigned the used protocol, from a few > + * protocols that get tried for device and controller > + * support. > + * > + * @opcode operation code for soft reset (or soft reset enable, > + * we currently assume they work the same in all systems) > + * > + * @op: pointer to operation struct to set up for reset or reset > + * enable. > + */ > +static void spi_nor_soft_reset_setup_op(struct spi_nor *nor, u16 opcode, struct spi_mem_op *op) > +{ > + enum spi_nor_protocol reset_proto; > + /** > + * admitedly arbitrary list, to be improved if there's > + * new knowledge of what works in different systems > + */ > + enum spi_nor_protocol reset_proto_candidates[] = { > + SNOR_PROTO_8_8_8_DTR, SNOR_PROTO_1_1_1_DTR, SNOR_PROTO_8_8_8, > + SNOR_PROTO_4_4_4, SNOR_PROTO_2_2_2, SNOR_PROTO_1_1_1 > + }; > + > + if (nor->reset_proto) { > + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), > + SPI_MEM_OP_NO_DUMMY, > + SPI_MEM_OP_NO_ADDR, > + SPI_MEM_OP_NO_DATA); > + spi_nor_setup_op(nor, op, nor->reset_proto); > + } else { > + for (int i = 0; i < ARRAY_SIZE(reset_proto_candidates) && !nor->reset_proto ; i++) { > + reset_proto = reset_proto_candidates[i]; > + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), > + SPI_MEM_OP_NO_DUMMY, > + SPI_MEM_OP_NO_ADDR, > + SPI_MEM_OP_NO_DATA); > + spi_nor_setup_op(nor, op, reset_proto); > + if (spi_mem_supports_op(nor->spi, op)) This only tells if the _controller_ supports the op. There is no way to find out if the flash supports the op without reading SFDP, which would need you to either reset the flash or know which mode it is in. So this patch is all wrong. The only way to find out what the flash supports is to read its ID or SFDP. > + nor->reset_proto = reset_proto; > + } > + } > +} > + > /** > * spi_nor_soft_reset() - perform the JEDEC Software Reset sequence > * @nor: the spi_nor structure > @@ -3756,11 +3815,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > #endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ > } > > - op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), > - SPI_MEM_OP_NO_DUMMY, > - SPI_MEM_OP_NO_ADDR, > - SPI_MEM_OP_NO_DATA); > - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > + spi_nor_soft_reset_setup_op(nor, SPINOR_OP_SRSTEN, &op); > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset enable failed: %d\n", ret); > @@ -3771,7 +3826,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > SPI_MEM_OP_NO_DUMMY, > SPI_MEM_OP_NO_ADDR, > SPI_MEM_OP_NO_DATA); > - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > + spi_nor_setup_op(nor, &op, nor->reset_proto); > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset failed: %d\n", ret); > @@ -3789,18 +3844,34 @@ out: > nor->cmd_ext_type = ext; > return ret; > } > -#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ > + > +static bool flash_supports_proto(const struct flash_info *flash, enum spi_nor_protocol proto) > +{ > + switch (spi_nor_get_protocol_data_nbits(proto)) { > + case 8: > + return flash->flags & (spi_nor_protocol_is_dtr(proto) > + ? SPI_NOR_OCTAL_DTR_READ > + : SPI_NOR_OCTAL_READ); > + case 4: return flash->flags & SPI_NOR_QUAD_READ; > + case 2: return flash->flags & SPI_NOR_DUAL_READ; > + default: > + return 1; > + } > +} > > int spi_nor_remove(struct spi_nor *nor) > { > -#ifdef CONFIG_SPI_FLASH_SOFT_RESET > - if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ && > + if (flash_supports_proto(nor->info, nor->reset_proto) && > nor->flags & SNOR_F_SOFT_RESET) > return spi_nor_soft_reset(nor); > -#endif > - > return 0; > } > +#else /* !CONFIG_SPI_FLASH_SOFT_RESET */ > +int spi_nor_remove(struct spi_nor *nor) > +{ > + return 0; > +} > +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ > > void spi_nor_set_fixups(struct spi_nor *nor) > { > @@ -3835,6 +3906,11 @@ void spi_nor_set_fixups(struct spi_nor *nor) > #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) > nor->fixups = ¯onix_octal_fixups; > #endif /* SPI_FLASH_MACRONIX */ > + > +#ifdef CONFIG_SPI_FLASH_XTX > + if (!strcmp(nor->info->name, "xt25f32b")) > + nor->fixups = &xtx25f32b_fixups; > +#endif > } > > int spi_nor_scan(struct spi_nor *nor) > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > index 2595bad9df..4fc81e7b8d 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -501,6 +501,8 @@ struct spi_flash { > * @read_proto: the SPI protocol for read operations > * @write_proto: the SPI protocol for write operations > * @reg_proto the SPI protocol for read_reg/write_reg/erase operations > + * @reset_proto: The SPI protocol for soft reset to return to state expected > + * by OS before running the OS (at remove time) or at sf probe > * @cmd_buf: used by the write_reg > * @cmd_ext_type: the command opcode extension for DTR mode. > * @fixups: flash-specific fixup hooks. > @@ -546,6 +548,9 @@ struct spi_nor { > enum spi_nor_protocol read_proto; > enum spi_nor_protocol write_proto; > enum spi_nor_protocol reg_proto; > +#ifdef CONFIG_SPI_FLASH_SOFT_RESET > + enum spi_nor_protocol reset_proto; > +#endif > bool sst_write_second; > u32 flags; > u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE]; > -- > 2.20.1 >
Thank you for your time looking at the patch. El Tue, Jul 26, 2022 at 12:43:06PM +0530, Pratyush Yadav deia: > > Please don't put the changelog in the commit message. Put it below the 3 > dashed lines below. > Sorry. Will try to remember it next time. Not sure there's a next version of this patch, though. > > This only tells if the _controller_ supports the op. There is no way to > find out if the flash supports the op without reading SFDP, which would > need you to either reset the flash or know which mode it is in. Correct. But you can't always read the SFDP if you get the flash in some wrong state and try to reset it through a mode that the controller doesn't support. > So this patch is all wrong. Then I won't send a 4th version unless someone else thinks it's worth it and I have more time for it. > The only way to find out what the flash supports is to read its ID or > SFDP. > Chicken and egg ? The soft_reset is done before reading SFDP. It was done always in octal mode before my patch ("always" means whenever CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT was enabled). My patch tries to do it in a mode that the controller supports. In my experiments this helps being able to program /dev/mtd0 from linux with flashrom. If that is working in mainstream U-Boot on a Rock Pi 4B version 1.4 or later (with XTX flash) for the rest of people, then I must be testing wrong, what do I know? Thanks. Have a nice day.
On 26/07/22 10:27AM, Xavier Drudis Ferran wrote: > > Thank you for your time looking at the patch. > > El Tue, Jul 26, 2022 at 12:43:06PM +0530, Pratyush Yadav deia: > > > > Please don't put the changelog in the commit message. Put it below the 3 > > dashed lines below. > > > > Sorry. Will try to remember it next time. Not sure there's a next version of > this patch, though. > > > > > This only tells if the _controller_ supports the op. There is no way to > > find out if the flash supports the op without reading SFDP, which would > > need you to either reset the flash or know which mode it is in. > > Correct. But you can't always read the SFDP if you get the flash in > some wrong state and try to reset it through a mode that the controller > doesn't support. > > > So this patch is all wrong. > > Then I won't send a 4th version unless someone else thinks it's worth > it and I have more time for it. > > > The only way to find out what the flash supports is to read its ID or > > SFDP. > > > > Chicken and egg ? The soft_reset is done before reading SFDP. > It was done always in octal mode before my patch ("always" means > whenever CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT was enabled). My > patch tries to do it in a mode that the controller supports. Yes, this is indeed a chicken and egg problem of sorts. The octal mode soft reset I added is a hack that gets _some_ flashes working but not all. I see 3 possible ways to solve this: 1. Encode soft reset type in device tree. Read DT to issue the correct type of reset. But if a flash supports multiple stateful modes like 4D-4D-4D and 8D-8D-8D, this might not work so well. 2. Do a hardware reset. This needs the RESET# line to be connected on the board and some way to toggle it. Does not work for boards that do not have this. 3. Discover the mode the flash is in. The SFDP spec (JESD216D-01) does recommend a way to do this in section "4.5 Command Modes". This can let us find out which type of soft reset command the flash takes by reading SFDP. Of course, this needs the flash to implement the read SFDP command in all modes, which is not mandatory as per spec (at least as per xSPI spec (JESD251), which documents 8D-8D-8D flashes). There is no one size fits all solution that I can see, so I think we need to do all 3 to get full coverage of all cases. But start with the one that fixes your use case and is easiest for you. I would guess that is point 2. And all this does not even fix the problem of flashes that do not support 1S-1S-1S mode at all. There are some flashes out there that simply only support 8D-8D-8D mode. For those flashes, a reset would still put them in 8D-8D-8D mode. To support those you need to discover the flash mode and then initialize the flash in that mode itself, without resetting. I would recommending working with the Linux SPI NOR subsystem first. That has more eyes looking at it so it would be easier to come up with a good solution. Then you can backport it to U-Boot. > > In my experiments this helps being able to program /dev/mtd0 from > linux with flashrom. If that is working in mainstream U-Boot on a Rock > Pi 4B version 1.4 or later (with XTX flash) for the rest of people, > then I must be testing wrong, what do I know? > > Thanks. Have a nice day.
El Tue, Jul 26, 2022 at 02:39:09PM +0530, Pratyush Yadav deia: > > Yes, this is indeed a chicken and egg problem of sorts. The octal mode > soft reset I added is a hack that gets _some_ flashes working but not > all. I see 3 possible ways to solve this: > But it was a hack that solved a problem. We still have hunger, war and disease, but we have some more flashes working. That's some good, isn't it? > 1. Encode soft reset type in device tree. Read DT to issue the correct > type of reset. But if a flash supports multiple stateful modes like > 4D-4D-4D and 8D-8D-8D, this might not work so well. So must flash chips always be listed in dts ? Can some boards have a socket and users plug different flashes to it ? Might it then not work so well also ? My idea was try what you can with the controller you have because you know more what controller you have than what flash you have (until you can ask your flash who it is and what it looks like). This is only active when a nondefault kconfig is enabled, anyway. > 2. Do a hardware reset. This needs the RESET# line to be connected on > the board and some way to toggle it. Does not work for boards that > do not have this. ACK. Unfortunately not in my case[1]. > 3. Discover the mode the flash is in. The SFDP spec (JESD216D-01) does > recommend a way to do this in section "4.5 Command Modes". This can > let us find out which type of soft reset command the flash takes by > reading SFDP. Of course, this needs the flash to implement the read > SFDP command in all modes, which is not mandatory as per spec (at > least as per xSPI spec (JESD251), which documents 8D-8D-8D > flashes). > I think my XTX supports the soft reset according to the manual (commands 66 and 99), but the SFDP info does not include info about soft reset. I might misremember though. > There is no one size fits all solution that I can see, so I think we > need to do all 3 to get full coverage of all cases. But start with the > one that fixes your use case and is easiest for you. I would guess that > is point 2. > My XT25F32B-S has no hardware reset pin. The manual[2] says so in a sentence, in page 49 (out of context) and the pinout is : - Chip Select Input (CS#) - Data Output(SO) or I/O 1 (IO1) - Write Protect Input (WP#), or I/O2 (IO2) - Ground (VSS) - Data Input (SI), or I/O 0 (IO0) - Serial Clock Input (SCLK) - Hold Input (HOLD#) - Power Supply (VCC) And of course the board does not have a line for the nonexistent pin, so no, the closest to hardware reset would be board poweroff. SI, SO, CS and SCLK are connected to a 40 pin connector though, so I can ground them or pull them up or something. But no use. > And all this does not even fix the problem of flashes that do not > support 1S-1S-1S mode at all. There are some flashes out there that > simply only support 8D-8D-8D mode. For those flashes, a reset would > still put them in 8D-8D-8D mode. To support those you need to discover > the flash mode and then initialize the flash in that mode itself, > without resetting. > Well, maybe we can limit ourselves to solve solvable problems... That should keep us busy for a while... > I would recommending working with the Linux SPI NOR subsystem first. > That has more eyes looking at it so it would be easier to come up with a > good solution. Then you can backport it to U-Boot. > Thanks for the advice. Makes sense I guess. I'll see if I have the time and motivation. [1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4b_plus_v16_sch_20200628.pdf [2] https://www.xtxtech.com/download/?AId=157
Hi Jagan, This patchset goes into my todo list, but I'm not very good at SPI module, how do you think about this patchset? I will happy to merge this if there is no regression for other SPI NOR device. Thanks, - Kever On 2022/7/20 23:42, Xavier Drudis Ferran wrote: > XTX25F32B does not use octal mode and accepts soft reset, despite its > SFDP tables. Soft reset at U-Boot exit seems to be required to write > to /dev/mtd0 from flashrom in linux. Soft reset at U-Boot start seems > to help booting from SPI (at least with the dts properties I'm using). > > The first soft reset is done before the flash id is read and the > fixups can be called, and v1 of this patch would now fail in Rock Pi 4 > because of unsupported operation if tried with > SNOR_PROTO_8_8_8_DTR. This was since commit 5752d6ae8daa ("spi: > spi-mem: add spi_mem_dtr_supports_op()") by Pratyush Yadav. > > So try a few modes until SNOR_PROTO_1_1_1 works and then remember the > reset_proto. This tries to be useful for other boards, but I still > don't know any other that needs it and what would work there. > > Changed since v2: > > - none (rebase) > > Changed since v1: > > - Generalization. First soft reset with SNOR_PROTO_8_8_8_DTR stopped > working since the improvement by Pratyush Yadav. > Instead of trying 8_8_8_DTR always at first reset, and force > 1_1_1 once XTX25F32B is detected (so, for last reset) do > a generic loop for any chip trying protocols until one is > supported and starting by the 8_8_8_DTR protocol (the one previously > used). This leverages the fixed supports_op() to take into account > controller and device. > > fixups can be called, and it would now fail in Rock Pi 4 because of > unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. So try a few > modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. > This tries to be useful for other boards, but I still don't know any > other that needs it and what would work there. > > Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat> > > Cc: Jagan Teki <jagan@amarulasolutions.com> > Cc: Vignesh R <vigneshr@ti.com> > > --- > drivers/mtd/spi/spi-nor-core.c | 98 ++++++++++++++++++++++++++++++---- > include/linux/mtd/spi-nor.h | 5 ++ > 2 files changed, 92 insertions(+), 11 deletions(-) > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index 8a226a7af5..17f0cb51fb 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -3575,6 +3575,18 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { > }; > #endif /* CONFIG_SPI_FLASH_MT35XU */ > > +#ifdef CONFIG_SPI_FLASH_XTX > +static void xtx25f32b_post_sfdp_fixup(struct spi_nor *nor, > + struct spi_nor_flash_parameter *params) > +{ > + nor->flags |= SNOR_F_SOFT_RESET; > +} > + > +static struct spi_nor_fixups xtx25f32b_fixups = { > + .post_sfdp = xtx25f32b_post_sfdp_fixup, > +}; > +#endif > + > #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) > /** > * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes. > @@ -3733,6 +3745,53 @@ static int spi_nor_init(struct spi_nor *nor) > } > > #ifdef CONFIG_SPI_FLASH_SOFT_RESET > +/** > + * spi_nor_soft_reset_setup_op() - Initial setup of op for soft > + * reset. Initializes nor->reset_proto iff needed. > + * > + * @nor: the spi_nor structure nor->reset_proto will be used or if > + * null, it'll be assigned the used protocol, from a few > + * protocols that get tried for device and controller > + * support. > + * > + * @opcode operation code for soft reset (or soft reset enable, > + * we currently assume they work the same in all systems) > + * > + * @op: pointer to operation struct to set up for reset or reset > + * enable. > + */ > +static void spi_nor_soft_reset_setup_op(struct spi_nor *nor, u16 opcode, struct spi_mem_op *op) > +{ > + enum spi_nor_protocol reset_proto; > + /** > + * admitedly arbitrary list, to be improved if there's > + * new knowledge of what works in different systems > + */ > + enum spi_nor_protocol reset_proto_candidates[] = { > + SNOR_PROTO_8_8_8_DTR, SNOR_PROTO_1_1_1_DTR, SNOR_PROTO_8_8_8, > + SNOR_PROTO_4_4_4, SNOR_PROTO_2_2_2, SNOR_PROTO_1_1_1 > + }; > + > + if (nor->reset_proto) { > + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), > + SPI_MEM_OP_NO_DUMMY, > + SPI_MEM_OP_NO_ADDR, > + SPI_MEM_OP_NO_DATA); > + spi_nor_setup_op(nor, op, nor->reset_proto); > + } else { > + for (int i = 0; i < ARRAY_SIZE(reset_proto_candidates) && !nor->reset_proto ; i++) { > + reset_proto = reset_proto_candidates[i]; > + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), > + SPI_MEM_OP_NO_DUMMY, > + SPI_MEM_OP_NO_ADDR, > + SPI_MEM_OP_NO_DATA); > + spi_nor_setup_op(nor, op, reset_proto); > + if (spi_mem_supports_op(nor->spi, op)) > + nor->reset_proto = reset_proto; > + } > + } > +} > + > /** > * spi_nor_soft_reset() - perform the JEDEC Software Reset sequence > * @nor: the spi_nor structure > @@ -3756,11 +3815,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > #endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ > } > > - op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), > - SPI_MEM_OP_NO_DUMMY, > - SPI_MEM_OP_NO_ADDR, > - SPI_MEM_OP_NO_DATA); > - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > + spi_nor_soft_reset_setup_op(nor, SPINOR_OP_SRSTEN, &op); > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset enable failed: %d\n", ret); > @@ -3771,7 +3826,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > SPI_MEM_OP_NO_DUMMY, > SPI_MEM_OP_NO_ADDR, > SPI_MEM_OP_NO_DATA); > - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > + spi_nor_setup_op(nor, &op, nor->reset_proto); > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset failed: %d\n", ret); > @@ -3789,18 +3844,34 @@ out: > nor->cmd_ext_type = ext; > return ret; > } > -#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ > + > +static bool flash_supports_proto(const struct flash_info *flash, enum spi_nor_protocol proto) > +{ > + switch (spi_nor_get_protocol_data_nbits(proto)) { > + case 8: > + return flash->flags & (spi_nor_protocol_is_dtr(proto) > + ? SPI_NOR_OCTAL_DTR_READ > + : SPI_NOR_OCTAL_READ); > + case 4: return flash->flags & SPI_NOR_QUAD_READ; > + case 2: return flash->flags & SPI_NOR_DUAL_READ; > + default: > + return 1; > + } > +} > > int spi_nor_remove(struct spi_nor *nor) > { > -#ifdef CONFIG_SPI_FLASH_SOFT_RESET > - if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ && > + if (flash_supports_proto(nor->info, nor->reset_proto) && > nor->flags & SNOR_F_SOFT_RESET) > return spi_nor_soft_reset(nor); > -#endif > - > return 0; > } > +#else /* !CONFIG_SPI_FLASH_SOFT_RESET */ > +int spi_nor_remove(struct spi_nor *nor) > +{ > + return 0; > +} > +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ > > void spi_nor_set_fixups(struct spi_nor *nor) > { > @@ -3835,6 +3906,11 @@ void spi_nor_set_fixups(struct spi_nor *nor) > #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) > nor->fixups = ¯onix_octal_fixups; > #endif /* SPI_FLASH_MACRONIX */ > + > +#ifdef CONFIG_SPI_FLASH_XTX > + if (!strcmp(nor->info->name, "xt25f32b")) > + nor->fixups = &xtx25f32b_fixups; > +#endif > } > > int spi_nor_scan(struct spi_nor *nor) > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > index 2595bad9df..4fc81e7b8d 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -501,6 +501,8 @@ struct spi_flash { > * @read_proto: the SPI protocol for read operations > * @write_proto: the SPI protocol for write operations > * @reg_proto the SPI protocol for read_reg/write_reg/erase operations > + * @reset_proto: The SPI protocol for soft reset to return to state expected > + * by OS before running the OS (at remove time) or at sf probe > * @cmd_buf: used by the write_reg > * @cmd_ext_type: the command opcode extension for DTR mode. > * @fixups: flash-specific fixup hooks. > @@ -546,6 +548,9 @@ struct spi_nor { > enum spi_nor_protocol read_proto; > enum spi_nor_protocol write_proto; > enum spi_nor_protocol reg_proto; > +#ifdef CONFIG_SPI_FLASH_SOFT_RESET > + enum spi_nor_protocol reset_proto; > +#endif > bool sst_write_second; > u32 flags; > u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE];
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 8a226a7af5..17f0cb51fb 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3575,6 +3575,18 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { }; #endif /* CONFIG_SPI_FLASH_MT35XU */ +#ifdef CONFIG_SPI_FLASH_XTX +static void xtx25f32b_post_sfdp_fixup(struct spi_nor *nor, + struct spi_nor_flash_parameter *params) +{ + nor->flags |= SNOR_F_SOFT_RESET; +} + +static struct spi_nor_fixups xtx25f32b_fixups = { + .post_sfdp = xtx25f32b_post_sfdp_fixup, +}; +#endif + #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) /** * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes. @@ -3733,6 +3745,53 @@ static int spi_nor_init(struct spi_nor *nor) } #ifdef CONFIG_SPI_FLASH_SOFT_RESET +/** + * spi_nor_soft_reset_setup_op() - Initial setup of op for soft + * reset. Initializes nor->reset_proto iff needed. + * + * @nor: the spi_nor structure nor->reset_proto will be used or if + * null, it'll be assigned the used protocol, from a few + * protocols that get tried for device and controller + * support. + * + * @opcode operation code for soft reset (or soft reset enable, + * we currently assume they work the same in all systems) + * + * @op: pointer to operation struct to set up for reset or reset + * enable. + */ +static void spi_nor_soft_reset_setup_op(struct spi_nor *nor, u16 opcode, struct spi_mem_op *op) +{ + enum spi_nor_protocol reset_proto; + /** + * admitedly arbitrary list, to be improved if there's + * new knowledge of what works in different systems + */ + enum spi_nor_protocol reset_proto_candidates[] = { + SNOR_PROTO_8_8_8_DTR, SNOR_PROTO_1_1_1_DTR, SNOR_PROTO_8_8_8, + SNOR_PROTO_4_4_4, SNOR_PROTO_2_2_2, SNOR_PROTO_1_1_1 + }; + + if (nor->reset_proto) { + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_NO_ADDR, + SPI_MEM_OP_NO_DATA); + spi_nor_setup_op(nor, op, nor->reset_proto); + } else { + for (int i = 0; i < ARRAY_SIZE(reset_proto_candidates) && !nor->reset_proto ; i++) { + reset_proto = reset_proto_candidates[i]; + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_NO_ADDR, + SPI_MEM_OP_NO_DATA); + spi_nor_setup_op(nor, op, reset_proto); + if (spi_mem_supports_op(nor->spi, op)) + nor->reset_proto = reset_proto; + } + } +} + /** * spi_nor_soft_reset() - perform the JEDEC Software Reset sequence * @nor: the spi_nor structure @@ -3756,11 +3815,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) #endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ } - op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), - SPI_MEM_OP_NO_DUMMY, - SPI_MEM_OP_NO_ADDR, - SPI_MEM_OP_NO_DATA); - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); + spi_nor_soft_reset_setup_op(nor, SPINOR_OP_SRSTEN, &op); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset enable failed: %d\n", ret); @@ -3771,7 +3826,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) SPI_MEM_OP_NO_DUMMY, SPI_MEM_OP_NO_ADDR, SPI_MEM_OP_NO_DATA); - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); + spi_nor_setup_op(nor, &op, nor->reset_proto); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset failed: %d\n", ret); @@ -3789,18 +3844,34 @@ out: nor->cmd_ext_type = ext; return ret; } -#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ + +static bool flash_supports_proto(const struct flash_info *flash, enum spi_nor_protocol proto) +{ + switch (spi_nor_get_protocol_data_nbits(proto)) { + case 8: + return flash->flags & (spi_nor_protocol_is_dtr(proto) + ? SPI_NOR_OCTAL_DTR_READ + : SPI_NOR_OCTAL_READ); + case 4: return flash->flags & SPI_NOR_QUAD_READ; + case 2: return flash->flags & SPI_NOR_DUAL_READ; + default: + return 1; + } +} int spi_nor_remove(struct spi_nor *nor) { -#ifdef CONFIG_SPI_FLASH_SOFT_RESET - if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ && + if (flash_supports_proto(nor->info, nor->reset_proto) && nor->flags & SNOR_F_SOFT_RESET) return spi_nor_soft_reset(nor); -#endif - return 0; } +#else /* !CONFIG_SPI_FLASH_SOFT_RESET */ +int spi_nor_remove(struct spi_nor *nor) +{ + return 0; +} +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ void spi_nor_set_fixups(struct spi_nor *nor) { @@ -3835,6 +3906,11 @@ void spi_nor_set_fixups(struct spi_nor *nor) #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) nor->fixups = ¯onix_octal_fixups; #endif /* SPI_FLASH_MACRONIX */ + +#ifdef CONFIG_SPI_FLASH_XTX + if (!strcmp(nor->info->name, "xt25f32b")) + nor->fixups = &xtx25f32b_fixups; +#endif } int spi_nor_scan(struct spi_nor *nor) diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 2595bad9df..4fc81e7b8d 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -501,6 +501,8 @@ struct spi_flash { * @read_proto: the SPI protocol for read operations * @write_proto: the SPI protocol for write operations * @reg_proto the SPI protocol for read_reg/write_reg/erase operations + * @reset_proto: The SPI protocol for soft reset to return to state expected + * by OS before running the OS (at remove time) or at sf probe * @cmd_buf: used by the write_reg * @cmd_ext_type: the command opcode extension for DTR mode. * @fixups: flash-specific fixup hooks. @@ -546,6 +548,9 @@ struct spi_nor { enum spi_nor_protocol read_proto; enum spi_nor_protocol write_proto; enum spi_nor_protocol reg_proto; +#ifdef CONFIG_SPI_FLASH_SOFT_RESET + enum spi_nor_protocol reset_proto; +#endif bool sst_write_second; u32 flags; u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE];
XTX25F32B does not use octal mode and accepts soft reset, despite its SFDP tables. Soft reset at U-Boot exit seems to be required to write to /dev/mtd0 from flashrom in linux. Soft reset at U-Boot start seems to help booting from SPI (at least with the dts properties I'm using). The first soft reset is done before the flash id is read and the fixups can be called, and v1 of this patch would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. This was since commit 5752d6ae8daa ("spi: spi-mem: add spi_mem_dtr_supports_op()") by Pratyush Yadav. So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there. Changed since v2: - none (rebase) Changed since v1: - Generalization. First soft reset with SNOR_PROTO_8_8_8_DTR stopped working since the improvement by Pratyush Yadav. Instead of trying 8_8_8_DTR always at first reset, and force 1_1_1 once XTX25F32B is detected (so, for last reset) do a generic loop for any chip trying protocols until one is supported and starting by the 8_8_8_DTR protocol (the one previously used). This leverages the fixed supports_op() to take into account controller and device. fixups can be called, and it would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there. Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi/spi-nor-core.c | 98 ++++++++++++++++++++++++++++++---- include/linux/mtd/spi-nor.h | 5 ++ 2 files changed, 92 insertions(+), 11 deletions(-)