From patchwork Fri Feb 15 14:45:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 10815049 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 969C8139A for ; Fri, 15 Feb 2019 14:46:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8755B2F800 for ; Fri, 15 Feb 2019 14:46:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7B5922F807; Fri, 15 Feb 2019 14:46:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 259272F800 for ; Fri, 15 Feb 2019 14:46:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727212AbfBOOqI (ORCPT ); Fri, 15 Feb 2019 09:46:08 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34776 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729828AbfBOOqH (ORCPT ); Fri, 15 Feb 2019 09:46:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EHWMeKcx9wnViTN9ihf7C7jkTSiQjOUf9Ygq4DjgD68=; b=MUFjJhePSTNbviuLt/tzzQlegp 6C9Yny9pX5Am+pFoqCjYBamJtvFxF6VSGg+uAHsh/OJSQ6jCVcELcnUrK0xLdXNmyR55fEhmNLfNr nBgr9WyvK54spzUaipd9NFC68oneY9FOpYTXwpiE55/Kf4Y8gj+xtP4qBte35QMr/M8Ho5iELjX48 e+CyhgSxIGwifBPgn7Cw885m8yz9s1g0q4sBWaqQG1+m8Ss0Ku3D7olkf1Xl9mocUXCzheBDn4t7P BJ2HJkbtFg8jn0vfC1k2dBaYNX4aiML7B/tIyhRdDyq45PYYCnwYAf2p4/FvqYqKcSm8PF2RQjLvE 8JHgpukg==; Received: from [91.112.108.175] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gueke-0005PN-22; Fri, 15 Feb 2019 14:46:04 +0000 From: Christoph Hellwig To: "David S. Miller" , Helge Deller Cc: Robin Murphy , iommu@lists.linux-foundation.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/5] ccio: allow large DMA masks Date: Fri, 15 Feb 2019 15:45:55 +0100 Message-Id: <20190215144559.8777-2-hch@lst.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190215144559.8777-1-hch@lst.de> References: <20190215144559.8777-1-hch@lst.de> MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There is no harm in setting a 64-bit mask even if we don't need it, and the current ccio code is one of the few place in the kernel still rejecting larger than required DMA masks. Signed-off-by: Christoph Hellwig --- drivers/parisc/ccio-dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c index 8d2fc84119c6..24a68fb7b2f9 100644 --- a/drivers/parisc/ccio-dma.c +++ b/drivers/parisc/ccio-dma.c @@ -710,8 +710,8 @@ ccio_dma_supported(struct device *dev, u64 mask) return 0; } - /* only support 32-bit devices (ie PCI/GSC) */ - return (int)(mask == 0xffffffffUL); + /* only support 32-bit or better devices (ie PCI/GSC) */ + return (int)(mask >= 0xffffffffUL); } /** From patchwork Fri Feb 15 14:45:56 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 10815039 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2909E6C2 for ; Fri, 15 Feb 2019 14:46:12 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1BE4A2F800 for ; Fri, 15 Feb 2019 14:46:12 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0FC792F807; Fri, 15 Feb 2019 14:46:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 86F392F800 for ; Fri, 15 Feb 2019 14:46:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392297AbfBOOqK (ORCPT ); Fri, 15 Feb 2019 09:46:10 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34814 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732862AbfBOOqK (ORCPT ); Fri, 15 Feb 2019 09:46:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3Z8IK9ObumLKlQEoOhPYkD5tqWFaSaaGvy74lBW38/o=; b=Kf1WYNyx8+s3FJ6Ck3PvKF9cdl e6EC7WxxODy2u7hHPGnK6S2S9m3XG1pAZE263aswnHhatPe2IyhPhf0oF1xufDjfmkrU37+476jtD vFhy9UNqy25mG8RP1DyVhlfKgTgTp5zGwa9JrmYCU1oyzb+Qp1FsjnuMhnFfaC9PuNpsouIkbRBft 1IR4PkSkMB02h4kk30XqtrR1lPbxgRRmQeWKAh8HDed1y8NwwA25cLZTMPJxaIasWAJ1Kk7U4PVx3 c74spC/CTmyEqKaNkbDaXXmPci+1esyb50q2dGOfyPaG2ssEpRIoJjrwsAiQPQDyv4Cfi8EkLSbRs s6bflFpA==; Received: from [91.112.108.175] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1guekg-0005PX-Cg; Fri, 15 Feb 2019 14:46:07 +0000 From: Christoph Hellwig To: "David S. Miller" , Helge Deller Cc: Robin Murphy , iommu@lists.linux-foundation.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/5] sparc64: refactor the ali DMA quirk Date: Fri, 15 Feb 2019 15:45:56 +0100 Message-Id: <20190215144559.8777-3-hch@lst.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190215144559.8777-1-hch@lst.de> References: <20190215144559.8777-1-hch@lst.de> MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Do the quirk first in the dma_supported routines, as we don't need any of the other checks for it, and remove the duplicate mask checking that is already done by the callers. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/kernel/iommu.c | 7 +++--- arch/sparc/kernel/kernel.h | 6 ++++- arch/sparc/kernel/pci.c | 46 ++++++++++++----------------------- arch/sparc/kernel/pci_sun4v.c | 5 +++- 4 files changed, 27 insertions(+), 37 deletions(-) diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c index b1a09080e8da..0c253f1c852e 100644 --- a/arch/sparc/kernel/iommu.c +++ b/arch/sparc/kernel/iommu.c @@ -745,14 +745,13 @@ static int dma_4u_supported(struct device *dev, u64 device_mask) { struct iommu *iommu = dev->archdata.iommu; + if (ali_sound_dma_hack(dev, device_mask)) + return 1; + if (device_mask > DMA_BIT_MASK(32)) return 0; if ((device_mask & iommu->dma_addr_mask) == iommu->dma_addr_mask) return 1; -#ifdef CONFIG_PCI - if (dev_is_pci(dev)) - return pci64_dma_supported(to_pci_dev(dev), device_mask); -#endif return 0; } diff --git a/arch/sparc/kernel/kernel.h b/arch/sparc/kernel/kernel.h index ddffd368e057..f6f498ba3198 100644 --- a/arch/sparc/kernel/kernel.h +++ b/arch/sparc/kernel/kernel.h @@ -45,7 +45,11 @@ void __irq_entry smp_receive_signal_client(int irq, struct pt_regs *regs); void __irq_entry smp_kgdb_capture_client(int irq, struct pt_regs *regs); /* pci.c */ -int pci64_dma_supported(struct pci_dev *pdev, u64 device_mask); +#ifdef CONFIG_PCI +int ali_sound_dma_hack(struct device *dev, u64 device_mask); +#else +#define ali_sound_dma_hack(dev, mask) (0) +#endif /* signal32.c */ void do_sigreturn32(struct pt_regs *regs); diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c index bcfec6a85d23..5ed43828e078 100644 --- a/arch/sparc/kernel/pci.c +++ b/arch/sparc/kernel/pci.c @@ -956,51 +956,35 @@ void arch_teardown_msi_irq(unsigned int irq) } #endif /* !(CONFIG_PCI_MSI) */ -static void ali_sound_dma_hack(struct pci_dev *pdev, int set_bit) +/* ALI sound chips generate 31-bits of DMA, a special register + * determines what bit 31 is emitted as. + */ +int ali_sound_dma_hack(struct device *dev, u64 device_mask) { + struct iommu *iommu = dev->archdata.iommu; struct pci_dev *ali_isa_bridge; u8 val; - /* ALI sound chips generate 31-bits of DMA, a special register - * determines what bit 31 is emitted as. - */ + if (!dev_is_pci(dev)) + return 0; + + if (to_pci_dev(dev)->vendor != PCI_VENDOR_ID_AL || + to_pci_dev(dev)->device != PCI_DEVICE_ID_AL_M5451 || + device_mask != 0x7fffffff) + return 0; + ali_isa_bridge = pci_get_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533, NULL); pci_read_config_byte(ali_isa_bridge, 0x7e, &val); - if (set_bit) + if (iommu->dma_addr_mask & 0x80000000) val |= 0x01; else val &= ~0x01; pci_write_config_byte(ali_isa_bridge, 0x7e, val); pci_dev_put(ali_isa_bridge); -} - -int pci64_dma_supported(struct pci_dev *pdev, u64 device_mask) -{ - u64 dma_addr_mask; - - if (pdev == NULL) { - dma_addr_mask = 0xffffffff; - } else { - struct iommu *iommu = pdev->dev.archdata.iommu; - - dma_addr_mask = iommu->dma_addr_mask; - - if (pdev->vendor == PCI_VENDOR_ID_AL && - pdev->device == PCI_DEVICE_ID_AL_M5451 && - device_mask == 0x7fffffff) { - ali_sound_dma_hack(pdev, - (dma_addr_mask & 0x80000000) != 0); - return 1; - } - } - - if (device_mask >= (1UL << 32UL)) - return 0; - - return (device_mask & dma_addr_mask) == dma_addr_mask; + return 1; } void pci_resource_to_user(const struct pci_dev *pdev, int bar, diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c index fa0e42b4cbfb..d30eb22b6e11 100644 --- a/arch/sparc/kernel/pci_sun4v.c +++ b/arch/sparc/kernel/pci_sun4v.c @@ -676,6 +676,9 @@ static int dma_4v_supported(struct device *dev, u64 device_mask) struct iommu *iommu = dev->archdata.iommu; u64 dma_addr_mask = iommu->dma_addr_mask; + if (ali_sound_dma_hack(dev, device_mask)) + return 1; + if (device_mask > DMA_BIT_MASK(32)) { if (iommu->atu) dma_addr_mask = iommu->atu->dma_addr_mask; @@ -685,7 +688,7 @@ static int dma_4v_supported(struct device *dev, u64 device_mask) if ((device_mask & dma_addr_mask) == dma_addr_mask) return 1; - return pci64_dma_supported(to_pci_dev(dev), device_mask); + return 0; } static const struct dma_map_ops sun4v_dma_ops = { From patchwork Fri Feb 15 14:45:57 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 10815047 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2E7CC6C2 for ; Fri, 15 Feb 2019 14:46:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 22A9E2F800 for ; Fri, 15 Feb 2019 14:46:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 172402F807; Fri, 15 Feb 2019 14:46:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B1EE02F800 for ; Fri, 15 Feb 2019 14:46:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395139AbfBOOqM (ORCPT ); Fri, 15 Feb 2019 09:46:12 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34826 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2395136AbfBOOqM (ORCPT ); Fri, 15 Feb 2019 09:46:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vWBg3JgcaBfg1pycBuwVJLdLYWOrWYb8fSLJb2JWrbw=; b=dqPnss6bDOC+lOREHVQtyFpKE+ atVsWDKV6aifHeGSqhsjlWy+VkpBmUHAUyQP7PjtapP8NUfmKOaoVS1nlChGl6BIV5sVuaE2Wh+Ox JGKuGmFXHHKeD5xXMUbR/JRq/iW+LNPQvZO1xm8VpFdzAXHBR0vAWYTuQYrRMBB+0d7MKs/4yNzmZ WOs00rBrAA8NuR6jrT0tEjYV8sqA2A6hDTazgD44ZgMjmY+G44RwonX5ZS+YmUDuMg1zu6s5mmoU0 AIhQ1kXpYD15OG9kNN2rKdXzfxgtKrTm7pbldjSoRqeXNUMY67ywB0L62QRTnkpVWF5Y1OtdEsR3e 2E6+d2Yg==; Received: from [91.112.108.175] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1guekj-0005QK-2h; Fri, 15 Feb 2019 14:46:09 +0000 From: Christoph Hellwig To: "David S. Miller" , Helge Deller Cc: Robin Murphy , iommu@lists.linux-foundation.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/5] sparc64/iommu: allow large DMA masks Date: Fri, 15 Feb 2019 15:45:57 +0100 Message-Id: <20190215144559.8777-4-hch@lst.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190215144559.8777-1-hch@lst.de> References: <20190215144559.8777-1-hch@lst.de> MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We've been moving to a model where the device just sets the DMA mask supported by it, instead of having to fallback to something it thinks the platform might support. Sparc64 is the remaining holdout forcing drivers to supply a matching mask. Change dma_4u_supported to just check if the supplied dma mask is large enough as nothing in the iommu.c code (or the core DMA code) actually looks at the DMA mask later on. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/kernel/iommu.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c index 0c253f1c852e..4ae7388b1bff 100644 --- a/arch/sparc/kernel/iommu.c +++ b/arch/sparc/kernel/iommu.c @@ -748,11 +748,9 @@ static int dma_4u_supported(struct device *dev, u64 device_mask) if (ali_sound_dma_hack(dev, device_mask)) return 1; - if (device_mask > DMA_BIT_MASK(32)) + if (device_mask < iommu->dma_addr_mask) return 0; - if ((device_mask & iommu->dma_addr_mask) == iommu->dma_addr_mask) - return 1; - return 0; + return 1; } static const struct dma_map_ops sun4u_dma_ops = { From patchwork Fri Feb 15 14:45:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 10815041 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C961F6C2 for ; Fri, 15 Feb 2019 14:46:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BD9642F805 for ; Fri, 15 Feb 2019 14:46:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B23C82F808; Fri, 15 Feb 2019 14:46:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5883B2F805 for ; Fri, 15 Feb 2019 14:46:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437187AbfBOOqQ (ORCPT ); Fri, 15 Feb 2019 09:46:16 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34846 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2395160AbfBOOqO (ORCPT ); Fri, 15 Feb 2019 09:46:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gRpyvzKY+i69CNAl/QWLFd4mkChnvpbe5xjE7SRKcBY=; b=JDNmphlGuTSPii7tD4NkZHytDv QPcOdCRN1MKb8WoYIg8Ta9kDAxUhzxAOAUSejGdSTVBxZRNUGSICYrs7KGReI7rEE5BrwtkD4XpVu XHMuxr9SjNDQTD5CLiwnEm+Uo9fRs3f5t6JOyO9LMMFT3HqvEIyRo+etErN/MITdFLD0jXUnzr8nm aMWgufM4iyWgp7HLwlmeN4+NJUgaVrzjR4/jfuMjGSQnQc9h2N97qR5SDd1KShBz/avHaCQo0BWe+ ldmiecehiAxXpc4EUsd3w6cz6mThT9b1rlFF1nVjs5axjEUfLPp21cDZ0lEvMXxamphJWrbSx4d3c EOZYBA5Q==; Received: from [91.112.108.175] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1guekl-0005Qv-Co; Fri, 15 Feb 2019 14:46:11 +0000 From: Christoph Hellwig To: "David S. Miller" , Helge Deller Cc: Robin Murphy , iommu@lists.linux-foundation.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 4/5] sparc64/pci_sun4v: allow large DMA masks Date: Fri, 15 Feb 2019 15:45:58 +0100 Message-Id: <20190215144559.8777-5-hch@lst.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190215144559.8777-1-hch@lst.de> References: <20190215144559.8777-1-hch@lst.de> MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We've been moving to a model where the device just sets the DMA mask supported by it, instead of having to fallback to something it thinks the platform might support. Sparc64 is the remaining holdout forcing drivers to supply a matching mask. Change dma_4v_supported to just check if the supplied dma mask is large enough. and adjust the mapping code to check ATU presence in addition to the DMA mask to decice on the mapping method. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/kernel/pci_sun4v.c | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c index d30eb22b6e11..a8af6023c126 100644 --- a/arch/sparc/kernel/pci_sun4v.c +++ b/arch/sparc/kernel/pci_sun4v.c @@ -92,7 +92,7 @@ static long iommu_batch_flush(struct iommu_batch *p, u64 mask) prot &= (HV_PCI_MAP_ATTR_READ | HV_PCI_MAP_ATTR_WRITE); while (npages != 0) { - if (mask <= DMA_BIT_MASK(32)) { + if (mask <= DMA_BIT_MASK(32) || !pbm->iommu->atu) { num = pci_sun4v_iommu_map(devhandle, HV_PCI_TSBID(0, entry), npages, @@ -208,7 +208,7 @@ static void *dma_4v_alloc_coherent(struct device *dev, size_t size, atu = iommu->atu; mask = dev->coherent_dma_mask; - if (mask <= DMA_BIT_MASK(32)) + if (mask <= DMA_BIT_MASK(32) || !atu) tbl = &iommu->tbl; else tbl = &atu->tbl; @@ -674,21 +674,12 @@ static void dma_4v_unmap_sg(struct device *dev, struct scatterlist *sglist, static int dma_4v_supported(struct device *dev, u64 device_mask) { struct iommu *iommu = dev->archdata.iommu; - u64 dma_addr_mask = iommu->dma_addr_mask; if (ali_sound_dma_hack(dev, device_mask)) return 1; - - if (device_mask > DMA_BIT_MASK(32)) { - if (iommu->atu) - dma_addr_mask = iommu->atu->dma_addr_mask; - else - return 0; - } - - if ((device_mask & dma_addr_mask) == dma_addr_mask) - return 1; - return 0; + if (device_mask < iommu->dma_addr_mask) + return 0; + return 1; } static const struct dma_map_ops sun4v_dma_ops = { From patchwork Fri Feb 15 14:45:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 10815045 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 19162139A for ; Fri, 15 Feb 2019 14:46:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BB9C2F800 for ; Fri, 15 Feb 2019 14:46:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F30C72F807; Fri, 15 Feb 2019 14:46:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 468DF2F800 for ; Fri, 15 Feb 2019 14:46:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437218AbfBOOqX (ORCPT ); Fri, 15 Feb 2019 09:46:23 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:34856 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437188AbfBOOqQ (ORCPT ); Fri, 15 Feb 2019 09:46:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From :Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+YlLmaBhSlNdpcKAQUe3Q1Jrzw7Au6m3V09YNp1ULuQ=; b=CkxrCGVif27HxR0nAG3QCYsHp5 rPzA3hIdQlB+OSogwgUaTNOrA7JwJ4koRngoU2uHsevIDyg/0jTUsrvL9qZ8bqkhzLjohKDC4l2Id iyoLPcqJE1PHP8dkW5etNjpmMU9ZIpgiO3pyRVDhXrXzuycbjwI9KZGsXtrDn+t1lvH9yPO3nOZD1 fpyLd2imN5bCAVKAUj4LscjCi7Ijh/f/xTefdCGGIF6HUh/JwjYgRLj2+cqpPsXIkN7TCZ48gzUoy nfWyrUzvq6WgG/jFJ25a7Ou51xnX1EotFUMMm5Qvb6HbhdutN1EQurrS16w7gjrgWyDfNf+l39X0q vgiYG4pQ==; Received: from [91.112.108.175] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1guekn-0005R8-MB; Fri, 15 Feb 2019 14:46:14 +0000 From: Christoph Hellwig To: "David S. Miller" , Helge Deller Cc: Robin Murphy , iommu@lists.linux-foundation.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 5/5] Documentation/DMA-API-HOWTO: update dma_mask sections Date: Fri, 15 Feb 2019 15:45:59 +0100 Message-Id: <20190215144559.8777-6-hch@lst.de> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190215144559.8777-1-hch@lst.de> References: <20190215144559.8777-1-hch@lst.de> MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We don't require drivers to guess a DMA mask that might actually match the system capabilities any more, so fix up the documentation to clear this up. Signed-off-by: Christoph Hellwig --- Documentation/DMA-API-HOWTO.txt | 121 +++++++++++--------------------- 1 file changed, 41 insertions(+), 80 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index f0cc3f772265..8e948fae34af 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -146,114 +146,75 @@ What about block I/O and networking buffers? The block I/O and networking subsystems make sure that the buffers they use are valid for you to DMA from/to. -DMA addressing limitations +DMA addressing capabilities ========================== -Does your device have any DMA addressing limitations? For example, is -your device only capable of driving the low order 24-bits of address? -If so, you need to inform the kernel of this fact. +By default, the kernel assumes that your device can address 32-bits of DMA +addressing. For a 64-bit capable device, this needs to be increased, and for +a device with limitations, it needs to be decreased. -By default, the kernel assumes that your device can address the full -32-bits. For a 64-bit capable device, this needs to be increased. -And for a device with limitations, as discussed in the previous -paragraph, it needs to be decreased. +Special note about PCI: PCI-X specification requires PCI-X devices to support +64-bit addressing (DAC) for all transactions. And at least one platform (SGI +SN2) requires 64-bit consistent allocations to operate correctly when the IO +bus is in PCI-X mode. -Special note about PCI: PCI-X specification requires PCI-X devices to -support 64-bit addressing (DAC) for all transactions. And at least -one platform (SGI SN2) requires 64-bit consistent allocations to -operate correctly when the IO bus is in PCI-X mode. +For correct operation, you must set the DMA mask to inform the kernel about +your devices DMA addressing capabilities. -For correct operation, you must interrogate the kernel in your device -probe routine to see if the DMA controller on the machine can properly -support the DMA addressing limitation your device has. It is good -style to do this even if your device holds the default setting, -because this shows that you did think about these issues wrt. your -device. - -The query is performed via a call to dma_set_mask_and_coherent():: +This is performed via a call to dma_set_mask_and_coherent():: int dma_set_mask_and_coherent(struct device *dev, u64 mask); -which will query the mask for both streaming and coherent APIs together. -If you have some special requirements, then the following two separate -queries can be used instead: +which will set the mask for both streaming and coherent APIs together. If you +have some special requirements, then the following two separate calls can be +used instead: - The query for streaming mappings is performed via a call to + The setup for streaming mappings is performed via a call to dma_set_mask():: int dma_set_mask(struct device *dev, u64 mask); - The query for consistent allocations is performed via a call + The setup for consistent allocations is performed via a call to dma_set_coherent_mask():: int dma_set_coherent_mask(struct device *dev, u64 mask); -Here, dev is a pointer to the device struct of your device, and mask -is a bit mask describing which bits of an address your device -supports. It returns zero if your card can perform DMA properly on -the machine given the address mask you provided. In general, the -device struct of your device is embedded in the bus-specific device -struct of your device. For example, &pdev->dev is a pointer to the -device struct of a PCI device (pdev is a pointer to the PCI device -struct of your device). +Here, dev is a pointer to the device struct of your device, and mask is a bit +mask describing which bits of an address your device supports. Often the +device struct of your device is embedded in the bus-specific device struct of +your device. For example, &pdev->dev is a pointer to the device struct of a +PCI device (pdev is a pointer to the PCI device struct of your device). -If it returns non-zero, your device cannot perform DMA properly on -this platform, and attempting to do so will result in undefined -behavior. You must either use a different mask, or not use DMA. +These calls usually return zero to indicated your device can perform DMA +properly on the machine given the address mask you provided, but they might +return an error if the mask is too small to be supportable on the given +system. If it returns non-zero, your device cannot perform DMA properly on +this platform, and attempting to do so will result in undefined behavior. +You must not use DMA on this device unless the dma_set_mask family of +functions has returned success. -This means that in the failure case, you have three options: +This means that in the failure case, you have two options: -1) Use another DMA mask, if possible (see below). -2) Use some non-DMA mode for data transfer, if possible. -3) Ignore this device and do not initialize it. +1) Use some non-DMA mode for data transfer, if possible. +2) Ignore this device and do not initialize it. -It is recommended that your driver print a kernel KERN_WARNING message -when you end up performing either #2 or #3. In this manner, if a user -of your driver reports that performance is bad or that the device is not -even detected, you can ask them for the kernel messages to find out -exactly why. +It is recommended that your driver print a kernel KERN_WARNING message when +setting the DMA mask fails. In this manner, if a user of your driver reports +that performance is bad or that the device is not even detected, you can ask +them for the kernel messages to find out exactly why. -The standard 32-bit addressing device would do something like this:: +The standard 64-bit addressing device would do something like this:: - if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { + if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } -Another common scenario is a 64-bit capable device. The approach here -is to try for 64-bit addressing, but back down to a 32-bit mask that -should not fail. The kernel may fail the 64-bit mask not because the -platform is not capable of 64-bit addressing. Rather, it may fail in -this case simply because 32-bit addressing is done more efficiently -than 64-bit addressing. For example, Sparc64 PCI SAC addressing is -more efficient than DAC addressing. - -Here is how you would handle a 64-bit capable device which can drive -all 64-bits when accessing streaming DMA:: - - int using_dac; +If the device only supports 32-bit addressing for descriptors in the +coherent allocations, but supports full 64-bits fro streaming mappings +it would look like this: - if (!dma_set_mask(dev, DMA_BIT_MASK(64))) { - using_dac = 1; - } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) { - using_dac = 0; - } else { - dev_warn(dev, "mydev: No suitable DMA available\n"); - goto ignore_this_device; - } - -If a card is capable of using 64-bit consistent allocations as well, -the case would look like this:: - - int using_dac, consistent_using_dac; - - if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { - using_dac = 1; - consistent_using_dac = 1; - } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { - using_dac = 0; - consistent_using_dac = 0; - } else { + if (dma_set_mask(dev, DMA_BIT_MASK(64))) { dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; }