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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 9C96FC433E6 for ; Tue, 14 Jul 2020 09:37:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 66828217A0 for ; Tue, 14 Jul 2020 09:37:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rfBjEGYg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66828217A0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5utsjsqKCvn7Q+ZfZkVGHbymok4XShKBBw6jWrB7Pi0=; b=rfBjEGYg7udKBxztSZwgT8Dh0 gXwBj0ddTNmHG3DO9YIGkSTfajX7lavsNNlvz9cgGYY6fJ4EhTv36F1Jd0Bzr9FcvAcY+CND3UQgk Cv7zIwe6CGdSMqwkiamtfC0GiVIyOOYN4kxyWgHtq/v8TYndsXrYPglzmi3MMoTRD4kqoWR0gslct 8Y5uGiLp0js6PRtd8Dt/bC2O/R1/0omMQ88/nwbMp85Rn61Fz4VfgBoYQvT+C2UBxLxPaAV7tuVpS FXotO64I0Bg37I1B2uD8kd9r9RQDr3YowSupUl8I2eBJa1CfUw1kQP0aTifeNKsx8IbEAohLjWNfw YnGTSuVgg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvHM5-0004ZS-Or; Tue, 14 Jul 2020 09:36:06 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvHLN-0004Lz-Nl for linux-arm-kernel@lists.infradead.org; Tue, 14 Jul 2020 09:35:39 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 37F4231B; Tue, 14 Jul 2020 02:35:20 -0700 (PDT) Received: from [10.119.37.146] (unknown [10.119.37.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 334A03F7BB; Tue, 14 Jul 2020 02:35:19 -0700 (PDT) Subject: Re: [RFC PATCH v1 2/2] perf/smmuv3: To support the dts to get options To: Rob Herring , Jean-Philippe Brucker References: <20200706112246.92220-1-jkchen@linux.alibaba.com> <20200706112246.92220-3-jkchen@linux.alibaba.com> <024231fc-cf6e-6785-5153-2e7f45496911@arm.com> <20200707150114.GC159413@myrica> <20200713232503.GB899100@bogus> From: Robin Murphy Message-ID: <2c64e95c-a4fc-4487-6e85-50e3882c0b64@arm.com> Date: Tue, 14 Jul 2020 10:35:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200713232503.GB899100@bogus> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200714_053521_975141_06F073A6 X-CRM114-Status: GOOD ( 28.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, Jay Chen , will@kernel.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-07-14 00:25, Rob Herring wrote: > On Tue, Jul 07, 2020 at 05:01:14PM +0200, Jean-Philippe Brucker wrote: >> Hi, >> >> On Mon, Jul 06, 2020 at 04:03:34PM +0100, Robin Murphy wrote: >>> On 2020-07-06 12:22, Jay Chen wrote: >>>> For the smmuv3 pmu for support the dts to get the >>>> options >>>> >>>> Signed-off-by: Jay Chen >> [...] >>>> +static const struct of_device_id smmu_pmu_of_match[] = { >>>> + { .compatible = "arm-smmu-v3-pmcg", }, >>> >>> Please define the DT binding first. IIRC Jean-Philippe wrote some patches a >>> while back that never got posted, but I suppose it should be YAML now... >> >> Yes, I've never followed through with that because it only supported the >> RevC FastModel with non-default model parameters. I attached the binding I >> currently have, converted to YAML. >> >> Thanks, >> Jean >> > >> >From b117e5b4ce96a5a8327333ab408cf61200850d4f Mon Sep 17 00:00:00 2001 >> From: Jean-Philippe Brucker >> Date: Tue, 7 Jul 2020 16:55:16 +0200 >> Subject: [PATCH] dt-bindings: Add SMMUv3 PMCG binding >> >> Add binding for the SMMUv3 PMU. Each node represents a PMCG, and is placed >> as a sibling node of the SMMU. As PMCGs are mainly implementation >> defined there is no 1-1 relation between SMMU and PMCG. The SMMU could >> have PMU counters for the TCU and each TBU, or a single PMCG. >> >> TODO: although the Linux implementation doesn't need them, it'd be nice >> to have links from the PMCG node to its associated SMMU. IORT does offer >> this (Node reference) and perhaps it could later help users figure out >> which PMCG is which on systems with dozens of SMMU. > > Is the PMCG really a separate block or a new node is just convenient to > instantiate a driver? Yes, PMCGs are their own thing with their own little programming interfaces and interrupts, there are typically multiple PMCG instances per SMMU, and they may even belong to "non-SMMU" components which participate in translation, like PCIe root complexes or devices with their own embedded TLBs. >> >> Signed-off-by: Jean-Philippe Brucker >> --- >> .../bindings/iommu/arm,smmu-v3-pmcg.yaml | 58 +++++++++++++++++++ >> 1 file changed, 58 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml >> >> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml >> new file mode 100644 >> index 000000000000..23190a617e7e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml >> @@ -0,0 +1,58 @@ >> +# SPDX-License-Identifier: GPL-2.0-only > > Dual license new bindings. > >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/iommu/arm,smmu-v3-pmcg.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: ARM SMMUv3 Performance Monitor Counter Group >> + >> +maintainers: >> + - Will Deacon >> + - Robin Murphy >> + >> +description: |+ >> + 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. >> + >> +properties: >> + $nodename: >> + pattern: "^smmu-pmcg@[0-9a-f]*" > > Should be generic: > > pmu@... > > (or whatever we've used for PMUs). > >> + compatible: >> + const: arm,smmu-v3-pmcg > > This is correct, but doesn't match the driver. To be fair, this binding wasn't originally written for this particular driver patch ;) >> + >> + reg: >> + minItems: 1 >> + maxItems: 2 > > More than 1 entry needs a description of what each one is. > > A variable number of 'reg' entries generally implies more than 1 > compatible unless the 2nd entry is optional. The second is "optional" in terms of the architecture (and thus the generic compatible), but fixed for any specific implementation - it's a choice of whether the counter registers are in the same page as the control registers or in a separate page, but that can be architecturally discovered from an ID register in the first page (see the handling of SMMU_PMCG_CFGR_RELOC_CTRS if you're interested). Robin. >> + >> + interrupts: >> + maxItems: 1 >> + >> + msi-parent: true >> + >> +required: >> + - compatible >> + - reg >> + >> +additionalProperties: false >> + >> +examples: >> + - |+ >> + #include >> + #include >> + >> + tcu: smmu-pmcg@2b420000 { > > Drop unused labels. > >> + compatible = "arm,smmu-v3-pmcg"; >> + reg = <0 0x2b420000 0 0x1000>, >> + <0 0x2b430000 0 0x1000>; >> + interrupts = ; >> + msi-parent = <&its 0xff0000>; >> + }; >> + >> + tbu0: smmu-pmcg@2b440000 { >> + compatible = "arm,smmu-v3-pmcg"; >> + reg = <0 0x2b440000 0 0x1000>, >> + <0 0x2b450000 0 0x1000>; >> + interrupts = ; >> + msi-parent = <&its 0xff0000>; >> + }; >> -- >> 2.27.0 >> > >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel