drivers/clk/clk.c | 207 +++++++++++++++++++++++++--- drivers/clk/clk_test.c | 317 +++++++++++++++++++++++++++++++++++++++++++ include/linux/clk-provider.h | 39 +++++- 3 files changed, 546 insertions(+), 17 deletions(-)
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.
More details about this particular case are documented at:
https://lore.kernel.org/linux-clk/20250528-clk-wip-v2-v2-2-0d2c2f220442@redhat.com/
- 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.
Note I am marking this series as a RFC because:
- I only have kunit tests, and there's no actual real users of these
new helpers. (kunit doesn't count.) I'm hoping to get feedback from
Stephen if this is what he had in mind for an acceptable solution
based on earlier discussions. In the mean time, I'll see if I can
get a board that has this issue, or work with someone in another
company that can test this for me.
- I feel like the names of some of these newly-introduced members
could be improved. Naming things can be hard.
Changes since v4:
https://lore.kernel.org/linux-clk/20250923-clk-tests-docs-v4-0-9205cb3d3cba@redhat.com/
- Reworked based on feedback at Linux Plumbers [2] as described in two
paragraphs above.
- Dropped gate and mux tests.
Changes since v3:
https://lore.kernel.org/r/20250812-clk-tests-docs-v3-0-054aed58dcd3@redhat.com
- Update clk_core struct members (Maxime)
- Add v2 rate negotiation logic and additional kunit tests
- Drop clk_dummy_rate_mhz() in kunit tests; use HZ_PER_MHZ
[1] https://lore.kernel.org/all/20260303115550.9279-1-mitltlatltl@gmail.com/
https://lore.kernel.org/lkml/20230825-pll-mipi_keep_rate-v1-0-35bc43570730@oltmanns.dev/
https://lore.kernel.org/linux-kernel/20230807-pll-mipi_set_rate_parent-v6-0-f173239a4b59@oltmanns.dev/
https://lore.kernel.org/all/20241114065759.3341908-1-victor.liu@nxp.com/
https://lore.kernel.org/linux-clk/20241121-ge-ian-debug-imx8-clk-tree-v1-0-0f1b722588fe@bootlin.com/
[2] Fixing Clock Tree Propagation in the Common Clk Framework
https://www.youtube.com/watch?v=R8TytDzlcFs
https://lpc.events/event/19/contributions/2152/
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
Brian Masney (4):
clk: test: introduce clk_dummy_div for a mock divider
clk: test: introduce test suite for sibling rate changes on a divider
clk: add support for coordinated rate changes from the providers
clk: test: add kunit test for coordinated rate change
drivers/clk/clk.c | 207 +++++++++++++++++++++++++---
drivers/clk/clk_test.c | 317 +++++++++++++++++++++++++++++++++++++++++++
include/linux/clk-provider.h | 39 +++++-
3 files changed, 546 insertions(+), 17 deletions(-)
---
base-commit: fc7b1a72c6cd5cbbd989c6c32a6486e3e4e3594d
change-id: 20260305-clk-scaling-b3b63cae7624
Best regards,
--
Brian Masney <bmasney@redhat.com>
On Fri, Mar 6, 2026 at 6:22 PM Brian Masney <bmasney@redhat.com> 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. > More details about this particular case are documented at: > https://lore.kernel.org/linux-clk/20250528-clk-wip-v2-v2-2-0d2c2f220442@redhat.com/ > > - 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. > > Note I am marking this series as a RFC because: > > - I only have kunit tests, and there's no actual real users of these > new helpers. (kunit doesn't count.) I'm hoping to get feedback from > Stephen if this is what he had in mind for an acceptable solution > based on earlier discussions. In the mean time, I'll see if I can > get a board that has this issue, or work with someone in another > company that can test this for me. > > - I feel like the names of some of these newly-introduced members > could be improved. Naming things can be hard. I came up with an idea to simplify this patch set even more, so folks can skip reviewing this version. I'll post a new even more simplified version next week hopefully. Brian
© 2016 - 2026 Red Hat, Inc.