From: Mitch Bradley <wmb@firmworks•com>
To: Sean MacLennan <smaclennan@pikatech•com>
Cc: linuxppc-dev@ozlabs•org, devicetree-discuss@ozlabs•org,
linux-mtd@lists•infradead.org
Subject: Re: [PATCH] ndfc driver
Date: Tue, 09 Dec 2008 22:28:09 -1000 [thread overview]
Message-ID: <493F7D99.5070400@firmworks.com> (raw)
In-Reply-To: <20081209230135.35e1b9d1@lappy.seanm.ca>
>
> n Mon, 08 Dec 2008 21:57:12 -1000
> "Mitch Bradley" <wmb@firmworks•com> wrote:
>
>
>> > One address/size cell isn't enough for the next generation of NAND
>> > FLASH chips.
>> >
>>
>
> I am no dts expert, but I thought I could put:
>
> nand {
> #address-cells = <1>;
> #size-cells = <1>;
>
> in my dts and you could put:
>
> nand {
> #address-cells = <2>;
> #size-cells = <2>;
>
> and, assuming we specified the reg entry right, everything would just
> work. Is that assumption wrong?
>
> And if the assumption is true, should I make a note in the doc that you
> can make the address and size bigger?
>
> Cheers,
> Sean
>
>
In principle that is correct, but the device tree partition parser in
the Linux kernel assumes one address cell and one size cell, or at least
it did the last time I looked.
I wrote a patch to fix that and circulated it on the linuxppc list, but
since lost interest. OLPC (my main focus) is probably going to switch to
managed NAND (SSD, LBA-NAND, eMMC, or some such thing with a built-in
Flash Translation Layer) at some point. Raw NAND is starting to go by
the wayside.
next prev parent reply other threads:[~2008-12-10 8:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081203222832.3fc77d28@lappy.seanm.ca>
2008-12-04 14:01 ` [PATCH] ndfc driver Josh Boyer
2008-12-04 17:17 ` Sean MacLennan
2008-12-09 0:34 ` Sean MacLennan
2008-12-09 2:11 ` Anton Vorontsov
2008-12-09 2:45 ` Sean MacLennan
2008-12-09 3:32 ` Josh Boyer
2008-12-09 4:54 ` Sean MacLennan
2008-12-09 7:57 ` Mitch Bradley
2008-12-10 4:01 ` Sean MacLennan
2008-12-10 8:28 ` Mitch Bradley [this message]
2008-12-09 6:10 ` Stefan Roese
2008-12-09 11:24 ` Josh Boyer
2008-12-10 23:16 ` Sean MacLennan
2008-12-17 4:14 ` Sean MacLennan
2008-12-17 11:34 ` Josh Boyer
2008-12-17 13:26 ` Josh Boyer
2008-12-09 0:51 ` Sean MacLennan
[not found] <9293074.419171225391386417.JavaMail.nabble@isper.nabble.com>
[not found] ` <20081030195858.28900ee5@lappy.seanm.ca>
[not found] ` <490D68A8.4060905@embedded-sol.com>
[not found] ` <20081102124804.15003002@lappy.seanm.ca>
[not found] ` <490E02D7.5050402@embedded-sol.com>
[not found] ` <20081102145811.6da10ef4@lappy.seanm.ca>
[not found] ` <490E074F.5050909@embedded-sol.com>
[not found] ` <20081102152958.42e88283@lappy.seanm.ca>
[not found] ` <490E4D0D.9060207@embedded-sol.com>
[not found] ` <20081102204510.3d8e71f2@lappy.seanm.ca>
2008-11-03 10:56 ` Felix Radensky
2008-10-30 6:08 Sean MacLennan
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=493F7D99.5070400@firmworks.com \
--to=wmb@firmworks$(echo .)com \
--cc=devicetree-discuss@ozlabs$(echo .)org \
--cc=linux-mtd@lists$(echo .)infradead.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=smaclennan@pikatech$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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