[PATCH 2/2] perf: Add Arm CMN-600 PMU driver

[John Garry]

>>
>> I had a quick look at the TRM (nearly 1000 pages, wow) for this IP, 
>> and could not see anything obvious to know the implementation id 
>> (similar problem to SMMU PMCG today). Do you know if there is anything 
>> appropiate? Is por_hnf_ppu_iidr any use here?
> 
> Note that PPU is a distinct thing with its own architecture (apparently 
> https://developer.arm.com/documentation/den0051/latest/ if you're 
> interested), so that particular IIDR is merely describing the 
> implementation of the PPU interface, which AFAICS is not necessarily 
> unique to CMN-600. In terms of the PMU and CMN overall there is no 
> architecture to speak of, the implementation just is what it is :)
> 
> I'd expect that some future interconnect IPs are likely to be similar 
> enough to share most of this driver, but those should get their own 
> top-level compatibles since they will not be CMN-600. Thus I don't 
> believe that identification is going to be too much of a concern.
> 
>> Just a couple of more questions for now...
>>
>> [snip]
>>
>>> +
>>> +static struct attribute *arm_cmn_event_attrs[] = {
>>> +    CMN_EVENT_DTC(cycles),
>>> +

[...]

>>> +
>>> +    NULL
>>> +};
>>
>> Just wondering how does "perf list" look when you have multiple 
>> instances of the device in the system?
> 
> Probably a giant mess, since I assume every (relevant) event should be 
> listed for each instance, much like CPU events on big.LITTLE systems, 
> and uncore events on many others (certainly most of the xgene_pmu events 
> on my eMAG workstation are repeated up to 8 times).

Yeah, so that's one thing we would solve with my "system PMU" perf 
support, such that we can have a single per-event alias listed for 
instances of that PMU.

So out of curiousity, for the big.LITTLE systems which you have seen 
with this issue, which cores do they have?

> 
>> [snip]

>>> +    };
>>> +
>>> +    if (atomic_fetch_inc(&id) == 0) {
>>> +        name = "arm_cmn";
>>> +    } else {
>>> +        name = devm_kasprintf(cmn->dev, GFP_KERNEL, "arm_cmn_%d", 
>>> atomic_read(&id));
>>
>> How is userspace supposed to know which device is which when we have 
>> multiple instances? I mean, doesn't this depend on arbitary probe 
>> ordering?
> 
> Right, I had it in my head that there should be enough information in 
> sysfs to link the PMU device back to its parent platform device, but 
> apparently that isn't the case :(
> 
> Furthermore, you've now got me thinking I might want to rejig the naming 
> scheme anyway - if I did have two instances named "foo" and "foo_1", is 
> perf tool going to interpret "-e foo/event/" as specifying a common 
> prefix and create the event on both PMUs even if I only wanted it on the 
> first one?

It should just create the event on the PMU "foo", and not also "foo_1". 
I think.

As for naming, as you know, for the SMMUv3 PMU driver we suffixed the HW 
base register address for the name - not ideal, but at least which PMU 
is which can be determined from userspace. Or for this driver case, 
maybe ACPI _UID could be used instead.

Thanks,
john