linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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/

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