Just note that pit_read_counter is implemented on top of CH2 of PIT, which is known as mode 0 to calibrate TSC earlier. However I see no place to re-initialize it again and it''s used as the source of platform timer count (when using_pit==1) immediately. It seems like weird usage since mode0 channel will fall into a loop starting counting down from 0xFFFF forever if nobody re-latches it again, which indicates a 18.2065 Hz source while platform_timer_scale is set as CLOCK_TICK_RATE. Seems ch0 is what''s really wanted... Is it a typo, or any special usage on ch2? Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/12/06 09:05, "Tian, Kevin" <kevin.tian@intel.com> wrote:> Just note that pit_read_counter is implemented on top of CH2 of PIT, > which is known as mode 0 to calibrate TSC earlier. However I see no > place to re-initialize it again and it''s used as the source of platform > timer count (when using_pit==1) immediately. It seems like weird > usage since mode0 channel will fall into a loop starting counting down > from 0xFFFF forever if nobody re-latches it again, which indicates a > 18.2065 Hz source while platform_timer_scale is set as CLOCK_TICK_RATE. > > Seems ch0 is what''s really wanted... Is it a typo, or any special usage > on ch2?We use it as a free-running globally-accessible counter of known frequency. We don''t take interrupts from it (in fact we can''t even if we wanted to as it''s not wired up to an IRQ). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir@xensource.com] >Sent: 2006年12月11日 17:36 >On 11/12/06 09:05, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> Just note that pit_read_counter is implemented on top of CH2 of PIT, >> which is known as mode 0 to calibrate TSC earlier. However I see no >> place to re-initialize it again and it''s used as the source of platform >> timer count (when using_pit==1) immediately. It seems like weird >> usage since mode0 channel will fall into a loop starting counting down >> from 0xFFFF forever if nobody re-latches it again, which indicates a >> 18.2065 Hz source while platform_timer_scale is set as >CLOCK_TICK_RATE. >> >> Seems ch0 is what''s really wanted... Is it a typo, or any special usage >> on ch2? > >We use it as a free-running globally-accessible counter of known >frequency. >We don''t take interrupts from it (in fact we can''t even if we wanted to as >it''s not wired up to an IRQ). > > -- KeirYes, there''s no interrupt from it. But what''s the known frequency? CALIBRATE_LATCH or CLOCK_TICK_RATE? platform_timer_scale is set to the later, and so ch2 needs to work on same frequency or else count value will result incorrect offset. However I didn''t see such setting on ch2. Does I miss something? :-) Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/12/06 12:10, "Tian, Kevin" <kevin.tian@intel.com> wrote:> Yes, there''s no interrupt from it. But what''s the known frequency? > CALIBRATE_LATCH or CLOCK_TICK_RATE? platform_timer_scale > is set to the later, and so ch2 needs to work on same frequency or > else count value will result incorrect offset. However I didn''t see such > setting on ch2. Does I miss something? :-)All the PIT channels tick at CLOCK_TICK_RATE. Mode-0 is not auto-relatching, so when the counter reaches 0000 it carries on FFFF, FFFE, FFFD, .... So we calculate platform system time as: system_timestamp + (pit_timestamp - pit_timenow) * (delta_system/delta_pit) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/12/06 14:35, "Keir Fraser" <keir@xensource.com> wrote:> On 11/12/06 12:10, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> Yes, there''s no interrupt from it. But what''s the known frequency? >> CALIBRATE_LATCH or CLOCK_TICK_RATE? platform_timer_scale >> is set to the later, and so ch2 needs to work on same frequency or >> else count value will result incorrect offset. However I didn''t see such >> setting on ch2. Does I miss something? :-) > > All the PIT channels tick at CLOCK_TICK_RATE. Mode-0 is not auto-relatching, > so when the counter reaches 0000 it carries on FFFF, FFFE, FFFD, .... > > So we calculate platform system time as: > system_timestamp + (pit_timestamp - pit_timenow) * (delta_system/delta_pit)Where, to be explicit, since system time is in nanoseconds we have: delta_system = 1000000000 delta_pit = CLOCK_TICK_RATE -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir@xensource.com] >Sent: 2006年12月11日 22:59 >On 11/12/06 14:35, "Keir Fraser" <keir@xensource.com> wrote: > >> On 11/12/06 12:10, "Tian, Kevin" <kevin.tian@intel.com> wrote: >> >>> Yes, there''s no interrupt from it. But what''s the known frequency? >>> CALIBRATE_LATCH or CLOCK_TICK_RATE? platform_timer_scale >>> is set to the later, and so ch2 needs to work on same frequency or >>> else count value will result incorrect offset. However I didn''t see such >>> setting on ch2. Does I miss something? :-) >> >> All the PIT channels tick at CLOCK_TICK_RATE. Mode-0 is not >auto-relatching, >> so when the counter reaches 0000 it carries on FFFF, FFFE, FFFD, .... >> >> So we calculate platform system time as: >> system_timestamp + (pit_timestamp - pit_timenow) * >(delta_system/delta_pit) > >Where, to be explicit, since system time is in nanoseconds we have: > delta_system = 1000000000 > delta_pit = CLOCK_TICK_RATE > > -- KeirYou''re exactly right. I happened to have illusion that counter represents the output frequency. What a misunderstanding! :-( Thanks for your explanation. - Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel