Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754219AbbKJQso (ORCPT ); Tue, 10 Nov 2015 11:48:44 -0500 Received: from mout.kundenserver.de ([212.227.126.187]:55578 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753385AbbKJQsm (ORCPT ); Tue, 10 Nov 2015 11:48:42 -0500 From: Arnd Bergmann To: Sinan Kaya Cc: linux-arm-kernel@lists.infradead.org, Abhijit Mahajan , Nagalakshmi Nandigama , linux-scsi@vger.kernel.org, jcm@redhat.com, timur@codeaurora.org, "James E.J. Bottomley" , linux-kernel@vger.kernel.org, Sreekanth Reddy , Praveen Krishnamoorthy , cov@codeaurora.org, linux-arm-msm@vger.kernel.org, agross@codeaurora.org, MPT-FusionLinux.pdl@avagotech.com, Hannes Reinecke Subject: Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Date: Tue, 10 Nov 2015 17:47:51 +0100 Message-ID: <4982446.ZlJVrezq1Y@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56421610.50005@codeaurora.org> References: <1447034266-28003-1-git-send-email-okaya@codeaurora.org> <5349261.sTnZTFhKWB@wuerfel> <56421610.50005@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:hN3vj8OiIGgr7y8beKaykV+M7zFvgreioROZfcClgiUuL6a4Fxt H96bhbbt8dfgdzxd1VXnD7nmDDbdrm4WFHLdG4XChKFW0WN5QE2F95T0cHAz4rGJAQE+YTz RFyUJRnXugnRt7QcAnlhehhs2guc+siUULwd6/jQn4sICECY44ir9fWEDgo1hulaQxdWG7e L7hHrM4BWzdpMBRhFYTiw== X-UI-Out-Filterresults: notjunk:1;V01:K0:R6WxcSTj6ME=:qBJreDOJabmUKVwDxJYgbj P4uoEhA3GdjVmfEaMW4sBLl6SWcfiFSZzhyh3fm57Y6Gb7eTqWEnirsiOY0XMa6hNpzBd6pAU 2kdgfv8j1MVMmOam1Nxz9cepBGCRmrEXXHGUEHXH6PT//d9AgbE3Tf2TOqiqiBxdKjRxM5cdv yK2/DbpXFzbwgMqifGdbrXPQcqLxCRUgwoR+vdmpq6tTAWot3mqdoJdxZHUHPUQk4k5k+a262 QGOkl4+sKA10kXkp/pbVYR/vCe/6HmiRei+r1CmUI0b+4flsOnkizwI6yFB1hl9hd+NqBa4qE pKuH0Z7h1+hH92VXrCaYSrz+YAA6cjhsTXICc7PVBOgU8/vnoptMe9jiBPOta1ReMSYnDRxyM qmqy4/t4Tmt5n9U2aSShyV2UhTDycZksQIXS/eYB06GKtTqneXb4rCwNTc7K25ClUSMZlq6og FeGkwk/a9518i/bYLRZsKAn8K8cTq9gQxMxdELeZfPCAId8qBG1TvcvEoqNZUj1qxJ+XO12dQ aI9o0cLie5mv9Xy+zeE1JE4DXmV3hLdiUcR+29AL0XYbyy58D76N+ZCUSv2tzIPkZ/dZ6Z28c waTgVTYmItYksgNodtweWsqbVVL3aatXz9Lul20mMF9vLxQfrxEtqBcm5eCPlKnV0x9jMyAVC c0YEP7w3fcsCRmLHCYPwH7s+FkwsQ+EHm3mwvXBbLWU0AuCmQCvvIz8No70AMM98nf6vDLWQa tz72RyoviQL/HMpu Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2568 Lines: 56 On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > > No, as Timur found, the driver is correct and it intentionally > > sets the 32-bit mask, and that is guaranteed to work on all sane > > hardware. Don't change the driver but find a better platform for > > your workload, or talk to the people that are responsible for > > the platform and get them to fix it. > > Platform does have an IOMMU. No issues there. I am trying to clean out > the patch pipe I have in order to get this card working with and without > IOMMU. On PowerPC, I think we automatically enable the IOMMU whenever a DMA mask is set that doesn't cover all of the RAM. We could think about doing the same thing on ARM64 to make all devices work out of the box. > > If the platform also doesn't have an IOMMU, you can probably work > > around it by setting up the dma-ranges property of the PCI host > > to map the low PCI addresses to the start of RAM. This will also > > require changes in the bootloader to set up the PCI outbound translation, > > and it will require implementing the DMA offset on ARM64, which I was > > hoping to avoid. > > From the email thread, it looks like this was introduced to support > some legacy card that has 64 bit addressing limitations and is being > carried around ("rotted") since then. > > I'm the second guy after the powerpc architecture complaining about the > very same issue. Any red flags? What BenH was worried about here is that the driver sets different masks for streaming and coherent mappings, which is indeed a worry that could hit us on ARM as well, but I suppose we'll have to deal with that in platform code. Setting both masks to 32-bit is something that a lot of drivers do, and without IOMMU enabled, you'd hit the same bug on all of them. > I can't change the address map for PCIe. SBSA requires all inbound PCIe > addresses to be non-translated. What about changing the memory map? I suspect there will be more problems for you in the future when all of your RAM is at high addresses. Is this something you could fix in the bootloader by moving the first 2GB to a different CPU physical address? > I'll just have to stick with IOMMU for this card. Ok. But how do you currently decide whether to use the IOMMU or not? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/