On Mon, Mar 23, 2026 at 01:24:51PM -0400, Brian Masney wrote: > The Common Clock Framework is expected to keep a clockâs rate stable > after setting a new rate with: > > clk_set_rate(clk, NEW_RATE); > > Clock consumers do not know about the clock hierarchy, sibling clocks, > or the type of clocks involved. However, several longstanding issues > affect how rate changes propagate through the clock tree when > CLK_SET_RATE_PARENT is involved, and the parent's clock rate is changed: > > - A clock in some cases can unknowingly change a sibling clock's rate. > > - No negotiation is done with the sibling clocks, so an inappropriate > or less than ideal parent rate can be selected. > > A selection of some real world examples of where this shows up is at > [1]. DRM needs to run at precise clock rates, and this issue shows up > there, however will also show up in other subsystems that require > precise clock rates, such as sound. > > This series introduces kunit tests to illustrate the current behavior in > the clk core. As discussed at Linux Plumbers Conference 2025 in Tokyo > [2], it was suggested to move the negotiation logic into the clk > providers themselves so that only the clks with this issue can have > their rate preserved, and add some common helpers to the clk core.
Sashiko identified a few issues with this series, so I'll post a new version with the fixes. https://sashiko.dev/#/patchset/20260323-clk-scaling-v7-0-8e7193dc9405%40redhat.com Brian
