All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel RAYNAL <miquel.raynal@free-electrons.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	David Woodhouse <dwmw2@infradead.org>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	linux-mtd@lists.infradead.org,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Antoine Tenart <antoine.tenart@free-electrons.com>,
	Nadav Haklai <nadavh@marvell.com>,
	Ofer Heifetz <oferh@marvell.com>,
	Neta Zur Hershkovits <neta@marvell.com>,
	Hanna Hawa <hannah@marvell.com>
Subject: Re: [RFC 03/12] mtd: nand: use a static data_interface in the nand_chip structure
Date: Fri, 3 Nov 2017 14:46:02 +0100	[thread overview]
Message-ID: <20171103144602.53f0bcbc@xps13> (raw)
In-Reply-To: <20171018190255.3b223d7e@bbrezillon>

Hi Boris,

> > Change the data_interface field from the nand_chip structure,
> > convert the pointer to a static structure.  
> 
> You mean "embed a nand_data_interface object". Not sure the static
> specifier can be used to describe what you do.

Ok.

> > Also remove the nand_get_default_data_interface() function that
> > become useless and rename the onfi_init_data_interface() by
> > nand_fill_data_interface(),  
> 
> I know I'm the one who suggested to rename this function, but I'm not
> so sure it's a good idea in the end, and I don't like the new
> prototype where you drop the iface_type parameter.

No problem, I will just rename it "onfi_fill_data_interface" because
there is no more real "initialization", it is just a dumb function
that fills the structure with the appropriate timings (I found the
name too close to "nand_init_data_interface" that really does
something). But ok, let's keep the iface_type parameter.

> 
> > which is a more appropriate name because
> > applied timings are ONFI, no matter if the NAND actually is one.  
> 
> Well, this is actually a good reason to keep the onfi_ prefix. A NAND
> driver can decide that its NAND is close to an existing timing mode
> and re-use this onfi_init_data_interface(), but maybe someday we'll
> have drivers filling the nand_data_interface object with their own
> (non-ONFI) timings.
> 
> > 
> > This is needed before passing to ->exec_op() to avoid any race
> > that  
> 
> It's not really a race, it's just that you need some timings during
> NAND detection, and the core is currently creating the
> nand_data_interface object after the detection step (in
> nand_scan_tail()).

I changed the commit message.


> > @@ -1107,7 +1107,6 @@ static int nand_wait(struct mtd_info *mtd,
> > struct nand_chip *chip) static int nand_reset_data_interface(struct
> > nand_chip *chip, int chipnr) {
> >  	struct mtd_info *mtd = nand_to_mtd(chip);
> > -	const struct nand_data_interface *conf;
> >  	int ret;
> >  
> >  	if (!chip->setup_data_interface)
> > @@ -1127,8 +1126,8 @@ static int nand_reset_data_interface(struct
> > nand_chip *chip, int chipnr)
> >  	 * timings to timing mode 0.
> >  	 */
> >  
> > -	conf = nand_get_default_data_interface();
> > -	ret = chip->setup_data_interface(mtd, chipnr, conf);
> > +	nand_fill_data_interface(chip, 0);
> > +	ret = chip->setup_data_interface(mtd, chipnr,
> > &chip->data_interface); if (ret)
> >  		pr_err("Failed to configure data interface to SDR
> > timing mode 0\n"); 
> 
> So now you're stuck in timing mode 0 as soon as you have nand_reset()
> called.
> 
> Actually, what we should do is:
> 
> 1/ at the beginning of nand_scan_ident(), call
>    onfi_init_data_interface(chip, &chip->data_interface,
> NAND_SDR_IFACE, 0) (or a wrapper that does that) so that
> data_interface is initialized with the appropriate timings for
> reset/detection operations 2/ after detection, find the best iface
> type and timing mode we can use (what's currently done in
> nand_init_data_interface()) 3/ in nand_reset(), you should save
> what's in chip->data_interface, in a local variable, then apply
> SDR+timing-mode-0 and finally restore the previous settings (the one
> you stored in your local variable) after the RESET op.
> 
> This way you're guaranteed to always end up with the best data iface
> settings after a RESET.

Clear explanation, this is corrected.

Thank you,
Miquèl

  reply	other threads:[~2017-11-03 13:46 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18 14:36 [RFC 00/12] Marvell NAND controller rework with ->exec_op() Miquel Raynal
2017-10-18 14:36 ` Miquel Raynal
2017-10-18 14:36 ` Miquel Raynal
2017-10-18 14:36 ` [RFC 01/12] mtd: nand: provide several helpers to do common NAND operations Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` [RFC 02/12] mtd: nand: force drivers to explicitly send READ/PROG commands Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-20  9:29   ` Stefan Agner
2017-10-20  9:29     ` Stefan Agner
2017-10-20  9:29     ` Stefan Agner
2017-10-20 11:18     ` Boris Brezillon
2017-10-20 11:18       ` Boris Brezillon
2017-10-20 11:18       ` Boris Brezillon
2017-11-06 15:02     ` Miquel RAYNAL
2017-10-18 14:36 ` [RFC 03/12] mtd: nand: use a static data_interface in the nand_chip structure Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 17:02   ` Boris Brezillon
2017-10-18 17:02     ` Boris Brezillon
2017-10-18 17:02     ` Boris Brezillon
2017-11-03 13:46     ` Miquel RAYNAL [this message]
2017-10-18 14:36 ` [RFC 04/12] mtd: nand: add ->exec_op() implementation Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 21:57   ` Boris Brezillon
2017-10-18 21:57     ` Boris Brezillon
2017-10-18 21:57     ` Boris Brezillon
2017-11-06 14:09     ` Miquel RAYNAL
2017-10-18 14:36 ` [RFC 05/12] dt-bindings: mtd: add Marvell NAND controller documentation Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 22:01   ` Boris Brezillon
2017-10-18 22:01     ` Boris Brezillon
2017-10-18 22:01     ` Boris Brezillon
2017-10-24 19:04   ` Rob Herring
2017-10-24 19:04     ` Rob Herring
2017-10-24 19:04     ` Rob Herring
2017-11-06 13:24     ` Miquel RAYNAL
2017-11-06 13:24       ` Miquel RAYNAL
2017-11-06 13:24       ` Miquel RAYNAL
2017-10-18 14:36 ` [RFC 06/12] mtd: nand: add reworked Marvell NAND controller driver Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-19  7:18   ` Boris Brezillon
2017-10-19  7:18     ` Boris Brezillon
2017-10-19  7:18     ` Boris Brezillon
2017-11-06 13:49     ` Miquel RAYNAL
2017-10-18 14:36 ` [RFC 07/12] ARM: dts: armada-370-xp: use reworked " Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` [RFC 08/12] ARM: dts: armada-375: " Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` [RFC 09/12] ARM: dts: armada-38x: " Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` [RFC 10/12] ARM: dts: armada-39x: " Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` [RFC 11/12] ARM: dts: pxa: " Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` [RFC 12/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 7K/8K Miquel Raynal
2017-10-18 14:36 ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 14:36 ` Miquel Raynal
     [not found] ` <20171018143629.29302-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-10-18 14:36   ` Miquel Raynal
2017-10-18 22:29 ` [RFC 00/12] Marvell NAND controller rework with ->exec_op() Boris Brezillon
2017-10-18 22:29   ` Boris Brezillon
2017-10-18 22:29   ` Boris Brezillon
2017-10-19  8:47   ` Marc Gonzalez
2017-10-19 11:30     ` 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=20171103144602.53f0bcbc@xps13 \
    --to=miquel.raynal@free-electrons.com \
    --cc=antoine.tenart@free-electrons.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=dwmw2@infradead.org \
    --cc=gregory.clement@free-electrons.com \
    --cc=hannah@marvell.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=nadavh@marvell.com \
    --cc=neta@marvell.com \
    --cc=oferh@marvell.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@free-electrons.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.