[PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

-----Original Message-----
From: Robin Murphy [mailto:robin.murphy at arm.com]
Sent: 02 October 2018 17:35
To: Jean-Philippe Brucker <redacted>; Shameerali
Kolothum Thodi [off-list ref];
lorenzo.pieralisi at arm.com
Cc: mark.rutland at arm.com; vkilari at codeaurora.org;
neil.m.leeder at gmail.com; pabba at codeaurora.org; John Garry
[off-list ref]; will.deacon at arm.com; rruigrok at codeaurora.org;
Linuxarm [off-list ref]; linux-acpi at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Guohanjun (Hanjun Guo)
[off-list ref]; linux-kernel at vger.kernel.org
Subject: Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

On 02/10/18 17:19, Jean-Philippe Brucker wrote:

quoted

On 02/10/2018 15:11, Jean-Philippe Brucker wrote:

quoted

quoted

+	cfgr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_CFGR);

Something I missed previously: when SMMU_PMCG_CFGR.SID_FILTER_TYPE

is 1,

quoted

filtering for all counters is configured by SMMU_PMCG_SMR0 and
SMMU_PMCG_EVTYPER0 (instead of having one separate filter per counter).

Oh, I hadn't even noticed it had that mode as well...

Thanks Jean. Missed that completely. 
 

quoted

In that mode with your patch, if the user applies a filter to the first
event in the list passed to perf, it will be applied to all events.
Filter applied on any subsequent event will be ignored. Could we make
this more explicit? Maybe in the probe print that the PMCG is
global-filtering, and when attempting to apply a filter to something
else than EVCNTR0, return an error?

FWIW filtering is always per-counter-group on the SMMUv2 PMU, and it's
actually pretty straightforward to cope with - pmu->add() just needs to
reject the event if one with an incompatible configuration is already
scheduled, so perf core handles it much like having more events than
counters, by rotating the mutually-exclusive sets.

I will take a look and address this in next version.

Thanks,
Shameer