From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: qemu-devel@nongnu.org
Cc: Damien Hedde <damien.hedde@greensocs.com>,
Peter Maydell <peter.maydell@linaro.org>,
Luc Michel <luc@lmichel.fr>,
Eduardo Habkost <ehabkost@redhat.com>,
qemu-arm@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC PATCH-for-6.1 0/9] hw/clock: Strengthen machine (non-qdev) clock propagation
Date: Fri, 9 Apr 2021 16:11:13 +0200 [thread overview]
Message-ID: <08698b00-e867-2e40-440b-89d303cbefef@amsat.org> (raw)
In-Reply-To: <774acc32-2d5a-298e-f47b-df763f86ad2d@amsat.org>
On 4/9/21 3:12 PM, Philippe Mathieu-Daudé wrote:
> On 4/9/21 8:23 AM, Philippe Mathieu-Daudé wrote:
>> Hi Damian, Luc, Peter.
>>
>> I've been debugging some odd issue with the clocks:
>> a clock created in the machine (IOW, not a qdev clock) isn't
>> always resetted, thus propagating its value.
>> "not always" is the odd part. In the MPS2 board, the machine
>> clock is propagated. Apparently because the peripherals are
>> created directly in the machine_init() handler. When moving
>> them out in a SoC QOM container, the clock isn't... I'm still
>> having hard time to understand what is going on.
>>
>> Alternatively I tried to strengthen the clock API by reducing
>> the clock creation in 2 cases: machine/device. This way clocks
>> aren't left dangling around alone. The qdev clocks are properly
>> resetted, and for the machine clocks I register a generic reset
>> handler. This way is safer, but I don't think we want to keep
>> adding generic reset handlers, instead we'd like to remove them.
>>
>> I'll keep debugging to understand. Meanwhile posting this series
>> as RFC to get feedback on the approach and start discussing on
>> this issue.
>
> I wonder if this could be the culprit:
No (same reverting it) :(
> commit 96250eab904261b31d9d1ac3abbdb36737635ffa
> Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Date: Fri Aug 28 10:02:44 2020 +0100
>
> hw/clock: Only propagate clock changes if the clock is changed
>
> Avoid propagating the clock change when the clock does not change.
>
> diff --git a/include/hw/clock.h b/include/hw/clock.h
> index d85af45c967..9ecd78b2c30 100644
> --- a/include/hw/clock.h
> +++ b/include/hw/clock.h
> @@ -165,8 +165,9 @@ void clock_propagate(Clock *clk);
> */
> static inline void clock_update(Clock *clk, uint64_t value)
> {
> - clock_set(clk, value);
> - clock_propagate(clk);
> + if (clock_set(clk, value)) {
> + clock_propagate(clk);
> + }
> }
>
> I.e.:
>
> - first use clock_set() to set the new period
> - then call clock_update() with the same "new period"
>
> -> the clock parent already has the new period, so the
> children are not updated.
This is actually what clock_set_source() does:
void clock_set_source(Clock *clk, Clock *src)
{
...
clk->period = src->period; // <------------------------------
QLIST_INSERT_HEAD(&src->children, clk, sibling);
clk->source = src;
clock_propagate_period(clk, false);
}
So indeed if we use qdev_connect_clock_in() in DeviceRealize(),
it calls clock_set_source() and set the period, does not propagate,
then later when clock_propagate_period() is called:
static void clock_propagate_period(Clock *clk, bool call_callbacks)
{
...
QLIST_FOREACH(child, &clk->children, sibling) {
if (child->period != clk->period) {
// ^^^^ this condition is false
...
clock_propagate_period(child, call_callbacks);
// ^^^ children never get clock propagated
}
}
}
Does it make sense?
next prev parent reply other threads:[~2021-04-09 14:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 6:23 [RFC PATCH-for-6.1 0/9] hw/clock: Strengthen machine (non-qdev) clock propagation Philippe Mathieu-Daudé
2021-04-09 6:23 ` [RFC PATCH-for-6.1 1/9] hw/core/clock: Increase clock propagation trace events verbosity Philippe Mathieu-Daudé
2021-04-09 6:23 ` [RFC PATCH-for-6.1 2/9] hw/core/machine: Add machine_create_constant_clock() helper Philippe Mathieu-Daudé
2021-04-09 6:23 ` [RFC PATCH-for-6.1 3/9] hw/arm: Use new " Philippe Mathieu-Daudé
2021-04-09 6:23 ` [RFC PATCH-for-6.1 4/9] hw/mips: " Philippe Mathieu-Daudé
2021-04-09 6:23 ` [RFC PATCH-for-6.1 5/9] hw/core/qdev-clock: Add qdev_ground_clock() helper Philippe Mathieu-Daudé
2021-04-19 14:22 ` Peter Maydell
2021-04-09 6:23 ` [RFC PATCH-for-6.1 6/9] hw/misc/bcm2835_cprman: Use " Philippe Mathieu-Daudé
2021-04-09 6:23 ` [RFC PATCH-for-6.1 7/9] hw/misc/bcm2835_cprman: Feed 'xosc' from the board Philippe Mathieu-Daudé
2021-04-19 14:24 ` Peter Maydell
2021-04-09 6:24 ` [RFC PATCH-for-6.1 8/9] hw/clock: Declare clock_new() internally Philippe Mathieu-Daudé
2021-04-19 14:26 ` Peter Maydell
2021-04-20 9:27 ` Philippe Mathieu-Daudé
2021-04-09 6:24 ` [RFC PATCH-for-6.1 9/9] hw/core/machine: Reset machine clocks using qemu_register_reset() Philippe Mathieu-Daudé
2021-04-19 14:27 ` Peter Maydell
2021-04-09 13:12 ` [RFC PATCH-for-6.1 0/9] hw/clock: Strengthen machine (non-qdev) clock propagation Philippe Mathieu-Daudé
2021-04-09 14:11 ` Philippe Mathieu-Daudé [this message]
2021-04-09 14:20 ` Philippe Mathieu-Daudé
2021-04-10 13:19 ` Luc Michel
2021-04-10 13:53 ` Philippe Mathieu-Daudé
2021-04-10 15:15 ` Peter Maydell
2021-04-10 16:14 ` Philippe Mathieu-Daudé
2021-04-12 10:11 ` Peter Maydell
2021-04-12 10:31 ` Philippe Mathieu-Daudé
2021-04-12 10:44 ` Peter Maydell
2021-04-12 11:00 ` Philippe Mathieu-Daudé
2021-04-13 19:43 ` Eduardo Habkost
2021-05-03 15:20 ` Igor Mammedov
2021-05-03 16:37 ` Philippe Mathieu-Daudé
2021-04-19 19:39 ` Luc Michel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=08698b00-e867-2e40-440b-89d303cbefef@amsat.org \
--to=f4bug@amsat.org \
--cc=damien.hedde@greensocs.com \
--cc=ehabkost@redhat.com \
--cc=luc@lmichel.fr \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).