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=-2.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FSL_HELO_FAKE,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 45EE1C433FE for ; Thu, 10 Dec 2020 23:31:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CDEE223E55 for ; Thu, 10 Dec 2020 23:31:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDEE223E55 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 F209B6B0036; Thu, 10 Dec 2020 18:31:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF9DE6B005D; Thu, 10 Dec 2020 18:31:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D99216B0068; Thu, 10 Dec 2020 18:31:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id C0A496B0036 for ; Thu, 10 Dec 2020 18:31:00 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 82F56181AEF32 for ; Thu, 10 Dec 2020 23:31:00 +0000 (UTC) X-FDA: 77578970280.04.pest56_4f0951d273fc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 6172E800CD1E for ; Thu, 10 Dec 2020 23:31:00 +0000 (UTC) X-HE-Tag: pest56_4f0951d273fc X-Filterd-Recvd-Size: 7379 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Dec 2020 23:30:59 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id i3so5684505pfd.6 for ; Thu, 10 Dec 2020 15:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DxIVSUX2H6bimNutMDtAzIsDtpsebc1xO6PGsZ2Pwhk=; b=GLRkf6JQL1ptO05KUdb29Wdoj51vQzqeflF1WXIJFrnJiwxWUSO6LD5UW/dQri2ULl 7QOrSSeGEpb68pcn9L/fFd7hRoRiQmwg8YgLf8weoubgjcOYqqNfrBP7As0weMoHsLb2 Zeqzs1Nx4Ah8yomvfrQovm/gEB2hH8COhGfUw5mePmVVZHlDl5VB9aEWYON4en+DoZNT ucf2LpDwtCCrDkkDUAnzEXyFHS9+g6RjvwNliWU4NjPEiWvamrvarJsaCapXe5qDkMW2 L5RBqKjX91B0sL0cgHvra3sfXHRhGTBpdfZjvcXf8y94yWyoX2I4Eg9FF7HsRrDbHGlb 8Ozw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=DxIVSUX2H6bimNutMDtAzIsDtpsebc1xO6PGsZ2Pwhk=; b=QDDSClgp5bqaQZYFXrTvXgNf3xCsn4/3SJBHRFO4h1uHjDY5cfSabILNPXVyqOySqi k4ktxyeffJOD7qMGGbN5Hjki/7TRdENM690YJmwAk8NAxNxcT2Y55yk5JpKHLOBm7EJE f+9Z8EipW0BBS0S3ePYPF5vFqYmDpk2LcVM5kwixqCHxUbrWSNXP+BJN1SlvbMQ7dRJz BIBbYDB2/EYCORFI8uSOtf4QZpvNaCoXwftuczH7ZioA5jGBj4BysSZo2iZy+M0OJMMy 6iY5Jz+Yftn7FjNvF7VS4qXcG1y5j6q4oEAwcWYsXO6kg4IDxmJjmDhluoXhC/cn95B7 AjfA== X-Gm-Message-State: AOAM53263QVNk4RYMH19B9oHcyukY6OrvnTa2somgfsCDM0DZryZu5Oj TLDyuTJeR49B1w6TpGT30r8= X-Google-Smtp-Source: ABdhPJzQ34O5574nawCtthvGcN4o4HywTqDu4/7/e/5QfeGCNPMRhSxX4RTQEVQMyXAdO/WoAlfGnw== X-Received: by 2002:a62:19ca:0:b029:19d:cd0d:af83 with SMTP id 193-20020a6219ca0000b029019dcd0daf83mr9006284pfz.51.1607643058804; Thu, 10 Dec 2020 15:30:58 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id e24sm5119240pjt.16.2020.12.10.15.30.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 15:30:57 -0800 (PST) Date: Thu, 10 Dec 2020 15:30:54 -0800 From: Minchan Kim To: John Stultz 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 Subject: Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap Message-ID: References: <20201117181935.3613581-1-minchan@kernel.org> <20201117181935.3613581-5-minchan@kernel.org> <20201119011431.GA136599@KEI> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 02:40:38PM -0800, John Stultz wrote: > 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). Sure, it doesn't have any problem to work but design ponint of view, it looks werid to me in that one of random driver in the specific scenario should have the heap registration and then we propagate the heap registeration logics to other drivers day by day. To avoid DT binding with dmabuf directy but it seems we have bad design. To me, it sounds like to toss DT with anonymous dmabuf binding problem to device drivers. > > > > 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. Hmm, if that's only way to proceed, Hyesoo, do you have any specifid driver in your mind to bind the CMA area?