All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: Marek Vasut <marex@denx.de>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-power <linux-power@rohmsemiconductoreurope.onmicrosoft.com>
Subject: Re: [PATCH 2/3] clk: Introduce 'critical-clocks' property
Date: Wed, 16 Feb 2022 12:06:53 +0000	[thread overview]
Message-ID: <c1fce212-4d9e-06fe-e3fe-6d0f2ab29489@fi.rohmeurope.com> (raw)
In-Reply-To: <20220215084412.8090-2-marex@denx.de>

Hi deee Ho Marek,

Long time no chatter :/ Nice to hear from you now!

On 2/15/22 10:44, Marek Vasut wrote:
> Some platforms require clock to be always running, e.g. because those clock
> supply devices which are not otherwise attached to the system. One example
> is a system where the SoC serves as a crystal oscillator replacement for a
> programmable logic device. The critical-clock property of a clock controller
> allows listing clock which must never be turned off.
> 
> The implementation here is similar to "protected-clock", except protected
> clock property is currently driver specific. This patch attempts to make
> a generic implementation of "critical-clock" instead.
> 
> Unlike "assigned-clocks", the "critical-clock" must be parsed much earlier
> in __clk_register() to assign CLK_IS_CRITICAL flag to clk_init_data .flags
> field. The parsing code obviously need to be cleaned up and factor out into
> separate function.
> 
> The new match_clkspec() callback is used to determine whether struct clk_hw
> that is currently being registered matches the clock specifier in the DT
> "critical-clock" property, and if so, then the CLK_IS_CRITICAL is added to
> these newly registered clock. This callback is currently driver specific,
> although I suspect a common and/or generic version of the callback could
> be added. Also, this new callback could possibly be used to replace (*get)
> argument of of_clk_add_hw_provider() later on too.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-power@fi.rohmeurope.com
> To: linux-clk@vger.kernel.org
> ---
>   drivers/clk/clk.c            | 41 ++++++++++++++++++++++++++++++++++++
>   include/linux/clk-provider.h |  3 +++
>   2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 8de6a22498e70..1e1686fa76e01 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3872,6 +3872,45 @@ static void clk_core_free_parent_map(struct clk_core *core)
>   	kfree(core->parents);
>   }
>   
> +static void
> +__clk_register_critical_clock(struct device_node *np, struct clk_core *core,
> +			      struct clk_hw *hw)
> +{
> +	struct of_phandle_args clkspec;
> +	u32 clksize, clktotal;
> +	int ret, i, index;
> +
> +	if (!np)
> +		return;
> +
> +	if (!core->ops->match_clkspec)
> +		return;
> +
> +	if (of_property_read_u32(np, "#clock-cells", &clksize))
> +		return;
> +
> +	/* Clock node with #clock-cells = <0> uses critical-clocks; */
> +	if (clksize == 0) {
> +		if (of_property_read_bool(np, "critical-clocks") &&
> +		    !core->ops->match_clkspec(hw, &clkspec))

I think this is never true as there is
if (!core->ops->match_clkspec)
	return;

above.

Anyways, seeing you added a dummy bd71837_match_clkspec in a follow-up 
patch for BD71837 - which has only single clock - I wonder if there is a 
way to omit that dummy callback in controllers which really provide only 
one clock? Eg, do you think such a situation could be detected by the 
core already here? Please just go on if that is hard - I was just 
thinking that maybe we could avoid such dummies - or at least provide 
one single dummy helper for that purpose instead of adding one in all 
similar drivers. How do you think?

Other than this - I still do like this idea! Thanks for working to 
implement this!


Best Regards
	-- Matti

-- 
The Linux Kernel guy at ROHM Semiconductors

Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~ this year is the year of a signature writers block ~~

  parent reply	other threads:[~2022-02-16 12:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  8:44 [PATCH 1/3] dt-bindings: clk: Introduce 'critical-clocks' property Marek Vasut
2022-02-15  8:44 ` [PATCH 2/3] " Marek Vasut
2022-02-15 11:23   ` kernel test robot
2022-02-15 11:23     ` kernel test robot
2022-02-15 13:57   ` kernel test robot
2022-02-15 13:57     ` kernel test robot
2022-02-16 12:06   ` Vaittinen, Matti [this message]
2022-02-16 16:52     ` Marek Vasut
2022-02-17  5:01       ` Vaittinen, Matti
2022-02-17 13:43         ` Marek Vasut
2022-02-17 22:23   ` Stephen Boyd
2022-02-21  0:58     ` Marek Vasut
2022-03-09 20:54       ` Marek Vasut
2022-03-12  5:04         ` Stephen Boyd
2022-03-12 10:26           ` Marek Vasut
2022-03-15 23:52             ` Stephen Boyd
2022-03-16 11:30               ` Marek Vasut
2022-05-03 19:17                 ` Marek Vasut
2022-02-15  8:44 ` [PATCH 3/3] clk: bd718xx: Implement basic .match_clkspec Marek Vasut
2022-02-15 20:55 [PATCH 2/3] clk: Introduce 'critical-clocks' property kernel test robot

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=c1fce212-4d9e-06fe-e3fe-6d0f2ab29489@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-power@rohmsemiconductoreurope.onmicrosoft.com \
    --cc=marex@denx.de \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.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 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.