Re: OF compatible MTD platform RAM driver ?

Laurent Pinchart
2008-03-31T08:21:37Z

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