All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Neil Armstrong <narmstrong@baylibre.com>,
	jbrunet@baylibre.com, mturquette@baylibre.com
Cc: linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Neil Armstrong <narmstrong@baylibre.com>
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".


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

WARNING: multiple messages have this Message-ID (diff)
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".


WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Neil Armstrong <narmstrong@baylibre.com>,
	jbrunet@baylibre.com, mturquette@baylibre.com
Cc: linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Neil Armstrong <narmstrong@baylibre.com>
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".


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-09-27  0:14 UTC|newest]

Thread overview: 24+ 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 ` Neil Armstrong
2019-09-19 10:25 ` Neil Armstrong
2019-09-19 10:25 ` [PATCH RFC 1/2] clk: introduce clk_invalidate_rate() Neil Armstrong
2019-09-19 10:25   ` Neil Armstrong
2019-09-19 10:25   ` Neil Armstrong
2019-09-27  0:14   ` Stephen Boyd [this message]
2019-09-27  0:14     ` Stephen Boyd
2019-09-27  0:14     ` Stephen Boyd
2019-09-27  6:40     ` Neil Armstrong
2019-09-27  6:40       ` Neil Armstrong
2019-09-27  6:40       ` Neil Armstrong
2019-09-27 16:38       ` Jerome Brunet
2019-09-27 16:38         ` Jerome Brunet
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-19 10:25   ` Neil Armstrong
2019-09-19 10:25   ` 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-26 20:46   ` Kevin Hilman
2019-09-26 20:46   ` Kevin Hilman
2019-09-27  6:38   ` Neil Armstrong
2019-09-27  6:38     ` Neil Armstrong
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.