-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Monday, December 11, 2023 9:03 AM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
On 12/8/23 17:05, Mahapatra, Amit Kumar wrote:
Hello Tudor,
Hi!
Hello Tudor,
-----Original Message----- From: Tudor Ambarus tudor.ambarus@linaro.org Sent: Wednesday, December 6, 2023 8:00 PM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com; broonie@kernel.org; pratyush@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; sbinding@opensource.cirrus.com; lee@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com Cc: linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; michael@walle.cc; linux-mtd@lists.infradead.org; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@tuxon.dev; Simek, Michal michal.simek@amd.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linux-sound@vger.kernel.org; git (AMD- Xilinx) git@amd.com; amitrkcian2002@gmail.com Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor
Hi, Amit,
On 11/25/23 09:21, Amit Kumar Mahapatra wrote:
Each flash that is connected in stacked mode should have a separate parameter structure. So, the flash parameter member(*params) of the spi_nor structure is changed to an array (*params[2]). The array is used to store the parameters of each flash connected in stacked
configuration.
The current implementation assumes that a maximum of two flashes are connected in stacked mode and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Do you plan to add support for different flashes in stacked mode? If not,
No, according to the current implementation, in stacked mode, both flashes must be of the same make.
wouldn't it be simpler to have just an array of flash sizes instead of duplicating the entire params struct?
Yes, that is accurate. In alignment with our current stacked support use case we can have an array of flash sizes instead. The primary purpose of having an array of params struct was to facilitate potential future extensions, allowing the addition of stacked support for different flashes
right. Don't do this change yet, let's decide on the overall architecture first.
Sure.
SPI-NOR is not aware of the chip_select values, for any incoming request SPI-NOR will decide the flash index with the help of individual flash size and the configuration type (single/stacked). SPI-NOR will pass on the flash index information to the SPI core & SPI driver by setting the appropriate bit in nor->spimem->spi->cs_index_mask. For example, if nth bit of nor->spimem->spi->cs_index_mask is set then the driver would assert/de-assert spi->chip_slect[n].
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
mahapatra@amd.com>
drivers/mtd/spi-nor/core.c | 272 +++++++++++++++++++++++++++++-----
--
drivers/mtd/spi-nor/core.h | 4 + include/linux/mtd/spi-nor.h | 15 +- 3 files changed, 240 insertions(+), 51 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 93ae69b7ff83..e990be7c7eb6 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c
cut
@@ -2905,7 +3007,10 @@ static void spi_nor_init_fixup_flags(struct spi_nor *nor) static int spi_nor_late_init_params(struct spi_nor *nor) { struct spi_nor_flash_parameter *params = spi_nor_get_params(nor,
0);
- int ret;
struct device_node *np = spi_nor_get_flash_node(nor);
u64 flash_size[SNOR_FLASH_CNT_MAX];
u32 idx = 0;
int rc, ret;
if (nor->manufacturer && nor->manufacturer->fixups && nor->manufacturer->fixups->late_init) { @@ -2937,6 +3042,44 @@
static int spi_nor_late_init_params(struct spi_nor *nor) if (params->n_banks > 1) params->bank_size = div64_u64(params->size, params-
n_banks);
- nor->num_flash = 0;
- /*
* The flashes that are connected in stacked mode should be of+same
make.
* Except the flash size all other properties are identical for all the* flashes connected in stacked mode.* The flashes that are connected in parallel mode should be identical.*/- while (idx < SNOR_FLASH_CNT_MAX) {
rc = of_property_read_u64_index(np, "stacked-memories",idx,
+&flash_size[idx]);
This is a little late in my opinion, as we don't have any sanity check on the flashes that are stacked on top of the first. We shall at least read and compare the ID for all.
Alright, I will incorporate a sanity check for reading and comparing the ID of the stacked flash. Subsequently, I believe this stacked logic should be relocated to spi_nor_get_flash_info() where we identify the first flash. Please share your thoughts on this. Additionally, do you
I'm wondering whether we can add a layer on top of the flash type to handle
When you mention "on top," are you referring to incorporating it into the MTD layer? Initially, Miquel had submitted this patch to address stacked/parallel handling in the MTD layer. https://lore.kernel.org/linux-mtd/20200114191052.0a16d116@xps13/t/ However, the Device Tree bindings were initially not accepted. Following a series of discussions, the below bindings were eventually merged. https://lore.kernel.org/all/20220126112608.955728-4-miquel.raynal@bootlin.co...
the stacked/parallel modes. This way everything will become flash type independent. Would it be possible to stack 2 SPI NANDs? How about a SPI NOR and a SPI NAND?
Is the datasheet of the controller public?
Yes, https://docs.xilinx.com/r/en-US/am011-versal-acap-trm/Quad-SPI-Controller
anticipate that SPI-NOR should throw an error if the second or any subsequent flash within the stacked connection is different? Or would you prefer it to print a warning and operate in single mode (i.e., only the first flash)?
Both options are fine, but I haven't yet decided on the overall architecture.
Ok.
Regards, Amit
Cheers, ta