[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160213011403.GI4847@codeaurora.org>
Date: Fri, 12 Feb 2016 17:14:03 -0800
From: Stephen Boyd <sboyd@...eaurora.org>
To: Michael Turquette <mturquette@...libre.com>
Cc: linux-clk@...r.kernel.org, lee.jones@...aro.org,
maxime.ripard@...e-electrons.com, maxime.coquelin@...com,
geert@...ux-m68k.org, heiko@...ech.de, andre.przywara@....com,
rklein@...dia.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v42 1/6] clk: Allow clocks to be marked as CRITICAL
On 02/11, Michael Turquette wrote:
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index b4db67a..993f775 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2484,6 +2484,11 @@ static int __clk_init(struct device *dev, struct clk *clk_user)
> if (core->ops->init)
> core->ops->init(core->hw);
>
> + if (core->flags & CLK_IS_CRITICAL) {
> + clk_core_prepare(core);
> + clk_core_enable(core);
> + }
What do we do if this is an orphan clk? From what I can tell
we're not going to increment the ref count on the parents that
may or may not appear at some later time when this flag is set.
Furthermore, do we want to propagate the CLK_IS_CRITICAL flag up
to all the parent clocks so that the warning mechanism spits out
errors for parent clocks? I suppose that may not be very useful
assuming refcounts are correct, but it may be useful to know
which clocks are critical and which ones aren't during debug.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Powered by blists - more mailing lists