linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
Cc: ben@simtec.co.uk, linuxppc-dev@ozlabs.org,
	linux-mtd@lists.infradead.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: OF compatible MTD platform RAM driver ?
Date: Mon, 31 Mar 2008 00:39:21 +0200	[thread overview]
Message-ID: <56851566f85e117c42b078dd2d6a2028@kernel.crashing.org> (raw)
In-Reply-To: <18416.813.635397.559197@cargo.ozlabs.ibm.com>

>>> For RAMs we
>>> need something to indicate that it's memory but intended for 
>>> secondary
>>> storage, not as main memory.
>>
>> How it is intended to be used is not a property of the hardware, so
>> that information doesn't belong in the device tree at all.  The Linux
>> platform code should handle this, I imagine.
>
> There must be some reason why it is not intended to be used as main
> memory.  Presumably it has something different about it compared to
> "normal" RAM, and that difference could perfectly well be expressed in
> the device tree.

Sure, that's a different thing.  It might sit on a bus that doesn't
do cache coherency, or maybe it's just slow (or sits on a slow bus).
All these things can be usefully expressed in the device tree (but
typically are not, it is left to the client code to know this stuff
implicitly).

It's still the (platform) probe code its responsibility to figure
out what (if anything) to do with any device.  And "main memory"
is probed differently (via /chosen/memory, for example) anyway.
Well, actually, Linux searches for all nodes with device_type "memory",
which should work fine as well [*].

So, all in all, I think we should just give these "auxiliary memory"
devices a name of "ram" c.q. "rom", and some "reg", and that should
be all that is needed: the main memory probe stuff won't consider
these nodes, and the (platform) device probe code can do whatever it
wants (create mtd devices, I guess).


Segher


[*] It seems to me the longtrail workaround code in prom_init.c is
incorrect though: it will match any node with name "memory" that
doesn't have a device_type?

  reply	other threads:[~2008-03-30 22:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-10 15:06 OF compatible MTD platform RAM driver ? Laurent Pinchart
2008-03-10 17:00 ` Rune Torgersen
2008-03-11  0:45   ` David Gibson
2008-03-11 10:39     ` Laurent Pinchart
2008-03-11 22:40       ` David Gibson
2008-03-25 14:36         ` Laurent Pinchart
2008-03-25 15:29           ` Sergei Shtylyov
2008-03-25 15:51             ` Laurent Pinchart
2008-03-25 16:23               ` Sergei Shtylyov
2008-03-25 16:44                 ` Laurent Pinchart
2008-03-25 17:02                   ` Sergei Shtylyov
2008-03-25 17:23                     ` Laurent Pinchart
2008-03-25 17:37                       ` Sergei Shtylyov
2008-03-25 17:56                       ` Rune Torgersen
2008-03-25 18:14                         ` Laurent Pinchart
2008-03-26 12:53                           ` Sergei Shtylyov
2008-03-27  9:13                             ` Laurent Pinchart
2008-03-27 10:03                               ` David Gibson
2008-03-27 12:23                                 ` Sergei Shtylyov
2008-03-28  0:07                                   ` David Gibson
2008-03-28 12:31                                     ` Sergei Shtylyov
2008-03-27 14:31                                 ` Laurent Pinchart
2008-03-28  0:09                                   ` David Gibson
2008-03-30 18:15                                 ` Segher Boessenkool
2008-03-30 21:16                                   ` Paul Mackerras
2008-03-30 22:39                                     ` Segher Boessenkool [this message]
2008-03-31  0:42                                       ` Paul Mackerras
2008-03-31  0:59                                         ` Segher Boessenkool
2008-03-31  1:24                                           ` Segher Boessenkool
2008-03-31  8:21                                       ` Laurent Pinchart
2008-03-31 12:21                                         ` Segher Boessenkool
2008-03-26 15:06                           ` Segher Boessenkool
2008-03-26 15:40                             ` Sergei Shtylyov
2008-03-27  9:24                               ` Laurent Pinchart
2008-03-30 18:12                               ` Segher Boessenkool
2008-03-26 15:09                   ` Segher Boessenkool
2008-03-11 15:00     ` Rune Torgersen
2008-03-11 22:41       ` David Gibson

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=56851566f85e117c42b078dd2d6a2028@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=ben@simtec.co.uk \
    --cc=david@gibson.dropbear.id.au \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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).