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

["Michael Walle" <mwalle@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]

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

> > 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.

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?

> > > 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.

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]