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=-8.5 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 B6562CA90AF for ; Tue, 12 May 2020 16:37:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D0AC206CC for ; Tue, 12 May 2020 16:37:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D0AC206CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 14B2F9000D2; Tue, 12 May 2020 12:37:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FD12900036; Tue, 12 May 2020 12:37:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2C5C9000D2; Tue, 12 May 2020 12:37:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id D8143900036 for ; Tue, 12 May 2020 12:37:17 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8D1222461 for ; Tue, 12 May 2020 16:37:17 +0000 (UTC) X-FDA: 76808622114.11.walk59_3f9f4f07a8b27 X-HE-Tag: walk59_3f9f4f07a8b27 X-Filterd-Recvd-Size: 8309 Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 May 2020 16:37:17 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id j4so10991251otr.11 for ; Tue, 12 May 2020 09:37:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wBA/X/8LEF2/kwe3eKVgHZUc/oSPTTRgLnnWRSdSQLs=; b=cw3QvP1nZ7m62ZqfQvWoLxpycAh9OkA5Zw7nqbqPPVxEaf+mA236c+HIHWHceRbyCt Omi+YBnOb9nufT20Mm3f6ncy7mU1r2HEHSu/nO9AaWHkElg2ey2nXKtZFiHVrnCSeRqb McxnHUIjFMV5PXAfGn80NXCPhDd6pq44cpCupGbptHLO0k2iGWrREh63ooj5LiAjp7Yf YpK2Bbi5cbG7suQxRlFdxJItntv7UaS5vB/pbNEYAjqiZ/csxlqPJJLRwDY7zLMO0Epx 7xVEdrcL7Fni+nq3bz3ufiqhmxFdvNQ4wV7rqlCYUaSl78tV97sTk+NSwuGCu1QCe8AE 4gFQ== X-Gm-Message-State: AGi0PuZfCKWo8HE/VlGcoYG8puDyODy0zKZRtmPo6kccjsBHbesjGKSd vpvoJ2BYqN692/ANBvZpRw== X-Google-Smtp-Source: APiQypJPGJFpNg4zyPPhL4TuOM3za0wjxYJWn89WKnZvHZpHJujTR9ZomHIUQRCotEkQVHzDbu3bUA== X-Received: by 2002:a9d:7a98:: with SMTP id l24mr18180169otn.79.1589301436443; Tue, 12 May 2020 09:37:16 -0700 (PDT) Received: from rob-hp-laptop (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id 61sm3538453oty.56.2020.05.12.09.37.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 09:37:15 -0700 (PDT) Received: (nullmailer pid 10735 invoked by uid 1000); Tue, 12 May 2020 16:37:14 -0000 Date: Tue, 12 May 2020 11:37:14 -0500 From: Rob Herring To: Brian Starkey Cc: John Stultz , Robin Murphy , lkml , Sumit Semwal , "Andrew F. Davis" , Benjamin Gaignard , Liam Mark , Pratik Patel , Laura Abbott , Chenbo Feng , Alistair Strachan , Sandeep Patil , Hridya Valsaraju , Christoph Hellwig , Marek Szyprowski , Andrew Morton , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , dri-devel , linux-mm , nd Subject: Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap" Message-ID: <20200512163714.GA22577@bogus> References: <20200501073949.120396-1-john.stultz@linaro.org> <20200501073949.120396-4-john.stultz@linaro.org> <20200501102143.xcckvsfecumbei3c@DESKTOP-E1NTVVP.localdomain> <47e7eded-7240-887a-39e1-97c55bf752e7@arm.com> <20200504090628.d2q32dwyg6em5pp7@DESKTOP-E1NTVVP.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504090628.d2q32dwyg6em5pp7@DESKTOP-E1NTVVP.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote: > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote: > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote: > > > > > > On 2020-05-01 11:21 am, Brian Starkey wrote: > > > > Hi John, > > > > > > > > On Fri, May 01, 2020 at 07:39:48AM +0000, John Stultz wrote: > > > >> This patch reworks the cma_heap initialization so that > > > >> we expose both the default CMA region and any CMA regions > > > >> tagged with "linux,cma-heap" in the device-tree. > > > >> > > > >> Cc: Rob Herring > > > >> Cc: Sumit Semwal > > > >> Cc: "Andrew F. Davis" > > > >> Cc: Benjamin Gaignard > > > >> Cc: Liam Mark > > > >> Cc: Pratik Patel > > > >> Cc: Laura Abbott > > > >> Cc: Brian Starkey > > > >> Cc: Chenbo Feng > > > >> Cc: Alistair Strachan > > > >> Cc: Sandeep Patil > > > >> Cc: Hridya Valsaraju > > > >> Cc: Christoph Hellwig > > > >> Cc: Marek Szyprowski > > > >> Cc: Robin Murphy > > > >> Cc: Andrew Morton > > > >> Cc: devicetree@vger.kernel.org > > > >> Cc: dri-devel@lists.freedesktop.org > > > >> Cc: linux-mm@kvack.org > > > >> Signed-off-by: John Stultz > > > >> --- > > > >> drivers/dma-buf/heaps/cma_heap.c | 18 +++++++++--------- > > > >> 1 file changed, 9 insertions(+), 9 deletions(-) > > > >> > > > >> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c > > > >> index 626cf7fd033a..dd154e2db101 100644 > > > >> --- a/drivers/dma-buf/heaps/cma_heap.c > > > >> +++ b/drivers/dma-buf/heaps/cma_heap.c > > > >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data) > > > >> { > > > >> struct cma_heap *cma_heap; > > > >> struct dma_heap_export_info exp_info; > > > >> + struct cma *default_cma = dev_get_cma_area(NULL); > > > >> + > > > >> + /* We only add the default heap and explicitly tagged heaps */ > > > >> + if (cma != default_cma && !cma_dma_heap_enabled(cma)) > > > >> + return 0; > > > > > > > > Thinking about the pl111 thread[1], I'm wondering if we should also > > > > let drivers call this directly to expose their CMA pools, even if they > > > > aren't tagged for dma-heaps in DT. But perhaps that's too close to > > > > policy. > > > > > > That sounds much like what my first thoughts were - apologies if I'm > > > wildly off-base here, but as far as I understand: > > > > > > - Device drivers know whether they have their own "memory-region" or not. > > > - Device drivers already have to do *something* to participate in dma-buf. > > > - Device drivers know best how they make use of both the above. > > > - Therefore couldn't it be left to drivers to choose whether to register > > > their CMA regions as heaps, without having to mess with DT at all? +1, but I'm biased toward any solution not using DT. :) > > I guess I'm not opposed to this. But I guess I'd like to see some more > > details? You're thinking the pl111 driver would add the > > "memory-region" node itself? > > > > Assuming that's the case, my only worry is what if that memory-region > > node isn't a CMA area, but instead something like a carveout? Does the > > driver need to parse enough of the dt to figure out where to register > > the region as a heap? > > My thinking was more like there would already be a reserved-memory > node in DT for the chunk of memory, appropriately tagged so that it > gets added as a CMA region. > > The device's node would have "memory-region=<&blah>;" and would use > of_reserved_mem_device_init() to link up dev->cma_area to the > corresponding cma region. > > So far, that's all in-place already. The bit that's missing is > exposing that dev->cma_area to userspace as a dma_heap - so we could > just have "int cma_heap_add(struct cma *cma)" or "int > cma_heap_dev_add(struct device *dev)" or something exported for > drivers to expose their device-assigned cma region if they wanted to. > > I don't think this runs into the lifetime problems of generalised > heaps-as-modules either, because the CMA region will never go away > even if the driver does. > > Alongside that, I do think the completely DT-driven approach can be > useful too - because there may be regions which aren't associated with > any specific device driver, that we want exported as heaps. And they are associated with the hardware description rather than the userspace environment? Rob