linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: bilhuang@nvidia.com (Bill Huang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
Date: Thu, 14 Mar 2013 18:20:54 -0700	[thread overview]
Message-ID: <1363310454.3311.44.camel@bilhuang-vm1> (raw)
In-Reply-To: <51420EBB.7080503@wwwdotorg.org>

On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote:
> On 03/14/2013 03:28 AM, Bill Huang wrote:
> > On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
> >> On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote:
> >>
> >>> I don't think deferring will work either, considering the usage of DVFS,
> >>> device voltage is tightly coupled with frequency, when clock rate is
> >>> about to increase, we have to boost voltage first and we can lower the
> >>> voltage after the clock rate has decreased. All the above sequence have
> >>> to be guaranteed or you might crash, so deferring not only make thing
> >>> complicated in controlling the order but also hurt performance.
> >>
> >> But we could use notifiers in clk_prepare/clk_unprepare to set the voltage no?
> >> As clk_prepare/clk_unprepare have to be called before clk_enable or after
> >> clk_disable, the voltage can be raised to a safe level, before the clock
> >> becomes active.
> > 
> > Thanks Peter, actually I'm just about to propose my v2 RFC which add
> > notifier in clk_prepare/clk_unprepare.
> 
> Can't clk_set_rate() be called while the clock is prepared, or even
> enabled? I don't see how your proposal would work.
> 
I think it works with just a little sacrifice on saving more power but
that's related minor. Taking clk_prepare as an indicator on that clock
will be enabled later, so we can raise the voltage to a safe level
(according to the current rate or maybe default rate when clk_prepare is
called, some time late when clk_set_rate() is called we can adjust again
according to the requested rate change) but there should be case that
clock will not be enabled after clk_prepare (I'm not sure is normal
though), that the case power might be wasted. Similarly, taking
clk_unprepare as an indicator on clock has been disabled but there might
be case clock is disabled but do not call clk_unprepare any time soon,
this is another case power is wasted but this should not be normal case.
So the point is, we can get notified on runtime clock change events (no
matter it is clock enable/disable or clock rate change) and act (get
best balance on power saving and system stability) accordingly.

  reply	other threads:[~2013-03-15  1:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-12 12:37 [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare Bill Huang
2013-03-12 13:40 ` Russell King - ARM Linux
2013-03-13  1:47   ` Bill Huang
2013-03-13  4:42     ` Stephen Warren
2013-03-13  5:08       ` Bill Huang
2013-03-13  5:24         ` Stephen Warren
2013-03-13  5:40           ` Bill Huang
2013-03-13 18:10             ` Stephen Warren
2013-03-14  2:15               ` Bill Huang
2013-03-14  9:21                 ` Peter De Schrijver
2013-03-14  9:28                   ` Bill Huang
2013-03-14 17:54                     ` Stephen Warren
2013-03-15  1:20                       ` Bill Huang [this message]
2013-03-15  5:22                         ` Stephen Warren
2013-03-15  5:48                           ` Bill Huang
2013-03-15  9:39                           ` Peter De Schrijver
2013-03-15 10:08                             ` Ulf Hansson
2013-03-15 12:06                               ` Bill Huang
2013-03-15 12:33                                 ` Ulf Hansson
2013-03-15 19:38                                   ` Stephen Warren
2013-03-16  1:54                                     ` Bill Huang
2013-03-18 10:36                                     ` Ulf Hansson
2013-03-21 22:28                                       ` Mike Turquette
2013-03-16  2:23                                   ` Bill Huang
2013-03-15 17:12                           ` Russell King - ARM Linux
2013-03-15 17:09             ` Russell King - ARM Linux
2013-03-16  2:25               ` Bill Huang
2013-03-15 16:59       ` Russell King - ARM Linux
2013-03-15 16:57     ` Russell King - ARM Linux
2013-03-15 18:44       ` Nicolas Pitre

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=1363310454.3311.44.camel@bilhuang-vm1 \
    --to=bilhuang@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.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).