[RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Stephen Warren]

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
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?

Is it possible to defer triggering of notifications to some non-atomic
context, even if they happen in an atomic context?

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?