cv500 ISP IRQ routing: 'ISP' platform IRQ resolves to VI_PROC0 (~1/8 fps), not VI_CAP0 (per-frame)

[widgetii]

Sub-task of #176. Surfaced by @widgetii during validation of the stacked FEND-extension branch.

Observation

On hi3516av300 (cv500 family) with majestic actively streaming a ~21 fps sensor, `/proc/interrupts` shows:

```
MIPI_RX IRQ 43: 64371 ← per-frame (matches sensor rate)
VI_CAP0 IRQ 45: 49609 ← high-rate ISP capture IRQ
VI_PROC0 IRQ 46: 1464 ← ~33× slower than VI_CAP0
VPSS IRQ 47: 1464
```

The ISP IRQ resolved by `osal_platform_get_irq_byname(pdev, "ISP")` and consumed by `isp_isr()` in `kernel/isp/arch/hi3516cv500/mkp/src/isp.c` fires at the VI_PROC0 rate (~1.5 Hz with 21 fps streaming), not VI_CAP0's per-frame rate.

A FEND-event hook attached inside that ISR therefore emits at ~1/8 the sensor rate, not 1:1 with FS. Time-pair measurement on av300 confirmed:

```
=== 114 events in 5.00 s ===
MIPI_FS : 101 (20.2 fps)
ISP_FEND : 13 ( 2.6 fps) ← ~7.8× slower
```

Hypotheses

Either:

1. Wrong IRQ resolved by name. `osal_platform_get_irq_byname(pdev, "ISP")` may be picking VI_PROC0 instead of VI_CAP0 because of how the device-tree node enumerates its IRQs and the order in which the OSAL wrapper walks them. Verifiable by logging the resolved `isp_fe_irq` value at module init and cross-referencing `/proc/interrupts` indexes. If true: switch the lookup to VI_CAP0 by name (or by index, after auditing the DT binding).

2. ISP back-end stall. The hardware may legitimately emit FEND only for frames the back-end pipeline can actually accept (DMA-bound, write-channel-bound). In that case FEND really is "frame fully delivered to ISP back end" — a semantically valid event, just not what we want for capture→encode timing. We'd need a different IRQ source for the per-frame back-end-ready signal.

Definition of done

1. Identify which of (1) or (2) is the actual mechanism on cv500. Diagnostics: dump `isp_fe_irq` value at module load, dump full `/proc/interrupts` while streaming, correlate IRQ count growth with frame count from `MIPI_RX`.
2. If (1): patch the cv500 ISP driver to resolve VI_CAP0 (or equivalent per-frame IRQ) for the FEND hook.
3. If (2): document this and audit V4 (ev200/ev300) ISP to confirm the equivalent IRQ source there is per-frame; otherwise propose an alternative (e.g., piggyback on the VI driver's frame-done callback, or hook a different IP block).
4. Once a per-frame FEND IRQ is identified, verify the FEND event from openipc_frame_ts: expose encoder-done / ISP frame-end event for per-segment latency decomposition #176's stacked branch fires 1:1 with FS over a 60 s capture on av300.

Notes

• V4 (ev200/ev300) ISP IRQ topology may be cleaner — initial FEND-branch testing was only done on cv500. Worth checking V4 in parallel before deciding the design.
• The vendor SDK's own ISP IRQ handler dispatches both `VI_PT0_INT_FSTART` and back-end-related interrupts inside a single `ISP_ISR` entry; the per-IP-block IRQ assignment is what differs across SoCs.

[widgetii]

New data point — FEND emits zero events on both V4 and cv500

Cherry-picked the FEND extension (`a410a3b` from `widgetii:feat/openipc-frame-ts-fend`) onto current main (post-#155 merge) — clean cherry-pick, builds clean for both `hi3516ev300_lite` and `hi3516av300_lite`. ABI v2 (`event_type` field) works correctly via the sample tool.

End-to-end test with majestic running, 15 s capture, `-e 0x3` (FS + FEND both enabled):

Board	FS captured	FEND captured	`/proc/interrupts` VI_PROC0
hi3516ev300 (V4)	3015	0	206 Hz
hi3516av300 (cv500)	373	0	2.6 Hz

So FEND-emits-zero is broader than the original cv500 IRQ-routing question — it manifests on V4 too.

Root cause: `ISP_INT_FE_MASK` initialized to 0 by vendor ISP HAL

```
$ grep -n "ISP_INT_FE_MASK.=.0x0|ISP_INT_FE_MASK.\|" kernel/isp/arch//hal/isp_drv.c

hi3516ev200/hal/isp_drv.c:772: IO_RW_FE_ADDRESS(ViPipe, ISP_INT_FE_MASK) = (0x0);
hi3516cv500/hal/isp_drv.c:723: io_rw_fe_address(vi_pipe, ISP_INT_FE_MASK) = (0x0);
```

V4 has an OR'd unmask in `ISP_DRV_SetIntEnable(ViPipe, bEn=true)` at `kernel/isp/mkp/src/isp.c:169`:

```c
IO_RW_FE_ADDRESS(ViPipe, ISP_INT_FE_MASK) |= ISP_INT_FE_FSTART;
IO_RW_FE_ADDRESS(ViPipe, ISP_INT_FE_MASK) |= ISP_INT_FE_FEND;
```

…but this is only reachable from userspace via `ISP_SET_INT_ENABLE` ioctl, which majestic + the vendor MPI don't appear to call during normal streaming setup. So the mask stays at 0 and the FEND bit is filtered out of `isp_int_status` even when hardware sets the raw bit.

Implication for #176 / fixing FEND emission

Three plausible paths:

1. Force-unmask in our chrdev module init — at `openipc_ft_init()`, write `ISP_INT_FE_MASK |= ISP_INT_FE_FEND` per VI pipe. Couples the chrdev module to ISP register layout (cross-module dependency we deliberately avoided in Add openipc_frame_ts: sensor frame-start (PTS, CLOCK_REALTIME) chrdev #155). Worst pattern, ruled out.

2. Force-unmask in mipi_rx_drv_init — same problem; mipi_rx doesn't know about ISP registers.

3. Hook into vendor's ISP_DRV_SetIntEnable path — patch the vendor ISP module's init so that whenever it sets up a pipe for streaming, FEND is unmasked alongside whatever else the vendor enables. Per-SoC patch (V4 `kernel/isp/mkp/src/isp.c`, cv500 `kernel/isp/arch/hi3516cv500/mkp/src/isp.c`, cv200 has no FEND IRQ surface). This is the cleanest layering but the SOC-specific reach widens substantially compared to Add openipc_frame_ts: sensor frame-start (PTS, CLOCK_REALTIME) chrdev #155.

Plus the W1C semantics question — once FEND is unmasked, does the IRQ handler clear the bit each time (so it can re-assert next frame) or does it stay asserted causing an IRQ storm? Need to read the vendor ISP IRQ handler carefully to determine where the FEND raw bit gets cleared.

Next steps recommendation

This is multiple-days of investigation per SoC family, not the "small reviewer-stacked-branch + ship" we hoped. Suggest:

1. Keep the cherry-picked branch local for now; don't open a PR with broken FEND emission.
2. Spike (a) the ISP_DRV_SetIntEnable invocation path during majestic startup to understand why bEn=true isn't being passed for FEND, and (b) the W1C / raw-bit-clear flow in the existing IRQ handler. That tells us whether option 3 is safe.
3. Until FEND emission works on at least V4, the userspace consumer (widgetii/majestic#83's RTCP SR path) gets nothing new from FEND, so deferring it doesn't block PixelPilot-style robotics use cases.

Closing this loop: #155 is shippable as-is via firmware bump; #176 is blocked on the further ISP investigation above.

[widgetii]

Resolved by #199. The FEND IRQ routing concern (FEND firing at ~1/8 frame rate) was a symptom of kernel/isp/arch/hi3516cv500/mkp/src/isp.c reading FEND from a path that wasn't 1:1 with sensor frames. #199 moved the hook to isp_raw_int & ISP_INT_FE_FSTART/_FEND inside the existing isp_drv_int_status_process() — same handler that runs on VI_CAP0 (the per-frame FE IRQ).

Verified on openipc-hi3516av300.dlab.torturelabs.com (cv500 / IMX415, ~22 fps streaming) — 60 s capture from /dev/openipc-frame-ts:

total events = 2679
  MIPI_FS  = 1339  (22.3/s)  chn=0, seq gap = {1}, monotonic = True
  ISP_FEND = 1340  (22.3/s)  chn=0, seq gap = {1}, monotonic = True
FS→FEND pairing: mean -18.15 ms (-18.45 to -17.98 ms range)

/proc/interrupts delta over the same 60 s:

MIPI_RX  IRQ 43: +0    (0 → 0, no MIPI controller IRQ involvement post-#199)
VI_CAP0  IRQ 45: +2450 (40.8 / s = 2× frame rate, FSTART + FEND alternating)
VI_PROC0 IRQ 46: +1225 (20.4 / s = 1× frame rate)

So FEND now fires 1:1 with MIPI_FS over a full 60 s capture (the original DoD on this issue), at the actual sensor frame rate.