[PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

Boris Brezillon boris.brezillon at free-electrons.com
Wed Oct 28 09:32:15 PDT 2015


Hi Marek,

On Wed, 28 Oct 2015 17:11:14 +0100
Marek Vasut <marex at 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



More information about the linux-mtd mailing list