hw/core/clock.c | 1 - 1 file changed, 1 deletion(-)
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
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
© 2016 - 2026 Red Hat, Inc.