Re: [RFC 1/1] clk: Add notifier support inclk_prepare_enable/clk_disable_unprepare

[Bill Huang]

On Fri, 2013-03-15 at 18:08 +0800, Ulf Hansson wrote:
> On 15 March 2013 10:39, Peter De Schrijver <pdeschrijver@xxxxxxxxxx> wrote:
> > On Fri, Mar 15, 2013 at 06:22:47AM +0100, Stephen Warren wrote:
> >> On 03/14/2013 07:20 PM, Bill Huang wrote:
> >> > On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote:
> >> >> On 03/14/2013 03:28 AM, Bill Huang wrote:
> >> >>> On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
> >> >>>> On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote:
> >> >>>>
> >> >>>>> 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.
> >> >>>>
> >> >>>> But we could use notifiers in clk_prepare/clk_unprepare to set the voltage no?
> >> >>>> As clk_prepare/clk_unprepare have to be called before clk_enable or after
> >> >>>> clk_disable, the voltage can be raised to a safe level, before the clock
> >> >>>> becomes active.
> >> >>>
> >> >>> Thanks Peter, actually I'm just about to propose my v2 RFC which add
> >> >>> notifier in clk_prepare/clk_unprepare.
> >> >>
> >> >> Can't clk_set_rate() be called while the clock is prepared, or even
> >> >> enabled? I don't see how your proposal would work.
> >> >
> >> > I think it works with just a little sacrifice on saving more power but
> >> > that's related minor. Taking clk_prepare as an indicator on that clock
> >> > will be enabled later, so we can raise the voltage to a safe level
> >> > (according to the current rate or maybe default rate when clk_prepare is
> >> > called, some time late when clk_set_rate() is called we can adjust again
> >> > according to the requested rate change)
> >>
> >> Is clk_set_rate() only legal to call in non-atomic contexts then? The
> >> header file doesn't say, although I guess since many other functions
> >> explicitly say they can't, then by omission it can...
> >
> > Yes. Only clk_enable() and clk_disable() can be called in an atomic context.
> >
> > Cheers,
> >
> > Peter.
> >
> > _______________________________________________
> > linaro-dev mailing list
> > linaro-dev@xxxxxxxxxxxxxxxx
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> 
> Just wanted to add my reflection on this topic;
> 
> Some prerequisites; I think am in favor of using the clk API to
> trigger DVFS changes and then I agree on that clk_prepare|unprepare
> needs to be possible to track from a DVFS perspective. clk_set_rate is
> not enough.
> 
> So if we decide to do the above (using the clk API to trigger DVFS
> changes), I believe we should discuss two possible solutions;
> - clk notifiers or..
> - dvfs clock type.
> 
> I am trying to make up my mind of what I think is the best solution.
> Have you considered "dvfs clock type"?
> I put some comments about this for "[PATCH 2/5] clk: notifier handler
> for dynamic voltage scaling" recently as well.
> 
> What could the advantages/disadvantages be between the two options?

I personally prefer clk notifiers since that's easy and all the existing
device drivers don't need to be modified, a new clock or API might be
more thoroughly considered (and hence maybe more graceful) but that
means we need more time to cook and many drivers need to plug into that
API when it comes out, a lot of test/verification or maybe chaos
follows, I'm not sure will that be a little overkill.

I'm not against designing a more robust API, I'm just suggesting before
we have that defined we should at least let clk notifiers work.
> 
> Kind regards
> Ulf Hansson


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/