From patchwork Wed May 24 18:01:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jean-Philippe Brucker X-Patchwork-Id: 9746673 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2A80B60209 for ; Wed, 24 May 2017 17:58:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1FBA3289A1 for ; Wed, 24 May 2017 17:58:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 141CD289C5; Wed, 24 May 2017 17:58:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AE9A0289A1 for ; Wed, 24 May 2017 17:58:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932641AbdEXR62 (ORCPT ); Wed, 24 May 2017 13:58:28 -0400 Received: from foss.arm.com ([217.140.101.70]:41974 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754409AbdEXR60 (ORCPT ); Wed, 24 May 2017 13:58:26 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D12F7165C; Wed, 24 May 2017 10:58:25 -0700 (PDT) Received: from e106794-lin.cambridge.arm.com (e106794-lin.cambridge.arm.com [10.1.210.58]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id A7C533F41F; Wed, 24 May 2017 10:58:22 -0700 (PDT) From: Jean-Philippe Brucker To: linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org Cc: bhelgaas@google.com, robh+dt@kernel.org, mark.rutland@arm.com, lorenzo.pieralisi@arm.com, hanjun.guo@linaro.org, sudeep.holla@arm.com, rjw@rjwysocki.net, lenb@kernel.org, will.deacon@arm.com, robin.murphy@arm.com, joro@8bytes.org, okaya@codeaurora.org, sunil.kovvuri@gmail.com, thunder.leizhen@huawei.com, tn@semihalf.com Subject: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes Date: Wed, 24 May 2017 19:01:38 +0100 Message-Id: <20170524180143.19855-3-jean-philippe.brucker@arm.com> X-Mailer: git-send-email 2.12.1 In-Reply-To: <20170524180143.19855-1-jean-philippe.brucker@arm.com> References: <20170524180143.19855-1-jean-philippe.brucker@arm.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Address Translation Service (ATS) is an extension to PCIe allowing endpoints to manage their own IOTLB, called Address Translation Cache (ATC). Instead of having every memory transaction processed by the IOMMU, the endpoint can first send an Address Translation Requests for an IOVA, obtain the corresponding Physical Address from the IOMMU and store it in its ATC. Subsequent transactions to this memory region can be performed on the PA, in which case they are marked 'translated' and (partially) bypass the IOMMU. Since the extension uses fields that were previously reserved in the PCIe Translation Layer Packet, it seems ill-advised to enabled it on a system that doesn't fully support ATS. To "old" root complexes that simply ignored the new AT field, an Address Translation Request will look exactly like a Memory Read Request, so the root bridge will forward a memory read to the IOMMU instead of a translation request. If the access succeeds, the RC will send a Read Completion, which looks like a Translation Completion, back to the endpoint. As a result the endpoint might end up storing the content of memory instead of a physical address in its ATC. In reality, it's more likely that the size fields will be invalid and either end will detect the error, but in any case, it is undesirable. Add a way for firmware to tell the OS that ATS is supported by the PCI root complex. Signed-off-by: Jean-Philippe Brucker --- Documentation/devicetree/bindings/pci/pci-iommu.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt index 0def586fdcdf..f21a68ec471a 100644 --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt @@ -44,6 +44,14 @@ Optional properties - iommu-map-mask: A mask to be applied to each Requester ID prior to being mapped to an IOMMU specifier per the iommu-map property. +- ats-supported: if present, the root complex supports the Address + Translation Service (ATS). It is able to interpret the AT field in PCIe + Transaction Layer Packets, and forward Translation Completions or + Invalidation Requests to endpoints. + + Device drivers should not enable ATS in endpoints unless this property + is present. + Example (1) ===========