Updates To Clock Management Within Zephyr RTOS
summary
Proposal replaces existing clock control with a clock-management subsystem that already implements runtime frequency requests, moves clock states to clock output nodes, and splits drivers into three clock classes (root, standard, multiplexer) so notification, parent selection and rate calc become generic. Implementation shows a ~150 byte flash overhead and runtime caching cuts tree-walk cost dramatically (SRAM impact on tests around 100 KB). Additive frequency constraints and locking guarantee requested ranges; driver API changes are required but the design is validated on LPC55S69 and STM32 work.
AI-written summary · about
chapters (8)
- 0:00Clock management updates intro
- 1:04Current Zephyr clocking
- 2:54Initial proposal limits
- 7:07Community feedback
- 12:00Updated proposal API
- 20:41User API improvements
- 25:38Outstanding issues next steps
- 31:15Q&A
related talks
47mUpdates To Clock Management Within Zephyr RTOS
40mClock Management in Zephyr RTOS
40mClock Management in Zephyr RTOS
40mReworking the Zephyr Clock Control Subsystem
26mA Clock-Distribution Abstraction for Resource-Constrained Real-Time Systems in Zephyr
28mUpdating and Modernizing Clk (Clock) Drivers
42mSTM32 on Zephyr, What You Need to Know
45mCommon Clock Framework: How To Use It