Fixing Clock Tree Propagation in the Common Clk Framework
summary
The Common Clk Framework currently lets a child call clk_set_rate that silently changes an ancestor via CLK_SET_RATE_PARENT, breaking sibling rates; reproductions include recently posted kunit tests reproduce the failures and several long-standing bug reports. Proposed changes add a new member to struct clk_ops and a V1/V2 negotiation logic that walks to the topmost clock, negotiates a rate acceptable to every node, and offers a kernel parameter to disable V2 for compatibility; device-tree fixes or warnings are suggested for boards that rely on the old behavior.
AI-written summary · about
chapters (8)
- 0:00Introduction and goals
- 3:13Proposed V1-V2 negotiation logic
- 6:19Discussion on existing behavior
- 11:58Handling sibling clock changes
- 16:38Focus on specific SoC solutions
- 20:10Flag-based sibling clock handling
- 23:47Static vs dynamic parent rates
- 24:09Q&A and wrap-up
related talks
45mCommon Clock Framework: How To Use It
47mUpdates To Clock Management Within Zephyr RTOS
35mTimekeeping in the Linux Kernel
47mRTC Subsystem, Recent Changes and Where it is Heading
30m"Logs Told Us It Was Kernel – It Wasn't"
44mSolving Devicetree Issues, part 3.0
29mpyadi-jif: JESD204 tools for mere mortals
30mPCIe Endpoint Subsystem Open Items Discussion