+config ARM_CORESIGHT_PMU
+ tristate "ARM Coresight PMU"
+ depends on ARM64 && ACPI_APMT
There shouldn't be any functional dependency on any CPU architecture here.
The spec is targeted towards ARM based system, shouldn't we explicitly limit it to ARM?
+/*
+ * Write to 64-bit register as a pair of 32-bit registers.
+ *
+ * @val : 64-bit value to write.
+ * @base : base address of page-0 or page-1 if dual-page ext. is enabled.
+ * @offset : register offset.
+ *
+ */
+static void write_reg64_lohi(u64 val, void __iomem *base, u32 offset)
+{
+ u32 val_lo, val_hi;
+
+ val_hi = upper_32_bits(val);
+ val_lo = lower_32_bits(val);
+
+ write_reg32(val_lo, base, offset);
+ write_reg32(val_hi, base, offset + 4);
+}
#include <linux/io-64-nonatomic-lo-hi.h>
Thanks for pointing this out. We will replace it with lo_hi_writeq.
+static inline bool is_cycle_cntr_idx(const struct perf_event *event)CORESIGHT_PMU_IDX_CCNTR);
+{
+ struct coresight_pmu *coresight_pmu = to_coresight_pmu(event-
pmu);
+ int idx = event->hw.idx;
+
+ return (support_cc(coresight_pmu) && idx ==
If we don't support cycle counting, cycles count events should have been
rejected in event_init. If they're able to propagate further than that
Not sure I understand, do you mean the check for cycle counter support is unnecessary ?
This function is actually called by coresight_pmu_start, which is after event_init had passed.
coresight_pmu_start is not aware if cycle counter is supported or not, so we need to keep checking it.
+}
+
+bool coresight_pmu_is_cc_event(const struct perf_event *event)
+{
+ struct coresight_pmu *coresight_pmu = to_coresight_pmu(event-
pmu);
+ u32 evtype = coresight_pmu->impl.ops->event_type(event);
+
+ return (support_cc(coresight_pmu) &&
Ditto.
This function is called by event_init to validate the event and find available counters.
+ * This is the default event number for cycle count, if supported, since thecode
+ * ARM Coresight PMU specification does not define a standard event
+ * for cycle count.
+ */
+#define CORESIGHT_PMU_EVT_CYCLES_DEFAULT (0x1ULL << 31)
And what do we do when an implementation defines 0x80000000 as one of
its own event specifiers? The standard cycle count is independent of any
other events, so it needs to be encoded in a manner which is distinct
from *any* potentially-valid PMEVTYPER value.
We were thinking that in such case, the implementor would provide coresight_pmu_impl_ops.
To avoid it, I guess we can use config[32] for the default cycle count event id.
The filter value will need to be moved to config1[31:0].
Does it sound reasonable ?