Every enabled DT node binds: bandwidth monitors, videocc, camcc (2026-11-04)
Attempt 2026-11-03-35 (written before midnight, booted 2026-11-04 about 12:00 AM ET): kernel #18 (commit
d41ab28, kernel/mica-sync.config), the board DTS with ADR 0008
(no PSCI domain idle states), image 4c8699959d256a77. One cold start (the EC reset itself at power-on:
Reset cause: sysjump hard efs). Sources: the netlog dumps/firstboot/2026-11-04-netlog.txt and the AP console log
(both gitignored), attempt.sh compare against -34 boot 3.
Change
kernel/mica-sync.config builds in three drivers that arm64 defconfig has as modules (the initramfs loads none):
QCOM_ICC_BWMON: the four bandwidth-monitor PMUspmu@24091000(qcom,sc7280-llcc-bwmon) andpmu@240b3400,@240b5400,@240b6400(qcom,sdm845-bwmon).SM_VIDEOCC_8550:clock-controller@aaf0000(qcom,x1e80100-videocc).CLK_X1E80100_CAMCC:clock-controller@ade0000.
The symbols come from scripts/dt-kconfig-map.py at a804c57; their four lines left kernel/dt-gaps.txt in the
same commit.
Result
unbound=went from 6 to 0. No line in dmesg sayssync_state() pending due to, so every interconnect and clock provider reachedsync_state().deferred=is empty.- No probe error from the new drivers (dmesg has no failure line naming bwmon, videocc or camcc).
- SCMI: 78 replies, max 3.9 ms, 0 timeouts. That is the fourth stall-free cold boot with no domain idle states. cpufreq is on all three clusters (710 MHz to 3.42 GHz).
- The touchscreen still fails (
hid-generic ... -22). Its rail and enable pin read on this time (ts-vreg=enabled users=1,gpio88 out high, against disabled/low on -34 boot 3), which is the same failure with a different probe order (inference). comparelabels this boot “warm”: it took the AP reset at EC 179 s, which was/init’s reboot after the run, while the EC’s own reset at power-on restarted its clock. The boot was cold.
Open
- What the providers’
sync_state()changes in power (bandwidth and clock votes dropped to what consumers ask for) has not been measured. The suspend test covers it.