archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <>
To: Guenter Roeck <>
Cc: Russell King - ARM Linux <>,
	Stephen Boyd <>,
	Dmitry Torokhov <>,
	Michael Turquette <>,
	Viresh Kumar <>,
	Andy Shevchenko <>,
	linux-clk <>,
	"" <>
Subject: Re: [PATCH v2] clk: add more managed APIs
Date: Tue, 31 Jan 2017 09:43:16 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Günter,

On Mon, Jan 30, 2017 at 11:51 PM, Guenter Roeck <> 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.



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

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

  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] " 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2] clk: add more managed APIs' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).