From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 41EB37E22E for ; Mon, 9 Apr 2018 07:08:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752483AbeDIHIH (ORCPT ); Mon, 9 Apr 2018 03:08:07 -0400 Received: from exmail.andestech.com ([59.124.169.137]:36905 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752196AbeDIHIH (ORCPT ); Mon, 9 Apr 2018 03:08:07 -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-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@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. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html