From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A3E9CA9EBB for ; Thu, 24 Oct 2019 14:51:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11449205F4 for ; Thu, 24 Oct 2019 14:51:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571928679; bh=MEaP5IL/IqooQRDNdNUcu8iypLi1gD3g0148DaXxsOA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=L9PQ0Xsat6lkyCRcJr61dSAZWZgfvvPKJS6QUfj294zlinoAz4LaRtTEhVRntbUM3 LlCPqjRslawOHhKno8mph4frAbypk2SgdFqNaKsVR/sM7uQW3AQ+Nj8xUGA9qBv8kV H2SLcwmggW0yCLe+aB6TMhU7cF+w2cGP4l+J3TVA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409498AbfJXOvS (ORCPT ); Thu, 24 Oct 2019 10:51:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:57052 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2409497AbfJXOvS (ORCPT ); Thu, 24 Oct 2019 10:51:18 -0400 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C3597205F4; Thu, 24 Oct 2019 14:51:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571928676; bh=MEaP5IL/IqooQRDNdNUcu8iypLi1gD3g0148DaXxsOA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=AhLTlEblswmwrWUsuXYU6je5kiKbSEAz/M0zJZKKJ0DIQ60EIdRbWyrk5REfexOGm Oe4Ph5iPBlOcnF2uQ0YfG5vcfCeB+jCFaTgmE7IuBNtSLI7D7+S483zv39vG/VvGE/ YHxedsM80fsfFCj4chEONOo9lXEDwHlLnhWbiK70= Received: by mail-qt1-f181.google.com with SMTP id m15so38352940qtq.2; Thu, 24 Oct 2019 07:51:16 -0700 (PDT) X-Gm-Message-State: APjAAAXTuaOrKY8k7tl0wIDwXyQaCMwBhzyLj7F6xornI5ysT4P6BTqe SYH84T/DVBWUE0RR7FdLhR1mcEjHRUP+5tJYLQ== X-Google-Smtp-Source: APXvYqyXI1R6tgkLf27Se2dMkBgfCAIms6JME3RgcEqcC6jce5AGFooEv86GX0hr06greCwOgnLCH683ZJIx8hx7MRM= X-Received: by 2002:a0c:f792:: with SMTP id s18mr14841198qvn.20.1571928675962; Thu, 24 Oct 2019 07:51:15 -0700 (PDT) MIME-Version: 1.0 References: <20191024142211.GA29467@arm.com> In-Reply-To: <20191024142211.GA29467@arm.com> From: Rob Herring Date: Thu, 24 Oct 2019 09:51:04 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Question regarding "reserved-memory" To: Ayan Halder Cc: Mark Rutland , "devicetree@vger.kernel.org" , "m.szyprowski@samsung.com" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Liviu Dudau , Mihail Atanassov , "james qian wang (Arm Technology China)" , Brian Starkey , nd Content-Type: text/plain; charset="UTF-8" Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Oct 24, 2019 at 9:22 AM Ayan Halder 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@60000000 { > compatible = "simple-bus"; > ... > > juno_wrapper { > > ... /* here we have all the nodes */ > /* corresponding to the devices in the fpga */ > > memory@d000000 { > device_type = "memory"; > reg = <0x00 0x60000000 0x00 0x8000000>; > }; > > reserved-memory { > #address-cells = <0x01>; > #size-cells = <0x01>; > ranges; > > framebuffer@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@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@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