From: Jerome Brunet <email@example.com>
To: Neil Armstrong <firstname.lastname@example.org>,
Stephen Boyd <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Subject: Re: [PATCH RFC 1/2] clk: introduce clk_invalidate_rate()
Date: Fri, 27 Sep 2019 18:38:45 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Fri 27 Sep 2019 at 08:40, Neil Armstrong <email@example.com> wrote:
> On 27/09/2019 02:14, Stephen Boyd wrote:
>> Quoting Neil Armstrong (2019-09-19 03:25:17)
>>> This introduces the clk_invalidate_rate() call used to recalculate the
>>> rate and parent tree of a particular clock if it's known that the
>>> underlying registers set has been altered by the firmware, like from
>>> a suspend/resume handler running in trusted cpu mode.
>>> The call refreshes the actual parent and when changed, instructs CCF
>>> the parent has changed. Finally the call will recalculate the rate of
>>> each part of the tree to make sure the CCF cached tree is in sync with
>>> the hardware.
>>> Signed-off-by: Neil Armstrong <firstname.lastname@example.org>
>> The knee-jerk reaction to these patches is that it shouldn't be a
>> consumer API (i.e. taking a struct clk) but a provider API (i.e. taking
>> a struct clk_hw). I haven't looked in any more detail but just know that
>> it's a non-starter to be a consumer based API because we don't want
>> random consumers out there to be telling the CCF or provider drivers
>> that some clk has lost state and needs to be "refreshed".
> Totally agree, I hesitated and obviously did the wrong choice, but
> this is a nit, the main algorithm is not tied to the API level.
> Should I resend it with clk_hw ? the difference will be small and
> the main subject is the resync algorithm.
Independent of the point above (partly a least), I wonder what will
happen in some particular use cases
* If clock is changed while in suspend. This clock can be a parent of
the clock invalidated but currently is not. What happen, if later,
it becomes the parent ?
Since it is not parent on resume it won't be invalidated. CCF might
still take a decision based on an invalid cached value.
* If a mux is changed while in suspend, the parent is not correct
anymore. The proposed patch recurse through the parents, it might
not invalidate what we need/expect ... things are getting a bit
IOW, this change take a leaf clock and tries to tell CCF that any parent
of this clock should not be trusted, but it might get it wrong in some
I think we should do it in the opposite way:
* Mark the "rogue" clock with a flag (CLK_REFRESH ?)
* Let CCF update the children of these clocks based on the new status
Back to Stephen point, I don't know which API it should be, but I
think the platform (fw driver or power stuff - not only clock provider)
should be able somehow to trigger the mechanism to let CCF know
something sketchy may have happened.
For the parameter, maybe there should not be any (no struct clk or
clk_hw) ? Maybe it would better if we let CCF refresh all the "rogue"
linux-amlogic mailing list
next prev parent reply other threads:[~2019-09-27 16:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 10:25 [PATCH RFC 0/2] clk: meson: g12a: handle clock hw changes while in suspend Neil Armstrong
2019-09-19 10:25 ` [PATCH RFC 1/2] clk: introduce clk_invalidate_rate() Neil Armstrong
2019-09-27 0:14 ` Stephen Boyd
2019-09-27 6:40 ` Neil Armstrong
2019-09-27 16:38 ` Jerome Brunet [this message]
2019-09-19 10:25 ` [PATCH RFC 2/2] clk: meson: g12a: add suspend-resume hooks Neil Armstrong
2019-09-26 20:46 ` [PATCH RFC 0/2] clk: meson: g12a: handle clock hw changes while in suspend Kevin Hilman
2019-09-27 6:38 ` Neil Armstrong
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).