RE: [Power.org:parch] devicetree: Musings on reserved regions

I've seen three types of reserved regions so far:

(1) Reserved regions that are permanently reserved. For example,
    RAM used for configuration of a device not communicated in the
    device tree. Nothing further needs to be said about this class.
(2) Reserved regions that are in use by something in the device tree
    (for example, a spin table, or a frame buffer for a video device).
    The client program can free these if it recognizes the node that
    is using them and reprograms it (e.g., boot all processors, or
    reprogram the video device).
(3) Reserved regions that contain data the client program might want to
    use but are not actually being used by the hardware for anything.
    For example, a RAM root file system.

I think this points strongly at having type 2 and type 3 reservations specified along with the nodes that make use of them, so that the client program can free the memory as soon as it has caused the reserved memory to no longer be in use for the purpose for which it was reserved (provided that we make it clear that reservations declared as such are not permitted to overlap).

Primarily because of type 1 reservations, I see no conflict between the conventional reservations list and the idea of explicitly identifying single-purpose reservations throughout the device tree where they are used.

However, in the spirit of distributing memory nodes, I think I would rather see the conventional reservations list moved to the corresponding memory nodes (with an added rule that a reservation may not cross a reg entry boundary, since that's just a big pain). If we're going to work towards keeping crap out of the header, then I don't see why the reservations block should be treated any differently.

Dan

-----Original Message-----
From: parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org [mailto:parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org] On Behalf Of Jimi Xenidis
Sent: Monday, February 07, 2011 2:01 PM
To: Grant Likely
Cc: Yoder Stuart-B08248; Benjamin Herrenschmidt; parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org;
devicetree-discuss; David Gibson; McClintock Matthew-B29882; Wood Scott-
B07421
Subject: Re: [Power.org:parch] devicetree: Musings on reserved regions

On Feb 7, 2011, at 3:56 PM, Grant Likely wrote:

quoted

On Mon, Feb 7, 2011 at 2:53 PM, Yoder Stuart-B08248
[off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of

Grant

quoted

quoted

quoted

Likely
Sent: Monday, February 07, 2011 3:45 PM
To: Benjamin Herrenschmidt
Cc: parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org; devicetree-discuss; David Gibson; Yoder Stuart-

B08248;

quoted

quoted

quoted

McClintock Matthew-B29882; Wood Scott-B07421
Subject: Re: [Power.org:parch] devicetree: Musings on reserved regions

On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

quoted

In addition to the reserved regions block in the header, define a

set

quoted

quoted

quoted

quoted

quoted

of properties in the memory node that specify the reserved regions
with the name reflecting the usage.
For example:

      memory@0 {
              device_type = "memory";
              reg = <0 0x40000000>;
              reserved-ramdisk = <0xc00000 0x200000>; /* 2MB ramdisk
*/
              reserved-dtb = <0xbf0000 0x1000>; /* devicetree */
              reserved-fb0 = 0x1000000 0x400000>; /* framebuffer */
      };

Each reserved property would start with "reserved-" followed by a
name.  reserved-ramdisk and reserved-dtb would be reserved for
ramdisk and dtb images respectively.  Other names could also be
defined; for example, reserved-openfirmware.

I very much dislike the list of properties with magic names. I'd
rather have a pair of properties containing lists (reserved-names and
reserved-ranges).

Heh, I have very much the opposite opinion.  I'd rather have property

names

quoted

quoted

quoted

that match the usage than have the names and values split into two
properties.  To me, keeping them together is more tasteful.  Queue the
debate...  :-)

Could we not do both? Use an enum to identify the region type:

   reserved = <0x1 0xc00000 0x200000>; /* 2MB ramdisk
   reserved = <0x2 0xbf0000 0x1000>; /* devicetree */
   reserved = <0x3 0x1000000 0x400000>; /* framebuffer */

I really dislike enums for this sort of thing.  I'd rather have a
string encoded somewhere, even if it is in a different property.

ack
-JX

quoted

g.