linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Neil Armstrong <narmstrong@baylibre.com>,
	jbrunet@baylibre.com, mturquette@baylibre.com
Cc: Neil Armstrong <narmstrong@baylibre.com>,
	linux-clk@vger.kernel.org, linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 1/2] clk: introduce clk_invalidate_rate()
Date: Thu, 26 Sep 2019 17:14:25 -0700	[thread overview]
Message-ID: <20190927001425.DFDC7207FF@mail.kernel.org> (raw)
In-Reply-To: <20190919102518.25126-2-narmstrong@baylibre.com>

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@baylibre.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".


  reply	other threads:[~2019-09-27  0:14 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 [this message]
2019-09-27  6:40     ` Neil Armstrong
2019-09-27 16:38       ` Jerome Brunet
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

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=20190927001425.DFDC7207FF@mail.kernel.org \
    --to=sboyd@kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=narmstrong@baylibre.com \
    /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).