From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765530AbdAKQWc (ORCPT ); Wed, 11 Jan 2017 11:22:32 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:55777 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764200AbdAKQWb (ORCPT ); Wed, 11 Jan 2017 11:22:31 -0500 From: Arnd Bergmann To: Nikita Yushchenko Cc: Robin Murphy , Will Deacon , linux-arm-kernel@lists.infradead.org, Catalin Marinas , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Simon Horman , Bjorn Helgaas , artemi.ivanov@cogentembedded.com, fkan@apm.com, Christoph Hellwig Subject: Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle Date: Wed, 11 Jan 2017 17:21:49 +0100 Message-ID: <3179509.2spa1K0WKy@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <7c6a1523-e41b-ad83-501a-27c260b9f9ee@cogentembedded.com> References: <1483947002-16410-1-git-send-email-nikita.yoush@cogentembedded.com> <5c5cd4fd-4854-a2dd-10b6-9cc98e63a85c@arm.com> <7c6a1523-e41b-ad83-501a-27c260b9f9ee@cogentembedded.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:eZAMXF4wBu5/jY3XEl8NYnP3fTIp4USujR2He5CadnUOvA7Yr3j qObnI9KrniF49eCVHr/w4unkumKvrwSreT38jVBH7S/fEsFMk9pQQhG32jc4o7FeRSUcLdc IkdXRypxF5CR6ejxTt34EaAIDrvDPBzvGkjfHdkw/xVKCtjtZ5P4Daoir7c88JR1qTwW5FB E6VlyFu19b90lWuMHn1KQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:XKvwCVVhBEI=:oFuKJ4+GiSZuk5SkVjsZlm ue9NQIuRJZq8EXAkBHVTZ/LBDR4pXHL563VsnvrmNu0ogBGOPr8SRpsYloPB2UoVPwqielpxN M0G37nbek/z8UQ5AvQ0qaDV+LWt6nY40wGoxadfd/axhSIy8oq4Czt3JsOWEjss36KGil25Do 4m0Zy1KHTD4NZkazd9W/3W/ZjyFNO0pbSGGNEocfWhC4wHbYegqNl/iBbBfZD5kVQd+eknX06 4U/HbRSan2cRXuyEFlwY1fF3PhhvuHZt+zMl1RsiFI10CxR0QwMBDR3Dr0sr7L8yUoMIm7nv2 C6BNJjanKxGwFIkXVsSDvSyL+PZGaqs50MLgp4HeQBVgYuEdXGcM8xgZRPYu4Jkh1Z3BBgO1c Py4NryFxtTi1xLltEDUG2L5y+IAiJcMzOJRxT26giNB/7CN+WqPbcPo2Du0134OrOZv3LdMTi 4pg/dg6gA9tS8Z9UBwVkA3gr5eDhuC26bRO/2GslehpM6JYRC34CcR3gIaQaA5XsvsfRrsl6G ZA/vtd/zdg4rS9CBo0Szlm+T0aEFR3n/s5eOXh11W+i8hrbikgYVoEnumqiAnLcbt/JNTr/gD uhDblHmZwxXKJWz8iBmwi4lG7eq/qtkgCa4S6PPh1++WNVY6h35d4Y7VZDFj5IQg/oRb8wzOD 1OsyEqSFlh9/Y4zCW52/N7tYg1zPoputoROdxgMiBQm8q46kaFxlRoXEtWb7NsegbnBFVCika 9Gq7ok8g4pcS1+Lw Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, January 11, 2017 3:37:22 PM CET Nikita Yushchenko wrote: > > I actually have a third variation of this problem involving a PCI root > > complex which *could* drive full-width (40-bit) addresses, but won't, > > due to the way its PCI<->AXI interface is programmed. That would require > > even more complicated dma-ranges handling to describe the windows of > > valid physical addresses which it *will* pass, so I'm not pressing the > > issue - let's just get the basic DMA mask case fixed first. > > R-Car + NVMe is actually not "basic case". > > It has PCI<->AXI interface involved. > PCI addresses are 64-bit and controller does handle 64-bit addresses > there. Mapping between PCI addresses and AXI addresses is defined. But > AXI is 32-bit. > > SoC has iommu that probably could be used between PCIe module and RAM. > Although AFAIK nobody made that working yet. > > Board I work with has 4G of RAM, in 4 banks, located at different parts > of wide address space, and only one of them is below 4G. But if iommu is > capable of translating addresses such that 4 gigabyte banks map to first > 4 gigabytes of address space, then all memory will become available for > DMA from PCIe device. You can in theory handle this by defining your own platform specific dma_map_ops, as we used to do in the old days. Unfortunately, the modern way of using the generic IOVA allocation can't handle really it, so it's unclear if the work that would be necessary to support it (and the long term maintenance cost) outweigh the benefits. The more likely option here is to try harder to get the IOMMU working (or show that it's impossible but make sure the next chip gets it right). Arnd