decrementer_count, count_period_num, and count_period_den has disappeared

It appears the decrementer_count, count_period_num, and
count_period_den variables from arch/ppc/kernel/time.c have changed.
This is causing arch/ppc/kernel/m8260_setup.c to not compile.

m8260_setup.c: In function `abort':
m8260_setup.c:105: warning: `noreturn' function does return
m8260_setup.c: In function `m8260_calibrate_decr':
m8260_setup.c:116: `decrementer_count' undeclared (first use in this function)
m8260_setup.c:116: (Each undeclared identifier is reported only once
m8260_setup.c:116: for each function it appears in.)
m8260_setup.c:117: `count_period_num' undeclared (first use in this function)
m8260_setup.c:118: `count_period_den' undeclared (first use in this function)

I believe that decrementer_count was renamed to tb_ticks_per_jiffy, and
count_period_num/count_period_den are converted somehow into tb_to_us.

Could someone tell me the relationship between
count_period_num/count_period_den and tb_to_us?

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 21 Aug 2000, diekema_jon wrote:

It appears the decrementer_count, count_period_num, and
count_period_den variables from arch/ppc/kernel/time.c have changed.
This is causing arch/ppc/kernel/m8260_setup.c to not compile.

Yes, that's my fault (but seriously the previous code was wrong).

m8260_setup.c: In function `abort':
m8260_setup.c:105: warning: `noreturn' function does return
m8260_setup.c: In function `m8260_calibrate_decr':
m8260_setup.c:116: `decrementer_count' undeclared (first use in this function)
m8260_setup.c:116: (Each undeclared identifier is reported only once
m8260_setup.c:116: for each function it appears in.)
m8260_setup.c:117: `count_period_num' undeclared (first use in this function)
m8260_setup.c:118: `count_period_den' undeclared (first use in this function)

I believe that decrementer_count was renamed to tb_ticks_per_jiffy, and
count_period_num/count_period_den are converted somehow into tb_to_us.

tb_to_us is a factor to convert with a single multiply high (mulhwu) the
difference between current tb and the current tb into microseconds.

Could someone tell me the relationship between
count_period_num/count_period_den and tb_to_us?

Have a look at the recent patches on prep_time/pmac_time/chrp_time:

- tb_to_us can be computed by mulhwu_scale_factor(decrementer_frequency,
1000000). There is no simple relationship.

Tell me if the timebase frequency is <1 MHz, I'll produce a specific patch
to help this case which can't work with the current algorithm (which made
gettimeday faster by removing an ugly integer divide).

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Does this patch make sense?


dell 200} bk diffs -r1.7 -u arch/ppc/kernel/m8260_setup.c
===== arch/ppc/kernel/m8260_setup.c 1.7 vs 1.10 =====

--- 1.7/arch/ppc/kernel/m8260_setup.c   Wed Aug  2 12:53:58 2000
+++ 1.10/arch/ppc/kernel/m8260_setup.c  Mon Aug 21 09:34:30 2000

@@ -113,9 +113,8 @@

        freq = (binfo->bi_busfreq * 1000000);
         divisor = 4;
-        decrementer_count = freq / HZ / divisor;
-        count_period_num = divisor;
-        count_period_den = freq / 1000000;
+       tb_ticks_per_jiffy = freq / divisor / HZ;
+       tb_to_us = mulhwu_scale_factor(freq / divisor, 1000000);
 }

 /* The 8260 has an internal 1-second timer update register that

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, 21 Aug 2000, diekema_jon wrote:

Does this patch make sense?

Yes, with the few remarks below...

I'd rather write it freq/(divisor*HZ), but it should not change anything.

+       tb_to_us = mulhwu_scale_factor(freq / divisor, 1000000);

I had the impression that the tb/decrementer frequency was not guaranteed
(from the comments) to be > 1MHz, while it's always the case for 6xx
processors. If it's in the right frequency range (1MHz to something like
4 billion*HZ or ~400GHz ;-)), then this code should work just fine.

The final test is obviously that it works... Check that gettimeofday does
not always return an exact multiple of 1/HZ. (or that 2 succesive calls to
gettimeofday do not return exactly the same value from user mode so that
there is enough delay)

	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/