Linux Kernel devfreq Framework: Architecture, Interfaces, and Workflow
Linux’s devfreq framework provides a generic DVFS subsystem for non‑CPU devices, defining standardized kernel‑space structures (devfreq_profile, devfreq_governor, devfreq_device) and sysfs user‑space interfaces, and managing device initialization, frequency scaling via governors, and clean removal, enabling flexible power‑performance optimization across heterogeneous SoC components.
Modern complex SoCs consist of multiple sub-modules that can be grouped into power domains, allowing some domains to run at lower voltage and frequency while others run at higher performance levels. The supported voltage‑frequency pairs are called Operating Performance Points (OPP). Non‑CPU devices that support OPP are referred to as OPP devices and are managed dynamically by the devfreq framework.
devfreq is a generic Dynamic Voltage and Frequency Scaling (DVFS) framework for non‑CPU devices, contributed by Samsung (MyungJoo Ham). Its design is similar to the cpufreq subsystem but unlike cpufreq, devfreq allows multiple devices to register simultaneously and lets each device have its own governor.
The devfreq framework is part of the power management subsystem and works together with cpufreq, cpuidle, and power manager to reduce overall system power consumption.
Standardized Interfaces
As a Linux kernel subsystem, devfreq provides both kernel‑space and user‑space interfaces. Kernel‑space interfaces consist of three main data structures:
devfreq_profile : describes the OPP device’s frequency table and callbacks; it is the primary interface between an OPP device driver and the devfreq core.
devfreq_governor : registers a governor with devfreq, containing governor‑specific attributes and function implementations.
devfreq_device : the core device structure that links a profile and a governor and exposes a sysfs interface to user space.
User‑space interaction is provided through a set of sysfs files (e.g., available_frequencies , available_governors , cur_freq , governor , max_freq , min_freq , polling_interval , target_freq , trans_stat ) located under kernel/Documentation/ABI/testing/sysfs-class-devfreq . The implementation resides in kernel/drivers/devfreq/devfreq.c .
Workflow
The devfreq framework operates through three major phases: initialization, frequency adjustment, and device removal.
1. Initialization
During boot, the devfreq core, all registered governors, and OPP devices are initialized. The steps include creating the devfreq device class, setting up a workqueue for load monitoring, and registering the initialization function with subsys_initcall . Governors are populated with their specific structures and added to the governor list, also via subsys_initcall . The default governors provided are simple_ondemand , performance , powersave , userspace , and passive . Custom governors can be added by filling a devfreq_governor structure and implementing get_target_freq and event_handler .
2. OPP Device Creation
When an OPP device (e.g., a UFS storage controller) wants to use devfreq, it registers a devfreq_profile with frequency tables and callbacks, selects a governor by name, and calls devfreq_add_device . The core allocates a devfreq device, links the profile and governor, and sends a DEVFREQ_GOV_START event to the governor to begin management.
3. Frequency Adjustment
The governor’s event_handler receives the DEVFREQ_GOV_START event, schedules the workqueue, and periodically runs a load‑monitoring routine. This routine calls the governor’s get_target_freq method to compute a new frequency, then invokes the OPP device’s target callback to apply the change, and finally re‑queues itself after the configured polling interval.
4. Device Removal
When a devfreq device is no longer needed, device_unregister is called, which triggers devfreq_dev_release . This sends a DEVFREQ_GOV_STOP event to stop the governor, calls the OPP device’s exit callback, and frees all allocated resources.
Architecture Design
devfreq abstracts multiple OPP devices and governors behind uniform kernel and user‑space interfaces, providing a clean extensibility model. This design serves as a reference for building other kernel subsystems that require standardized device‑governor interactions.
Conclusion
The article presents the background, interfaces, data structures, workflow, and architectural considerations of the Linux kernel devfreq framework, offering a comprehensive guide for developers and engineers working on power management in embedded systems.
OPPO Kernel Craftsman
Sharing Linux kernel-related cutting-edge technology, technical articles, technical news, and curated tutorials
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.