[PATCH] hw/core/clock: remove assert in clock_propagate

[PATCH] hw/core/clock: remove assert in clock_propagate

[Raphael Poggi]

This commit allows childs clock to propagate their new frequency,
for example, after setting a new multiplier/diviser.

Signed-off-by: Raphael Poggi <raphael.poggi@lynxleap.co.uk>
---
 hw/core/clock.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/core/clock.c b/hw/core/clock.c
index 85421f8b55..174c8be095 100644
--- a/hw/core/clock.c
+++ b/hw/core/clock.c
@@ -109,7 +109,6 @@ static void clock_propagate_period(Clock *clk, bool call_callbacks)
 
 void clock_propagate(Clock *clk)
 {
-    assert(clk->source == NULL);
     trace_clock_propagate(CLOCK_PATH(clk));
     clock_propagate_period(clk, true);
 }
-- 
2.44.0

Re: [PATCH] hw/core/clock: remove assert in clock_propagate

[Peter Maydell]

On Fri, 19 Apr 2024 at 17:30, Raphael Poggi
<raphael.poggi@lynxleap.co.uk> wrote:
>
> This commit allows childs clock to propagate their new frequency,
> for example, after setting a new multiplier/diviser.
>
> Signed-off-by: Raphael Poggi <raphael.poggi@lynxleap.co.uk>

Applied to target-arm.next, thanks. I rewrote the commit message
to document the conversation we had in the other email thread:

    hw/core/clock: allow clock_propagate on child clocks

    clock_propagate() has an assert that clk->source is NULL, i.e. that
    you are calling it on a clock which has no source clock.  This made
    sense in the original design where the only way for a clock's
    frequency to change if it had a source clock was when that source
    clock changed.  However, we subsequently added multiplier/divider
    support, but didn't look at what that meant for propagation.

    If a clock-management device changes the multiplier or divider value
    on a clock, it needs to propagate that change down to child clocks,
    even if the clock has a source clock set.  So the assertion is now
    incorrect.

    Remove the assertion.

-- PMM