From: bilhuang@nvidia.com (Bill Huang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
Date: Tue, 19 Mar 2013 19:55:49 -0700 [thread overview]
Message-ID: <1363748149.8815.16.camel@bilhuang-vm1> (raw)
In-Reply-To: <20130319170140.8663.93388@quantum>
On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote:
> Quoting Bill Huang (2013-03-19 06:28:32)
> > Add notifier calls in clk_prepare and clk_unprepare so drivers which are
> > interested in knowing that clk_prepare/unprepare call can act accordingly.
> >
> > The existing "clk_set_rate" notifier is not enough for normal DVFS
> > inplementation since clock might be enabled/disabled at runtime. Adding
> > these notifiers is useful on DVFS core which take clk_prepare as a hint
> > on that the notified clock might be enabled later so it can raise voltage
> > to a safe level before enabling the clock, and take clk_unprepare as a
> > hint that the clock has been disabled and is safe to lower the voltage.
> >
> > The added notifier events are:
> >
> > PRE_CLK_PREPARE
> > POST_CLK_PREPARE
> > ABORT_CLK_PREPARE
> > PRE_CLK_UNPREPARE
> > POST_CLK_UNPREPARE
> >
> > Signed-off-by: Bill Huang <bilhuang@nvidia.com>
>
> I'm still not sure about this approach. Based on feedback I got from
> Linaro Connect I am not convinced that scaling voltage through clk
> rate-change notifiers is the right way to go. As I understand it this
> patch only exists for that single purpose, so if the voltage-notifier
> idea gets dropped then I will not take this patch in.
>
Thanks Mike, actually we won't use your "clk: notifier handler for
dynamic voltage scaling" patch instead we are trying to port our DVFS
into Non-CPU DVFS framework "devfreq" which will need to hook those
notifiers, without the clock notifiers been extended the framework is
useless for us since we cannot do polling due to the fact that polling
is not in real time. If it ended up extending the notifiers cannot
happen then the only choice for us I think would be giving up "devfreq"
and implement them in Tegra's "clk_hw".
next prev parent reply other threads:[~2013-03-20 2:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 13:28 [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare Bill Huang
2013-03-19 17:01 ` Mike Turquette
2013-03-20 2:55 ` Bill Huang [this message]
2013-03-20 3:31 ` Mike Turquette
2013-03-20 4:39 ` Bill Huang
2013-03-20 14:47 ` Mike Turquette
2013-03-20 21:06 ` Ulf Hansson
2013-03-21 22:36 ` Mike Turquette
2013-03-22 0:06 ` Colin Cross
2013-03-28 22:01 ` Mike Turquette
2013-03-28 22:24 ` Stephen Warren
2013-04-02 9:53 ` Peter De Schrijver
2013-03-21 1:03 ` Bill Huang
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=1363748149.8815.16.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).