Received: by 10.223.185.116 with SMTP id b49csp214962wrg; Thu, 8 Mar 2018 16:01:35 -0800 (PST) X-Google-Smtp-Source: AG47ELucm/buGAXW+JEoL7JqIjLAEU70BT2C6HQsslXHcmq1/quakSOWn7cMHVPFqBzxtfaQ8qsT X-Received: by 10.101.73.197 with SMTP id t5mr22886348pgs.426.1520553695649; Thu, 08 Mar 2018 16:01:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520553695; cv=none; d=google.com; s=arc-20160816; b=Ee9ePUCW4m5H/wveT4OKAmx0zN7Jhg9BbM/BLbjJJQHvkehBQEEZxIRl79/zWTe/Xm xlf1JAHG8Z3wLHKvrOCMQjxwCj0sIAdxe97wQzB9avaC2KRLpt2jDAbfUwSpEVjRnC5F kCF/RVnE8rJSCh4c4CupXVpvTWtR8wOVo2c7yRgfD2XoZBFJGfaO36GQ296pWTyCfsMo CRHNFpLqjrBg1WGQH25OUosUJ8ToGlBVaBf5Vq7y226MCqlstFPv/sA6G8jCiQwXAxRD 19lygoStwr0ZWH27Kz5O6vvLryGzeEBt7qUGQ7OoBWp8SoLBjgmN3p8Ef5kEGK9pZK3l l8fQ== 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:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=vgguGmY7x6325NNeaLcqA8hiRFhxy37HesUkM3l8Y/Y=; b=LFanAX3Ux2VTDGK40Br9TtRLx9Ih0dBGVJeMaHl5G8QL2/veJxnMqaIF9h8HF1l3Rs NwypLFeFDSCgr4vdnNmg92VJ2m64bi0g+PIWxPre7aGIcPhbCw72Uu70ABmhJLAVkn4V obt4CQqhvyNKZgxcQoiKcohMlinQZwFL2tpfdGFNpM/jwWsgOopx5Bwq8dn9mBX3K55j wCEqs8uayg8/tEZO9aN2cZzbehF9tW+2OIrbqlbIqLzgHtOnX2C1lDtQXfzmi2ZYq/jZ U0RXxXyRmK01mJNAh9iH13FsNZRVRvbEL0tf9ZgO3kUxZT4oA8ijUKcSogu+e0a5wXZ0 pcuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=oFE7n1UJ; dkim=pass header.i=@codeaurora.org header.s=default header.b=A8suUNUK; 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 y15si12369967pfb.346.2018.03.08.16.01.18; Thu, 08 Mar 2018 16:01:35 -0800 (PST) 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; dkim=pass header.i=@codeaurora.org header.s=default header.b=oFE7n1UJ; dkim=pass header.i=@codeaurora.org header.s=default header.b=A8suUNUK; 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 S1751315AbeCHX7I (ORCPT + 99 others); Thu, 8 Mar 2018 18:59:08 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:49564 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750824AbeCHX7H (ORCPT ); Thu, 8 Mar 2018 18:59:07 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id E61F1601D2; Thu, 8 Mar 2018 23:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520553546; bh=3iXOj6WFIBBtwqNjD6YFiyWddkbBZ+NZRPG5pIx7Y9Y=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=oFE7n1UJ38GQwu+YNia0qyWqAW7q6kl02xy19L49JVeDze3YNntlqaTi1tevxPEuD LkTx/OnPMvfTE6NXuFxptMJ83K7L0GwdT9K0ekzdJzv7y1GEwlfTG7vKApJPRJYZtl IUPF3xwyHdhJRsEDhIV5gE8ByqbAiY8moRO6adXI= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.134.64.210] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: skannan@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id DB7ED601D2; Thu, 8 Mar 2018 23:59:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520553545; bh=3iXOj6WFIBBtwqNjD6YFiyWddkbBZ+NZRPG5pIx7Y9Y=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=A8suUNUKe2YlHPP3HSYnrbh+fa8Pl2ReCSk5GjaZKItl74i1gW9Ajk2owepx1SO/r vE44GfWJQNGRh/tpGcK9KyU44GsiWUjH6YbBOO5hxKdPp3LBQuNEDtuVMkeCtOyjX9 qPLf13OZTsJgShtG2uKysDmKy3j7zJp2Vj1FohYM= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org DB7ED601D2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=skannan@codeaurora.org Message-ID: <5AA1CE48.5030203@codeaurora.org> Date: Thu, 08 Mar 2018 15:59:04 -0800 From: Saravana Kannan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Suzuki K Poulose CC: will.deacon@arm.com, mark.rutland@arm.com, robh@kernel.org, sudeep.holla@arm.com, mathieu.poirier@linaro.org, peterz@infradead.org, jonathan.cameron@huawei.com, linux-kernel@vger.kernel.org, marc.zyngier@arm.com, leo.yan@linaro.org, frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org, rananta@codeaurora.org, avilaj@codeaurora.org Subject: Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support References: <20180102112533.13640-1-suzuki.poulose@arm.com> <20180102112533.13640-9-suzuki.poulose@arm.com> In-Reply-To: <20180102112533.13640-9-suzuki.poulose@arm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: > Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). > The DSU integrates one or more cores with an L3 memory system, control > logic, and external interfaces to form a multicore cluster. The PMU > allows counting the various events related to L3, SCU etc, along with > providing a cycle counter. > > The PMU can be accessed via system registers, which are common > to the cores in the same cluster. The PMU registers follow the > semantics of the ARMv8 PMU, mostly, with the exception that > the counters record the cluster wide events. > > This driver is mostly based on the ARMv8 and CCI PMU drivers. > The driver only supports ARM64 at the moment. It can be extended > to support ARM32 by providing register accessors like we do in > arch/arm64/include/arm_dsu_pmu.h. > > Cc: Mark Rutland > Cc: Will Deacon > Reviewed-by: Jonathan Cameron > Reviewed-by: Mark Rutland > Signed-off-by: Suzuki K Poulose > --- > Changes since V9: > - Rely on cpuhp callback for probing the PMU. > - Clear the overflow mask whenever the first CPU is brought up. > - Remove dsu_pmu_get_online_cpu(), which is not needed anymore. > - Flip the order of context migration and setting the active CPU. > > Changes since V8: > - Include required header files (Mark Rutland) > - Remove Kconfig dependency on PERF_EVENTS (Mark Rutland) > - Fix typo in event name, bus_acesss => bus_access (Mark Rutland) > - Use find_first_zero_bit instead of find_next_zero_bit (Mark Rutland) > - Change order of checks in dsu_pmu_event_init (Mark Rutland) > - Allow lazy initialisation of DSU PMU to handle cases where CPUs > may be brought up later (e.g, maxcpus=N)- Mark Rutland. > - Clear the interrupt overflow status upon initialisation (Mark Rutland) > - Change the CPU check to "associated_cpus" from "active_cpus", > as when we migrate the perf context we will access the DSU > from two different CPUs (source and destination). > - Fill in the "module" field for the PMU to prevent the module unload > when the PMU is active. > Changes since V6: > - Address comments from Jonathan > - Add Reviewed-by tags from Jonathan > Changes since V5: > - Address comments on V5 by Mark. > - Use IRQ_NOBALANCING for IRQ handler > - Don't expose events which could be unimplemented. > - Get rid of dsu_pmu_event_supported and allow raw event > code to be used without validating whether it is supported. > - Rename "supported_cpus" mask to "associated_cpus" > - Add Documentation for the PMU driver > - Don't disable IRQ for dsu_pmu_{enable/disable}_counters > - Use consistent return codes for validate_event/group calls. > - Check PERF_ATTACH_TASK flag in event_init. > - Allow missing CPUs in dsu_pmu_dt_get_cpus, to handle cases > where kernel could have capped nr_cpus. > - Cleanup sanity checking for the CPU before accessing DSU > - Reject events with counting CPU not associated with the DSU. > Changes since V4: > - Reflect the changed generic helper for mapping CPU id > Changes since V2: > - Cleanup dsu_pmu_device_probe error handling. > - Fix event validate_group to invert the result check of validate_event > - Return errors if we failed to parse CPUs in the DSU. > - Add MODULE_DEVICE_TABLE entry > - Use hlist_entry_safe for converting cpuhp_node to dsu_pmu. > --- > Documentation/perf/arm_dsu_pmu.txt | 28 ++ > arch/arm64/include/asm/arm_dsu_pmu.h | 129 ++++++ > drivers/perf/Kconfig | 9 + > drivers/perf/Makefile | 1 + > drivers/perf/arm_dsu_pmu.c | 843 +++++++++++++++++++++++++++++++++++ > 5 files changed, 1010 insertions(+) > create mode 100644 Documentation/perf/arm_dsu_pmu.txt > create mode 100644 arch/arm64/include/asm/arm_dsu_pmu.h > create mode 100644 drivers/perf/arm_dsu_pmu.c > Looking at the code, I didn't see any specific handling of cluster power collapse. AFAIK, the HW counters do not retain config (what event they are counting) or value (the current count) across power collapse. Wouldn't you need to register for some kind of PM_ENTER/EXIT notifiers to handle that? Thanks, Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project