From: saiprakash.ranjan@codeaurora.org
To: Stephen Boyd <sboyd@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, Rob Clark <robclark@gmail.com>,
Sean Paul <seanpaul@chromium.org>,
linux-arm-msm-owner@vger.kernel.org
Subject: Re: [RFC] clk: Remove cached cores in parent map during unregister
Date: Wed, 21 Aug 2019 18:42:50 +0000 [thread overview]
Message-ID: <cda27c942f332d9da47fe8c4c5305207@codeaurora.org> (raw)
In-Reply-To: <20190821181009.00D6322D6D@mail.kernel.org>
Hi Stephen,
On 2019-08-21 18:10, Stephen Boyd wrote:
>
> Here's an attempt at the simple approach. There's another problem where
> the cached 'hw' member of the parent data is held around when we don't
> know when the caller has destroyed it. Not much else we can do for that
> though.
>
> ---8<---
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index c0990703ce54..f42a803fb11a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3737,6 +3737,37 @@ static const struct clk_ops clk_nodrv_ops = {
> .set_parent = clk_nodrv_set_parent,
> };
>
> +static void clk_core_evict_parent_cache_subtree(struct clk_core *root,
> + struct clk_core *target)
> +{
> + int i;
> + struct clk_core *child;
> +
> + if (!root)
> + return;
> +
> + for (i = 0; i < root->num_parents; i++)
> + if (root->parents[i].core == target)
> + root->parents[i].core = NULL;
> +
> + hlist_for_each_entry(child, &root->children, child_node)
> + clk_core_evict_parent_cache_subtree(child, target);
> +}
> +
> +/* Remove this clk from all parent caches */
> +static void clk_core_evict_parent_cache(struct clk_core *core)
> +{
> + struct hlist_head **lists;
> + struct clk_core *root;
> +
> + lockdep_assert_held(&prepare_lock);
> +
> + for (lists = all_lists; *lists; lists++)
> + hlist_for_each_entry(root, *lists, child_node)
> + clk_core_evict_parent_cache_subtree(root, core);
> +
> +}
> +
> /**
> * clk_unregister - unregister a currently registered clock
> * @clk: clock to unregister
> @@ -3775,6 +3806,8 @@ void clk_unregister(struct clk *clk)
> clk_core_set_parent_nolock(child, NULL);
> }
>
> + clk_core_evict_parent_cache(clk->core);
> +
> hlist_del_init(&clk->core->child_node);
>
> if (clk->core->prepare_count)
Thanks for the patch. This fixes the dispcc issue which I was observing
with latest kernel on cheza.
You can have the tested by when you post the actual patch.
Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
For reference, below is the error log:
[ 3.992243] msm ae00000.mdss: Adding to iommu group 1
[ 3.999877] msm ae00000.mdss: bound ae01000.mdp (ops
0xffffff8010a87b78)
[ 4.023597] msm ae00000.mdss: failed to bind ae94000.dsi (ops
0xffffff8010a8b360): -517
[ 4.031898] msm ae00000.mdss: master bind failed: -517
[ 5.297509] msm ae00000.mdss: bound ae01000.mdp (ops
0xffffff8010a87b78)
[ 5.320906] msm ae00000.mdss: failed to bind ae94000.dsi (ops
0xffffff8010a8b360): -517
[ 5.329261] msm ae00000.mdss: master bind failed: -517
[ 5.648667] msm ae00000.mdss: bound ae01000.mdp (ops
0xffffff8010a87b78)
[ 5.672005] clk_core_set_parent_nolock: clk dsi0_phy_pll_out_byteclk
can not be parent of clk disp_cc_mdss_byte0_clk_src p_index=-22 <---
error
[ 5.699799] msm ae00000.mdss: failed to bind ae94000.dsi (ops
0xffffff8010a8b360): -22
[ 5.708086] msm ae00000.mdss: master bind failed: -22
[ 5.714052] msm: probe of ae00000.mdss failed with error -22
[ 6.033541] clk_core_set_parent_nolock: clk dsi0_phy_pll_out_dsiclk
can not be parent of clk disp_cc_mdss_pclk0_clk_src p_index=-22 <---
error
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2019-08-21 18:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-23 5:14 [RFC] clk: Remove cached cores in parent map during unregister Bjorn Andersson
2019-07-29 22:46 ` Stephen Boyd
2019-08-21 18:10 ` Stephen Boyd
2019-08-21 18:42 ` saiprakash.ranjan [this message]
2019-08-26 21:24 ` Stephen Boyd
2019-09-17 15:34 ` Raul Rangel
2019-09-17 15:55 ` Sai Prakash Ranjan
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=cda27c942f332d9da47fe8c4c5305207@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robclark@gmail.com \
--cc=sboyd@kernel.org \
--cc=seanpaul@chromium.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.