Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Joel Soete <soete.joel@tiscali.be>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: Carlos O'Donell <carlos@baldric.uwo.ca>,
	Matthew Wilcox <willy@debian.org>,
	parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] sched_clock implementation
Date: Sun, 05 Oct 2003 15:43:16 +0000	[thread overview]
Message-ID: <3F803C14.4030900@tiscali.be> (raw)
In-Reply-To: <20030921000447.GC31268@dsl2.external.hp.com>

Grant Grundler wrote:

>On Sat, Sep 20, 2003 at 06:02:10PM +0000, Joel Soete wrote:
>  
>
>>a quick look into paxx.pdf which about CR16 speak of "peak instruction 
>>rate" but do not define anywhere?
>>I presume that is the cpu clock but would like somebody confirm.
>>    
>>
>
>Read about "Interval Timer" (cr16) in the PA 2.0 Arch book.
>PDC provides the exact rate that CR16 is changing.
>Looks like PDC_TOD_ITIMER is the call but I'm not sure offhand.
>In any case, I've only seen it used as CPU cycle counter.
>(ie 1:1 with CPU clock).
>
>hth,
>grant
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>  
>
Much more for remind, here is a proposed implementation of a pdc_tod_itimer:
diff -Naur linux-2.6.0-test6-pa6.orig/arch/parisc/kernel/firmware.c 
linux-2.6.0-test6-pa6.test/arch/parisc/kernel/firmware.c
--- linux-2.6.0-test6-pa6.orig/arch/parisc/kernel/firmware.c    
2003-10-05 17:14:13.000000000 +0200
+++ linux-2.6.0-test6-pa6.test/arch/parisc/kernel/firmware.c    
2003-10-05 17:09:14.000000000 +0200
@@ -682,6 +682,26 @@
 }
 EXPORT_SYMBOL(pdc_tod_set);

+/**
+ * pdc_tod_Calibrate_timers - Read "Calibrate timers" data
+ * @tod_calib: The return buffer:
+ *
+ * Calibrate the Interval Timer (CR16).
+ */
+int pdc_tod_itimer(struct pdc_tod_calib *tod_calib)
+{
+        int retval;
+
+        spin_lock_irq(&pdc_lock);
+        retval = mem_pdc_call(PDC_TOD, PDC_TOD_ITIMER, 
__pa(pdc_result), 0);
+        convert_to_wide(pdc_result);
+        memcpy(tod_calib, pdc_result, sizeof(tod_calib));
+        spin_unlock_irq(&pdc_lock);
+
+        return retval;
+}
+EXPORT_SYMBOL(pdc_tod_itimer);
+
 #ifdef __LP64__
 int pdc_mem_mem_table(struct pdc_memory_table_raddr *r_addr,
                struct pdc_memory_table *tbl, unsigned long entries)
diff -Naur linux-2.6.0-test6-pa6.orig/include/asm-parisc/pdc.h 
linux-2.6.0-test6-pa6.test/include/asm-parisc/pdc.h
--- linux-2.6.0-test6-pa6.orig/include/asm-parisc/pdc.h 2003-10-05 
17:15:09.000000000 +0200
+++ linux-2.6.0-test6-pa6.test/include/asm-parisc/pdc.h 2003-10-05 
17:11:26.000000000 +0200
@@ -670,6 +670,13 @@
        unsigned long tod_usec;
 };

+struct pdc_tod_calib {
+       unsigned long calib_0;
+       unsigned long calib_1;
+       unsigned long TOD_acc;
+       unsigned long CR_acc;
+};
+
 #ifdef __LP64__
 struct pdc_pat_cell_num {
        unsigned long cell_num;
@@ -943,6 +950,7 @@
 int pdc_get_initiator(struct hardware_path *hwpath, unsigned char 
*scsi_id, unsigned long *period, char *width, char *mode);
 int pdc_tod_read(struct pdc_tod *tod);
 int pdc_tod_set(unsigned long sec, unsigned long usec);
+int pdc_tod_itimer(struct pdc_tod_calib *tod_calib);

 #ifdef __LP64__
 int pdc_mem_mem_table(struct pdc_memory_table_raddr *r_addr,

Well I don't know yet if it would help for a better sched_clock() because:
a) I already found some get_jiffies_64() which seems to be a good candidate?

b) I don't yet find how jiffies and jiffies_64 are continuously updated. 
I presume that we take advantage of an 'external interupt request' by 
CR16 (interval timer) but don't reach to find neither where this one is 
initialised (just to determine if get_jiffies_64 is enough (theoriticaly 
1/100s ?) or request more) nor where it is updated?

Thanks in advance for comments and idea,
    Joel

PS:
I added some test on my c110 and got some:
Oct  5 15:57:51 hpalin kernel: Calib_0 =  0x405e0000
Oct  5 15:57:51 hpalin kernel: Calib_1 =  0x00000000
Oct  5 15:57:51 hpalin kernel: TOD_acc =  0x00000000
Oct  5 15:57:51 hpalin kernel: CR_acc  =  0x00000000

merging Calib_1, Calib_0 in a union retrun me a frequency of 120Mhz 
(exactly) when "Oct  5 15:57:51 hpalin kernel: Calibrating delay loop... 
119.60 BogoMIPS" (but printk don't print float :( )

but it is curious that TOD_acc and CR_acc are 0 any idea?

  parent reply	other threads:[~2003-10-05 15:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-18 20:35 [parisc-linux] sched_clock implementation Matthew Wilcox
2003-09-19 15:32 ` Joel Soete
2003-09-19 16:00   ` Carlos O'Donell
2003-09-19 16:11     ` Joel Soete
2003-09-20 18:02     ` Joel Soete
2003-09-21  0:04       ` Grant Grundler
2003-09-21 11:20         ` Helge Deller
2003-09-21 14:24           ` Carlos O'Donell
2003-10-05 15:43         ` Joel Soete [this message]
2003-10-06 14:20           ` Carlos O'Donell
     [not found]             ` <3F5CB6FB0000DCF3@ocpmta1.freegates.net>
2003-10-06 17:31               ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F803C14.4030900@tiscali.be \
    --to=soete.joel@tiscali.be \
    --cc=carlos@baldric.uwo.ca \
    --cc=grundler@parisc-linux.org \
    --cc=parisc-linux@parisc-linux.org \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox