On Wed, 27 Mar 2013, Ulf Hansson wrote:
On 27 March 2013 10:55, Viresh Kumar viresh.kumar@linaro.org wrote:
On 27 March 2013 15:10, Thomas Gleixner tglx@linutronix.de wrote:
On Wed, 27 Mar 2013, Mike Turquette wrote:
Reentrancy into the clock framework from the clk.h api is necessary for clocks that are prepared and unprepared via i2c_transfer (which includes many PMICs and discrete audio chips) as well as for several other use cases.
That explanation sucks.
Why does an i2c clock need reentrancy? Just because it's i2c or what?
I am noway connected to this development but was just going through your mail and i think i might know the answer why is this required.
Consider an example where an external chip has clock controller and has bits which can be programmed to enable/disable clock. And this chip is connected via spi/i2c to SoC.
clk_prepare(peripheral on external chip) -> i2c_xfer(to write to external chips register) -> clk_enable(i2c controller) ->controller-xfer-routine.. and finally we enable clk here...
Which does not explain the whole issue:
clk_prepare() takes the mutex clk_enable() takes the spinlock
That works today.
The issue arises, if you need to call clk_prepare(i2c) in the xfer routine.
Sorry if i am on the wrong side :)
Only slightly :)
I agree with you Viresh. I guess Mike should update the commit message.
I would also like add another reason to why this is needed. For some clks you would like to do pinctrl operations from a clk hw. But since a pinctrl driver likely requires a clk to be prepared|enabled, we run into a clk reentrant issue.
Fair enough. This all wants to go into the changelog, so we can understand why we have this business.
Thanks,
tglx