Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp653278ybg; Tue, 9 Jun 2020 09:27:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykYI/qb8x0A+LBlLX5ShZZRIM/NJnqIPNjb5AhFh3cq7KKFUrdwnd9vUA9dvJsSNrYDSiE X-Received: by 2002:a17:906:c10f:: with SMTP id do15mr27384880ejc.249.1591720071917; Tue, 09 Jun 2020 09:27:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591720071; cv=none; d=google.com; s=arc-20160816; b=MA1TrjieDVws0JY4nMgzR3ISXU9RKfni5yKpzEHA/XTWkTmOPKZzzqbzZ56wpAStg4 OUL339OixA7XHRZYxFz8qFtJTUF9Z+2Bv+x15msFVAIEQyysR4w5B3wiEqi1nd1qjvGg maDnqJ4TMhH0awPtAkat6E0WvGx/0KHqiqA4u5zB0A0BhsnpbJlwFIFv1xUbx8RSj1AE sv6vpkZ1xST2xmQqbvG2Pv3k5joTxoO5kftnxq+svKfhfOtxYW1lV/JvTvbZ3yV/DC7Y c3cD7D9oOiW44J2/blowgTkuodCMP+QXGcEft2iTJmO88LkeRgTqzVKLf/VHx8Tc667X gUvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=6wYo84JFN4Jg5g5mspkMLXaR0sIwHMW1pK6ZphSgwNM=; b=fMTCK5ZrKnjYpjXX4jE8DTcviJxDbsIzGOb6lSDTpsn+x23iFJGp6IkcnZuksDlr7A 5G1j4m1oVEBQ0VAvqDgeOu8KA2Iylk1DgQgdQCiQPFndLyyKTwAG/5MS/dZ45nZV38Zp CgL3i7cPLKSh6hBCUAo2c0oNnfRzSzlia+5Zs59vZzo+pYzJEsr4TVW6mOq08hTVDzB5 bbRJswZkpCL9YJOmJ/61BdG8kmLYl4cSjeE/8V+Nbk2evO++48aFojv7KtSNyUDYVCUr LQkdns7Sdb5jgecbqcQXbnIA5yFQXmqSnnbhjoSU4Fe5eRquENyBdvxSpSYh3JliD0+/ p04A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b17si9247791ejb.626.2020.06.09.09.27.27; Tue, 09 Jun 2020 09:27:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728287AbgFIQZK (ORCPT + 99 others); Tue, 9 Jun 2020 12:25:10 -0400 Received: from foss.arm.com ([217.140.110.172]:44788 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725894AbgFIQZK (ORCPT ); Tue, 9 Jun 2020 12:25:10 -0400 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 69E5F1FB; Tue, 9 Jun 2020 09:25:09 -0700 (PDT) Received: from [10.57.49.155] (unknown [10.57.49.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1B0BA3F73D; Tue, 9 Jun 2020 09:25:05 -0700 (PDT) Subject: Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory From: Vladimir Murzin To: Christoph Hellwig , dillon min Cc: Rob Herring , Maxime Coquelin , Alexandre Torgue , linux@armlinux.org.uk, Kate Stewart , allison@lohutok.net, info@metux.net, tglx@linutronix.de, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-stm32@st-md-mailman.stormreply.com, Linux ARM , Linux Kernel Mailing List References: <1591605038-8682-1-git-send-email-dillon.minfei@gmail.com> <1591605038-8682-3-git-send-email-dillon.minfei@gmail.com> <90df5646-e0c4-fcac-d934-4cc922230dd2@arm.com> <20200609153646.GA17969@lst.de> <031034fb-b109-7410-3ff8-e78cd12a5552@arm.com> Message-ID: Date: Tue, 9 Jun 2020 17:25:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <031034fb-b109-7410-3ff8-e78cd12a5552@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/9/20 4:43 PM, Vladimir Murzin wrote: > On 6/9/20 4:36 PM, Christoph Hellwig wrote: >> On Tue, Jun 09, 2020 at 11:22:24PM +0800, dillon min wrote: >>> Hi Vladimir, >>> >>> Thanks for reviewing. >>> >>> Hi Christoph Hellwig, >>> >>> I just want to know if kernel dma mapping/direct is focused on >>> platforms with MMU. >>> leave arch code to handle dma coherent memory management themself for >>> no-MMU platform. >> >> No, I'd really like to consolidate everything that isn't overly >> arch specific eventually. >> >>> >>> so, you just return error code in kernel/dma/mapping.c,direct.c >>> without CONFIG_MMU defined ? >>> which means dma-direct mapping doesn't support !CONFIG_MMU is not a >>> bug, but design as it's. >>> or, just return error code currently, will add dma direct mapping >>> support for !CONFIG_MMU in the >>> future? >>> >>> As Vladimir Murzin's suggestion has changes in kernel code, I need >>> your input to get >>> the design goal about dma-direct mapping, thanks. >> >> Can someone repost the whole patch? >> > > Happy to repost as separate patch once dillon confirms it actually works. > > Meanwhile, I'm trying to understand at which point we lost this > functionality for NOMMU... maybe it will become different patch :) > mmap operation for dma-noop (ancestor of dma-direct) was proposed in [1]. It was suggested to change dma_common_map() instead which was implemented in 07c75d7a6b9e ("drivers: dma-mapping: allow dma_common_mmap() for NOMMU") that removed CONFIG_MMU drom dma_common_mmap(). Later 62fcee9a3bd7 ("dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP") reintroduced CONFIG_MMU in dma_common_mmap(). Even though commit mentions ARM, I do not see how mmap would continue to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations only in cases where caches are implemented or active, in other cases it fully relies on dma-direct. It looks to me that we either should provide NOMMU variant for mmap in dma/direct or (carefully) fix dma/mapping. Thoughts? [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/480600.html Vladimir > Cheers > Vladimir >