Lines Matching +full:interrupt +full:- +full:counter
2 Supporting PMUs on RISC-V platforms
8 ------------
10 As of this writing, perf_event-related features mentioned in The RISC-V ISA
23 Counters are just free-running all the time in our case.
24 * Interrupt caused by counter overflow
26 * Interrupt indicator
27 It is not possible to have many interrupt ports for all counters, so an
28 interrupt indicator is required for software to tell which counter has
33 hardware-extension for M-S-U model machines to write counters directly.
44 -----------------
47 various methods according to perf's internal convention and PMU-specific
53 the minimal and already-implemented logic can be leveraged, or invent his/her
63 -----------------------
72 into bitmap, so that HW-related control registers or counters can directly be
78 (1) interrupt setting, which is stated in the next section;
81 (4) tweaks for non-sampling events, which will be utilized by functions such as
85 hwc->sample_period = x86_pmu.max_period;
86 hwc->last_period = hwc->sample_period;
87 local64_set(&hwc->period_left, hwc->sample_period);
93 3. Interrupt
94 ------------
96 3.1. Interrupt Initialization
109 err = -EBUSY;
128 It does NOT deal with the binding between an event and a physical counter,
135 for each hardware counter that triggered this overflow
137 get the event of this counter
141 count the delta value since previous interrupt
142 update the event->count (# event occurs) by adding delta, and
143 event->hw.period_left by subtracting delta
147 set the counter appropriately for the next overflow
156 However as of this writing, none of the RISC-V implementations have designed an
157 interrupt for perf, so the details are to be completed in the future.
160 ---------------------------
165 counter (event->count), but also updates the left period to the next interrupt
166 (event->hw.period_left).
169 is hidden behind the abstraction of 1) *pmu->start*, literally start counting so one
170 has to set the counter to a good value for the next interrupt; 2) inside the IRQ
171 it should set the counter to the same resonable value.
173 Reading is not a problem in RISC-V but writing would need some effort, since
174 counters are not allowed to be written by S-mode.
178 -----------------------------
181 starts/stop the counter of some event in the PMU. All of them take the same
186 Three states (event->hw.state) are defined:
188 * PERF_HES_STOPPED: the counter is stopped
189 * PERF_HES_UPTODATE: the event->count is up-to-date
190 * PERF_HES_ARCH: arch-dependent usage ... we don't need this for now
195 * When being context-switched in, *add* is called by the perf core, with a flag
197 At this stage, a general event is bound to a physical counter, if any.
201 - *start* is then called, and the counter is enabled.
202 With flag PERF_EF_RELOAD, it writes an appropriate value to the counter (check
208 * When being context-switched out, *del* is called. It then checks out all the
211 - *stop* is called by *del*
216 - Life cycle of these two pairs: *add* and *del* are called repeatedly as
217 tasks switch in-and-out; *start* and *stop* is also called when the perf core
218 needs a quick stop-and-start, for instance, when the interrupt period is being
225 ---------------------
230 Both structures are designed to be read-only.
236 *struct riscv_pmu* defines PMU-specific parameters. The naming follows the
242 The generic structure that represents perf events, and the hardware-related
251 ----------
253 [1] https://github.com/riscv/riscv-linux/pull/124
255 [2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/f19TmCNP6yA