You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:189 → scripts/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.
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,
mainata1154631cd03a212636e36407ba73d21d675fff0:crates/thumos/src/exceptions.rs:356— the only surviving mention ofARMPLL/MCDIin the kernel crate is a comment recording that this path used to issue those writes.ARMPLL_CON1does 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.power::check_backlight_timeout; no frequency or core-parking transition is reachable from it..github/workflows/ci.yml:189→scripts/check-board-seam.shrejects re-declaring board MMIO values as constants outsideboard/, which is what would be needed to reintroduce a speculative PCW table.The earlier Evidence text stated that
power.rsmodels 1500/1200/900/600 MHz with approximate PCWs and that the device path writes them toARMPLL_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