DRAM FREQUENCY CONTROLLER (dmc devfreq) - Board A

We spent significant time on the hypothesis that DRAM frequency switching caused
the corruption. We were wrong. This file is the evidence that killed it.

=== live state ===
governor:                  performance
cur_freq:                  2112000000
available_frequencies:     528000000 1068000000 1560000000 2112000000
available_governors:       rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand

=== transitions since boot (trans_stat, last line) ===
Total transition : 2

=== device tree ===
compatible: rockchip,rk3588-dmc
status    : okay

=== WHAT WE MEASURED ===

RETRACTED CLAIM: that pinning the dmc governor to "performance" stops the corruption.

The original A/B was confounded by TIME. It compared "inside the fault window, governor
unpinned" against "after the fault window, governor pinned". The fault is time-clustered,
so the pin took credit for the window closing on its own.

Re-run properly on the stock dmc_ondemand governor:

  87 iterations, 10,975 DRAM frequency transitions counted   ->  ZERO faults
  120 iterations total on the stock governor                 ->  ZERO faults
  180 consecutive clean runs since the fault window closed

And from the opposite direction - the HEALTHY control board switches MORE, not less:

  control board (has never corrupted anything) : 99,492 transitions
  Board A       (corrupts)                     : 34,802 transitions
                                                 -> 2.9x MORE switching on the clean board

DRAM DVFS is exonerated as a cause of the corruption.

Where the confound came from, in full: this board pins both the CPU and DMC governors to
"performance" via a boot-time unit, for an unrelated INFERENCE THROUGHPUT reason that we
measured separately (schedutil costs up to 4.9x on layer-split inference, because a ~27 ms
compute burst cannot outrun the frequency ramp). That pin was already there. When the
fault window closed, the pin was sitting in the frame and took the credit.

The pin is still in place, for the throughput reason only. We no longer claim it has any
bearing on memory integrity, and the numbers above are why.

We publish this because DVFS is the first thing anyone will suggest, and because our own
notes carried the wrong version for weeks before we caught it.
