Message-ID: <CAPDyKFpHz6KCNbVe2AsDuzZw-oN7NyRzCA=RatWA+9iMaQ7C+Q@mail.gmail.com>
Date:	Fri, 15 Mar 2013 13:33:08 +0100
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Bill Huang <bilhuang@...dia.com>
Cc:	Peter De Schrijver <pdeschrijver@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...aro.org" <patches@...aro.org>,
	"linaro-dev@...ts.linaro.org" <linaro-dev@...ts.linaro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

On 15 March 2013 13:06, Bill Huang <bilhuang@...dia.com> wrote:
> On Fri, 2013-03-15 at 18:08 +0800, Ulf Hansson wrote:
>> On 15 March 2013 10:39, Peter De Schrijver <pdeschrijver@...dia.com> 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@...ts.linaro.org
>> > 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 guess you did not fully got what I meant with "dvfs clock type". It
will not affect the clock API. But instead the dvfs is handled by
implementing a specific clk hw type. So the same thing is accomplished
as with clk notifiers, no changes should be needed to device drivers.

The difference is only that no notifiers will be needed, and all the
dvfs stuff will be handled in the clk hw instead. It will mean that we
will bundle dvfs stuff into the clock drivers, instead of separating
the code outside the clock drivers. But, on the other hand no
notifiers will be needed.

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

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

Powered by blists - more mailing lists