Updates To Clock Management Within Zephyr RTOS
summary
Proposal shows a concrete rework of Zephyr clock management with an implemented subsystem, new driver APIs and a plan to merge to mainline, not just abstract ideas. It adds runtime frequency requests, splits clocks into three classes (root standard multiplexer) with a configure_recalc API and generic parent/notification handling, introduces rank/rank_factor scoring for selection, and moves clock states into clock outputs in device tree. Measured costs are modest — about +150 bytes flash and ~100 KB SRAM when runtime features and caching are enabled — and caching cuts walk time substantially.
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
49mThe Zephyr™ Project – An Updated Overview
42mSTM32 on Zephyr, What You Need to Know