Question regarding "reserved-memory"
Rob Herring
robh+dt at kernel.org
Thu Oct 24 14:51:04 UTC 2019
On Thu, Oct 24, 2019 at 9:22 AM Ayan Halder <Ayan.Halder at arm.com> wrote:
>
>
> Hi Folks,
>
> I have a question regarding "reserved-memory". I am using an Arm Juno
> platform which has a chunk of ram in its fpga. I intend to make this
> memory as reserved so that it can be shared between various devices
> for passing framebuffer.
>
> My dts looks like the following:-
>
> / {
> .... // some nodes
>
> tlx at 60000000 {
> compatible = "simple-bus";
> ...
>
> juno_wrapper {
>
> ... /* here we have all the nodes */
> /* corresponding to the devices in the fpga */
>
> memory at d000000 {
> device_type = "memory";
> reg = <0x00 0x60000000 0x00 0x8000000>;
> };
>
> reserved-memory {
> #address-cells = <0x01>;
> #size-cells = <0x01>;
> ranges;
>
> framebuffer at d000000 {
> compatible = "shared-dma-pool";
> linux,cma-default;
> reusable;
> reg = <0x00 0x60000000 0x00 0x8000000>;
> phandle = <0x44>;
> };
> };
> ...
> }
> }
> ...
> }
>
> Note that the depth of the "reserved-memory" node is 3.
>
> Refer __fdt_scan_reserved_mem() :-
>
> if (!found && depth == 1 && strcmp(uname, "reserved-memory") == 0) {
>
> if (__reserved_mem_check_root(node) != 0) {
> pr_err("Reserved memory: unsupported node
> format, ignoring\n");
> /* break scan */
> return 1;
> }
> found = 1;
>
> /* scan next node */
> return 0;
> }
>
> It expects the "reserved-memory" node to be at depth == 1 and so it
> does not probe it in our case.
>
> Niether from the
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> nor from commit - e8d9d1f5485b52ec3c4d7af839e6914438f6c285,
> I could understand the reason for such restriction.
>
> So, I seek the community's advice as to whether I should fix up
> __fdt_scan_reserved_mem() so as to do away with the restriction or
> put the "reserved-memory" node outside of 'tlx at 60000000' (which looks
> logically incorrect as the memory is on the fpga platform).
For now, I'm going to say it must be at the root level. I'd guess the
memory at d000000 node is also just ignored (wrong unit-address BTW).
I think you're also forgetting the later unflattened parsing of
/reserved-memory. The other complication IIRC is booting with UEFI
does it's own reserved memory table which often uses the DT table as
its source.
Rob
More information about the dri-devel
mailing list