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 DB6F6C433F5 for ; Tue, 7 Dec 2021 13:48:23 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kLVJipbjpkrIzKIVaQt+b9dLw7EZZnpHK67vxiIkAo4=; b=b3PM0GWoJ+GxDJ by4pryKzjHLdKtZIulOO2hvQ0WMvuZLdUOVhSYPYY1faupQ5UDrAIot35luB6YGu2adK5fH67vQIL fGb35yPvGkX4ZCGNgBeQHYl66HG0KaT/7v23tBMjhhCTUjjA8xRCOc8Ue31SbjTpQ5cuXjYtCo59V FUbj55tnJ1pzrleXEw6+tjOIrrnhBNDH0DyAnC2gUjgsY4w/T1BhyZ3YCAMDaCGCgv8TZqXtH28s8 7W46VpNBQKXN+Mo+Rj57kVHulXW8X1oWR7ZDq9yzxRHxBZhLsz4sXYkw2zG2q/6eQeqps2PkH4Lc5 xyEYGmeTr4Ikex5FCFkQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muaoA-008kRw-WE; Tue, 07 Dec 2021 13:47:03 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muao6-008kQz-CF for linux-arm-kernel@lists.infradead.org; Tue, 07 Dec 2021 13:47:00 +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 EC85B11FB; Tue, 7 Dec 2021 05:46:54 -0800 (PST) Received: from [10.57.34.58] (unknown [10.57.34.58]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5CC683F5A1; Tue, 7 Dec 2021 05:46:53 -0800 (PST) Message-ID: <675bfd78-69ac-608f-1303-e86b90a83f72@arm.com> Date: Tue, 7 Dec 2021 13:46:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers Content-Language: en-GB To: Leo Yan Cc: John Garry , Jean-Philippe Brucker , mark.rutland@arm.com, devicetree@vger.kernel.org, iommu@lists.linux-foundation.org, uchida.jun@socionext.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org References: <20211117144844.241072-1-jean-philippe@linaro.org> <20211117144844.241072-4-jean-philippe@linaro.org> <766ac58a-ffb7-f673-709b-0f0f740f3cfd@arm.com> <53f868a8-c7ae-b69d-b061-bb0a7dc98f8a@huawei.com> <20211207132007.GB255238@leoy-ThinkPad-X240s> From: Robin Murphy In-Reply-To: <20211207132007.GB255238@leoy-ThinkPad-X240s> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211207_054658_576614_8099F283 X-CRM114-Status: GOOD ( 29.47 ) 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-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 2021-12-07 13:20, Leo Yan wrote: > On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote: >> On 2021-12-07 12:28, John Garry via iommu wrote: >>> On 07/12/2021 12:04, Robin Murphy wrote: >>>>>> >>>>> So is there some userspace part to go with this now? >>>> >>>> FWIW I've not looked into it - is it just a case of someone knocking >>>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to >>>> do? >>> >>> That should just be it. > > Hope I didn't arrive too late :) > > Yes, I think we just missed two things: the DT binding for SMMUv3 PMU > which is just addressed by this patchset; and the PMU event aliasing > for SMMUv3 PMU, before I inquired with John and John said he would > upstream the related patches after kernel can export a IIDR value via > sysfs node. > > Seems to me, after this patchset for DT binding and PMU event alias > patches are landed to the mainline kernel, it would be perfect. > >>>> I had the impression that *some* part of the process was stalled >>>> until implementations can start providing meaningful IIDRs, but I >>>> wasn't sure whether that was tooling or just data. I just work the >>>> low-level enablement angle :) >>> >>> Tooling should be ok, but I would just like to see more of these JSONs >>> so any tooling issues can be ironed out. >> >> Sounds good - Jean, Leo, is that something Linaro might like to pick up as >> part of the PMCG interest, or shall I make a note on my to-do list for the >> new year? > > I took a look for current patch for using PIDR to synthesize IIDR, it > looks good to me. But I tested it on Hisilicon D06 board and observed > the composed IIDR values are still zeros. > > I added a printk sentence to dump iidr value at the end of the function > smmu_pmu_get_iidr(): > > leoy@ubuntu:~$ dmesg | grep iidr > [ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0 > [ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0 > [ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0 > [ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0 > [ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0 > [ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0 > [ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0 > [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0 > > Please confirm if this is expected or not? I think this might > introduce difficulty for John for the PMU event alias patches, which > is dependent on a non-zero IIDR. Yes, from previous discussions I believe the HiSilicon implementations don't have much meaningful ID information at all (hence why we have to match ACPI table headers to identify the counter erratum). My trick only works for Arm Ltd. implementations since they happen to have the IMP-DEF CoreSight registers with the same information as would be in the future IIDR. To clarify, the proposal at this point is to write up JSON files for MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for future SMMUv3.3 PMCG implementations with real IIDRs. Whether other implementers might retroactively define "equivalent" IIDR values for their existing implementations in a way we could potentially quirk in the driver is an orthogonal question. Cheers, Robin. > > At last, very appreciate your (Jean-Philippe, Robin and John) help! > > Thanks, > Leo > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel