From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] clk: shmobile: rcar-gen2: Use kick bit to allow Z clock frequency change
Date: Wed, 26 Feb 2014 21:53:03 +0000 [thread overview]
Message-ID: <2510385.4lBXQqHTss@avalon> (raw)
In-Reply-To: <530C9D2A.8030409@baylibre.com>
Hi Mike,
On Wednesday 26 February 2014 12:54:55 Mike Turquette wrote:
> Quoting Laurent Pinchart (2014-02-25 09:48:38)
> > On Tuesday 25 February 2014 18:07:54 Benoit Cousson wrote:
> > > On 25/02/2014 17:01, Laurent Pinchart wrote:
> > > > On Tuesday 25 February 2014 14:39:54 Benoit Cousson wrote:
> > > >> + /*
> > > >> + * Set KICK bit in FRQCRB to update hardware setting and
> > > >> + * wait for completion.
> > > >> + */
> > > >> + kick = clk_readl(zclk->kick_reg);
> > > >> + kick |= CPG_FRQCRB_KICK;
> > > >> + clk_writel(kick, zclk->kick_reg);
> > > >
> > > > Does CCF guarantee that two set_rate calls for different clocks will
> > > > not occur concurrently ? If so a brief comment would be nice.
> > > > Otherwise we need a lock around this.
> > >
> > > So far, this is the only user of the register. That's why there is no
> > > lock. It is explained in the changelog. But if you want I can re-use the
> > > same comment here.
> >
> > A comment would be nice, yes. You can make it shorter than the commit
> > message.
>
> CCF holds a global mutex during a call to clk_set_rate. So clk_prepare,
> clk_unprepare, clk_set_parent or a competing clk_set_rate will not touch
> this register during the critical section.
>
> However it is possible to reenter the framework, but usually you control
> that code flow.
>
> The main two reasons to introduce your own more granular register-level
> locking are:
>
> 1) clk_enable & clk_disable hold a separate global spinlock (not the
> global mutex), so if this register is used for set_rate operations AND
> enable/disable operations then you'll need a spinlock.
>
> 2) Other stuff outside of the clk framework touches this register
> (sounds like it is not the case here).
Thanks a lot for the explanation. I've cooked up a small documentation patch
to avoid the need to repeat this over and over, I'll send it separately.
Looking at the implementation I found something that looked like a locking bug
in the Qualcomm clock drivers at first sight.
clk-rpg.c calls __clk_is_enabled() from within its configure_bank() function.
That function ends up being called from within the .set_rate, .set_parent and
.set_rate_and_parent operations. This leads to __clk_is_enabled() being called
without the enable spinlock held.
Now, clk-rpg.c provides an .is_enabled handler (clk_is_enabled_regmap) so
we're at least not accessing the clock enable_count counter without the proper
lock being held. I don't know whether clk_is_enabled_regmap() will handle
locking properly though.
Exporting __clk_is_enabled() looks a bit dangerous to me. It might make sense
to replace the __clk_is_enabled() call in clk-rpg.c with a direct call to
clk_is_enabled_regmap(), but we still have two other users (namely
drivers/cpufreq/kirkwood-cpufreq.c and arch/arm/mach-omap2/pm24xx.c) in the
mainline kernel.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-02-26 21:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 13:39 [PATCH] clk: shmobile: rcar-gen2: Use kick bit to allow Z clock frequency change Benoit Cousson
2014-02-25 15:59 ` Laurent Pinchart
2014-02-25 17:07 ` Benoit Cousson
2014-02-25 17:48 ` Laurent Pinchart
2014-02-26 20:54 ` Mike Turquette
2014-02-26 21:53 ` Laurent Pinchart [this message]
2014-02-27 0:50 ` Stephen Boyd
2014-02-27 22:46 ` Laurent Pinchart
2014-02-28 0:03 ` Stephen Boyd
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=2510385.4lBXQqHTss@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-sh@vger.kernel.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.