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

[Bill Huang]

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.