public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb@firmworks.com>
To: Sean MacLennan <smaclennan@pikatech.com>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@ozlabs.org,
	avorontsov@ru.mvista.com, 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.

  reply	other threads:[~2008-12-10  8:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-04  3:28 [PATCH] ndfc driver Sean MacLennan
2008-12-04 14:01 ` 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
  -- strict thread matches above, loose matches on Subject: below --
2008-12-23 12:26 Kostas Nakos
2008-12-23 22:00 ` Sean MacLennan
2008-12-24  6:58   ` knakos
2008-12-27  1:56     ` Sean MacLennan
2008-12-29 10:58   ` Kostas Nakos
2009-01-06  1:23     ` Sean MacLennan
2009-01-07  9:51       ` Kostas Nakos
2009-01-07 17:21         ` Sean MacLennan
2009-01-08 15:37           ` Kostas Nakos
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.com \
    --cc=avorontsov@ru.mvista.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=smaclennan@pikatech.com \
    /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