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
