[PATCH v11 00/10] spi: Add support for stacked/parallel memories
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support.
The first nine patches https://lore.kernel.org/all/20230119185342.2093323-1-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-2-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-3-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-4-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-5-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-6-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-7-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-8-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-9-amit.kumar-mahapatra@am... of the previous series got applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next But the rest of the patches in the series did not get applied as failure was reported for spi driver with GPIO CS, so send the remaining patches in the series after rebasing it on top of for-next branch and fixing the issue.
CS GPIO is not tested on our hardware, but it has been tested by @Stefan https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirru... --- BRANCH: for-next
Changes in v11: - Rebased patch series on top of latest for-next branch. - Added a new patch(1/10) to replace spi->chip_select with spi_get_chipselect() call in tps6594-spi.c. - Added a new patch(2/10) to replace spi->chip_select with spi_get_chipseletc() call in cs35l56_hda_spi.c. - In spi.c initialized unused CS[] to 0xff and spi->cs_index_mask to 0x01 in all flows. - Updated spi_dev_check() to compare the CS of old spi device with the new spi device CS. - Updated cover letter description to add information regarding GPIO CS testing and added Stefen's Tested-by tag in 3/10 patch.
Changes in v10: - Rebased patch series on top of latest for-next branch and fixed merge conflicts.
Changes in v9: - Updated 1/8 patch description to add an high-level overview of parallel(multi-cs) & stacked design. - Initialized all unused CS to 0xFF. - Moved CS check from spi_add_device() to __spi_add_device(). - Updated __spi_add_device() to check to make sure that multiple logical CS don't map to the same physical CS and same physical CS doesn't map to different logical CS. - Updated 1/8, 5/8 & 7/8 to support arbitrary number of flash devices connected in parallel or stacked mode. - Updated documentation for chip_select. - Added a new spi-nor structure member nor->num_flash to keep track of the number of flashes connected. - Added a new patch in the series 4/8 to move write_enable call just before spi_mem ops call in SPI-NOR. - Added comments in SPI core & SPI-NOR. - Rebased the patch series on top of the latest for-next branch.
Changes in v8: - Updated __spi_add_device() and spi_set_cs() to fix spi driver failure with GPIO CS. - Rebased the patch series on top of latest for-next branch and fixed merge conflicts. - Updated cover letter description to add information regarding GPIO CS testing and request Stefan to provide his Tested-by tag for 1/7 patch. - Updated 1/7 patch description.
Changes in v7: - Updated spi_dev_check() to avoid failures for spi driver GPIO CS and moved the error message from __spi_add_device() to spi_dev_check(). - Resolved code indentation issue in spi_set_cs(). - In spi_set_cs() call spi_delay_exec( ) once if the controller supports multi cs with both the CS backed by GPIO. - Updated __spi_validate()to add checks for both the GPIO CS. - Replaced cs_index_mask bit mask with SPI_CS_CNT_MAX. - Updated struct spi_controller to represent multi CS capability of the spi controller through a flag bit SPI_CONTROLLER_MULTI_CS instead of a boolen structure member "multi_cs_cap". - Updated 1/7 patch description .
Changes in v6: - Rebased on top of latest v6.3-rc1 and fixed merge conflicts in spi-mpc512x-psc.c, sfdp.c, spansion.c files and removed spi-omap-100k.c. - Updated spi_dev_check( ) to reject new devices if any one of the chipselect is used by another device.
Changes in v5: - Rebased the patches on top of v6.3-rc1 and fixed the merge conflicts. - Fixed compilation warnings in spi-sh-msiof.c with shmobile_defconfig
Changes in v4: - Fixed build error in spi-pl022.c file - reported by Mark. - Fixed build error in spi-sn-f-ospi.c file. - Added Reviewed-by: Serge Semin fancer.lancer@gmail.com tag. - Added two more patches to replace spi->chip_select with API calls in mpc832x_rdb.c & cs35l41_hda_spi.c files.
Changes in v3: - Rebased the patches on top of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next - Added a patch to convert spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros into inline functions - Added Reviewed-by & Acked-by tags
Changes in v2: - Rebased the patches on top of v6.2-rc1 - Created separate patch to add get & set APIs for spi->chip_select & spi->cs_gpiod, and replaced all spi->chip_select and spi->cs_gpiod references with the API calls. - Created separate patch to add get & set APIs for nor->params. --- Amit Kumar Mahapatra (10): mfd: tps6594: Use set/get APIs to access spi->chip_select ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select spi: Add multi-cs memories support in SPI core mtd: spi-nor: Convert macros with inline functions mtd: spi-nor: Add APIs to set/get nor->params mtd: spi-nor: Move write enable inside specific write & erase APIs mtd: spi-nor: Add stacked memories support in spi-nor spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver mtd: spi-nor: Add parallel memories support in spi-nor spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver
drivers/mfd/tps6594-spi.c | 2 +- drivers/mtd/spi-nor/atmel.c | 17 +- drivers/mtd/spi-nor/core.c | 683 +++++++++++++++++++++++++------ drivers/mtd/spi-nor/core.h | 8 + drivers/mtd/spi-nor/debugfs.c | 4 +- drivers/mtd/spi-nor/gigadevice.c | 4 +- drivers/mtd/spi-nor/issi.c | 11 +- drivers/mtd/spi-nor/macronix.c | 10 +- drivers/mtd/spi-nor/micron-st.c | 35 +- drivers/mtd/spi-nor/otp.c | 48 ++- drivers/mtd/spi-nor/sfdp.c | 33 +- drivers/mtd/spi-nor/spansion.c | 57 +-- drivers/mtd/spi-nor/sst.c | 7 +- drivers/mtd/spi-nor/swp.c | 25 +- drivers/mtd/spi-nor/winbond.c | 2 +- drivers/mtd/spi-nor/xilinx.c | 18 +- drivers/spi/spi-zynqmp-gqspi.c | 58 ++- drivers/spi/spi.c | 259 ++++++++++-- include/linux/mtd/spi-nor.h | 21 +- include/linux/spi/spi.h | 51 ++- sound/pci/hda/cs35l56_hda_spi.c | 2 +- 21 files changed, 1085 insertions(+), 270 deletions(-)
In preparation for adding multiple CS support for a device, set/get functions were introduces accessing spi->chip_select in 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod")'. Replace spi->chip_select with spi_get_chipselect() API.
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/mfd/tps6594-spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/tps6594-spi.c b/drivers/mfd/tps6594-spi.c index f4b4f37f957f..24b72847e3f5 100644 --- a/drivers/mfd/tps6594-spi.c +++ b/drivers/mfd/tps6594-spi.c @@ -98,7 +98,7 @@ static int tps6594_spi_probe(struct spi_device *spi) spi_set_drvdata(spi, tps);
tps->dev = dev; - tps->reg = spi->chip_select; + tps->reg = spi_get_chipselect(spi, 0); tps->irq = spi->irq;
tps->regmap = devm_regmap_init(dev, NULL, spi, &tps6594_spi_regmap_config);
On Sat, 25 Nov 2023 14:51:28 +0530, Amit Kumar Mahapatra wrote:
In preparation for adding multiple CS support for a device, set/get functions were introduces accessing spi->chip_select in 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod")'. Replace spi->chip_select with spi_get_chipselect() API.
[...]
Applied, thanks!
[01/10] mfd: tps6594: Use set/get APIs to access spi->chip_select commit: dd636638446c87c95c5beddcd367d95ac6764c6c
-- Lee Jones [李琼斯]
On Fri, Dec 01, 2023 at 09:57:36AM +0000, Lee Jones wrote:
On Sat, 25 Nov 2023 14:51:28 +0530, Amit Kumar Mahapatra wrote:
In preparation for adding multiple CS support for a device, set/get functions were introduces accessing spi->chip_select in 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod")'. Replace spi->chip_select with spi_get_chipselect() API.
Applied, thanks!
[01/10] mfd: tps6594: Use set/get APIs to access spi->chip_select commit: dd636638446c87c95c5beddcd367d95ac6764c6c
Is there a signed tag available for this - without this change the subsequent SPI changes introduce a build breakage.
On Fri, 01 Dec 2023, Mark Brown wrote:
On Fri, Dec 01, 2023 at 09:57:36AM +0000, Lee Jones wrote:
On Sat, 25 Nov 2023 14:51:28 +0530, Amit Kumar Mahapatra wrote:
In preparation for adding multiple CS support for a device, set/get functions were introduces accessing spi->chip_select in 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod")'. Replace spi->chip_select with spi_get_chipselect() API.
Applied, thanks!
[01/10] mfd: tps6594: Use set/get APIs to access spi->chip_select commit: dd636638446c87c95c5beddcd367d95ac6764c6c
Is there a signed tag available for this - without this change the subsequent SPI changes introduce a build breakage.
Not yet, but I can get around to making one.
Good afternoon Mark,
Is there a signed tag available for this - without this change the subsequent SPI changes introduce a build breakage.
The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-spi-v6.8
for you to fetch changes up to 4ae08845db4c1f759b8382bc7527ab8249230e7f:
mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select (2023-12-07 13:36:29 +0000)
---------------------------------------------------------------- Immutable branch between MFD and SPI due for the v6.8 merge window
---------------------------------------------------------------- Amit Kumar Mahapatra (1): mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select
drivers/mfd/tps6594-spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, Dec 07, 2023 at 01:38:49PM +0000, Lee Jones wrote:
Good afternoon Mark,
Is there a signed tag available for this - without this change the subsequent SPI changes introduce a build breakage.
The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-spi-v6.8
for you to fetch changes up to 4ae08845db4c1f759b8382bc7527ab8249230e7f:
mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select (2023-12-07 13:36:29 +0000)
Thanks!
In preparation for adding multiple CS support for a device, set/get functions were introduces accessing spi->chip_select in 'commit 303feb3cc06a ("spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod")'. Replace spi->chip_select with spi_get_chipselect() API.
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- sound/pci/hda/cs35l56_hda_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/cs35l56_hda_spi.c b/sound/pci/hda/cs35l56_hda_spi.c index 756aec342eab..1c5cb3b1e2c3 100644 --- a/sound/pci/hda/cs35l56_hda_spi.c +++ b/sound/pci/hda/cs35l56_hda_spi.c @@ -29,7 +29,7 @@ static int cs35l56_hda_spi_probe(struct spi_device *spi) return ret; }
- ret = cs35l56_hda_common_probe(cs35l56, spi->chip_select); + ret = cs35l56_hda_common_probe(cs35l56, spi_get_chipselect(spi, 0)); if (ret) return ret; ret = cs35l56_irq_request(&cs35l56->base, spi->irq);
In further patches the nor->params references in spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros will be replaced with spi_nor_get_params() API. To make the transition smoother, first converting the macros into static inline functions.
Suggested-by: Michal Simek michal.simek@amd.com Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/mtd/spi-nor/otp.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c index 9a729aa3452d..23fe75ddc9cf 100644 --- a/drivers/mtd/spi-nor/otp.c +++ b/drivers/mtd/spi-nor/otp.c @@ -11,8 +11,27 @@
#include "core.h"
-#define spi_nor_otp_region_len(nor) ((nor)->params->otp.org->len) -#define spi_nor_otp_n_regions(nor) ((nor)->params->otp.org->n_regions) +/** + * spi_nor_otp_region_len() - get size of one OTP region in bytes + * @nor: pointer to 'struct spi_nor' + * + * Return: size of one OTP region in bytes + */ +static inline unsigned int spi_nor_otp_region_len(struct spi_nor *nor) +{ + return nor->params->otp.org->len; +} + +/** + * spi_nor_otp_n_regions() - get number of individual OTP regions + * @nor: pointer to 'struct spi_nor' + * + * Return: number of individual OTP regions + */ +static inline unsigned int spi_nor_otp_n_regions(struct spi_nor *nor) +{ + return nor->params->otp.org->n_regions; +}
/** * spi_nor_otp_read_secr() - read security register
AMD-Xilinx GQSPI controller has two advanced mode that allows the controller to consider two flashes as one single device.
One of these two mode is the parallel mode in which each byte of data is stored in both devices, the even bits in the lower flash & the odd bits in the upper flash. The byte split is automatically handled by the QSPI controller.
The other mode is the stacked mode in which both the flashes share the same SPI bus but each of the device contain half of the data. In this mode, the controller does not follow CS requests but instead internally wires the two CS levels with the value of the most significant address bit.
For supporting both these modes SPI core need to be updated for providing multiple CS for a single SPI device.
For adding multi CS support the SPI device need to be aware of all the CS values. So, the "chip_select" member in the spi_device structure is now an array that holds all the CS values.
spi_device structure now has a "cs_index_mask" member. This acts as an index to the chip_select array. If nth bit of spi->cs_index_mask is set then the driver would assert spi->chip_select[n].
In parallel mode all the chip selects are asserted/de-asserted simultaneously and each byte of data is stored in both devices, the even bits in one, the odd bits in the other. The split is automatically handled by the GQSPI controller. The GQSPI controller supports a maximum of two flashes connected in parallel mode. A SPI_CONTROLLER_MULTI_CS flag bit is added in the spi controller flags, through ctlr->flags the spi core will make sure that the controller is capable of handling multiple chip selects at once.
For supporting multiple CS via GPIO the cs_gpiod member of the spi_device structure is now an array that holds the gpio descriptor for each chipselect.
CS GPIO is not tested on our hardware, but it has been tested by @Stefan https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirru...
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com Tested-by: Stefan Binding sbinding@opensource.cirrus.com --- drivers/spi/spi.c | 259 +++++++++++++++++++++++++++++++++------- include/linux/spi/spi.h | 51 ++++++-- 2 files changed, 258 insertions(+), 52 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 8ead7acb99f3..45b6898cf0ee 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -612,10 +612,21 @@ static int spi_dev_check(struct device *dev, void *data) { struct spi_device *spi = to_spi_device(dev); struct spi_device *new_spi = data; - - if (spi->controller == new_spi->controller && - spi_get_chipselect(spi, 0) == spi_get_chipselect(new_spi, 0)) - return -EBUSY; + int idx, nw_idx; + u8 cs, cs_nw; + + if (spi->controller == new_spi->controller) { + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + cs = spi_get_chipselect(spi, idx); + for (nw_idx = 0; nw_idx < SPI_CS_CNT_MAX; nw_idx++) { + cs_nw = spi_get_chipselect(new_spi, nw_idx); + if (cs != 0xFF && cs_nw != 0xFF && cs == cs_nw) { + dev_err(dev, "chipselect %d already in use\n", cs_nw); + return -EBUSY; + } + } + } + } return 0; }
@@ -629,13 +640,32 @@ static int __spi_add_device(struct spi_device *spi) { struct spi_controller *ctlr = spi->controller; struct device *dev = ctlr->dev.parent; - int status; + int status, idx, nw_idx; + u8 cs, nw_cs; + + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + /* Chipselects are numbered 0..max; validate. */ + cs = spi_get_chipselect(spi, idx); + if (cs != 0xFF && cs >= ctlr->num_chipselect) { + dev_err(dev, "cs%d >= max %d\n", spi_get_chipselect(spi, idx), + ctlr->num_chipselect); + return -EINVAL; + } + }
- /* Chipselects are numbered 0..max; validate. */ - if (spi_get_chipselect(spi, 0) >= ctlr->num_chipselect) { - dev_err(dev, "cs%d >= max %d\n", spi_get_chipselect(spi, 0), - ctlr->num_chipselect); - return -EINVAL; + /* + * Make sure that multiple logical CS doesn't map to the same physical CS. + * For example, spi->chip_select[0] != spi->chip_select[1] and so on. + */ + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + cs = spi_get_chipselect(spi, idx); + for (nw_idx = idx + 1; nw_idx < SPI_CS_CNT_MAX; nw_idx++) { + nw_cs = spi_get_chipselect(spi, nw_idx); + if (cs != 0xFF && nw_cs != 0xFF && cs == nw_cs) { + dev_err(dev, "chipselect %d already in use\n", nw_cs); + return -EBUSY; + } + } }
/* Set the bus ID string */ @@ -647,11 +677,8 @@ static int __spi_add_device(struct spi_device *spi) * its configuration. */ status = bus_for_each_dev(&spi_bus_type, NULL, spi, spi_dev_check); - if (status) { - dev_err(dev, "chipselect %d already in use\n", - spi_get_chipselect(spi, 0)); + if (status) return status; - }
/* Controller may unregister concurrently */ if (IS_ENABLED(CONFIG_SPI_DYNAMIC) && @@ -659,8 +686,15 @@ static int __spi_add_device(struct spi_device *spi) return -ENODEV; }
- if (ctlr->cs_gpiods) - spi_set_csgpiod(spi, 0, ctlr->cs_gpiods[spi_get_chipselect(spi, 0)]); + if (ctlr->cs_gpiods) { + u8 cs; + + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + cs = spi_get_chipselect(spi, idx); + if (cs != 0xFF) + spi_set_csgpiod(spi, idx, ctlr->cs_gpiods[cs]); + } + }
/* * Drivers may modify this initial i/o setup, but will @@ -701,6 +735,9 @@ int spi_add_device(struct spi_device *spi) struct spi_controller *ctlr = spi->controller; int status;
+ /* Set the bus ID string */ + spi_dev_set_name(spi); + mutex_lock(&ctlr->add_lock); status = __spi_add_device(spi); mutex_unlock(&ctlr->add_lock); @@ -727,6 +764,7 @@ struct spi_device *spi_new_device(struct spi_controller *ctlr, { struct spi_device *proxy; int status; + u8 idx;
/* * NOTE: caller did any chip->bus_num checks necessary. @@ -742,6 +780,18 @@ struct spi_device *spi_new_device(struct spi_controller *ctlr,
WARN_ON(strlen(chip->modalias) >= sizeof(proxy->modalias));
+ /* + * Zero(0) is a valid physical CS value and can be located at any + * logical CS in the spi->chip_select[]. If all the physical CS + * are initialized to 0 then It would be difficult to differentiate + * between a valid physical CS 0 & an unused logical CS whose physical + * CS can be 0. As a solution to this issue initialize all the CS to 0xFF. + * Now all the unused logical CS will have 0xFF physical CS value & can be + * ignore while performing physical CS validity checks. + */ + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) + spi_set_chipselect(proxy, idx, 0xFF); + spi_set_chipselect(proxy, 0, chip->chip_select); proxy->max_speed_hz = chip->max_speed_hz; proxy->mode = chip->mode; @@ -750,6 +800,15 @@ struct spi_device *spi_new_device(struct spi_controller *ctlr, proxy->dev.platform_data = (void *) chip->platform_data; proxy->controller_data = chip->controller_data; proxy->controller_state = NULL; + /* + * spi->chip_select[i] gives the corresponding physical CS for logical CS i + * logical CS number is represented by setting the ith bit in spi->cs_index_mask + * So, for example, if spi->cs_index_mask = 0x01 then logical CS number is 0 and + * spi->chip_select[0] will give the physical CS. + * By default spi->chip_select[0] will hold the physical CS number so, set + * spi->cs_index_mask as 0x01. + */ + proxy->cs_index_mask = 0x01;
if (chip->swnode) { status = device_add_software_node(&proxy->dev, chip->swnode); @@ -942,32 +1001,51 @@ static void spi_res_release(struct spi_controller *ctlr, struct spi_message *mes }
/*-------------------------------------------------------------------------*/ +static inline bool spi_is_last_cs(struct spi_device *spi) +{ + u8 idx; + bool last = false; + + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + if ((spi->cs_index_mask >> idx) & 0x01) { + if (spi->controller->last_cs[idx] == spi_get_chipselect(spi, idx)) + last = true; + } + } + return last; +} +
static void spi_set_cs(struct spi_device *spi, bool enable, bool force) { bool activate = enable; + u8 idx;
/* * Avoid calling into the driver (or doing delays) if the chip select * isn't actually changing from the last time this was called. */ - if (!force && ((enable && spi->controller->last_cs == spi_get_chipselect(spi, 0)) || - (!enable && spi->controller->last_cs != spi_get_chipselect(spi, 0))) && + if (!force && ((enable && spi->controller->last_cs_index_mask == spi->cs_index_mask && + spi_is_last_cs(spi)) || + (!enable && spi->controller->last_cs_index_mask == spi->cs_index_mask && + !spi_is_last_cs(spi))) && (spi->controller->last_cs_mode_high == (spi->mode & SPI_CS_HIGH))) return;
trace_spi_set_cs(spi, activate);
- spi->controller->last_cs = enable ? spi_get_chipselect(spi, 0) : -1; + spi->controller->last_cs_index_mask = spi->cs_index_mask; + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) + spi->controller->last_cs[idx] = enable ? spi_get_chipselect(spi, 0) : -1; spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;
- if ((spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) && !activate) - spi_delay_exec(&spi->cs_hold, NULL); - if (spi->mode & SPI_CS_HIGH) enable = !enable;
- if (spi_get_csgpiod(spi, 0)) { + if (spi_is_csgpiod(spi)) { + if (!spi->controller->set_cs_timing && !activate) + spi_delay_exec(&spi->cs_hold, NULL); + if (!(spi->mode & SPI_NO_CS)) { /* * Historically ACPI has no means of the GPIO polarity and @@ -979,26 +1057,38 @@ static void spi_set_cs(struct spi_device *spi, bool enable, bool force) * ambiguity. That's why we use enable, that takes SPI_CS_HIGH * into account. */ - if (has_acpi_companion(&spi->dev)) - gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), !enable); - else - /* Polarity handled by GPIO library */ - gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), activate); + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + if (((spi->cs_index_mask >> idx) & 0x01) && + spi_get_csgpiod(spi, idx)) { + if (has_acpi_companion(&spi->dev)) + gpiod_set_value_cansleep(spi_get_csgpiod(spi, idx), + !enable); + else + /* Polarity handled by GPIO library */ + gpiod_set_value_cansleep(spi_get_csgpiod(spi, idx), + activate); + + if (activate) + spi_delay_exec(&spi->cs_setup, NULL); + else + spi_delay_exec(&spi->cs_inactive, NULL); + } + } } /* Some SPI masters need both GPIO CS & slave_select */ if ((spi->controller->flags & SPI_CONTROLLER_GPIO_SS) && spi->controller->set_cs) spi->controller->set_cs(spi, !enable); + + if (!spi->controller->set_cs_timing) { + if (activate) + spi_delay_exec(&spi->cs_setup, NULL); + else + spi_delay_exec(&spi->cs_inactive, NULL); + } } else if (spi->controller->set_cs) { spi->controller->set_cs(spi, !enable); } - - if (spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) { - if (activate) - spi_delay_exec(&spi->cs_setup, NULL); - else - spi_delay_exec(&spi->cs_inactive, NULL); - } }
#ifdef CONFIG_HAS_DMA @@ -2222,8 +2312,8 @@ static void of_spi_parse_dt_cs_delay(struct device_node *nc, static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi, struct device_node *nc) { - u32 value; - int rc; + u32 value, cs[SPI_CS_CNT_MAX]; + int rc, idx;
/* Mode (clock phase/polarity/etc.) */ if (of_property_read_bool(nc, "spi-cpha")) @@ -2295,14 +2385,53 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi, return 0; }
+ if (ctlr->num_chipselect > SPI_CS_CNT_MAX) { + dev_err(&ctlr->dev, "No. of CS is more than max. no. of supported CS\n"); + return -EINVAL; + } + + /* + * Zero(0) is a valid physical CS value and can be located at any + * logical CS in the spi->chip_select[]. If all the physical CS + * are initialized to 0 then It would be difficult to differentiate + * between a valid physical CS 0 & an unused logical CS whose physical + * CS can be 0. As a solution to this issue initialize all the CS to 0xFF. + * Now all the unused logical CS will have 0xFF physical CS value & can be + * ignore while performing physical CS validity checks. + */ + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) + spi_set_chipselect(spi, idx, 0xFF); + /* Device address */ - rc = of_property_read_u32(nc, "reg", &value); - if (rc) { + rc = of_property_read_variable_u32_array(nc, "reg", &cs[0], 1, + SPI_CS_CNT_MAX); + if (rc < 0) { dev_err(&ctlr->dev, "%pOF has no valid 'reg' property (%d)\n", nc, rc); return rc; } - spi_set_chipselect(spi, 0, value); + if (rc > ctlr->num_chipselect) { + dev_err(&ctlr->dev, "%pOF has number of CS > ctlr->num_chipselect (%d)\n", + nc, rc); + return rc; + } + if ((of_property_read_bool(nc, "parallel-memories")) && + (!(ctlr->flags & SPI_CONTROLLER_MULTI_CS))) { + dev_err(&ctlr->dev, "SPI controller doesn't support multi CS\n"); + return -EINVAL; + } + for (idx = 0; idx < rc; idx++) + spi_set_chipselect(spi, idx, cs[idx]); + + /* + * spi->chip_select[i] gives the corresponding physical CS for logical CS i + * logical CS number is represented by setting the ith bit in spi->cs_index_mask + * So, for example, if spi->cs_index_mask = 0x01 then logical CS number is 0 and + * spi->chip_select[0] will give the physical CS. + * By default spi->chip_select[0] will hold the physical CS number so, set + * spi->cs_index_mask as 0x01. + */ + spi->cs_index_mask = 0x01;
/* Device speed */ if (!of_property_read_u32(nc, "spi-max-frequency", &value)) @@ -2408,6 +2537,7 @@ struct spi_device *spi_new_ancillary_device(struct spi_device *spi, struct spi_controller *ctlr = spi->controller; struct spi_device *ancillary; int rc = 0; + u8 idx;
/* Alloc an spi_device */ ancillary = spi_alloc_device(ctlr); @@ -2418,12 +2548,33 @@ struct spi_device *spi_new_ancillary_device(struct spi_device *spi,
strscpy(ancillary->modalias, "dummy", sizeof(ancillary->modalias));
+ /* + * Zero(0) is a valid physical CS value and can be located at any + * logical CS in the spi->chip_select[]. If all the physical CS + * are initialized to 0 then It would be difficult to differentiate + * between a valid physical CS 0 & an unused logical CS whose physical + * CS can be 0. As a solution to this issue initialize all the CS to 0xFF. + * Now all the unused logical CS will have 0xFF physical CS value & can be + * ignore while performing physical CS validity checks. + */ + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) + spi_set_chipselect(ancillary, idx, 0xFF); + /* Use provided chip-select for ancillary device */ spi_set_chipselect(ancillary, 0, chip_select);
/* Take over SPI mode/speed from SPI main device */ ancillary->max_speed_hz = spi->max_speed_hz; ancillary->mode = spi->mode; + /* + * spi->chip_select[i] gives the corresponding physical CS for logical CS i + * logical CS number is represented by setting the ith bit in spi->cs_index_mask + * So, for example, if spi->cs_index_mask = 0x01 then logical CS number is 0 and + * spi->chip_select[0] will give the physical CS. + * By default spi->chip_select[0] will hold the physical CS number so, set + * spi->cs_index_mask as 0x01. + */ + ancillary->cs_index_mask = 0x01;
WARN_ON(!mutex_is_locked(&ctlr->add_lock));
@@ -2626,6 +2777,7 @@ struct spi_device *acpi_spi_device_alloc(struct spi_controller *ctlr, struct acpi_spi_lookup lookup = {}; struct spi_device *spi; int ret; + u8 idx;
if (!ctlr && index == -1) return ERR_PTR(-EINVAL); @@ -2661,12 +2813,33 @@ struct spi_device *acpi_spi_device_alloc(struct spi_controller *ctlr, return ERR_PTR(-ENOMEM); }
+ /* + * Zero(0) is a valid physical CS value and can be located at any + * logical CS in the spi->chip_select[]. If all the physical CS + * are initialized to 0 then It would be difficult to differentiate + * between a valid physical CS 0 & an unused logical CS whose physical + * CS can be 0. As a solution to this issue initialize all the CS to 0xFF. + * Now all the unused logical CS will have 0xFF physical CS value & can be + * ignore while performing physical CS validity checks. + */ + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) + spi_set_chipselect(spi, idx, 0xFF); + ACPI_COMPANION_SET(&spi->dev, adev); spi->max_speed_hz = lookup.max_speed_hz; spi->mode |= lookup.mode; spi->irq = lookup.irq; spi->bits_per_word = lookup.bits_per_word; spi_set_chipselect(spi, 0, lookup.chip_select); + /* + * spi->chip_select[i] gives the corresponding physical CS for logical CS i + * logical CS number is represented by setting the ith bit in spi->cs_index_mask + * So, for example, if spi->cs_index_mask = 0x01 then logical CS number is 0 and + * spi->chip_select[0] will give the physical CS. + * By default spi->chip_select[0] will hold the physical CS number so, set + * spi->cs_index_mask as 0x01. + */ + spi->cs_index_mask = 0x01;
return spi; } @@ -3100,6 +3273,7 @@ int spi_register_controller(struct spi_controller *ctlr) struct boardinfo *bi; int first_dynamic; int status; + int idx;
if (!dev) return -ENODEV; @@ -3164,7 +3338,8 @@ int spi_register_controller(struct spi_controller *ctlr) }
/* Setting last_cs to -1 means no chip selected */ - ctlr->last_cs = -1; + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) + ctlr->last_cs[idx] = -1;
status = device_add(&ctlr->dev); if (status < 0) @@ -3889,7 +4064,7 @@ static int __spi_validate(struct spi_device *spi, struct spi_message *message) * cs_change is set for each transfer. */ if ((spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || - spi_get_csgpiod(spi, 0))) { + spi_is_csgpiod(spi))) { size_t maxsize = BITS_TO_BYTES(spi->bits_per_word); int ret;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 7b4baff63c5c..871d3a6d879b 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -20,6 +20,9 @@
#include <uapi/linux/spi/spi.h>
+/* Max no. of CS supported per spi device */ +#define SPI_CS_CNT_MAX 4 + struct dma_chan; struct software_node; struct ptp_system_timestamp; @@ -132,7 +135,8 @@ extern void spi_transfer_cs_change_delay_exec(struct spi_message *msg, * @max_speed_hz: Maximum clock rate to be used with this chip * (on this board); may be changed by the device's driver. * The spi_transfer.speed_hz can override this for each transfer. - * @chip_select: Chipselect, distinguishing chips handled by @controller. + * @chip_select: Array of physical chipselect, spi->chipselect[i] gives + * the corresponding physical CS for logical CS i. * @mode: The spi mode defines how data is clocked out and in. * This may be changed by the device's driver. * The "active low" default for chipselect mode can be overridden @@ -157,8 +161,8 @@ extern void spi_transfer_cs_change_delay_exec(struct spi_message *msg, * the device will bind to the named driver and only the named driver. * Do not set directly, because core frees it; use driver_set_override() to * set or clear it. - * @cs_gpiod: GPIO descriptor of the chipselect line (optional, NULL when - * not using a GPIO line) + * @cs_gpiod: Array of GPIO descriptors of the corresponding chipselect lines + * (optional, NULL when not using a GPIO line) * @word_delay: delay to be inserted between consecutive * words of a transfer * @cs_setup: delay to be introduced by the controller after CS is asserted @@ -167,6 +171,7 @@ extern void spi_transfer_cs_change_delay_exec(struct spi_message *msg, * deasserted. If @cs_change_delay is used from @spi_transfer, then the * two delays will be added up. * @pcpu_statistics: statistics for the spi_device + * @cs_index_mask: Bit mask of the active chipselect(s) in the chipselect array * * A @spi_device is used to interchange data between an SPI slave * (usually a discrete chip) and CPU memory. @@ -182,7 +187,7 @@ struct spi_device { struct spi_controller *controller; struct spi_controller *master; /* Compatibility layer */ u32 max_speed_hz; - u8 chip_select; + u8 chip_select[SPI_CS_CNT_MAX]; u8 bits_per_word; bool rt; #define SPI_NO_TX BIT(31) /* No transmit wire */ @@ -213,7 +218,7 @@ struct spi_device { void *controller_data; char modalias[SPI_NAME_SIZE]; const char *driver_override; - struct gpio_desc *cs_gpiod; /* Chip select GPIO descriptor */ + struct gpio_desc *cs_gpiod[SPI_CS_CNT_MAX]; /* Chip select gpio desc */ struct spi_delay word_delay; /* Inter-word delay */ /* CS delays */ struct spi_delay cs_setup; @@ -223,6 +228,13 @@ struct spi_device { /* The statistics */ struct spi_statistics __percpu *pcpu_statistics;
+ /* Bit mask of the chipselect(s) that the driver need to use from + * the chipselect array.When the controller is capable to handle + * multiple chip selects & memories are connected in parallel + * then more than one bit need to be set in cs_index_mask. + */ + u32 cs_index_mask : SPI_CS_CNT_MAX; + /* * Likely need more hooks for more protocol options affecting how * the controller talks to each chip, like: @@ -279,22 +291,33 @@ static inline void *spi_get_drvdata(const struct spi_device *spi)
static inline u8 spi_get_chipselect(const struct spi_device *spi, u8 idx) { - return spi->chip_select; + return spi->chip_select[idx]; }
static inline void spi_set_chipselect(struct spi_device *spi, u8 idx, u8 chipselect) { - spi->chip_select = chipselect; + spi->chip_select[idx] = chipselect; }
static inline struct gpio_desc *spi_get_csgpiod(const struct spi_device *spi, u8 idx) { - return spi->cs_gpiod; + return spi->cs_gpiod[idx]; }
static inline void spi_set_csgpiod(struct spi_device *spi, u8 idx, struct gpio_desc *csgpiod) { - spi->cs_gpiod = csgpiod; + spi->cs_gpiod[idx] = csgpiod; +} + +static inline bool spi_is_csgpiod(struct spi_device *spi) +{ + u8 idx; + + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) { + if (spi_get_csgpiod(spi, idx)) + return true; + } + return false; }
/** @@ -399,6 +422,8 @@ extern struct spi_device *spi_new_ancillary_device(struct spi_device *spi, u8 ch * @bus_lock_spinlock: spinlock for SPI bus locking * @bus_lock_mutex: mutex for exclusion of multiple callers * @bus_lock_flag: indicates that the SPI bus is locked for exclusive use + * @multi_cs_cap: indicates that the SPI Controller can assert/de-assert + * more than one chip select at once. * @setup: updates the device mode and clocking records used by a * device's SPI controller; protocol code may call this. This * must fail if an unrecognized or unsupported mode is requested. @@ -567,6 +592,11 @@ struct spi_controller { #define SPI_CONTROLLER_MUST_TX BIT(4) /* Requires tx */ #define SPI_CONTROLLER_GPIO_SS BIT(5) /* GPIO CS must select slave */ #define SPI_CONTROLLER_SUSPENDED BIT(6) /* Currently suspended */ + /* + * The spi-controller has multi chip select capability and can + * assert/de-assert more than one chip select at once. + */ +#define SPI_CONTROLLER_MULTI_CS BIT(7)
/* Flag indicating if the allocation of this struct is devres-managed */ bool devm_allocated; @@ -677,7 +707,8 @@ struct spi_controller { bool rt; bool auto_runtime_pm; bool cur_msg_mapped; - char last_cs; + char last_cs[SPI_CS_CNT_MAX]; + char last_cs_index_mask; bool last_cs_mode_high; bool fallback; struct completion xfer_completion;
Hi,
On Sat, Nov 25, 2023 at 02:51:30PM +0530, Amit Kumar Mahapatra wrote:
AMD-Xilinx GQSPI controller has two advanced mode that allows the controller to consider two flashes as one single device.
One of these two mode is the parallel mode in which each byte of data is stored in both devices, the even bits in the lower flash & the odd bits in the upper flash. The byte split is automatically handled by the QSPI controller.
The other mode is the stacked mode in which both the flashes share the same SPI bus but each of the device contain half of the data. In this mode, the controller does not follow CS requests but instead internally wires the two CS levels with the value of the most significant address bit.
For supporting both these modes SPI core need to be updated for providing multiple CS for a single SPI device.
For adding multi CS support the SPI device need to be aware of all the CS values. So, the "chip_select" member in the spi_device structure is now an array that holds all the CS values.
spi_device structure now has a "cs_index_mask" member. This acts as an index to the chip_select array. If nth bit of spi->cs_index_mask is set then the driver would assert spi->chip_select[n].
In parallel mode all the chip selects are asserted/de-asserted simultaneously and each byte of data is stored in both devices, the even bits in one, the odd bits in the other. The split is automatically handled by the GQSPI controller. The GQSPI controller supports a maximum of two flashes connected in parallel mode. A SPI_CONTROLLER_MULTI_CS flag bit is added in the spi controller flags, through ctlr->flags the spi core will make sure that the controller is capable of handling multiple chip selects at once.
For supporting multiple CS via GPIO the cs_gpiod member of the spi_device structure is now an array that holds the gpio descriptor for each chipselect.
CS GPIO is not tested on our hardware, but it has been tested by @Stefan https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirru...
With this patch in the mainline kernel, two of my qemu emulations (quanta-q71l-bmc and almetto-bmc) fail to instantiate the first SPI controller and thus fail to boot from SPI. The error message is
[ 3.006458] spi_master spi0: No. of CS is more than max. no. of supported CS [ 3.006775] spi_master spi0: Failed to create SPI device for /ahb/spi@1e620000/flash@0
The problem is no longer seen after reverting this patch.
Bisect log attached for reference.
Guenter
--- # bad: [70d201a40823acba23899342d62bc2644051ad2e] Merge tag 'f2fs-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs # good: [0dd3ee31125508cd67f7e7172247f05b7fd1753a] Linux 6.7 git bisect start 'HEAD' 'v6.7' # bad: [de927f6c0b07d9e698416c5b287c521b07694cac] Merge tag 's390-6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect bad de927f6c0b07d9e698416c5b287c521b07694cac # bad: [35f11a3710cdcbbc5090d14017a6295454e0cc73] Merge tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux git bisect bad 35f11a3710cdcbbc5090d14017a6295454e0cc73 # good: [d30e51aa7b1f6fa7dd78d4598d1e4c047fcc3fb9] Merge tag 'slab-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab git bisect good d30e51aa7b1f6fa7dd78d4598d1e4c047fcc3fb9 # good: [fb46e22a9e3863e08aef8815df9f17d0f4b9aede] Merge tag 'mm-stable-2024-01-08-15-31' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm git bisect good fb46e22a9e3863e08aef8815df9f17d0f4b9aede # good: [063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac] Merge tag 'lsm-pr-20240105' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm git bisect good 063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac # bad: [f6cd66231aa58599526584ff4df1bdde8d86eac8] spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc git bisect bad f6cd66231aa58599526584ff4df1bdde8d86eac8 # good: [18f78b5e609b19b56237f0dae47068d44b8b0ecd] spi: axi-spi-engine: improvements round 2 git bisect good 18f78b5e609b19b56237f0dae47068d44b8b0ecd # bad: [9d93c8d97b4cdb5edddb4c5530881c90eecb7e44] spi: spi-ti-qspi: switch to use modern name git bisect bad 9d93c8d97b4cdb5edddb4c5530881c90eecb7e44 # bad: [e6b7e64cb11966b26646a362677ca5a08481157e] spi: st-ssc4: switch to use modern name git bisect bad e6b7e64cb11966b26646a362677ca5a08481157e # bad: [c3aeaf2f0ec8af93189488bda3928a1ac7752388] spi: pxa2xx: Use inclusive language git bisect bad c3aeaf2f0ec8af93189488bda3928a1ac7752388 # good: [f05e2f61fe88092e0d341ea27644a84e3386358d] ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select git bisect good f05e2f61fe88092e0d341ea27644a84e3386358d # bad: [88a50c1663ffa9f6b31705c6bf7a887a2c8d9434] spi: Add support for stacked/parallel memories git bisect bad 88a50c1663ffa9f6b31705c6bf7a887a2c8d9434 # bad: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core git bisect bad 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b # first bad commit: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core
On Fri, Jan 12, 2024 at 11:11:07AM -0800, Guenter Roeck wrote:
On Sat, Nov 25, 2023 at 02:51:30PM +0530, Amit Kumar Mahapatra wrote:
AMD-Xilinx GQSPI controller has two advanced mode that allows the controller to consider two flashes as one single device.
...
With this patch in the mainline kernel, two of my qemu emulations (quanta-q71l-bmc and almetto-bmc) fail to instantiate the first SPI controller and thus fail to boot from SPI. The error message is
Not sure what quanta-q711-bmc is - is almetto-bmc really palmetto-bmc (which has a mainline DT with a SPI flash)?
[ 3.006458] spi_master spi0: No. of CS is more than max. no. of supported CS [ 3.006775] spi_master spi0: Failed to create SPI device for /ahb/spi@1e620000/flash@0
The problem is no longer seen after reverting this patch.
Bisect log attached for reference.
Guenter
# bad: [70d201a40823acba23899342d62bc2644051ad2e] Merge tag 'f2fs-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs # good: [0dd3ee31125508cd67f7e7172247f05b7fd1753a] Linux 6.7 git bisect start 'HEAD' 'v6.7' # bad: [de927f6c0b07d9e698416c5b287c521b07694cac] Merge tag 's390-6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect bad de927f6c0b07d9e698416c5b287c521b07694cac # bad: [35f11a3710cdcbbc5090d14017a6295454e0cc73] Merge tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux git bisect bad 35f11a3710cdcbbc5090d14017a6295454e0cc73 # good: [d30e51aa7b1f6fa7dd78d4598d1e4c047fcc3fb9] Merge tag 'slab-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab git bisect good d30e51aa7b1f6fa7dd78d4598d1e4c047fcc3fb9 # good: [fb46e22a9e3863e08aef8815df9f17d0f4b9aede] Merge tag 'mm-stable-2024-01-08-15-31' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm git bisect good fb46e22a9e3863e08aef8815df9f17d0f4b9aede # good: [063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac] Merge tag 'lsm-pr-20240105' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm git bisect good 063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac # bad: [f6cd66231aa58599526584ff4df1bdde8d86eac8] spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc git bisect bad f6cd66231aa58599526584ff4df1bdde8d86eac8 # good: [18f78b5e609b19b56237f0dae47068d44b8b0ecd] spi: axi-spi-engine: improvements round 2 git bisect good 18f78b5e609b19b56237f0dae47068d44b8b0ecd # bad: [9d93c8d97b4cdb5edddb4c5530881c90eecb7e44] spi: spi-ti-qspi: switch to use modern name git bisect bad 9d93c8d97b4cdb5edddb4c5530881c90eecb7e44 # bad: [e6b7e64cb11966b26646a362677ca5a08481157e] spi: st-ssc4: switch to use modern name git bisect bad e6b7e64cb11966b26646a362677ca5a08481157e # bad: [c3aeaf2f0ec8af93189488bda3928a1ac7752388] spi: pxa2xx: Use inclusive language git bisect bad c3aeaf2f0ec8af93189488bda3928a1ac7752388 # good: [f05e2f61fe88092e0d341ea27644a84e3386358d] ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select git bisect good f05e2f61fe88092e0d341ea27644a84e3386358d # bad: [88a50c1663ffa9f6b31705c6bf7a887a2c8d9434] spi: Add support for stacked/parallel memories git bisect bad 88a50c1663ffa9f6b31705c6bf7a887a2c8d9434 # bad: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core git bisect bad 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b # first bad commit: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core
On 1/12/24 11:16, Mark Brown wrote:
On Fri, Jan 12, 2024 at 11:11:07AM -0800, Guenter Roeck wrote:
On Sat, Nov 25, 2023 at 02:51:30PM +0530, Amit Kumar Mahapatra wrote:
AMD-Xilinx GQSPI controller has two advanced mode that allows the controller to consider two flashes as one single device.
...
With this patch in the mainline kernel, two of my qemu emulations (quanta-q71l-bmc and almetto-bmc) fail to instantiate the first SPI controller and thus fail to boot from SPI. The error message is
Not sure what quanta-q711-bmc is - is almetto-bmc really palmetto-bmc (which has a mainline DT with a SPI flash)?
Yes, sorry, it should have been palmetto-bmc.
quanta-q71l-bmc: See arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-q71l.dts
(it is q71l, not q711)
Guenter
On Fri, Jan 12, 2024 at 11:11:10AM -0800, Guenter Roeck wrote:
Hi,
On Sat, Nov 25, 2023 at 02:51:30PM +0530, Amit Kumar Mahapatra wrote:
AMD-Xilinx GQSPI controller has two advanced mode that allows the controller to consider two flashes as one single device.
One of these two mode is the parallel mode in which each byte of data is stored in both devices, the even bits in the lower flash & the odd bits in the upper flash. The byte split is automatically handled by the QSPI controller.
The other mode is the stacked mode in which both the flashes share the same SPI bus but each of the device contain half of the data. In this mode, the controller does not follow CS requests but instead internally wires the two CS levels with the value of the most significant address bit.
For supporting both these modes SPI core need to be updated for providing multiple CS for a single SPI device.
For adding multi CS support the SPI device need to be aware of all the CS values. So, the "chip_select" member in the spi_device structure is now an array that holds all the CS values.
spi_device structure now has a "cs_index_mask" member. This acts as an index to the chip_select array. If nth bit of spi->cs_index_mask is set then the driver would assert spi->chip_select[n].
In parallel mode all the chip selects are asserted/de-asserted simultaneously and each byte of data is stored in both devices, the even bits in one, the odd bits in the other. The split is automatically handled by the GQSPI controller. The GQSPI controller supports a maximum of two flashes connected in parallel mode. A SPI_CONTROLLER_MULTI_CS flag bit is added in the spi controller flags, through ctlr->flags the spi core will make sure that the controller is capable of handling multiple chip selects at once.
For supporting multiple CS via GPIO the cs_gpiod member of the spi_device structure is now an array that holds the gpio descriptor for each chipselect.
CS GPIO is not tested on our hardware, but it has been tested by @Stefan https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirru...
With this patch in the mainline kernel, two of my qemu emulations (quanta-q71l-bmc and almetto-bmc) fail to instantiate the first SPI controller and thus fail to boot from SPI. The error message is
[ 3.006458] spi_master spi0: No. of CS is more than max. no. of supported CS [ 3.006775] spi_master spi0: Failed to create SPI device for /ahb/spi@1e620000/flash@0
The problem is no longer seen after reverting this patch.
FWIW, the problem is due to
+#define SPI_CS_CNT_MAX 4
in the offending patch, but apeed2400 FMC supports up to 5 SPI chip selects.
static const struct aspeed_spi_data ast2400_fmc_data = { .max_cs = 5, ^^^^^^^^^^^^^^^^^^^ .hastype = true,
Limiting .max_cs to 4 or increasing SPI_CS_CNT_MAX to 5 fixes the problem, though of course I don't know if increasing SPI_CS_CNT_MAX has other side effects.
Guenter
Bisect log attached for reference.
Guenter
# bad: [70d201a40823acba23899342d62bc2644051ad2e] Merge tag 'f2fs-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs # good: [0dd3ee31125508cd67f7e7172247f05b7fd1753a] Linux 6.7 git bisect start 'HEAD' 'v6.7' # bad: [de927f6c0b07d9e698416c5b287c521b07694cac] Merge tag 's390-6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect bad de927f6c0b07d9e698416c5b287c521b07694cac # bad: [35f11a3710cdcbbc5090d14017a6295454e0cc73] Merge tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux git bisect bad 35f11a3710cdcbbc5090d14017a6295454e0cc73 # good: [d30e51aa7b1f6fa7dd78d4598d1e4c047fcc3fb9] Merge tag 'slab-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab git bisect good d30e51aa7b1f6fa7dd78d4598d1e4c047fcc3fb9 # good: [fb46e22a9e3863e08aef8815df9f17d0f4b9aede] Merge tag 'mm-stable-2024-01-08-15-31' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm git bisect good fb46e22a9e3863e08aef8815df9f17d0f4b9aede # good: [063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac] Merge tag 'lsm-pr-20240105' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm git bisect good 063a7ce32ddc2c4f2404b0dfd29e60e3dbcdffac # bad: [f6cd66231aa58599526584ff4df1bdde8d86eac8] spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc git bisect bad f6cd66231aa58599526584ff4df1bdde8d86eac8 # good: [18f78b5e609b19b56237f0dae47068d44b8b0ecd] spi: axi-spi-engine: improvements round 2 git bisect good 18f78b5e609b19b56237f0dae47068d44b8b0ecd # bad: [9d93c8d97b4cdb5edddb4c5530881c90eecb7e44] spi: spi-ti-qspi: switch to use modern name git bisect bad 9d93c8d97b4cdb5edddb4c5530881c90eecb7e44 # bad: [e6b7e64cb11966b26646a362677ca5a08481157e] spi: st-ssc4: switch to use modern name git bisect bad e6b7e64cb11966b26646a362677ca5a08481157e # bad: [c3aeaf2f0ec8af93189488bda3928a1ac7752388] spi: pxa2xx: Use inclusive language git bisect bad c3aeaf2f0ec8af93189488bda3928a1ac7752388 # good: [f05e2f61fe88092e0d341ea27644a84e3386358d] ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select git bisect good f05e2f61fe88092e0d341ea27644a84e3386358d # bad: [88a50c1663ffa9f6b31705c6bf7a887a2c8d9434] spi: Add support for stacked/parallel memories git bisect bad 88a50c1663ffa9f6b31705c6bf7a887a2c8d9434 # bad: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core git bisect bad 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b # first bad commit: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core
On Sat, Jan 20, 2024 at 09:05:43AM -0800, Guenter Roeck wrote:
FWIW, the problem is due to
+#define SPI_CS_CNT_MAX 4
in the offending patch, but apeed2400 FMC supports up to 5 SPI chip selects.
static const struct aspeed_spi_data ast2400_fmc_data = { .max_cs = 5, ^^^^^^^^^^^^^^^^^^^ .hastype = true,
Limiting .max_cs to 4 or increasing SPI_CS_CNT_MAX to 5 fixes the problem, though of course I don't know if increasing SPI_CS_CNT_MAX has other side effects.
Yeah, I was coming to a similar conclusion myself - the limit is just too low. I can't see any problem with increasing it.
On 1/20/24 17:04, Mark Brown wrote:
On Sat, Jan 20, 2024 at 09:05:43AM -0800, Guenter Roeck wrote:
FWIW, the problem is due to
+#define SPI_CS_CNT_MAX 4
in the offending patch, but apeed2400 FMC supports up to 5 SPI chip selects.
static const struct aspeed_spi_data ast2400_fmc_data = { .max_cs = 5, ^^^^^^^^^^^^^^^^^^^ .hastype = true,
Limiting .max_cs to 4 or increasing SPI_CS_CNT_MAX to 5 fixes the problem, though of course I don't know if increasing SPI_CS_CNT_MAX has other side effects.
Yeah, I was coming to a similar conclusion myself - the limit is just too low. I can't see any problem with increasing it.
It would cost a bit of memory and somewhat affect performance sine many of the newly introduced loops are bound by SPI_CS_CNT_MAX and not by num_chipselect.
It also might make sense to document the new limit somewhere. Prior to this commit it was not limited at all. Documentation/devicetree/bindings/spi/spi-davinci.txt lists 5 chip selects in its example for the use of cs-gpios. Documentation/devicetree/bindings/spi/spi-controller.yaml also does not list a limit.
Thanks, Guenter
FWIW, the problem is due to
+#define SPI_CS_CNT_MAX 4
in the offending patch, but apeed2400 FMC supports up to 5 SPI chip selects.
static const struct aspeed_spi_data ast2400_fmc_data = { .max_cs = 5, ^^^^^^^^^^^^^^^^^^^ .hastype = true,
Limiting .max_cs to 4 or increasing SPI_CS_CNT_MAX to 5 fixes the problem, though of course I don't know if increasing SPI_CS_CNT_MAX has other side effects.
Yeah, I was coming to a similar conclusion myself - the limit is just too low. I can't see any problem with increasing it.
It would cost a bit of memory and somewhat affect performance sine many of the newly introduced loops are bound by SPI_CS_CNT_MAX and not by num_chipselect.
It also might make sense to document the new limit somewhere. Prior to this commit it was not limited at all. Documentation/devicetree/bindings/spi/spi-davinci.txt lists 5 chip selects in its example for the use of cs-gpios. Documentation/devicetree/bindings/spi/spi-controller.yaml also does not list a limit.
Given that, that the rest of this series is under discussion (and esp. whether it is the correct way to do it) it might make sense to just revert the picked patches.
-michael
On 1/21/24 10:06, Michael Walle wrote:
FWIW, the problem is due to
+#define SPI_CS_CNT_MAX 4
in the offending patch, but apeed2400 FMC supports up to 5 SPI chip selects.
static const struct aspeed_spi_data ast2400_fmc_data = { .max_cs = 5, ^^^^^^^^^^^^^^^^^^^ .hastype = true,
Limiting .max_cs to 4 or increasing SPI_CS_CNT_MAX to 5 fixes the problem, though of course I don't know if increasing SPI_CS_CNT_MAX has other side effects.
Yeah, I was coming to a similar conclusion myself - the limit is just too low. I can't see any problem with increasing it.
It would cost a bit of memory and somewhat affect performance sine many of the newly introduced loops are bound by SPI_CS_CNT_MAX and not by num_chipselect.
It also might make sense to document the new limit somewhere. Prior to this commit it was not limited at all. Documentation/devicetree/bindings/spi/spi-davinci.txt lists 5 chip selects in its example for the use of cs-gpios. Documentation/devicetree/bindings/spi/spi-controller.yaml also does not list a limit.
Given that, that the rest of this series is under discussion (and esp. whether it is the correct way to do it) it might make sense to just revert the picked patches.
I can't really comment on that, but I found that there is another affected devicetree property: num-cs. Its range isn't limited in Documentation/devicetree/bindings/spi/spi-controller.yaml. Various dts/dtsi files use numbers as large as 8. The range is limited in some bindings files, but not all of them. Documentation/devicetree/bindings/spi/spi-lantiq-ssc.txt, for example, says
"num-cs: see spi-bus.txt, set to 8 if unset"
Various Broadcom dtsi files set it to 8.
So I guess 8 would be the absolute minimum to re-enable support for affected systems.
Guenter
On Sun, Jan 21, 2024 at 11:29:48AM -0800, Guenter Roeck wrote:
So I guess 8 would be the absolute minimum to re-enable support for affected systems.
That's actually the number I went for, just waiting for CI to go through before I send it out.
On Sun, Jan 21, 2024 at 07:06:31PM +0100, Michael Walle wrote:
Given that, that the rest of this series is under discussion (and esp. whether it is the correct way to do it) it might make sense to just revert the picked patches.
The API change in the patch is a pain out of tree due to the way it's easy to add new things that miss the helpers without it so I'd rather keep it in if possible. The underlying implementation does need some TLC though.
On 12.01.24 20:11, Guenter Roeck wrote:
On Sat, Nov 25, 2023 at 02:51:30PM +0530, Amit Kumar Mahapatra wrote:
AMD-Xilinx GQSPI controller has two advanced mode that allows the controller to consider two flashes as one single device.
One of these two mode is the parallel mode in which each byte of data is stored in both devices, the even bits in the lower flash & the odd bits in the upper flash. The byte split is automatically handled by the QSPI controller.
[...] With this patch in the mainline kernel, two of my qemu emulations (quanta-q71l-bmc and almetto-bmc) fail to instantiate the first SPI controller and thus fail to boot from SPI. The error message is
[ 3.006458] spi_master spi0: No. of CS is more than max. no. of supported CS [ 3.006775] spi_master spi0: Failed to create SPI device for /ahb/spi@1e620000/flash@0
The problem is no longer seen after reverting this patch. [...] # first bad commit: [4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b] spi: Add multi-cs memories support in SPI core
Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot:
#regzbot ^introduced 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9 #regzbot title spi: qemu emulations quanta-q71l-bmc and almetto-bmc fail to boot #regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
In most of the register write operations the spi_nor_write_enable is called from within that API from where spi_mem APIs are called. Follwoing the same trend move the write enable API from spi_nor_write & spi_nor_erase APIs to the respective write & erase APIs.
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/mtd/spi-nor/core.c | 40 ++++++++++++++------------------------ 1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 72c80d8b5858..93ae69b7ff83 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -301,6 +301,12 @@ static ssize_t spi_nor_spimem_write_data(struct spi_nor *nor, loff_t to, ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len, const u8 *buf) { + int ret; + + ret = spi_nor_write_enable(nor); + if (ret) + return ret; + if (nor->spimem) return spi_nor_spimem_write_data(nor, to, len, buf);
@@ -1074,6 +1080,10 @@ static int spi_nor_erase_chip(struct spi_nor *nor)
dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
+ ret = spi_nor_write_enable(nor); + if (ret) + return ret; + if (nor->spimem) { struct spi_mem_op op = SPI_NOR_CHIP_ERASE_OP;
@@ -1481,10 +1491,14 @@ static u32 spi_nor_convert_addr(struct spi_nor *nor, loff_t addr) */ int spi_nor_erase_sector(struct spi_nor *nor, u32 addr) { - int i; + int i, ret;
addr = spi_nor_convert_addr(nor, addr);
+ ret = spi_nor_write_enable(nor); + if (ret) + return ret; + if (nor->spimem) { struct spi_mem_op op = SPI_NOR_SECTOR_ERASE_OP(nor->erase_opcode, @@ -1777,12 +1791,6 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len) if (ret) goto destroy_erase_cmd_list;
- ret = spi_nor_write_enable(nor); - if (ret) { - spi_nor_unlock_device(nor); - goto destroy_erase_cmd_list; - } - ret = spi_nor_erase_sector(nor, addr); spi_nor_unlock_device(nor); if (ret) @@ -1841,12 +1849,6 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) if (ret) goto erase_err;
- ret = spi_nor_write_enable(nor); - if (ret) { - spi_nor_unlock_device(nor); - goto erase_err; - } - ret = spi_nor_erase_chip(nor); spi_nor_unlock_device(nor); if (ret) @@ -1877,12 +1879,6 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) if (ret) goto erase_err;
- ret = spi_nor_write_enable(nor); - if (ret) { - spi_nor_unlock_device(nor); - goto erase_err; - } - ret = spi_nor_erase_sector(nor, addr); spi_nor_unlock_device(nor); if (ret) @@ -2177,12 +2173,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, if (ret) goto write_err;
- ret = spi_nor_write_enable(nor); - if (ret) { - spi_nor_unlock_device(nor); - goto write_err; - } - ret = spi_nor_write_data(nor, addr, page_remain, buf + i); spi_nor_unlock_device(nor); if (ret < 0)
GQSPI supports two chip select CS0 & CS1. Update the driver to assert/de-assert the appropriate chip select as per the bits set in qspi->cs_index_mask.
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/spi/spi-zynqmp-gqspi.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c index 9a46b2478f4e..c5d12ddd4ab3 100644 --- a/drivers/spi/spi-zynqmp-gqspi.c +++ b/drivers/spi/spi-zynqmp-gqspi.c @@ -154,6 +154,9 @@ #define GQSPI_FREQ_100MHZ 100000000 #define GQSPI_FREQ_150MHZ 150000000
+#define GQSPI_SELECT_LOWER_CS BIT(0) +#define GQSPI_SELECT_UPPER_CS BIT(1) + #define SPI_AUTOSUSPEND_TIMEOUT 3000 enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
@@ -465,15 +468,17 @@ static void zynqmp_qspi_chipselect(struct spi_device *qspi, bool is_high)
genfifoentry |= GQSPI_GENFIFO_MODE_SPI;
+ if (qspi->cs_index_mask & GQSPI_SELECT_UPPER_CS) { + zynqmp_gqspi_selectslave(xqspi, + GQSPI_SELECT_FLASH_CS_UPPER, + GQSPI_SELECT_FLASH_BUS_LOWER); + } else if (qspi->cs_index_mask & GQSPI_SELECT_LOWER_CS) { + zynqmp_gqspi_selectslave(xqspi, + GQSPI_SELECT_FLASH_CS_LOWER, + GQSPI_SELECT_FLASH_BUS_LOWER); + } + genfifoentry |= xqspi->genfifobus; if (!is_high) { - if (!spi_get_chipselect(qspi, 0)) { - xqspi->genfifobus = GQSPI_GENFIFO_BUS_LOWER; - xqspi->genfifocs = GQSPI_GENFIFO_CS_LOWER; - } else { - xqspi->genfifobus = GQSPI_GENFIFO_BUS_UPPER; - xqspi->genfifocs = GQSPI_GENFIFO_CS_UPPER; - } - genfifoentry |= xqspi->genfifobus; genfifoentry |= xqspi->genfifocs; genfifoentry |= GQSPI_GENFIFO_CS_SETUP; } else {
Supporting multi-cs in spi-nor would require the *params member of struct spi_nor to be an array. To make the transition smoother introduced spi_nor_get_params() & spi_nor_set_params() APIs to get & set nor->params, added a new local variable (struct spi_nor_flash_parameter *params) to hold the return value of the spi_nor_get_params() function call and replaced all nor->params references with the "params". While adding multi-cs support in further patches the *params member of the spi_nor structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., nor->params[idx].
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/mtd/spi-nor/atmel.c | 17 ++-- drivers/mtd/spi-nor/core.c | 136 ++++++++++++++++++++----------- drivers/mtd/spi-nor/debugfs.c | 4 +- drivers/mtd/spi-nor/gigadevice.c | 4 +- drivers/mtd/spi-nor/issi.c | 11 ++- drivers/mtd/spi-nor/macronix.c | 10 ++- drivers/mtd/spi-nor/micron-st.c | 30 ++++--- drivers/mtd/spi-nor/otp.c | 29 +++++-- drivers/mtd/spi-nor/sfdp.c | 33 ++++---- drivers/mtd/spi-nor/spansion.c | 57 +++++++------ drivers/mtd/spi-nor/sst.c | 7 +- drivers/mtd/spi-nor/swp.c | 25 ++++-- drivers/mtd/spi-nor/winbond.c | 2 +- drivers/mtd/spi-nor/xilinx.c | 18 ++-- include/linux/mtd/spi-nor.h | 10 +++ 15 files changed, 257 insertions(+), 136 deletions(-)
diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c index e13b8d2dd50a..b63cbe18162c 100644 --- a/drivers/mtd/spi-nor/atmel.c +++ b/drivers/mtd/spi-nor/atmel.c @@ -23,10 +23,11 @@ static int at25fs_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
/* We only support unlocking the whole flash array */ - if (ofs || len != nor->params->size) + if (ofs || len != params->size) return -EINVAL;
/* Write 0x00 to the status register to disable write protection */ @@ -50,7 +51,9 @@ static const struct spi_nor_locking_ops at25fs_nor_locking_ops = {
static int at25fs_nor_late_init(struct spi_nor *nor) { - nor->params->locking_ops = &at25fs_nor_locking_ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->locking_ops = &at25fs_nor_locking_ops;
return 0; } @@ -71,11 +74,12 @@ static const struct spi_nor_fixups at25fs_nor_fixups = { static int atmel_nor_set_global_protection(struct spi_nor *nor, loff_t ofs, uint64_t len, bool is_protect) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret; u8 sr;
/* We only support locking the whole flash array */ - if (ofs || len != nor->params->size) + if (ofs || len != params->size) return -EINVAL;
ret = spi_nor_read_sr(nor, nor->bouncebuf); @@ -133,9 +137,10 @@ static int atmel_nor_global_unprotect(struct spi_nor *nor, loff_t ofs, static int atmel_nor_is_global_protected(struct spi_nor *nor, loff_t ofs, uint64_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
- if (ofs >= nor->params->size || (ofs + len) > nor->params->size) + if (ofs >= params->size || (ofs + len) > params->size) return -EINVAL;
ret = spi_nor_read_sr(nor, nor->bouncebuf); @@ -153,7 +158,9 @@ static const struct spi_nor_locking_ops atmel_nor_global_protection_ops = {
static int atmel_nor_global_protection_late_init(struct spi_nor *nor) { - nor->params->locking_ops = &atmel_nor_global_protection_ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->locking_ops = &atmel_nor_global_protection_ops;
return 0; } diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 1c443fe568cf..72c80d8b5858 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -448,14 +448,15 @@ int spi_nor_read_id(struct spi_nor *nor, u8 naddr, u8 ndummy, u8 *id, */ int spi_nor_read_sr(struct spi_nor *nor, u8 *sr) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
if (nor->spimem) { struct spi_mem_op op = SPI_NOR_RDSR_OP(sr);
if (nor->reg_proto == SNOR_PROTO_8_8_8_DTR) { - op.addr.nbytes = nor->params->rdsr_addr_nbytes; - op.dummy.nbytes = nor->params->rdsr_dummy; + op.addr.nbytes = params->rdsr_addr_nbytes; + op.dummy.nbytes = params->rdsr_dummy; /* * We don't want to read only one byte in DTR mode. So, * read 2 and then discard the second byte. @@ -688,14 +689,15 @@ static void spi_nor_unlock_rdst(struct spi_nor *nor) static int spi_nor_ready(struct spi_nor *nor) { int ret; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
ret = spi_nor_lock_rdst(nor); if (ret) return 0;
/* Flashes might override the standard routine. */ - if (nor->params->ready) - ret = nor->params->ready(nor); + if (params->ready) + ret = params->ready(nor); else ret = spi_nor_sr_ready(nor);
@@ -861,6 +863,7 @@ static int spi_nor_write_sr1_and_check(struct spi_nor *nor, u8 sr1) */ static int spi_nor_write_16bit_sr_and_check(struct spi_nor *nor, u8 sr1) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret; u8 *sr_cr = nor->bouncebuf; u8 cr_written; @@ -872,7 +875,7 @@ static int spi_nor_write_16bit_sr_and_check(struct spi_nor *nor, u8 sr1) return ret; } else if (spi_nor_get_protocol_width(nor->read_proto) == 4 && spi_nor_get_protocol_width(nor->write_proto) == 4 && - nor->params->quad_enable) { + params->quad_enable) { /* * If the Status Register 2 Read command (35h) is not * supported, we should at least be sure we don't @@ -1150,17 +1153,21 @@ static u8 spi_nor_convert_3to4_erase(u8 opcode)
static bool spi_nor_has_uniform_erase(const struct spi_nor *nor) { - return !!nor->params->erase_map.uniform_erase_type; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + return !!params->erase_map.uniform_erase_type; }
static void spi_nor_set_4byte_opcodes(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode); nor->program_opcode = spi_nor_convert_3to4_program(nor->program_opcode); nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
if (!spi_nor_has_uniform_erase(nor)) { - struct spi_nor_erase_map *map = &nor->params->erase_map; + struct spi_nor_erase_map *map = ¶ms->erase_map; struct spi_nor_erase_type *erase; int i;
@@ -1302,6 +1309,7 @@ void spi_nor_unlock_and_unprep(struct spi_nor *nor) /* Internal locking helpers for program and erase operations */ static bool spi_nor_rww_start_pe(struct spi_nor *nor, loff_t start, size_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_rww *rww = &nor->rww; unsigned int used_banks = 0; bool started = false; @@ -1313,7 +1321,7 @@ static bool spi_nor_rww_start_pe(struct spi_nor *nor, loff_t start, size_t len) if (rww->ongoing_io || rww->ongoing_rd || rww->ongoing_pe) goto busy;
- spi_nor_offset_to_banks(nor->params->bank_size, start, len, &first, &last); + spi_nor_offset_to_banks(params->bank_size, start, len, &first, &last); for (bank = first; bank <= last; bank++) { if (rww->used_banks & BIT(bank)) goto busy; @@ -1332,13 +1340,14 @@ static bool spi_nor_rww_start_pe(struct spi_nor *nor, loff_t start, size_t len)
static void spi_nor_rww_end_pe(struct spi_nor *nor, loff_t start, size_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_rww *rww = &nor->rww; u8 first, last; int bank;
mutex_lock(&nor->lock);
- spi_nor_offset_to_banks(nor->params->bank_size, start, len, &first, &last); + spi_nor_offset_to_banks(params->bank_size, start, len, &first, &last); for (bank = first; bank <= last; bank++) rww->used_banks &= ~BIT(bank);
@@ -1379,6 +1388,7 @@ static void spi_nor_unlock_and_unprep_pe(struct spi_nor *nor, loff_t start, size /* Internal locking helpers for read operations */ static bool spi_nor_rww_start_rd(struct spi_nor *nor, loff_t start, size_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_rww *rww = &nor->rww; unsigned int used_banks = 0; bool started = false; @@ -1390,7 +1400,7 @@ static bool spi_nor_rww_start_rd(struct spi_nor *nor, loff_t start, size_t len) if (rww->ongoing_io || rww->ongoing_rd) goto busy;
- spi_nor_offset_to_banks(nor->params->bank_size, start, len, &first, &last); + spi_nor_offset_to_banks(params->bank_size, start, len, &first, &last); for (bank = first; bank <= last; bank++) { if (rww->used_banks & BIT(bank)) goto busy; @@ -1410,13 +1420,14 @@ static bool spi_nor_rww_start_rd(struct spi_nor *nor, loff_t start, size_t len)
static void spi_nor_rww_end_rd(struct spi_nor *nor, loff_t start, size_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_rww *rww = &nor->rww; u8 first, last; int bank;
mutex_lock(&nor->lock);
- spi_nor_offset_to_banks(nor->params->bank_size, start, len, &first, &last); + spi_nor_offset_to_banks(params->bank_size, start, len, &first, &last); for (bank = first; bank <= last; bank++) nor->rww.used_banks &= ~BIT(bank);
@@ -1457,10 +1468,12 @@ static void spi_nor_unlock_and_unprep_rd(struct spi_nor *nor, loff_t start, size
static u32 spi_nor_convert_addr(struct spi_nor *nor, loff_t addr) { - if (!nor->params->convert_addr) + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + if (!params->convert_addr) return addr;
- return nor->params->convert_addr(nor, addr); + return params->convert_addr(nor, addr); }
/* @@ -1680,7 +1693,8 @@ static int spi_nor_init_erase_cmd_list(struct spi_nor *nor, struct list_head *erase_list, u64 addr, u32 len) { - const struct spi_nor_erase_map *map = &nor->params->erase_map; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_erase_map *map = ¶ms->erase_map; const struct spi_nor_erase_type *erase, *prev_erase = NULL; struct spi_nor_erase_region *region; struct spi_nor_erase_command *cmd = NULL; @@ -2124,9 +2138,10 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf) { struct spi_nor *nor = mtd_to_spi_nor(mtd); + struct spi_nor_flash_parameter *params; size_t page_offset, page_remain, i; ssize_t ret; - u32 page_size = nor->params->page_size; + u32 page_size;
dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
@@ -2134,6 +2149,9 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, if (ret) return ret;
+ params = spi_nor_get_params(nor, 0); + page_size = params->page_size; + for (i = 0; i < len; ) { ssize_t written; loff_t addr = to + i; @@ -2289,6 +2307,8 @@ int spi_nor_hwcaps_pp2cmd(u32 hwcaps) static int spi_nor_spimem_check_op(struct spi_nor *nor, struct spi_mem_op *op) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + /* * First test with 4 address bytes. The opcode itself might * be a 3B addressing opcode but we don't care, because @@ -2297,7 +2317,7 @@ static int spi_nor_spimem_check_op(struct spi_nor *nor, */ op->addr.nbytes = 4; if (!spi_mem_supports_op(nor->spimem, op)) { - if (nor->params->size > SZ_16M) + if (params->size > SZ_16M) return -EOPNOTSUPP;
/* If flash size <= 16MB, 3 address bytes are sufficient */ @@ -2361,7 +2381,7 @@ static int spi_nor_spimem_check_pp(struct spi_nor *nor, static void spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); unsigned int cap;
/* X-X-X modes are not supported yet, mask them all. */ @@ -2462,6 +2482,7 @@ static int spi_nor_select_read(struct spi_nor *nor, u32 shared_hwcaps) { int cmd, best_match = fls(shared_hwcaps & SNOR_HWCAPS_READ_MASK) - 1; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); const struct spi_nor_read_command *read;
if (best_match < 0) @@ -2471,7 +2492,7 @@ static int spi_nor_select_read(struct spi_nor *nor, if (cmd < 0) return -EINVAL;
- read = &nor->params->reads[cmd]; + read = ¶ms->reads[cmd]; nor->read_opcode = read->opcode; nor->read_proto = read->proto;
@@ -2492,6 +2513,7 @@ static int spi_nor_select_read(struct spi_nor *nor, static int spi_nor_select_pp(struct spi_nor *nor, u32 shared_hwcaps) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int cmd, best_match = fls(shared_hwcaps & SNOR_HWCAPS_PP_MASK) - 1; const struct spi_nor_pp_command *pp;
@@ -2502,7 +2524,7 @@ static int spi_nor_select_pp(struct spi_nor *nor, if (cmd < 0) return -EINVAL;
- pp = &nor->params->page_programs[cmd]; + pp = ¶ms->page_programs[cmd]; nor->program_opcode = pp->opcode; nor->write_proto = pp->proto; return 0; @@ -2568,7 +2590,8 @@ spi_nor_select_uniform_erase(struct spi_nor_erase_map *map)
static int spi_nor_select_erase(struct spi_nor *nor) { - struct spi_nor_erase_map *map = &nor->params->erase_map; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + struct spi_nor_erase_map *map = ¶ms->erase_map; const struct spi_nor_erase_type *erase = NULL; struct mtd_info *mtd = &nor->mtd; int i; @@ -2611,7 +2634,7 @@ static int spi_nor_select_erase(struct spi_nor *nor) static int spi_nor_default_setup(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u32 ignored_mask, shared_mask; int err;
@@ -2671,8 +2694,10 @@ static int spi_nor_default_setup(struct spi_nor *nor,
static int spi_nor_set_addr_nbytes(struct spi_nor *nor) { - if (nor->params->addr_nbytes) { - nor->addr_nbytes = nor->params->addr_nbytes; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + if (params->addr_nbytes) { + nor->addr_nbytes = params->addr_nbytes; } else if (nor->read_proto == SNOR_PROTO_8_8_8_DTR) { /* * In 8D-8D-8D mode, one byte takes half a cycle to transfer. So @@ -2693,7 +2718,7 @@ static int spi_nor_set_addr_nbytes(struct spi_nor *nor) nor->addr_nbytes = 3; }
- if (nor->addr_nbytes == 3 && nor->params->size > 0x1000000) { + if (nor->addr_nbytes == 3 && params->size > 0x1000000) { /* enable 4-byte addressing if the device exceeds 16MiB */ nor->addr_nbytes = 4; } @@ -2715,10 +2740,11 @@ static int spi_nor_set_addr_nbytes(struct spi_nor *nor) static int spi_nor_setup(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
- if (nor->params->setup) - ret = nor->params->setup(nor, hwcaps); + if (params->setup) + ret = params->setup(nor, hwcaps); else ret = spi_nor_default_setup(nor, hwcaps); if (ret) @@ -2753,7 +2779,7 @@ static void spi_nor_manufacturer_init_params(struct spi_nor *nor) */ static void spi_nor_no_sfdp_init_params(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_erase_map *map = ¶ms->erase_map; const struct flash_info *info = nor->info; const u8 no_sfdp_flags = info->no_sfdp_flags; @@ -2823,6 +2849,7 @@ static void spi_nor_no_sfdp_init_params(struct spi_nor *nor) */ static void spi_nor_init_flags(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct device_node *np = spi_nor_get_flash_node(nor); const u16 flags = nor->info->flags;
@@ -2853,7 +2880,7 @@ static void spi_nor_init_flags(struct spi_nor *nor) if (flags & NO_CHIP_ERASE) nor->flags |= SNOR_F_NO_OP_CHIP_ERASE;
- if (flags & SPI_NOR_RWW && nor->params->n_banks > 1 && + if (flags & SPI_NOR_RWW && params->n_banks > 1 && !nor->controller_ops) nor->flags |= SNOR_F_RWW; } @@ -2887,7 +2914,7 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) */ static int spi_nor_late_init_params(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
if (nor->manufacturer && nor->manufacturer->fixups && @@ -2914,7 +2941,7 @@ static int spi_nor_late_init_params(struct spi_nor *nor) * NOR protection support. When locking_ops are not provided, we pick * the default ones. */ - if (nor->flags & SNOR_F_HAS_LOCK && !nor->params->locking_ops) + if (nor->flags & SNOR_F_HAS_LOCK && !params->locking_ops) spi_nor_init_default_locking_ops(nor);
if (params->n_banks > 1) @@ -2933,12 +2960,13 @@ static int spi_nor_late_init_params(struct spi_nor *nor) */ static void spi_nor_sfdp_init_params_deprecated(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_flash_parameter sfdp_params;
- memcpy(&sfdp_params, nor->params, sizeof(sfdp_params)); + memcpy(&sfdp_params, params, sizeof(sfdp_params));
if (spi_nor_parse_sfdp(nor)) { - memcpy(nor->params, &sfdp_params, sizeof(*nor->params)); + memcpy(params, &sfdp_params, sizeof(*params)); nor->flags &= ~SNOR_F_4B_OPCODES; } } @@ -2973,7 +3001,7 @@ static void spi_nor_init_params_deprecated(struct spi_nor *nor) */ static void spi_nor_init_default_params(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); const struct flash_info *info = nor->info; struct device_node *np = spi_nor_get_flash_node(nor);
@@ -3060,12 +3088,15 @@ static void spi_nor_init_default_params(struct spi_nor *nor) */ static int spi_nor_init_params(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
- nor->params = devm_kzalloc(nor->dev, sizeof(*nor->params), GFP_KERNEL); - if (!nor->params) + params = devm_kzalloc(nor->dev, sizeof(*params), GFP_KERNEL); + if (!params) return -ENOMEM;
+ spi_nor_set_params(nor, 0, params); + spi_nor_init_default_params(nor);
if (spi_nor_needs_sfdp(nor)) { @@ -3091,9 +3122,10 @@ static int spi_nor_init_params(struct spi_nor *nor) */ static int spi_nor_set_octal_dtr(struct spi_nor *nor, bool enable) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
- if (!nor->params->set_octal_dtr) + if (!params->set_octal_dtr) return 0;
if (!(nor->read_proto == SNOR_PROTO_8_8_8_DTR && @@ -3103,7 +3135,7 @@ static int spi_nor_set_octal_dtr(struct spi_nor *nor, bool enable) if (!(nor->flags & SNOR_F_IO_MODE_EN_VOLATILE)) return 0;
- ret = nor->params->set_octal_dtr(nor, enable); + ret = params->set_octal_dtr(nor, enable); if (ret) return ret;
@@ -3123,14 +3155,16 @@ static int spi_nor_set_octal_dtr(struct spi_nor *nor, bool enable) */ static int spi_nor_quad_enable(struct spi_nor *nor) { - if (!nor->params->quad_enable) + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + if (!params->quad_enable) return 0;
if (!(spi_nor_get_protocol_width(nor->read_proto) == 4 || spi_nor_get_protocol_width(nor->write_proto) == 4)) return 0;
- return nor->params->quad_enable(nor); + return params->quad_enable(nor); }
/** @@ -3142,7 +3176,7 @@ static int spi_nor_quad_enable(struct spi_nor *nor) */ int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
ret = params->set_4byte_addr_mode(nor, enable); @@ -3395,6 +3429,7 @@ static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
static void spi_nor_set_mtd_info(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct mtd_info *mtd = &nor->mtd; struct device *dev = nor->dev;
@@ -3413,9 +3448,9 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) mtd->flags |= MTD_NO_ERASE; else mtd->_erase = spi_nor_erase; - mtd->writesize = nor->params->writesize; - mtd->writebufsize = nor->params->page_size; - mtd->size = nor->params->size; + mtd->writesize = params->writesize; + mtd->writebufsize = params->page_size; + mtd->size = params->size; mtd->_read = spi_nor_read; /* Might be already set by some SST flashes. */ if (!mtd->_write) @@ -3469,7 +3504,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, * We need the bounce buffer early to read/write registers when going * through the spi-mem layer (buffers have to be DMA-able). * For spi-mem drivers, we'll reallocate a new buffer if - * nor->params->page_size turns out to be greater than PAGE_SIZE (which + * params->page_size turns out to be greater than PAGE_SIZE (which * shouldn't happen before long since NOR pages are usually less * than 1KB) after spi_nor_scan() returns. */ @@ -3543,13 +3578,14 @@ EXPORT_SYMBOL_GPL(spi_nor_scan);
static int spi_nor_create_read_dirmap(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_dirmap_info info = { .op_tmpl = SPI_MEM_OP(SPI_MEM_OP_CMD(nor->read_opcode, 0), SPI_MEM_OP_ADDR(nor->addr_nbytes, 0, 0), SPI_MEM_OP_DUMMY(nor->read_dummy, 0), SPI_MEM_OP_DATA_IN(0, NULL, 0)), .offset = 0, - .length = nor->params->size, + .length = params->size, }; struct spi_mem_op *op = &info.op_tmpl;
@@ -3574,13 +3610,14 @@ static int spi_nor_create_read_dirmap(struct spi_nor *nor)
static int spi_nor_create_write_dirmap(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_dirmap_info info = { .op_tmpl = SPI_MEM_OP(SPI_MEM_OP_CMD(nor->program_opcode, 0), SPI_MEM_OP_ADDR(nor->addr_nbytes, 0, 0), SPI_MEM_OP_NO_DUMMY, SPI_MEM_OP_DATA_OUT(0, NULL, 0)), .offset = 0, - .length = nor->params->size, + .length = params->size, }; struct spi_mem_op *op = &info.op_tmpl;
@@ -3603,6 +3640,7 @@ static int spi_nor_create_write_dirmap(struct spi_nor *nor)
static int spi_nor_probe(struct spi_mem *spimem) { + struct spi_nor_flash_parameter *params; struct spi_device *spi = spimem->spi; struct flash_platform_data *data = dev_get_platdata(&spi->dev); struct spi_nor *nor; @@ -3649,13 +3687,15 @@ static int spi_nor_probe(struct spi_mem *spimem)
spi_nor_debugfs_register(nor);
+ params = spi_nor_get_params(nor, 0); + /* * None of the existing parts have > 512B pages, but let's play safe * and add this logic so that if anyone ever adds support for such * a NOR we don't end up with buffer overflows. */ - if (nor->params->page_size > PAGE_SIZE) { - nor->bouncebuf_size = nor->params->page_size; + if (params->page_size > PAGE_SIZE) { + nor->bouncebuf_size = params->page_size; devm_kfree(nor->dev, nor->bouncebuf); nor->bouncebuf = devm_kmalloc(nor->dev, nor->bouncebuf_size, diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c index 6e163cb5b478..72a901b88ea9 100644 --- a/drivers/mtd/spi-nor/debugfs.c +++ b/drivers/mtd/spi-nor/debugfs.c @@ -76,7 +76,7 @@ static void spi_nor_print_flags(struct seq_file *s, unsigned long flags, static int spi_nor_params_show(struct seq_file *s, void *data) { struct spi_nor *nor = s->private; - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_erase_map *erase_map = ¶ms->erase_map; struct spi_nor_erase_region *region; const struct flash_info *info = nor->info; @@ -184,7 +184,7 @@ static void spi_nor_print_pp_cmd(struct seq_file *s, static int spi_nor_capabilities_show(struct seq_file *s, void *data) { struct spi_nor *nor = s->private; - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u32 hwcaps = params->hwcaps.mask; int i, cmd;
diff --git a/drivers/mtd/spi-nor/gigadevice.c b/drivers/mtd/spi-nor/gigadevice.c index ef1edd0add70..338ce989df22 100644 --- a/drivers/mtd/spi-nor/gigadevice.c +++ b/drivers/mtd/spi-nor/gigadevice.c @@ -13,6 +13,8 @@ gd25q256_post_bfpt(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, const struct sfdp_bfpt *bfpt) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + /* * GD25Q256C supports the first version of JESD216 which does not define * the Quad Enable methods. Overwrite the default Quad Enable method. @@ -24,7 +26,7 @@ gd25q256_post_bfpt(struct spi_nor *nor, */ if (bfpt_header->major == SFDP_JESD216_MAJOR && bfpt_header->minor == SFDP_JESD216_MINOR) - nor->params->quad_enable = spi_nor_sr1_bit6_quad_enable; + params->quad_enable = spi_nor_sr1_bit6_quad_enable;
return 0; } diff --git a/drivers/mtd/spi-nor/issi.c b/drivers/mtd/spi-nor/issi.c index 18d9a00aa22e..ea148a3a5e1f 100644 --- a/drivers/mtd/spi-nor/issi.c +++ b/drivers/mtd/spi-nor/issi.c @@ -13,6 +13,8 @@ is25lp256_post_bfpt_fixups(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, const struct sfdp_bfpt *bfpt) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + /* * IS25LP256 supports 4B opcodes, but the BFPT advertises * BFPT_DWORD1_ADDRESS_BYTES_3_ONLY. @@ -20,7 +22,7 @@ is25lp256_post_bfpt_fixups(struct spi_nor *nor, */ if ((bfpt->dwords[SFDP_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) == BFPT_DWORD1_ADDRESS_BYTES_3_ONLY) - nor->params->addr_nbytes = 4; + params->addr_nbytes = 4;
return 0; } @@ -31,7 +33,8 @@ static const struct spi_nor_fixups is25lp256_fixups = {
static int pm25lv_nor_late_init(struct spi_nor *nor) { - struct spi_nor_erase_map *map = &nor->params->erase_map; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + struct spi_nor_erase_map *map = ¶ms->erase_map; int i;
/* The PM25LV series has a different 4k sector erase opcode */ @@ -131,7 +134,9 @@ static const struct flash_info issi_nor_parts[] = {
static void issi_nor_default_init(struct spi_nor *nor) { - nor->params->quad_enable = spi_nor_sr1_bit6_quad_enable; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->quad_enable = spi_nor_sr1_bit6_quad_enable; }
static const struct spi_nor_fixups issi_fixups = { diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c index ea6be95e75a5..be1f273e3ce2 100644 --- a/drivers/mtd/spi-nor/macronix.c +++ b/drivers/mtd/spi-nor/macronix.c @@ -187,13 +187,17 @@ static const struct flash_info macronix_nor_parts[] = {
static void macronix_nor_default_init(struct spi_nor *nor) { - nor->params->quad_enable = spi_nor_sr1_bit6_quad_enable; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->quad_enable = spi_nor_sr1_bit6_quad_enable; }
static int macronix_nor_late_init(struct spi_nor *nor) { - if (!nor->params->set_4byte_addr_mode) - nor->params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_en4b_ex4b; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + if (!params->set_4byte_addr_mode) + params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_en4b_ex4b;
return 0; } diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c index 8920547c12bf..813a5b1a269b 100644 --- a/drivers/mtd/spi-nor/micron-st.c +++ b/drivers/mtd/spi-nor/micron-st.c @@ -49,10 +49,11 @@
static int micron_st_nor_octal_dtr_en(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op; u8 *buf = nor->bouncebuf; int ret; - u8 addr_mode_nbytes = nor->params->addr_mode_nbytes; + u8 addr_mode_nbytes = params->addr_mode_nbytes;
/* Use 20 dummy cycles for memory array reads. */ *buf = 20; @@ -128,27 +129,31 @@ static int micron_st_nor_set_octal_dtr(struct spi_nor *nor, bool enable)
static void mt35xu512aba_default_init(struct spi_nor *nor) { - nor->params->set_octal_dtr = micron_st_nor_set_octal_dtr; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->set_octal_dtr = micron_st_nor_set_octal_dtr; }
static int mt35xu512aba_post_sfdp_fixup(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + /* Set the Fast Read settings. */ - nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR; - spi_nor_set_read_settings(&nor->params->reads[SNOR_CMD_READ_8_8_8_DTR], + params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR; + spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR], 0, 20, SPINOR_OP_MT_DTR_RD, SNOR_PROTO_8_8_8_DTR);
nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; - nor->params->rdsr_dummy = 8; - nor->params->rdsr_addr_nbytes = 0; + params->rdsr_dummy = 8; + params->rdsr_addr_nbytes = 0;
/* * The BFPT quad enable field is set to a reserved value so the quad * enable function is ignored by spi_nor_parse_bfpt(). Make sure we * disable it. */ - nor->params->quad_enable = NULL; + params->quad_enable = NULL;
return 0; } @@ -457,14 +462,15 @@ static const struct flash_info st_nor_parts[] = { */ static int micron_st_nor_read_fsr(struct spi_nor *nor, u8 *fsr) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
if (nor->spimem) { struct spi_mem_op op = MICRON_ST_RDFSR_OP(fsr);
if (nor->reg_proto == SNOR_PROTO_8_8_8_DTR) { - op.addr.nbytes = nor->params->rdsr_addr_nbytes; - op.dummy.nbytes = nor->params->rdsr_dummy; + op.addr.nbytes = params->rdsr_addr_nbytes; + op.dummy.nbytes = params->rdsr_dummy; /* * We don't want to read only one byte in DTR mode. So, * read 2 and then discard the second byte. @@ -567,14 +573,16 @@ static int micron_st_nor_ready(struct spi_nor *nor)
static void micron_st_nor_default_init(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + nor->flags |= SNOR_F_HAS_LOCK; nor->flags &= ~SNOR_F_HAS_16BIT_SR; - nor->params->quad_enable = NULL; + params->quad_enable = NULL; }
static int micron_st_nor_late_init(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
if (nor->info->mfr_flags & USE_FSR) params->ready = micron_st_nor_ready; diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c index 23fe75ddc9cf..16a9a0375aeb 100644 --- a/drivers/mtd/spi-nor/otp.c +++ b/drivers/mtd/spi-nor/otp.c @@ -19,7 +19,9 @@ */ static inline unsigned int spi_nor_otp_region_len(struct spi_nor *nor) { - return nor->params->otp.org->len; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + return params->otp.org->len; }
/** @@ -30,7 +32,9 @@ static inline unsigned int spi_nor_otp_region_len(struct spi_nor *nor) */ static inline unsigned int spi_nor_otp_n_regions(struct spi_nor *nor) { - return nor->params->otp.org->n_regions; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + return params->otp.org->n_regions; }
/** @@ -241,7 +245,8 @@ int spi_nor_otp_is_locked_sr2(struct spi_nor *nor, unsigned int region)
static loff_t spi_nor_otp_region_start(const struct spi_nor *nor, unsigned int region) { - const struct spi_nor_otp_organization *org = nor->params->otp.org; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_otp_organization *org = params->otp.org;
return org->base + region * org->offset; } @@ -266,7 +271,8 @@ static int spi_nor_mtd_otp_info(struct mtd_info *mtd, size_t len, size_t *retlen, struct otp_info *buf) { struct spi_nor *nor = mtd_to_spi_nor(mtd); - const struct spi_nor_otp_ops *ops = nor->params->otp.ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_otp_ops *ops = params->otp.ops; unsigned int n_regions = spi_nor_otp_n_regions(nor); unsigned int i; int ret, locked; @@ -303,7 +309,8 @@ static int spi_nor_mtd_otp_info(struct mtd_info *mtd, size_t len, static int spi_nor_mtd_otp_range_is_locked(struct spi_nor *nor, loff_t ofs, size_t len) { - const struct spi_nor_otp_ops *ops = nor->params->otp.ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_otp_ops *ops = params->otp.ops; unsigned int region; int locked;
@@ -328,7 +335,8 @@ static int spi_nor_mtd_otp_read_write(struct mtd_info *mtd, loff_t ofs, const u8 *buf, bool is_write) { struct spi_nor *nor = mtd_to_spi_nor(mtd); - const struct spi_nor_otp_ops *ops = nor->params->otp.ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_otp_ops *ops = params->otp.ops; const size_t rlen = spi_nor_otp_region_len(nor); loff_t rstart, rofs; unsigned int region; @@ -414,7 +422,8 @@ static int spi_nor_mtd_otp_write(struct mtd_info *mtd, loff_t to, size_t len, static int spi_nor_mtd_otp_erase(struct mtd_info *mtd, loff_t from, size_t len) { struct spi_nor *nor = mtd_to_spi_nor(mtd); - const struct spi_nor_otp_ops *ops = nor->params->otp.ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_otp_ops *ops = params->otp.ops; const size_t rlen = spi_nor_otp_region_len(nor); unsigned int region; loff_t rstart; @@ -467,7 +476,8 @@ static int spi_nor_mtd_otp_erase(struct mtd_info *mtd, loff_t from, size_t len) static int spi_nor_mtd_otp_lock(struct mtd_info *mtd, loff_t from, size_t len) { struct spi_nor *nor = mtd_to_spi_nor(mtd); - const struct spi_nor_otp_ops *ops = nor->params->otp.ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spi_nor_otp_ops *ops = params->otp.ops; const size_t rlen = spi_nor_otp_region_len(nor); unsigned int region; int ret; @@ -501,9 +511,10 @@ static int spi_nor_mtd_otp_lock(struct mtd_info *mtd, loff_t from, size_t len)
void spi_nor_set_mtd_otp_ops(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct mtd_info *mtd = &nor->mtd;
- if (!nor->params->otp.ops) + if (!params->otp.ops) return;
if (WARN_ON(!is_power_of_2(spi_nor_otp_region_len(nor)))) diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c index b3b11dfed789..f7137c100569 100644 --- a/drivers/mtd/spi-nor/sfdp.c +++ b/drivers/mtd/spi-nor/sfdp.c @@ -436,7 +436,7 @@ static void spi_nor_regions_sort_erase_types(struct spi_nor_erase_map *map) static int spi_nor_parse_bfpt(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_erase_map *map = ¶ms->erase_map; struct spi_nor_erase_type *erase_type = map->erase_type; struct sfdp_bfpt bfpt; @@ -661,6 +661,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, */ static u8 spi_nor_smpt_addr_nbytes(const struct spi_nor *nor, const u32 settings) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + switch (settings & SMPT_CMD_ADDRESS_LEN_MASK) { case SMPT_CMD_ADDRESS_LEN_0: return 0; @@ -670,7 +672,7 @@ static u8 spi_nor_smpt_addr_nbytes(const struct spi_nor *nor, const u32 settings return 4; case SMPT_CMD_ADDRESS_LEN_USE_CURRENT: default: - return nor->params->addr_mode_nbytes; + return params->addr_mode_nbytes; } }
@@ -822,7 +824,8 @@ spi_nor_region_check_overlay(struct spi_nor_erase_region *region, static int spi_nor_init_non_uniform_erase_map(struct spi_nor *nor, const u32 *smpt) { - struct spi_nor_erase_map *map = &nor->params->erase_map; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + struct spi_nor_erase_map *map = ¶ms->erase_map; struct spi_nor_erase_type *erase = map->erase_type; struct spi_nor_erase_region *region; u64 offset; @@ -910,6 +913,7 @@ static int spi_nor_init_non_uniform_erase_map(struct spi_nor *nor, static int spi_nor_parse_smpt(struct spi_nor *nor, const struct sfdp_parameter_header *smpt_header) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); const u32 *sector_map; u32 *smpt; size_t len; @@ -940,7 +944,7 @@ static int spi_nor_parse_smpt(struct spi_nor *nor, if (ret) goto out;
- spi_nor_regions_sort_erase_types(&nor->params->erase_map); + spi_nor_regions_sort_erase_types(¶ms->erase_map); /* fall through */ out: kfree(smpt); @@ -980,7 +984,7 @@ static int spi_nor_parse_4bait(struct spi_nor *nor, { 0u /* not used */, BIT(11) }, { 0u /* not used */, BIT(12) }, }; - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_pp_command *params_pp = params->page_programs; struct spi_nor_erase_map *map = ¶ms->erase_map; struct spi_nor_erase_type *erase_type = map->erase_type; @@ -1143,6 +1147,7 @@ static int spi_nor_parse_4bait(struct spi_nor *nor, static int spi_nor_parse_profile1(struct spi_nor *nor, const struct sfdp_parameter_header *profile1_header) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u32 *dwords, addr; size_t len; int ret; @@ -1165,14 +1170,14 @@ static int spi_nor_parse_profile1(struct spi_nor *nor,
/* Set the Read Status Register dummy cycles and dummy address bytes. */ if (dwords[SFDP_DWORD(1)] & PROFILE1_DWORD1_RDSR_DUMMY) - nor->params->rdsr_dummy = 8; + params->rdsr_dummy = 8; else - nor->params->rdsr_dummy = 4; + params->rdsr_dummy = 4;
if (dwords[SFDP_DWORD(1)] & PROFILE1_DWORD1_RDSR_ADDR_BYTES) - nor->params->rdsr_addr_nbytes = 4; + params->rdsr_addr_nbytes = 4; else - nor->params->rdsr_addr_nbytes = 0; + params->rdsr_addr_nbytes = 0;
/* * We don't know what speed the controller is running at. Find the @@ -1201,8 +1206,8 @@ static int spi_nor_parse_profile1(struct spi_nor *nor, dummy = round_up(dummy, 2);
/* Update the fast read settings. */ - nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR; - spi_nor_set_read_settings(&nor->params->reads[SNOR_CMD_READ_8_8_8_DTR], + params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR; + spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR], 0, dummy, opcode, SNOR_PROTO_8_8_8_DTR);
@@ -1210,7 +1215,7 @@ static int spi_nor_parse_profile1(struct spi_nor *nor, * Page Program is "Required Command" in the xSPI Profile 1.0. Update * the params->hwcaps.mask here. */ - nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR; + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
out: kfree(dwords); @@ -1231,7 +1236,7 @@ static int spi_nor_parse_profile1(struct spi_nor *nor, static int spi_nor_parse_sccr(struct spi_nor *nor, const struct sfdp_parameter_header *sccr_header) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u32 *dwords, addr; size_t len; int ret; @@ -1282,7 +1287,7 @@ static int spi_nor_parse_sccr(struct spi_nor *nor, static int spi_nor_parse_sccr_mc(struct spi_nor *nor, const struct sfdp_parameter_header *sccr_mc_header) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u32 *dwords, addr; u8 i, n_dice; size_t len; diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c index 12921344373d..63f46e443b29 100644 --- a/drivers/mtd/spi-nor/spansion.c +++ b/drivers/mtd/spi-nor/spansion.c @@ -78,7 +78,8 @@ struct spansion_nor_params { */ static void spansion_nor_clear_sr(struct spi_nor *nor) { - const struct spansion_nor_params *priv_params = nor->params->priv; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + const struct spansion_nor_params *priv_params = params->priv; int ret;
if (nor->spimem) { @@ -98,7 +99,7 @@ static void spansion_nor_clear_sr(struct spi_nor *nor)
static int cypress_nor_sr_ready_and_clear_reg(struct spi_nor *nor, u64 addr) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op = CYPRESS_NOR_RD_ANY_REG_OP(params->addr_mode_nbytes, addr, 0, nor->bouncebuf); @@ -140,7 +141,7 @@ static int cypress_nor_sr_ready_and_clear_reg(struct spi_nor *nor, u64 addr) */ static int cypress_nor_sr_ready_and_clear(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u64 addr; int ret; u8 i; @@ -159,10 +160,11 @@ static int cypress_nor_sr_ready_and_clear(struct spi_nor *nor)
static int cypress_nor_set_memlat(struct spi_nor *nor, u64 addr) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op; u8 *buf = nor->bouncebuf; int ret; - u8 addr_mode_nbytes = nor->params->addr_mode_nbytes; + u8 addr_mode_nbytes = params->addr_mode_nbytes;
op = (struct spi_mem_op) CYPRESS_NOR_RD_ANY_REG_OP(addr_mode_nbytes, addr, 0, buf); @@ -189,13 +191,14 @@ static int cypress_nor_set_memlat(struct spi_nor *nor, u64 addr)
static int cypress_nor_set_octal_dtr_bits(struct spi_nor *nor, u64 addr) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op; u8 *buf = nor->bouncebuf;
/* Set the octal and DTR enable bits. */ buf[0] = SPINOR_REG_CYPRESS_CFR5_OCT_DTR_EN; op = (struct spi_mem_op) - CYPRESS_NOR_WR_ANY_REG_OP(nor->params->addr_mode_nbytes, + CYPRESS_NOR_WR_ANY_REG_OP(params->addr_mode_nbytes, addr, 1, buf);
return spi_nor_write_any_volatile_reg(nor, &op, nor->reg_proto); @@ -203,7 +206,7 @@ static int cypress_nor_set_octal_dtr_bits(struct spi_nor *nor, u64 addr)
static int cypress_nor_octal_dtr_en(struct spi_nor *nor) { - const struct spi_nor_flash_parameter *params = nor->params; + const struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u8 *buf = nor->bouncebuf; u64 addr; int i, ret; @@ -253,7 +256,7 @@ static int cypress_nor_set_single_spi_bits(struct spi_nor *nor, u64 addr)
static int cypress_nor_octal_dtr_dis(struct spi_nor *nor) { - const struct spi_nor_flash_parameter *params = nor->params; + const struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u8 *buf = nor->bouncebuf; u64 addr; int i, ret; @@ -280,8 +283,9 @@ static int cypress_nor_octal_dtr_dis(struct spi_nor *nor)
static int cypress_nor_quad_enable_volatile_reg(struct spi_nor *nor, u64 addr) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op; - u8 addr_mode_nbytes = nor->params->addr_mode_nbytes; + u8 addr_mode_nbytes = params->addr_mode_nbytes; u8 cfr1v_written; int ret;
@@ -339,7 +343,7 @@ static int cypress_nor_quad_enable_volatile_reg(struct spi_nor *nor, u64 addr) */ static int cypress_nor_quad_enable_volatile(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u64 addr; u8 i; int ret; @@ -418,6 +422,7 @@ static int cypress_nor_determine_addr_mode_by_sr1(struct spi_nor *nor, */ static int cypress_nor_set_addr_mode_nbytes(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op; u8 addr_mode; int ret; @@ -459,8 +464,8 @@ static int cypress_nor_set_addr_mode_nbytes(struct spi_nor *nor) return spi_nor_set_4byte_addr_mode(nor, true); }
- nor->params->addr_nbytes = addr_mode; - nor->params->addr_mode_nbytes = addr_mode; + params->addr_nbytes = addr_mode; + params->addr_mode_nbytes = addr_mode;
return 0; } @@ -477,10 +482,10 @@ static int cypress_nor_set_addr_mode_nbytes(struct spi_nor *nor) */ static int cypress_nor_get_page_size(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op = - CYPRESS_NOR_RD_ANY_REG_OP(nor->params->addr_mode_nbytes, + CYPRESS_NOR_RD_ANY_REG_OP(params->addr_mode_nbytes, 0, 0, nor->bouncebuf); - struct spi_nor_flash_parameter *params = nor->params; int ret; u8 i;
@@ -507,12 +512,14 @@ static int cypress_nor_get_page_size(struct spi_nor *nor)
static void cypress_nor_ecc_init(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + /* * Programming is supported only in 16-byte ECC data unit granularity. * Byte-programming, bit-walking, or multiple program operations to the * same ECC data unit without an erase are not allowed. */ - nor->params->writesize = 16; + params->writesize = 16; nor->flags |= SNOR_F_ECC; }
@@ -521,6 +528,7 @@ s25fs256t_post_bfpt_fixup(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, const struct sfdp_bfpt *bfpt) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_mem_op op; int ret;
@@ -530,7 +538,7 @@ s25fs256t_post_bfpt_fixup(struct spi_nor *nor,
/* Read Architecture Configuration Register (ARCFN) */ op = (struct spi_mem_op) - CYPRESS_NOR_RD_ANY_REG_OP(nor->params->addr_mode_nbytes, + CYPRESS_NOR_RD_ANY_REG_OP(params->addr_mode_nbytes, SPINOR_REG_CYPRESS_ARCFN, 1, nor->bouncebuf); ret = spi_nor_read_any_reg(nor, &op, nor->reg_proto); @@ -546,7 +554,7 @@ s25fs256t_post_bfpt_fixup(struct spi_nor *nor,
static int s25fs256t_post_sfdp_fixup(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
/* * S25FS256T does not define the SCCR map, but we would like to use the @@ -588,20 +596,21 @@ s25hx_t_post_bfpt_fixup(struct spi_nor *nor, const struct sfdp_bfpt *bfpt) { int ret; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
ret = cypress_nor_set_addr_mode_nbytes(nor); if (ret) return ret;
/* Replace Quad Enable with volatile version */ - nor->params->quad_enable = cypress_nor_quad_enable_volatile; + params->quad_enable = cypress_nor_quad_enable_volatile;
return 0; }
static int s25hx_t_post_sfdp_fixup(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spi_nor_erase_type *erase_type = params->erase_map.erase_type; unsigned int i;
@@ -637,7 +646,7 @@ static int s25hx_t_post_sfdp_fixup(struct spi_nor *nor)
static int s25hx_t_late_init(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
/* Fast Read 4B requires mode cycles */ params->reads[SNOR_CMD_READ_FAST].num_mode_clocks = 8; @@ -671,7 +680,7 @@ static int cypress_nor_set_octal_dtr(struct spi_nor *nor, bool enable)
static int s28hx_t_post_sfdp_fixup(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
if (!params->n_dice || !params->vreg_offset) { dev_err(nor->dev, "%s failed. The volatile register offset could not be retrieved from SFDP.\n", @@ -720,7 +729,7 @@ static int s28hx_t_post_bfpt_fixup(struct spi_nor *nor,
static int s28hx_t_late_init(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
params->set_octal_dtr = cypress_nor_set_octal_dtr; params->ready = cypress_nor_sr_ready_and_clear; @@ -740,13 +749,15 @@ s25fs_s_nor_post_bfpt_fixups(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, const struct sfdp_bfpt *bfpt) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + /* * The S25FS-S chip family reports 512-byte pages in BFPT but * in reality the write buffer still wraps at the safe default * of 256 bytes. Overwrite the page size advertised by BFPT * to get the writes working. */ - nor->params->page_size = 256; + params->page_size = 256;
return 0; } @@ -1045,7 +1056,7 @@ static int spansion_nor_sr_ready_and_clear(struct spi_nor *nor)
static int spansion_nor_late_init(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct spansion_nor_params *priv_params; u8 mfr_flags = nor->info->mfr_flags;
diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c index 44d2a546bf17..8d6e50cfef62 100644 --- a/drivers/mtd/spi-nor/sst.c +++ b/drivers/mtd/spi-nor/sst.c @@ -20,10 +20,11 @@ static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
/* We only support unlocking the entire flash array. */ - if (ofs != 0 || len != nor->params->size) + if (ofs != 0 || len != params->size) return -EINVAL;
ret = spi_nor_read_cr(nor, nor->bouncebuf); @@ -51,7 +52,9 @@ static const struct spi_nor_locking_ops sst26vf_nor_locking_ops = {
static int sst26vf_nor_late_init(struct spi_nor *nor) { - nor->params->locking_ops = &sst26vf_nor_locking_ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->locking_ops = &sst26vf_nor_locking_ops;
return 0; } diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c index 585813310ee1..78febd6e1a00 100644 --- a/drivers/mtd/spi-nor/swp.c +++ b/drivers/mtd/spi-nor/swp.c @@ -39,7 +39,8 @@ static u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor) * the flash. For now, we need to have that ugly default. */ unsigned int sector_size = nor->info->sector_size ?: SPI_NOR_DEFAULT_SECTOR_SIZE; - u64 n_sectors = div_u64(nor->params->size, sector_size); + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + u64 n_sectors = div_u64(params->size, sector_size); u8 mask = spi_nor_get_sr_bp_mask(nor);
/* Reserved one for "protect none" and one for "protect all". */ @@ -350,11 +351,14 @@ static const struct spi_nor_locking_ops spi_nor_sr_locking_ops = {
void spi_nor_init_default_locking_ops(struct spi_nor *nor) { - nor->params->locking_ops = &spi_nor_sr_locking_ops; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->locking_ops = &spi_nor_sr_locking_ops; }
static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len) { + struct spi_nor_flash_parameter *params; struct spi_nor *nor = mtd_to_spi_nor(mtd); int ret;
@@ -362,7 +366,8 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len) if (ret) return ret;
- ret = nor->params->locking_ops->lock(nor, ofs, len); + params = spi_nor_get_params(nor, 0); + ret = params->locking_ops->lock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor); return ret; @@ -370,6 +375,7 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) { + struct spi_nor_flash_parameter *params; struct spi_nor *nor = mtd_to_spi_nor(mtd); int ret;
@@ -377,7 +383,8 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) if (ret) return ret;
- ret = nor->params->locking_ops->unlock(nor, ofs, len); + params = spi_nor_get_params(nor, 0); + ret = params->locking_ops->unlock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor); return ret; @@ -385,6 +392,7 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len) { + struct spi_nor_flash_parameter *params; struct spi_nor *nor = mtd_to_spi_nor(mtd); int ret;
@@ -392,7 +400,8 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len) if (ret) return ret;
- ret = nor->params->locking_ops->is_locked(nor, ofs, len); + params = spi_nor_get_params(nor, 0); + ret = params->locking_ops->is_locked(nor, ofs, len);
spi_nor_unlock_and_unprep(nor); return ret; @@ -412,6 +421,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len) */ void spi_nor_try_unlock_all(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); int ret;
if (!(nor->flags & SNOR_F_HAS_LOCK)) @@ -419,16 +429,17 @@ void spi_nor_try_unlock_all(struct spi_nor *nor)
dev_dbg(nor->dev, "Unprotecting entire flash array\n");
- ret = spi_nor_unlock(&nor->mtd, 0, nor->params->size); + ret = spi_nor_unlock(&nor->mtd, 0, params->size); if (ret) dev_dbg(nor->dev, "Failed to unlock the entire flash memory array\n"); }
void spi_nor_set_mtd_locking_ops(struct spi_nor *nor) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct mtd_info *mtd = &nor->mtd;
- if (!nor->params->locking_ops) + if (!params->locking_ops) return;
mtd->_lock = spi_nor_lock; diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c index 142fb27b2ea9..cdbec66aed91 100644 --- a/drivers/mtd/spi-nor/winbond.c +++ b/drivers/mtd/spi-nor/winbond.c @@ -303,7 +303,7 @@ static const struct spi_nor_otp_ops winbond_nor_otp_ops = {
static int winbond_nor_late_init(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = nor->params; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
if (params->otp.org) params->otp.ops = &winbond_nor_otp_ops; diff --git a/drivers/mtd/spi-nor/xilinx.c b/drivers/mtd/spi-nor/xilinx.c index f99118c691b0..046dfba6b166 100644 --- a/drivers/mtd/spi-nor/xilinx.c +++ b/drivers/mtd/spi-nor/xilinx.c @@ -50,7 +50,8 @@ static const struct flash_info xilinx_nor_parts[] = { */ static u32 s3an_nor_convert_addr(struct spi_nor *nor, u32 addr) { - u32 page_size = nor->params->page_size; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + u32 page_size = params->page_size; u32 offset, page;
offset = addr % page_size; @@ -110,6 +111,7 @@ static int xilinx_nor_sr_ready(struct spi_nor *nor) static int xilinx_nor_setup(struct spi_nor *nor, const struct spi_nor_hwcaps *hwcaps) { + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); u32 page_size; int ret;
@@ -135,14 +137,14 @@ static int xilinx_nor_setup(struct spi_nor *nor, */ if (nor->bouncebuf[0] & XSR_PAGESIZE) { /* Flash in Power of 2 mode */ - page_size = (nor->params->page_size == 264) ? 256 : 512; - nor->params->page_size = page_size; + page_size = (params->page_size == 264) ? 256 : 512; + params->page_size = page_size; nor->mtd.writebufsize = page_size; - nor->params->size = nor->info->size; + params->size = nor->info->size; nor->mtd.erasesize = 8 * page_size; } else { /* Flash in Default addressing mode */ - nor->params->convert_addr = s3an_nor_convert_addr; + params->convert_addr = s3an_nor_convert_addr; nor->mtd.erasesize = nor->info->sector_size; }
@@ -151,8 +153,10 @@ static int xilinx_nor_setup(struct spi_nor *nor,
static int xilinx_nor_late_init(struct spi_nor *nor) { - nor->params->setup = xilinx_nor_setup; - nor->params->ready = xilinx_nor_sr_ready; + struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + + params->setup = xilinx_nor_setup; + params->ready = xilinx_nor_sr_ready;
return 0; } diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index cdcfe0fd2e7d..59909e7d6f53 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -433,6 +433,16 @@ static inline struct device_node *spi_nor_get_flash_node(struct spi_nor *nor) return mtd_get_of_node(&nor->mtd); }
+static inline struct spi_nor_flash_parameter *spi_nor_get_params(const struct spi_nor *nor, u8 idx) +{ + return nor->params; +} + +static inline void spi_nor_set_params(struct spi_nor *nor, u8 idx, + struct spi_nor_flash_parameter *params) +{ + nor->params = params; +} /** * spi_nor_scan() - scan the SPI NOR * @nor: the spi_nor structure
The current implementation assumes that a maximum of two flashes are connected in parallel mode. The QSPI controller splits the data evenly between both the flashes so, both the flashes that are connected in parallel mode should be identical. During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in nor->spimem->spi->cs_index_mask. The QSPI driver will then assert/de-assert CS0 & CS1. Write operation in parallel mode are performed in page size * 2 chunks as each write operation results in writing both the flashes. For doubling the address space each operation is performed at addr/2 flash offset, where addr is the address specified by the user.
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/mtd/spi-nor/core.c | 409 +++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + drivers/mtd/spi-nor/micron-st.c | 5 + 3 files changed, 333 insertions(+), 85 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index e990be7c7eb6..2e6cc45341ed 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -470,17 +470,29 @@ int spi_nor_read_sr(struct spi_nor *nor, u8 *sr) op.data.nbytes = 2; }
+ if (nor->flags & SNOR_F_HAS_PARALLEL) + op.data.nbytes = 2; + spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op); } else { - ret = spi_nor_controller_ops_read_reg(nor, SPINOR_OP_RDSR, sr, - 1); + if (nor->flags & SNOR_F_HAS_PARALLEL) + ret = spi_nor_controller_ops_read_reg(nor, + SPINOR_OP_RDSR, + sr, 2); + else + ret = spi_nor_controller_ops_read_reg(nor, + SPINOR_OP_RDSR, + sr, 1); }
if (ret) dev_dbg(nor->dev, "error %d reading SR\n", ret);
+ if (nor->flags & SNOR_F_HAS_PARALLEL) + sr[0] |= sr[1]; + return ret; }
@@ -1824,6 +1836,7 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) struct spi_nor_flash_parameter *params; u32 addr, len, offset, cur_cs_num = 0; uint32_t rem; + u32 n_flash = 1; int ret; u64 sz;
@@ -1833,6 +1846,9 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) params = spi_nor_get_params(nor, 0); sz = params->size;
+ if (nor->num_flash) + n_flash = nor->num_flash; + if (spi_nor_has_uniform_erase(nor)) { div_u64_rem(instr->len, mtd->erasesize, &rem); if (rem) @@ -1854,53 +1870,82 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) if (ret) goto erase_err;
- while (cur_cs_num < nor->num_flash) { - nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; + if (nor->flags & SNOR_F_HAS_PARALLEL) { + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; ret = spi_nor_erase_chip(nor); spi_nor_unlock_device(nor); if (ret) goto erase_err;
/* - * Scale the timeout linearly with the size of the flash, with - * a minimum calibrated to an old 2MB flash. We could try to - * pull these from CFI/SFDP, but these values should be good - * enough for now. - */ + * Scale the timeout linearly with the size of the flash, with + * a minimum calibrated to an old 2MB flash. We could try to + * pull these from CFI/SFDP, but these values should be good + * enough for now. + */ timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES, - CHIP_ERASE_2MB_READY_WAIT_JIFFIES * - (unsigned long)(params->size / SZ_2M)); + CHIP_ERASE_2MB_READY_WAIT_JIFFIES * + (unsigned long)(mtd->size / SZ_2M)); ret = spi_nor_wait_till_ready_with_timeout(nor, timeout); if (ret) goto erase_err; - cur_cs_num++; - }
+ } else { + while (cur_cs_num < n_flash) { + nor->spimem->spi->cs_index_mask = 1 << cur_cs_num; + ret = spi_nor_erase_chip(nor); + spi_nor_unlock_device(nor); + if (ret) + goto erase_err; + + /* + * Scale the timeout linearly with the size of the flash, with + * a minimum calibrated to an old 2MB flash. We could try to + * pull these from CFI/SFDP, but these values should be good + * enough for now. + */ + timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES, + CHIP_ERASE_2MB_READY_WAIT_JIFFIES * + (unsigned long)(params->size / SZ_2M)); + ret = spi_nor_wait_till_ready_with_timeout(nor, timeout); + if (ret) + goto erase_err; + + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + } + } /* REVISIT in some cases we could speed up erasing large regions * by using SPINOR_OP_SE instead of SPINOR_OP_BE_4K. We may have set up * to use "small sector erase", but that's not always optimal. */ - /* "sector"-at-a-time erase */ } else if (spi_nor_has_uniform_erase(nor)) { - /* Determine the flash from which the operation need to start */ - while ((cur_cs_num < nor->num_flash) && (addr > sz - 1)) { - cur_cs_num++; - params = spi_nor_get_params(nor, cur_cs_num); - sz += params->size; + if (!(nor->flags & SNOR_F_HAS_PARALLEL)) { + while ((cur_cs_num < n_flash) && (addr > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } } - while (len) { ret = spi_nor_lock_device(nor); if (ret) goto erase_err;
- nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; offset = addr; if (nor->flags & SNOR_F_HAS_STACKED) { params = spi_nor_get_params(nor, cur_cs_num); offset -= (sz - params->size); } + nor->spimem->spi->cs_index_mask = 1 << cur_cs_num; + if (nor->flags & SNOR_F_HAS_PARALLEL) { + u64 aux = offset; + + ret = do_div(aux, n_flash); + offset = aux; + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; + }
ret = spi_nor_erase_sector(nor, offset); spi_nor_unlock_device(nor); @@ -1923,34 +1968,42 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) sz += params->size; } } - /* erase multiple sectors */ } else { - u64 erase_len = 0; + if (nor->flags & SNOR_F_HAS_PARALLEL) { + u64 aux = offset;
- /* Determine the flash from which the operation need to start */ - while ((cur_cs_num < nor->num_flash) && (addr > sz - 1)) { - cur_cs_num++; - params = spi_nor_get_params(nor, cur_cs_num); - sz += params->size; - } - /* perform multi sector erase onec per Flash*/ - while (len) { - erase_len = (len > (sz - addr)) ? (sz - addr) : len; - offset = addr; - nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; - if (nor->flags & SNOR_F_HAS_STACKED) { - params = spi_nor_get_params(nor, cur_cs_num); - offset -= (sz - params->size); - } - ret = spi_nor_erase_multi_sectors(nor, offset, erase_len); + ret = do_div(aux, n_flash); + offset = aux; + ret = spi_nor_erase_multi_sectors(nor, addr, len); if (ret) goto erase_err; - len -= erase_len; - addr += erase_len; - cur_cs_num++; - params = spi_nor_get_params(nor, cur_cs_num); - sz += params->size; + } else { + u64 erase_len = 0; + + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < n_flash) && (addr > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } + /* perform multi sector erase onec per Flash*/ + while (len) { + erase_len = (len > (sz - addr)) ? (sz - addr) : len; + offset = addr; + nor->spimem->spi->cs_index_mask = 1 << cur_cs_num; + if (nor->flags & SNOR_F_HAS_STACKED) { + params = spi_nor_get_params(nor, cur_cs_num); + offset -= (sz - params->size); + } + ret = spi_nor_erase_multi_sectors(nor, offset, erase_len); + if (ret) + goto erase_err; + len -= erase_len; + addr += erase_len; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } } }
@@ -2144,9 +2197,12 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, struct spi_nor *nor = mtd_to_spi_nor(mtd); struct spi_nor_flash_parameter *params; ssize_t ret, read_len, len_lock = len; + bool is_ofst_odd = false; loff_t from_lock = from; u32 cur_cs_num = 0; - u64 sz; + u_char *readbuf; + u32 n_flash = 1; + u64 sz = 0;
dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
@@ -2157,23 +2213,54 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, params = spi_nor_get_params(nor, 0); sz = params->size;
- /* Determine the flash from which the operation need to start */ - while ((cur_cs_num < nor->num_flash) && (from > sz - 1)) { - cur_cs_num++; - params = spi_nor_get_params(nor, cur_cs_num); - sz += params->size; + if (nor->num_flash) + n_flash = nor->num_flash; + + /* + * When even number of flashes are connected in parallel and the + * requested read length is odd then read (len + 1) from offset + 1 + * and ignore offset[0] data. + */ + if ((nor->flags & SNOR_F_HAS_PARALLEL) && (!(n_flash % 2)) && (from & 0x01)) { + from = (loff_t)(from - 1); + len = (size_t)(len + 1); + is_ofst_odd = true; + readbuf = kmalloc(len, GFP_KERNEL); + if (!readbuf) + return -ENOMEM; + } else { + readbuf = buf; } + + if (!(nor->flags & SNOR_F_HAS_PARALLEL)) { + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < n_flash) && (from > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } + } + while (len) { loff_t addr = from;
- nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; - read_len = (len > (sz - addr)) ? (sz - addr) : len; - params = spi_nor_get_params(nor, cur_cs_num); - addr -= (sz - params->size); + if (nor->flags & SNOR_F_HAS_PARALLEL) { + u64 aux = addr; + + ret = do_div(aux, n_flash); + addr = aux; + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; + read_len = len; + } else { + nor->spimem->spi->cs_index_mask = 1 << cur_cs_num; + read_len = (len > (sz - addr)) ? (sz - addr) : len; + params = spi_nor_get_params(nor, cur_cs_num); + addr -= (sz - params->size); + }
addr = spi_nor_convert_addr(nor, addr);
- ret = spi_nor_read_data(nor, addr, len, buf); + ret = spi_nor_read_data(nor, addr, read_len, readbuf); if (ret == 0) { /* We shouldn't see 0-length reads */ ret = -EIO; @@ -2183,8 +2270,20 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, goto read_err;
WARN_ON(ret > read_len); - *retlen += ret; + if (is_ofst_odd) { + /* + * Cannot read from odd offset in parallel mode. + * So read len + 1 from offset + 1 from the flash + * and copy len data from readbuf[1]. + */ + memcpy(buf, (readbuf + 1), (len - 1)); + *retlen += (ret - 1); + } else { + *retlen += ret; + } buf += ret; + if (!is_ofst_odd) + readbuf += ret; from += ret; len -= ret;
@@ -2202,8 +2301,10 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, ret = 0;
read_err: - spi_nor_unlock_and_unprep_rd(nor, from_lock, len_lock); + if (is_ofst_odd) + kfree(readbuf);
+ spi_nor_unlock_and_unprep_rd(nor, from_lock, len_lock); return ret; }
@@ -2219,6 +2320,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, struct spi_nor_flash_parameter *params; size_t page_offset, page_remain, i; u32 page_size, cur_cs_num = 0; + u32 n_flash = 1; ssize_t ret; u64 sz;
@@ -2232,11 +2334,41 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, page_size = params->page_size; sz = params->size;
- /* Determine the flash from which the operation need to start */ - while ((cur_cs_num < nor->num_flash) && (to > sz - 1)) { - cur_cs_num++; - params = spi_nor_get_params(nor, cur_cs_num); - sz += params->size; + if (nor->num_flash) + n_flash = nor->num_flash; + + if (nor->flags & SNOR_F_HAS_PARALLEL) { + /* + * When even number of flashes are connected in parallel and the + * requested write length is odd then first write 2 bytes. + */ + if ((!(n_flash % 2)) && (to & 0x01)) { + u8 two[2] = {0xff, buf[0]}; + size_t written_len; + + ret = spi_nor_write(mtd, to & ~1, 2, &written_len, two); + if (ret < 0) + return ret; + *retlen += 1; /* We've written only one actual byte */ + ++buf; + --len; + ++to; + } + /* + * Write operation are performed in page size chunks and in + * parallel memories both the flashes are written simultaneously, + * hence increase the page_size in multiple of the number of flash + * connected in parallel. + */ + page_size *= n_flash; + + } else { + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < n_flash) && (to > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } }
for (i = 0; i < len; ) { @@ -2258,9 +2390,17 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, /* the size of data remaining on the first page */ page_remain = min_t(size_t, page_size - page_offset, len - i);
- nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; - params = spi_nor_get_params(nor, cur_cs_num); - addr -= (sz - params->size); + if (nor->flags & SNOR_F_HAS_PARALLEL) { + u64 aux = addr; + + ret = do_div(aux, n_flash); + addr = aux; + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; + } else { + nor->spimem->spi->cs_index_mask = 1 << cur_cs_num; + params = spi_nor_get_params(nor, cur_cs_num); + addr -= (sz - params->size); + }
addr = spi_nor_convert_addr(nor, addr);
@@ -2701,7 +2841,15 @@ static int spi_nor_select_erase(struct spi_nor *nor) if (!erase) return -EINVAL; nor->erase_opcode = erase->opcode; - mtd->erasesize = erase->size; + /* + * In parallel-memories the erase operation is + * performed on both the flashes simultaneously + * so, double the erasesize. + */ + if (nor->flags & SNOR_F_HAS_PARALLEL) + mtd->erasesize = erase->size * 2; + else + mtd->erasesize = erase->size; return 0; }
@@ -2719,7 +2867,15 @@ static int spi_nor_select_erase(struct spi_nor *nor) if (!erase) return -EINVAL;
- mtd->erasesize = erase->size; + /* + * In parallel-memories the erase operation is + * performed on both the flashes simultaneously + * so, double the erasesize. + */ + if (nor->flags & SNOR_F_HAS_PARALLEL) + mtd->erasesize = erase->size * 2; + else + mtd->erasesize = erase->size; return 0; }
@@ -3060,6 +3216,17 @@ static int spi_nor_late_init_params(struct spi_nor *nor)
nor->num_flash++; } + idx = 0; + while (idx < SNOR_FLASH_CNT_MAX) { + rc = of_property_read_u64_index(np, "parallel-memories", idx, &flash_size[idx]); + if (rc) + break; + idx++; + if (!(nor->flags & SNOR_F_HAS_PARALLEL)) + nor->flags |= SNOR_F_HAS_PARALLEL; + + nor->num_flash++; + }
/* * By default one flash device should be connected @@ -3068,7 +3235,7 @@ static int spi_nor_late_init_params(struct spi_nor *nor) if (!nor->num_flash) nor->num_flash = 1;
- if (nor->flags & SNOR_F_HAS_STACKED) { + if (nor->flags & (SNOR_F_HAS_STACKED | SNOR_F_HAS_PARALLEL)) { for (idx = 1; idx < nor->num_flash; idx++) { params = spi_nor_get_params(nor, idx); params = devm_kzalloc(nor->dev, sizeof(*params), GFP_KERNEL); @@ -3289,10 +3456,14 @@ static int spi_nor_set_octal_dtr(struct spi_nor *nor, bool enable) static int spi_nor_quad_enable(struct spi_nor *nor) { struct spi_nor_flash_parameter *params; + u32 n_flash = 1; int err, idx;
- for (idx = 0; idx < nor->num_flash; idx++) { - params = spi_nor_get_params(nor, idx); + if (nor->num_flash) + n_flash = nor->num_flash; + + if (nor->flags & SNOR_F_HAS_PARALLEL) { + params = spi_nor_get_params(nor, 0); if (!params->quad_enable) return 0;
@@ -3300,14 +3471,32 @@ static int spi_nor_quad_enable(struct spi_nor *nor) spi_nor_get_protocol_width(nor->write_proto) == 4)) return 0; /* - * Set the appropriate CS index before - * issuing the command. + * In parallel mode both chip selects i.e., CS0 & + * CS1 need to be asserted simulatneously. */ - nor->spimem->spi->cs_index_mask = 0x01 << idx; - + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; err = params->quad_enable(nor); if (err) return err; + } else { + for (idx = 0; idx < n_flash; idx++) { + params = spi_nor_get_params(nor, idx); + if (!params->quad_enable) + return 0; + + if (!(spi_nor_get_protocol_width(nor->read_proto) == 4 || + spi_nor_get_protocol_width(nor->write_proto) == 4)) + return 0; + /* + * Set the appropriate CS index before + * issuing the command. + */ + nor->spimem->spi->cs_index_mask = 1 << idx; + + err = params->quad_enable(nor); + if (err) + return err; + } } return err; } @@ -3341,8 +3530,12 @@ int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable)
static int spi_nor_init(struct spi_nor *nor) { + u32 n_flash = 1; int err, idx;
+ if (nor->num_flash) + n_flash = nor->num_flash; + err = spi_nor_set_octal_dtr(nor, true); if (err) { dev_dbg(nor->dev, "octal mode not supported\n"); @@ -3382,15 +3575,26 @@ static int spi_nor_init(struct spi_nor *nor) */ WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET, "enabling reset hack; may not recover from unexpected reboots\n"); - for (idx = 0; idx < nor->num_flash; idx++) { + if (nor->flags & SNOR_F_HAS_PARALLEL) { /* - * Select the appropriate CS index before - * issuing the command. + * In parallel mode both chip selects i.e., CS0 & + * CS1 need to be asserted simulatneously. */ - nor->spimem->spi->cs_index_mask = 0x01 << idx; + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; err = spi_nor_set_4byte_addr_mode(nor, true); if (err) return err; + } else { + for (idx = 0; idx < n_flash; idx++) { + /* + * Select the appropriate CS index before + * issuing the command. + */ + nor->spimem->spi->cs_index_mask = 1 << idx; + err = spi_nor_set_4byte_addr_mode(nor, true); + if (err) + return err; + } } }
@@ -3505,19 +3709,23 @@ static void spi_nor_put_device(struct mtd_info *mtd)
static void spi_nor_restore(struct spi_nor *nor) { + u32 n_flash = 1; int ret; int idx;
+ if (nor->num_flash) + n_flash = nor->num_flash; + /* restore the addressing mode */ if (nor->addr_nbytes == 4 && !(nor->flags & SNOR_F_4B_OPCODES) && nor->flags & SNOR_F_BROKEN_RESET) { - for (idx = 0; idx < nor->num_flash; idx++) { + if (nor->flags & SNOR_F_HAS_PARALLEL) { /* - * Select the appropriate CS index before - * issuing the command. + * In parallel mode both chip selects i.e., CS0 & + * CS1 need to be asserted simulatneously. */ - nor->spimem->spi->cs_index_mask = 1 << idx; - ret = spi_nor_set_4byte_addr_mode(nor, false); + nor->spimem->spi->cs_index_mask = SPI_NOR_ENABLE_MULTI_CS; + spi_nor_set_4byte_addr_mode(nor, false); if (ret) /* * Do not stop the execution in the hope that the flash @@ -3527,6 +3735,24 @@ static void spi_nor_restore(struct spi_nor *nor) dev_err(nor->dev, "Failed to exit 4-byte address mode, err = %d\n", ret); + } else { + for (idx = 0; idx < n_flash; idx++) { + /* + * Select the appropriate CS index before + * issuing the command. + */ + nor->spimem->spi->cs_index_mask = 1 << idx; + ret = spi_nor_set_4byte_addr_mode(nor, false); + if (ret) + /* + * Do not stop the execution in the hope that the + * flash will default to the 3-byte address mode + * after the software reset. + */ + dev_err(nor->dev, + "Failed to exit 4-byte address mode, err = %d\n", + ret); + } } }
@@ -3595,11 +3821,15 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) struct mtd_info *mtd = &nor->mtd; struct device *dev = nor->dev; u64 total_sz = 0; + u32 n_flash = 1; int idx;
spi_nor_set_mtd_locking_ops(nor); spi_nor_set_mtd_otp_ops(nor);
+ if (nor->num_flash) + n_flash = nor->num_flash; + mtd->dev.parent = dev; if (!mtd->name) mtd->name = dev_name(dev); @@ -3613,8 +3843,17 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) else mtd->_erase = spi_nor_erase; mtd->writesize = params->writesize; - mtd->writebufsize = params->page_size; - for (idx = 0; idx < nor->num_flash; idx++) { + /* + * In parallel-memories the write operation is + * performed on both the flashes simultaneously + * one page per flash, so double the writebufsize. + */ + if (nor->flags & SNOR_F_HAS_PARALLEL) + mtd->writebufsize = params->page_size << 1; + else + mtd->writebufsize = params->page_size; + + for (idx = 0; idx < n_flash; idx++) { params = spi_nor_get_params(nor, idx); total_sz += params->size; } diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h index b2997eca7551..6c3009796013 100644 --- a/drivers/mtd/spi-nor/core.h +++ b/drivers/mtd/spi-nor/core.h @@ -21,6 +21,9 @@ /* In single configuration enable CS0 */ #define SPI_NOR_ENABLE_CS0 BIT(0)
+/* In parallel configuration enable multiple CS */ +#define SPI_NOR_ENABLE_MULTI_CS (BIT(0) | BIT(1)) + /* Standard SPI NOR flash operations. */ #define SPI_NOR_READID_OP(naddr, ndummy, buf, len) \ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 0), \ @@ -144,6 +147,7 @@ enum spi_nor_option_flags { SNOR_F_ECC = BIT(15), SNOR_F_NO_WP = BIT(16), SNOR_F_HAS_STACKED = BIT(17), + SNOR_F_HAS_PARALLEL = BIT(18), };
struct spi_nor_read_command { diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c index 813a5b1a269b..577121ebd6e8 100644 --- a/drivers/mtd/spi-nor/micron-st.c +++ b/drivers/mtd/spi-nor/micron-st.c @@ -478,6 +478,9 @@ static int micron_st_nor_read_fsr(struct spi_nor *nor, u8 *fsr) op.data.nbytes = 2; }
+ if (nor->flags & SNOR_F_HAS_PARALLEL) + op.data.nbytes = 2; + spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op); @@ -489,6 +492,8 @@ static int micron_st_nor_read_fsr(struct spi_nor *nor, u8 *fsr) if (ret) dev_dbg(nor->dev, "error %d reading FSR\n", ret);
+ if (nor->flags & SNOR_F_HAS_PARALLEL) + fsr[0] &= fsr[1]; return ret; }
During probe GQSPI driver sets SPI_CONTROLLER_MULTI_CS bit in ctlr->flags for notifying SPI core about multi CS capability of the controller. In parallel mode the controller can either split the data between both the flash or can send the same data to both the flashes, this is determined by the STRIPE bit. While sending commands to the flashes the GQSPI driver send the same command to both the flashes by resetting the STRIPE bit, but while writing/reading data to & from the flash the GQSPI driver splits the data evenly between both the flashes by setting the STRIPE bit.
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/spi/spi-zynqmp-gqspi.c | 39 +++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c index c5d12ddd4ab3..61e91d59014b 100644 --- a/drivers/spi/spi-zynqmp-gqspi.c +++ b/drivers/spi/spi-zynqmp-gqspi.c @@ -21,6 +21,7 @@ #include <linux/spinlock.h> #include <linux/workqueue.h> #include <linux/spi/spi-mem.h> +#include <linux/mtd/spi-nor.h>
/* Generic QSPI register offsets */ #define GQSPI_CONFIG_OFST 0x00000100 @@ -190,6 +191,7 @@ struct qspi_platform_data { * @op_lock: Operational lock * @speed_hz: Current SPI bus clock speed in hz * @has_tapdelay: Used for tapdelay register available in qspi + * @is_parallel: Used for multi CS support */ struct zynqmp_qspi { struct spi_controller *ctlr; @@ -212,8 +214,33 @@ struct zynqmp_qspi { struct mutex op_lock; u32 speed_hz; bool has_tapdelay; + bool is_parallel; };
+/** + * zynqmp_gqspi_update_stripe - For GQSPI controller data stripe capabilities + * @op: Pointer to mem ops + * Return: Status of the data stripe + * + * Returns true if data stripe need to be enabled, else returns false + */ +bool zynqmp_gqspi_update_stripe(const struct spi_mem_op *op) +{ + if (op->cmd.opcode == SPINOR_OP_BE_4K || + op->cmd.opcode == SPINOR_OP_BE_32K || + op->cmd.opcode == SPINOR_OP_CHIP_ERASE || + op->cmd.opcode == SPINOR_OP_SE || + op->cmd.opcode == SPINOR_OP_BE_32K_4B || + op->cmd.opcode == SPINOR_OP_SE_4B || + op->cmd.opcode == SPINOR_OP_BE_4K_4B || + op->cmd.opcode == SPINOR_OP_WRSR || + op->cmd.opcode == SPINOR_OP_BRWR || + (op->cmd.opcode == SPINOR_OP_WRSR2 && !op->addr.nbytes)) + return false; + + return true; +} + /** * zynqmp_gqspi_read - For GQSPI controller read operation * @xqspi: Pointer to the zynqmp_qspi structure @@ -468,7 +495,14 @@ static void zynqmp_qspi_chipselect(struct spi_device *qspi, bool is_high)
genfifoentry |= GQSPI_GENFIFO_MODE_SPI;
- if (qspi->cs_index_mask & GQSPI_SELECT_UPPER_CS) { + if ((qspi->cs_index_mask & GQSPI_SELECT_LOWER_CS) && + (qspi->cs_index_mask & GQSPI_SELECT_UPPER_CS)) { + zynqmp_gqspi_selectslave(xqspi, + GQSPI_SELECT_FLASH_CS_BOTH, + GQSPI_SELECT_FLASH_BUS_BOTH); + if (!xqspi->is_parallel) + xqspi->is_parallel = true; + } else if (qspi->cs_index_mask & GQSPI_SELECT_UPPER_CS) { zynqmp_gqspi_selectslave(xqspi, GQSPI_SELECT_FLASH_CS_UPPER, GQSPI_SELECT_FLASH_BUS_LOWER); @@ -1137,6 +1171,8 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem, }
if (op->data.nbytes) { + if (xqspi->is_parallel && zynqmp_gqspi_update_stripe(op)) + genfifoentry |= GQSPI_GENFIFO_STRIPE; reinit_completion(&xqspi->data_completion); if (op->data.dir == SPI_MEM_DATA_OUT) { xqspi->txbuf = (u8 *)op->data.buf.out; @@ -1332,6 +1368,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev) ctlr->bits_per_word_mask = SPI_BPW_MASK(8); ctlr->dev.of_node = np; ctlr->auto_runtime_pm = true; + ctlr->flags |= SPI_CONTROLLER_MULTI_CS;
ret = devm_spi_register_controller(&pdev->dev, ctlr); if (ret) {
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com --- drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -1821,13 +1821,18 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len) static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) { struct spi_nor *nor = mtd_to_spi_nor(mtd); - u32 addr, len; + struct spi_nor_flash_parameter *params; + u32 addr, len, offset, cur_cs_num = 0; uint32_t rem; int ret; + u64 sz;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr, (long long)instr->len);
+ params = spi_nor_get_params(nor, 0); + sz = params->size; + if (spi_nor_has_uniform_erase(nor)) { div_u64_rem(instr->len, mtd->erasesize, &rem); if (rem) @@ -1849,23 +1854,27 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) if (ret) goto erase_err;
- ret = spi_nor_erase_chip(nor); - spi_nor_unlock_device(nor); - if (ret) - goto erase_err; + while (cur_cs_num < nor->num_flash) { + nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; + ret = spi_nor_erase_chip(nor); + spi_nor_unlock_device(nor); + if (ret) + goto erase_err;
- /* - * Scale the timeout linearly with the size of the flash, with - * a minimum calibrated to an old 2MB flash. We could try to - * pull these from CFI/SFDP, but these values should be good - * enough for now. - */ - timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES, - CHIP_ERASE_2MB_READY_WAIT_JIFFIES * - (unsigned long)(mtd->size / SZ_2M)); - ret = spi_nor_wait_till_ready_with_timeout(nor, timeout); - if (ret) - goto erase_err; + /* + * Scale the timeout linearly with the size of the flash, with + * a minimum calibrated to an old 2MB flash. We could try to + * pull these from CFI/SFDP, but these values should be good + * enough for now. + */ + timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES, + CHIP_ERASE_2MB_READY_WAIT_JIFFIES * + (unsigned long)(params->size / SZ_2M)); + ret = spi_nor_wait_till_ready_with_timeout(nor, timeout); + if (ret) + goto erase_err; + cur_cs_num++; + }
/* REVISIT in some cases we could speed up erasing large regions * by using SPINOR_OP_SE instead of SPINOR_OP_BE_4K. We may have set up @@ -1874,12 +1883,26 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
/* "sector"-at-a-time erase */ } else if (spi_nor_has_uniform_erase(nor)) { + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < nor->num_flash) && (addr > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } + while (len) { ret = spi_nor_lock_device(nor); if (ret) goto erase_err;
- ret = spi_nor_erase_sector(nor, addr); + nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; + offset = addr; + if (nor->flags & SNOR_F_HAS_STACKED) { + params = spi_nor_get_params(nor, cur_cs_num); + offset -= (sz - params->size); + } + + ret = spi_nor_erase_sector(nor, offset); spi_nor_unlock_device(nor); if (ret) goto erase_err; @@ -1890,13 +1913,45 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
addr += mtd->erasesize; len -= mtd->erasesize; + + /* + * Flash cross over condition in stacked mode. + */ + if ((nor->flags & SNOR_F_HAS_STACKED) && (addr > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } }
/* erase multiple sectors */ } else { - ret = spi_nor_erase_multi_sectors(nor, addr, len); - if (ret) - goto erase_err; + u64 erase_len = 0; + + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < nor->num_flash) && (addr > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } + /* perform multi sector erase onec per Flash*/ + while (len) { + erase_len = (len > (sz - addr)) ? (sz - addr) : len; + offset = addr; + nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; + if (nor->flags & SNOR_F_HAS_STACKED) { + params = spi_nor_get_params(nor, cur_cs_num); + offset -= (sz - params->size); + } + ret = spi_nor_erase_multi_sectors(nor, offset, erase_len); + if (ret) + goto erase_err; + len -= erase_len; + addr += erase_len; + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } }
ret = spi_nor_write_disable(nor); @@ -2087,9 +2142,11 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf) { struct spi_nor *nor = mtd_to_spi_nor(mtd); + struct spi_nor_flash_parameter *params; + ssize_t ret, read_len, len_lock = len; loff_t from_lock = from; - size_t len_lock = len; - ssize_t ret; + u32 cur_cs_num = 0; + u64 sz;
dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
@@ -2097,9 +2154,23 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, if (ret) return ret;
+ params = spi_nor_get_params(nor, 0); + sz = params->size; + + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < nor->num_flash) && (from > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } while (len) { loff_t addr = from;
+ nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; + read_len = (len > (sz - addr)) ? (sz - addr) : len; + params = spi_nor_get_params(nor, cur_cs_num); + addr -= (sz - params->size); + addr = spi_nor_convert_addr(nor, addr);
ret = spi_nor_read_data(nor, addr, len, buf); @@ -2111,11 +2182,22 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len, if (ret < 0) goto read_err;
- WARN_ON(ret > len); + WARN_ON(ret > read_len); *retlen += ret; buf += ret; from += ret; len -= ret; + + /* + * Flash cross over condition in stacked mode. + * + */ + if ((nor->flags & SNOR_F_HAS_STACKED) && (from > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } + } ret = 0;
@@ -2136,8 +2218,9 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, struct spi_nor *nor = mtd_to_spi_nor(mtd); struct spi_nor_flash_parameter *params; size_t page_offset, page_remain, i; + u32 page_size, cur_cs_num = 0; ssize_t ret; - u32 page_size; + u64 sz;
dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
@@ -2147,6 +2230,14 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
params = spi_nor_get_params(nor, 0); page_size = params->page_size; + sz = params->size; + + /* Determine the flash from which the operation need to start */ + while ((cur_cs_num < nor->num_flash) && (to > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + }
for (i = 0; i < len; ) { ssize_t written; @@ -2167,6 +2258,10 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, /* the size of data remaining on the first page */ page_remain = min_t(size_t, page_size - page_offset, len - i);
+ nor->spimem->spi->cs_index_mask = 0x01 << cur_cs_num; + params = spi_nor_get_params(nor, cur_cs_num); + addr -= (sz - params->size); + addr = spi_nor_convert_addr(nor, addr);
ret = spi_nor_lock_device(nor); @@ -2184,6 +2279,15 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len, goto write_err; *retlen += written; i += written; + + /* + * Flash cross over condition in stacked mode. + */ + if ((nor->flags & SNOR_F_HAS_STACKED) && ((to + i) > sz - 1)) { + cur_cs_num++; + params = spi_nor_get_params(nor, cur_cs_num); + sz += params->size; + } }
write_err: @@ -2297,8 +2401,6 @@ int spi_nor_hwcaps_pp2cmd(u32 hwcaps) static int spi_nor_spimem_check_op(struct spi_nor *nor, struct spi_mem_op *op) { - struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); - /* * First test with 4 address bytes. The opcode itself might * be a 3B addressing opcode but we don't care, because @@ -2307,7 +2409,7 @@ static int spi_nor_spimem_check_op(struct spi_nor *nor, */ op->addr.nbytes = 4; if (!spi_mem_supports_op(nor->spimem, op)) { - if (params->size > SZ_16M) + if (nor->mtd.size > SZ_16M) return -EOPNOTSUPP;
/* If flash size <= 16MB, 3 address bytes are sufficient */ @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); - int ret; + struct device_node *np = spi_nor_get_flash_node(nor); + u64 flash_size[SNOR_FLASH_CNT_MAX]; + u32 idx = 0; + int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params->n_banks);
+ nor->num_flash = 0; + + /* + * The flashes that are connected in stacked mode should be of same make. + * Except the flash size all other properties are identical for all the + * flashes connected in stacked mode. + * The flashes that are connected in parallel mode should be identical. + */ + while (idx < SNOR_FLASH_CNT_MAX) { + rc = of_property_read_u64_index(np, "stacked-memories", idx, &flash_size[idx]); + if (rc) + break; + idx++; + if (!(nor->flags & SNOR_F_HAS_STACKED)) + nor->flags |= SNOR_F_HAS_STACKED; + + nor->num_flash++; + } + + /* + * By default one flash device should be connected + * so, nor->num_flash is 1. + */ + if (!nor->num_flash) + nor->num_flash = 1; + + if (nor->flags & SNOR_F_HAS_STACKED) { + for (idx = 1; idx < nor->num_flash; idx++) { + params = spi_nor_get_params(nor, idx); + params = devm_kzalloc(nor->dev, sizeof(*params), GFP_KERNEL); + if (params) { + memcpy(params, spi_nor_get_params(nor, 0), sizeof(*params)); + params->size = flash_size[idx]; + spi_nor_set_params(nor, idx, params); + } + } + } + return 0; }
@@ -3145,16 +3288,28 @@ static int spi_nor_set_octal_dtr(struct spi_nor *nor, bool enable) */ static int spi_nor_quad_enable(struct spi_nor *nor) { - struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); + struct spi_nor_flash_parameter *params; + int err, idx;
- if (!params->quad_enable) - return 0; + for (idx = 0; idx < nor->num_flash; idx++) { + params = spi_nor_get_params(nor, idx); + if (!params->quad_enable) + return 0;
- if (!(spi_nor_get_protocol_width(nor->read_proto) == 4 || - spi_nor_get_protocol_width(nor->write_proto) == 4)) - return 0; + if (!(spi_nor_get_protocol_width(nor->read_proto) == 4 || + spi_nor_get_protocol_width(nor->write_proto) == 4)) + return 0; + /* + * Set the appropriate CS index before + * issuing the command. + */ + nor->spimem->spi->cs_index_mask = 0x01 << idx;
- return params->quad_enable(nor); + err = params->quad_enable(nor); + if (err) + return err; + } + return err; }
/** @@ -3186,7 +3341,7 @@ int spi_nor_set_4byte_addr_mode(struct spi_nor *nor, bool enable)
static int spi_nor_init(struct spi_nor *nor) { - int err; + int err, idx;
err = spi_nor_set_octal_dtr(nor, true); if (err) { @@ -3227,9 +3382,16 @@ static int spi_nor_init(struct spi_nor *nor) */ WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET, "enabling reset hack; may not recover from unexpected reboots\n"); - err = spi_nor_set_4byte_addr_mode(nor, true); - if (err) - return err; + for (idx = 0; idx < nor->num_flash; idx++) { + /* + * Select the appropriate CS index before + * issuing the command. + */ + nor->spimem->spi->cs_index_mask = 0x01 << idx; + err = spi_nor_set_4byte_addr_mode(nor, true); + if (err) + return err; + } }
return 0; @@ -3344,18 +3506,28 @@ static void spi_nor_put_device(struct mtd_info *mtd) static void spi_nor_restore(struct spi_nor *nor) { int ret; + int idx;
/* restore the addressing mode */ if (nor->addr_nbytes == 4 && !(nor->flags & SNOR_F_4B_OPCODES) && nor->flags & SNOR_F_BROKEN_RESET) { - ret = spi_nor_set_4byte_addr_mode(nor, false); - if (ret) + for (idx = 0; idx < nor->num_flash; idx++) { /* - * Do not stop the execution in the hope that the flash - * will default to the 3-byte address mode after the - * software reset. + * Select the appropriate CS index before + * issuing the command. */ - dev_err(nor->dev, "Failed to exit 4-byte address mode, err = %d\n", ret); + nor->spimem->spi->cs_index_mask = 1 << idx; + ret = spi_nor_set_4byte_addr_mode(nor, false); + if (ret) + /* + * Do not stop the execution in the hope that the flash + * will default to the 3-byte address mode after the + * software reset. + */ + dev_err(nor->dev, + "Failed to exit 4-byte address mode, err = %d\n", + ret); + } }
if (nor->flags & SNOR_F_SOFT_RESET) @@ -3422,6 +3594,8 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); struct mtd_info *mtd = &nor->mtd; struct device *dev = nor->dev; + u64 total_sz = 0; + int idx;
spi_nor_set_mtd_locking_ops(nor); spi_nor_set_mtd_otp_ops(nor); @@ -3440,7 +3614,11 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) mtd->_erase = spi_nor_erase; mtd->writesize = params->writesize; mtd->writebufsize = params->page_size; - mtd->size = params->size; + for (idx = 0; idx < nor->num_flash; idx++) { + params = spi_nor_get_params(nor, idx); + total_sz += params->size; + } + mtd->size = total_sz; mtd->_read = spi_nor_read; /* Might be already set by some SST flashes. */ if (!mtd->_write) diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h index 93cd2fc3606d..b2997eca7551 100644 --- a/drivers/mtd/spi-nor/core.h +++ b/drivers/mtd/spi-nor/core.h @@ -18,6 +18,9 @@ #define SPI_NOR_DEFAULT_N_BANKS 1 #define SPI_NOR_DEFAULT_SECTOR_SIZE SZ_64K
+/* In single configuration enable CS0 */ +#define SPI_NOR_ENABLE_CS0 BIT(0) + /* Standard SPI NOR flash operations. */ #define SPI_NOR_READID_OP(naddr, ndummy, buf, len) \ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 0), \ @@ -140,6 +143,7 @@ enum spi_nor_option_flags { SNOR_F_RWW = BIT(14), SNOR_F_ECC = BIT(15), SNOR_F_NO_WP = BIT(16), + SNOR_F_HAS_STACKED = BIT(17), };
struct spi_nor_read_command { diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 59909e7d6f53..9d72b0bbab94 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -127,6 +127,12 @@ #define SR2_LB3 BIT(5) /* Security Register Lock Bit 3 */ #define SR2_QUAD_EN_BIT7 BIT(7)
+/* + * Maximum number of flashes that can be connected + * in stacked/parallel configuration + */ +#define SNOR_FLASH_CNT_MAX 4 + /* Supported SPI protocols */ #define SNOR_PROTO_INST_MASK GENMASK(23, 16) #define SNOR_PROTO_INST_SHIFT 16 @@ -378,6 +384,7 @@ struct spi_nor_flash_parameter; * hooks, or dynamically when parsing the SFDP tables. * @dirmap: pointers to struct spi_mem_dirmap_desc for reads/writes. * @priv: pointer to the private data + * @num_flash number of flashes connected in parallel or stacked mode */ struct spi_nor { struct mtd_info mtd; @@ -412,13 +419,13 @@ struct spi_nor {
const struct spi_nor_controller_ops *controller_ops;
- struct spi_nor_flash_parameter *params; + struct spi_nor_flash_parameter *params[SNOR_FLASH_CNT_MAX];
struct { struct spi_mem_dirmap_desc *rdesc; struct spi_mem_dirmap_desc *wdesc; } dirmap; - + u32 num_flash; void *priv; };
@@ -435,13 +442,13 @@ static inline struct device_node *spi_nor_get_flash_node(struct spi_nor *nor)
static inline struct spi_nor_flash_parameter *spi_nor_get_params(const struct spi_nor *nor, u8 idx) { - return nor->params; + return nor->params[idx]; }
static inline void spi_nor_set_params(struct spi_nor *nor, u8 idx, struct spi_nor_flash_parameter *params) { - nor->params = params; + nor->params[idx] = params; } /** * spi_nor_scan() - scan the SPI NOR
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not, wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) {
@@ -2937,6 +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params->n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of same make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories", idx, &flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Cheers, ta
On 12/6/23 14:30, Tudor Ambarus wrote:
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not, wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) {
@@ -2937,6 +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params->n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of same make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories", idx, &flash_size[idx]);
also, it's not clear to me why you read this property multiple times. Have you sent a device tree patch somewhere? It will help me understand what you're trying to achieve.
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Cheers, ta
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:14 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/6/23 14:30, Tudor Ambarus wrote:
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not, wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
mahapatra@amd.com>
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params-
n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of same
make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",
idx,
+&flash_size[idx]);
also, it's not clear to me why you read this property multiple times. Have you sent a device tree patch somewhere? It will help me understand what you're trying to achieve.
Miquel submitted the device tree patch; here is the series. https://lore.kernel.org/all/20220126112608.955728-1-miquel.raynal@bootlin.co...
Regards, Amit
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Cheers, ta
On 12/8/23 17:06, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:14 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/6/23 14:30, Tudor Ambarus wrote:
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not, wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
mahapatra@amd.com>
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params-
n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of same
make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",
idx,
+&flash_size[idx]);
also, it's not clear to me why you read this property multiple times. Have you sent a device tree patch somewhere? It will help me understand what you're trying to achieve.
Miquel submitted the device tree patch; here is the series. https://lore.kernel.org/all/20220126112608.955728-1-miquel.raynal@bootlin.co...
oh, yes, I remember seeing this on the ml, but I couldn't allocate time to review it. Looking at: https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@bootlin.co...
Flash size is not necessary for SPI NORs, as it can be discovered via SFDP. And spi-max-frequency should have been specified for all flashes, as I expect it can differ. At least so that the controller chooses the minimum frequency from all the max (if it can't operate the stacks at different frequencies).
Cheers, ta
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:00 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not,
No, according to the current implementation, in stacked mode, both flashes must be of the same make.
wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
Yes, that is accurate. In alignment with our current stacked support use case we can have an array of flash sizes instead. The primary purpose of having an array of params struct was to facilitate potential future extensions, allowing the addition of stacked support for different flashes
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params- n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of same
make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",
idx,
+&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you anticipate that SPI-NOR should throw an error if the second or any subsequent flash within the stacked connection is different? Or would you prefer it to print a warning and operate in single mode (i.e., only the first flash)?
Regards, Amit
Cheers, ta
On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:00 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not,
No, according to the current implementation, in stacked mode, both flashes must be of the same make.
wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
Yes, that is accurate. In alignment with our current stacked support use case we can have an array of flash sizes instead. The primary purpose of having an array of params struct was to facilitate potential future extensions, allowing the addition of stacked support for different flashes
right. Don't do this change yet, let's decide on the overall architecture first.
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra amit.kumar-mahapatra@amd.com
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++------- drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params- n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of same
make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",
idx,
+&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
anticipate that SPI-NOR should throw an error if the second or any subsequent flash within the stacked connection is different? Or would you prefer it to print a warning and operate in single mode (i.e., only the first flash)?
Both options are fine, but I haven't yet decided on the overall architecture.
Cheers, ta
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Monday, December 11, 2023 9:03 AM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:00 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not,
No, according to the current implementation, in stacked mode, both flashes must be of the same make.
wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
Yes, that is accurate. In alignment with our current stacked support use case we can have an array of flash sizes instead. The primary purpose of having an array of params struct was to facilitate potential future extensions, allowing the addition of stacked support for different flashes
right. Don't do this change yet, let's decide on the overall architecture first.
Sure.
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
mahapatra@amd.com>
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++-----
--
drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params-
n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of
+same
make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",
idx,
+&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle
When you mention "on top," are you referring to incorporating it into the MTD layer? Initially, Miquel had submitted this patch to address stacked/parallel handling in the MTD layer. https://lore.kernel.org/linux-mtd/20200114191052.0a16d116@xps13/t/ However, the Device Tree bindings were initially not accepted. Following a series of discussions, the below bindings were eventually merged. https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@bootlin.co...
the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Controller
anticipate that SPI-NOR should throw an error if the second or any subsequent flash within the stacked connection is different? Or would you prefer it to print a warning and operate in single mode (i.e., only the first flash)?
Both options are fine, but I haven't yet decided on the overall architecture.
Ok.
Regards, Amit
Cheers, ta
On 12/11/23 06:56, Mahapatra, Amit Kumar wrote:
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Monday, December 11, 2023 9:03 AM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
Hello Tudor,
Hi!
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:00 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not,
No, according to the current implementation, in stacked mode, both flashes must be of the same make.
wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
Yes, that is accurate. In alignment with our current stacked support use case we can have an array of flash sizes instead. The primary purpose of having an array of params struct was to facilitate potential future extensions, allowing the addition of stacked support for different flashes
right. Don't do this change yet, let's decide on the overall architecture first.
Sure.
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
mahapatra@amd.com>
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++-----
--
drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params-
n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of
+same
make.
* Except the flash size all other properties are identical for all the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",
idx,
+&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle
When you mention "on top," are you referring to incorporating it into the MTD layer? Initially, Miquel had submitted this patch to address
I mean something above SPI MEM flashes, be it NOR, NANDs or whatever. Instead of treating the stacked flashes as a monolithic device and treat in SPI NOR some array of flashes, to have a layer above which probes the SPI MEM flash driver for each stacked flash. In your case SPI NOR would be probed twice, as you use 2 SPI NOR flashes.
stacked/parallel handling in the MTD layer. https://lore.kernel.org/linux-mtd/20200114191052.0a16d116@xps13/t/ However, the Device Tree bindings were initially not accepted.
Okay, thanks for the pointer. I'll take a look.
Following a series of discussions, the below bindings were eventually merged. https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@bootlin.co...
I saw, thanks.
the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Controller
Wonderful, I'll take a look. I see two clocks there. Does this mean that the stacked flashes can be operated at different frequencies? Do you know if we can combine a SPI NOR with a SPI NAND in stacked configuration?
I need to study this a bit. I'll try to involve Michael and Pratyush too.
Cheers, ta
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Monday, December 11, 2023 3:05 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/11/23 06:56, Mahapatra, Amit Kumar wrote:
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Monday, December 11, 2023 9:03 AM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
Hello Tudor,
Hi!
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:00 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com;
david.rhodes@cirrus.com;
rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not,
No, according to the current implementation, in stacked mode, both flashes must be of the same make.
wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
Yes, that is accurate. In alignment with our current stacked support use case we can have an array of flash sizes instead. The primary purpose of having an array of params struct was to facilitate potential future extensions, allowing the addition of stacked support for different flashes
right. Don't do this change yet, let's decide on the overall architecture first.
Sure.
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
mahapatra@amd.com>
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++-----
--
drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44
@@ static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params-
n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be
of
+same
make.
* Except the flash size all other properties are identical for all
the
* flashes connected in stacked mode.
* The flashes that are connected in parallel mode should be
identical.
*/
- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-
memories",
idx,
+&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle
When you mention "on top," are you referring to incorporating it into the MTD layer? Initially, Miquel had submitted this patch to address
I mean something above SPI MEM flashes, be it NOR, NANDs or whatever. Instead of treating the stacked flashes as a monolithic device and treat in SPI NOR some array of flashes, to have a layer above which probes the SPI MEM flash driver for each stacked flash. In your case SPI NOR would be probed twice, as you use 2 SPI NOR flashes.
stacked/parallel handling in the MTD layer. https://lore.kernel.org/linux-mtd/20200114191052.0a16d116@xps13/t/ However, the Device Tree bindings were initially not accepted.
Okay, thanks for the pointer. I'll take a look.
Following a series of discussions, the below bindings were eventually merged. https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@boot lin.com/
I saw, thanks.
the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Control ler
Wonderful, I'll take a look. I see two clocks there. Does this mean that the stacked flashes can be operated at different frequencies? Do you know if we
In stacked configuration, both flashes utilize a common clock (single clock line). In a parallel setup, the flashes share the same clock but have distinct clock lines. Please refer the diagrams in the sections below for reference. https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface-D...
can combine a SPI NOR with a SPI NAND in stacked configuration?
No, Xilinx/AMD QSPI controllers doesn't support this configuration.
Regards, Amit
I need to study this a bit. I'll try to involve Michael and Pratyush too.
Cheers, ta
On 12/11/23 13:37, Mahapatra, Amit Kumar wrote:
Hi!
cut
> drivers/mtd/spi-nor/core.c | 272 > +++++++++++++++++++++++++++++-----
--
> drivers/mtd/spi-nor/core.h | 4 + > include/linux/mtd/spi-nor.h | 15 +- > 3 files changed, 240 insertions(+), 51 deletions(-) > > diff --git a/drivers/mtd/spi-nor/core.c > b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 > 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c
cut
> @@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct > spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor > *nor) { > struct spi_nor_flash_parameter *params = spi_nor_get_params(nor, 0); > - int ret; > + struct device_node *np = spi_nor_get_flash_node(nor); > + u64 flash_size[SNOR_FLASH_CNT_MAX]; > + u32 idx = 0; > + int rc, ret; > > if (nor->manufacturer && nor->manufacturer->fixups && > nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 > @@ static int spi_nor_late_init_params(struct spi_nor *nor) > if (params->n_banks > 1) > params->bank_size = div64_u64(params->size, params-
n_banks);
> > + nor->num_flash = 0; > + > + /* > + * The flashes that are connected in stacked mode should be
of
> +same make. > + * Except the flash size all other properties are identical for all
the
> + * flashes connected in stacked mode. > + * The flashes that are connected in parallel mode should be
identical.
> + */ > + while (idx < SNOR_FLASH_CNT_MAX) { > + rc = of_property_read_u64_index(np, "stacked-
memories",
idx, > +&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle
When you mention "on top," are you referring to incorporating it into the MTD layer? Initially, Miquel had submitted this patch to address
I mean something above SPI MEM flashes, be it NOR, NANDs or whatever. Instead of treating the stacked flashes as a monolithic device and treat in SPI NOR some array of flashes, to have a layer above which probes the SPI MEM flash driver for each stacked flash. In your case SPI NOR would be probed twice, as you use 2 SPI NOR flashes.
stacked/parallel handling in the MTD layer. https://lore.kernel.org/linux-mtd/20200114191052.0a16d116@xps13/t/ However, the Device Tree bindings were initially not accepted.
Okay, thanks for the pointer. I'll take a look.
haven't yet read the thread from above, but I skimmed over the AMD controller datasheet.
Following a series of discussions, the below bindings were eventually merged. https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@boot lin.com/
I saw, thanks.
the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Control ler
Wonderful, I'll take a look. I see two clocks there. Does this mean that the stacked flashes can be operated at different frequencies? Do you know if we
In stacked configuration, both flashes utilize a common clock (single clock line). In a parallel setup, the flashes share the same clock but have distinct clock lines. Please refer the diagrams in the sections below for reference. https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface-D...
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
can combine a SPI NOR with a SPI NAND in stacked configuration?
No, Xilinx/AMD QSPI controllers doesn't support this configuration.
2 SPI NANDs shall work with the AMD controller, right?
I skimmed over the QSPI controller datasheet and wondered why one would get complicated with 2 Quad Flashes when we have Octal. But then I saw that the same SoC can configure an Octal controller (the Octal and Quad controllers seems mutual exclusive) and that the Octal one can operate 2 octal flashes in stacked mode :).
Cheers, ta
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Tuesday, December 12, 2023 8:33 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/11/23 13:37, Mahapatra, Amit Kumar wrote:
Hi!
cut
>> drivers/mtd/spi-nor/core.c | 272 >> +++++++++++++++++++++++++++++-----
--
>> drivers/mtd/spi-nor/core.h | 4 + >> include/linux/mtd/spi-nor.h | 15 +- >> 3 files changed, 240 insertions(+), 51 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/core.c >> b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 >> 100644 >> --- a/drivers/mtd/spi-nor/core.c >> +++ b/drivers/mtd/spi-nor/core.c > > cut > >> @@ -2905,7 +3007,10 @@ static void >> spi_nor_init_fixup_flags(struct spi_nor *nor) static int >> spi_nor_late_init_params(struct spi_nor >> *nor) { >> struct spi_nor_flash_parameter *params = >> spi_nor_get_params(nor, > 0); >> - int ret; >> + struct device_node *np = spi_nor_get_flash_node(nor); >> + u64 flash_size[SNOR_FLASH_CNT_MAX]; >> + u32 idx = 0; >> + int rc, ret; >> >> if (nor->manufacturer && nor->manufacturer->fixups && >> nor->manufacturer->fixups->late_init) { @@ -2937,6 >> +3042,44 @@ static int spi_nor_late_init_params(struct spi_nor
*nor)
>> if (params->n_banks > 1) >> params->bank_size = div64_u64(params->size,
params-
n_banks);
>> >> + nor->num_flash = 0; >> + >> + /* >> + * The flashes that are connected in stacked mode should be
of
>> +same > make. >> + * Except the flash size all other properties are identical >> +for all
the
>> + * flashes connected in stacked mode. >> + * The flashes that are connected in parallel mode should be
identical.
>> + */ >> + while (idx < SNOR_FLASH_CNT_MAX) { >> + rc = of_property_read_u64_index(np, "stacked-
memories",
> idx, >> +&flash_size[idx]); > > This is a little late in my opinion, as we don't have any sanity > check on the flashes that are stacked on top of the first. We > shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle
When you mention "on top," are you referring to incorporating it into the MTD layer? Initially, Miquel had submitted this patch to address
I mean something above SPI MEM flashes, be it NOR, NANDs or whatever. Instead of treating the stacked flashes as a monolithic device and treat in SPI NOR some array of flashes, to have a layer above which probes the SPI MEM flash driver for each stacked flash. In your case SPI NOR would be probed twice, as you use 2 SPI NOR flashes.
stacked/parallel handling in the MTD layer. https://lore.kernel.org/linux-mtd/20200114191052.0a16d116@xps13/t/ However, the Device Tree bindings were initially not accepted.
Okay, thanks for the pointer. I'll take a look.
haven't yet read the thread from above, but I skimmed over the AMD controller datasheet.
Following a series of discussions, the below bindings were eventually merged. https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@bo ot lin.com/
I saw, thanks.
the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Contr ol ler
Wonderful, I'll take a look. I see two clocks there. Does this mean that the stacked flashes can be operated at different frequencies? Do you know if we
In stacked configuration, both flashes utilize a common clock (single clock line). In a parallel setup, the flashes share the same clock but have distinct clock lines. Please refer the diagrams in the sections below for reference. https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Inter face-Diagrams
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
I used SPI-NOR QSPI flashes for testing stacked and parallel.
can combine a SPI NOR with a SPI NAND in stacked configuration?
No, Xilinx/AMD QSPI controllers doesn't support this configuration.
2 SPI NANDs shall work with the AMD controller, right?
We never tested 2 SPI-NAND with AMD controller.
I skimmed over the QSPI controller datasheet and wondered why one would get complicated with 2 Quad Flashes when we have Octal. But then I saw that the same SoC can configure an Octal controller (the Octal and Quad controllers seems mutual exclusive) and that the Octal one can operate 2 octal flashes in stacked mode :).
Thats correct .
Please let me know how you want me to proceed on this.
Regards, Amit
Cheers, ta
On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
I used SPI-NOR QSPI flashes for testing stacked and parallel.
I got that, I wanted the flash name or device ID.
What I'm interested is if each flash is in its own package. Are they?
can combine a SPI NOR with a SPI NAND in stacked configuration?
No, Xilinx/AMD QSPI controllers doesn't support this configuration.
2 SPI NANDs shall work with the AMD controller, right?
We never tested 2 SPI-NAND with AMD controller.
I was asking because I think the stacked layer shall be SPI MEM generic, and not particular to SPI NOR.
I skimmed over the QSPI controller datasheet and wondered why one would get complicated with 2 Quad Flashes when we have Octal. But then I saw that the same SoC can configure an Octal controller (the Octal and Quad controllers seems mutual exclusive) and that the Octal one can operate 2 octal flashes in stacked mode 🙂.
Thats correct .
Please let me know how you want me to proceed on this.
I got you. Still need to allocate more time on this.
Cheers, ta
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 1:40 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
I used SPI-NOR QSPI flashes for testing stacked and parallel.
I got that, I wanted the flash name or device ID.
N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI flashes on which we tested. Additionally, we conducted tests on over 30 different QSPI flashes from four distinct vendors (Miron, Winbond, Macronix, and ISSI).
What I'm interested is if each flash is in its own package. Are they?
I'm sorry, but I don't quite understand what you mean by "if each flash in its own package."
can combine a SPI NOR with a SPI NAND in stacked configuration?
No, Xilinx/AMD QSPI controllers doesn't support this configuration.
2 SPI NANDs shall work with the AMD controller, right?
We never tested 2 SPI-NAND with AMD controller.
I was asking because I think the stacked layer shall be SPI MEM generic, and not particular to SPI NOR.
Yes, I agree.
I skimmed over the QSPI controller datasheet and wondered why one would get complicated with 2 Quad Flashes when we have Octal. But then I saw that the same SoC can configure an Octal controller (the Octal and Quad controllers seems mutual exclusive) and that the Octal one can operate 2 octal flashes in stacked mode 🙂.
Thats correct .
Please let me know how you want me to proceed on this.
I got you. Still need to allocate more time on this.
Sure.
Regards, Amit
Cheers, ta
On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 1:40 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
I used SPI-NOR QSPI flashes for testing stacked and parallel.
I got that, I wanted the flash name or device ID.
N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI flashes on which we tested. Additionally, we conducted tests on over 30 different QSPI flashes from four distinct vendors (Miron, Winbond, Macronix, and ISSI).
Great.
What I'm interested is if each flash is in its own package. Are they?
I'm sorry, but I don't quite understand what you mean by "if each flash in its own package."
There are flashes that are stacked at the physical level. It's a single flash with multiple dies, that are all under a single physical package.
As I understand, your stacked flash model is at logical level. You have 2 flashes each in its own package. 2 different entities. Is my understanding correct?
Cheers, ta
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 4:03 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux-arm-kernel@lists.infradead.org; alsa- devel@alsa-project.org; patches@opensource.cirrus.com; linux- sound@vger.kernel.org; git (AMD-Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 1:40 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
I used SPI-NOR QSPI flashes for testing stacked and parallel.
I got that, I wanted the flash name or device ID.
N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI
flashes
on which we tested. Additionally, we conducted tests on over 30 different QSPI flashes from four distinct vendors (Miron, Winbond,
Macronix, and ISSI).
Great.
What I'm interested is if each flash is in its own package. Are they?
I'm sorry, but I don't quite understand what you mean by "if each flash in its own package."
There are flashes that are stacked at the physical level. It's a single flash with multiple dies, that are all under a single physical package.
Got it. The W25H02JV QSPI flash I mentioned earlier is a device with with four dies that are stacked at the physical level.
As I understand, your stacked flash model is at logical level. You have 2 flashes each in its own package. 2 different entities. Is my understanding correct?
Yes, that’s correct.
I'd like to contribute to your earlier point regarding the placement of the stacked layer. As you correctly highlighted, it should be in the spi-mem generic layer. For instance, when a read/write operation extends across multiple flashes (whether SPI-NOR or SPI-NAND), the stacked layer must handle the flash crossover. This requires setting the appropriate CS index in mem->spi->cs_index_mask to select the correct slave device and updating the data buffer, address & data length in spi_mem_op struct variable. Does this align with your understanding?
Regards, Amit
Cheers, ta
On 15.12.2023 13:20, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 4:03 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux-arm-kernel@lists.infradead.org; alsa- devel@alsa-project.org; patches@opensource.cirrus.com; linux- sound@vger.kernel.org; git (AMD-Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 1:40 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
Thanks! Can you share with us what flashes you used for testing in the stacked and parallel configurations?
I used SPI-NOR QSPI flashes for testing stacked and parallel.
I got that, I wanted the flash name or device ID.
N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI
flashes
on which we tested. Additionally, we conducted tests on over 30 different QSPI flashes from four distinct vendors (Miron, Winbond,
Macronix, and ISSI).
Great.
What I'm interested is if each flash is in its own package. Are they?
I'm sorry, but I don't quite understand what you mean by "if each flash in its own package."
There are flashes that are stacked at the physical level. It's a single flash with multiple dies, that are all under a single physical package.
Got it. The W25H02JV QSPI flash I mentioned earlier is a device with with four dies that are stacked at the physical level.
As I understand, your stacked flash model is at logical level. You have 2 flashes each in its own package. 2 different entities. Is my understanding correct?
Yes, that’s correct.
I'd like to contribute to your earlier point regarding the placement of the stacked layer. As you correctly highlighted, it should be in the spi-mem generic layer. For instance, when a read/write operation extends across multiple flashes (whether SPI-NOR or SPI-NAND), the stacked layer must handle the flash crossover. This requires setting the appropriate CS index in mem->spi->cs_index_mask to select the correct slave device and updating the data buffer, address & data length in spi_mem_op struct variable. Does this align with your understanding?
This was the initial idea, yes, but we'll have to see how mtd concat fits in. Maybe the abstraction can be made at the mtd level, which I suspect mtd concat does. I have to read that driver, never opened it.
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/-/media/client/global/documents/products/data-s...
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit. Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
I had a short chat with Michael and he highlighted that instead of the parallel mode, one would be better of with an octal device. I wonder whether the quad parallel is worth the effort. I see AMD can select either quad (single/stacked/parallel) or octal (single/stacked). Is the parallel mode considered obsolete for new IPs?
Cheers, ta
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Tuesday, December 19, 2023 1:56 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 15.12.2023 13:20, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 4:03 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux-arm-kernel@lists.infradead.org; alsa- devel@alsa-project.org; patches@opensource.cirrus.com; linux- sound@vger.kernel.org; git (AMD-Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/15/23 10:02, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, December 15, 2023 1:40 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com;
david.rhodes@cirrus.com;
rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 15.12.2023 09:55, Mahapatra, Amit Kumar wrote:
> Thanks! Can you share with us what flashes you used for testing > in the stacked and parallel configurations? I used SPI-NOR QSPI flashes for testing stacked and parallel.
I got that, I wanted the flash name or device ID.
N25Q00A, MX66U2G45G, IS25LP01G & W25H02JV are some of the QSPI
flashes
on which we tested. Additionally, we conducted tests on over 30 different QSPI flashes from four distinct vendors (Miron, Winbond,
Macronix, and ISSI).
Great.
What I'm interested is if each flash is in its own package. Are they?
I'm sorry, but I don't quite understand what you mean by "if each flash in its own package."
There are flashes that are stacked at the physical level. It's a single flash with multiple dies, that are all under a single physical package.
Got it. The W25H02JV QSPI flash I mentioned earlier is a device with with four dies that are stacked at the physical level.
As I understand, your stacked flash model is at logical level. You have 2 flashes each in its own package. 2 different entities. Is my understanding correct?
Yes, that’s correct.
I'd like to contribute to your earlier point regarding the placement of the stacked layer. As you correctly highlighted, it should be in the spi-mem generic layer. For instance, when a read/write operation extends across multiple flashes (whether SPI-NOR or SPI-NAND), the stacked layer must handle the flash crossover. This requires setting the appropriate CS index in mem->spi->cs_index_mask to select the correct slave device and updating the data buffer, address & data length in spi_mem_op struct variable. Does this align with your
understanding?
This was the initial idea, yes, but we'll have to see how mtd concat fits in. Maybe the abstraction can be made at the mtd level, which I suspect mtd concat does. I have to read that driver, never opened it.
I haven't explored the mtd concat driver either.
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/serial- nor/mt25t/generation- b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit.
Yes, I agree.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
Yes, correct.
I had a short chat with Michael and he highlighted that instead of the parallel mode, one would be better of with an octal device. I wonder whether the quad parallel is worth the effort. I see AMD can select either quad (single/stacked/parallel) or octal (single/stacked). Is the parallel mode
Indeed, customers have the flexibility to choose between quad or octal options. However, some opt for a cost-effective strategy by selecting only Quad SPI in their chipset and boosting throughput through the parallel use of two flashes. To gauge the popularity of this configuration, I will consult with our marketing team for further insights. Given that parallel is a controller feature, it can be integrated into the driver file. At present, we can emphasis on implementing support for stacked mode, either through a new interface like mtd/spi-nor/stacked.c or by utilizing the mtd concat driver.
considered obsolete for new IPs?
No, the parallel mode feature is still present in AMD's new IPs.
Regards, Amit
Cheers, ta
On 12/21/23 06:54, Mahapatra, Amit Kumar wrote:
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/serial- nor/mt25t/generation- b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit.
Yes, I agree.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
Yes, correct.
Amit, please help me to assess this. I assume Micron and Microchip is using the same concepts as AMD uses for the "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode".
I was wrong, the AMD datasheet [1] was misleading [2], it described the IOs for both flashes as IO[3:0], but later on in the "Table QSPI Interface Signals" the second flash is described with IO[7:4].
The AMD's 8-bit Dual Flash Parallel Interface is using dedicated CS# and CLK# lines for each flash. As Micron does, isn't it?
Micron says [3] that: "The device contains two quad I/O die, each able to operate independently for a total of eight I/Os. The memory map applies to each die. Each die has internal registers for status, configuration, and device protection that can be set and read independently from one other. Micron recommends that internal configuration settings for the two die be set identically."
it also says that: "When using quad commands in XIO-SPI or when using QIO-SPI, DQ[3:0]/DQ[7:4] are I/O."
So I guess the upper layers just ask for a chunk of memory to be written and the controller handles the cs# lines automatically. How is the AMD controller working, do you have to drive the cs# lines manually, or you just set the parallel mode and the controller takes care of everything?
I assume this is how mchp is handling things, they seem to just set a bit the protocol into the QSPI_IFR.PROTTYP register field and that's all [4]. They even seem to write the registers of both flashes at the same time.
In what regards the AMD's "dual stack interface", AMD is sharing the clock and IO lines and uses dedicated CS# lines for the flashes, whereas Micron shares the CS# and CLK# lines with different IO lines.
Amit, please study the architectures used by mchp, micron and amd and let us know if they are the same or they differ, and if they differ what are the differences.
I added Conor from mchp in cc, I see Nicolas is already there, and Bean from micron.
Thanks, ta
[1] https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface-S... [2] https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv4ry78x... [3] https://media-www.micron.com/-/media/client/global/documents/products/data-s... [4] https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocu...
On 2/9/24 11:06, Tudor Ambarus wrote:
On 12/21/23 06:54, Mahapatra, Amit Kumar wrote:
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/serial- nor/mt25t/generation- b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit.
Yes, I agree.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
Yes, correct.
Amit, please help me to assess this. I assume Micron and Microchip is using the same concepts as AMD uses for the "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode".
I was wrong, the AMD datasheet [1] was misleading [2], it described the IOs for both flashes as IO[3:0], but later on in the "Table QSPI Interface Signals" the second flash is described with IO[7:4].
The AMD's 8-bit Dual Flash Parallel Interface is using dedicated CS# and CLK# lines for each flash. As Micron does, isn't it?
Micron says [3] that: "The device contains two quad I/O die, each able to operate independently for a total of eight I/Os. The memory map applies to each die. Each die has internal registers for status, configuration, and device protection that can be set and read independently from one other. Micron recommends that internal configuration settings for the two die be set identically."
Amit,
I forgot to say my first conclusion about the quote from above. Even if the dies are in the same physical package, micron asks users to configure each die as it is a self-standing entity, IOW to configure each die as it is a flash on its own. To me it looks like 2 concatenated flashes at first look. Thus identical to how AMD controller works. Please clarify this.
it also says that: "When using quad commands in XIO-SPI or when using QIO-SPI, DQ[3:0]/DQ[7:4] are I/O."
and this would be a parallel concatenation of two flashes.
Then it would be good if you let us now the similarities and differences between how amd and mchp controller work, I scrawled few ideas below.
thanks, ta
So I guess the upper layers just ask for a chunk of memory to be written and the controller handles the cs# lines automatically. How is the AMD controller working, do you have to drive the cs# lines manually, or you just set the parallel mode and the controller takes care of everything?
I assume this is how mchp is handling things, they seem to just set a bit the protocol into the QSPI_IFR.PROTTYP register field and that's all [4]. They even seem to write the registers of both flashes at the same time.
In what regards the AMD's "dual stack interface", AMD is sharing the clock and IO lines and uses dedicated CS# lines for the flashes, whereas Micron shares the CS# and CLK# lines with different IO lines.
Amit, please study the architectures used by mchp, micron and amd and let us know if they are the same or they differ, and if they differ what are the differences.
I added Conor from mchp in cc, I see Nicolas is already there, and Bean from micron.
Thanks, ta
[1] https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface-S... [2] https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv4ry78x... [3] https://media-www.micron.com/-/media/client/global/documents/products/data-s... [4] https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocu...
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, February 9, 2024 9:44 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com; Conor Dooley conor.dooley@microchip.com; beanhuo@micron.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 2/9/24 11:06, Tudor Ambarus wrote:
On 12/21/23 06:54, Mahapatra, Amit Kumar wrote:
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/serial- nor/mt25t/generation-
b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit.
Yes, I agree.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
Yes, correct.
Amit, please help me to assess this. I assume Micron and Microchip is using the same concepts as AMD uses for the "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode".
I was wrong, the AMD datasheet [1] was misleading [2], it described the IOs for both flashes as IO[3:0], but later on in the "Table QSPI Interface Signals" the second flash is described with IO[7:4].
The AMD's 8-bit Dual Flash Parallel Interface is using dedicated CS# and CLK# lines for each flash. As Micron does, isn't it?
Micron says [3] that: "The device contains two quad I/O die, each able to operate independently for a total of eight I/Os. The memory map applies to each die. Each die has internal registers for status, configuration, and device protection that can be set and read independently from one
other.
Micron recommends that internal configuration settings for the two die be set identically."
Hello Tudor,
Amit,
I forgot to say my first conclusion about the quote from above. Even if the dies are in the same physical package, micron asks users to configure each die as it is a self-standing entity, IOW to configure each die as it is a flash on its own. To me it looks like 2 concatenated flashes at first look. Thus identical to how AMD controller works. Please clarify this.
That’s correct, the Micron flash that you referred can communicate with the AMD QSPI controller in both parallel and stacked mode.
it also says that: "When using quad commands in XIO-SPI or when using QIO-SPI, DQ[3:0]/DQ[7:4] are I/O."
and this would be a parallel concatenation of two flashes.
That's correct.
Regards, Amit
Then it would be good if you let us now the similarities and differences between how amd and mchp controller work, I scrawled few ideas below.
thanks, ta
So I guess the upper layers just ask for a chunk of memory to be written and the controller handles the cs# lines automatically. How is the AMD controller working, do you have to drive the cs# lines manually, or you just set the parallel mode and the controller takes care of
everything?
I assume this is how mchp is handling things, they seem to just set a bit the protocol into the QSPI_IFR.PROTTYP register field and that's all [4]. They even seem to write the registers of both flashes at the same
time.
In what regards the AMD's "dual stack interface", AMD is sharing the clock and IO lines and uses dedicated CS# lines for the flashes, whereas Micron shares the CS# and CLK# lines with different IO lines.
Amit, please study the architectures used by mchp, micron and amd and let us know if they are the same or they differ, and if they differ what are the differences.
I added Conor from mchp in cc, I see Nicolas is already there, and Bean from micron.
Thanks, ta
[1] https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Inter face-Signals [2]
https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv
4ry78xM0_EF5kv4mA [3] https://media-www.micron.com/-
/media/client/global/documents/products/
data-sheet/nor-flash/serial-nor/mt25t/generation-b/mt25t_qljs_l_512_xb a_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500 [4]
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ Produ
ctDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf
-----Original Message----- From: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com Sent: Wednesday, March 13, 2024 9:34 PM To: Tudor Ambarus tudor.ambarus@linaro.org; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com; Conor Dooley conor.dooley@microchip.com; beanhuo@micron.com Subject: RE: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, February 9, 2024 9:44 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com;
linux-
arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com; Conor Dooley conor.dooley@microchip.com; beanhuo@micron.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hello Everyone,
I would like to propose another approach for handling stacked and parallel connection modes and would appreciate your thoughts on it. But before that, here is some background on what we are trying to achieve.
The AMD QSPI controller supports two advanced connection modes(Stacked and Dual Parallel) which allow the controller to treat two different flashes as one storage.
Stacked: Flashes share the same SPI bus, but different CS line, controller asserts the CS of the flash to which it needs to communicate.
Dual Parallel: Both the flashes have their separate SPI bus CS of both the flashes will be asserted/de-asserted at the same time. In this mode data will be split across both the flashes by enabling the STRIPE setting in the controller. If STRIPE is not enabled, then same data will be sent to both the devices.
For more information on the modes please feel free to go through the controller flash interface below https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Interfa...
Mirochip QSPI controller also supports "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode". https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocu...
DT binding changes were added through the following commits: https://github.com/torvalds/linux/commit/f89504300e94524d5d5846ff8b728592ac7... https://github.com/torvalds/linux/commit/eba5368503b4291db7819512600fa014ea1... https://github.com/torvalds/linux/commit/e2edd1b64f1c79e8abda365149ed62a2a9a...
SPI core changes were adds through the following commit: https://github.com/torvalds/linux/commit/4d8ff6b0991d5e86b17b235fc46ec62e919...
Based on the inputs/suggestions from Tudor, i am planning to add a new layer between the SPI-NOR and MTD layers to support stacked and parallel configurations. This new layer will be part of the spi-nor and located in mtd/spi-nor/
This layer would perform the following tasks: - During probing, store information from all the connected flashes, whether in stacked or parallel mode, and present it as a single device to the MTD layer. - Register callbacks through this new layer instead of spi-nor/core.c and handle MTD device registration. - In stacked mode, select the appropriate spi-nor flash based on the address provided by the MTD layer during flash operations. - Manage flash crossover operations in stacked mode. - Ensure both connected flashes are identical in parallel mode. - Handle odd byte count requests from the MTD layer during flash operations in parallel mode.
For implementing this the current DT binding need to be updated as follows.
stacked-memories DT changes: - Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding. - Each stacked flash will have its own flash node. This approach allows flashes of different makes and sizes to be stacked together, as each flash will be probed individually. - The stacked-memories DT bindings will contain the phandles of the flash nodes connected in stacked mode.
spi@0 {
flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; stacked-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; };
}
flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } }
parallel-memories DT changes: - Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding. - Each flash connected in parallel mode will have its own flash node. This allows us to verify that both flashes connected in parallel are identical, as each flash node will be probed separately. - The parallel-memories DT bindings will contain the phandles of the flash nodes connected in parallel.
spi@0 {
flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; parallel-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; };
}
flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } }
Regards, Amit
On 2/9/24 11:06, Tudor Ambarus wrote:
On 12/21/23 06:54, Mahapatra, Amit Kumar wrote:
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/seria l- nor/mt25t/generation-
b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit.
Yes, I agree.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
Yes, correct.
Amit, please help me to assess this. I assume Micron and Microchip is using the same concepts as AMD uses for the "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode".
I was wrong, the AMD datasheet [1] was misleading [2], it described the IOs for both flashes as IO[3:0], but later on in the "Table QSPI Interface Signals" the second flash is described with IO[7:4].
The AMD's 8-bit Dual Flash Parallel Interface is using dedicated CS# and CLK# lines for each flash. As Micron does, isn't it?
Micron says [3] that: "The device contains two quad I/O die, each able to operate independently for a total of eight I/Os. The memory map applies to each die. Each die has internal registers for status, configuration, and device protection that can be set and read independently from one
other.
Micron recommends that internal configuration settings for the two die be set identically."
Hello Tudor,
Amit,
I forgot to say my first conclusion about the quote from above. Even if the dies are in the same physical package, micron asks users to configure each die as it is a self-standing entity, IOW to configure each die as it is a flash on its own. To me it looks like 2 concatenated flashes at first look. Thus identical to how AMD controller
works.
Please clarify this.
That’s correct, the Micron flash that you referred can communicate with the AMD QSPI controller in both parallel and stacked mode.
it also says that: "When using quad commands in XIO-SPI or when using QIO-SPI, DQ[3:0]/DQ[7:4] are I/O."
and this would be a parallel concatenation of two flashes.
That's correct.
Regards, Amit
Then it would be good if you let us now the similarities and differences between how amd and mchp controller work, I scrawled few
ideas below.
thanks, ta
So I guess the upper layers just ask for a chunk of memory to be written and the controller handles the cs# lines automatically. How is the AMD controller working, do you have to drive the cs# lines manually, or you just set the parallel mode and the controller takes care of
everything?
I assume this is how mchp is handling things, they seem to just set a bit the protocol into the QSPI_IFR.PROTTYP register field and that's all [4]. They even seem to write the registers of both flashes at the same
time.
In what regards the AMD's "dual stack interface", AMD is sharing the clock and IO lines and uses dedicated CS# lines for the flashes, whereas Micron shares the CS# and CLK# lines with different IO lines.
Amit, please study the architectures used by mchp, micron and amd and let us know if they are the same or they differ, and if they differ what are the differences.
I added Conor from mchp in cc, I see Nicolas is already there, and Bean from micron.
Thanks, ta
[1] https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Int er face-Signals [2]
https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv
4ry78xM0_EF5kv4mA [3] https://media-www.micron.com/-
/media/client/global/documents/products/
data-sheet/nor-flash/serial-nor/mt25t/generation-b/mt25t_qljs_l_512_ xb a_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500 [4]
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/
Produ
ctDocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf
Hi,
Hello Everyone,
I would like to propose another approach for handling stacked and parallel connection modes and would appreciate your thoughts on it. But before that, here is some background on what we are trying to achieve.
The AMD QSPI controller supports two advanced connection modes(Stacked and Dual Parallel) which allow the controller to treat two different flashes as one storage.
Stacked: Flashes share the same SPI bus, but different CS line, controller asserts the CS of the flash to which it needs to communicate.
Dual Parallel: Both the flashes have their separate SPI bus CS of both the flashes will be asserted/de-asserted at the same time. In this mode data will be split across both the flashes by enabling the STRIPE setting in the controller. If STRIPE is not enabled, then same data will be sent to both the devices.
For more information on the modes please feel free to go through the controller flash interface below https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Interfa...
Mirochip QSPI controller also supports "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode". https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocu...
DT binding changes were added through the following commits: https://github.com/torvalds/linux/commit/f89504300e94524d5d5846ff8b728592ac7... https://github.com/torvalds/linux/commit/eba5368503b4291db7819512600fa014ea1... https://github.com/torvalds/linux/commit/e2edd1b64f1c79e8abda365149ed62a2a9a...
SPI core changes were adds through the following commit: https://github.com/torvalds/linux/commit/4d8ff6b0991d5e86b17b235fc46ec62e919...
Based on the inputs/suggestions from Tudor, i am planning to add a new layer between the SPI-NOR and MTD layers to support stacked and parallel configurations. This new layer will be part of the spi-nor and located in mtd/spi-nor/
For now I don't think you need a totally generic implementation. As long as there is only one controller supporting these modes, I'd say this is not super relevant.
This layer would perform the following tasks:
- During probing, store information from all the connected flashes, whether in stacked or parallel mode, and present it as a single device to the MTD layer.
- Register callbacks through this new layer instead of spi-nor/core.c and handle MTD device registration.
- In stacked mode, select the appropriate spi-nor flash based on the address provided by the MTD layer during flash operations.
- Manage flash crossover operations in stacked mode.
- Ensure both connected flashes are identical in parallel mode.
- Handle odd byte count requests from the MTD layer during flash operations in parallel mode.
For implementing this the current DT binding need to be updated as follows.
So you want to go back to step 1 and redefine bindings? Is that worth?
stacked-memories DT changes:
- Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding.
- Each stacked flash will have its own flash node. This approach allows flashes of different makes and sizes to be stacked together, as each flash will be probed individually.
And how will you define partitions crossing device boundaries? I believe this constraint has been totally forgotten in this proposal. The whole idea of stacking two devices this way was to simplify the user's life with a single device exposed and the controller handling itself the CS changes. That is precisely what the current binding do. The final goal being to double your storage transparently. If your goal was to put two chips aside, then none of this was actually needed. If you don't care about that anymore, then all the energy put into discussing the bindings initially was useless and a controller property could also have made the trick.
- The stacked-memories DT bindings will contain the phandles of the flash nodes connected in stacked mode.
spi@0 {
flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; stacked-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; };
}
flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } }
parallel-memories DT changes:
- Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding.
- Each flash connected in parallel mode will have its own flash node. This allows us to verify that both flashes connected in parallel are identical, as each flash node will be probed separately.
Well, you don't have to verify that. It's a basic hardware design constraint for using this mode.
Otherwise same comment as above, this description doesn't allow correct partitioning and that was one of the main constraints back when we discussed these needs.
- The parallel-memories DT bindings will contain the phandles of the flash nodes connected in parallel.
spi@0 {
flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; parallel-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; };
}
flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } }
Thanks, Miquèl
Hiya,
Amit, the thread becomes unreadable, better start a new one describing what you plan to do.
On 8/12/24 9:38 AM, Miquel Raynal wrote:
For now I don't think you need a totally generic implementation. As long as there is only one controller supporting these modes, I'd say this is not super relevant.
Miquel,
Microchip supports a twin quad mode too, and micron has some flashes with similar architecture, see:
https://lore.kernel.org/linux-mtd/20231125092137.2948-1-amit.kumar-mahapatra...
We shall consider them from the beginning. I guess we need to read everything all over again.
Hello Miquel,
Based on the inputs/suggestions from Tudor, i am planning to add a new layer between the SPI-NOR and MTD layers to support stacked and parallel configurations. This new layer will be part of the spi-nor and located in mtd/spi-nor/
For now I don't think you need a totally generic implementation. As long as there is only one controller supporting these modes, I'd say this is not super relevant.
IMHO, there should be a general solution since this isn't limited to just one controller. Any controller can support stacked mode with multiple native-cs or multiple gpio-cs, or with a combination of a native-cs and a gpio-cs. For parallel configurations, there are other controllers from Microchip and some flash devices that operate similarly to AMD's parallel mode.
This layer would perform the following tasks:
- During probing, store information from all the connected flashes, whether in stacked or parallel mode, and present it as a single device to the MTD layer.
- Register callbacks through this new layer instead of spi-nor/core.c and handle MTD device registration.
- In stacked mode, select the appropriate spi-nor flash based on the address provided by the MTD layer during flash operations.
- Manage flash crossover operations in stacked mode.
- Ensure both connected flashes are identical in parallel mode.
- Handle odd byte count requests from the MTD layer during flash operations in parallel mode.
For implementing this the current DT binding need to be updated as follows.
So you want to go back to step 1 and redefine bindings? Is that worth?
The current bindings are effective if we only support identical flash devices or flashes of the same make but with different sizes connected in stacked mode. However, if we want to extend stacked support to include flashes of different makes in stacked mode, the current bindings may not be adequate. That's why I suggested updating the bindings to accommodate all possible scenario.
stacked-memories DT changes:
- Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding.
- Each stacked flash will have its own flash node. This approach allows flashes of different makes and sizes to be stacked together, as each flash will be probed individually.
And how will you define partitions crossing device boundaries? I believe this constraint has been totally forgotten in this proposal.
According to the new binding proposal, one of the two flash nodes will have a partition that crosses the device boundary.
The whole idea of stacking two devices this way was to simplify the user's life with a single device exposed and the controller handling itself the CS changes. That is precisely what the current binding do.
That's true, but as I mentioned earlier, if we're not inclined to support stacked mode for flashes of different makes, then the current bindings are sufficient.
The final goal being to double your storage transparently. If your goal was to put two chips aside, then none of this was actually needed. If you don't care about that anymore, then all the energy put into discussing the bindings initially was useless and a controller property could also have made the trick.
- The stacked-memories DT bindings will contain the phandles of the flash nodes connected in stacked mode.
spi@0 {
flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; stacked-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; };
}
flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } }
parallel-memories DT changes:
- Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding.
- Each flash connected in parallel mode will have its own flash node. This allows us to verify that both flashes connected in parallel are identical, as each flash node will be probed separately.
Well, you don't have to verify that. It's a basic hardware design constraint for using this mode.
Agree
Regards, Amit
Otherwise same comment as above, this description doesn't allow correct partitioning and that was one of the main constraints back when we discussed these needs.
- The parallel-memories DT bindings will contain the phandles of the flash nodes connected in parallel.
spi@0 {
flash@0 { compatible = "jedec,spi-nor" reg = <0x00>; parallel-memories = <&flash@0 &flash@1>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-0"; reg = <0x0 0xf00000>; };
}
flash@1 { compatible = "jedec,spi-nor" reg = <0x01>; spi-max-frequency = <50000000>; ... partition@0 { label = "qspi-1"; reg = <0x0 0x800000>; }; } }
Thanks, Miquèl
Hi Amit,
amit.kumar-mahapatra@amd.com wrote on Wed, 14 Aug 2024 07:13:35 +0000:
Hello Miquel,
Based on the inputs/suggestions from Tudor, i am planning to add a new layer between the SPI-NOR and MTD layers to support stacked and parallel configurations. This new layer will be part of the spi-nor and located in mtd/spi-nor/
For now I don't think you need a totally generic implementation. As long as there is only one controller supporting these modes, I'd say this is not super relevant.
IMHO, there should be a general solution since this isn't limited to just one controller. Any controller can support stacked mode with multiple native-cs or multiple gpio-cs, or with a combination of a native-cs and a gpio-cs.
That's not what was initially discussed. The Xilinx use case was: a controller is managing two devices "at the same time" transparently from the host. So the two flashes appear like a single one and thus, are described like a single one.
You don't need anything in the bindings nor in the core to manage two flashes connected to the same controller otherwise. The only use case the Xilinx model was bringing, was to consider the storage bigger from a host perspective and thus be able to store files across the device boundary natively.
For parallel configurations, there are other controllers from Microchip and some flash devices that operate similarly to AMD's parallel mode.
Yes, Tudor reminded me about these.
This layer would perform the following tasks:
- During probing, store information from all the connected flashes, whether in stacked or parallel mode, and present it as a single device to the MTD layer.
- Register callbacks through this new layer instead of spi-nor/core.c and handle MTD device registration.
- In stacked mode, select the appropriate spi-nor flash based on the address provided by the MTD layer during flash operations.
- Manage flash crossover operations in stacked mode.
- Ensure both connected flashes are identical in parallel mode.
- Handle odd byte count requests from the MTD layer during flash operations in parallel mode.
For implementing this the current DT binding need to be updated as follows.
So you want to go back to step 1 and redefine bindings? Is that worth?
The current bindings are effective if we only support identical flash devices or flashes of the same make but with different sizes connected in stacked mode. However, if we want to extend stacked support to include flashes of different makes in stacked mode,
The only actual feature the stacked mode brings is the ability to consider two devices like one. This is abstracted by hardware, this is a controller capability. The only way this can work is if the two storage devices are of the same kind and accept the same commands/init cycles.
If you consider two different devices, then there is no hardware abstraction anymore, the controller is no longer "smart" enough and you are back to the standard situation with two devices connected using their own independent CS, known by the host. In this case the "stacked-mode" bindings no longer apply. You need to describe the two chips independently in the DT, and your stacked feature in the controller can no longer be used.
You need other bindings to support this case because it is a different situation. For this case, there was a mtd-concat approach (which was never merged). But this is really something different than the stacked mode in your controller because there is no specific hardware feature involved, it's just pure software.
the current bindings may not be adequate. That's why I suggested updating the bindings to accommodate all possible scenario.
stacked-memories DT changes:
- Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding.
- Each stacked flash will have its own flash node. This approach allows flashes of different makes and sizes to be stacked together, as each flash will be probed individually.
And how will you define partitions crossing device boundaries? I believe this constraint has been totally forgotten in this proposal.
According to the new binding proposal, one of the two flash nodes will have a partition that crosses the device boundary.
From a bindings perspective, it feels very awkward and I doubt it will be accepted. From a code perspective, you're gonna need to butcher the core...
The whole idea of stacking two devices this way was to simplify the user's life with a single device exposed and the controller handling itself the CS changes. That is precisely what the current binding do.
That's true, but as I mentioned earlier, if we're not inclined to support stacked mode for flashes of different makes, then the current bindings are sufficient.
Thanks, Miquèl
Hello Miquel,
That's not what was initially discussed. The Xilinx use case was: a controller is managing two devices "at the same time" transparently from
Yes, but in stacked mode, the controller communicates with one of the two connected flash devices at any given time, based on the address and data length. It doesn't assert both chip selects simultaneously.
the host. So the two flashes appear like a single one and thus, are described like a single one.
You don't need anything in the bindings nor in the core to manage two flashes connected to the same controller otherwise. The only use case the Xilinx model was bringing, was to consider the storage bigger from a host perspective and thus be able to store files across the device boundary natively.
When adding stacked support to the SPI core, Mark also asked us to support the GPIO chip select use case, so it is not only restricted to native cs.
For parallel configurations, there are other controllers from Microchip and some flash devices that operate similarly to AMD's parallel mode.
Yes, Tudor reminded me about these.
This layer would perform the following tasks:
- During probing, store information from all the connected flashes, whether in stacked or parallel mode, and present it as a single device to the MTD layer.
- Register callbacks through this new layer instead of spi-nor/core.c and handle MTD device registration.
- In stacked mode, select the appropriate spi-nor flash based on the address provided by the MTD layer during flash operations.
- Manage flash crossover operations in stacked mode.
- Ensure both connected flashes are identical in parallel mode.
- Handle odd byte count requests from the MTD layer during flash operations in parallel mode.
For implementing this the current DT binding need to be updated as follows.
So you want to go back to step 1 and redefine bindings? Is that worth?
The current bindings are effective if we only support identical flash devices or flashes of the same make but with different sizes connected in stacked mode. However, if we want to extend stacked support to include flashes of different makes in stacked mode,
The only actual feature the stacked mode brings is the ability to consider two devices like one. This is abstracted by hardware, this is a controller capability.
Stacked mode is a software abstraction rather than a controller feature or capability. At any given time, the controller communicates with one of the two connected flash devices, as determined by the requested address and data length. If an operation starts on one flash and ends on the other, the core needs to split it into two separate operations and adjust the data length accordingly.
The only way this can work is if the two storage devices are of the same kind and accept the same commands/init cycles.
If you consider two different devices, then there is no hardware abstraction anymore, the controller is no longer "smart" enough and you are back to the standard situation with two devices connected using their own independent CS, known by the host. In this case the "stacked-mode" bindings no longer apply. You need to describe the two chips independently in the DT, and your stacked feature in the controller can no longer be used.
As stated earlier stacked is not a controller feature but rather a software abstraction to assert the appropriate cs as per the requested address & data length.
Regards, Amit
You need other bindings to support this case because it is a different situation. For this case, there was a mtd-concat approach (which was never merged). But this is really something different than the stacked mode in your controller because there is no specific hardware feature involved, it's just pure software.
the current bindings may not be adequate. That's why I suggested updating the bindings to accommodate all possible scenario.
stacked-memories DT changes:
- Flash size information can be retrieved directly from the flash, so it has been removed from the DT binding.
- Each stacked flash will have its own flash node. This approach allows flashes of different makes and sizes to be stacked together, as each flash will be probed individually.
And how will you define partitions crossing device boundaries? I believe this constraint has been totally forgotten in this proposal.
According to the new binding proposal, one of the two flash nodes will have a partition that crosses the device boundary.
From a bindings perspective, it feels very awkward and I doubt it will be accepted. From a code perspective, you're gonna need to butcher the core...
The whole idea of stacking two devices this way was to simplify the user's life with a single device exposed and the controller handling itself
the CS changes.
That is precisely what the current binding do.
That's true, but as I mentioned earlier, if we're not inclined to support stacked mode for flashes of different makes, then the current bindings are sufficient.
Thanks, Miquèl
Hi Amit,
For implementing this the current DT binding need to be updated as follows.
So you want to go back to step 1 and redefine bindings? Is that worth?
The current bindings are effective if we only support identical flash devices or flashes of the same make but with different sizes connected in stacked mode. However, if we want to extend stacked support to include flashes of different makes in stacked mode,
The only actual feature the stacked mode brings is the ability to consider two devices like one. This is abstracted by hardware, this is a controller capability.
Stacked mode is a software abstraction rather than a controller feature or capability. At any given time, the controller communicates with one of the two connected flash devices, as determined by the requested address and data length. If an operation starts on one flash and ends on the other, the core needs to split it into two separate operations and adjust the data length accordingly.
I'm sorry, that was not my understanding, cf the initial RFC:
Subject: [RFC PATCH 0/3] Dual stacked/parallel memories bindings Date: Fri, 12 Nov 2021 16:24:08 +0100
"[...] supporting specific SPI controller modes like Xilinx's where the controller can highly abstract the hardware and provide access to a single bigger device instead [...]"
Furthermore, I rapidly checked the Zynq7000 TRM, it suggests that the controller is capable of addressing the right memory itself based on the address, especially in linear mode?
https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Dual-SS-4-bit-Stacked-I...
"The lower SPI flash memory should always be connected if the linear Quad-SPI memory subsystem is used, and the upper flash memory is optional. Total address space is 32 MB with a 25-bit address. In IO mode, the MSB of the address is defined by U_PAGE which is located at bit 28 of register 0xA0 . In Linear address mode, AXI address bit 24 determines the upper or lower memory page. All of the commands will be executed by the device selected by U_PAGE in I/O mode and address bit 24 in linear mode."
Anyway, you may decide to go down the "pure software" route, which is probably easier from an implementation perspective, but means you're gonna have to argue -again- in favor of the representation of a purely virtual device that is not hardware.
Cheers, Miquèl
Hello Miquel,
Hi Amit,
For implementing this the current DT binding need to be updated as follows.
So you want to go back to step 1 and redefine bindings? Is that worth?
The current bindings are effective if we only support identical flash devices or flashes of the same make but with different sizes connected in stacked mode. However, if we want to extend stacked support to include flashes of different makes in stacked mode,
The only actual feature the stacked mode brings is the ability to consider two devices like one. This is abstracted by hardware, this is a
controller capability.
Stacked mode is a software abstraction rather than a controller feature or capability. At any given time, the controller communicates with one of the two connected flash devices, as determined by the requested address and data length. If an operation starts on one flash and ends on the other, the core needs to split it into two separate operations and adjust the data length accordingly.
I'm sorry, that was not my understanding, cf the initial RFC:
Subject: [RFC PATCH 0/3] Dual stacked/parallel memories bindings Date: Fri, 12 Nov 2021 16:24:08 +0100
"[...] supporting specific SPI controller modes like Xilinx's where the controller can highly abstract the hardware and provide access to a single bigger device instead [...]"
Furthermore, I rapidly checked the Zynq7000 TRM, it suggests that the controller is capable of addressing the right memory itself based on the address, especially in linear mode?
Yes, this is true only when operating in Linear Mode. In this mode, the Zynq 7000 can only perform read operations. Erase and write operations are possible only in I/O mode, so while operating in I/O mode the CS pins must be manually asserted by the driver according to the address and data length
https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Dual-SS- 4-bit-Stacked-I/O
"The lower SPI flash memory should always be connected if the linear Quad-SPI memory subsystem is used, and the upper flash memory is optional. Total address space is 32 MB with a 25-bit address. In IO mode, the MSB of the address is defined by U_PAGE which is located at bit 28 of register 0xA0 . In Linear address mode, AXI address bit 24 determines the upper or lower memory page. All of the commands will be executed by the device selected by U_PAGE in I/O mode and address bit 24 in linear mode."
Anyway, you may decide to go down the "pure software" route, which is probably easier from an implementation perspective, but means you're gonna have to argue -again- in favor of the representation of a purely virtual device that is not hardware.
Yes, that's correct, but I was planning to manage it through a new layer rather than using mtd-concat. As Tudor mentioned, I will start a new email thread outlining my proposal so we can resume the discussion on the patch moving forward.
Regards, Amit
Cheers, Miquèl
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Friday, February 9, 2024 4:36 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com; Conor Dooley conor.dooley@microchip.com; beanhuo@micron.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
On 12/21/23 06:54, Mahapatra, Amit Kumar wrote:
Something else to consider: I see that Micron has a twin quad mode: https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/serial- nor/mt25t/generation-
b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500
The micron's "Separate Chip-Select and Clock Signals" resembles the AMD's dual parallel 8-bit.
Yes, I agree.
Micron's "Shared Chip-Select and Clock Signals" differs from the AMD's stacked mode, as Micron uses DQ[3:0] and DQ[7:4], whereas AMD considers both as DQ[3:0].
Yes, correct.
Amit, please help me to assess this. I assume Micron and Microchip is using the same concepts as AMD uses for the "Dual Parallel 8-bit IO mode", but they call it "Twin Quad Mode".
That's accurate. It's the same concept.
I was wrong, the AMD datasheet [1] was misleading [2], it described the IOs for both flashes as IO[3:0], but later on in the "Table QSPI Interface Signals" the second flash is described with IO[7:4].
That’s correct.
The AMD's 8-bit Dual Flash Parallel Interface is using dedicated CS# and CLK# lines for each flash. As Micron does, isn't it?
Correct.
Micron says [3] that: "The device contains two quad I/O die, each able to operate independently for a total of eight I/Os. The memory map applies to each die. Each die has internal registers for status, configuration, and device protection that can be set and read independently from one other. Micron recommends that internal configuration settings for the two die be set identically."
it also says that: "When using quad commands in XIO-SPI or when using QIO-SPI, DQ[3:0]/DQ[7:4] are I/O."
So I guess the upper layers just ask for a chunk of memory to be written and the controller handles the cs# lines automatically. How is the AMD controller working, do you have to drive the cs# lines manually, or you just set the parallel mode and the controller takes care of everything?
https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Word-Format In parallel mode, the driver sets both the CS_LOWER and CS_UPPER bits in the Cmd_FIFO_Data register(please refer the above link), and sets BUS_SEL to 2’b11 to utilize all 8 IO lines. The controller then manages the assertion and de-assertion of the CS# lines.
I assume this is how mchp is handling things, they seem to just set a bit the protocol into the QSPI_IFR.PROTTYP register field and that's all [4]. They even seem to write the registers of both flashes at the same time.
Yes, that's accurate, but the key distinction is that in Microchip, the QSPI controller has one CS# (referred to as QCS), whereas the AMD QSPI controller has 2 CS#(referred to as CS0 & CS1).
Regards, Amit
In what regards the AMD's "dual stack interface", AMD is sharing the clock and IO lines and uses dedicated CS# lines for the flashes, whereas Micron shares the CS# and CLK# lines with different IO lines.
Amit, please study the architectures used by mchp, micron and amd and let us know if they are the same or they differ, and if they differ what are the differences.
I added Conor from mchp in cc, I see Nicolas is already there, and Bean from micron.
Thanks, ta
[1] https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Interface- Signals [2] https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv 4ry78xM0_EF5kv4mA [3] https://media-www.micron.com/- /media/client/global/documents/products/data-sheet/nor-flash/serial- nor/mt25t/generation- b/mt25t_qljs_l_512_xba_0.pdf?rev=de70b770c5dc4da8b8ead06b57c03500 [4] https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ ProductDocuments/DataSheets/SAMA7G5-Series-Data-Sheet- DS60001765.pdf
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Too much restrictions, isn't it? Have you thought about adding a layer on top of SPI NOR managing the stacked/parallel flashes?
On Sat, 25 Nov 2023 14:51:27 +0530, Amit Kumar Mahapatra wrote:
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support.
The first nine patches https://lore.kernel.org/all/20230119185342.2093323-1-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-2-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-3-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-4-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-5-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-6-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-7-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-8-amit.kumar-mahapatra@am... https://lore.kernel.org/all/20230310173217.3429788-9-amit.kumar-mahapatra@am... of the previous series got applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next But the rest of the patches in the series did not get applied as failure was reported for spi driver with GPIO CS, so send the remaining patches in the series after rebasing it on top of for-next branch and fixing the issue.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[02/10] ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select commit: f05e2f61fe88092e0d341ea27644a84e3386358d [03/10] spi: Add multi-cs memories support in SPI core commit: 4d8ff6b0991d5e86b17b235fc46ec62e9195cb9b
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support.
Honestly, I'm not thrilled about how this is implemented in the core and what the restrictions are. First, the pattern "if (n==1) then { old behavior } else { copy old code modify for n==2 }" is hard to maintain. There should be no copy and the old code shall be adapted to work for both n=1 and n>1.
But I agree with Tudor, some kind of abstraction (layer) would be nice.
Also, you hardcode n=2 everywhere. Please generalize that one.
Are you aware of any other controller supporting such a feature? I've seen you also need to modify the spi controller and intercept some commands. Can everything be moved there?
I'm not sure we are implementing controller specific things in the core. Hard to judge without seeing other controllers doing a similar thing. I'd like to avoid that.
If we had some kind of abstraction here, that might be easier to adapt in the future, but just putting everything into the core will make it really hard to maintain. So if everything related to stacked and parallel memory would be in drivers/mtd/spi-nor/stacked.c, we'd have at least everything in one place with a proper interface between that and the core.
-michael
Hello Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: Tuesday, December 12, 2023 6:05 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com Cc: broonie@kernel.org; tudor.ambarus@linaro.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com; linux- spi@vger.kernel.org; linux-kernel@vger.kernel.org; linux- mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux-arm-kernel@lists.infradead.org; alsa- devel@alsa-project.org; patches@opensource.cirrus.com; linux- sound@vger.kernel.org; git (AMD-Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 00/10] spi: Add support for stacked/parallel memories
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support.
Honestly, I'm not thrilled about how this is implemented in the core and what the restrictions are. First, the pattern "if (n==1) then { old behavior } else { copy old code modify for n==2 }" is hard to maintain. There should be no copy and the old code shall be adapted to work for both n=1 and n>1.
Stacked mode serves as an extension of single device mode concerning data handling and CS line assertion. In both scenarios, the driver only asserts one CS line at any given time. The existing code has been expanded to determine the CS line to be asserted based on the requested address and data length. This modification accommodates both single (legacy) and stacked use cases.
In contrast, parallel mode differs from the legacy (single) mode in terms of data handling. In parallel mode, each byte of data is stored in both devices, with even bits in the lower flash and odd bits in the upper flash. During the transfer, multiple CS lines need to be asserted simultaneously. Consequently, special handling is necessary for parallel mode.
But I agree with Tudor, some kind of abstraction (layer) would be nice.
I agree too.
Also, you hardcode n=2 everywhere. Please generalize that one.
Are you aware of any other controller supporting such a feature? I've seen
Currently, I am familiar only with the AMD-Xilinx QSPI controllers that support parallel/stacked configurations and AMD-Xilinx OSPI controllers, which support stacked configuration. However, it's important to highlight certain aspects of these configurations. In parallel mode, each byte of data is stored in both flash devices, and the QSPI controller automatically handles the byte split and the simultaneous assertion/de-assertion of multiple CS lines. Hence, it can be stated that parallel operation is a controller feature, and other controllers wishing to operate flashes in parallel mode should be capable of data splitting and asserting multiple CS lines simultaneously. This characteristic might be specific to the AMD-Xilinx controller.
In contrast, in stacked mode, only one CS pin is asserted at any given time, determined by the memory address and the accessed data length. Stacked mode, unlike parallel mode, functions as a software abstraction. Once implemented, any SPI controller with multiple CS lines or with a combination of native-CS and GPIO-CS can operate two or more flashes in stacked mode.
you also need to modify the spi controller and intercept some commands.
Command interception occurs exclusively in parallel mode, not in stacked mode. In parallel mode, data must be split during flash memory read/write operations. However, during Flash register read/write operations, there should be no data split, as the identical data needs to be written to (or read from) the register of both flashes. Consequently, the driver has to intercept the command before activating the data split feature of the controller.
Can everything be moved there?
In stacked mode, determining which flash device needs to be asserted is based on the flash address and the length of the requested data. This information is handled by the spi-nor core. If the operation spans across multiple flashes, the command, address, dummy (if required), and residual data must be issued to multiple flashes. This process should be carried out in the spi-nor core layer( or before spi-mem) and not in the driver.
That is why >
I'm not sure we are implementing controller specific things in the core. Hard
As explained earlier the parallel mode of operation can be controller specific, But the stacked mode is controller independent.
to judge without seeing other controllers doing a similar thing. I'd like to avoid that.
If we had some kind of abstraction here, that might be easier to adapt in the future, but just putting everything into the core will make it really hard to maintain. So if everything related to stacked and parallel memory would be in drivers/mtd/spi-nor/stacked.c, we'd have at least everything in one place with a proper interface between that and the core.
I agree.
Regards Amit
-michael
----- Ursprüngliche Mail -----
Von: "Amit Kumar Mahapatra" amit.kumar-mahapatra@amd.com
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support.
I wish the series had a real cover letter which explains the big picture in more detail.
What I didn't really get so far, is it really necessary to support multiple chip selects within a single mtd? You changes introduce hard to maintain changes into the spi-nor/mtd core code which alert me. Why can't we have one mtd for each cs and, if needed, combine them later? We have drivers such as mtdconcat for reasons.
Thanks, //richard
Hi Richard,
richard@nod.at wrote on Mon, 18 Dec 2023 23:10:20 +0100 (CET):
----- Ursprüngliche Mail -----
Von: "Amit Kumar Mahapatra" amit.kumar-mahapatra@amd.com
This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support.
I wish the series had a real cover letter which explains the big picture in more detail.
What I didn't really get so far, is it really necessary to support multiple chip selects within a single mtd? You changes introduce hard to maintain changes into the spi-nor/mtd core code which alert me. Why can't we have one mtd for each cs and, if needed, combine them later? We have drivers such as mtdconcat for reasons.
The Xilinx SPI controller is a bit convoluted, there are two ways to address the bits in a memory: * Either your extend the memory range with the second chip "on top" of the first (which would typically be a mtd-concat use case) * Or you use the two chips in parallel and you store the even bits in one device (let's say cs0) and the odd bits in the other (cs1). Extending mtd-concat for this might be another solution, I don't know how feasible it would be.
Maybe these bindings will help understanding the logic: e2edd1b64f1c ("spi: dt-bindings: Describe stacked/parallel memories modes") eba5368503b4 ("spi: dt-bindings: Add an example with two stacked flashes")
However I agree the changes will likely be hard to maintain given the complexity brought with such a different controller.
Thanks, Miquèl
participants (10)
-
Amit Kumar Mahapatra
-
Guenter Roeck
-
Lee Jones
-
Linux regression tracking #adding (Thorsten Leemhuis)
-
Mahapatra, Amit Kumar
-
Mark Brown
-
Michael Walle
-
Miquel Raynal
-
Richard Weinberger
-
Tudor Ambarus