Zephyr Runtime PM Dependencies: Holding a Sensor Does Not Hold Its I2C Bus
A sensor remains runtime-active while its I2C controller repeatedly suspends and resumes between transfers. That trace does not necessarily indicate a leaked reference, a failed sensor acquisition or a broken bus. The sensor and controller are separate runtime-PM objects, and a reference to one need not retain the other.
This review pins Zephyr v4.4.0’s runtime-PM documentation, runtime implementation and the Nordic nrfx TWIM driver. The example uses an ordinary synchronous thread path with runtime PM enabled on the relevant devices. It is not a statement about every Zephyr I2C driver or ISR-safe acquisition.
Draw three device identities before interpreting the trace
Identify the sensor object, its I2C controller and any configured power-domain device. Label the actual relationship on each edge. The sensor uses the controller for transactions; a power-domains relationship describes power-domain membership. Those relationships need not have the same lifetime or even connect the same devices.
The documentation provides automatic acquisition and release for a configured power domain in response to child runtime-PM operations. To control that domain’s state automatically, runtime PM must also be enabled on the domain device.
Its separate dependency note says general device dependencies are not automatically managed. A sensor depending on a bus therefore does not imply that the framework recursively holds the controller throughout the sensor’s active interval. The power-domain feature is a specific relationship, not a general traversal of every devicetree connection.
Inspect the dependency edge the implementation follows
In the ordinary pm_device_runtime_get() path, the framework obtains the device’s configured PM_DOMAIN and claims that domain when needed before increasing the child usage count. It tracks the claim with PM_DEVICE_FLAG_PD_CLAIMED and releases it through the corresponding domain-release paths.
This establishes why an automatically retained domain can coexist with a separately idling bus controller. Keeping a supply domain available does not require every controller in or near that domain to remain runtime-active. Likewise, a controller’s software suspend callback is not proof that an entire physical rail turned off.
For the proposed sensor burst, keep domain configuration fixed. Changing both the domain topology and controller retention policy would obscure which dependency actually explained the repeated transitions.
Follow one successful nrfx transfer interval
The inspected TWIM transfer function enters through i2c_nrfx_twim_exclusive_access_acquire(). That helper takes the transfer semaphore and calls pm_device_runtime_get() on the controller. The ordinary transfer tail calls the corresponding release helper, which invokes runtime put and releases the semaphore.
Thus one successful transfer can hold the controller only for that transfer’s interval. A second transfer later can acquire it again. The sensor’s longer active interval does not, by itself, join those two controller intervals into one continuous hold.
Keep the source example’s limits visible. The acquire helper discards the PM-get result and returns the semaphore result; its success return is not independent evidence that runtime resume succeeded. Also, a buffer-preparation failure in the pinned transfer function returns before the common release tail. This article uses the normal successful path to explain retention scope, and does not certify every driver error path as balanced.
Decide whether a longer bus hold is actually required
If the sensor driver’s supported operation comprises several nearby transfers, its owner can consider an explicit runtime-PM reference to the controller for that bounded operation. Acquire it with the supported standard API, check acquisition failure, and retain it until the last actual I/O in the operation has finished.
This additional reference holds runtime activity; it does not lock the I2C bus, combine transfers atomically or replace the controller driver’s own transfer serialization. Do not confuse it with taking the driver’s exclusive-access helper around a call that already acquires that same semaphore internally.
Release the extra reference only if that operation successfully acquired it, and account for the release result under the selected API contract. Do not manipulate internal state fields or disable power management globally to conceal an unexplained transition. The required decision is whether this specific operation needs a wider controller-use interval.
Compare callback boundaries with a controlled model
A proposed fake-driver fixture uses two successful controller transfers inside one sensor-use interval, with no other controller users. Without an outer bus reference, each transfer can take controller usage from zero to one and back to zero, permitting a resume and suspend for each transfer.
With one successfully acquired outer controller reference, each transfer temporarily raises controller usage from one to two and returns it to one. The final outer release returns it to zero after both transfers. Under the stated synchronous model, that separates the operation-wide lifetime from the two shorter transfer lifetimes.
Record device identity, acquisition outcome and callback boundaries in the proposed trace. Include failure to acquire the outer reference and verify that dependent I/O is not issued on that failed assumption. Keep the sensor and domain events in separate columns so a domain callback cannot be mistaken for a bus callback.
No fixture, current measurement or hardware wake test was executed here. Fewer modeled controller transitions do not establish a measured energy or latency benefit. The deliverable is the missing-dependency explanation and a bounded retention decision tied to the actual driver path, followed by target qualification of the first and last useful I/O.
