Clock Management in Zephyr RTOS
summary
Proposes concrete API changes and a prototype: a two-layer driver+management design with clock nodes described in device tree, device-tree clock states for run/sleep setpoints, and rate-change notifications that propagate down a parent/child clock tree. Prototype runs on LPC55S69 and boots a basic helloworld application; implementation adds roughly 1 KB of flash with notifications enabled and drops substantially when callbacks are disabled. The proposal preserves existing get_rate behavior, makes set_rate optional, and targets lower RAM/flash overhead and better code reuse across SOCs.
AI-written summary · about
chapters (10)
- 0:00Clock management intro
- 1:02Current clock framework
- 4:12Framework limitations
- 6:37New clock system requirements
- 10:29Proposed clock implementation
- 14:03Clock driver API details
- 19:03Device tree clock hierarchy
- 23:35Framework implementation examples
- 28:57Current status and alternatives
- 31:19Q&A
related talks
40mClock Management in Zephyr RTOS
47mUpdates To Clock Management Within Zephyr RTOS- 47mUpdates To Clock Management Within Zephyr RTOS
40mReworking the Zephyr Clock Control Subsystem
26mA Clock-Distribution Abstraction for Resource-Constrained Real-Time Systems in Zephyr
42mSTM32 on Zephyr, What You Need to Know
42mCommon Clock Framework: How to use it
43mBeyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...