linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Marek Vasut <marex@denx.de>
Cc: Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Scott Wood <scottwood@freescale.com>, Josh Wu <josh.wu@atmel.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Han Xu <han.xu@freescale.com>,
	Huang Shijie <shijie.huang@arm.com>
Subject: Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node
Date: Wed, 28 Oct 2015 17:32:15 +0100	[thread overview]
Message-ID: <20151028173215.0c1c4e30@bbrezillon> (raw)
In-Reply-To: <201510281711.14196.marex@denx.de>

Hi Marek,

On Wed, 28 Oct 2015 17:11:14 +0100
Marek Vasut <marex@denx.de> wrote:

> On Wednesday, October 28, 2015 at 08:58:13 AM, Boris Brezillon wrote:
> > Hi Brian,
> 
> Hi,
> 
> [...]
> 
> > > Are
> > > there ever cases we want more than one (master) MTD per nand_chip? Or
> > > vice versa?
> > 
> > Nope, I'd say that you always have a 1:1 relationship between a master
> > MTD device and a NAND device.
> 
> Do some sorts of chipselects come into play here ? Ie. you can have one master
> with multiple NAND chips connected to it.

Most NAND controllers support interacting with several chips (or
dies in case your chip embeds several NAND dies), but I keep thinking
each physical chip should have its own instance of nand_chip + mtd_info.
If you want to have a single mtd device aggregating several chips you
can use mtdconcat.

This leaves the multi-dies chip case, and IHMO we should represent those
chips as a single entity, and I guess that's the purpose of the
->numchips field in nand_chip (if your chip embeds 2 dies with 2 CS
lines, then ->numchips should be 2).

Anyway, I think the whole problem here is that most NAND drivers are
mixing the concepts of NAND controller (the controller driving one or
several NAND chips) and NAND chip (a chip connected to a NAND
controller).
The NAND controller should not be represented with a nand_chip
instance, but with a nand_hw_control instance, which is rarely done
except in a few drivers.

I sent an RFC a while ago [1] to clarify that, but didn't have time to
post a new version.

Best Regards,

Boris

[1]http://thread.gmane.org/gmane.linux.drivers.mtd/57614/focus=58552

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2015-10-28 16:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27  2:31 [PATCH 0/5] mtd: migrate 'of_node' handling to core, not in mtd_part_parser_data Brian Norris
2015-10-27  2:31 ` [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node Brian Norris
2015-10-27  7:42   ` Boris Brezillon
2015-10-27 17:54     ` Brian Norris
2015-10-28  1:01       ` Brian Norris
2015-10-28  8:02         ` Boris Brezillon
2015-10-28  7:58       ` Boris Brezillon
2015-10-28 16:11         ` Marek Vasut
2015-10-28 16:32           ` Boris Brezillon [this message]
2015-10-28 17:14             ` Brian Norris
2015-10-28 20:55               ` Robert Jarzmik
2015-10-28 22:47                 ` Marek Vasut
2015-10-29  6:32                   ` Robert Jarzmik
2015-10-29  7:24                     ` Boris Brezillon
2015-10-29 17:23                       ` Marek Vasut
2015-10-29 17:34                         ` Boris Brezillon
2015-10-29 20:28                           ` Robert Jarzmik
2015-10-28 20:38             ` Marek Vasut
2015-10-27  2:31 ` [PATCH 2/5] mtd: nand: drop unnecessary partition parser data Brian Norris
2015-10-27  7:52   ` Boris Brezillon
2015-10-28  0:45   ` Brian Norris
2015-10-27  2:31 ` [PATCH 3/5] mtd: spi-nor: " Brian Norris
2015-10-27  2:31 ` [PATCH 4/5] mtd: " Brian Norris
2015-10-27  2:31 ` [PATCH 5/5] mtd: drop 'of_node' " Brian Norris

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=20151028173215.0c1c4e30@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=han.xu@freescale.com \
    --cc=josh.wu@atmel.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    --cc=robert.jarzmik@free.fr \
    --cc=scottwood@freescale.com \
    --cc=shijie.huang@arm.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).