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 E165AC433FE for ; Thu, 10 Dec 2020 22:40:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6395423D5A for ; Thu, 10 Dec 2020 22:40:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6395423D5A 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 642406B0036; Thu, 10 Dec 2020 17:40:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F5276B005D; Thu, 10 Dec 2020 17:40:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50B8F6B0068; Thu, 10 Dec 2020 17:40:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 3B9946B0036 for ; Thu, 10 Dec 2020 17:40:53 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EBA47181AEF31 for ; Thu, 10 Dec 2020 22:40:52 +0000 (UTC) X-FDA: 77578843944.21.spot13_4507f94273fc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id CD078180442CE for ; Thu, 10 Dec 2020 22:40:52 +0000 (UTC) X-HE-Tag: spot13_4507f94273fc X-Filterd-Recvd-Size: 6161 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Dec 2020 22:40:52 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id y16so8637117ljk.1 for ; Thu, 10 Dec 2020 14:40:52 -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=tQWc8Ya/SQ8yu30f2oZK/6gpauwPuWfx0xpCfyzU+rc=; b=x0OoNs2LTcACOemmbvVWROexONVqsHi3sxvsxjEkiZzo8yXWD3n2DmqzuWPVW+Lr4b ZJhgIZibF4dI8oEPYTgpj3vnCqYB525AAWOvKChixhX1HbwGJ8vSAaE0408WP1YA75TG S1Nhwojylv6YfsOD+wxBGPQMRLauPSsMloHkNDFklJ1y2vMtdHU/V7YoC69m6DevORi4 kF+vdp2hTOIddsuNkaW670CKMwdt6o8sgaDP56d/wvUEluoyEdEpeOxAOCz6ZjYRN2lS 7NBmhYBNu2YeZZpzS7fwTANlplEp0hZ2PXtBjnNT5YVv1HOonto2C0QmjPttLym4AgAA KM9Q== 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=tQWc8Ya/SQ8yu30f2oZK/6gpauwPuWfx0xpCfyzU+rc=; b=pnJn4xbKtTonf2YJWtfOzdE6n49NvX9/THhNQu2ECaaI1ufdmLByW2nHiZCqvpH0R5 MvUBhbDhWqT/vuQb64zVRaI7LEDTuOWBS/5NHTerYy47oX8YjJGQDTulha0Y7sGxTRas 3yDrQAF+tfUGjuL7io0DVIC0/pthZy9W9i0S3FLJHRZwTMA+BkjL9L5KCXIskUVykzqM hVtiDHgwHYUOcEWmhX+zf6rL73zdPOSLjpuiTd9iKhc/m+FpdFaep53m9/MJ6EVfP6ww J+DZCNQlG1B1q+0O3fhZ7rbSaCms/iTK/ROOs4MOfd66ehrXNWw2kWBpunx9ThMaFgfg aiZA== X-Gm-Message-State: AOAM532r8bMhbKXomLwH5JqoKuMU7aehfva6Vhxjc598aQhzAvYpvf8U xVwa2TylGnLwyFXUjsD/y8wRcrERaKXUlEkP2E/4Rw== X-Google-Smtp-Source: ABdhPJzyv+/ixUU7Z4gURlK7gfSgTumIWFyuUn9BMQjVKhZOvuG2b6lPyD6nHt8L6UK49w2MpVe7eroKVnmkRciqHvk= X-Received: by 2002:a05:651c:10e:: with SMTP id a14mr3979348ljb.128.1607640050539; Thu, 10 Dec 2020 14:40:50 -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 14:40:38 -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 Thu, Dec 10, 2020 at 8:06 AM Minchan Kim wrote: > On Thu, Dec 10, 2020 at 12:15:15AM -0800, John Stultz wrote: > > 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. > > Then, I am worry about that we spread out dma_heap_add_cma to too many > drivers since kernel doesn't how userspace will use it. > For example, system 1 could have device A-B-C pipeline so they added > it A driver. After that, system 2 could have device B-C-D pipeline > so they add dma_heap_add_cma into B device. I'm not sure I see this as a major issue? If the drivers add it based on the dt memory reference, those will be configured to not add duplicate heaps (and even so the heap driver can also ensure we don't try to add a heap twice). > > 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. > > As I mentioned above, it could be a display at this moment but it could > be different driver next time. If I miss your point, let me know. > I guess I just don't see potentially having the registration calls added to multiple drivers as a big problem. Ideally, yes, I'd probably rather see a DT node that would allow the heap driver to register specified regions, but that's been NACKed multiple times. Given that, having hooks in device drivers to export the region seems to me like the next best approach, as it avoids DT ABI ( if ends up its a bad approach, its not something we have to keep). The bigger problem right now is not that there are too many places the registration call would be made from, but that there aren't upstream drivers which I'm aware of where it would currently make sense to add specific dma_heap_add_cma() registration hooks to. We need an upstream user of Kunihiko Hayashi's patch. thanks -john