From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934964AbdAJPCI (ORCPT ); Tue, 10 Jan 2017 10:02:08 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:54250 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759156AbdAJPCB (ORCPT ); Tue, 10 Jan 2017 10:02:01 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Christoph Hellwig , Nikita Yushchenko , Keith Busch , Sagi Grimberg , Jens Axboe , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-renesas-soc@vger.kernel.org, Simon Horman , linux-pci@vger.kernel.org, Bjorn Helgaas , artemi.ivanov@cogentembedded.com Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Tue, 10 Jan 2017 16:00:47 +0100 Message-ID: <7276604.Zo5Nlf9pQ3@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20170110144453.GA27156@lst.de> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <1988852.3nyUoruEjG@wuerfel> <20170110144453.GA27156@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:+Q1F/dnaE7pUizcf342ofET55BvYSnvj82SZQsTfxFo3gpkb1pW Mou05POI/aGzhPHvRW9nW/g1q9Cwz+YWF9Y+QXEzpbZZ9aEcetw367imhd+PBln8envuMh3 ChK8YuzEOTZStYaZiUL9C8iiY6SKR/ffO0r7pSu74hMd7Oh5fyu/jfDK6iJtTxrlPa8/C0L otqG1UBcJ3S2P9r1FRFnQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:k0piT3E/+1A=:nDe4is40nPYscegjvSGrpI UQPGoWxlhOydsX1t3hTiMGdwiuvWJ6mytt/MFTeTaKXlwVbLmtQ7giEObOhCzf8DlQv4mrPgb /H/IolxDcsmV2PdCKR3S2JcSkeWi42zlKP4+SXE8d4vDqx21D1dBjy1c4zCKVEl/ARRM/Gzcu nUMEXNRYNfewCb/0I3OAXKl6lo5L7BhSudCRGUSLVJsBfhNDRclc/Rz/KURDsKbg6rQt8/Ln4 n3ZmGSdpYWrXsbe7G8zb71ggXtECTltTYP5/yMEcGbPOGPOXU0SlGLHJl3UMEdhyv3Q563RYd o9rnyy1HfcKEhPAoUo0hYuop0nnX0xN8IYPNmpGVNlLat/8YmcGC6luZIgqMPAbtLQTK55/dy HNTDeFHhMfSGOGT61QrDF3HVa4G5HgdEkKS5AwSF01y70M+rexCxh1bHEE/XgqdW1/TU0Cnw5 LD5Dkxeh7hxaqjaQjNaEEa6N/mmjRCeclTHrSOzOKIO5JS8XAKWcKVnA3FsUnyv6Uxm+4AyXM CiCyozDQPupdSfV7ec41PAR12gT5lK9Jp1G2VcJruoscNjAhuwbFjQqMGnyNUPh2T70wRQB44 qGAqUz7CP8ELKcykMoQQ7/Zz54JvIBgvYrokWXfdUKWGP7oxxcsuJMShekC9MIprzdV5AUGw9 +SSGjXV+xWTywLSziIt+j8yaJeH9Wj9BmItI97YZQ0KxMsziud8BYTxXQ9pTc33uHpgnPw3lP ykhPre3xHlC2/Lkz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > > there are several 64-bit architectures that do not have swiotlb > > (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc > > always use some form of IOMMU, but the other four apparently don't, > > so we would need to add swiotlb support there to remove all the > > bounce buffering in network and block layers. > > mips has lots of weird swiotlb wire-up in it's board code (the swiotlb > arch glue really needs some major cleanup..), My reading of the MIPS code was that only the 64-bit platforms use it, but there are a number of 32-bit platforms that have 64-bit physical addresses and don't. > as does arm. Not sure about the others. 32-bit ARM doesn't actually use SWIOTLB at all, despite selecting it in Kconfig. I think Xen uses it for its own purposes, but nothing else does. Most ARM platforms can't actually have RAM beyond 4GB, and the ones that do have it tend to also come with an IOMMU, but I remember at least BCM53xx actually needing swiotlb on some chip revisions that are widely used and that cannot DMA to the second memory bank from PCI (!). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Tue, 10 Jan 2017 16:00:47 +0100 Message-ID: <7276604.Zo5Nlf9pQ3@wuerfel> In-Reply-To: <20170110144453.GA27156@lst.de> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <1988852.3nyUoruEjG@wuerfel> <20170110144453.GA27156@lst.de> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nikita Yushchenko , Jens Axboe , Sagi Grimberg , linux-pci@vger.kernel.org, Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Keith Busch , Simon Horman , linux-renesas-soc@vger.kernel.org, Bjorn Helgaas , artemi.ivanov@cogentembedded.com, Christoph Hellwig Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > > there are several 64-bit architectures that do not have swiotlb > > (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc > > always use some form of IOMMU, but the other four apparently don't, > > so we would need to add swiotlb support there to remove all the > > bounce buffering in network and block layers. > > mips has lots of weird swiotlb wire-up in it's board code (the swiotlb > arch glue really needs some major cleanup..), My reading of the MIPS code was that only the 64-bit platforms use it, but there are a number of 32-bit platforms that have 64-bit physical addresses and don't. > as does arm. Not sure about the others. 32-bit ARM doesn't actually use SWIOTLB at all, despite selecting it in Kconfig. I think Xen uses it for its own purposes, but nothing else does. Most ARM platforms can't actually have RAM beyond 4GB, and the ones that do have it tend to also come with an IOMMU, but I remember at least BCM53xx actually needing swiotlb on some chip revisions that are widely used and that cannot DMA to the second memory bank from PCI (!). Arnd _______________________________________________ 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: arnd@linaro.org (Arnd Bergmann) Date: Tue, 10 Jan 2017 16:00:47 +0100 Subject: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask In-Reply-To: <20170110144453.GA27156@lst.de> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <1988852.3nyUoruEjG@wuerfel> <20170110144453.GA27156@lst.de> Message-ID: <7276604.Zo5Nlf9pQ3@wuerfel> On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017@11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > > there are several 64-bit architectures that do not have swiotlb > > (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc > > always use some form of IOMMU, but the other four apparently don't, > > so we would need to add swiotlb support there to remove all the > > bounce buffering in network and block layers. > > mips has lots of weird swiotlb wire-up in it's board code (the swiotlb > arch glue really needs some major cleanup..), My reading of the MIPS code was that only the 64-bit platforms use it, but there are a number of 32-bit platforms that have 64-bit physical addresses and don't. > as does arm. Not sure about the others. 32-bit ARM doesn't actually use SWIOTLB at all, despite selecting it in Kconfig. I think Xen uses it for its own purposes, but nothing else does. Most ARM platforms can't actually have RAM beyond 4GB, and the ones that do have it tend to also come with an IOMMU, but I remember at least BCM53xx actually needing swiotlb on some chip revisions that are widely used and that cannot DMA to the second memory bank from PCI (!). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@linaro.org (Arnd Bergmann) Date: Tue, 10 Jan 2017 16:00:47 +0100 Subject: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask In-Reply-To: <20170110144453.GA27156@lst.de> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <1988852.3nyUoruEjG@wuerfel> <20170110144453.GA27156@lst.de> Message-ID: <7276604.Zo5Nlf9pQ3@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote: > On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote: > > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of > > 32-bit architectures without swiotlb (arc, arm, some mips32), and > > there are several 64-bit architectures that do not have swiotlb > > (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc > > always use some form of IOMMU, but the other four apparently don't, > > so we would need to add swiotlb support there to remove all the > > bounce buffering in network and block layers. > > mips has lots of weird swiotlb wire-up in it's board code (the swiotlb > arch glue really needs some major cleanup..), My reading of the MIPS code was that only the 64-bit platforms use it, but there are a number of 32-bit platforms that have 64-bit physical addresses and don't. > as does arm. Not sure about the others. 32-bit ARM doesn't actually use SWIOTLB at all, despite selecting it in Kconfig. I think Xen uses it for its own purposes, but nothing else does. Most ARM platforms can't actually have RAM beyond 4GB, and the ones that do have it tend to also come with an IOMMU, but I remember at least BCM53xx actually needing swiotlb on some chip revisions that are widely used and that cannot DMA to the second memory bank from PCI (!). Arnd