Message-ID: <aec7e5c30906102251n36bbe6f9x9b384131f332d4d9@mail.gmail.com>
Date:	Thu, 11 Jun 2009 14:51:54 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, lethal@...ux-sh.org,
	tglx@...utronix.de, akpm@...ux-foundation.org
Subject: Re: [PATCH] clocksource: setup mult_orig in clocksource_enable()

Hi John,

On Thu, Jun 11, 2009 at 6:04 AM, john stultz<johnstul@...ibm.com> wrote:
> On Fri, 2009-05-01 at 14:45 +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm@...l.co.jp>
>>
>> Setup clocksource mult_orig in clocksource_enable().
>
> Hey Magnus,
> Sorry I missed this earlier, I just noticed it in the -tip tree.

No worries!

> I've some concerns below.
>
>> Clocksource drivers can save power by using keeping the
>> device clock disabled while the clocksource is unused.
>>
>> In practice this means that the enable() and disable()
>> callbacks perform clk_enable() and clk_disable().
>>
>> The enable() callback may also use clk_get_rate() to get
>> the clock rate from the clock framework. This information
>> can then be used to calculate the shift and mult variables.
>
> Hrmmm.. So when the clocksource code was designed, it was expected that
> the clocksource mult value would be set prior to registration, and then
> would not be modified by any user other then the timekeeping core. As
> changing the mult value directly (on a clocksource thats being used)
> could cause time inconsistencies.

But no one is changing the mult value on a clocksource that is being
used in this case, no? I may remember wrong, but isn't
clocksource_enable() called on unused clocksources that soon will
become used?

>> Currently the mult_orig variable is setup from mult at
>> registration time only. This is conflicting with the above
>> case since the clock is disabled and the mult variable is
>> not yet calculated at the time of registration.
>
> Is there really no way to calculate the mult value prior to
> registration? Maybe quickly enabling, getting the freq, and then
> disabling?

I can't think of any way that would work. The clock frequency can be
changed while the clock is disabled. And we can only know the rate
after enabling the clock, see these lines from include/linux/clk.h:

/**
 * clk_get_rate - obtain the current clock rate (in Hz) for a clock source.
 *		  This is only valid once the clock source has been enabled.
 * @clk: clock source
 */
unsigned long clk_get_rate(struct clk *clk);

>> --- 0001/include/linux/clocksource.h
>> +++ work/include/linux/clocksource.h  2009-05-01 12:59:27.000000000 +0900
>> @@ -288,7 +288,15 @@ static inline cycle_t clocksource_read(s
>>   */
>>  static inline int clocksource_enable(struct clocksource *cs)
>>  {
>> -     return cs->enable ? cs->enable(cs) : 0;
>> +     int ret = 0;
>> +
>> +     if (cs->enable)
>> +             ret = cs->enable(cs);
>> +
>> +     /* save mult_orig on enable */
>> +     cs->mult_orig = cs->mult;
>> +
>> +     return ret;
>>  }
>
> So this seems like it will break if a clocksource is switched away from
> and then back to (the reason we added mult_orig in the first place).
> Since the re-enabled clocksource would then save off its modified mult
> value into mult_orig.

Oh, I see. Sorry about that. I wonder if adding a "cs->mult =
cs->orig_mult;" to clock_disable() would help?

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