Hi, Mike
We met a issue between clk_prepare_enable /clk_disable_unprepare and
clk_set_parent.
As we know, clk preprare/unprare will grab preprare lock, and clk
enable/disable will grab enable lock. clk_set_parent will grab prepare
lock
but there is no lock protection in clk_prepare_enable /clk_disable_unprepare,
for example, in clk_disable_unprepare, it is expended as clk_disable +
clk_unprepare,
and if below condition occurs, there will be problem
thread1 thread 2
call clk_disable_unprepare
1) clk_disable
get enable lock
...............
release enable lock
call clk_set_parent
get prepare lock
set clock's
parent to another parent
release prepare lock
2) clk_unprepare
get prepare lock
unprepare parent clock <<--------------
release prepare lock
In above sequence, After thread 1 call clock disable, thread 2 change
clk's parent to another clock, then in thread1 step2, it will
unprepare clk's new parent, but not old parent, this will cause old
parent is not unprepared, but new parent is unprepared even when it is
not prepared yet.
So How can we use this API: clk_prepare_enable and clk_disable_unprepare ?
Should we add lock to protect this API, if we get a prepare lock
inside this API, like
clk_disable_unprepare ()
{
get_prepare_lock();
clk_disable();
clk_unprepare();
clk_prepare_unlock();
}
is above sequence ok? if so, I can provide a patch for this.
Thanks
Xiaoguang
On Wed, Jan 22, 2014 at 02:02:57PM +0800, Xiaoguang Chen wrote:
> Hi, Mike
>
> We met a issue between clk_prepare_enable /clk_disable_unprepare and
> clk_set_parent.
clk_prepare_enable/disable_unprepare are perfectly fine in themselves.
You're looking at the problem wrongly - because drivers can perfectly
well call clk_prepare() and clk_unprepare() themselves. There's no
requirement for the enable and prepare to be paired together under any
kind of lock.
> and if below condition occurs, there will be problem
>
> thread1 thread 2
> call clk_disable_unprepare
Okay, if we're calling clk_disable_unprepare(), then the clock
must already have been prepared and enabled - which means that
the current parent is already prepared and enabled.
> 1) clk_disable
> get enable lock
> ...............
> release enable lock
This may result in the parent being disabled too.
>
> call clk_set_parent
> get prepare lock
> set clock's
> parent to another parent
At this point, the existing parent clock should be disabled if this
clock was enabled, and unprepared if this clock was prepared. The
new parent should be prepared and enabled as appropriate too so that
everything is kept balanced.
> release prepare lock
>
> 2) clk_unprepare
> get prepare lock
> unprepare parent clock <<--------------
> release prepare lock
And with the above guarantee - which is required in any case to make
reparenting safe - there's no problem here.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".