Add support for PMU on SMP systems for ARM64

[gonzo]

Summary

Bind IRQs to respective CPU cores specified by interrupt-affinity parameter
of the PMU node in a DTS file.

Also add compat string for Cortex A53

Test Plan

Without this change pmcstat -TS INST_RETIRED -w1 makes system
unresponsive on RK3328-based SBC. With this change it functions
as expected.

[andrew]

sys/arm/arm/pmu.c

179–191

This should be in an FDT specific function. This code is also used on ACPI systems.

[br]

sys/arm/arm/pmu.c

190

This block does not fit 80 characters in width

[gonzo]

Fix all comments from reviewrs

[val_packett.cool]

sys/arm/arm/pmu.c

154

defined(FDT) is not really FDT-specific code, as FDT vs ACPI is a runtime decision. What would happen if node is NULL?

Please see D24423 — I have split out pmu_acpi and pmu_fdt there.

[gonzo]

sys/arm/arm/pmu.c

154

For this particular code it's OK. There is no ACPI support and if there is, like in your submitted patch, it's going to be different driver.

If node is null the code is going to proceed like there is no "interrupt-affinity" property. phandle_t is integer, not pointer, so 0 is treated as "invalid handle". Although for code readability I need to add handler for that case.

[andrew]

sys/arm/arm/pmu.c

154

There is D24423 to add ACPI support

[gonzo]

sys/arm/arm/pmu.c

154

Yes, Greg referenced it in his comment. But even with the patch in D24423 the ACPI code is in a different driver. I don't quite understand what's the objection to this code being conditionally-compiled.

[gonzo]

• Fix memory leak
• Handle error case

[mmel]

I think that we should fix this also for arm. Or at least we should use ‘compatible’ (with arm) way.
So if I can summarize actual status:

• PMU can have single PPI interrupt or multiple SPI interrupts (one for each core in given cluster).
• The driver must not expect that all cores are started (PSCI is free to not start a core)
• The system may have multiple PMUs (each cluster may have own - moreover with different type for big-little SoC).
• cpuid has no relation to the order of any property in DT. The only robust way how to identify right physical core is comparing its MPIDR register to expected value

With all this optimal interrupt binding algorithm looks for me as:

• The driver should read all interrupts resource in all cases
• The first resource shout be tested if is PPI, if is then we are done. *1
• The driver should read interrupt-affinity property and if exist the should read reg property from linked cpu property. If this fail, synthetic PMIDR should be constructed (this is the only case where the order within the interrupt property is important)
• the driver should iterate over all pcpus and compare stored MPIDR for getting right cupid. *2
• finally, interrupt should be binded to right cpuid.

ad 1 - We don’t have such call, but we can safely assume that if only one interrupt is defined then is PPI
ad 2 -Assuming that D13863 is applied

Please, take all this as my personal opinion, nothing more..