[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e07105d41ec62a6ee47ca0295ca347dc@walle.cc>
Date: Wed, 30 Nov 2022 23:32:20 +0100
From: Michael Walle <michael@...le.cc>
To: Nathan Barrett-Morrison <nathan.morrison@...esys.com>
Cc: greg.malysa@...esys.com,
Tudor Ambarus <tudor.ambarus@...rochip.com>,
Pratyush Yadav <pratyush@...nel.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: issi: Add in support for IS25LX256 chip,
operating in 1S-1S-8S mode.
Hi,
Am 2022-11-30 16:34, schrieb Nathan Barrett-Morrison:
>> Does this flash have SFDP data? If possible, this should be
>> derived from that. Could you dump the SFDP table and
>> post it here [1].
>
> # hexdump sfdp
> 0000000 4653 5044 0106 ff01 0600 1001 0030 ff00
> 0000010 0084 0201 0080 ff00 ffff ffff ffff ffff
> 0000020 ffff ffff ffff ffff ffff ffff ffff ffff
> 0000030 20e5 ff8a ffff 0fff 0000 0000 0000 0000
> 0000040 fffe ffff ffff ff00 ffff 0000 200c d811
> 0000050 520f ff00 2224 00a9 8e8b d103 01ac 3827
> 0000060 757a 757a bdfb 5cd5 0000 ff70 b081 2238
> 0000070 ffff ffff ffff ffff ffff ffff ffff ffff
> 0000080 0e43 ffff dc21 ff5c
>
> Looking at the latest SFDP document from
> https://www.jedec.org/standards-documents/docs/jesd216b, I see
> 1s-1s-8s would be in BFPT DWORD 17, which appears to be 0xffffffff if
> I'm reading this hexdump correctly.
There is no dword 17, the table is shorter than that. But
there is a 4BAIT table at the end, starting at offset 80h.
And from what I can parse with my sleepy eyes, it says
"support for 1s-1s-8s via 7Ch" and "support for 1s-8s-8s via
CCh", which is consistent with the datasheet.
So all you'd need to do is to extend the sfdp parser to parse
that modes in the 4bait table.
Btw there is a newer JESD216F (you can get it from JEDEC for
free, you just have to sign up there).
>> why?
>
> This was because ISSI's default_init was setting a quad_enable
> function pointer which is not relevant to this part. This probably
> doesn't need to be done though, as SPI_NOR_QUAD_* isn't being set in
> the flash_info table and therefore quad_enable will never be used?
Yes.
The SFDP specifies 111b as the enable method which is reserved
according to JESD216F. I still vote for setting the quad_enable
to NULL if there is SFDP which should know better. This should
be "fixed" (IOW unset) by the following patch (but it never
made it):
https://lore.kernel.org/linux-mtd/20220304185137.3376011-1-michael@walle.cc/
-michael
Powered by blists - more mailing lists