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/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
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/[email protected]/
---
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 <[email protected]> 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(-)
--
2.17.1
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 <[email protected]>
---
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);
--
2.17.1
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 <[email protected]>
Signed-off-by: Amit Kumar Mahapatra <[email protected]>
---
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
--
2.17.1
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 <[email protected]>
---
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
--
2.17.1
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 <[email protected]>
---
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 {
--
2.17.1
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 <[email protected]>
---
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;
}
--
2.17.1
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 <[email protected]>
---
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);
--
2.17.1
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/[email protected]/
Signed-off-by: Amit Kumar Mahapatra <[email protected]>
Tested-by: Stefan Binding <[email protected]>
---
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;
--
2.17.1
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 <[email protected]>
---
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)
--
2.17.1
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 <[email protected]>
---
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
--
2.17.1
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 <[email protected]>
---
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) {
--
2.17.1
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.
--
Lee Jones [李琼斯]
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 <[email protected]>
> ---
> 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 <[email protected]>
>> ---
>> 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
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(-)
--
Lee Jones [李琼斯]
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 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!
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/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> 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
Hello Tudor,
> -----Original Message-----
> From: Tudor Ambarus <[email protected]>
> Sent: Wednesday, December 6, 2023 8:00 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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 <[email protected]>
> > ---
> > 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
Hello Tudor,
> -----Original Message-----
> From: Tudor Ambarus <[email protected]>
> Sent: Wednesday, December 6, 2023 8:14 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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-
> [email protected]>
> >> ---
> >> 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/[email protected]/
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:05, Mahapatra, Amit Kumar wrote:
> Hello Tudor,
Hi!
>
>> -----Original Message-----
>> From: Tudor Ambarus <[email protected]>
>> Sent: Wednesday, December 6, 2023 8:00 PM
>> To: Mahapatra, Amit Kumar <[email protected]>;
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; Simek, Michal <[email protected]>; linux-
>> [email protected]; [email protected];
>> [email protected]; [email protected]; git (AMD-
>> Xilinx) <[email protected]>; [email protected]
>> 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 <[email protected]>
>>> ---
>>> 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
On 12/8/23 17:06, Mahapatra, Amit Kumar wrote:
> Hello Tudor,
Hi!
>
>> -----Original Message-----
>> From: Tudor Ambarus <[email protected]>
>> Sent: Wednesday, December 6, 2023 8:14 PM
>> To: Mahapatra, Amit Kumar <[email protected]>;
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; Simek, Michal <[email protected]>; linux-
>> [email protected]; [email protected];
>> [email protected]; [email protected]; git (AMD-
>> Xilinx) <[email protected]>; [email protected]
>> 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-
>> [email protected]>
>>>> ---
>>>> 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/[email protected]/
>
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/[email protected]/
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
> -----Original Message-----
> From: Tudor Ambarus <[email protected]>
> Sent: Monday, December 11, 2023 9:03 AM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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 <[email protected]>
> >> Sent: Wednesday, December 6, 2023 8:00 PM
> >> To: Mahapatra, Amit Kumar <[email protected]>;
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; Simek, Michal <[email protected]>;
> >> linux- [email protected]; [email protected];
> >> [email protected]; [email protected]; git (AMD-
> >> Xilinx) <[email protected]>; [email protected]
> >> 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-
> [email protected]>
> >>> ---
> >>> 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/[email protected]/
> 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 <[email protected]>
>> Sent: Monday, December 11, 2023 9:03 AM
>> To: Mahapatra, Amit Kumar <[email protected]>;
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; Simek, Michal <[email protected]>; linux-
>> [email protected]; [email protected];
>> [email protected]; [email protected]; git (AMD-
>> Xilinx) <[email protected]>; [email protected]
>> 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 <[email protected]>
>>>> Sent: Wednesday, December 6, 2023 8:00 PM
>>>> To: Mahapatra, Amit Kumar <[email protected]>;
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected]
>>>> Cc: [email protected]; [email protected];
>>>> [email protected]; [email protected];
>>>> [email protected]; [email protected];
>>>> [email protected]; Simek, Michal <[email protected]>;
>>>> linux- [email protected]; [email protected];
>>>> [email protected]; [email protected]; git (AMD-
>>>> Xilinx) <[email protected]>; [email protected]
>>>> 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-
>> [email protected]>
>>>>> ---
>>>>> 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/[email protected]/
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 <[email protected]>
> Sent: Monday, December 11, 2023 3:05 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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 <[email protected]>
> >> Sent: Monday, December 11, 2023 9:03 AM
> >> To: Mahapatra, Amit Kumar <[email protected]>;
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; Simek, Michal <[email protected]>;
> >> linux- [email protected]; [email protected];
> >> [email protected]; [email protected]; git (AMD-
> >> Xilinx) <[email protected]>; [email protected]
> >> 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 <[email protected]>
> >>>> Sent: Wednesday, December 6, 2023 8:00 PM
> >>>> To: Mahapatra, Amit Kumar <[email protected]>;
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> [email protected];
> >>>> [email protected]; [email protected]; [email protected]
> >>>> Cc: [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected]; Simek, Michal <[email protected]>;
> >>>> linux- [email protected]; [email protected];
> >>>> [email protected]; [email protected]; git
> >>>> (AMD-
> >>>> Xilinx) <[email protected]>; [email protected]
> >>>> 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-
> >> [email protected]>
> >>>>> ---
> >>>>> 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-Diagrams
> 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
> 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
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-Diagrams
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 Michael,
> -----Original Message-----
> From: Michael Walle <[email protected]>
> Sent: Tuesday, December 12, 2023 6:05 PM
> To: Mahapatra, Amit Kumar <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; Simek, Michal
> <[email protected]>; [email protected]; alsa-
> [email protected]; [email protected]; linux-
> [email protected]; git (AMD-Xilinx) <[email protected]>;
> [email protected]
> 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
Hello Tudor,
> -----Original Message-----
> From: Tudor Ambarus <[email protected]>
> Sent: Tuesday, December 12, 2023 8:33 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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 <[email protected]>
> Sent: Friday, December 15, 2023 1:40 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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 <[email protected]>
>> Sent: Friday, December 15, 2023 1:40 PM
>> To: Mahapatra, Amit Kumar <[email protected]>;
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; Simek, Michal <[email protected]>; linux-
>> [email protected]; [email protected];
>> [email protected]; [email protected]; git (AMD-
>> Xilinx) <[email protected]>; [email protected]
>> 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 <[email protected]>
> Sent: Friday, December 15, 2023 4:03 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; Simek, Michal
> <[email protected]>; [email protected]; alsa-
> [email protected]; [email protected]; linux-
> [email protected]; git (AMD-Xilinx) <[email protected]>;
> [email protected]
> 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 <[email protected]>
> >> Sent: Friday, December 15, 2023 1:40 PM
> >> To: Mahapatra, Amit Kumar <[email protected]>;
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; Simek, Michal <[email protected]>;
> >> linux- [email protected]; [email protected];
> >> [email protected]; [email protected]; git (AMD-
> >> Xilinx) <[email protected]>; [email protected]
> >> 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
----- Ursprüngliche Mail -----
> Von: "Amit Kumar Mahapatra" <[email protected]>
> 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,
[email protected] wrote on Mon, 18 Dec 2023 23:10:20 +0100 (CET):
> ----- Ursprüngliche Mail -----
> > Von: "Amit Kumar Mahapatra" <[email protected]>
>
> > 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
On 15.12.2023 13:20, Mahapatra, Amit Kumar wrote:
> Hello Tudor,
>
Hi!
>> -----Original Message-----
>> From: Tudor Ambarus <[email protected]>
>> Sent: Friday, December 15, 2023 4:03 PM
>> To: Mahapatra, Amit Kumar <[email protected]>;
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected]; Simek, Michal
>> <[email protected]>; [email protected]; alsa-
>> [email protected]; [email protected]; linux-
>> [email protected]; git (AMD-Xilinx) <[email protected]>;
>> [email protected]
>> 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 <[email protected]>
>>>> Sent: Friday, December 15, 2023 1:40 PM
>>>> To: Mahapatra, Amit Kumar <[email protected]>;
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected]
>>>> Cc: [email protected]; [email protected];
>>>> [email protected]; [email protected];
>>>> [email protected]; [email protected];
>>>> [email protected]; Simek, Michal <[email protected]>;
>>>> linux- [email protected]; [email protected];
>>>> [email protected]; [email protected]; git (AMD-
>>>> Xilinx) <[email protected]>; [email protected]
>>>> 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-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.
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 <[email protected]>
> Sent: Tuesday, December 19, 2023 1:56 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]
> 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 <[email protected]>
> >> Sent: Friday, December 15, 2023 4:03 PM
> >> To: Mahapatra, Amit Kumar <[email protected]>;
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected];
> >> [email protected]; [email protected]; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; [email protected];
> >> [email protected]; Simek, Michal <[email protected]>;
> >> [email protected]; alsa- [email protected];
> >> [email protected]; linux- [email protected]; git
> >> (AMD-Xilinx) <[email protected]>; [email protected]
> >> 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 <[email protected]>
> >>>> Sent: Friday, December 15, 2023 1:40 PM
> >>>> To: Mahapatra, Amit Kumar <[email protected]>;
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> [email protected];
> >>>> [email protected]; [email protected]; [email protected]
> >>>> Cc: [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected]; Simek, Michal <[email protected]>;
> >>>> linux- [email protected]; [email protected];
> >>>> [email protected]; [email protected]; git
> >>>> (AMD-
> >>>> Xilinx) <[email protected]>; [email protected]
> >>>> 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
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/[email protected]/
>
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/[email protected]/
> >
>
> 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 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.
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 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 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 21.01.24 10:42, Linux regression tracking #adding (Thorsten Leemhuis)
wrote:
> 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
#regzbot fix: spi: Raise limit on number of chip selects
#regzbot ignore-activity
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.
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-Signals
[2]
https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv4ry78xM0_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 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-Signals
> [2]
> https://docs.xilinx.com/viewer/attachment/dwmjhDJGICdJqD4swyVzcQ/fD8nv4ry78xM0_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
Hello Tudor,
> -----Original Message-----
> From: Tudor Ambarus <[email protected]>
> Sent: Friday, February 9, 2024 4:36 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]; Conor Dooley
> <[email protected]>; [email protected]
> 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
> -----Original Message-----
> From: Tudor Ambarus <[email protected]>
> Sent: Friday, February 9, 2024 9:44 PM
> To: Mahapatra, Amit Kumar <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Simek, Michal <[email protected]>; linux-
> [email protected]; [email protected];
> [email protected]; [email protected]; git (AMD-
> Xilinx) <[email protected]>; [email protected]; Conor Dooley
> <[email protected]>; [email protected]
> 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