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, 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 0210AC433FE for ; Wed, 9 Dec 2020 23:53:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7901C207E8 for ; Wed, 9 Dec 2020 23:53:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7901C207E8 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 AC08E6B005C; Wed, 9 Dec 2020 18:53:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A70346B005D; Wed, 9 Dec 2020 18:53:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9111C6B0068; Wed, 9 Dec 2020 18:53:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id 7B9526B005C for ; Wed, 9 Dec 2020 18:53:33 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4812F181AC9CB for ; Wed, 9 Dec 2020 23:53:33 +0000 (UTC) X-FDA: 77575398306.01.sound02_550d402273f3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 28AF310229473 for ; Wed, 9 Dec 2020 23:53:33 +0000 (UTC) X-HE-Tag: sound02_550d402273f3 X-Filterd-Recvd-Size: 8495 Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Dec 2020 23:53:32 +0000 (UTC) Received: by mail-pg1-f196.google.com with SMTP id t3so2433331pgi.11 for ; Wed, 09 Dec 2020 15:53:32 -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=LINlBO/TC6i2SZUXr1MFYVpHThXjdgKp5RJMwGfVaFM=; b=Ny+CXFK7gIl0c60QTsv6Z179rJXR+V/YO1bIOBjW/l36zV9omQz1PBALfvBpcGzTzF gXsqkrEm1CcmvQ2EoKrLaYwZSi7fVot1JQROXWmWH1LBOFx4BkOQ2vw/sS8SYaZr5z5s CCWxSXYyQEkYlKvrA910I3lxzryURgyLRfyU+bP+f8XJiZpG7Cxgmuzk/k8N6yL/U/1C D+ActPuN+MZir1Yt/UE4quga/vC9g4s2goTY8mC0rdT9kSKYmLJhEUENbGpUHrWM1P9S 81RQTmr3YzjSHxMDCd232An57Vj2JZjbjHu6+yKppbsP30SaKbdHosSsfCL2ZdGKxKTI 8VJw== 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=LINlBO/TC6i2SZUXr1MFYVpHThXjdgKp5RJMwGfVaFM=; b=bQ3QBTPdF3TpVk2kA78Zg28fGMZeT+Tzrw5snPgaA9eBg/3/uFf/OL83NjpYOpHUzA WrnUHzWh0hYoUtU4WimmyAj+JkswrrCObYRhByH1geoRbfvmCcVepU35MPSeUPs31GBU 1MlXDGHTBuGh5dfNgk6/szXLLFQd723zLGblQEd1Rm63OcPBJx8bSSJnLOHrrZ8qoQkK APzvOByAThaUK6TPnlgdOUYrgB4UywXwYaz73Njx+vMfWWbfkduFmi8GLj17CAs/RzcI pxR1ThEaPWeAA3NXpRucIcElb1PHhp6i6I9tqWpu92qtL4DqxkLGf55d6qvI4cUWqPPh 6zbg== X-Gm-Message-State: AOAM53137vSNoAxQ+qjJ+WDn/dcR3QjhAqc+qWv9lWs2Pd9wocfor2x7 pFzEuEdnGGCTR9JXyU2L8ic= X-Google-Smtp-Source: ABdhPJxXQYKC6C+ZALoZwKd3MPYBy3Ldrw2eWk/ZTeLxkruiOLwLFI4xttcrwjLymhD24YOSNPZv7Q== X-Received: by 2002:a63:cd01:: with SMTP id i1mr4137530pgg.83.1607558011479; Wed, 09 Dec 2020 15:53:31 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id f7sm3742524pfe.30.2020.12.09.15.53.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Dec 2020 15:53:30 -0800 (PST) Date: Wed, 9 Dec 2020 15:53:27 -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" 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 Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote: > 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. 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. 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. > > > 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. > > 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?