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

[Dan Hettena]

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 at power.org [mailto:parch at power.org] On Behalf Of Jimi Xenidis
> Sent: Monday, February 07, 2011 2:01 PM
> To: Grant Likely
> Cc: Yoder Stuart-B08248; Benjamin Herrenschmidt; parch at power.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:
> >
> > On Mon, Feb 7, 2011 at 2:53 PM, Yoder Stuart-B08248
> > <B08248 at freescale.com> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of
> Grant
> >>> Likely
> >>> Sent: Monday, February 07, 2011 3:45 PM
> >>> To: Benjamin Herrenschmidt
> >>> Cc: parch at power.org; devicetree-discuss; David Gibson; Yoder Stuart-
> B08248;
> >>> 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
> >>> <benh at kernel.crashing.org> wrote:
> >>>>
> >>>>> In addition to the reserved regions block in the header, define a
> set
> >>>>> of properties in the memory node that specify the reserved regions
> >>>>> with the name reflecting the usage.
> >>>>> For example:
> >>>>>
> >>>>>       memory at 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
> >>> 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
> 
> >
> > g.
>