Re: Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

[<claus.fabig@emerson.com>]

> Hi,
> 
> On Fri Jul 26, 2024 at 2:04 PM CEST, claus.fabig wrote:
> > > Hi,
> > Hi Michael, thanks for your response resp. advices and apologies for the late
> response.
> > >
> > > There is something odd with your mail client, maybe have a look at
> > > git send-email.
> > Unfortunately I am only able to send/receive email from my windows
> > machine and therefore have some challenges within our company
> infrastructure.
> > I still try to find the best way to get the formatting correct.
> 
> In that case you can also have a look at:
> https://b4.docs.kernel.org/en/latest/contributor/send.html

Thanks, I looked into it but have problem with our smtp server since it 
requests a password, even with smtpauth=none in .gitconfig. I will clone my
Linux target repo to Windows virtual machine and use git send-email
instead since there no password is requested.

> 
> > > Also we usually push back on the MRAM devices and refer the users to
> > > the at25 driver. But as this doesn't use the NO_ERASE flag.. I'll
> > > let Tudor and Pratyush decide.
> > I am aware that using at25 driver works but have the task to integrate
> > that in mtd since another used MRAM Everspin flash MR25H10 on our
> > board is also accessed in that way and already part of the mainline. That will
> lead to confusion on user side.
> 
> I suggest that you'll look into evaluating and converting your existing boards to
> nvmem (which is the interface at25 exposes) instead.

My problem is that we have two MRAMs on our board configuration - both 
from Everspin (MR25H10 and EM008LX). The first is accessible via /dev/mtd 
and already part of mainline. The second should also be be accessible via this 
interface so this is why mtd is more preferred than nvmem interface. I noticed
that the first MRAM with /dev/mtd is also existing in nvmem but only as read-only.

> 
> The MTD maintainers agreed that new fram/mram won't likely be added
> anymore. As I said, this patch might be an exception, because you are actually
> emulating a flash device (because you *don't* have the NO_ERASE flag).
> Otherwise, the m/fram are more like an EEPROM and thus should use the at25
> driver.
> 
> > > > From: Claus Fabig <claus.fabig@emerson.com>
> > > > Date: Thu, 18 Jul 2024 09:53:36 +0200
> > > > Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin
> > > > EM008LXB
> > > >
> > > > The Everspin EM008LXB MRAM has 8Mb and is populated on a custom
> > > board
> > > > using Microchip's PCI12000 spi host controller running on low 30MHz
> clock.
> > > > According to Everspin Read Fast (0xb) command below 60MHz is
> > > > neither specified and nor tested. Test shows that using Read Fast
> > > > (0xb) will result in reading inconsistent data in this setup but
> > > > writing is fine, so only supporting Read (0x3) command should be
> acceptable for the moment.
> > >
> > > This is really odd. Is there an explanation for that? Usually, fast
> > > read will just add dummy cycles in between. Also the datasheet just
> > > mentions a "maximum frequency" which actually makes sense. Do the
> > > dummy cycles for our fast read operation match the number of dummy
> > > cycles in your device?
> > >
> > Yes, at first I configured the chip with 8 dummy cycles to match with
> > platform dummy cycles with the result of reading inconsistent data.
> > The answer from Everspin product engineering was:
> > "Read fast has only been tested down to 66 Mhz. If you are only
> > running at 30 Mhz, you should be using the Read command instead. Read
> > Fast is designed for Higher speed operation". Unfortunately no more
> explanation.
> 
> I guess you cannot use it with at least 66MHz?

Unfortunately not, it's limited by hardware design.

> 
> > > > The device is JEDEC compatible (JESD251 and JESD251-1) but not
> > > > able to provide SFDP information.
> > >
> > > There is no SFDP data for this chip is it? But it has a READ_ID
> > > command.
> > For my understanding reading SFDP works with command 0x5A which is not
> > supported, reading ID is command 0x9F and supported. I don't understand
> your point.
> > Maybe you could give me a hint to better understand.
> 
> Please see my comments on the code in my first reply. You basically don't
> probe the driver by the name, but by it's ID.

Understood, changed this accordingly and will send Patch v2 
(via git send-email hopefully).

> 
> -michael
Best regards, Claus