On Thu, 2013-03-14 at 02:10 +0800, Stephen Warren wrote:
On 03/12/2013 11:40 PM, Bill Huang wrote:
On Wed, 2013-03-13 at 13:24 +0800, Stephen Warren wrote:
On 03/12/2013 11:08 PM, Bill Huang wrote:
On Wed, 2013-03-13 at 12:42 +0800, Stephen Warren wrote:
On 03/12/2013 07:47 PM, Bill Huang wrote:
On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: > On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: >> Add the below four notifier events so drivers which are interested in >> knowing the clock status can act accordingly. This is extremely useful >> in some of the DVFS (Dynamic Voltage Frequency Scaling) design. >> >> PRE_CLK_ENABLE >> POST_CLK_ENABLE >> PRE_CLK_DISABLE >> POST_CLK_DISABLE
...
Thanks, I know the point, but unfortunately there is no good choice for hooking this since those low level functions clk_enable/clk_disable will be called in interrupt context so it is not possible to send notify. We might need to come out a better approach if we can think of any. Currently I still think this is acceptable (Having all the drivers which are using our interested clocks call these function to enable/disable clock in their runtime_pm calls) though it's not perfect.
No, that definitely won't work. Not all drivers use those APIs, nor should they.
That will be too bad, it looks like we deadlock in the mechanism, we cannot change existing drivers behavior (that means some call clk_disable/enable directly, some are not), and we cannot hook notifier in clk_disable/enable either, that means there seems no any chance to get what we want, any idea?
I don't know the correct answer.
But I have a question: Why can't we run notifications from the real clk_enable? Does the notification mechanism itself inherently block, or are we worried that implementations/receivers of these notifications might block. Perhaps we can simply define that these notification types
I think both.
may be triggered in atomic context and hence implementations have to support executing in atomic context. Is possible to make that a requirement? Is it possible to implement the code that receives these notifications in atomic context?
Making it executing in atomic context won't work since for DVFS we generally having to set voltage (while receiving the notify) through I2C interface which can sleep.
Is it possible to defer triggering of notifications to some non-atomic context, even if they happen in an atomic context?
I don't think deferring will work either, considering the usage of DVFS, device voltage is tightly coupled with frequency, when clock rate is about to increase, we have to boost voltage first and we can lower the voltage after the clock rate has decreased. All the above sequence have to be guaranteed or you might crash, so deferring not only make thing complicated in controlling the order but also hurt performance.
I also wonder if this is the right conceptual level to be hooking into the system. Perhaps DVFS is not something that should be triggered by noticing that clocks have changed rates, but rather it should be some form of higher layer that controls (calls into) both the regulator and clock APIs?
I wonder will there be a feasible API can do that since most of SoC is characterizing DVFS on frequency vs. voltage, it makes sense that reviewing voltage when the clock rate change happen, and the only mechanism seem to be hooking notifier in not only clock rate change but also clock enable/disable.