Hi Takahiro.Kuwano,
On 13.10.26 03:20, [email protected] wrote:
Hi Heiko,
Hi Takahiro.Kuwano,
On 09.10.26 11:28, Heiko Schocher wrote:
Hello Takahiro.Kuwano,
just answer here, before I looked into the comments from Simon...
On 09.10.26 10:29, [email protected] wrote:
Hi Heiko and Simon,
Hi Heiko,
On 2026-10-04T04:06:44, Heiko Schocher <[email protected]> wrote:
mtd: add driver for the Microchip 23LCV1024 SPI SRAM
The 23LCV1024 is a 1 Mbit serial SRAM with battery backup, sitting on
an SPI bus and used as non volatile scratch storage. Register it as an
MTD device of type MTD_RAM, so the mtd command reaches it.
The device powers up in byte operation, where every command carries
exactly one data byte. Select sequential operation once during probe,
Just to check, is this right? My understanding is that the
23LC1024/23LCV1024 data sheet gives sequential mode (01) as the MODE
register default; byte mode is the default only on the older 23K256.
The Linux mchp23k256 driver never writes the MODE register. Setting it
explicitly is still a fine defensive step, since something else could
have changed the mode and the part keeps it while on battery. Please
can you reword the commit message and the comment in spi_ram_probe()
to match?
so that a read or a write of any length is served by a single command
and the bus is claimed once per transfer.
Writing needs no erase. The driver therefore implements no erase
operation and says MTD_NO_ERASE in the MTD flags.
Signed-off-by: Stefan Bigler <[email protected]>
Signed-off-by: Heiko Schocher <[email protected]>
MAINTAINERS | 5 ++
configs/sandbox_defconfig | 1 +
drivers/mtd/Kconfig | 14 +++
drivers/mtd/Makefile | 1 +
drivers/mtd/spi_ram.c | 222
++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 243 insertions(+)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
@@ -194,6 +194,20 @@ config ALTERA_QSPI
+config SPI_RAM
+ bool "Microchip 23LCV1024 SPI SRAM"
+ depends on DM_SPI && DM_MTD
SPI_RAM, spi_ram.c and the spi_ram driver name are very generic for a
driver that handles one Microchip part. Linux already supports this
chip in drivers/mtd/devices/mchp23k256.c (CONFIG_MTD_MCHP23K256), and
the binding in dts/upstream/Bindings/mtd/microchip,mchp23k256.yaml
lists both microchip,mchp23k256 and microchip,mchp23lcv1024. How about
using the Linux names, here and in MAINTAINERS?
I would rather have a generic SPI-RAM driver that also supports MRAM [1]
and FRAM devices using the common opcode set without erase.
Currently, some FRAM chips are handled by SPI-NOR, but new devices should
be added to the SPI-RAM driver if it exists.
What are your thoughts on this?
Seems like a valid argument to me. Simon? What do you think?
After looking into patches from Yasir (added to cc). the FRAM
case is different. The FRAM (at least the one Yasir adds) has a JEDEC
interface, the 23LCV1024 has not! So 23LCV1024 is really special, and I
currently tend to say, that Simon is correct, that we should name
the 23LCV1024 driver drivers/mtd/devices/mchp23k256.c.
The MRAM (not FRAM) part doesn't support Read ID (JEDEC ID) command. Yasir
mentions that in the commit description and I checked datasheet [1].
Why did you get it has a JEDEC interface?
Seems I looked into the wrong datasheet! Maybe it is too early for me here...
I need a coffee now.
Thanks!
In linux the MRAM Yasir adds, is also handled in spi nor driver.
the register 5/1 (read/write status register) and 3/2 (read/write data)
seems the same for both chips and for spi-nor subsystem.
But, spi-nor and MRAM expect a "status register" and the 23LCV1024 [2]
has there a mode register, with different bit meanings!
Seems to me, that is why the 23LCV1024 got his own driver in linux...
even if this is the only obvious difference (not checked deeper now).
I tend to be in sync with linux here, and still add the MRAM Yasir adds to
the spi-nor driver, and have an own driver for the 23LCV1024 in
drivers/mtd/devices.
If not I see 2 options:
a) Yasir adds the MR25H40 to the "spi-ram" driver in this thread
in a follow up series. I tend to say, I first go with driver place
and name Simon proposed.
b) add 23LCV1024 to spi-nor subsystem and find a way to work out mode/status
register differences
other options?
b) seems ugly, a) doable... but all options differ to linux approach.
bye,
Heiko
[2] https://ww1.microchip.com/downloads/en/DeviceDoc/25156A.pdf
Thanks,
Takahiro
[1]
https://www.mouser.com/datasheet/2/144/EST_MR25H40_prod-2578.pdf?srsltid=AU7gw4XF8HonuNZoC78eWKFbMoaNLlWH1vNgEGA6NH-YFQrIpWVFulpv
--
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: [email protected]
Geschäftsführer : Stefano Babic
