From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] tegra: enable NAND on Harmony
Date: Mon, 13 Aug 2012 10:24:09 -0600 [thread overview]
Message-ID: <50292A29.3040608@wwwdotorg.org> (raw)
In-Reply-To: <50259A09.4000905@freescale.com>
On 08/10/2012 05:32 PM, Scott Wood wrote:
> On 07/30/2012 12:37 PM, Stephen Warren wrote:
>> diff --git a/board/nvidia/dts/tegra20-harmony.dts b/board/nvidia/dts/tegra20-harmony.dts
>> + nand-controller at 70008000 {
...
>> + nand at 0 {
>> + reg = <0>;
>> + compatible = "hynix,hy27uf4g2b", "nand-flash";
>
> Where is the binding for a generic "nand-flash" compatible?
I don't know if there is one. This patch was cribbed from one by Simon
(CC'd) for Seaboard. Simon do you know the answer?
That said, it seems like it's quite reasonable to create or assume such
a binding, since NAND flash appears self-describing.
That said, looking for precedence in the Linux kernel indicates some
inconsistencies. There exist:
* Many (ARM and PowerPC) bindings that have no node for the NAND chip
itself, but rather the NAND controller has children that describe the
partitioning of the NAND chip.
* Many (I think only PowerPC) bindings that have a node for the NAND
chip, but containing little but #address/#size-cells, and this node then
contains children that describe the partitioning.
* I guess there is at least one PowerPC example just like this patch,
that contains a child node containing a compatible value describing the
flash model number.
prev parent reply other threads:[~2012-08-13 16:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-30 17:37 [U-Boot] [PATCH] tegra: enable NAND on Harmony Stephen Warren
2012-07-30 20:34 ` Simon Glass
2012-07-31 5:53 ` Thierry Reding
2012-08-10 23:32 ` Scott Wood
2012-08-13 16:24 ` Stephen Warren [this message]
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=50292A29.3040608@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.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