Re: [PATCH 0/2] Revert support for reserved memory regions defined in device tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, Oct 11, 2013 at 2:48 AM, Benjamin Herrenschmidt
<benh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 2013-10-11 at 09:27 +0200, Marek Szyprowski wrote:
>> Hi all!
>>
>> Benjamin Herrenschmidt pointed a few issues in the proposed design of
>> device tree bindings for contiguous memory allocator and reserved memory
>> regions:
>> https://lkml.org/lkml/2013/9/15/151
>> http://www.spinics.net/lists/arm-kernel/msg273548.html
>
> Are you guys in Edinburgh ?
>
> I'll be there from Tuesday PM (so really Wed) to Friday (fly out on
> Sat). We should catch up, brainstorm and come up with something.
>
> Cheers,
> Ben.

This may be late, but please can you consider re-using the CHRP
reserved node (i.e. device_type = "reserved")?

Since it does exactly the same thing, is well defined since the dark ages?

It's CHRP 1.7 section 5.9 by the way (just before /chosen gets defined).

It would solve a selection of the issues; and require zero binding
work except describing perhaps a couple freakish Linux-specific
properties that may be only as intrusive as, say, linux,initrd would
be in /chosen.

The most effective, multi-OS way of using it ("available" property not
currently implemented in Linux for some reason, but it could come in
so handy - not only because it matches the way Linux resource
structures are handled)

memory@0x70000000 {
   device_type = "memory";
   reg = <0x70000000 0x40000000>;
   available = <0x70000000 0x10000000
                     0x90000000 0x1ffc00000>; /* top 16KiB of memory
is where the secure firmware keeps it's mailboxes */
};

freaky-codec-memory: reserved@0x80000000 {
    device_type = "reserved";
    reg = <0x80000000 0x10000000>;
    available = <0x80000000 0x8000000
                      0x88000000 0x8000000>; /* two 128MiB buffers */
    non-objectionable-mark-as-contiguous-property-name-here;
    cacheable;
};

Any driver that has, previously, required a bunch of it's own memory
carved out of DDR *should* be gaining a phandle reference to that
reserved node however it likes (it would be up to that devices'
binding).

On Linux under CMA, it may well be ignored and just stuffed into the
generic CMA regions, and the driver MAY allocate anywhere it likes,
but it COULD ask for memory based on a region phandle or, horribly, by
name (since there's no other way to search for it, the OF "name" for
reserved SHALL be "reserved") and be given memory in that region
defined by the reserved node if it had any addressing restrictions.

/videodecoder@0x43f01000 {
    compatible = "freaky,codec";
    :
    decode-buffer = &freaky-codec-memory;
};

On another OS it may manually map and use a custom allocator for that
memory region, since otherwise the OS would not have even looked at
it.

Also this discussion of Jeremy Kerr's proposal seems to be 'missing'
on Google. Do you happen to have a link to it?

Thanks,
Matt Sealey <neko@xxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux