From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754648AbbKMOAR (ORCPT ); Fri, 13 Nov 2015 09:00:17 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:60044 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751881AbbKMOAP (ORCPT ); Fri, 13 Nov 2015 09:00:15 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Phil Edworthy , Lorenzo Pieralisi , Magnus , Will Deacon , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , Bjorn Helgaas , "Liviu.Dudau@arm.com" Subject: Re: PCIe host controller behind IOMMU on ARM Date: Fri, 13 Nov 2015 14:59:40 +0100 Message-ID: <4744053.Iz6Y8QJQYF@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <4169020.aC5VXkILQm@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:HuTRiUpNv8CjbvaRBbh0huP2x1gzetQFdJdNmHOK6xH34fXR3UA aV6asStqcL6T7qreB469U/dzxX9PuyHXdNSTDE+dHMKukmFfW48URZ+XK4PT8pcWvzWNOaf fulXlIOPogqgbf/saEXL8iURbiJHFsz6EGIuZSTalhWXq2GeSAv9yIGNwdkD+B304s+6Dke iBaCUD+fNY2RjDM0jjJBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0q0PUffA46s=:Do85TIoyQOVaWNHSs/HT8J GTFczsGUTEVRbcVpcs4f28GtwXol5YIxuch9wkg1Lh5z6rYBtdrsttVsE+jsexjVrE4eKH0YO 4aJvUwKR4Mz79Srh88ug50llrmGuVTkES4WoHCcYTImlZkYjOYUdd+5d7AOhHr4CqFXsUPk0i Pc30YsL50/57ZYcQ58pqfUx+/y8d3+6SMY4HfuJDhpss9mnHrv2vDTZSaoCYVVT5OZJb70g7F u3NTWd7rLmg55gnR7428b0191O+pU3M8W9lkY18xI8zS5isryFR4RwTWus518Km41s92ZSzWu WjzlsmebKZeInp1unp6nrc237halakcrOhtL8GO3ClUHg+cnVtW72m7ALTnDL1KtosdycqgQ2 7mkbzAFmeO8Bns8/hH3YusuGUU5aKNBeJabyerXKRlEsarxb/GiiG1HK64yfkHoe9uJNLbv/5 dvvobvofVzSqutP4Y89T8kFegIO0Pe9x31PD7g2UeSKSyiphL3kNWH8CXg/bv7n7srwVHJAk7 0RwJ3NSHLtwvU4XCYKsKiN4YRoPNqs9Tjs34kBmP1YACdQpU41frFhfnIHTDFnX1FVdiYo4u6 WJfnuS65DCAvEewISqlNpcyZMq5dCgmHzmKfjNPR6kGghC3+ciqnQz6lrVxX/tVIMM4diGe5b WjY5U+ztmDzq3EztNOteiHp6gHXic+3Q1BGGZNLYaQ313NkoxTsfNTa1rnr9iDAZ8BNn4YnCk zuWlu54939zNWJkc Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 13 November 2015 13:03:11 Phil Edworthy wrote: > > > > Then pci_device_add() sets the devices coherent_dma_mask to 4GiB before > > > calling of_pci_dma_configure(). I assume it does this on the basis that this is a > > > good default for PCI drivers that don't call dma_set_mask(). > > > So if arch_setup_dma_ops() walks up the parents to limit the mask, you'll hit > > > this mask. > > > > arch_setup_dma_ops() does not walk up the hierarchy, of_dma_configure() > > does this before calling arch_setup_dma_ops(). The PCI devices start out > > with the 32-bit mask, but the limit should be whatever PCI host uses. > Ok, so of_dma_configure() could walk up the tree and restrict the dma > mask to whatever parents limit it to. Then it could be overridden by > a dma-ranges entry in the DT node, right? No, the dma-ranges properties tell you what the allowed masks are, this is what of_dma_configure() looks at. > If so, one problem I can see is PCI controllers already use the > dma-ranges binding but with 3 address cells since it also specifies > the PCI address range. > > I noticed that of_dma_get_range() skips straight to the parent node. > Shouldn't it attempt to get the dma-ranges for the device's node > first? No, the dma-ranges explain the capabilities of the bus, this is what you have to look at. The device itself may have additional restrictions, but those are what the driver knows based on the compatibility value when it passes the device specific mask into dma_set_mask() > I mean most hardware is limited by the peripheral's > capabilities, not the bus. If fact, of_dma_get_range() gets the number > of address and size cells from the device node, but gets the dma-ranges > from the parent. That seems a little odd to me. of_dma_get_range() calls of_n_addr_cells()/of_n_size_cells(), which get the #address-cells/#size-cells property from the parent device (except for the root, which is special). > The only other problem I can see is that currently all PCI drivers can > try to set their dma mask to 64 bits. At the moment that succeeds > because there are no checks. Right, this is the main bug we need to fix. > Until devices using them have their DTs > updated with dma-ranges, we would be limiting them to a 32 bit mask. I > guess that's not much of an issue in practice. Correct. I've tried to tell everyone about this when they added device nodes for DMA capable devices. In most cases, they want 32-bit masks anyway. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 13 Nov 2015 14:59:40 +0100 Subject: PCIe host controller behind IOMMU on ARM In-Reply-To: References: <4169020.aC5VXkILQm@wuerfel> Message-ID: <4744053.Iz6Y8QJQYF@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Friday 13 November 2015 13:03:11 Phil Edworthy wrote: > > > > Then pci_device_add() sets the devices coherent_dma_mask to 4GiB before > > > calling of_pci_dma_configure(). I assume it does this on the basis that this is a > > > good default for PCI drivers that don't call dma_set_mask(). > > > So if arch_setup_dma_ops() walks up the parents to limit the mask, you'll hit > > > this mask. > > > > arch_setup_dma_ops() does not walk up the hierarchy, of_dma_configure() > > does this before calling arch_setup_dma_ops(). The PCI devices start out > > with the 32-bit mask, but the limit should be whatever PCI host uses. > Ok, so of_dma_configure() could walk up the tree and restrict the dma > mask to whatever parents limit it to. Then it could be overridden by > a dma-ranges entry in the DT node, right? No, the dma-ranges properties tell you what the allowed masks are, this is what of_dma_configure() looks at. > If so, one problem I can see is PCI controllers already use the > dma-ranges binding but with 3 address cells since it also specifies > the PCI address range. > > I noticed that of_dma_get_range() skips straight to the parent node. > Shouldn't it attempt to get the dma-ranges for the device's node > first? No, the dma-ranges explain the capabilities of the bus, this is what you have to look at. The device itself may have additional restrictions, but those are what the driver knows based on the compatibility value when it passes the device specific mask into dma_set_mask() > I mean most hardware is limited by the peripheral's > capabilities, not the bus. If fact, of_dma_get_range() gets the number > of address and size cells from the device node, but gets the dma-ranges > from the parent. That seems a little odd to me. of_dma_get_range() calls of_n_addr_cells()/of_n_size_cells(), which get the #address-cells/#size-cells property from the parent device (except for the root, which is special). > The only other problem I can see is that currently all PCI drivers can > try to set their dma mask to 64 bits. At the moment that succeeds > because there are no checks. Right, this is the main bug we need to fix. > Until devices using them have their DTs > updated with dma-ranges, we would be limiting them to a 32 bit mask. I > guess that's not much of an issue in practice. Correct. I've tried to tell everyone about this when they added device nodes for DMA capable devices. In most cases, they want 32-bit masks anyway. Arnd