From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
Stephen Boyd <sboyd@codeaurora.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Michael Turquette <mturquette@baylibre.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
linux-clk <linux-clk@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] clk: add more managed APIs
Date: Tue, 31 Jan 2017 09:43:16 +0100 [thread overview]
Message-ID: <CAMuHMdW9Sx7nw6yYpvqNZ9WPHD1rsDe5HVRrmJj=xswGT=7D0g@mail.gmail.com> (raw)
In-Reply-To: <20170130225138.GA14987@roeck-us.net>
Hi Günter,
On Mon, Jan 30, 2017 at 11:51 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Jan 30, 2017 at 09:42:28PM +0000, Russell King - ARM Linux wrote:
>> On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote:
>> > Maybe the additional calls make sense; I can imagine they would.
>> > However, I personally would be a bit wary of changing the initialization
>> > order of multi-clock initializations, and I am not sure how a single call
>> > could address setting the rate ([devm_]clk_get_setrate_prepare_enable()
>> > seems like a bit too much).
>> >
>> > [ On a side note, why is there no clk_get_prepare_enable() and
>> > clk_get_prepare() ? Maybe it would be better to introduce those
>> > together with the matching devm_ functions in a separate patch
>> > if they are useful. ]
>>
>> If you take the view that trying to keep clocks disabled is a good way
>> to save power, then you'd have the clk_prepare() or maybe
>> clk_prepare_enable() in your runtime PM resume handler, or maybe even
>> deeper in the driver... the original design goal of the clk API was to
>> allow power saving and clock control.
>>
>> With that in mind, getting and enabling the clock together in the
>> probe function didn't make sense.
>>
>> I feel that aspect has been somewhat lost, and people now regard much
>> of the clk API as a bit of a probe-time nusience.
>
> While I understand what you are saying, I think just focusing on power
> savings paints a bit of a simplistic view of the clock API and its use.
> Power saving is not its only use case. In a system where power saving isn't
> the highest priority (say, in a high end switch), it is still extremely
> valuable, providing a unified API to the clocks in the system (and there
> are lots of clocks in a high end switch). Having seen what happens if there
> is _no_ unified API (ie a complete mess of per-clock-driver calls all over
> the place), I consider this as at least as or even more important than its
> power savings potential. In this use case, one would normally both get and
> enable the clock (or, much more likely, clocks) in the probe function.
> One would also need remove functions, since interfaces in a high end switch
> are typically OIR capable.
>
> For my part, I stumbled over the lack of devm functions for clock APIs recently
> when trying to convert watchdog drivers to use devm functions where possible.
> Many watchdog drivers do use the clock API to only enable the clock when the
> watchdog is actually running. However, there are several which prepare and
> enable the clock at probe time, and disable/unprepare on remove. Would it be
> possible to convert those to only prepare/enable the clocks if the watchdog
> is actually enabled ? Possibly, but I am sure that there are cases where that
> is not possible, or feasible. Either way, watchdog drivers are usually only
> loaded when actually used, so trying to optimize clock usage would often be
> more pain than it is worth.
>
> When I did that conversion, I started out using devm_add_action_or_reset().
> While that does work, it was pointed out that using devm functions for the
> clock APIs would be a much better solution. As it turns out, devm_add_action()
> and devm_add_action_or_reset() is already being used by various drivers to
> work around the lack of devm functions for the clock API. With that in mind,
> have a choice to make - we can continue forcing people to do that, or we can
> introduce devm functions. My vote is for the latter.
W.r.t. clocks, there may be multiple reasons why you care about them:
1. You need to control a clock output to a slave device (e.g. SPI, i2c,
audio, ...).
Here your driver cares about both enabling/disabling the clock, and
programming its clock rate.
2. You need to control a clock because synchronous hardware needs a running
clock to operate.
Here you only care about enabling/disabling the clock, and this falls
under the "power saving" umbrella.
These days it's typically handled by a clock domain driver implementing
a PM Domain using the genpd framework. Hence your driver doesn't need
to manage the clock explicitly (no clk_get()/clk_prepare_enable() etc.),
but just calls the pm_runtime_*() functions.
Using pm_runtime_*() is always a good idea, even if currently there is
no clock to control, as your device may end up in a future SoC that does
have a clock (or power domains).
3. Combinations of the above.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2017-01-31 8:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-28 18:40 [PATCH] clk: add more managed APIs Dmitry Torokhov
2017-01-28 19:03 ` Russell King - ARM Linux
2017-01-28 19:22 ` Dmitry Torokhov
2017-01-28 21:44 ` Guenter Roeck
2017-01-28 23:39 ` Russell King - ARM Linux
2017-01-29 16:00 ` Guenter Roeck
2017-01-29 18:07 ` [PATCH v2] " Dmitry Torokhov
2017-01-29 18:31 ` Guenter Roeck
2017-01-30 18:55 ` Stephen Boyd
2017-01-30 19:22 ` Guenter Roeck
2017-01-30 21:42 ` Russell King - ARM Linux
2017-01-30 21:58 ` Dmitry Torokhov
2017-01-30 22:25 ` Russell King - ARM Linux
2017-01-30 22:51 ` Guenter Roeck
2017-01-31 8:43 ` Geert Uytterhoeven [this message]
2017-01-31 0:59 ` Dmitry Torokhov
2017-01-31 17:20 ` Guenter Roeck
2017-01-31 18:26 ` Dmitry Torokhov
2017-01-31 19:34 ` Guenter Roeck
2017-01-31 0:57 ` [PATCH v3] " Dmitry Torokhov
2017-02-07 3:51 ` Dmitry Torokhov
2017-02-14 19:44 ` Stephen Boyd
2017-02-14 19:55 ` Dmitry Torokhov
2017-02-14 20:31 ` Guenter Roeck
2017-02-14 20:01 ` Russell King - ARM Linux
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='CAMuHMdW9Sx7nw6yYpvqNZ9WPHD1rsDe5HVRrmJj=xswGT=7D0g@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=andy.shevchenko@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@roeck-us.net \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
--cc=viresh.kumar@linaro.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).