lkml.org 
[lkml]   [2004]   [Mar]   [18]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated
Fromjohn stultz <>
DateThu, 18 Mar 2004 13:05:30 -0800
On Thu, 2004-03-18 at 00:51, Dominik Brodowski wrote:
> On Wed, Mar 17, 2004 at 02:56:27PM -0800, Nate Lawson wrote:
> > Instead of all this gymnastics, how about:
> 
> It's not so much gymnastics -- implementing different handling for cpufreq
> drivers which do not affect the TSC is easy. It's just difficult to get to
> know what drivers/CPUs are affected... and the test run you did yesterday
> helped in evaluating this. Thanks for doing so.
> 
> > 1. If using Px states, state is unknown until first "set" event.
> 
> Normally, when using cpufreq drivers the original state is known -- only the
> ACPI spec has this severe flaw, but there are tries for a workaround [patch
> is submitted]
> 
> > 2. Implement priorities for time source selection and a generic timer API.
> > This gets around the need to get the clock rate correct to have system
> > timers work.  On FreeBSD, this is /sys/kern/kern_tc.c
> 
> IIRC, John Stultz intends to do a major upgrade of the timing code in 2.7.

Well, we already have time source selection in 2.6 for i386. Most other
arches have a single stable time source, so its not as critical for
them. As for 2.7, a couple of holes have been poked in my initial
design, so any major rewrite is somewhat on hold. Moving more arches to
the more generic time_interpolator interface that ia64 uses may be the
best solution, although its not as clean as I'd really like.

thanks
-john


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

\
 
 \ /
  Last update: 2005-03-22 13:01    [from the cache]
©2003-2008