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 08857CDB474 for ; Mon, 23 Oct 2023 06:16:38 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=zS7HO+zya7f5mkg2lK9t/mkX5KKZOGedJRjRtbpg6Pw=; b=2dpgim79OKFzRA WoR4rnFSI15pS+x4PWlFvccjI8JvzjL/7BNYazdu0t6LuQD8/+RTOBYV2z+udKCqEu+IQghFtlWmB OVkFOJeDfkxzgwVhERmr0/X7kzZ2gXo58Hll1sL9K9SPmba03DHMClSDBWFgBO4Je2a5mO2UIAO6I aTm/Fw7ye/XsfHT5BONGd+JHkbVIkfloDdJxwRm6umOvuuL8fPhK50xt4UigqwirIjCFp3M6n89jr sIH0bt9IbzMnI3/Xs2cxAhfM8Ng5W0u55dTZvGIJNfUG+TzDXElfax85ECa4u/eM7Cv9rxxmDxi6n VLaBh6Nw93b5PugSf0pQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1quoEW-006WD5-2h; Mon, 23 Oct 2023 06:16:12 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1quoEU-006WCB-0E for linux-arm-kernel@lists.infradead.org; Mon, 23 Oct 2023 06:16:11 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id DB32968AA6; Mon, 23 Oct 2023 08:16:01 +0200 (CEST) Date: Mon, 23 Oct 2023 08:16:01 +0200 From: Christoph Hellwig To: Marek Szyprowski Cc: Christoph Hellwig , Jim Quinlan , Linus Walleij , bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com, Russell King , Arnd Bergmann , Geert Uytterhoeven , "Russell King (Oracle)" , Andrew Morton , Jonathan Corbet , Thomas Gleixner , Sebastian Reichel , "Mike Rapoport (IBM)" , Eric DeVolder , Nathan Chancellor , "Kirill A. Shutemov" , Christophe Leroy , "moderated list:ARM PORT" , open list Subject: Re: [PATCH v1 1/1] ARM: Select DMA_DIRECT_REMAP to fix restricted DMA Message-ID: <20231023061601.GA12056@lst.de> References: <20230926175208.9298-1-james.quinlan@broadcom.com> <20230926175208.9298-2-james.quinlan@broadcom.com> <20231002061628.GC911@lst.de> <20231006074045.GA15303@lst.de> <3515448c-8a4b-4669-9f80-2f55c5100674@samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3515448c-8a4b-4669-9f80-2f55c5100674@samsung.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231022_231610_276893_0B7E72BE X-CRM114-Status: GOOD ( 18.01 ) 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 On Fri, Oct 20, 2023 at 10:16:46AM +0200, Marek Szyprowski wrote: > For historical reasons (performance and limitations of the pre-ARM v7 > cores), on the 32bit ARM the whole kernel's direct mapping is done using > so called 'sections' (1MiB size afair). Those sections are created in > the per-process MMU page tables (there are no separate MMU table for the > kernel mappings), so altering those mappings requires updating bits in > all processes in the system. Practically this means that those mappings > has to be static once created during boot time. That's actually the same on many architetures, and matches the explanation I heard from Russell before. > That's why when no CMA > is selected, the whole dma_alloc_coherent() allocations are limited to > rather small region, which is already remapped as non-cached during boot. But this does not match my understanding of the code: - arch_dma_alloc calls __dma_alloc with is_coherent set to false - __dma_alloc then selects cma_allocator if CMA is supported for the device / allocation, else remap_allocator if the allocation is allowed to block and only if blocking is not allowed pool_allocator to allocate from the boot-time pool This very match matches the dma-direct flow with DMA_DIRECT_REMAP selected. The major exception is the direct mapping of the CMA allocations done by arm32. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel