Received: by 10.213.65.68 with SMTP id h4csp2275218imn; Mon, 9 Apr 2018 00:11:09 -0700 (PDT) X-Google-Smtp-Source: AIpwx48I9/F8P4Ssf10X+aw6Z7reI/ypvszYzEodju030ZRElbrW6CXNWaL3wvs4yYSPSvNOru8j X-Received: by 2002:a17:902:20ca:: with SMTP id v10-v6mr38364570plg.9.1523257869555; Mon, 09 Apr 2018 00:11:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523257869; cv=none; d=google.com; s=arc-20160816; b=L8Xl1CrGSokhP+ti1pyXbKOqo17/DtSUT+nCswpBq6MbC3/nh7Xy2zGK3FZjPWKNBs RiLLZtEzk+flFgGfcLqS/W6E74sEmZ0uPjTuapTy+viarm+Fz2GANyQSaPpJ8uzJhsAS xiP8rLsG7UFo7wJQGs80NxP0f87hObXeTvjy+s7ZGRXTFzaXWcbQ7ax01ZINAFMxS5GO rorL1g6lEysruN5NGqWp1S9TmbH5sDgITZccFeP+mc1qxsh45LdMdB+9Cj+WW48eIIew 9ldb8RcApqkECU2DXkCb3A4gwt23TZuORkHkAl4T9LwRn3R7+W58zbqIqX+Y7kRbQRCZ IC3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=jKd07ON5kOoik9yg1IFP1Y/Lpx+Ha1/6cxkunhAQnIQ=; b=jDHKvvK+EYv4c7nxv9v5prF0ezXvhRTA/jl+pgTt5wbcbIAXU/oS3D014hjrJyXuYt jcQZK0oduC4qCJ4SRXz0FVGq892ro+S0t/4/daby+3ZaSXuuq1r/5dsz3n9B9jyn00YG O+vkfq19/qBkSLo4Qi7lsb66TXKc/a/0UUW3WeePkLBiaTi5gt0hHWRPJeOAvYv/jIpd Q65c/Po2/MkqbqPyFyuaS1EHqfc2EyJSJ1qxcCz3m72AuuVmZSZCwCMgaVEyG3Pab9H+ WOYJF+G+IhAZVBj+v+RwSseEdbLaFexrCK7kF+PKpFlFD9Jt7pqy++qD0FKmDE1ChmCa cTTg== 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 n16-v6si13862694pll.66.2018.04.09.00.10.32; Mon, 09 Apr 2018 00:11:09 -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 S1752376AbeDIHHU (ORCPT + 99 others); Mon, 9 Apr 2018 03:07:20 -0400 Received: from exmail.andestech.com ([59.124.169.137]:27704 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbeDIHHT (ORCPT ); Mon, 9 Apr 2018 03:07:19 -0400 Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id w3971XTH047779; Mon, 9 Apr 2018 15:01:33 +0800 (GMT-8) (envelope-from alankao@andestech.com) Received: from andestech.com (10.0.1.85) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.123.3; Mon, 9 Apr 2018 15:07:11 +0800 Date: Mon, 9 Apr 2018 15:07:11 +0800 From: Alan Kao To: Palmer Dabbelt CC: , , , , , , , , , , , , , Subject: Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support Message-ID: <20180409070710.GA3844@andestech.com> References: <1522051075-6442-2-git-send-email-alankao@andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.0.1.85] X-DNSRBL: X-MAIL: ATCSQR.andestech.com w3971XTH047779 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 05, 2018 at 09:47:50AM -0700, Palmer Dabbelt wrote: > On Mon, 26 Mar 2018 00:57:54 PDT (-0700), alankao@andestech.com wrote: > >This patch provide a basic PMU, riscv_base_pmu, which supports two > >general hardware event, instructions and cycles. Furthermore, this > >PMU serves as a reference implementation to ease the portings in > >the future. > > > >riscv_base_pmu should be able to run on any RISC-V machine that > >conforms to the Priv-Spec. Note that the latest qemu model hasn't > >fully support a proper behavior of Priv-Spec 1.10 yet, but work > >around should be easy with very small fixes. Please check > >https://github.com/riscv/riscv-qemu/pull/115 for future updates. > > > >Cc: Nick Hu > >Cc: Greentime Hu > >Signed-off-by: Alan Kao > > We should really be able to detect PMU types at runtime (via a device tree > entry) rather than requiring that a single PMU is built in to the kernel. > This will require a handful of modifications to how this patch works, which > I'll try to list below. > >+menu "PMU type" > >+ depends on PERF_EVENTS > >+ > >+config RISCV_BASE_PMU > >+ bool "Base Performance Monitoring Unit" > >+ def_bool y > >+ help > >+ A base PMU that serves as a reference implementation and has limited > >+ feature of perf. > >+ > >+endmenu > >+ > > Rather than a menu where a single PMU can be selected, there should be > options to enable or disable support for each PMU type -- this is just like > how all our other drivers work. > I see. Sure. The descriptions and implementation will be refined in v3. > >+struct pmu * __weak __init riscv_init_platform_pmu(void) > >+{ > >+ riscv_pmu = &riscv_base_pmu; > >+ return riscv_pmu->pmu; > >+} > > Rather than relying on a weak symbol that gets overridden by other PMU > types, this should look through the device tree for a compatible PMU (in the > case of just the base PMU it could be any RISC-V hart) and install a PMU > handler for it. There'd probably be some sort of priority scheme here, like > there are for other driver subsystems, where we'd pick the best PMU driver > that's compatible with the PMUs on every hart. > > >+ > >+int __init init_hw_perf_events(void) > >+{ > >+ struct pmu *pmu = riscv_init_platform_pmu(); > >+ > >+ perf_irq = NULL; > >+ perf_pmu_register(pmu, "cpu", PERF_TYPE_RAW); > >+ return 0; > >+} > >+arch_initcall(init_hw_perf_events); > > Since we only have a single PMU type right now this isn't critical to handle > right away, but we will have to refactor this before adding another PMU. I see. My rough plan is to do the device tree parsing here, and if no specific PMU string is found then just register the base PMU proposed in this patch. How about this idea? Thanks.