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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 927A5C433F5 for ; Fri, 10 Dec 2021 11:35:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240585AbhLJLiw (ORCPT ); Fri, 10 Dec 2021 06:38:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237724AbhLJLiv (ORCPT ); Fri, 10 Dec 2021 06:38:51 -0500 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 929B4C061746 for ; Fri, 10 Dec 2021 03:35:16 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id y13so28576359edd.13 for ; Fri, 10 Dec 2021 03:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sHUQnknpRoRpINaobvY2dor6jsSdIZSUoZ8Zm4a2q70=; b=LadmZCjaZOlcssnT0OFEV4tiYNuniS1zjMbnun6AR2XupZ5FHTEh+sbVXdnATwo0XX YHHOr3n+69Mbvv55eH7BOrXueoWN6mAmF+irOtwoIcFiUxXPMMJ40dSK6aIuzvMicgtP 5CWdUJmIpooWMNySNL11fA+tq2liADfyiULGsbwe0bJrEolmvlpI0f0cp44u8bt8aHtn bEjoLPfT0VlGidN+XNd7gA61tRT71HFaxa1z6MZ6FrHVpyaiTvyqg1yk3lxDuRrHGrXo PaYIetNfeTrrxatKOVumscoyVV5hPXXgue56dK0D0neUfogL/gkLb2xDxjGzQnjRL4T0 7h1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sHUQnknpRoRpINaobvY2dor6jsSdIZSUoZ8Zm4a2q70=; b=Z33bYMUP78XB/hySeB+Vc+PfFe4dkhyuHkN8IT7q68nd9LHjNqQ1nTLkP+eUAv1ZcM urYu7+fFuIvx7r6CzhDYA4C2x17p13L2DlLtbZxUr/XoS6Z/H1KQ1eW6iTiUNT5PQGaX C3+WEcZys1X1rFaKZzz9e2vcgZK51tbK5FBljDgwbKOvuPgn7HuYjnqAXQGYBZd1Spgn /4KzpFjUCJBjh5tLqVsMBDPduwHTBdC7l89B8mWlh/ayY7Gjb7TDM6rU2z8VziJmgh87 Md3sRS8+CKfqvAgg2l0b8fMojGMDxtMc3HM9jdWIjkCdejy1OGzJnkOFwW6bdX9HalZG 4mMQ== X-Gm-Message-State: AOAM533H306KMRCGDbv76au6kRBwl2B/aqmmjcqQJqSRebZukvGag+nZ RJcHHrYdHYlCu4wCqFyzTYQddg== X-Google-Smtp-Source: ABdhPJzsYrBDIoY58eWULptlz5iAZzxR1uzAUkqovIWOgsfT1CCTkFzLpJgHyonknttyFtOH9BeMBA== X-Received: by 2002:a17:907:d0b:: with SMTP id gn11mr22731241ejc.355.1639136114749; Fri, 10 Dec 2021 03:35:14 -0800 (PST) Received: from myrica (cpc92880-cmbg19-2-0-cust679.5-4.cable.virginm.net. [82.27.106.168]) by smtp.gmail.com with ESMTPSA id g9sm1373553edb.52.2021.12.10.03.35.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 03:35:14 -0800 (PST) Date: Fri, 10 Dec 2021 11:34:52 +0000 From: Jean-Philippe Brucker To: Robin Murphy Cc: Rob Herring , Linux IOMMU , devicetree@vger.kernel.org, linux-arm-kernel , Will Deacon , Joerg Roedel , Mark Rutland , Jay Chen , Leo Yan , uchida.jun@socionext.com Subject: Re: [PATCH 1/2] dt-bindings: Add Arm SMMUv3 PMCG binding Message-ID: References: <20211116113536.69758-1-jean-philippe@linaro.org> <20211116113536.69758-2-jean-philippe@linaro.org> <2f17b812-367c-da75-a2a6-0c16a93cf4a3@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f17b812-367c-da75-a2a6-0c16a93cf4a3@arm.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Nov 18, 2021 at 03:50:54PM +0000, Robin Murphy wrote: > > > + An SMMUv3 may have several Performance Monitor Counter Group (PMCG). > > > + They are standalone performance monitoring units that support both > > > + architected and IMPLEMENTATION DEFINED event counters. > > > > Humm, I don't know that I agree they are standalone. They could be I > > guess, but looking at the MMU-600 spec the PMCG looks like it's just a > > subset of registers in a larger block. This seems similar to MPAM > > (which I'm working on a binding for) where it's just a register map > > and interrupts, but every other possible resource is unspecified by > > the architecture. > > They're "standalone" in the sense that they don't have to be part of an > SMMU, they could be part of a PCIe root complex or other SoC device that > couples to an SMMU (e.g. anything that can speak AMBA DTI, in the case of > our SMMU implementations). The "standalone" word came from the SMMUv3 spec (IHI0070D.b 10.1): The Performance Monitor Counter Groups are standalone monitoring facilities and, as such, can be implemented in separate components that are all associated with (but not necessarily part of) an SMMU. > > In fact our SMMU TBUs are pretty much separate devices themselves, they just > *only* speak DTI, so access to their registers is proxied through the TCU > programming interface. > > > The simplest change from this would be just specifying that the PMCG > > is child node(s) of whatever it is part of. The extreme would be this > > is all part of the SMMU binding (i.e. reg entry X is PMCG registers, > > interrupts entry Y is pmu irq). > > Being a child of its associated device doesn't seem too bad semantically, > however how would we describe a PMCG as a child of a PCIe node when its > "reg" property still exists in the parent address space and not PCI > config/memory space like any of its siblings? Also in practical terms, > consuming that binding in Linux and getting the things to probe when it may > want to be independent of whether we even understand the parent node at all > could be... unpleasant. So there are multiple options for what "the PMCG is part of". (a) The SMMU: the spec guarantees that a PMCG is associated with an SMMU. (b) The MMIO region: may be within the SMMU (as with MMU-600), outside of it (as does another implementation, two 64k pages after the SMMU base) or, theoretically, within a separate device (e.g. PCIe controller). (c) The thing being measured: does not necessarily match the MMIO region. For example a TBU attached to the PCIe RC but the PMCG MMIO is within the SMMU region. (d) None: the PMCG can be probed and driven separately from the SMMU and other components, as demonstrated by Linux. Which one is normally picked to decide where to insert a devicetree node? I guess (b)? I picked (d) so far as the easiest choice. (a) is also a reasonable choice, being based on the spec, but it might be confusing to have a PMCG node inside the SMMU node when the MMIO region is external, possibly belonging to another device. For the same reason we could discard (c). (b) feels more natural, although it's not clear what to do when the PMCG MMIO region is external or adjacent to the SMMU region. Does the node go inside the SMMU node or one level up? Thanks, Jean > > Robin. > > > > + > > > +properties: > > > + $nodename: > > > + pattern: "^pmu@[0-9a-f]*" > > > > s/*/+/ > > > > Need at least 1 digit. > > > > > + compatible: > > > + oneOf: > > > + - items: > > > + - enum: > > > + - hisilicon,smmu-v3-pmcg-hip08 > > > + - const: arm,smmu-v3-pmcg > > > + - const: arm,smmu-v3-pmcg > > > + > > > + reg: > > > + description: | > > > + Base addresses of the PMCG registers. Either a single address for Page 0 > > > + or an additional address for Page 1, where some registers can be > > > + relocated with SMMU_PMCG_CFGR.RELOC_CTRS. > > > + minItems: 1 > > > + maxItems: 2 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + msi-parent: true > > > + > > > +required: > > > + - compatible > > > + - reg > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - |+ > > > + #include > > > + #include > > > + > > > + pmu@2b420000 { > > > + compatible = "arm,smmu-v3-pmcg"; > > > + reg = <0 0x2b420000 0 0x1000>, > > > + <0 0x2b430000 0 0x1000>; > > > + interrupts = ; > > > + msi-parent = <&its 0xff0000>; > > > + }; > > > + > > > + pmu@2b440000 { > > > + compatible = "arm,smmu-v3-pmcg"; > > > + reg = <0 0x2b440000 0 0x1000>, > > > + <0 0x2b450000 0 0x1000>; > > > + interrupts = ; > > > + msi-parent = <&its 0xff0000>; > > > + }; > > > -- > > > 2.33.1 > > > 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 Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A7DACC433F5 for ; Fri, 10 Dec 2021 11:35:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 294D761407; Fri, 10 Dec 2021 11:35:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rosCbWz-66qh; Fri, 10 Dec 2021 11:35:20 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTPS id EDA3761406; Fri, 10 Dec 2021 11:35:19 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8B7EFC002F; Fri, 10 Dec 2021 11:35:19 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id DDF32C0012 for ; Fri, 10 Dec 2021 11:35:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C917061406 for ; Fri, 10 Dec 2021 11:35:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKmYse4Wx7oR for ; Fri, 10 Dec 2021 11:35:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by smtp3.osuosl.org (Postfix) with ESMTPS id B1D5C61405 for ; Fri, 10 Dec 2021 11:35:16 +0000 (UTC) Received: by mail-ed1-x530.google.com with SMTP id l25so29190306eda.11 for ; Fri, 10 Dec 2021 03:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sHUQnknpRoRpINaobvY2dor6jsSdIZSUoZ8Zm4a2q70=; b=LadmZCjaZOlcssnT0OFEV4tiYNuniS1zjMbnun6AR2XupZ5FHTEh+sbVXdnATwo0XX YHHOr3n+69Mbvv55eH7BOrXueoWN6mAmF+irOtwoIcFiUxXPMMJ40dSK6aIuzvMicgtP 5CWdUJmIpooWMNySNL11fA+tq2liADfyiULGsbwe0bJrEolmvlpI0f0cp44u8bt8aHtn bEjoLPfT0VlGidN+XNd7gA61tRT71HFaxa1z6MZ6FrHVpyaiTvyqg1yk3lxDuRrHGrXo PaYIetNfeTrrxatKOVumscoyVV5hPXXgue56dK0D0neUfogL/gkLb2xDxjGzQnjRL4T0 7h1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sHUQnknpRoRpINaobvY2dor6jsSdIZSUoZ8Zm4a2q70=; b=3yyBsVEa/giOnlsYmmHWRlupqbPAzVXrkbh5wihDY93eTsijyJQwEpdoSiJ5uMsTH0 37Lb6FNdmrpMBIINjdvPqWXzqQ9L5unO1SIwgOjLX8LG2kRHqrhkjGZUGA5oO/Tddz6S 42D4dt7J5PdaRQWkUgviMbYeR82C1JYHZJMeReBcO+4NHiCWvCi12SyiOwQJ7XnwlpLt odxZhvUrSrOmcbaE7jSV3PpkUjLDzQ0KfG4YlVIUWD7zIakd7bwHMwj8I3gIWxucxcIV 9Zi315sUygjV1zc5sDkBOZ4G6c7ajzrKbsbtpo1EjfefCue2TRqb7jQdXo8XjG7HKR/l d4+w== X-Gm-Message-State: AOAM5332HeBtgMfTeDEcADHqLwM8q0LQyq2nB8ox5Man+cVvP33SZFzT 80SMG91Lonb/FqGRY1sfULPhhA== X-Google-Smtp-Source: ABdhPJzsYrBDIoY58eWULptlz5iAZzxR1uzAUkqovIWOgsfT1CCTkFzLpJgHyonknttyFtOH9BeMBA== X-Received: by 2002:a17:907:d0b:: with SMTP id gn11mr22731241ejc.355.1639136114749; Fri, 10 Dec 2021 03:35:14 -0800 (PST) Received: from myrica (cpc92880-cmbg19-2-0-cust679.5-4.cable.virginm.net. [82.27.106.168]) by smtp.gmail.com with ESMTPSA id g9sm1373553edb.52.2021.12.10.03.35.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 03:35:14 -0800 (PST) Date: Fri, 10 Dec 2021 11:34:52 +0000 From: Jean-Philippe Brucker To: Robin Murphy Subject: Re: [PATCH 1/2] dt-bindings: Add Arm SMMUv3 PMCG binding Message-ID: References: <20211116113536.69758-1-jean-philippe@linaro.org> <20211116113536.69758-2-jean-philippe@linaro.org> <2f17b812-367c-da75-a2a6-0c16a93cf4a3@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2f17b812-367c-da75-a2a6-0c16a93cf4a3@arm.com> Cc: Mark Rutland , devicetree@vger.kernel.org, Linux IOMMU , Rob Herring , uchida.jun@socionext.com, Leo Yan , Will Deacon , linux-arm-kernel X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Thu, Nov 18, 2021 at 03:50:54PM +0000, Robin Murphy wrote: > > > + An SMMUv3 may have several Performance Monitor Counter Group (PMCG). > > > + They are standalone performance monitoring units that support both > > > + architected and IMPLEMENTATION DEFINED event counters. > > > > Humm, I don't know that I agree they are standalone. They could be I > > guess, but looking at the MMU-600 spec the PMCG looks like it's just a > > subset of registers in a larger block. This seems similar to MPAM > > (which I'm working on a binding for) where it's just a register map > > and interrupts, but every other possible resource is unspecified by > > the architecture. > > They're "standalone" in the sense that they don't have to be part of an > SMMU, they could be part of a PCIe root complex or other SoC device that > couples to an SMMU (e.g. anything that can speak AMBA DTI, in the case of > our SMMU implementations). The "standalone" word came from the SMMUv3 spec (IHI0070D.b 10.1): The Performance Monitor Counter Groups are standalone monitoring facilities and, as such, can be implemented in separate components that are all associated with (but not necessarily part of) an SMMU. > > In fact our SMMU TBUs are pretty much separate devices themselves, they just > *only* speak DTI, so access to their registers is proxied through the TCU > programming interface. > > > The simplest change from this would be just specifying that the PMCG > > is child node(s) of whatever it is part of. The extreme would be this > > is all part of the SMMU binding (i.e. reg entry X is PMCG registers, > > interrupts entry Y is pmu irq). > > Being a child of its associated device doesn't seem too bad semantically, > however how would we describe a PMCG as a child of a PCIe node when its > "reg" property still exists in the parent address space and not PCI > config/memory space like any of its siblings? Also in practical terms, > consuming that binding in Linux and getting the things to probe when it may > want to be independent of whether we even understand the parent node at all > could be... unpleasant. So there are multiple options for what "the PMCG is part of". (a) The SMMU: the spec guarantees that a PMCG is associated with an SMMU. (b) The MMIO region: may be within the SMMU (as with MMU-600), outside of it (as does another implementation, two 64k pages after the SMMU base) or, theoretically, within a separate device (e.g. PCIe controller). (c) The thing being measured: does not necessarily match the MMIO region. For example a TBU attached to the PCIe RC but the PMCG MMIO is within the SMMU region. (d) None: the PMCG can be probed and driven separately from the SMMU and other components, as demonstrated by Linux. Which one is normally picked to decide where to insert a devicetree node? I guess (b)? I picked (d) so far as the easiest choice. (a) is also a reasonable choice, being based on the spec, but it might be confusing to have a PMCG node inside the SMMU node when the MMIO region is external, possibly belonging to another device. For the same reason we could discard (c). (b) feels more natural, although it's not clear what to do when the PMCG MMIO region is external or adjacent to the SMMU region. Does the node go inside the SMMU node or one level up? Thanks, Jean > > Robin. > > > > + > > > +properties: > > > + $nodename: > > > + pattern: "^pmu@[0-9a-f]*" > > > > s/*/+/ > > > > Need at least 1 digit. > > > > > + compatible: > > > + oneOf: > > > + - items: > > > + - enum: > > > + - hisilicon,smmu-v3-pmcg-hip08 > > > + - const: arm,smmu-v3-pmcg > > > + - const: arm,smmu-v3-pmcg > > > + > > > + reg: > > > + description: | > > > + Base addresses of the PMCG registers. Either a single address for Page 0 > > > + or an additional address for Page 1, where some registers can be > > > + relocated with SMMU_PMCG_CFGR.RELOC_CTRS. > > > + minItems: 1 > > > + maxItems: 2 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + msi-parent: true > > > + > > > +required: > > > + - compatible > > > + - reg > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - |+ > > > + #include > > > + #include > > > + > > > + pmu@2b420000 { > > > + compatible = "arm,smmu-v3-pmcg"; > > > + reg = <0 0x2b420000 0 0x1000>, > > > + <0 0x2b430000 0 0x1000>; > > > + interrupts = ; > > > + msi-parent = <&its 0xff0000>; > > > + }; > > > + > > > + pmu@2b440000 { > > > + compatible = "arm,smmu-v3-pmcg"; > > > + reg = <0 0x2b440000 0 0x1000>, > > > + <0 0x2b450000 0 0x1000>; > > > + interrupts = ; > > > + msi-parent = <&its 0xff0000>; > > > + }; > > > -- > > > 2.33.1 > > > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 15390C433F5 for ; Fri, 10 Dec 2021 11:37:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=86ASdL28rtMszkFmVcuTUc4hG+gd76QKcURuD7fncqM=; b=P9KqZqRERTXREj XrSRKGSGDai5UZvo3bAYcZANdhhD9STrn1oFc4Bq/aQpQ4TCAzWHFnDftlj3HW4I4PeBERZRhpemm 6fP3c92Kat7at/mdKJU7QZeyxmhRW0VggIrWMvU/W0P7HSXpFI91Xs3u5aVjebjdXMlq72wgCpdk5 321XZjNRN6Wuxc/tVQTRixgsFKKqu4z03V6YhVGa6NHp65b5VJy1CPLbFQDgQc8XWYc8iT0dzyizG 0hr2fXPw9aiZE0Nk8vwJhCXbDlBhdunH3g4rqvkIo18a8wDW/sde/9D+zx69UK+RuMnYcUgJiNU0R AMFgwpwur+R2dy+++bXw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mveBR-001gyc-S1; Fri, 10 Dec 2021 11:35:26 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mveBK-001gx6-Gu for linux-arm-kernel@lists.infradead.org; Fri, 10 Dec 2021 11:35:20 +0000 Received: by mail-ed1-x52d.google.com with SMTP id o20so29308546eds.10 for ; Fri, 10 Dec 2021 03:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sHUQnknpRoRpINaobvY2dor6jsSdIZSUoZ8Zm4a2q70=; b=LadmZCjaZOlcssnT0OFEV4tiYNuniS1zjMbnun6AR2XupZ5FHTEh+sbVXdnATwo0XX YHHOr3n+69Mbvv55eH7BOrXueoWN6mAmF+irOtwoIcFiUxXPMMJ40dSK6aIuzvMicgtP 5CWdUJmIpooWMNySNL11fA+tq2liADfyiULGsbwe0bJrEolmvlpI0f0cp44u8bt8aHtn bEjoLPfT0VlGidN+XNd7gA61tRT71HFaxa1z6MZ6FrHVpyaiTvyqg1yk3lxDuRrHGrXo PaYIetNfeTrrxatKOVumscoyVV5hPXXgue56dK0D0neUfogL/gkLb2xDxjGzQnjRL4T0 7h1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sHUQnknpRoRpINaobvY2dor6jsSdIZSUoZ8Zm4a2q70=; b=LLIMpTRI1fcj4yDcfPeJ77APy7mMYKFifosmRjqj3EA5LxdsRcaNmIFvfQ1knrTlwf hhbcdYOzLTwvUsGFm047HAQOj28GXrWUiaWr+2locD1JLOyG0Ow9jDVmW99vQZJbMtkm TyzIx8OQ0eEWdcpiYvp27shCsPGGe3S1z7hRKVAC1kspPqQusHfQGrbIMcTwFXmvu/cw PMRrqFzudRqZv5Hgi9FQWiaatnZi4hexOZHyemuhjAdT66UbYU7QlpVB8rJXje5GOekS JkWtCHvkzROeg1MK7VDpakTGxVDYBvDMSRKOgtzlINH+vCnBtCsLq7HPNRvV7E2XyQFF FqpQ== X-Gm-Message-State: AOAM531k/W8hX286sEUPq4Vx5YbnlMwZHBDE+sSdbFK1BSywS3wUf8Oz 1mr2Tq/8QsvUse9vg/rp4YyT+g== X-Google-Smtp-Source: ABdhPJzsYrBDIoY58eWULptlz5iAZzxR1uzAUkqovIWOgsfT1CCTkFzLpJgHyonknttyFtOH9BeMBA== X-Received: by 2002:a17:907:d0b:: with SMTP id gn11mr22731241ejc.355.1639136114749; Fri, 10 Dec 2021 03:35:14 -0800 (PST) Received: from myrica (cpc92880-cmbg19-2-0-cust679.5-4.cable.virginm.net. [82.27.106.168]) by smtp.gmail.com with ESMTPSA id g9sm1373553edb.52.2021.12.10.03.35.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 03:35:14 -0800 (PST) Date: Fri, 10 Dec 2021 11:34:52 +0000 From: Jean-Philippe Brucker To: Robin Murphy Cc: Rob Herring , Linux IOMMU , devicetree@vger.kernel.org, linux-arm-kernel , Will Deacon , Joerg Roedel , Mark Rutland , Jay Chen , Leo Yan , uchida.jun@socionext.com Subject: Re: [PATCH 1/2] dt-bindings: Add Arm SMMUv3 PMCG binding Message-ID: References: <20211116113536.69758-1-jean-philippe@linaro.org> <20211116113536.69758-2-jean-philippe@linaro.org> <2f17b812-367c-da75-a2a6-0c16a93cf4a3@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2f17b812-367c-da75-a2a6-0c16a93cf4a3@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211210_033518_608429_211FC691 X-CRM114-Status: GOOD ( 36.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 18, 2021 at 03:50:54PM +0000, Robin Murphy wrote: > > > + An SMMUv3 may have several Performance Monitor Counter Group (PMCG). > > > + They are standalone performance monitoring units that support both > > > + architected and IMPLEMENTATION DEFINED event counters. > > > > Humm, I don't know that I agree they are standalone. They could be I > > guess, but looking at the MMU-600 spec the PMCG looks like it's just a > > subset of registers in a larger block. This seems similar to MPAM > > (which I'm working on a binding for) where it's just a register map > > and interrupts, but every other possible resource is unspecified by > > the architecture. > > They're "standalone" in the sense that they don't have to be part of an > SMMU, they could be part of a PCIe root complex or other SoC device that > couples to an SMMU (e.g. anything that can speak AMBA DTI, in the case of > our SMMU implementations). The "standalone" word came from the SMMUv3 spec (IHI0070D.b 10.1): The Performance Monitor Counter Groups are standalone monitoring facilities and, as such, can be implemented in separate components that are all associated with (but not necessarily part of) an SMMU. > > In fact our SMMU TBUs are pretty much separate devices themselves, they just > *only* speak DTI, so access to their registers is proxied through the TCU > programming interface. > > > The simplest change from this would be just specifying that the PMCG > > is child node(s) of whatever it is part of. The extreme would be this > > is all part of the SMMU binding (i.e. reg entry X is PMCG registers, > > interrupts entry Y is pmu irq). > > Being a child of its associated device doesn't seem too bad semantically, > however how would we describe a PMCG as a child of a PCIe node when its > "reg" property still exists in the parent address space and not PCI > config/memory space like any of its siblings? Also in practical terms, > consuming that binding in Linux and getting the things to probe when it may > want to be independent of whether we even understand the parent node at all > could be... unpleasant. So there are multiple options for what "the PMCG is part of". (a) The SMMU: the spec guarantees that a PMCG is associated with an SMMU. (b) The MMIO region: may be within the SMMU (as with MMU-600), outside of it (as does another implementation, two 64k pages after the SMMU base) or, theoretically, within a separate device (e.g. PCIe controller). (c) The thing being measured: does not necessarily match the MMIO region. For example a TBU attached to the PCIe RC but the PMCG MMIO is within the SMMU region. (d) None: the PMCG can be probed and driven separately from the SMMU and other components, as demonstrated by Linux. Which one is normally picked to decide where to insert a devicetree node? I guess (b)? I picked (d) so far as the easiest choice. (a) is also a reasonable choice, being based on the spec, but it might be confusing to have a PMCG node inside the SMMU node when the MMIO region is external, possibly belonging to another device. For the same reason we could discard (c). (b) feels more natural, although it's not clear what to do when the PMCG MMIO region is external or adjacent to the SMMU region. Does the node go inside the SMMU node or one level up? Thanks, Jean > > Robin. > > > > + > > > +properties: > > > + $nodename: > > > + pattern: "^pmu@[0-9a-f]*" > > > > s/*/+/ > > > > Need at least 1 digit. > > > > > + compatible: > > > + oneOf: > > > + - items: > > > + - enum: > > > + - hisilicon,smmu-v3-pmcg-hip08 > > > + - const: arm,smmu-v3-pmcg > > > + - const: arm,smmu-v3-pmcg > > > + > > > + reg: > > > + description: | > > > + Base addresses of the PMCG registers. Either a single address for Page 0 > > > + or an additional address for Page 1, where some registers can be > > > + relocated with SMMU_PMCG_CFGR.RELOC_CTRS. > > > + minItems: 1 > > > + maxItems: 2 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + msi-parent: true > > > + > > > +required: > > > + - compatible > > > + - reg > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - |+ > > > + #include > > > + #include > > > + > > > + pmu@2b420000 { > > > + compatible = "arm,smmu-v3-pmcg"; > > > + reg = <0 0x2b420000 0 0x1000>, > > > + <0 0x2b430000 0 0x1000>; > > > + interrupts = ; > > > + msi-parent = <&its 0xff0000>; > > > + }; > > > + > > > + pmu@2b440000 { > > > + compatible = "arm,smmu-v3-pmcg"; > > > + reg = <0 0x2b440000 0 0x1000>, > > > + <0 0x2b450000 0 0x1000>; > > > + interrupts = ; > > > + msi-parent = <&its 0xff0000>; > > > + }; > > > -- > > > 2.33.1 > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel