Camera sensor PMIC power sequencing: device tree rails and delays

A camera sensor that refuses to enumerate is usually a power-tree problem, not a sensor problem. The part runs on three rails — 2.8 V analog, 1.8 V digital I/O, 1.2 V core — that must switch in a fixed order, and an embedded Linux board gives you two places to enforce it: the device tree and the driver. This guide is for firmware and board engineers wiring a sensor to a PMIC on a custom carrier. It gives you the fixed-regulator nodes that describe each rail, the driver code that enables them in sequence, the right home for enable and reset GPIOs, the bench check that proves the order, and the failure signs that point back at the power tree.

Which rails does a camera sensor need, and at what voltages?

A typical CMOS image sensor runs on three rails: AVDD at 2.8 V for the analog core, DOVDD or IOVDD at 1.8 V for the digital I/O pads, and DVDD at 1.2 V for the digital core, each held within a few percent of nominal.

The electrical table of the sensor datasheet prints the exact values. The analog rail is most often 2.8 V and the I/O rail 1.8 V, with the core rail at the low value above; 1.05 V and 1.5 V appear on other generations. Tolerances are tight: the core rail usually allows about ±5%, which is ±60 mV here, so a regulator that sags under load bursts is wrong even when a meter reads nominal at idle. Each rail also carries its own datasheet current, tens of milliamps for a typical small sensor; copy those numbers from the table rather than from a similar part.

Name the rails exactly as the datasheet does — AVDD, DOVDD (some vendors write IOVDD), DVDD — because those names become the strings your driver requests and the -supply suffixes in the device tree.

What order should the rails switch on and off?

For the sequence documented in camera-module power application notes, switch AVDD 2.8 V on first, DOVDD 1.8 V second and DVDD last, keep 0-1 ms between rails, then shut down in the exact reverse order so the core rail is always first off.

The invariant behind that example holds across most sensors: the core rail is last on and first off, and the I/O rail is never the first thing to drop. Some sensor families bring the I/O rail up first instead, so the timing diagram in your sensor's datasheet is the authority — the driver code below simply replays whatever that diagram shows. Gaps matter as much as order: 0-1 ms between rails covers the common case, and the real requirement is that no rail starts rising while the previous one is still ramping. Keep the sensor in reset from the moment the first rail moves until the last rail has been stable, and mirror the order exactly on power-down so every power cycle, cold or warm, repeats a known-good sequence.

How do you describe the rails in the device tree?

Describe each rail as a fixed-regulator node with its voltage, enable GPIO and start-up delay, then point the sensor node at all three with avdd-supply, dovdd-supply and dvdd-supply phandles, and the kernel's regulator framework does the bookkeeping.

One node per rail, using the kernel's documented regulator-fixed compatible. The node names and labels below are mine; the property names are the standard bindings:

cam_avdd: regulator-cam-avdd {
    compatible = "regulator-fixed";
    regulator-name = "cam_avdd";
    regulator-min-microvolt = <2800000>;
    regulator-max-microvolt = <2800000>;
    enable-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
    enable-active-high;
    startup-delay-us = <1000>;      /* 1 ms settle */
    vin-supply = <&vcc_3v3>;
};

cam_dovdd and cam_dvdd repeat that node with regulator-min-microvolt and regulator-max-microvolt at <1800000> and <1200000> and their own enable pins and delays. The sensor node then points at each regulator with a phandle named after the supply string plus -supply:

&i2c2 {
    camera@10 {
        compatible = "vendor,sensor";   /* the string in your driver's of_match table */
        reg = <0x10>;
        avdd-supply  = <&cam_avdd>;
        dovdd-supply = <&cam_dovdd>;
        dvdd-supply  = <&cam_dvdd>;
        reset-gpios  = <&gpio1 11 GPIO_ACTIVE_LOW>;
        status = "okay";
    };
};

Match the suffix to what the driver requests: a driver that asks for iovdd looks for an iovdd-supply phandle, and the driver's regulator_get() fails when the names do not line up. On kernels older than the enable-gpios property, the fixed-regulator binding spells the same pin gpio. If the overlay never applies at all, the device tree mismatch guide sorts out missing DTBs and wrong overlays.

How does the driver code sequence the rails?

The driver requests its supplies by name with devm_regulator_bulk_get(), then calls regulator_enable() on each rail one at a time in the datasheet order with fsleep(1000) — a 1 ms settle — between the calls, and disables them in reverse order.

static const char *const cam_supply_names[] = { "avdd", "dovdd", "dvdd" };

/* probe: fill the supply names, then bind them to the -supply phandles */
unsigned int i;
int ret;
for (i = 0; i < ARRAY_SIZE(cam_supply_names); i++)
    cam->supplies[i].supply = cam_supply_names[i];
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(cam_supply_names), cam->supplies);

static int cam_power_on(struct cam_sensor *cam)
{
    unsigned int i;
    int ret;

    for (i = 0; i < ARRAY_SIZE(cam_supply_names); i++) {
        ret = regulator_enable(cam->supplies[i].consumer);
        if (ret)
            return ret;
        fsleep(1000);   /* 1 ms settle from the timing diagram */
    }
    return 0;
}

cam_power_off() walks the same array backwards with regulator_disable(), so the board mirrors the power-up order on its way down. Because each regulator_enable() call waits out the rail node's startup-delay-us before returning, regulator_bulk_enable() over the same array produces the identical order; pick one mechanism per gap, since fsleep() on top of startup-delay-us doubles the wait. The names in cam_supply_names[] must match the device tree suffixes exactly — that match is what binds this code to the nodes above. The proof is on the bench, in the steps below: order you can see on a scope is order you can trust.

Where do the enable and reset GPIOs go?

Boot-only lines such as a PMIC enable or camera standby line belong in a GPIO hog under the GPIO controller node, while the sensor's reset line belongs in the sensor node as reset-gpios so the driver can release it after the rails settle.

&gpio1 {
    cam0-standby {
        gpio-hog;
        gpios = <8 0>;
        output-low;
        line-name = "cam0-standby";
    };
};

A hog claims the line as the GPIO controller probes, before any camera code runs, which is what you want when a PMIC enable pin must not float during boot. The reset line is different: it lives in the sensor node (pwdn-gpios alongside reset-gpios when the sensor has a power-down pin) because the driver asserts it during the rail sequence and releases it afterwards. Hold reset through the whole sequence, release it once the last rail's startup delay has elapsed, and leave 1-10 ms before the first I2C transaction — the sensor's timing table gives the exact window. Set the polarity flags to match the schematic; active-low resets are the common case on sensor modules. The electrical side of these pins — drive limits and damage triage — is covered in the camera GPIO wiring guide.

How do you bring the sensor up from schematic to first frame?

Run the bring-up as eight fixed steps, starting with the arithmetic that sizes the 3.3 V feed: example rails of 30 mA, 25 mA and 60 mA draw about 61 mA from 3.3 V through LDOs, so that input gets a 150 mA budget.

An LDO's input current is its output current scaled by the voltage ratio, because an LDO burns the difference as heat: dropping DVDD from a 3.3 V feed with 60 mA flowing dissipates (3.3 V − DVDD) × 60 mA = 2.1 V × 60 mA = 126 mW. A buck eases the heat, not the input budget: 60 mA × DVDD / (3.3 V × 0.9) ≈ 24 mA at the input, marginally more than the LDO's 21.8 mA. Double the 61 mA total and round up: budget the 3.3 V feed at 150 mA. The same arithmetic sizes the board's own input, and if the camera node hangs off an Ethernet run, PoE splitters that deliver regulated 5 V and 3.3 V device power with camera pass-through are one clean way to feed it.

1. Copy the power-up timing diagram: rail order, voltages, gaps — 2.8 V, 1.8 V, then the core rail with 1 ms between rails in the example.
2. Size the input feed from the rail currents with the arithmetic above; budget 150 mA on the 3.3 V input for the example rails.
3. Write one regulator-fixed node per rail, with startup-delay-us equal to the gap.
4. Point the sensor node at the rails with the -supply phandles your driver requests by name.
5. Park boot-only enable lines in a GPIO hog; declare reset-gpios on the sensor node.
6. Enable the rails in order in the driver with a settle delay between each; disable in reverse.
7. Scope all three rails plus reset during a driver power-on: rise order matches the diagram, and no rail rests at a half-voltage — an ESD-diode back-power shows 0.3-0.7 V on a rail that should read 0 V.
8. Read the sensor ID register over I2C; only then bring up lanes, formats and streaming.

What are the signs the sequence is wrong?

The signature of a wrong sequence is no I2C response at the sensor's address, a rail resting at 0.3-0.7 V instead of 0 V where another rail back-powers it through ESD diodes, and faults that clear on a cold power cycle and return on a warm reboot.

1. No I2C ACK at the sensor's address. Measure each rail at the sensor's own pins, not at the regulator output — a series ferrite or a mislabeled net leaves the regulator healthy and the sensor dead. Scope a fresh power-on and check that all three rails actually rise.
2. The sensor probes but never reaches userspace. The rails were fine, so the hunt moves to lanes, clocks and driver state — the MIPI power, clocks and device tree checklist picks up from exactly there.
3. A media controller node with no video device. The driver never finished probing; the media0 without video0 walkthrough covers that failure.
4. Sensor control failed on I2C after a warm reboot but works after a cold one. The rails never really dropped — check for always-on regulators and hogs holding enables high — and the I2C soft reset or dead board triage separates the recoverable from the fried.
5. A rail scorching hot or drawing far above its datasheet current. Cut power immediately; an inverted enable polarity or a swapped rail pair is the usual cause.

None of this exists if the sensor arrives as a finished board instead of a die you wire yourself: every board-level camera is a completed assembly with the sensor mounted and its rail passives placed, so the power design is a single supply input rather than a sequence you enforce in code.

For an inspection task with no custom optics, the module below is that shortcut: a 6.3 MP rolling-shutter sensor on a CS-mount board with a GigE interface.

The board level camera selection guide compares the series, the camera finder filters by sensor format and interface, and if your sensor and PMIC are already fixed, talk to the applications team with the schematic page and the dmesg log. More carrier-board troubleshooting lives on the systems topic page.