Skip to content

power: source-ground MT6739 DVFS and MCDI transitions before enabling device writes #879

Description

@forkwright

Finding

The unsafe actuation is gone; the source grounding it was blocking on is not. PR #887 structurally removed the approximate ARMPLL writes and the incomplete MCDI sequence from the timer path, and deleted the speculative operating points and PCW constants that fed them. CPU frequency and core-power actuation are now unavailable rather than approximate. This issue remains open for the work it was always about: pinning the authoritative MT6739 contract and building a source-grounded backend behind it.

Evidence

Current tree, main at a1154631cd03a212636e36407ba73d21d675fff0:

  • crates/thumos/src/exceptions.rs:356 — the only surviving mention of ARMPLL/MCDI in the kernel crate is a comment recording that this path used to issue those writes. ARMPLL_CON1 does not exist anywhere in the tree.
  • crates/thumos/src/power.rs — carries no PCW, OPP, or CPU-frequency constants at all. Its sole remaining MMIO call is a DSI display FIFO write (power.rs:264), unrelated to CPU power.
  • The timer IRQ body reaches only power::check_backlight_timeout; no frequency or core-parking transition is reachable from it.
  • .github/workflows/ci.yml:189scripts/check-board-seam.sh rejects re-declaring board MMIO values as constants outside board/, which is what would be needed to reintroduce a speculative PCW table.

The earlier Evidence text stated that power.rs models 1500/1200/900/600 MHz with approximate PCWs and that the device path writes them to ARMPLL_CON1. Neither is true of the current tree; both describe code #887 deleted.

Why this matters

An ungrounded PLL, voltage, or core-power transition can hang or damage a physical device, and that specific hazard is now structurally unreachable rather than merely disabled — there is no code path from the timer to an MMIO write, so no flag or build profile re-enables one.

What survives is a documentation hazard rather than an execution one. The removed constants were plausible-looking numbers, and the next author reaching for DVFS will find an empty space where a working table used to be. Without the pinned source contract below, the cheapest way to fill that space is to re-derive the same approximations, which is exactly how this issue was created the first time.

Done when

  • Met in fix(power): disable ungrounded CPU actuation #887 — device builds fail closed with DVFS and core parking disabled; no approximate PCW reaches MMIO.
  • Pin authoritative MT6739 BSP/vendor sources for supported CPU OPPs, efuse/bin selection, voltage/PLL ordering, locks/barriers/timeouts, and clock-switch semantics.
  • Pin the complete MCDI/core power-state protocol, including acknowledgements, wakeup, rollback, and multi-core concurrency.
  • Separate pure policy from hardware actuation and expose requested/applied/observed/failed state.
  • Host tests cover threshold/hysteresis policy, unsupported OPP rejection, timeout/rollback, and concurrent core transitions.
  • Resolve the planning-versus-source discrepancy where planning named 500 MHz and the lowest modelled point was 600 MHz; the pinned source decides.
  • Only after the source-grounded implementation and CI land may operator-owned M7 qualification exercise DVFS or core parking.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions