On Monday 31 March 2008 00:39, Segher Boessenkool wrote: > >>> 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).
Ok, I get your point. I'll prepare a new documentation patch; changes to physmap_of.c will go away. If I understand you correctly, there should be no "compatible" property on the ram and rom devices. Should the "non-volatile", "slow" and "static ram" properties still be expressed in the device tree ? -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
