From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-mtd@lists.infradead.org,
Brian Norris <computersforpeace@gmail.com>
Subject: Re: Multiple NANDs on non contiguous chip selects, how?
Date: Sun, 21 Feb 2016 08:36:35 +0100 [thread overview]
Message-ID: <20160221083635.4660c3d0@bbrezillon> (raw)
In-Reply-To: <20160215122251.GE19372@pengutronix.de>
Hi Sacha,
On Mon, 15 Feb 2016 13:22:52 +0100
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi all,
>
> I have a i.MX6 board here which has two NAND chips connected to CS0 and
> CS2 on the same controller. The current code in nand_scan_ident iterates
> over the chip selects and bails out when there's nothing found on a chip
> select. This means the current code never finds the chip on CS2 since it
> already bails out after probing the empty CS1.
>
> Any preferences how this should be handled? I could implement a i.MX6
> specific mapping function, possibly initialized from the device tree, to
> map the real chip selects to contiguous chip selects for the NAND layer.
>
> Normally such a function should not be needed since we could autodetect
> if a chip select has a device connected or not, so the NAND layer could
> handle this without driver intervention, but is that what we want?
>
> Any ideas/opinions?
This is a common mistake, caused by a poor documentation of what
nand->numchips and the chip argument passed to ->select_chip() are
representing. I'm not even sure I have the correct answer, but here is
my understanding (and last time I discussed it with Brian he seemed to
agree).
'struct nand_chip' is representing a single NAND chip not the NAND
controller, so, if you have 2 chips on your board, then your NAND
controller driver should instantiate 2 nand chips. and register both of
them to the NAND framework.
The only case where you'll need to specify numchips > 1 is when you
have a NAND chip stacking several dies, each of them accessible with
its own CS line.
In this case, the mapping between the controller CS line and the chip
CS line should be done by the NAND controller driver.
If you take your particular imx6 case, the mapping between the
chip and controller CS lines should be defined somewhere in the DT.
You can have a look at this binding [1] if you need an example, and if
I extend it for the multi-die case, it gives something like that:
nfc: nand@01c03000 {
compatible = "allwinner,sun4i-a10-nand";
/* ... */
#address-cells = <1>;
#size-cells = <0>;
nand@0 {
reg = <0 2>; /* CS0 and CS2 */
allwinner,rb = <0 2>; /* RB0 and RB2 */
/* ... */
};
nand@1 {
reg = <1>; /* CS1 */
allwinner,rb = <1>; /* RB0 and RB2 */
/* ... */
};
};
I hope this helps.
Best Regards,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-02-21 7:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 12:22 Multiple NANDs on non contiguous chip selects, how? Sascha Hauer
2016-02-21 7:36 ` Boris Brezillon [this message]
2016-02-23 6:48 ` Sascha Hauer
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=20160221083635.4660c3d0@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/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