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.8 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 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 0C0A4C4361B for ; Thu, 10 Dec 2020 08:15:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6844F23D51 for ; Thu, 10 Dec 2020 08:15:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6844F23D51 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 7816B6B0036; Thu, 10 Dec 2020 03:15:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 70A486B005D; Thu, 10 Dec 2020 03:15:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FB7D6B0068; Thu, 10 Dec 2020 03:15:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id 4CA166B0036 for ; Thu, 10 Dec 2020 03:15:28 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1C17E181AEF39 for ; Thu, 10 Dec 2020 08:15:28 +0000 (UTC) X-FDA: 77576663136.09.knee78_3a10324273f6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 036DD180AD81D for ; Thu, 10 Dec 2020 08:15:27 +0000 (UTC) X-HE-Tag: knee78_3a10324273f6 X-Filterd-Recvd-Size: 7554 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Dec 2020 08:15:27 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id x13so4095733oto.8 for ; Thu, 10 Dec 2020 00:15:27 -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=olWrAE9JSl9kyhmzpxdnQFXpcomh9eOZ+RfshA6M+Yw=; b=p6vfVBFEHoqspcfUNgn7sdgCPUwg36wBSjUfb4RLyJ5vULAwLKN8GmiD6e33Ac8VER FHjrYoCNFIe95KV0RX2o8nIfoYplxquDDBIrmfd7JKKvmFFKtM7pWvdbEurFdl0S+ixF a9WQ7JW4DjKNcbPrKFxaHPTaUsgn16vKzBa02kR0EjoU02V4pI6BZwvElTZfSnsE5U47 FO9QCOfjziR2mf4UreXeSdxMFAqv2P08icJDjBfNGQoS1VkLg1peKe+fS9PJGTp6YjU4 nnDn4b9KTTXh4iWvfxY5u22uy3SpZLdJHQwIhSObuqCNepIpcwc+QkYtjVkMO+J6fFF4 xlCA== 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=olWrAE9JSl9kyhmzpxdnQFXpcomh9eOZ+RfshA6M+Yw=; b=oZxltvPH7vZGbm8wKMZ5Pf72mGn56G0bEPILL4NWb8SIkgGve3YV9gzoF2slhThRl0 MuabR9rWC+9jZbhk1+giybzTi3lgBd9sy9xNnDMof3kFzR3Gfz4ay1+LlFvQqoGSwW2F xLEu2Ndn78UCbRWllvQrKVpsJjRgpRzMe8b/h95nM8ZMWsyNz88WVUPwAXafs4J/YWF9 0zJ1tJ8Xwv4czVhczdILOXkziUVgtl9k5HPWYW0SgLDpLn8uQcL6KxGxVVNFQ6qtXqAH SlwG2jPCH6hNZ3aVu6iVfj1L+kyzYD+Ogk0o6xBJFlXmFKvjJofLJPPa0MEyKXysL7qh ZnZg== X-Gm-Message-State: AOAM530UyNa+eAH7B+0zZLxsrg8nkhEh7zDLMsjEvOYKinQkTT1UMaDh r/vS2kn6K8qhlY8M9xvxkXLnvBjBkkyp5HYDNeYJCQ== X-Google-Smtp-Source: ABdhPJzESi9phEemd0Mo7b+JZyuIKDL6cbPIDC8u/pLidmYe6NDQenscRoW5LI/oInq9snMQmz4nqWLuWYa3ePUC+pk= X-Received: by 2002:a05:6830:1411:: with SMTP id v17mr1298573otp.352.1607588126592; Thu, 10 Dec 2020 00:15:26 -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: From: John Stultz Date: Thu, 10 Dec 2020 00:15:15 -0800 Message-ID: Subject: Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap To: Minchan Kim Cc: Hyesoo Yu , 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" , Kunihiko Hayashi 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, Dec 9, 2020 at 3:53 PM Minchan Kim wrote: > On Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote: > > 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. > > Yub. > > dma-buf really need a way to make exclusive CMA area. Otherwise, default > CMA would be shared among drivers and introduce fragmentation easily > since we couldn't control other drivers. In such aspect, I don't think > current cma-heap works if userspace needs big memory chunk. Yes, the default CMA region is not always optimal. That's why I was hopeful for Kunihiko Hayashi's patch to allow for exposing specific cma regions: https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihiko@socionext.com/ I think it would be a good solution, but all we need is *some* driver which can be considered the primary user/owner of the cma region which would then explicitly export it via the dmabuf heaps. > Here, the problem is there is no in-kernel user to bind the specific > CMA area because the owner will be random in userspace via dma-buf > interface. Well, while I agree that conceptually the dmabuf heaps allow for allocations for multi-device pipelines, and thus are not tied to specific devices. I do think that the memory types exposed are likely to have specific devices/drivers in the pipeline that it matters most to. So I don't see a big issue with the in-kernel driver registering a specific CMA region as a dmabuf heap. > > > 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). > > If it's the only solution, we could create some dummy driver which has > only module_init and bind it from there but I don't think it's a good > idea. Yea, an un-upstreamable dummy driver is maybe what it devolves to in the worst case. But I suspect it would be cleaner for a display or ISP driver that benefits most from the heap type to add the reserved memory reference to their DT node, and on init for them to register the region with the dmabuf heap code. > > 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. > > Do you think that's the only solution to make progress for this feature? > Then, could you elaborate it a bit more or any other ideas from dma-buf > folks? I'm skeptical of that DT tag approach working out, as we'd need a new DT binding for the new tag name, and we'd have to do so for each new heap type that needs this (so non-default cma, your chunk heap, whatever other similar heap types that use reserved regions folks come up with). Having *some* driver take ownership for the reserved region and register it with the appropriate heap type seems much cleaner/flexible and avoids mucking with the DT ABI. thanks -john