From: Boris Brezillon <boris.brezillon@bootlin.com>
To: "Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@nokia.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Marek Vasut <marek.vasut@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Richard Weinberger <richard@nod.at>,
Tudor Ambarus <tudor.ambarus@microchip.com>
Subject: Re: [PATCH] mtd: spi-nor: Provide default address width and latency for map selection
Date: Mon, 3 Dec 2018 09:23:37 +0100 [thread overview]
Message-ID: <20181203092337.52817e0e@bbrezillon> (raw)
In-Reply-To: <f11c7ab4-ee19-ad4e-7943-d6359ac58249@nokia.com>
On Mon, 3 Dec 2018 08:03:18 +0000
"Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@nokia.com>
wrote:
> Hello Boris!
>
> On 30/11/2018 11:40, Boris Brezillon wrote:
> >> + /*
> >> + * JESD216 allows to omit particular address length or latency
> >> + * specification in the header and at this point they are still
> >> + * unset, so we need some heuristics. One example is S25FS128S.
> >> + */
> >> + if (!nor->addr_width)
> >> + nor->addr_width = 3;
> >> + if (!nor->read_dummy)
> >> + nor->read_dummy = 8;
> >> +
> > Looks like the same problem was reported by Yogesh here [1]. One more
>
> This is indeed the same problem, although I was not aware of the [1] discussion.
>
> > proof that parsing SFDP is not trivial. I mean, what's the point of
> > defining a generic tables to describe NOR capabilities if you then
> > depend on vendor/chip specific init to read those tables...
> >
> > Anyway, I think this sort of initialization should be placed in a
> > pre_sfdp() fixup hook, as getting the right values likely requires
>
> This is still on my TODO list, to learn about new hooks.
->pre_sfdp() does not exist yet, but I'm about to add it for other
reasons, and it looks like a good place to put this sort of
initialization.
>
> > reading some volatile/non-volatile regs.
>
> This is the same instruction 65h which is used to read regs and which
> appears in SMPT headers, it is a chicken-egg problem.
Oh, right, I remember now. Not a smart decision from Spansion :-/.
>
> Therefore, I don't know if it's possible to provide smarter heuristics
> here.
Maybe:
ref_cr1 = read_CR1_using_RDCR()
for_each_possible_dummy_and_addr_width
cr1 = read_CR1_using_RDAR()
if (cr1 == ref_cr1)
break;
> But without it Spansion S25FS-S Family is now broken by SFDP.
Do you have [1] in your tree? IIRC, this fixed Yogesh issue.
[1]https://patchwork.ozlabs.org/patch/994765/
next prev parent reply other threads:[~2018-12-03 8:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 18:15 [PATCH] mtd: spi-nor: Provide default address width and latency for map selection Sverdlin, Alexander (Nokia - DE/Ulm)
2018-11-30 10:40 ` Boris Brezillon
2018-12-03 8:03 ` Sverdlin, Alexander (Nokia - DE/Ulm)
2018-12-03 8:23 ` Boris Brezillon [this message]
2018-12-03 8:34 ` Sverdlin, Alexander (Nokia - DE/Ulm)
2018-12-03 8:37 ` Sverdlin, Alexander (Nokia - DE/Ulm)
2018-12-03 9:08 ` Boris Brezillon
2018-12-03 9:34 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181203092337.52817e0e@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=alexander.sverdlin@nokia.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
--cc=tudor.ambarus@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).