Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2265313ybi; Mon, 17 Jun 2019 01:38:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjR2Pr28pToL97rAVPPGKBlo569FWOrrWs3WD9aJGTxIAiftiFd5zfz1K3CDOOzfz+PUud X-Received: by 2002:a63:b1d:: with SMTP id 29mr48143963pgl.103.1560760706985; Mon, 17 Jun 2019 01:38:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560760706; cv=none; d=google.com; s=arc-20160816; b=JLO/9VbaWUhZ3UB/0c+wec3WLaVUnUeaB8GGLwv6FRHTEX0s4RdOf6AQbQXvb5bTjf FhetLQx0izCz5iwRgC8XruSEJVDW2h3+R7KBpfleU6Hf1huKWkvcuSD69h4gCA0XGDRQ UwTEq8I2e5sAtPApa/PJ8vEMbIF317TRZxDi6VmLpTPn5vB6XEGpGZiQqPaAJgsKQozd 67PMwrhuVP/qbdX6VSBHliP4634iiGbgF4rLusCHlUPI+Ef7zVDCVYmb6xlXlCeaRMOU i3SLaDOlgxgZshLif20lCxqlCef7QUZvXSF62/UVgfHRVrtaeY2nkSj9vPOaeQMKuB2v DaXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=xexmwnmCjZQU5g18uzmFVq5Jk9iKkALq7mZ+K9BQswA=; b=cNl6GVCk5GakYL95soENna+HiImxTiclKhODypE7eXRHteIA6URUpOdHskaC5ynk1U fvz4pawFeRUgtBSblI6rA2zS16D2cwO8n2dMHFcCKp+FGuR9wn3mjm3WBewXSN1leUTL O2wfwgZfO+E8nCtoyUa6puKflnYhAFwlpu3MDweBv1uvDWucHUvDTN/0QAx0cgtr1leg 82FtFq8DFeVjP+4qcMi0rHSHpANMGLDl92ETOPjPDP+12jCk6TNvaXWE7Bl2KZtwpHXr vl9Johv+WhbaFKsbg8sFYXsK29wmbMt0Fk/ncQxvlrOnBoFMbBvjRCT+UTW3zeESolUz RHKg== 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 g190si1638813pgc.131.2019.06.17.01.38.11; Mon, 17 Jun 2019 01:38:26 -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 S1727703AbfFQIhG (ORCPT + 99 others); Mon, 17 Jun 2019 04:37:06 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:18585 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727424AbfFQIhF (ORCPT ); Mon, 17 Jun 2019 04:37:05 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7645971360ECAA5C908A; Mon, 17 Jun 2019 16:37:01 +0800 (CST) Received: from [127.0.0.1] (10.177.223.23) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.439.0; Mon, 17 Jun 2019 16:36:57 +0800 Subject: Re: [PATCH v4 0/4] arm64: SPE ACPI enablement To: Jeremy Linton , CC: , , , , , , , , References: <20190615010910.33921-1-jeremy.linton@arm.com> From: Hanjun Guo Message-ID: <7215e7f2-b8d3-999e-427b-428282765276@huawei.com> Date: Mon, 17 Jun 2019 16:36:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20190615010910.33921-1-jeremy.linton@arm.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.223.23] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/6/15 9:09, Jeremy Linton wrote: > This patch series enables the Arm Statistical Profiling > Extension (SPE) on ACPI platforms. > > This is possible because ACPI 6.3 uses a previously > reserved field in the MADT to store the SPE interrupt > number, similarly to how the normal PMU is described. > If a consistent valid interrupt exists across all the > cores in the system, a platform device is registered. > That then triggers the SPE module, which runs as normal. > > We also add the ability to parse the PPTT for IDENTICAL > cores. We then use this to sanity check the single SPE > device we create. This creates a bit of a problem with > respect to the specification though. The specification > says that its legal for multiple tree's to exist in the > PPTT. We handle this fine, but what happens in the > case of multiple tree's is that the lack of a common > node with IDENTICAL set forces us to assume that there > are multiple non-IDENTICAL cores in the machine. > > v3->v4: Rebase to 5.2. > Minor formatting, patch rearrangement. > Add missing `inline` in static header definition. > Drop ARM_SPE_ACPI and just use ARM_SPE_PMU. Tested on top of 5.2-rc1, I can see in the boot log: arm_spe_pmu arm,spe-v1: probed for CPUs 0-95 [max_record_sz 128, align 4, features 0x7] and I also tested perf record, and works as expected, Tested-by: Hanjun Guo Thanks Hanjun