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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 D3CAAC5519F for ; Thu, 19 Nov 2020 03:19:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 11514246C0 for ; Thu, 19 Nov 2020 03:19:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="IyWxWBUR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11514246C0 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 E4F986B005C; Wed, 18 Nov 2020 22:19:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DDAC66B005D; Wed, 18 Nov 2020 22:19:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA02C6B006C; Wed, 18 Nov 2020 22:19:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id 99EA06B005C for ; Wed, 18 Nov 2020 22:19:20 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4A24C1EE6 for ; Thu, 19 Nov 2020 03:19:20 +0000 (UTC) X-FDA: 77499712080.13.feet52_3e170df2733f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 2BBAA18140B60 for ; Thu, 19 Nov 2020 03:19:20 +0000 (UTC) X-HE-Tag: feet52_3e170df2733f X-Filterd-Recvd-Size: 7073 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Nov 2020 03:19:19 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id d9so4813622oib.3 for ; Wed, 18 Nov 2020 19:19:19 -0800 (PST) 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=2H1F3Ka0Ka6X1YRsJFJYW9O6FRzLC0ev/xiBm/ktwsY=; b=IyWxWBURU+L3lmO9KtVhwYIiuruSmn9ZlAcdweefmTY5hAECqpXAaF/Q6hROSqENTV rwiFeUc5CbI4nOCvIfKSE1SdCRTqL+TTTM7mnf9axLFoIti2sbuSrlqkxXkIHYOXe09F Po5URQbjzkMHe/gbBrO+p4j+MJqV3szMdw/7uIuFsmP/ZvfIcDnysACiLZkSy1RLIkVn FD9EsqbfamHxVSHAnQFe9NnluhjfSemN68nnDk4HSsiYw9ISIy+6jXCVQEmc1KQCov49 QKdlaU8Jts+5w7P0Bpvn0eqdF9AgaGSrysflrv+tBrQn50EyIR6WKMR4HaJxHU8REJoU 4jHg== 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=2H1F3Ka0Ka6X1YRsJFJYW9O6FRzLC0ev/xiBm/ktwsY=; b=XuGiFgWWRDZI2RpbryRbnJKlwmY/IeCpFaqpSf9I6ule/J9su/Ih8FPpsrTH1fDqrU S+9jKTO6MQs/w09UaubO/vvuvGbA/esqSMMLrlNrie6S2PnAQbjTvX40VOHySFEZXnMR rH+7/i61ChkbURPVyvogV+mYESWXe5XY2zO5/ziHCU7obqzwjnaBJPNbcZuFlefQZPNH a+8Z9J3crJcTBBm1MhldiYhyjVNtcWZdtzJMSX8Vwb2HLHiGmzEp6tAalP3zsQZx6MVZ PvKDk/sF51aLYK3bFLmJt7M9KV0jX6rFNdbN45r1yaBUnaRKgV0ClBPxZjrH0rZw/jyX VkGA== X-Gm-Message-State: AOAM530uaxVGYAgTvVIRsXGyY+lu0pE/BoHSGXlys72s1K3efGQ9ZQzE 06eIHwwkSyirrEbEvlye8qC3sWZJveWjtxMI2qEHhA== X-Google-Smtp-Source: ABdhPJwiWiMPc8ySQheAiJ+dOGvXYSSllZWJP6v01aEX68C0WjWv5jKCxWcHdCZq8zmoeaKI9163QlcRHy4zl2ArzSg= X-Received: by 2002:a05:6808:4b:: with SMTP id v11mr1511116oic.169.1605755958902; Wed, 18 Nov 2020 19:19:18 -0800 (PST) MIME-Version: 1.0 References: <20201117181935.3613581-1-minchan@kernel.org> <20201117181935.3613581-5-minchan@kernel.org> <20201119011431.GA136599@KEI> In-Reply-To: <20201119011431.GA136599@KEI> From: John Stultz Date: Wed, 18 Nov 2020 19:19:07 -0800 Message-ID: Subject: Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap To: Hyesoo Yu Cc: Minchan Kim , Andrew Morton , LKML , linux-mm , Matthew Wilcox , david@redhat.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, Suren Baghdasaryan , KyongHo Cho , John Dias , Hridya Valsaraju , Sumit Semwal , Brian Starkey , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Rob Herring , Christian Koenig , "moderated list:DMA BUFFER SHARING FRAMEWORK" 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, Nov 18, 2020 at 5:22 PM Hyesoo Yu wrote: > > On Tue, Nov 17, 2020 at 07:00:54PM -0800, John Stultz wrote: > > So I suspect Rob will push back on this as he has for other dt > > bindings related to ion/dmabuf heaps (I tried to push a similar > > solution to exporting multiple CMA areas via dmabuf heaps). > > > > The proposal he seemed to like best was having an in-kernel function > > that a driver would call to initialize the heap (associated with the > > CMA region the driver is interested in). Similar to Kunihiko Hayashi's > > patch here: > > - https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihiko@socionext.com/ > > > > The one sticking point for that patch (which I think is a good one), > > is that we don't have any in-tree users, so it couldn't be merged yet. > > > > A similar approach might be good here, but again we probably need to > > have at least one in-tree user which could call such a registration > > function. > > Thanks for your review. > > The chunk heap is not considered for device-specific reserved memory and specific driver. > It is similar to system heap, but it only collects high-order pages by using specific cma-area for performance. So, yes I agree, the chunk heap isn't device specific. It's just that the CMA regions usually are tied to devices. The main objection to this style of solution has been due to the fact that the DTS is supposed to describe the physical hardware (in an OS agnostic way), rather than define configuration info for Linux software drivers. Obviously this can be quibbled about, as the normal way of tying devices to CMA has some assumptions of what the driver will use that region for, rather than somehow representing a physical tie between a memory reservation and a device. Nonetheless, Rob has been hesitant to take any sort of ION/DmaBuf Heap DT devices, and has been more interested in some device having the memory reservation reference and the driver for that doing the registration. > It is strange that there is in-tree user who registers chunk heap. > (Wouldn't it be strange for some users to register the system heap?) Well, as there's no reservation/configuration needed, the system heap can register itself. The CMA heap currently only registers the default CMA heap, as we didn't want to expose all CMA regions and there's otherwise no way to pick and choose. > Is there a reason to use dma-heap framework to add cma-area for specific device ? > > Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. > For exclusive access, I guess, the device don't need to register dma-heap for cma area. > It's not really about exclusive access. More just that if you want to bind a memory reservation/region (cma or otherwise), at least for DTS, it needs to bind with some device in DT. Then the device driver can register that region with a heap driver. This avoids adding new Linux-specific software bindings to DT. It becomes a driver implementation detail instead. The primary user of the heap type would probably be a practical pick (ie the display or isp driver). The other potential solution Rob has suggested is that we create some tag for the memory reservation (ie: like we do with cma: "reusable"), which can be used to register the region to a heap. But this has the problem that each tag has to be well defined and map to a known heap. thanks -john