linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Burton <paul.burton@imgtec.com>
To: James Hogan <james.hogan@imgtec.com>
Cc: Alex Smith <alex@alex-smith.me.uk>,
	Harvey Hunt <harvey.hunt@imgtec.com>,
	<linux-mtd@lists.infradead.org>,
	Alex Smith <alex.smith@imgtec.com>,
	"Zubair Lutfullah Kakakhel" <Zubair.Kakakhel@imgtec.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes
Date: Fri, 16 Oct 2015 11:48:48 +0100	[thread overview]
Message-ID: <20151016104848.GA1408@NP-P-BURTON> (raw)
In-Reply-To: <20151016103112.GB29285@jhogan-linux.le.imgtec.org>

On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > >> +
> > >> +&nemc {
> > >> +     status = "okay";
> > >> +
> > >> +     nand: nand@1 {
> > >> +             compatible = "ingenic,jz4780-nand";
> > >
> > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > driver and binding already accepted upstream with that compatible
> > > string?
> > 
> > This is the compatible string for the JZ4780 NAND driver, this patch
> > is part of the series adding that. Detection of the NAND part is
> > handled by the MTD subsystem.
> 
> Right (didn't spot that it was part of a series).
> 
> The node appears to describe the NAND interface itself, i.e. a part of
> the SoC, so should be in the SoC dtsi file, with overrides in the board
> file if necessary for it to work with a particular NAND part
> (potentially utilising status="disabled"). Would you agree?

Hi James,

The "nemc" node there is for the Nand & External Memory Controller which
is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
pins, each associated with a different address range, that connect to
different devices). NAND flash is one such possible device, but a board
could connect it to any of the 6 chip selects, or banks. To represent
that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
default, which doesn't make a whole lot of sense to me. Other, non-NAND
devices can connect to the NEMC too - for example the ethernet
controller on the CI20 is connected to one bank.

The NAND device nodes are sort of a mix of describing the NAND flash
(ie. Micron part as you point out) and its connections & properties, the
way the NEMC should be used to interact with it alongside the BCH block,
and the configuration for the NEMC such as timing parameters.

I imagine the most semantically correct means of describing it would
probably be for the compatible string to reflect the Micron NAND part,
and the NEMC driver to pick up on the relevant properties of its child
nodes for configuring timings, whether the device is NAND etc. However
the handling of registering NAND devices with MTD would probably then
have to be part of the NEMC driver, which feels a bit off too.

Thanks,
    Paul

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

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1444148837-10770-1-git-send-email-harvey.hunt@imgtec.com>
2015-10-06 16:27 ` [PATCH v7,1/3] dt-bindings: binding for jz4780-{nand,bch} Harvey Hunt
2015-11-04  7:57   ` Boris Brezillon
2015-11-17 16:08     ` Harvey Hunt
2015-11-17 16:25     ` Harvey Hunt
2015-10-06 16:27 ` [PATCH v7,2/3] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs Harvey Hunt
2015-11-04 10:18   ` [PATCH v7, 2/3] " Boris Brezillon
2015-11-17 16:28     ` Harvey Hunt
2015-11-17 19:09       ` Boris Brezillon
2015-10-06 16:27 ` [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes Harvey Hunt
2015-10-08 21:22   ` Ezequiel Garcia
2015-10-14  9:15     ` Harvey Hunt
2015-10-15  8:47   ` James Hogan
2015-10-16 10:11     ` Alex Smith
2015-10-16 10:31       ` James Hogan
2015-10-16 10:48         ` Paul Burton [this message]
2015-11-04  7:51           ` Boris Brezillon
2015-11-17 16:29             ` Harvey Hunt

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=20151016104848.GA1408@NP-P-BURTON \
    --to=paul.burton@imgtec.com \
    --cc=Zubair.Kakakhel@imgtec.com \
    --cc=alex.smith@imgtec.com \
    --cc=alex@alex-smith.me.uk \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=harvey.hunt@imgtec.com \
    --cc=james.hogan@imgtec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mtd@lists.infradead.org \
    /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).