Skip to content

arm_pmu: ACPI support

Mark Rutland linux-arm-kernel 1 version New

Get series with b4
b4 am 20170315153420.GC9404@leverpostej

Versions newest first

  1. v1 Latest0 of 14 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 14 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 00/14] arm_pmu: ACPI support
Quoted 9 lines · Jeremy Linton
Quoted 8 lines · Mark Rutland

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

 $ taskset -c ${SOME_CPU_HERE} perf record \
   -e armv8_pmuv3_0/cpu_cycles/ \
   -e armv8_pmuv3_1/cpu_cycles/ \
   cat /proc/interrupts
Quoted 8 lines
Quoted 3 lines

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them. Although its quite possibly PEBCAK.

It looks like we've gotten to the bottom of the hang in the other thread; I had a go with a hack to bodge around that (as I have not yet upgraded the FW).

I had a go with the above taskset pattern (limited to a single PMU) on an APM Mustang board. Everything seems happy, even when I booted with maxcpus temporarily capped, where CPUs successfully associated themselves with the PMU later on.

Thanks,
Mark.

Read the cover letter in its thread