Bus DCVS: Dynamic Clock and Voltage Scaling for DDR Bandwidth Management in Modern SoCs

In modern SoCs, CPU tasks can be CPU‑bound, I/O‑bound, or a mixture of both. While performance tuning often focuses on the CPU, the DDR subsystem, which provides code execution space and data cache, also requires dynamic bandwidth management. Different usage scenarios (e.g., music playback vs. high‑definition video streaming) demand different DDR bandwidth, so the system must adjust the DDR bus frequency to balance performance and power consumption.

What is BUS DCVS? BUS DCVS (Dynamic Clock and Voltage Scaling) is an algorithm that selects the optimal bus frequency based on real‑time workload demands, aiming to achieve a performance‑power trade‑off.

The typical SOC contains many masters (CPU, GPU, NPU, DISPLAY, CAMERA, etc.) that vote for DDR bandwidth. The RPM (Resource Power Manager) aggregates these votes and sets the final DDR frequency.

The article focuses on two main BUS DCVS strategies used in mainstream platforms:

bw_hwmon (bandwidth hardware monitor) : Adjusts cache and DDR frequencies based on the bandwidth observed between CPU‑to‑cache and cache‑to‑DDR paths.

memlat (memory latency) : Adjusts frequencies based on latency‑sensitive metrics collected from the cache‑miss and instruction‑count counters.

Software architecture of BUS DCVS

1. User space : Exposes sysfs nodes such as /sys/class/devfreq/soc*ddr-bw and /sys/class/devfreq/soc*ddr-lat , as well as standard devfreq nodes (min_freq, max_freq, cur_freq). Users can read current bandwidth demands and, with proper permissions, write policy parameters.

2. Kernel space : Implements BUS DCVS as a devfreq governor. The core components are the devfreq framework, the bimc‑bwmon device (bandwidth monitor) and the devbw device (bandwidth demand). Two governors are provided: bw_hwmon and memlat .

3. RPM OS : Collects votes from all masters and programs the LPDDR hardware with the selected frequency.

bw_hwmon strategy

Source files:

drivers/devfreq/devfreq_devbw.c

drivers/devfreq/bimc-bwmon.c

driver/devfreq/governor_bw_hwmon.c

arch/arm64/boot/dts/vendor/qcom/

The flow is:

The bimc‑bwmon driver registers as a devfreq governor, providing get_target_freq and event_handler callbacks.

The devbw driver registers its device, sets up the devfreq_dev_profile with target and get_dev_status functions, and defines the polling interval.

When the governor receives a GOV_START event, it registers an interrupt that triggers on rapid bandwidth changes; a delayed work may also update the frequency periodically.

Key parameters used in get_bw_and_set_irq :

guard_band_mbps : Adds a safety margin to the measured bandwidth before voting.

decay_rate : Controls how much historical data influences the current measurement (0‑100, where 100 ignores history).

bw_step : Rounds the bandwidth to reduce frequency‑change jitter.

io_percent : Represents the proportion of time the CPU spends on memory accesses, used to compute instantaneous bandwidth (IB).

The governor calculates average (AB) and instantaneous (IB) bandwidth, applies the above parameters, and votes for a new DDR frequency via the RPM.

memlat strategy

Source files:

drivers/devfreq/devfreq_devbw.c

drivers/devfreq/arm-memlat-mon.c

driver/devfreq/governor_memlat.c

arch/arm64/boot/dts/vendor/qcom/

This governor complements bw_hwmon by focusing on memory‑latency‑sensitive workloads. It uses a PMU‑based memlat‑mon device to measure cache‑miss events and instruction counts. The flow mirrors bw_hwmon: the driver registers as a devfreq governor, sets up callbacks, and starts monitoring on GOV_START .

During each monitoring interval, the governor computes the ratio inst / miss . If the ratio is below a configured ratioceil , the governor triggers a frequency update by calling devfreq_bw 's set_bw function.

Conclusion

BUS DCVS provides fine‑grained control over DDR frequency, enabling SoCs to adapt to mixed CPU‑bound and I/O‑bound workloads. By leveraging both bandwidth‑based ( bw_hwmon ) and latency‑based ( memlat ) governors within the Linux devfreq framework, manufacturers can achieve better performance‑power balance across diverse usage scenarios.