linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Heiko Stuebner <heiko@sntech.de>, mturquette@linaro.org
Cc: linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
	dianders@chromium.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/4] clk: add clk_is_orphan() to check if a clocks inherits from an orphan clock
Date: Fri, 10 Apr 2015 17:49:16 -0700	[thread overview]
Message-ID: <55286F8C.1030008@codeaurora.org> (raw)
In-Reply-To: <1427988853-9549-3-git-send-email-heiko@sntech.de>

On 04/02/15 08:34, Heiko Stuebner wrote:
> There are cases where it is helpful to know if the full clock path can be
> trusted or if there is a parent clock missing somewhere in the parent-path.
>
> We keep it confined to the ccf area for now, if later users outside the ccf
> surface it can be made more publically available.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
>  drivers/clk/clk.c | 38 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 512323f..476f491 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2271,6 +2271,44 @@ bool clk_is_match(const struct clk *p, const struct clk *q)
>  EXPORT_SYMBOL_GPL(clk_is_match);
>  
>  /**
> + * __clk_is_orphan - check if a clock or its parent is an orphan

@clk?

> + *
> + * Walks up the clock parents until it reaches a root-clock or
> + * a clock contained in the orphan list. Returns true if there is
> + * an orphan in the parent-path otherwise false.
> + */
> +static bool __clk_is_orphan(struct clk_core *clk)
> +{
> +	struct clk_core *orphan;
> +
> +	if (clk->flags & CLK_IS_ROOT)
> +		return false;
> +
> +	hlist_for_each_entry(orphan, &clk_orphan_list, child_node) {
> +		if (clk == orphan)
> +			return true;
> +	}

Nitpick: Please drop braces

> +
> +	if (clk->num_parents)
> +		return __clk_is_orphan(clk->parent);

This looks inefficient. Hopefully we're not calling this all the time?
Except we call it from clk_get().

Maybe it would make sense to mark the clock as orphaned or not. When we
regsiter the clock we can see if the parent is there and if so, check
the parent's flag to see if it's orphaned or not. If it isn't orphaned
everything is good, cheap lookup to figure it out and we don't set the
flag. If it is orphaned, again cheap lookup and we set the flag. When we
adopt the clock (deorphan?) we would have to go through the clock and
all it's children to clear the flag. The cost is paid once. Then this
function becomes a cheap flag check that we can do whenever we want.

> +
> +	return false;
> +}
> +
> +static bool clk_is_orphan(struct clk *clk)
> +{
> +	bool ret;
> +
> +	if (!clk)
> +		return false;
> +
> +	clk_prepare_lock();
> +	ret = __clk_is_orphan(clk->core);
> +	clk_prepare_unlock();

Unfortunately we still have to take some sort of lock here. If we had a
new lock, orphan_lock or something, then we could lock the adoption
phase and the flag setting of all clocks under that lock. When we go to
per-clock locks we could change that to use the lock for a particular clock.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


  reply	other threads:[~2015-04-11  0:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 15:34 [PATCH 0/4] clk: improve handling of orphan clocks Heiko Stuebner
2015-04-02 15:34 ` [PATCH 1/4] clk: Propagate prepare and enable when reparenting orphans Heiko Stuebner
2015-04-11  0:59   ` Stephen Boyd
2015-04-02 15:34 ` [PATCH 2/4] clk: add clk_is_orphan() to check if a clocks inherits from an orphan clock Heiko Stuebner
2015-04-11  0:49   ` Stephen Boyd [this message]
2015-04-02 15:34 ` [PATCH 3/4] clk: add CLK_DEFER_ORPHAN flag to prevent orphans from being used Heiko Stuebner
2015-04-11  0:52   ` Stephen Boyd
2015-04-11  1:32     ` Heiko Stübner
2015-04-02 15:34 ` [PATCH 4/4] clk: rockchip: enable CLK_DEFER_ORPHAN for all branches Heiko Stuebner

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=55286F8C.1030008@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@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).