From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/4] [RFC] clk: new locking scheme for reentrancy
Date: Wed, 29 Aug 2012 14:41:02 -0700 [thread overview]
Message-ID: <20120829214102.4450.35547@nucleus> (raw)
In-Reply-To: <CADTbHxob_pkYN_73AD4YL_Ki5i40iLTJuN0rPuFzYcyyhfoMAQ@mail.gmail.com>
Quoting Pankaj Jangra (2012-08-27 10:05:29)
> Hi Mike,
>
> On Thu, Aug 16, 2012 at 5:13 AM, Mike Turquette <mturquette@linaro.org> wrote:
> > +}
> > +
> > +void __clk_unprepare(struct clk *clk, struct clk *top)
>
> Why do you need to change the signature of __clk_prepare and
> __clk_unprepare functions ?
> I mean i did not understand the use of passing struct clk *top? As i
> understand, it tells when you reach at the last
> clk struct in the tree which needs to be prepared/unprepared. Do we
> have extra benefit of this or if i am missing something?
>
This series breaks compatibility with the internal clk functions. So if
you were using __clk_prepare in your code somewhere then this will no
longer work. It is likely you could just call clk_prepare in the same
place since there is some reentrancy introduced in this series.
Your understanding of top is correct: I want to avoid walking to the
root of the clock tree every time. We determine the top based on
finding a positive clk->enable_count value. There is no "extra
benefit", but locking to the root of the tree would destroy the goal of
reentrancy since there would be locking collisions at the top of the
tree.
<snip>
> > + if (IS_ERR(top)) {
> > + pr_debug("%s: %s failed with %ld on attempt %d\n",
> > + __func__, clk->name, PTR_ERR(top),
> > + tries);
> > + wait_for_completion(&clk_completion);
> > + if (WAIT_TRIES == ++tries)
> > + break;
> > + } else
> > + break;
>
> Braces around else part please.
>
OK.
> > + }
> > +
> > + if (WAIT_TRIES == tries) {
> > + pr_warning("%s: failed to lock clocks; cyclical dependency?\n",
> > + __func__);
> > + return;
> > + }
> > +
> > + /* unprepare the list of clocks from clk to top */
> > + __clk_unprepare(clk, top);
> > +
>
> > + /* unprepare the list of clocks from clk to top */
> > + __clk_prepare(clk, top);
>
> You mean prepare right ? :)
>
Right. Will fix in next version of RFC.
Thanks much for the review,
Mike
>
>
> Regards,
> Pankaj Kumar
next prev parent reply other threads:[~2012-08-29 21:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 23:43 [PATCH v2 0/4] [RFC] reentrancy in the common clk framework Mike Turquette
2012-08-15 23:43 ` [PATCH v2 1/4] [RFC] clk: new locking scheme for reentrancy Mike Turquette
2012-08-27 17:05 ` Pankaj Jangra
2012-08-29 21:41 ` Mike Turquette [this message]
2012-09-04 14:25 ` Shawn Guo
2012-08-15 23:43 ` [PATCH v2 2/4] [RFC] clk: notifier handler for dynamic voltage scaling Mike Turquette
2012-08-15 23:43 ` [PATCH v2 3/4] [RFC] cpufreq: omap: scale regulator from clk notifier Mike Turquette
2012-08-15 23:43 ` [PATCH v2 4/4] [RFC] omap3+: clk: dpll: call clk_prepare directly Mike Turquette
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=20120829214102.4450.35547@nucleus \
--to=mturquette@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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).