[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190927001425.DFDC7207FF@mail.kernel.org>
Date: Thu, 26 Sep 2019 17:14:25 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Neil Armstrong <narmstrong@...libre.com>, jbrunet@...libre.com,
mturquette@...libre.com
Cc: Neil Armstrong <narmstrong@...libre.com>,
linux-clk@...r.kernel.org, linux-amlogic@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/2] clk: introduce clk_invalidate_rate()
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 <narmstrong@...libre.com>
> ---
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".
Powered by blists - more mailing lists