From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85727C433DF for ; Fri, 22 May 2020 14:08:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 58E6622227 for ; Fri, 22 May 2020 14:08:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590156530; bh=9ttEKhP9nDiAvnPqT2NbUpZ5A85BLKTda+04YGkS/Jc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=N9nqiHqCfmiDwKJrRlyemChSAz7cL4Tc6m9kNXv0ojJiXd8lADHbddMpTtCyhvxI2 5rqfFhxsiC2S7vgWNx6akt5FYlIR10Fe+iSglRbr9jlr1Q6nPP0gYiKLqZZvHbT9No rr/JIIdSdqHGlZ874MF1pjgOWedUu91I81iumqsQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729700AbgEVOIt (ORCPT ); Fri, 22 May 2020 10:08:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:38466 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729399AbgEVOIt (ORCPT ); Fri, 22 May 2020 10:08:49 -0400 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B4B62221F0; Fri, 22 May 2020 14:08:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590156528; bh=9ttEKhP9nDiAvnPqT2NbUpZ5A85BLKTda+04YGkS/Jc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=T2Xyqu7RlLiGBaCDD17OBLgGFUconLgjUep1CkxaxuB56HWep4NJb4MnEUKbTJIQ/ BPsiP4uyGXiJCNa4XV3/qJeym+K49EOY/CQRq66xChHwJq+W43g+ybH/t+8d2XG6f7 7IYLQaIq15BXntiJmBfIChnqjuJ6478npY1kpw0A= Received: by mail-oi1-f172.google.com with SMTP id b3so9338991oib.13; Fri, 22 May 2020 07:08:48 -0700 (PDT) X-Gm-Message-State: AOAM530uA6ql+kxFtZhv+7pk1R35lkGpW/ckI4x0pm/rYAFA4e+q3HcL XXTLdLOZ5CRRBsFNiZRwClPR2TE6zBhO+vL+iQ== X-Google-Smtp-Source: ABdhPJxbEp1ZalT7LjeGB8CX9V1N0S0pLASvdZoVw8NWjkZUBBbTq4XnQYOc4bY4bi78FkEmC75vv9c1Cjc7aIFvTrE= X-Received: by 2002:aca:f084:: with SMTP id o126mr2821207oih.106.1590156527984; Fri, 22 May 2020 07:08:47 -0700 (PDT) MIME-Version: 1.0 References: <20200521130008.8266-1-lorenzo.pieralisi@arm.com> <20200521130008.8266-10-lorenzo.pieralisi@arm.com> In-Reply-To: From: Rob Herring Date: Fri, 22 May 2020 08:08:36 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus To: Diana Craciun OSS Cc: Robin Murphy , Lorenzo Pieralisi , devicetree@vger.kernel.org, Catalin Marinas , Will Deacon , PCI , Sudeep Holla , "Rafael J. Wysocki" , Makarand Pawagi , linux-acpi@vger.kernel.org, Linux IOMMU , Marc Zyngier , Hanjun Guo , Bjorn Helgaas , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, May 22, 2020 at 3:57 AM Diana Craciun OSS wrote: > > On 5/22/2020 12:42 PM, Robin Murphy wrote: > > On 2020-05-22 00:10, Rob Herring wrote: > >> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi > >> wrote: > >>> > >>> From: Laurentiu Tudor > >>> > >>> The existing bindings cannot be used to specify the relationship > >>> between fsl-mc devices and GIC ITSes. > >>> > >>> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using > >>> msi-map property. > >>> > >>> Signed-off-by: Laurentiu Tudor > >>> Cc: Rob Herring > >>> --- > >>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 > >>> +++++++++++++++++-- > >>> 1 file changed, 27 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > >>> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > >>> index 9134e9bcca56..b0813b2d0493 100644 > >>> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > >>> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt > >>> @@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit > >>> value called an ICID > >>> the requester. > >>> > >>> The generic 'iommus' property is insufficient to describe the > >>> relationship > >>> -between ICIDs and IOMMUs, so an iommu-map property is used to define > >>> -the set of possible ICIDs under a root DPRC and how they map to > >>> -an IOMMU. > >>> +between ICIDs and IOMMUs, so the iommu-map and msi-map properties > >>> are used > >>> +to define the set of possible ICIDs under a root DPRC and how they > >>> map to > >>> +an IOMMU and a GIC ITS respectively. > >>> > >>> For generic IOMMU bindings, see > >>> Documentation/devicetree/bindings/iommu/iommu.txt. > >>> @@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt. > >>> For arm-smmu binding, see: > >>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml. > >>> > >>> +For GICv3 and GIC ITS bindings, see: > >>> +Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. > >>> > >>> + > >>> Required properties: > >>> > >>> - compatible > >>> @@ -119,6 +122,15 @@ Optional properties: > >>> associated with the listed IOMMU, with the iommu-specifier > >>> (i - icid-base + iommu-base). > >>> > >>> +- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier > >>> + data. > >>> + > >>> + The property is an arbitrary number of tuples of > >>> + (icid-base,iommu,iommu-base,length). > >> > >> I'm confused because the example has GIC ITS phandle, not an IOMMU. > >> > >> What is an iommu-base? > > > > Right, I was already halfway through writing a reply to say that all > > the copy-pasted "iommu" references here should be using the > > terminology from the pci-msi.txt binding instead. > > Right, will change it. > > > > >>> + > >>> + Any ICID in the interval [icid-base, icid-base + length) is > >>> + associated with the listed GIC ITS, with the iommu-specifier > >>> + (i - icid-base + iommu-base). > >>> Example: > >>> > >>> smmu: iommu@5000000 { > >>> @@ -128,6 +140,16 @@ Example: > >>> ... > >>> }; > >>> > >>> + gic: interrupt-controller@6000000 { > >>> + compatible = "arm,gic-v3"; > >>> + ... > >>> + its: gic-its@6020000 { > >>> + compatible = "arm,gic-v3-its"; > >>> + msi-controller; > >>> + ... > >>> + }; > >>> + }; > >>> + > >>> fsl_mc: fsl-mc@80c000000 { > >>> compatible = "fsl,qoriq-mc"; > >>> reg = <0x00000008 0x0c000000 0 0x40>, /* MC > >>> portal base */ > >>> @@ -135,6 +157,8 @@ Example: > >>> msi-parent = <&its>; > > > > Side note: is it right to keep msi-parent here? It rather implies that > > the MC itself has a 'native' Device ID rather than an ICID, which I > > believe is not strictly true. Plus it's extra-confusing that it > > doesn't specify an ID either way, since that makes it look like the > > legacy PCI case that gets treated implicitly as an identity msi-map, > > which makes no sense at all to combine with an actual msi-map. > > Before adding msi-map, the fsl-mc code assumed that ICID and streamID > are equal and used msi-parent just to get the reference to the ITS node. > Removing msi-parent will break the backward compatibility of the already > existing systems. Maybe we should mention that this is legacy and not to > be used for newer device trees. If ids are 1:1, then the DT should use msi-parent. If there is remapping, then use msi-map. A given system should use one or the other. I suppose if some ids are 1:1 and the msi-map was added to add additional support for ids not 1:1, then you could end up with both. That's fine in dts files, but examples should reflect the 'right' way. Rob