From: Mike Turquette <mturquette@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Barry Song <baohua@kernel.org>,
Sachin Kamat <sachin.kamat@linaro.org>,
linux-arm-msm@vger.kernel.org,
Peter De Schrijver <pdeschrijver@nvidia.com>,
linux-kernel@vger.kernel.org,
Viresh Kumar <viresh.linux@gmail.com>,
ccross@android.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
Date: Wed, 08 Oct 2014 19:59:23 -0700 [thread overview]
Message-ID: <20141009025923.4379.66113@quantum> (raw)
In-Reply-To: <54348EC2.3040300@codeaurora.org>
Quoting Stephen Boyd (2014-10-07 18:09:22)
> On 09/29/2014 05:12 PM, Stephen Boyd wrote:
> > I'm also auditing clock
> > drivers to find potential brokenness.
> >
>
> These are places where we re-enter the framework under drivers/clk/. It
> looks like sirf can be ported to use determine_rate() and something like
> my "safe parent" patch. Tegra is concerning given that they call
> clk_get_rate() in atomic context which is bad because that
> clk_get_rate() can sleep on the prepare mutex. Otherwise we can probably
> just convert that to use the unlocked variants. I'm aware of the qcom
> one, maybe we need a framework flag that indicates that all parent
> clocks must be enabled to switch this clock's parent. The last one is
> versatile which I hope we can convert to use assigned-rates?
+Barry for SiRF
+Sachin for Versatile
+Viresh for SPEaR
+Peter for Tegra
For those just joining the thread, Stephen's proposal to replace the
global clk_prepare mutex with per-clock ww_mutexes breaks the reentrant
behavior of the clock framework. He has identified the below spots where
clock drivers rely on reentering into the framework. Can you take a look
at them and see if it is possible to handle it another way?
I'm pretty happy to get rid of reentrancy for two reasons:
1) Stephen's patch fixes the "spi deadlock problem", which reentrancy
did not solve. Reentrancy only solved the "i2c deadlock problem" which
the ww_mutex approach also solves nicely.
2) The current reentrancy scheme does not take advantage of lockdep for
checking correctness. It is very possible to silent hang yourself
(though I've not seen any reports of that ... yet).
Regards,
Mike
>
> drivers/clk/sirf/clk-common.c:409: ret1 = clk_set_parent(hw->clk,
> clk_pll1.hw.clk);
> drivers/clk/sirf/clk-common.c:414: ret1 = clk_set_parent(hw->clk,
> clk_pll2.hw.clk);
> drivers/clk/sirf/clk-common.c:419: ret1 = clk_set_parent(hw->clk,
> clk_pll3.hw.clk);
> drivers/clk/sirf/clk-common.c:427: ret1 = clk_set_parent(hw->clk,
> clk_pll2.hw.clk);
> drivers/clk/sirf/clk-common.c:433: ret1 = clk_set_parent(hw->clk,
> clk_pll1.hw.clk);
> drivers/clk/versatile/clk-sp810.c:103: clk_set_parent(hw->clk, new_parent);
> drivers/clk/sirf/clk-common.c:431: ret2 =
> clk_set_rate(clk_pll1.hw.clk, rate);
> drivers/clk/qcom/mmcc-msm8960.c:520: ret =
> clk_prepare_enable(clk_get_parent_by_index(clk, i));
> drivers/clk/qcom/mmcc-msm8960.c:549:
> clk_disable_unprepare(clk_get_parent_by_index(clk, i));
> Not necessary? drivers/clk/sirf/clk-common.c:168: struct clk
> *parent_clk = clk_get_parent(hw->clk);
> Not necessary? drivers/clk/sirf/clk-common.c:169: struct clk
> *pll_parent_clk = clk_get_parent(parent_clk);
> Not necessary! drivers/clk/sirf/clk-common.c:181: struct clk
> *parent_clk = clk_get_parent(hw->clk);
> drivers/clk/sirf/clk-common.c:423: cur_parent = clk_get_parent(hw->clk);
> drivers/clk/spear/clk-vco-pll.c:90:
> __clk_get_rate(__clk_get_parent(__clk_get_parent(hw->clk)));
> drivers/clk/tegra/clk-pll.c:732: unsigned long input_rate =
> clk_get_rate(clk_get_parent(hw->clk));
> drivers/clk/tegra/clk-pll.c:1288: unsigned long input_rate =
> clk_get_rate(clk_get_parent(hw->clk));
> drivers/clk/versatile/clk-sp810.c:82: struct clk *old_parent =
> __clk_get_parent(hw->clk);
> drivers/clk/qcom/mmcc-msm8960.c:520: ret =
> clk_prepare_enable(clk_get_parent_by_index(clk, i));
> drivers/clk/versatile/clk-sp810.c:102: clk_prepare(new_parent);
> drivers/clk/versatile/clk-sp810.c:104: clk_unprepare(old_parent);
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
next prev parent reply other threads:[~2014-10-09 2:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 1:01 [PATCH v2 0/4] Use wound/wait mutexes in the common clock framework Stephen Boyd
2014-09-04 1:01 ` [PATCH v2 1/4] clk: Recalc rate and accuracy in underscore functions if not caching Stephen Boyd
2014-09-04 1:01 ` [PATCH v2 2/4] clk: Make __clk_lookup() use a list instead of tree search Stephen Boyd
2014-09-04 1:01 ` [PATCH v2 3/4] clk: Use lockless functions for debug printing Stephen Boyd
2014-09-04 1:01 ` [PATCH v2 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock} Stephen Boyd
2014-09-28 2:41 ` Mike Turquette
2014-09-30 0:12 ` Stephen Boyd
2014-10-08 1:09 ` Stephen Boyd
2014-10-09 2:59 ` Mike Turquette [this message]
2014-10-10 8:24 ` Peter De Schrijver
2014-10-11 0:20 ` Stephen Boyd
2014-10-13 8:23 ` Peter De Schrijver
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=20141009025923.4379.66113@quantum \
--to=mturquette@linaro.org \
--cc=baohua@kernel.org \
--cc=ccross@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pdeschrijver@nvidia.com \
--cc=sachin.kamat@linaro.org \
--cc=sboyd@codeaurora.org \
--cc=viresh.linux@gmail.com \
/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).