Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965610AbcKJTq6 (ORCPT ); Thu, 10 Nov 2016 14:46:58 -0500 Received: from foss.arm.com ([217.140.101.70]:58046 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965165AbcKJTq5 (ORCPT ); Thu, 10 Nov 2016 14:46:57 -0500 Date: Thu, 10 Nov 2016 19:46:59 +0000 From: Will Deacon To: Mark Rutland Cc: Jan Glauber , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 1/5] arm64: perf: Basic uncore counter support for Cavium ThunderX SOC Message-ID: <20161110194659.GD17134@arm.com> References: <73173d6ad2430eead5e9da40564a90a60961b6d9.1477741719.git.jglauber@cavium.com> <20161110165405.GH4418@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161110165405.GH4418@leverpostej> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1433 Lines: 31 On Thu, Nov 10, 2016 at 04:54:06PM +0000, Mark Rutland wrote: > On Sat, Oct 29, 2016 at 01:55:29PM +0200, Jan Glauber wrote: > > diff --git a/drivers/perf/uncore/uncore_cavium.c b/drivers/perf/uncore/uncore_cavium.c > > new file mode 100644 > > index 0000000..a7b4277 > > --- /dev/null > > +++ b/drivers/perf/uncore/uncore_cavium.c > > + * Some notes about the various counters supported by this "uncore" PMU > > + * and the design: > > + * > > + * All counters are 64 bit long. > > + * There are no overflow interrupts. > > + * Counters are summarized per node/socket. > > + * Most devices appear as separate PCI devices per socket with the exception > > + * of OCX TLK which appears as one PCI device per socket and contains several > > + * units with counters that are merged. > > As a general note, as I commented on the QC L2 PMU driver [1,2], we need > to figure out if we should be aggregating physical PMUs or not. > > Judging by subsequent patches, each unit has individual counters and > controls, and thus we cannot atomically read/write counters or controls > across them. As such, I do not think we should aggregate them, and > should expose them separately to userspace. I thought each unit was registered as a separate PMU to perf? Or are you specifically commenting on the OCX TLK? The comment there suggests that the units cannot be individually enabled/disabled and, without docs, I trust that's the case. Will