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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1158FC43334 for ; Tue, 12 Jul 2022 10:56:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8243B94005E; Tue, 12 Jul 2022 06:56:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FA9C94005D; Tue, 12 Jul 2022 06:56:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7104494005E; Tue, 12 Jul 2022 06:56:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6326A94005D for ; Tue, 12 Jul 2022 06:56:09 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3D9062075B for ; Tue, 12 Jul 2022 10:56:09 +0000 (UTC) X-FDA: 79678143258.09.6A2D7B1 Received: from sender4-op-o14.zoho.com (sender4-op-o14.zoho.com [136.143.188.14]) by imf25.hostedemail.com (Postfix) with ESMTP id 973B7A006D for ; Tue, 12 Jul 2022 10:56:08 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1657623350; cv=none; d=zohomail.com; s=zohoarc; b=NesB+pgNfxQce8Q3B1kMWPE9IL4UaavFicShfBxDFet9aF74U8kRb82jonZ3bs+4FvuLgAKU9+8jejGXqQzpBHQcmaiEsLiwNMdBmqKiP3xvEIFygJ0UBJnoRhkcRiHE6oH7w4SSiq/M1XX0CoV6d6WeEiMAjxeKHgrQPupaI5I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1657623350; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=tFSe8DXlfnP6rHVBGRr8qpDTToiIeu8mAIvR+SIfcvs=; b=WpIBPNEcOfsLcMZzFn2MWXCUqTxRahZaFWyPQd4agadCJQDTNS7wzR+DxgM/o/wcjEf6LPmFWqLgjWcUusfScsh/KM3YGc4VORFs0DrnA0v4ZEsdUDYk5UuvTHVDMRJ4+dAW/tli8Li1rlhAcjYYTvX3OWddcvD1o//zPVAtSbY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1657623350; s=zmail; d=linux.beauty; i=me@linux.beauty; h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=tFSe8DXlfnP6rHVBGRr8qpDTToiIeu8mAIvR+SIfcvs=; b=K9L+GTzW7q5PPB0CK2GhHx8xFcFfkcRU2cAR9moGiynNvzWaw9rXMqet08cIl0FC fuGdtYBHr9454wBiW7TdTYuNPdJ6pXlM/mcW6U9rkYt9qM/kV+ofw/8NgmtBgIeLhfj /CmN+dKnhILe3EByBAGfdjGzWS2mWfmYT1ZwQKRE= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1657623348256160.91761174332316; Tue, 12 Jul 2022 03:55:48 -0700 (PDT) Date: Tue, 12 Jul 2022 18:55:48 +0800 From: Li Chen To: "Arnd Bergmann" Cc: "Catalin Marinas" , "Will Deacon" , "Rob Herring" , "Frank Rowand" , "Andrew Morton" , "Li Chen" , "Linux ARM" , "Linux Kernel Mailing List" , "DTML" , "Linux-MM" Message-ID: <181f20d0403.121f433c8600165.2068876337784123868@linux.beauty> In-Reply-To: References: <20220711122459.13773-1-me@linux.beauty> <20220711122459.13773-5-me@linux.beauty> <181efcca6ae.de84203d522625.7740936811073442334@linux.beauty> <181f1d88b64.e2eb2601586551.453778983551010212@linux.beauty> Subject: Re: [PATCH 4/4] sample/reserved_mem: Introduce a sample of struct page and dio support to no-map rmem MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=linux.beauty header.s=zmail header.b=K9L+GTzW; dmarc=none; spf=pass (imf25.hostedemail.com: domain of me@linux.beauty designates 136.143.188.14 as permitted sender) smtp.mailfrom=me@linux.beauty; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657623368; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tFSe8DXlfnP6rHVBGRr8qpDTToiIeu8mAIvR+SIfcvs=; b=b8dz19ayUsq8goZNdLkejySgnuJebfTPlxojTFaKPjT11Ib8rX/oL/M3ltvscyj6Phaxkm 8CTybM0QEWKePJODi7g81lwfYRBefuO1IbPu3JgabLKAAK/FhxoaSALlJU4weQGHqMLFBg mg7fZTH3Km6pn42YsBbrJ4MGhHABZ1g= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1657623368; a=rsa-sha256; cv=pass; b=ov/HiFGjqYsLTBawzSMFL4RvNI2RjtXXnE84SG3LycppInVB0AWYQQ9n12yoN/C+QJvRkQ mKeQAZNcg3Yk7S5/yLV6CcY0Zp5CmjI53tNWAwHmUgOprERPsqb+BBYhhn8YTAABTH70RM gPvzW7kct0jVXleT75+oHUgNi+hjSQs= X-Stat-Signature: y4r1s74xcj6qgxpsgm9js3bs7jhw51m5 X-Rspamd-Queue-Id: 973B7A006D Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.beauty header.s=zmail header.b=K9L+GTzW; dmarc=none; spf=pass (imf25.hostedemail.com: domain of me@linux.beauty designates 136.143.188.14 as permitted sender) smtp.mailfrom=me@linux.beauty; arc=pass ("zohomail.com:s=zohoarc:i=1") X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1657623368-873647 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: Hi Arnd, ---- On Tue, 12 Jul 2022 18:08:10 +0800 Arnd Bergmann wrote --- > On Tue, Jul 12, 2022 at 11:58 AM Li Chen wrote: > > > On Tue, Jul 12, 2022 at 2:26 AM Li Chen wrote: > > > > ---- On Mon, 11 Jul 2022 21:28:10 +0800 Arnd Bergmann wrote --- > > > > > On Mon, Jul 11, 2022 at 2:24 PM Li Chen wrote: > > > > > The problem here is that the DT is meant to describe the platform in an OS > > > > > independent way, so having a binding that just corresponds to a user space > > > > > interface is not a good abstraction. > > > > > > > > Gotcha, but IMO dts + rmem is the only choice for our use case. In our real > > > > case, we use reg instead of size to specify the physical address, so > > > > memremap cannot be used. > > > > > > Does your hardware require a fixed address for the buffer? If it can be > > > anywhere in memory (or at least within a certain range) but just has to > > > be physically contiguous, the normal way would be to use a CMA area > > > to allocate from, which gives you 'struct page' backed pages. > > > > The limitation is our DSP can only access 32bit memory, but total dram is > 4G, so I cannot use > > "size = <...>" in our real case (it might get memory above 4G). I'm not sure if other vendors' DSP also has > > this limitation, if so, how do they deal with it if throughput matters. > > This is a common limitation that gets handled automatically by setting > the dma_mask of the device through the dma-ranges property in DT. > When the driver does dma_alloc_coherent() or similar to gets its buffer, > it will then allocate pages below this boundary. Thanks for the tip! I wasn't aware that dma-ranges can be used by devices other than PCIe controllers. > If you need a large contiguous memory area, then using CMA allows > you to specify a region of memory that is kept reserved for DMA > allocations, so a call to dma_alloc_coherent() on your device will > get contiguous pages from that area, and move other data in those > pages elsewhere if necessary. non-movable data is allocated from > pages outside of the CMA reserved area in this case. We need a large memory pool, around 2G. I will try CMA and dma-ranges later! Regards, Li