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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 981ABC43334 for ; Tue, 12 Jul 2022 10:56:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232690AbiGLK4R (ORCPT ); Tue, 12 Jul 2022 06:56:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232356AbiGLK4O (ORCPT ); Tue, 12 Jul 2022 06:56:14 -0400 Received: from sender4-op-o14.zoho.com (sender4-op-o14.zoho.com [136.143.188.14]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34EA9AE54E; Tue, 12 Jul 2022 03:56:12 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A3668C43334 for ; Tue, 12 Jul 2022 10:57:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Subject:References: In-Reply-To:Message-ID:Cc:To:From:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=MmcujhUeyVAwhPJCH1BFmgIzbXPGnTLFDeCVUjD8Okg=; b=4EMnvo/DvsIfWwjS6/JwX+dtqK m46oHzfo2e4LD0iBnC2pcLxw2V5sMR1ic0BsXDqzyJ6xTi7aJVUnI1Ppy66YZ/rjzn4mbXfnc/zQ/ 0svRr+dXInhI5sw2Wo+0cLc6WqlNg24NunxbH6R587q2vMB71NlkIDXDirlTuwUFOtQrsNhF2YjHC DH4M4HkAKAZBPJItJ8wz3Lb9DbpQbT+fF9qhZTIEwvVb5/CryxO1p1KDoKBeAOsXV6FKsAIMf4UcX PGKqRkaSYJg5PJ6cTq3sD9gvEQj2i/CeEJUYgGyy8itt6eFI7ftFMHZzgXsU6BXWlWPkdREDN6o6n gF4UMgoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBDYj-00A8bg-WA; Tue, 12 Jul 2022 10:56:06 +0000 Received: from sender4-op-o14.zoho.com ([136.143.188.14]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBDYf-00A8WJ-NW for linux-arm-kernel@lists.infradead.org; Tue, 12 Jul 2022 10:56:04 +0000 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 Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220712_035601_846918_0FC36843 X-CRM114-Status: GOOD ( 32.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel