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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3EE6C2D0DB for ; Thu, 30 Jan 2020 16:40:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9EF2E20674 for ; Thu, 30 Jan 2020 16:40:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727359AbgA3QkN (ORCPT ); Thu, 30 Jan 2020 11:40:13 -0500 Received: from verein.lst.de ([213.95.11.211]:40961 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727193AbgA3QkN (ORCPT ); Thu, 30 Jan 2020 11:40:13 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id AF3F568B20; Thu, 30 Jan 2020 17:40:10 +0100 (CET) Date: Thu, 30 Jan 2020 17:40:10 +0100 From: Christoph Hellwig To: Peter Ujfalusi Cc: Christoph Hellwig , robh@kernel.org, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , linux-arm-kernel@lists.infradead.org, rogerq@ti.com Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130164010.GA6472@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> <20200130075332.GA30735@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 30, 2020 at 03:04:37PM +0200, Peter Ujfalusi via iommu wrote: > On 30/01/2020 9.53, Christoph Hellwig wrote: > > [skipping the DT bits, as I'm everything but an expert on that..] > > > > On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > >> I agree on the phys_to_dma(). It should fail for addresses which does > >> not fall into any of the ranges. > >> It is just a that we in Linux don't have the concept atm for ranges, we > >> have only _one_ range which applies to every memory address. > > > > what does atm here mean? > > struct device have only single dma_pfn_offset, one can not have multiple > ranges defined. If we have then only the first is taken and the physical > address and dma address is discarded, only the dma_pfn_offset is stored > and used. > > > We have needed multi-range support for quite a while, as common broadcom > > SOCs do need it. So patches for that are welcome at least from the > > DMA layer perspective (kinda similar to your pseudo code earlier) > > But do they have dma_pfn_offset != 0? Well, with that I mean multiple ranges with different offsets. Take a look at arch/mips/bmips/dma.c:__phys_to_dma() and friends. This is an existing implementation for mips, but there are arm and arm64 SOCs using the same logic on the market as well, and we'll want to support them eventually. > The dma_pfn_offset is _still_ applied to the mask we are trying to set > (and validate) via dma-direct. And for the general case that is exactly the right thing to do, we just need to deal with really odd ZONE_DMA placements like yours. > > We'll need to find the minimum change to make it work > > for now without switching ops, even if it isn't the correct one, and > > then work from there. > > Sure, but can we fix the regression by reverting to arm_ops for now only > if dma_pfn_offset is not 0? It used to work fine in the past at least it > appeared to work on K2 platforms. But that will cause yet another regression in what we have just fixed with using the generic direct ops, at which points it turns into who screams louder. For now I'm tempted to throw something like this in, which is a bit of a hack, but actually 100% matches what various architectures have historically done: diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 6af7ae83c4ad..6ba9ee6e20bd 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -482,6 +482,9 @@ int dma_direct_supported(struct device *dev, u64 mask) { u64 min_mask; + if (mask >= DMA_BIT_MASK(32)) + return 1; + if (IS_ENABLED(CONFIG_ZONE_DMA)) min_mask = DMA_BIT_MASK(zone_dma_bits); else 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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7F3DC2D0DB for ; Thu, 30 Jan 2020 16:40:18 +0000 (UTC) Received: from whitealder.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 mail.kernel.org (Postfix) with ESMTPS id 95A3720674 for ; Thu, 30 Jan 2020 16:40:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95A3720674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 57002877AD; Thu, 30 Jan 2020 16:40:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMJl-bgn03xY; Thu, 30 Jan 2020 16:40:17 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by whitealder.osuosl.org (Postfix) with ESMTP id A3FB187686; Thu, 30 Jan 2020 16:40:17 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 989ECC1796; Thu, 30 Jan 2020 16:40:17 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 93BA2C0171 for ; Thu, 30 Jan 2020 16:40:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 8F8A7876D5 for ; Thu, 30 Jan 2020 16:40:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlVaOtTAAdUF for ; Thu, 30 Jan 2020 16:40:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by whitealder.osuosl.org (Postfix) with ESMTPS id 265C587686 for ; Thu, 30 Jan 2020 16:40:15 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id AF3F568B20; Thu, 30 Jan 2020 17:40:10 +0100 (CET) Date: Thu, 30 Jan 2020 17:40:10 +0100 From: Christoph Hellwig To: Peter Ujfalusi Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130164010.GA6472@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> <20200130075332.GA30735@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: robh@kernel.org, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, rogerq@ti.com 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Thu, Jan 30, 2020 at 03:04:37PM +0200, Peter Ujfalusi via iommu wrote: > On 30/01/2020 9.53, Christoph Hellwig wrote: > > [skipping the DT bits, as I'm everything but an expert on that..] > > > > On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > >> I agree on the phys_to_dma(). It should fail for addresses which does > >> not fall into any of the ranges. > >> It is just a that we in Linux don't have the concept atm for ranges, we > >> have only _one_ range which applies to every memory address. > > > > what does atm here mean? > > struct device have only single dma_pfn_offset, one can not have multiple > ranges defined. If we have then only the first is taken and the physical > address and dma address is discarded, only the dma_pfn_offset is stored > and used. > > > We have needed multi-range support for quite a while, as common broadcom > > SOCs do need it. So patches for that are welcome at least from the > > DMA layer perspective (kinda similar to your pseudo code earlier) > > But do they have dma_pfn_offset != 0? Well, with that I mean multiple ranges with different offsets. Take a look at arch/mips/bmips/dma.c:__phys_to_dma() and friends. This is an existing implementation for mips, but there are arm and arm64 SOCs using the same logic on the market as well, and we'll want to support them eventually. > The dma_pfn_offset is _still_ applied to the mask we are trying to set > (and validate) via dma-direct. And for the general case that is exactly the right thing to do, we just need to deal with really odd ZONE_DMA placements like yours. > > We'll need to find the minimum change to make it work > > for now without switching ops, even if it isn't the correct one, and > > then work from there. > > Sure, but can we fix the regression by reverting to arm_ops for now only > if dma_pfn_offset is not 0? It used to work fine in the past at least it > appeared to work on K2 platforms. But that will cause yet another regression in what we have just fixed with using the generic direct ops, at which points it turns into who screams louder. For now I'm tempted to throw something like this in, which is a bit of a hack, but actually 100% matches what various architectures have historically done: diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 6af7ae83c4ad..6ba9ee6e20bd 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -482,6 +482,9 @@ int dma_direct_supported(struct device *dev, u64 mask) { u64 min_mask; + if (mask >= DMA_BIT_MASK(32)) + return 1; + if (IS_ENABLED(CONFIG_ZONE_DMA)) min_mask = DMA_BIT_MASK(zone_dma_bits); else _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_DBL_ABUSE_MALW,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E631C2D0DB for ; Thu, 30 Jan 2020 16:40:24 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id D2A9120674 for ; Thu, 30 Jan 2020 16:40:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CusCoP94" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2A9120674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=+5UPQN6yTB0Ny94BgDkC2drT7AVfza2zgwHvVI3MHjk=; b=CusCoP94fuOMGr qs8zlNPwbw7gLsVIwlMiMVUOFSHTpMKarJDm/4K2q0vcL2nHS69ckUwfm6IdWhLtyXDNFWtokUxRl falxg8YO5fcZY+efzojnKHFL7z9AboUdqHqxFHoERmUJOX3hN7duMV2LjxQ88i/okPhdqekrpb7Tq QKLM/4c3VKVaJ6ZVlsx/2pcdYaL1bl8f9aey+gclyr5Rd747ziPAVB3jfVJNYYj34j9Bz9lpA27L+ 6Ni2LmicGXIi2FYHTd4vZd3FniHS4NEyGmsDLmmnFKdpmpWCCW509IJAWyOzdB0zFOCNJHYKNjulE LesLXXPaCBtk3mlgPrlA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ixCra-00082d-Dw; Thu, 30 Jan 2020 16:40:18 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ixCrX-00081r-LL for linux-arm-kernel@lists.infradead.org; Thu, 30 Jan 2020 16:40:17 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id AF3F568B20; Thu, 30 Jan 2020 17:40:10 +0100 (CET) Date: Thu, 30 Jan 2020 17:40:10 +0100 From: Christoph Hellwig To: Peter Ujfalusi Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130164010.GA6472@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> <20200130075332.GA30735@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20200130_084015_846986_AB1EDF5D X-CRM114-Status: GOOD ( 21.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: robh@kernel.org, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, rogerq@ti.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 30, 2020 at 03:04:37PM +0200, Peter Ujfalusi via iommu wrote: > On 30/01/2020 9.53, Christoph Hellwig wrote: > > [skipping the DT bits, as I'm everything but an expert on that..] > > > > On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > >> I agree on the phys_to_dma(). It should fail for addresses which does > >> not fall into any of the ranges. > >> It is just a that we in Linux don't have the concept atm for ranges, we > >> have only _one_ range which applies to every memory address. > > > > what does atm here mean? > > struct device have only single dma_pfn_offset, one can not have multiple > ranges defined. If we have then only the first is taken and the physical > address and dma address is discarded, only the dma_pfn_offset is stored > and used. > > > We have needed multi-range support for quite a while, as common broadcom > > SOCs do need it. So patches for that are welcome at least from the > > DMA layer perspective (kinda similar to your pseudo code earlier) > > But do they have dma_pfn_offset != 0? Well, with that I mean multiple ranges with different offsets. Take a look at arch/mips/bmips/dma.c:__phys_to_dma() and friends. This is an existing implementation for mips, but there are arm and arm64 SOCs using the same logic on the market as well, and we'll want to support them eventually. > The dma_pfn_offset is _still_ applied to the mask we are trying to set > (and validate) via dma-direct. And for the general case that is exactly the right thing to do, we just need to deal with really odd ZONE_DMA placements like yours. > > We'll need to find the minimum change to make it work > > for now without switching ops, even if it isn't the correct one, and > > then work from there. > > Sure, but can we fix the regression by reverting to arm_ops for now only > if dma_pfn_offset is not 0? It used to work fine in the past at least it > appeared to work on K2 platforms. But that will cause yet another regression in what we have just fixed with using the generic direct ops, at which points it turns into who screams louder. For now I'm tempted to throw something like this in, which is a bit of a hack, but actually 100% matches what various architectures have historically done: diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 6af7ae83c4ad..6ba9ee6e20bd 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -482,6 +482,9 @@ int dma_direct_supported(struct device *dev, u64 mask) { u64 min_mask; + if (mask >= DMA_BIT_MASK(32)) + return 1; + if (IS_ENABLED(CONFIG_ZONE_DMA)) min_mask = DMA_BIT_MASK(zone_dma_bits); else _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel