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 AC552C433EF for ; Tue, 23 Nov 2021 11:58:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236796AbhKWMCE (ORCPT ); Tue, 23 Nov 2021 07:02:04 -0500 Received: from foss.arm.com ([217.140.110.172]:51650 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231180AbhKWMCD (ORCPT ); Tue, 23 Nov 2021 07:02:03 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDC521063; Tue, 23 Nov 2021 03:58:54 -0800 (PST) Received: from [10.57.56.56] (unknown [10.57.56.56]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8214F3F5A1; Tue, 23 Nov 2021 03:58:52 -0800 (PST) Message-ID: <75ea1026-63e5-165a-9e07-27b5ac4c7579@arm.com> Date: Tue, 23 Nov 2021 11:58:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH 0/3] Allow restricted-dma-pool to customize IO_TLB_SEGSIZE Content-Language: en-GB To: Hsin-Yi Wang , Christoph Hellwig Cc: Marek Szyprowski , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Rob Herring , Maxime Ripard , - , devicetree@vger.kernel.org, Matthias Brugger , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, senozhatsky@chromium.org, tfiga@chromium.org References: <20211123112104.3530135-1-hsinyi@chromium.org> From: Robin Murphy In-Reply-To: <20211123112104.3530135-1-hsinyi@chromium.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-11-23 11:21, Hsin-Yi Wang wrote: > Default IO_TLB_SEGSIZE (128) slabs may be not enough for some use cases. > This series adds support to customize io_tlb_segsize for each > restricted-dma-pool. > > Example use case: > > mtk-isp drivers[1] are controlled by mtk-scp[2] and allocate memory through > mtk-scp. In order to use the noncontiguous DMA API[3], we need to use > the swiotlb pool. mtk-scp needs to allocate memory with 2560 slabs. > mtk-isp drivers also needs to allocate memory with 200+ slabs. Both are > larger than the default IO_TLB_SEGSIZE (128) slabs. Are drivers really doing streaming DMA mappings that large? If so, that seems like it might be worth trying to address in its own right for the sake of efficiency - allocating ~5MB of memory twice and copying it back and forth doesn't sound like the ideal thing to do. If it's really about coherent DMA buffer allocation, I thought the plan was that devices which expect to use a significant amount and/or size of coherent buffers would continue to use a shared-dma-pool for that? It's still what the binding implies. My understanding was that swiotlb_alloc() is mostly just a fallback for the sake of drivers which mostly do streaming DMA but may allocate a handful of pages worth of coherent buffers here and there. Certainly looking at the mtk_scp driver, that seems like it shouldn't be going anywhere near SWIOTLB at all. Robin. > [1] (not in upstream) https://patchwork.kernel.org/project/linux-media/cover/20190611035344.29814-1-jungo.lin@mediatek.com/ > [2] https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/mtk_scp.c > [3] https://patchwork.kernel.org/project/linux-media/cover/20210909112430.61243-1-senozhatsky@chromium.org/ > > Hsin-Yi Wang (3): > dma: swiotlb: Allow restricted-dma-pool to customize IO_TLB_SEGSIZE > dt-bindings: Add io-tlb-segsize property for restricted-dma-pool > arm64: dts: mt8183: use restricted swiotlb for scp mem > > .../reserved-memory/shared-dma-pool.yaml | 8 +++++ > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 +-- > include/linux/swiotlb.h | 1 + > kernel/dma/swiotlb.c | 34 ++++++++++++++----- > 4 files changed, 37 insertions(+), 10 deletions(-) > 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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 8F8A7C433F5 for ; Tue, 23 Nov 2021 11:59:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3535C80CF9; Tue, 23 Nov 2021 11:59:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs_eNoU84wqZ; Tue, 23 Nov 2021 11:59:00 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 23DEC80CD8; Tue, 23 Nov 2021 11:59:00 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id E56D1C002E; Tue, 23 Nov 2021 11:58:59 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 30BCBC0012 for ; Tue, 23 Nov 2021 11:58:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 18FFE80CD0 for ; Tue, 23 Nov 2021 11:58:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOytsMfCZ5hU for ; Tue, 23 Nov 2021 11:58:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp1.osuosl.org (Postfix) with ESMTP id 0FE6B80BAC for ; Tue, 23 Nov 2021 11:58:55 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDC521063; Tue, 23 Nov 2021 03:58:54 -0800 (PST) Received: from [10.57.56.56] (unknown [10.57.56.56]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8214F3F5A1; Tue, 23 Nov 2021 03:58:52 -0800 (PST) Message-ID: <75ea1026-63e5-165a-9e07-27b5ac4c7579@arm.com> Date: Tue, 23 Nov 2021 11:58:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH 0/3] Allow restricted-dma-pool to customize IO_TLB_SEGSIZE Content-Language: en-GB To: Hsin-Yi Wang , Christoph Hellwig References: <20211123112104.3530135-1-hsinyi@chromium.org> From: Robin Murphy In-Reply-To: <20211123112104.3530135-1-hsinyi@chromium.org> Cc: devicetree@vger.kernel.org, - , linux-kernel@vger.kernel.org, senozhatsky@chromium.org, iommu@lists.linux-foundation.org, Rob Herring , linux-mediatek@lists.infradead.org, Maxime Ripard , Matthias Brugger , linux-arm-kernel@lists.infradead.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021-11-23 11:21, Hsin-Yi Wang wrote: > Default IO_TLB_SEGSIZE (128) slabs may be not enough for some use cases. > This series adds support to customize io_tlb_segsize for each > restricted-dma-pool. > > Example use case: > > mtk-isp drivers[1] are controlled by mtk-scp[2] and allocate memory through > mtk-scp. In order to use the noncontiguous DMA API[3], we need to use > the swiotlb pool. mtk-scp needs to allocate memory with 2560 slabs. > mtk-isp drivers also needs to allocate memory with 200+ slabs. Both are > larger than the default IO_TLB_SEGSIZE (128) slabs. Are drivers really doing streaming DMA mappings that large? If so, that seems like it might be worth trying to address in its own right for the sake of efficiency - allocating ~5MB of memory twice and copying it back and forth doesn't sound like the ideal thing to do. If it's really about coherent DMA buffer allocation, I thought the plan was that devices which expect to use a significant amount and/or size of coherent buffers would continue to use a shared-dma-pool for that? It's still what the binding implies. My understanding was that swiotlb_alloc() is mostly just a fallback for the sake of drivers which mostly do streaming DMA but may allocate a handful of pages worth of coherent buffers here and there. Certainly looking at the mtk_scp driver, that seems like it shouldn't be going anywhere near SWIOTLB at all. Robin. > [1] (not in upstream) https://patchwork.kernel.org/project/linux-media/cover/20190611035344.29814-1-jungo.lin@mediatek.com/ > [2] https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/mtk_scp.c > [3] https://patchwork.kernel.org/project/linux-media/cover/20210909112430.61243-1-senozhatsky@chromium.org/ > > Hsin-Yi Wang (3): > dma: swiotlb: Allow restricted-dma-pool to customize IO_TLB_SEGSIZE > dt-bindings: Add io-tlb-segsize property for restricted-dma-pool > arm64: dts: mt8183: use restricted swiotlb for scp mem > > .../reserved-memory/shared-dma-pool.yaml | 8 +++++ > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 +-- > include/linux/swiotlb.h | 1 + > kernel/dma/swiotlb.c | 34 ++++++++++++++----- > 4 files changed, 37 insertions(+), 10 deletions(-) > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 21EE8C433EF for ; Tue, 23 Nov 2021 11:59:18 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oYr1e1ihE7ge7W/K3K8O3Q65CMMoGeOXP27L2LE6Nn8=; b=ynVMI5Unu1njHt VhNxEFulGCa1NULhoiTvJOnwEfppoFh3ApDDyojTd8IFF+ga/xf/jo8KXHoJLi7HRKPdDhlHk3ip1 pzaQj7k3pXD7wEtyMl9aVTcYcm3CXHd/fQoqdBuAvcpA81Vyex5OKNX1OzjxUPLC5QrT0JGn7udCj Gt0kvx9ufOIhohQy/Hnsfro1Y8T/VJCdJRnx8AWtDeov7FsLPvC7eiEZEjOs+GXR1cweAyCIRGOP7 vHRbaKkETECXPkx9XninmQhE0BQSLIPyHrVPGcUxvkG+lwUzDkcNk36jOduVozYb5mMzzw1sgUYBh BJRkQZAusrXmdpK7O69Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpUS6-001z6K-VV; Tue, 23 Nov 2021 11:59:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpURr-001z0f-Nz; Tue, 23 Nov 2021 11:58:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDC521063; Tue, 23 Nov 2021 03:58:54 -0800 (PST) Received: from [10.57.56.56] (unknown [10.57.56.56]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8214F3F5A1; Tue, 23 Nov 2021 03:58:52 -0800 (PST) Message-ID: <75ea1026-63e5-165a-9e07-27b5ac4c7579@arm.com> Date: Tue, 23 Nov 2021 11:58:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH 0/3] Allow restricted-dma-pool to customize IO_TLB_SEGSIZE Content-Language: en-GB To: Hsin-Yi Wang , Christoph Hellwig Cc: Marek Szyprowski , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Rob Herring , Maxime Ripard , - , devicetree@vger.kernel.org, Matthias Brugger , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, senozhatsky@chromium.org, tfiga@chromium.org References: <20211123112104.3530135-1-hsinyi@chromium.org> From: Robin Murphy In-Reply-To: <20211123112104.3530135-1-hsinyi@chromium.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211123_035855_874962_5AA7D7E6 X-CRM114-Status: GOOD ( 15.47 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On 2021-11-23 11:21, Hsin-Yi Wang wrote: > Default IO_TLB_SEGSIZE (128) slabs may be not enough for some use cases. > This series adds support to customize io_tlb_segsize for each > restricted-dma-pool. > > Example use case: > > mtk-isp drivers[1] are controlled by mtk-scp[2] and allocate memory through > mtk-scp. In order to use the noncontiguous DMA API[3], we need to use > the swiotlb pool. mtk-scp needs to allocate memory with 2560 slabs. > mtk-isp drivers also needs to allocate memory with 200+ slabs. Both are > larger than the default IO_TLB_SEGSIZE (128) slabs. Are drivers really doing streaming DMA mappings that large? If so, that seems like it might be worth trying to address in its own right for the sake of efficiency - allocating ~5MB of memory twice and copying it back and forth doesn't sound like the ideal thing to do. If it's really about coherent DMA buffer allocation, I thought the plan was that devices which expect to use a significant amount and/or size of coherent buffers would continue to use a shared-dma-pool for that? It's still what the binding implies. My understanding was that swiotlb_alloc() is mostly just a fallback for the sake of drivers which mostly do streaming DMA but may allocate a handful of pages worth of coherent buffers here and there. Certainly looking at the mtk_scp driver, that seems like it shouldn't be going anywhere near SWIOTLB at all. Robin. > [1] (not in upstream) https://patchwork.kernel.org/project/linux-media/cover/20190611035344.29814-1-jungo.lin@mediatek.com/ > [2] https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/mtk_scp.c > [3] https://patchwork.kernel.org/project/linux-media/cover/20210909112430.61243-1-senozhatsky@chromium.org/ > > Hsin-Yi Wang (3): > dma: swiotlb: Allow restricted-dma-pool to customize IO_TLB_SEGSIZE > dt-bindings: Add io-tlb-segsize property for restricted-dma-pool > arm64: dts: mt8183: use restricted swiotlb for scp mem > > .../reserved-memory/shared-dma-pool.yaml | 8 +++++ > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 +-- > include/linux/swiotlb.h | 1 + > kernel/dma/swiotlb.c | 34 ++++++++++++++----- > 4 files changed, 37 insertions(+), 10 deletions(-) > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 6DF6BC433F5 for ; Tue, 23 Nov 2021 12:00:14 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0dpIzuXebfZjAljKLwHfEpGAfe0XJh/hR+7kro0bR+U=; b=E3d7dfm/Pz/5KM XZHPw+usu8tCVt/CbK1yztuldcVpU1vtTx2CwVE5yi3siMGnVxNTHtk4UDoLkFxtOllFvpA/g1v0M 3k+POa9rs4ow/gMFeqiqkDwGtII+EFEG4L0js7cHTEqVG9IArZdVUl0q/WZ+CNhZY8bXr1adMzgG2 Fk1z5ZCKDRI3dVzGo26NxV608UirFH97+cAeAJqAWhDl9HxoJZmNsbj4UT66jQSVbUCSjuh7r4eK5 z/6h2KxYzcarfL6V6FiLL6Xp3oY56FTLZ0sKBPI/Me5umw0Nje48nEplS9JY+8nX4Xil110JAMyNQ ZxvxNNCX7ipgSiKTl0eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpURw-001z2a-1t; Tue, 23 Nov 2021 11:59:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpURr-001z0f-Nz; Tue, 23 Nov 2021 11:58:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDC521063; Tue, 23 Nov 2021 03:58:54 -0800 (PST) Received: from [10.57.56.56] (unknown [10.57.56.56]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8214F3F5A1; Tue, 23 Nov 2021 03:58:52 -0800 (PST) Message-ID: <75ea1026-63e5-165a-9e07-27b5ac4c7579@arm.com> Date: Tue, 23 Nov 2021 11:58:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH 0/3] Allow restricted-dma-pool to customize IO_TLB_SEGSIZE Content-Language: en-GB To: Hsin-Yi Wang , Christoph Hellwig Cc: Marek Szyprowski , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Rob Herring , Maxime Ripard , - , devicetree@vger.kernel.org, Matthias Brugger , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, senozhatsky@chromium.org, tfiga@chromium.org References: <20211123112104.3530135-1-hsinyi@chromium.org> From: Robin Murphy In-Reply-To: <20211123112104.3530135-1-hsinyi@chromium.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211123_035855_874962_5AA7D7E6 X-CRM114-Status: GOOD ( 15.47 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-11-23 11:21, Hsin-Yi Wang wrote: > Default IO_TLB_SEGSIZE (128) slabs may be not enough for some use cases. > This series adds support to customize io_tlb_segsize for each > restricted-dma-pool. > > Example use case: > > mtk-isp drivers[1] are controlled by mtk-scp[2] and allocate memory through > mtk-scp. In order to use the noncontiguous DMA API[3], we need to use > the swiotlb pool. mtk-scp needs to allocate memory with 2560 slabs. > mtk-isp drivers also needs to allocate memory with 200+ slabs. Both are > larger than the default IO_TLB_SEGSIZE (128) slabs. Are drivers really doing streaming DMA mappings that large? If so, that seems like it might be worth trying to address in its own right for the sake of efficiency - allocating ~5MB of memory twice and copying it back and forth doesn't sound like the ideal thing to do. If it's really about coherent DMA buffer allocation, I thought the plan was that devices which expect to use a significant amount and/or size of coherent buffers would continue to use a shared-dma-pool for that? It's still what the binding implies. My understanding was that swiotlb_alloc() is mostly just a fallback for the sake of drivers which mostly do streaming DMA but may allocate a handful of pages worth of coherent buffers here and there. Certainly looking at the mtk_scp driver, that seems like it shouldn't be going anywhere near SWIOTLB at all. Robin. > [1] (not in upstream) https://patchwork.kernel.org/project/linux-media/cover/20190611035344.29814-1-jungo.lin@mediatek.com/ > [2] https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/mtk_scp.c > [3] https://patchwork.kernel.org/project/linux-media/cover/20210909112430.61243-1-senozhatsky@chromium.org/ > > Hsin-Yi Wang (3): > dma: swiotlb: Allow restricted-dma-pool to customize IO_TLB_SEGSIZE > dt-bindings: Add io-tlb-segsize property for restricted-dma-pool > arm64: dts: mt8183: use restricted swiotlb for scp mem > > .../reserved-memory/shared-dma-pool.yaml | 8 +++++ > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 +-- > include/linux/swiotlb.h | 1 + > kernel/dma/swiotlb.c | 34 ++++++++++++++----- > 4 files changed, 37 insertions(+), 10 deletions(-) > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH 0/3] Allow restricted-dma-pool to customize IO_TLB_SEGSIZE Date: Tue, 23 Nov 2021 11:58:47 +0000 Message-ID: <75ea1026-63e5-165a-9e07-27b5ac4c7579@arm.com> References: <20211123112104.3530135-1-hsinyi@chromium.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Content-Language: en-GB In-Reply-To: <20211123112104.3530135-1-hsinyi-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Hsin-Yi Wang , Christoph Hellwig Cc: Marek Szyprowski , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Maxime Ripard , - , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matthias Brugger , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, senozhatsky-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org On 2021-11-23 11:21, Hsin-Yi Wang wrote: > Default IO_TLB_SEGSIZE (128) slabs may be not enough for some use cases. > This series adds support to customize io_tlb_segsize for each > restricted-dma-pool. > > Example use case: > > mtk-isp drivers[1] are controlled by mtk-scp[2] and allocate memory through > mtk-scp. In order to use the noncontiguous DMA API[3], we need to use > the swiotlb pool. mtk-scp needs to allocate memory with 2560 slabs. > mtk-isp drivers also needs to allocate memory with 200+ slabs. Both are > larger than the default IO_TLB_SEGSIZE (128) slabs. Are drivers really doing streaming DMA mappings that large? If so, that seems like it might be worth trying to address in its own right for the sake of efficiency - allocating ~5MB of memory twice and copying it back and forth doesn't sound like the ideal thing to do. If it's really about coherent DMA buffer allocation, I thought the plan was that devices which expect to use a significant amount and/or size of coherent buffers would continue to use a shared-dma-pool for that? It's still what the binding implies. My understanding was that swiotlb_alloc() is mostly just a fallback for the sake of drivers which mostly do streaming DMA but may allocate a handful of pages worth of coherent buffers here and there. Certainly looking at the mtk_scp driver, that seems like it shouldn't be going anywhere near SWIOTLB at all. Robin. > [1] (not in upstream) https://patchwork.kernel.org/project/linux-media/cover/20190611035344.29814-1-jungo.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org/ > [2] https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/mtk_scp.c > [3] https://patchwork.kernel.org/project/linux-media/cover/20210909112430.61243-1-senozhatsky-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org/ > > Hsin-Yi Wang (3): > dma: swiotlb: Allow restricted-dma-pool to customize IO_TLB_SEGSIZE > dt-bindings: Add io-tlb-segsize property for restricted-dma-pool > arm64: dts: mt8183: use restricted swiotlb for scp mem > > .../reserved-memory/shared-dma-pool.yaml | 8 +++++ > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 +-- > include/linux/swiotlb.h | 1 + > kernel/dma/swiotlb.c | 34 ++++++++++++++----- > 4 files changed, 37 insertions(+), 10 deletions(-) >