From patchwork Mon Sep 30 14:33:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 174755 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp7216206ill; Mon, 30 Sep 2019 07:37:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqwu6W39HbvItNw88jifFR1hhppTlhRkCXilReq1wLyoeIhyo5oUnDbZBV0y6MwcrNyrLV6Y X-Received: by 2002:aa7:c5c1:: with SMTP id h1mr19905689eds.10.1569854220234; Mon, 30 Sep 2019 07:37:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569854220; cv=none; d=google.com; s=arc-20160816; b=l/E9sJgHBayTs8+TTCwGrKGOEhrbo2qjCRkhmcxc/yXZpxZnyFvwh7EFYqOzyTz1fk ftPmS1ZCvl2GN6T/fCzq6YRG/uR+SNp2HBe/DM7/+cCsENgjw1933SQ+HOEaa57X5tyQ uwDj86A/KaW2y3dFC/cU1ah1n6MdLcEZAiJdr4Isb9uieyI6h4XiKBl8QzSsP8ZDA6L8 9nYJ1rXIqG1qvuvsTOO2c473Q8f/PqnVV+T/h0T6oqlCGLmzqneAPLi29PWDjeXbVHNQ P5gQRwE2mumxUlGMQ6vL6zevtwgHOyTTXLrWNw5YK3Vw84kfuRWXWjj2WflpeafCdaBI E1mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=UcVWQRn9Xwe1Sf2E1IZDX0ioMnZOV2S6YSTCWoP65lM=; b=ww6wrlZEsg633b//T2LdOZC7OT7OhWfLumopqzejkfLYRLBhaMgIG9jjwYovP/Xl3b CFNd8iHjZmq6YTfbBN6uz6GWSiAYYrpLeTXpR6rymPX3vUGL8wOCHEOwD03Oy+z6KrN6 U8V0Of9fkieTIHPLeOF73EeTYHuqCFYjbGPX7ZJQQKjQBF4PkVNUbIbLV3BIa04qQ2Hl uDfzflkJ0f8A13qAKsneSMiL+2zGjBIPhNyAncr5ddWBAPHIsIu4iPQK0g+iNgl0/iHF wQ2UjQrIYykSh8W59UEzSoGVl8ltrMw9CCXOVuMpYZIvx15dsGRGCSAvE9i3y0FC0Vdo flzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ng7si7198007ejb.91.2019.09.30.07.37.00; Mon, 30 Sep 2019 07:37:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731689AbfI3Og4 (ORCPT + 27 others); Mon, 30 Sep 2019 10:36:56 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:46088 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730780AbfI3Ogz (ORCPT ); Mon, 30 Sep 2019 10:36:55 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 4FC4CFE66C605F3E5AC5; Mon, 30 Sep 2019 22:36:53 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.439.0; Mon, 30 Sep 2019 22:36:46 +0800 From: John Garry To: , , , , , CC: , , , , , , , , John Garry Subject: [RFC PATCH 0/6] SMMUv3 PMCG IMP DEF event support Date: Mon, 30 Sep 2019 22:33:45 +0800 Message-ID: <1569854031-237636-1-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 2.8.1 MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patchset adds IMP DEF event support for the SMMUv3 PMCG. It is marked as an RFC as the method to identify the PMCG implementation may be a quite disliked. And, in general, the series is somewhat incomplete. So the background is that the PMCG supports IMP DEF events, yet we have no method to identify the PMCG to know the IMP DEF events. A method for identifying the PMCG implementation could be using PMDEVARCH, but we cannot rely on this being set properly, as whether this is implemented is not defined in SMMUv3 spec. Another method would be perf event aliasing, but this method of event matching is based on CPU id, which would not guarantee same uniqueness as PMCG implementation. Yet another method could be to continue using ACPI OEM ID in the IORT code, but this does not scale. And it is not suitable if we ever add DT support to the PMCG driver. The method used in this series is based on matching on the parent SMMUv3 IIDR. We store this IIDR contents in the arm smmu structure as the first element, which means that we don't have to expose SMMU APIs - this is the part which may be disliked. The final two patches switch the pre-existing PMCG model identification from ACPI OEM ID to the same parent SMMUv3 IIDR matching. For now, we only consider SMMUv3' nodes being the associated node for PMCG. John Garry (6): ACPI/IORT: Set PMCG device parent iommu/arm-smmu-v3: Record IIDR in arm_smmu_device structure perf/smmuv3: Retrieve parent SMMUv3 IIDR perf/smmuv3: Support HiSilicon hip08 (hi1620) IMP DEF events perf/smmuv3: Match implementation options based on parent SMMU IIDR ACPI/IORT: Drop code to set the PMCG software-defined model drivers/acpi/arm64/iort.c | 69 ++++++++++++++-------------- drivers/iommu/arm-smmu-v3.c | 5 +++ drivers/perf/arm_smmuv3_pmu.c | 84 ++++++++++++++++++++++++++++++----- include/linux/acpi_iort.h | 8 ---- 4 files changed, 112 insertions(+), 54 deletions(-) -- 2.17.1