Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752121AbdGZOfb (ORCPT ); Wed, 26 Jul 2017 10:35:31 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33764 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751606AbdGZOf2 (ORCPT ); Wed, 26 Jul 2017 10:35:28 -0400 Subject: Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters To: Jan Glauber , bp@alien8.de References: <20170725150422.4775-1-jglauber@cavium.com> <20170725150422.4775-2-jglauber@cavium.com> <72145781-e9ec-036f-f752-b4756fef08ee@arm.com> <20170726111946.GA6273@hc> <20170726131058.GA8665@hc> Cc: Mark Rutland , Will Deacon , linux-arm-kernel@lists.infradead.org, "linux-kernel@vger.kernel.org" From: Suzuki K Poulose Message-ID: <131179fe-42e7-f286-5bd4-801f4c93d5f9@arm.com> Date: Wed, 26 Jul 2017 15:35:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170726131058.GA8665@hc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3225 Lines: 80 +To: Boris Hi Boris, On 26/07/17 14:10, Jan Glauber wrote: > On Wed, Jul 26, 2017 at 01:47:35PM +0100, Suzuki K Poulose wrote: >> On 26/07/17 12:19, Jan Glauber wrote: >>> On Tue, Jul 25, 2017 at 04:39:18PM +0100, Suzuki K Poulose wrote: >>>> On 25/07/17 16:04, Jan Glauber wrote: >>>>> Add support for the PMU counters on Cavium SOC memory controllers. >>>>> >>>>> This patch also adds generic functions to allow supporting more >>>>> devices with PMU counters. >>>>> >>>>> Properties of the LMC PMU counters: >>>>> - not stoppable >>>>> - fixed purpose >>>>> - read-only >>>>> - one PCI device per memory controller >>>>> >>>>> Signed-off-by: Jan Glauber >>>>> --- >>>>> drivers/perf/Kconfig | 8 + >>>>> drivers/perf/Makefile | 1 + >>>>> drivers/perf/cavium_pmu.c | 424 +++++++++++++++++++++++++++++++++++++++++++++ >>>>> include/linux/cpuhotplug.h | 1 + >>>>> 4 files changed, 434 insertions(+) >>>>> create mode 100644 drivers/perf/cavium_pmu.c >>>>> >>>>> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig >>>>> index e5197ff..a46c3f0 100644 >>>>> --- a/drivers/perf/Kconfig >>>>> +++ b/drivers/perf/Kconfig >>>>> @@ -43,4 +43,12 @@ config XGENE_PMU >>>>> help >>>>> Say y if you want to use APM X-Gene SoC performance monitors. >>>>> >>>>> +config CAVIUM_PMU >>>>> + bool "Cavium SOC PMU" >>>> >>>> Is there any specific reason why this can't be built as a module ? >>> >>> Yes. I don't know how to load the module automatically. I can't make it >>> a pci driver as the EDAC driver "owns" the device (and having two >>> drivers for one device wont work as far as I know). I tried to hook >>> into the EDAC driver but the EDAC maintainer was not overly welcoming >>> that approach. >> >>> >>> And while it would be possible to have it a s a module I think it is of >>> no use if it requires manualy loading. But maybe there is a simple >>> solution I'm missing here? >> >> >> If you are talking about a Cavium specific EDAC driver, may be we could >> make that depend on this driver "at runtime" via symbols (may be even, >> trigger the probe of PMU), which will be referenced only when CONFIG_CAVIUM_PMU >> is defined. It is not the perfect solution, but that should do the trick. > > I think that is roughly what I proposed in v6. Can you have a look at: > > https://lkml.org/lkml/2017/6/23/333 > https://patchwork.kernel.org/patch/9806427/ So the Cavium EDACs, which appear as PCI devices have a PMU attached to it. In order to build this PMU driver as a module, we need a way to load the module automatically based on the PCI id. However, since the EDAC driver already registers with that PCI id, we cannot use the same for the PMU. Ideally, the PMU driver should be loaded when the EDAC driver is loaded. But looking at the links above, it looks like you don't like the idea of triggering a probe of the PMU component from the EDAC driver. We may be able to get rid of the PMU specific information from the EDAC driver by maintaining the PCI id of the device in the PMU driver. But we may still need to make sure that the PMU driver gets a chance to probe the PMU when the device is available. What do you think is the best option here ? Suzuki