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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 7F5A2C4724C for ; Wed, 6 May 2020 16:30:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4160420708 for ; Wed, 6 May 2020 16:30:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="xGbq/nBk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4160420708 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BFACE8E0005; Wed, 6 May 2020 12:30:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAAA28E0003; Wed, 6 May 2020 12:30:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC13E8E0005; Wed, 6 May 2020 12:30:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 9395A8E0003 for ; Wed, 6 May 2020 12:30:29 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4B41821E4 for ; Wed, 6 May 2020 16:30:29 +0000 (UTC) X-FDA: 76786832178.06.guide22_5b83ce98c8d59 X-HE-Tag: guide22_5b83ce98c8d59 X-Filterd-Recvd-Size: 5224 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 May 2020 16:30:28 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id c12so1283263oic.1 for ; Wed, 06 May 2020 09:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EvHPxE7L1Cb6oif98tDAWFYOvy9QzwI+EVnlaf1jpTo=; b=xGbq/nBkeNTeQkh8TeQ07h15oTGAYHX6j5LFfR/RI3sHIvBIymNOSSXRcu+wHZ1aVW Bi9WC0jgv9B5Kp+7cwBmKtfn1QjRyVdEkInImfKuIlVtWGUJmKfhJrI1QWyRGwCX0yJD ZWlgp81bR5ws/479qoQiUXdTQKezTywlxfTMxQqtDA8i2bG+9sntoecsCgJ9HLEPbqvg G34LbxJQDBp7Gtl0+VsmxjLGveZyAEy3fCO4pbX5afZwwEcYRPCDhYIDmwlFwhGzmFcG Lqdq+jCKkXA8vZnRXREVS+dR1h3wiY7f35aHnymxitA672W5CrNu0RAOCSEsoG6c/aHS oveg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EvHPxE7L1Cb6oif98tDAWFYOvy9QzwI+EVnlaf1jpTo=; b=sKbATHlZR+xHtMnQSLGu75wIdaptw6JNF1exnDu7uip8ZRIQJs6cEJBKAK8MN2RriG o/AcwFfQyhV9Cdn+hFWp/nYsSVUXoYufTw248qGEsbt9B03QhepKGw440CTabgFdENPw HE/s0TpejNRb05hNZLvHBmNCcHS7RyZoCy9gMQ75nAay8GsvPorBuZjfYhr4FBQ/olZr EPuiQ5fr26zp4rm1bk8kiKejIo0s7baeieWaZkjs6VlJ8sVfKd6GrSCkBQo64on8sub/ h1jjrmHDmNdpgkDPPdNwzzQkdGolAvCfEj/zzD3BLBXkOHARJw5NbjEuFJgAJVPD1C5t QYng== X-Gm-Message-State: AGi0PuZYMfc0h3uxkXazXzVUSsfnlEslcNq2E1mo+UVn5X3FyTL1JNoG IJVrkGtLSooO1HPqWwyVwe5cJnBloGqGKSYIpmIzYA== X-Google-Smtp-Source: APiQypJOjwli0ENiyI3cl299qwfEK7rVXtgNZRAGsYZ2j/Qgmpsi7m4V2zQHdFeurrc2zQ1jwMe1nfOg2GrAWKcKGNo= X-Received: by 2002:aca:cf83:: with SMTP id f125mr3336594oig.97.1588782627545; Wed, 06 May 2020 09:30:27 -0700 (PDT) MIME-Version: 1.0 References: <20200501073949.120396-1-john.stultz@linaro.org> <20200501073949.120396-2-john.stultz@linaro.org> <20200501104216.4f226c2a7bzval5o@DESKTOP-E1NTVVP.localdomain> <20200504085007.5yrjhknkg6ugbqwk@DESKTOP-E1NTVVP.localdomain> <1bddb721-d4d9-f113-bacc-0a0ca2d57753@ti.com> In-Reply-To: <1bddb721-d4d9-f113-bacc-0a0ca2d57753@ti.com> From: John Stultz Date: Wed, 6 May 2020 09:30:16 -0700 Message-ID: Subject: Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux,cma-heap tag for reserved memory To: "Andrew F. Davis" Cc: Brian Starkey , lkml , Rob Herring , Sumit Semwal , Benjamin Gaignard , Liam Mark , Pratik Patel , Laura Abbott , Chenbo Feng , Alistair Strachan , Sandeep Patil , Hridya Valsaraju , Christoph Hellwig , Marek Szyprowski , Robin Murphy , Andrew Morton , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , dri-devel , linux-mm , nd Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 6, 2020 at 9:04 AM Andrew F. Davis wrote: > On 5/4/20 4:50 AM, Brian Starkey wrote: > > On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote: > >> So the name we expose is the CMA name itself. So with dt it will be > >> the name of the reserved memory node that the flag property is added > >> to. > >> > > > > Yeah I'm just wondering if that's "stable" so we can say "the heap > > will use the node name", or if saying that would cause us a headache > > in the future. > > > The issue is going to be this causes the node name in DT to become a > kind of ABI. Right now until we have some userspace lib that enumerates > the heaps in a stable way programs will hard-code the full heap name, > which right now would look like: > > char *heap = "/dev/dma_heap/dma_heap_mem@89000000"; > If that's what the device chose to export. > Yuk.. we might want to look into exporting heap properties to make them > searchable based on something other than name here soon. Or this will be > a mess to cleanup in the future. Eh. I don't see this as such an issue. On different systems we have different device nodes. Some boards have more or fewer NICs, or various partitions, etc. There has to be some device specific userland config that determines which partitions are mounted where (this is my "gralloc is fstab" thesis :) I think with the heaps, qualities other than name are going to be poorly specified or unenumerable, so any generic query interface is going to fall down there (and be awful to use). thanks -john