From patchwork Tue Dec 23 17:42:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Murali Karicheri X-Patchwork-Id: 5534631 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 3B1A9BEEA8 for ; Tue, 23 Dec 2014 17:45:20 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4868D20121 for ; Tue, 23 Dec 2014 17:45:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3438E20120 for ; Tue, 23 Dec 2014 17:45:18 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y3TTp-00038S-CT; Tue, 23 Dec 2014 17:42:45 +0000 Received: from arroyo.ext.ti.com ([192.94.94.40]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y3TTk-00035D-M7 for linux-arm-kernel@lists.infradead.org; Tue, 23 Dec 2014 17:42:41 +0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id sBNHg6Jw015000; Tue, 23 Dec 2014 11:42:06 -0600 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id sBNHg5rj021467; Tue, 23 Dec 2014 11:42:05 -0600 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.3.174.1; Tue, 23 Dec 2014 11:42:05 -0600 Received: from [158.218.104.161] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id sBNHg43J017224; Tue, 23 Dec 2014 11:42:04 -0600 Message-ID: <5499A96D.4010704@ti.com> Date: Tue, 23 Dec 2014 12:42:05 -0500 From: Murali Karicheri User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Arnd Bergmann Subject: Re: [RFC v1 PATCH 1/2] of/pci: add of_pci_dma_configure() update dma configuration References: <1418940425-2017-1-git-send-email-m-karicheri2@ti.com> <54989DDE.3060409@ti.com> <1723662.JYr5muIJha@wuerfel> <5090769.jqAkiDgYu7@wuerfel> In-Reply-To: <5090769.jqAkiDgYu7@wuerfel> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141223_094240_825183_0D8663D8 X-CRM114-Status: GOOD ( 23.77 ) X-Spam-Score: -5.0 (-----) Cc: devicetree@vger.kernel.org, linux-pci@vger.kernel.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, grant.likely@linaro.org, robh+dt@kernel.org, bhelgaas@google.com, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 12/22/2014 06:07 PM, Arnd Bergmann wrote: > On Monday 22 December 2014 23:44:52 Arnd Bergmann wrote: >> On Monday 22 December 2014 17:40:30 Murali Karicheri wrote: >>> On 12/22/2014 05:24 PM, Arnd Bergmann wrote: >>>> On Monday 22 December 2014 16:40:43 Murali Karicheri wrote: >>>>>>> +++ b/arch/arm/mm/dma-mapping.c >>>>>>> @@ -2052,9 +2052,10 @@ void arch_setup_dma_ops(struct device *dev, u64 >>>>>>> dma_base, u64 size, >>>>>>> struct iommu_ops *iommu, bool coherent) >>>>>>> { >>>>>>> struct dma_map_ops *dma_ops; >>>>>>> + u64 temp_size = min((*(dev->dma_mask) + 1), size); >>>>>>> >>>>>>> dev->archdata.dma_coherent = coherent; >>>>>>> - if (arm_setup_iommu_dma_ops(dev, dma_base, size, iommu)) >>>>>>> + if (arm_setup_iommu_dma_ops(dev, dma_base, temp_size, iommu)) >>>>>>> >>>>>>> If you agree, I will post v1 of the patch with these updates. Let me >>>>>>> know. I did some basic tests on Keystone with these changes and it works >>>>>>> fine. >>>>>> >>>>>> It's not exactly what I meant. My main point was that we need to limit >>>>>> dev->dma_mask to (size-1) here, but you are not touching that. >>>>> >>>>> if you mean overriding the dev->dma_mask to min((*dev->dma_mask), >>>>> size-1), then I am getting the error "Coherent DMA mask 0x7fffffff (pfn >>>>> 0x780000-0x800000) covers a smaller range of system memory than the DMA >>>>> zone pfn 0x0-0x880000) when the devices on Keystone tries to set the dma >>>>> mask. Something wrong and I need to look into the code. >>>> >>>> Right, it sounds like the offset was applied incorrectly at some point. >>>> >>>> What are the DMA zone size and the phys-offset? >>> 2G and 0x8_0000_0000. This limit the usable DMA size to 2G on Keystone, >>> I believe you shouldn't be limiting the dma mask to size-1 in this case, >>> right? The DT setup the dma-range to have a size of 2G (0x80000000). >> >> No, the problem is something else: the pfn range that we calculate for the >> coherent DMA mask should have been 0x800000-0x880000, not 0x780000-0x800000, >> so we would exactly match the ZONE_DMA. > > I gave it some more thought, and concluded that the size that gets passed > down is not really the right value to be compared to a mask if the dma-capable > area starts at a nonzero bus address. > > In your case, bus addresses 0x80000000-0xffffffff are valid for DMA, so > the mask must be 0xffffffff to forbid any DMA to addresses larger than > 0x100000000, not 0x7fffffff which would not be enough to cover any RAM. > > I guess the dma_mask should be 'min((*dev->dma_mask), dma_base + size - 1)' > here. Arnd, I guess so. Besides we need to keep the default coherent dma mask to 32bit 0xffffffffull as well to work on Keystone and also in sync with current defaults used in pci_device_add() so that we don't break this behavior. Here is the summary of changes need to make on top of my existing patch. 1. of_dma_configure() - change size = dev->coherent_dma_mask to size = dev->coherent_dma_mask + 1. This is a new patch to fix existing code. 2. Do the above change to of_pci_dma_configure() as well. 3. in arch_setup_dma_ops() update the DMA mask to min((*dev->dma_mask), dma_base + size - 1) as Murali > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index c17f6a9..88b4769 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -2053,8 +2053,13 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, { struct dma_map_ops *dma_ops; + + *dev->dma_mask = min((*dev->dma_mask), (dma_base + size - 1)); I have tested this on keystone and it works fine with rootfs on PCI SATA harddisk. I will be doing more tests with this change. If you are in agreement with the above changes, I will re-spin the patch to accomodate them and send v1 of the same. Regards,