On Fri, Sep 21, 2012 at 12:10 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

Hi folks !

The reserve map is, imho, my biggest mistake when coming up with the FDT
format.

The main problem is that it doesn't survive the transition via a real
Open Firmware interface. There is no practical way to indicate reserved
regions of memory accross in that case, unless you have an OS that is
nice enough to try to keep OF alive and accomodate its advertised
"available" properties, but that's typically not the case of Linux on
ppc.

So I would like to propose that we add a new "better" way to convey
reserved memory information, via properties in the tree.

I originally though of having these in the "memory" nodes themselves but
this can be tricky on machines that have multiple nodes (ie, NUMA
generally means a memory node per NUMA node) since the reserved regions
can spawn accross nodes and I don't want to complicate FW life too much
by requiring breaking them up in that case.

So what about something at the root of the tree:

reserved-ranges: An array of ranges of reserved memory

reserved-names: A list of zero terminated strings, one for each entry in
the reserved-ranges array, providing optional "names" for the reserved
ranges.

I think this makes sense. Cyril and I are just talking about what he
needs. He wants to set aside per-device reserved regions and would
like to have the ability to reference a particular reserved region
from a device node, probably with a phandle. I like the look of the
reserved-{ranges,names} properties in the root, but I see the argument
that it isn't very flexible. What about something like this:

reserved-memory {
        reserved@0x10000000 { reg = <0x10000000 0x08000000>; };
        reserved@0x01000000 { reg = <0x01000000 0x00200000>; };
}

The node name of the child nodes could be different of course.

The idea here is that we could have well defined names (using a similar
prefix we use for properties) such as linux,initrd, which indicates
clearly to the kernel that the only reason that range is reserved is
because it contains an initrd (ie, it can be freed once that's been
extracted).

It would also be generally handy in case a reserved area is meant to be
used by a specific driver, such as an in-memory framebuffer
pre-initialized by the firmware. The generic memory management code
doesn't need to know, but later on, the gfx driver can pick it up easily
provided the name is part of the binding for that device.

Right, that would work also even though I prefer phandle references in
general. Is it conceivable that additional data would want to be
attached to a particular reserved region?

g.