Re: [PATCH RFC v5 0/4] clk: add support for v1 / v2 clock rate negotiation and kunit tests

[Brian Masney]

On Fri, Mar 6, 2026 at 6:22 PM Brian Masney <bmasney@xxxxxxxxxx> 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@xxxxxxxxxx/
>
> - 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