Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752118AbbKJT5g (ORCPT ); Tue, 10 Nov 2015 14:57:36 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:49393 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751807AbbKJT5f (ORCPT ); Tue, 10 Nov 2015 14:57:35 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Sinan Kaya , Abhijit Mahajan , linux-scsi@vger.kernel.org, Nagalakshmi Nandigama , jcm@redhat.com, timur@codeaurora.org, "James E.J. Bottomley" , linux-kernel@vger.kernel.org, Sreekanth Reddy , Hannes Reinecke , Praveen Krishnamoorthy , cov@codeaurora.org, linux-arm-msm@vger.kernel.org, MPT-FusionLinux.pdl@avagotech.com, agross@codeaurora.org Subject: Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Date: Tue, 10 Nov 2015 20:56:47 +0100 Message-ID: <3742888.Lmg2Y11mdz@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56422725.7040809@codeaurora.org> References: <1447034266-28003-1-git-send-email-okaya@codeaurora.org> <4982446.ZlJVrezq1Y@wuerfel> <56422725.7040809@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:FPYy/ZVXsB6PPGJ7+RNFW2pDOW4x7jn2KuVud3QeSSDv4oQdDG6 4P+IwO3zU2RO37Z4svxyH36xwwEUk4vOij1FA/HyE1xFRFttV+9BWS3hZA2AMY/STBXt7Uf 8wZAV7pJ6SDwf4jovYFojMOvBGg4UQDSgNowPQ4/Zt2w4d7AhP7hlPoLsjYEkxB/B+/BRNq DOvxT+ytXkqTdKPXsGDFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:WKq1hbCttxk=:evI/wlIFYXeAB8F8eiCsUr k4hZYFmUNWveFbgO/raOFQVkHMUbf4vsg0VfR1ebcJA1NjKW2VeIZ3lAcGnBWyx+fkFz8HKJO EALJVyNBGp3giknW7BJwcN7jGjNmbmxnQ4xlbjLTDvQgutxKv9DPm0Bj1GEFKa2YU8+T4JCUb xyyF2DbYIF9Z8Zf+hOhnWX8roIyBUOo5XMLwUftQaTOwvvyFqBKVPF6kO2i1NOUY4+z9U3zyQ vx431h849ibEttHY6iuuw0tzPGwyD1lfRFx2AlkPlbUV3R3YG3xjfekxJOTEXG3nRNv1rhhp2 eczwtACIAmiLBuPlvfq3s8yVNdCTy5yO5grnQdVTIcLHYhnoBh101DfL9ayw+IR4/lLgzLaPR sviDZszw4kAeCZIh1rKr83EK2tMY7NKGQBLxHlXxoOGAoeMzaYr66Mxl9m53q19LrzDQy1ZH9 qdn49RW3pRuCVp808VVLWsK4m4UWek5/o3CfWheqai3IYDlbRRUPW+a89ifHIreHtShthsM6b X4ZUYWZ06BSLo3TSxAA/3ic1ZY6xXRef7R207NjA8wtpwlc/tX+ZJVShm6UhV8EDxFvDeuoMQ Jvb7EdTyJYxSdoHDqDu1Xkqg4VKS9W9P2z/qmFuppeslSO+Ghc6QuAqTRQOJFOnHistr+gVUk sbWUnkjR0/HqP/cs/G02WnI187uqFJ1mcKoRsdPCgdojwEUCVWEXdTSmeh4C7YCa5ANbOtlCh jjZa23LUbV+crOhZ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1896 Lines: 37 On Tuesday 10 November 2015 12:19:33 Sinan Kaya wrote: > On 11/10/2015 11:47 AM, Arnd Bergmann wrote: > > 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. > > > > The ACPI IORT table declares whether you enable IOMMU for a particular > device or not. The placement of IOMMU HW is system specific. The IORT > table gives the IOMMU HW topology to the operating system. This sounds odd. Clearly you need to specify the IOMMU settings for each possible PCI device independent of whether the OS actually uses the IOMMU or not. In a lot of cases, we want to turn it off to get better performance when the driver has set a DMA mask that covers all of RAM, but you also want to enable the IOMMU for debugging purposes or for device assignment if you run virtual machines. The bootloader doesn't know how the device is going to be used, so it cannot define the policy here. 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/