The RK3399 IO domain controller is a small but critical block: it tells the SoC what voltage each external IO bank is running at (1.8 V vs 3.3 V) so the input buffer trip points and slew rates are programmed correctly. Get it wrong and signals look fine on a scope but the SoC samples them at the wrong threshold, producing the kind of bug that manifests as “this peripheral is flaky” without any obvious cause.
The chip has two instances — one on the PMU (always-on) power island and one in the SoC GRF — because some of the IO banks live on the PMU side and some on the main SoC side.
Identity
| Property | Value |
|---|---|
| Block | RK3399 IO domain controller (PMU + SoC instances) |
| DTS compatible | rockchip,rk3399-pmu-io-voltage-domain and rockchip,rk3399-io-voltage-domain |
| Bindings | One regulator-supply property per IO bank, naming maps a regulator to a domain |
| Linux driver | drivers/soc/rockchip/io-domain.c |
Driver
● workingBoth PMU and SoC IO domain instances attach cleanly. Both come from the upstream FreeBSD-extras Rockchip support; the Honeyguide overlay configures them via DTS supplies.
The driver reads the regulator voltage for each named supply
(vcc1-supply … vccN-supply) and writes the corresponding bit in
the GRF IO_VSEL register (PMU instance) or
PMUGRF_SOC_CON* (SoC instance) to tell the IO buffers whether
they’re 1.8 V or 3.3 V. This happens once at attach; there is no
runtime per-bank voltage switching on this hardware.
Driver path in the FreeBSD tree (mainline, not under our overlay):
sys/dev/iicbus/pmic/rockchip/
and adjacent — the iodomain logic lives alongside the rest of the
RK3399 GRF / PMU support.
Verify on running hardware:
# Look for both attached instances
dmesg | grep -i iodomain
# Expect: rk_iodomain0 / rk_iodomain1 (or equivalent — names vary by tree)
Why this matters
If iodomain were wrong, expect:
- I2C buses on the affected bank reporting NACKs from devices that acknowledge correctly when scoped from a real master.
- SDIO IRQ misbehavior on DAT[1] — the controller sees the line as “asserted” or “floating” depending on threshold.
- GPIO inputs reading the wrong level near the rail mid-point.
Today none of those symptoms point at iodomain on this board, which is the strongest signal that both instances are doing their job.
Status
| Question | Answer |
|---|---|
| Probes? | Yes — both PMU and SoC instances |
| Misconfiguration risk? | Low — DTS supplies match Linux mainline |
| Open work? | None |
Related
- Hardware reference — IO domains row in Power management.
HARDWARE.md— IO voltage domains listed as “rk_iodomain attached (both PMU and SoC instances)” under Power Management.