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 A52D4E7D240 for ; Tue, 26 Sep 2023 06:50:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230334AbjIZGvD (ORCPT ); Tue, 26 Sep 2023 02:51:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbjIZGvA (ORCPT ); Tue, 26 Sep 2023 02:51:00 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E01FE6; Mon, 25 Sep 2023 23:50:54 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 2588267373; Tue, 26 Sep 2023 08:50:50 +0200 (CEST) Date: Tue, 26 Sep 2023 08:50:49 +0200 From: Christoph Hellwig To: Tomasz Figa Cc: Fang Hui , Christoph Hellwig , Robin Murphy , m.szyprowski@samsung.com, mchehab@kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, anle.pan@nxp.com, xuegang.liu@nxp.com Subject: Re: [PATCH] MA-21654 Use dma_alloc_pages in vb2_dma_sg_alloc_compacted Message-ID: <20230926065049.GA5606@lst.de> References: <20230914145812.12851-1-hui.fang@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 20, 2023 at 04:41:08PM +0900, Tomasz Figa wrote: > On Thu, Sep 14, 2023 at 4:41 PM Fang Hui wrote: > > > > On system with "CONFIG_ZONE_DMA32=y", if the allocated physical address is > > First of all, thanks a lot for the patch! Please check my review comments below. > > Is CONFIG_ZONE_DMA32 really the factor that triggers the problem? My > understanding was that the problem was that the hardware has 32-bit > DMA, but the system has physical memory at addresses beyond the first > 4G. You should NEVER disable CONFIG_ZONE_DMA32 for a system that has memory > 4GB. I've made this point repeatedly, but the ARM64 maintainers insist on making it configurable instead of selecting it like most other 64-bit architetures that aren't guaranteed to always use a IOMMU. We need to stop that. > Hmm, when I was proposing dma_alloc_pages(), I missed that it returns > a DMA handle. That on its own can be handled by saving the returned > handles somewhere in struct vb2_dma_sg_buf, but there is a bigger > problem - the function would actually create a mapping if the DMA > device requires some mapping management (e.g. is behind an IOMMU), > which is undesirable, because we create the mapping ourselves below > anyway... > > @Christoph Hellwig @Robin Murphy I need your thoughts on this as > well. Would it make sense to have a variant of dma_alloc_pages() that > only allocates the pages, but doesn't perform the mapping? (Or a flag > that tells the implementation to skip creating a mapping.) dma_map_pages needs to map the pages as part of finding out that the allocation actually works. So skipping it can't really be done. So why do you want to create your own mapping anyway?