Use CCNT cycle counter for get_cyclecount() where available.

[bz]

Summary

Now that the PMU implementation is independent of HWPMC
as of r288992 use it to manage the CCNT.

Use the CNNT for get_cyclecount() instead of
binuptime() when device pmu is compiled in.

Enable by default for the BeagleBoneBlack configuration.

Optained from: Cambridge/L41
Sponsored by: DARPA/AFRL

We'll add DTrace as another downstream consumer later.
We'll also cleanup HWPMC to not manage this interrupt
anymore but just use the function.

[bz]

Whitespace nits I'll fix before committing.

sys/arm/arm/pmu.c

213

Needs an extra leading whitespace.

sys/arm/include/cpu.h

22

Should be

>= 6

in the comment

[andrew]

There should be a warning in the code that the some SoC vendors place an or gate over the per-cpu interrupts so we may only receive it on one core. It would be nice if we could detect this, but the detection can be left to a future commit.

sys/arm/include/cpu.h

27

Should we keep the old armv6 code when the pmu driver is missing?

How will this work id the pmu driver doesn't attach?

[mmel]

The only one "major" consumer of get_cyclecount() is KTR (and random, of course). Unfortunately, exposing per core unsynchronized counter to it breaks its usability. Actually, is impossible to track time in KTR dumps on SMP ARM systems. So real questions is: is per core PMU counter usable cyclecount source?

sys/arm/arm/pmu.c

99

static ?

185

I think we are missing initialization PMCR.D. Also, both registers must be initialized also on AP cores.

208

CCNT runs on CPU (or CPU/64) clock. CPU speed can be changed at any time. And if SoC uses DVFS then is dynamic. So calibration doesn't look useful to me.

[bz]

Counter questions and comments.

sys/arm/arm/pmu.c

99

Use from cpu.h and ccnt_freq will be used from Dtrace so, no (with some planning ahead).

208

Can you point me at some documentation source for this? If the speed is "dynamic" CCNT is more or less useless for almost anything but random, right?

sys/arm/include/cpu.h

27

For armv6 __ARM_ARCH == 6 we do what we did so far.

If DEV_PMU is compiled in and doesn't attach then this won't be reliable either. Not sure how to "cheaply" fix that issue apart from putting a panic into pmu.c. I am more interested in the above comment about frequency to be sorted first.

[mmel]

sys/arm/arm/pmu.c

208

• CCNT counts processor clock cycles ( B4.1.113 ), so it runs on CPU frequency.
• It can be stopped (or slowdown) in WFI/WFE mode ( C12.1.5 ).
• On some SoC, CPU cores can be clocked independently
• If SoC have implemented DVFS (dynamic voltage and frequency scaling), then CPU frequency is changed on demand ("continuously"), per core or per cluster
• CPU frequency can be also changed by user (or by powerd)

I'm not sure what Dtrace needs, CCNT is still useful from performance monitoring point of view, but you must use CPU cycle count as base measurement unit. On other hand, CCNT is not (and cannot) be related to real time.

I don't want to block anything. Just, please, take the above information into account.

All references are from current ARM ARM (ARM DDI 0406C.c)

[bz]

Removed the scaling.
Added the fallback (as discussed with Andrew) in case PMU fails to attach.
Addressed the whitespace issues (hopefully).

[andrew]

sys/arm/arm/pmu.c

180–181

This looks odd, using err for the iterator.