Resending the patch. A major change from previous version is
elimination of fixmap for HPET. Based on Andrew Morton's suggestion,
we have a new hook in init/main.c for late_time_init(), at which
time we can use ioremap, in place of fixmap.
Impact on other archs: Calibrate_delay() (and hence loops_per_jiffy
calculation) has moved down in main.c, from after time_init()
to after kmem_cache_init().
Patchset description:
1/6 - hpet1.patch - main.c change to introduce late_time_init()
2/6 - hpet2.patch - acpi boot time parsing changes to look for HPET
3/6 - hpet3.patch - Miscallaneous makefile and config changes
4/6 - hpet4.patch - All the changes required to use HPET in place
of PIT as the kernel base-timer at IRQ 0.
5/6 - hpet5.patch - All changes required to support timer services
(gettimeofday) with HPET. There are two options:
- Use HPET for gettimeofday.
- Use rdtsc for gettimeofday.
rdtsc is still faster then HPET reads, but HPET
has advantage that its rate remain same,
irrespective of CPU frequency. Also, HPET is
more scalable than TSC in case of multi-node
systems. So, our timer priority is
platform_specific_timer(if any), timer_hpet
and timer_tsc in that order.
6/6 - hpet6.patch - This can be a standalone patch. Without this
patch we loose interrupt generation capability
of RTC (/dev/rtc), due to HPET. With this patch
we basically try to emulate RTC interrupt
functions in software using HPET counter 1.
This is only required to provide compatibility
to the applications that depend on rtc driver's
interrupt generation capability.
This emulation will not be as accurate as RTC
interrupt, as HPET is not tied to RTC hardware
and does not know anything about RTC time.
But should enough for compatibility purposes.
All comments/feedbacks welcome.
Thanks,
-Venkatesh
HPET Description
High Precision Event Timer (HPET) is next generation timer
hardware and has various advantages over legacy 8254
(PIT) timer, like:
- Associated registers are mapped to memory space. So, we no
longer require in and out on legacy ioports
- Memory map address is reported by ACPI (and are not
hard-coded)
- Each timer can be configured to generate separate interrupts,
even sharing lines with PCI devices
- HPET has a minimum period of 100 nanosecs and is not fixed.
Giving a flexibility of increasing the resolution in future.
- Most current implementations has 3 counters, but in future,
we can have as many as 32 timers per block, and 8
HPET timer blocks (total 256 timers)
- Can support 32bit and 64bit counting
(Refer to http://www.intel.com/labs/platcomp/hpet/hpetspec.htm
for complete specs)
The patchset that follow adds support for High Precision Event
Timer (HPET) based timer in kernel. This uses the HPET in
LegacyReplacement mode (so that counter 0 will be tied to IRQ0,
and counter 1 will be tied to IRQ 8). In this mode, HPET overrides
PIT and RTC interrupt lines. The patch will enable HPET by default,
on systems where ACPI tables reports this feature. The patch will
have no impact on systems that do not support this feature.
>>>>> On Fri, 29 Aug 2003 01:50:09 +0200, "Pallipadi, Venkatesh" <[email protected]> said:
Venkatesh> Resending the patch. A major change from previous version
Venkatesh> is elimination of fixmap for HPET. Based on Andrew
Venkatesh> Morton's suggestion, we have a new hook in init/main.c
Venkatesh> for late_time_init(), at which time we can use ioremap,
Venkatesh> in place of fixmap. Impact on other archs:
Venkatesh> Calibrate_delay() (and hence loops_per_jiffy calculation)
Venkatesh> has moved down in main.c, from after time_init() to after
Venkatesh> kmem_cache_init().
Venkatesh> All comments/feedbacks welcome.
How much is really architecture-specific? HPET isn't x86-only so
sooner or later, we'll have to move it out of arch/i386 anyhow.
--david
The part of the patch that does the HPET initialization for timer
interrupt, and general HPET registers read/write/programming can be
common across architectures.
However, different archs diverge, when it comes to gettimeofday-timer
implementation (tsc, pit, itc, hpet, ) and we may still have to keep
that part architecture specific.
Thanks,
Venkatesh
> -----Original Message-----
> From: David Mosberger-Tang [mailto:[email protected]]
> Sent: Thursday, August 28, 2003 8:41 PM
> To: Pallipadi, Venkatesh
> Cc: [email protected]
> Subject: Re: [PATCHSET][2.6-test4][0/6]Support for HPET based
> timer - Take 2
>
>
> >>>>> On Fri, 29 Aug 2003 01:50:09 +0200, "Pallipadi,
> Venkatesh" <[email protected]> said:
>
> Venkatesh> Resending the patch. A major change from previous version
> Venkatesh> is elimination of fixmap for HPET. Based on Andrew
> Venkatesh> Morton's suggestion, we have a new hook in init/main.c
> Venkatesh> for late_time_init(), at which time we can use ioremap,
> Venkatesh> in place of fixmap. Impact on other archs:
> Venkatesh> Calibrate_delay() (and hence loops_per_jiffy calculation)
> Venkatesh> has moved down in main.c, from after time_init() to after
> Venkatesh> kmem_cache_init().
>
> Venkatesh> All comments/feedbacks welcome.
>
> How much is really architecture-specific? HPET isn't x86-only so
> sooner or later, we'll have to move it out of arch/i386 anyhow.
>
> --david
>
"Pallipadi, Venkatesh" <[email protected]> wrote:
>
> Resending the patch.
Thanks, I'll include these in the next -mm kernel.
Reading the code, the only thing which leaps out is:
+/* Use our own asm for 64 bit multiply/divide */
+#define ASM_MUL64_REG(eax_out,edx_out,reg_in,eax_in) \
+ __asm__ __volatile__("mull %2" \
+ :"=a" (eax_out), "=d" (edx_out) \
+ :"r" (reg_in), "0" (eax_in))
+
+#define ASM_DIV64_REG(eax_out,edx_out,reg_in,eax_in,edx_in) \
+ __asm__ __volatile__("divl %2" \
+ :"=a" (eax_out), "=d" (edx_out) \
+ :"r" (reg_in), "0" (eax_in), "1" (edx_in))
We seem to keep on proliferating home-grown x86 64-bit math functions.
Do you really need these? Is it possible to use do_div() and the C 64x64
`*' operator instead?
I'd like the rtc emulation patch to be redone to remove the ifdefs please,
they're a real eyesore.
At the top of rtc.c, do something like this:
#ifndef CONFIG_HPET_EMULATE_RTC
#define is_hpet_enabled() 0
#define hpet_set_alarm_time(hrs, min, sec) 0
#define hpet_set_periodic_freq(arg) 0
static inline int hpet_mask_rtc_irq_bit(int arg) { return 0; }
#define hpet_rtc_timer_init() do { } while (0)
#define hpet_rtc_dropped_irq() 0
#endif
And then all those eleven ifdefs can be removed from rtc.c.
Thanks.
On Fri Aug 29, 2003 at 11:23:47AM -0700, Andrew Morton wrote:
> "Pallipadi, Venkatesh" <[email protected]> wrote:
> >
> > Resending the patch.
>
> Thanks, I'll include these in the next -mm kernel.
>
> Reading the code, the only thing which leaps out is:
>
> +/* Use our own asm for 64 bit multiply/divide */
> +#define ASM_MUL64_REG(eax_out,edx_out,reg_in,eax_in) \
> + __asm__ __volatile__("mull %2" \
> + :"=a" (eax_out), "=d" (edx_out) \
> + :"r" (reg_in), "0" (eax_in))
> +
> +#define ASM_DIV64_REG(eax_out,edx_out,reg_in,eax_in,edx_in) \
> + __asm__ __volatile__("divl %2" \
> + :"=a" (eax_out), "=d" (edx_out) \
> + :"r" (reg_in), "0" (eax_in), "1" (edx_in))
>
> We seem to keep on proliferating home-grown x86 64-bit math functions.
>
> Do you really need these? Is it possible to use do_div() and the C 64x64
> `*' operator instead?
The fundamental reason these are proliferating is that given
some random bit of code such as:
u64 foo=9, bar=3, baz;
baz = foo / bar;
baz = foo % bar;
gcc then generates code calling __udivdi3 and __umoddi3. Since
the kernel does not provide these, people keep reinventing them.
Perhaps it is time to kill off do_div and all its little friends
and simply copy __udivdi3 and __umoddi3 from libgcc.....
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
> -----Original Message-----
> From: Andrew Morton [mailto:[email protected]]
>
> We seem to keep on proliferating home-grown x86 64-bit math functions.
>
> Do you really need these? Is it possible to use do_div() and
> the C 64x64
> `*' operator instead?
>
We can change these handcoded 64 bit divs to do_div, with just an
additional data copy
(as do_div changes dividend in place). But, changing mul into 64x64 '*'
may be tricky.
Gcc seem to generate a combination of mul, 2imul and add, where as we
are happy with
using only one mull here.
>
> I'd like the rtc emulation patch to be redone to remove the
> ifdefs please,
> they're a real eyesore.
>
> At the top of rtc.c, do something like this:
>
> #ifndef CONFIG_HPET_EMULATE_RTC
> #define is_hpet_enabled() 0
> #define hpet_set_alarm_time(hrs, min, sec) 0
> #define hpet_set_periodic_freq(arg) 0
> static inline int hpet_mask_rtc_irq_bit(int arg) { return 0; }
> #define hpet_rtc_timer_init() do { } while (0)
> #define hpet_rtc_dropped_irq() 0
> #endif
>
> And then all those eleven ifdefs can be removed from rtc.c.
Yes. That surely makes the patch lot more cleaner. Attached is the
updated rtc
emulation patch.
Thanks,
-Venkatesh
>>>>> On Fri, 29 Aug 2003 09:12:52 -0700, "Pallipadi, Venkatesh" <[email protected]> said:
Venkatesh> The part of the patch that does the HPET initialization
Venkatesh> for timer interrupt, and general HPET registers
Venkatesh> read/write/programming can be common across
Venkatesh> architectures. However, different archs diverge, when it
Venkatesh> comes to gettimeofday-timer implementation (tsc, pit,
Venkatesh> itc, hpet, ) and we may still have to keep that part
Venkatesh> architecture specific.
Is the time_interpolator interface provided by timex.h sufficient for
HPET timer-interrupt needs? I think It ought to be. If so, perhaps
all that's missing is that x86 needs to be switched over to that
interface?
--david
> -----Original Message-----
> From: David Mosberger-Tang [mailto:[email protected]]
> >>>>> On Fri, 29 Aug 2003 09:12:52 -0700, "Pallipadi,
> Venkatesh" <[email protected]> said:
>
> Venkatesh> The part of the patch that does the HPET initialization
> Venkatesh> for timer interrupt, and general HPET registers
> Venkatesh> read/write/programming can be common across
> Venkatesh> architectures. However, different archs diverge, when it
> Venkatesh> comes to gettimeofday-timer implementation (tsc, pit,
> Venkatesh> itc, hpet, ) and we may still have to keep that part
> Venkatesh> architecture specific.
>
> Is the time_interpolator interface provided by timex.h sufficient for
> HPET timer-interrupt needs? I think It ought to be. If so, perhaps
> all that's missing is that x86 needs to be switched over to that
> interface?
>
timer_interpolator kind of interface helps for one part of HPET changes.
That is using HPET during gettimeofday(). Unfortunately, i386 has its
own timer infrastructure (which is quite similar to timer_interpolator),
which is already being used by variety of timers that exist (cyclone_timer,
tsc, pit - code under arch/i386/kernel/timers). i386 timers seems to be
the superset of timer_interpolator.
struct timer_opts{
int (*init)(char *override);
void (*mark_offset)(void);
unsigned long (*get_offset)(void);
unsigned long long (*monotonic_clock)(void);
void (*delay)(unsigned long);
};
I agree, in future, it is best to integrate these timers in an
architecture independent way.
The other part of HPET change is, change in kernel base timer. In i386,
along with local APIC timer interrupts, we also have a IRQ0 timer interrupt.
This is where kernel time-keeping happens (similar to TIME_KEEPER_ID in IPF).
This will also used for process times in UP case, when there is no LAPIC.
As of now this interrupt comes from PIT/8254. HPET will replace this too,
and can be programmed to generate periodic interrupts at a particular rate.
This part may be specific to i386.
Thanks,
-Venkatesh
On Fri, 29 Aug 2003, Erik Andersen wrote:
>
> gcc then generates code calling __udivdi3 and __umoddi3. Since
> the kernel does not provide these, people keep reinventing them.
> Perhaps it is time to kill off do_div and all its little friends
> and simply copy __udivdi3 and __umoddi3 from libgcc.....
No. do_div() does _nothing_ like __udivdi3/__umoddi3.
Read the documentation.
Linus
On Sun Aug 31, 2003 at 02:05:25PM -0700, Linus Torvalds wrote:
>
> On Fri, 29 Aug 2003, Erik Andersen wrote:
> >
> > gcc then generates code calling __udivdi3 and __umoddi3. Since
> > the kernel does not provide these, people keep reinventing them.
> > Perhaps it is time to kill off do_div and all its little friends
> > and simply copy __udivdi3 and __umoddi3 from libgcc.....
>
> No. do_div() does _nothing_ like __udivdi3/__umoddi3.
>
> Read the documentation.
Been there done that, got the scars to prove it. do_div() is a
macro that acts sortof like the ISO C99 lldiv(3) function.
Except it does unexpected things like modify its arguments...
Most places in the kernel using do_div() not because it is the
right thing to do, but because they tried to do something
seemingly simple such as:
u64 foo, bar, baz;
...
baz = foo / bar;
and then got an error that __udivdi3 was undefined. So the
authors then go hunting for a way to do a 64 bit division and
find do_div()...
See mm/vmscan.c, mm/shmem.c, fs/proc/proc_misc.c,
drivers/ide/ide-disk.c, etc, etc, etc, for plenty of examples of
_exactly_ this sort of thing. Every one of them is using
do_div() to perform 64 bit division. Not becase that is the
right thing to do, but because __udivdi3 is missing.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Sun, 31 Aug 2003, Erik Andersen wrote:
>
> Been there done that, got the scars to prove it. do_div() is a
> macro that acts sortof like the ISO C99 lldiv(3) function.
No.
You missed a very important part of do_div() - it has _totally_ different
numerical range than a regular /, % or lldiv() call.
All of /, % and lldiv() work on 64-bit numbers. do_div() DOES NOT!
do_div() very much is all about:
*** 32-bit divisor ***
which also implies that the remainder is 32-bit.
And the fact is, such a division is a lot faster than a full 64-bit
division. On a _lot_ of architectures, but notably so on x86.
It is _not_ a 64-bit divide, and that's not only important, it's the
whole _reason_d'etre_ for the whole function. See?
So by continually confusing it with a 64-bit divide (either by confusing
it with lldiv() or those horrible gcc internal __{div|mod}di3u things),
you miss the whole point of the function.
Linus
Erik Andersen wrote:
> On Fri Aug 29, 2003 at 11:23:47AM -0700, Andrew Morton wrote:
>
>>"Pallipadi, Venkatesh" <[email protected]> wrote:
>>
>>>Resending the patch.
>>
>>Thanks, I'll include these in the next -mm kernel.
>>
>>Reading the code, the only thing which leaps out is:
>>
>>+/* Use our own asm for 64 bit multiply/divide */
>>+#define ASM_MUL64_REG(eax_out,edx_out,reg_in,eax_in) \
>>+ __asm__ __volatile__("mull %2" \
>>+ :"=a" (eax_out), "=d" (edx_out) \
>>+ :"r" (reg_in), "0" (eax_in))
This can be done in standard C. If you want an inline, how about
(from .../kernel/posix-timers.c):
static inline u64 mpy_l_X_l_ll(unsigned long mpy1,unsigned long mpy2)
{
return (u64)mpy1 * mpy2;
}
>>+
>>+#define ASM_DIV64_REG(eax_out,edx_out,reg_in,eax_in,edx_in) \
>>+ __asm__ __volatile__("divl %2" \
>>+ :"=a" (eax_out), "=d" (edx_out) \
>>+ :"r" (reg_in), "0" (eax_in), "1" (edx_in))
This appears to be the same as (from .../include/asm-i386/div64.h):
#define div_long_long_rem(a,b,c) div_ll_X_l_rem(a,b,c)
extern inline long
div_ll_X_l_rem(long long divs, long div, long *rem)
{
long dum2;
__asm__("divl %2":"=a"(dum2), "=d"(*rem)
: "rm"(div), "A"(divs));
return dum2;
}
-g
>>
>>We seem to keep on proliferating home-grown x86 64-bit math functions.
>>
>>Do you really need these? Is it possible to use do_div() and the C 64x64
>>`*' operator instead?
>
>
>
> The fundamental reason these are proliferating is that given
> some random bit of code such as:
>
> u64 foo=9, bar=3, baz;
> baz = foo / bar;
> baz = foo % bar;
>
> gcc then generates code calling __udivdi3 and __umoddi3. Since
> the kernel does not provide these, people keep reinventing them.
> Perhaps it is time to kill off do_div and all its little friends
> and simply copy __udivdi3 and __umoddi3 from libgcc.....
>
> -Erik
>
> --
> Erik B. Andersen http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Pallipadi, Venkatesh wrote:
>
>
>>-----Original Message-----
>>From: Andrew Morton [mailto:[email protected]]
>>
>>We seem to keep on proliferating home-grown x86 64-bit math functions.
>>
>>Do you really need these? Is it possible to use do_div() and
>>the C 64x64
>>`*' operator instead?
>>
>
>
>
> We can change these handcoded 64 bit divs to do_div, with just an
> additional data copy
We already have this in .../include/asm-i386/div64.h. Check usage in
.../posix-timers.c to cover archs that have not yet included it in
there div64.h.
> (as do_div changes dividend in place). But, changing mul into 64x64 '*'
> may be tricky.
> Gcc seem to generate a combination of mul, 2imul and add, where as we
> are happy with
> using only one mull here.
You just need to do the right casting. It should like
u64=u32*(u64)u32 as in .../kernel/posix-timers.c. This could also be
signed with the same results. If you really need to do a u64*u32, it
will do that as well but takes two mpys. In this case you will need
to do it unsigned to eliminate the third mpy.
>
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
> -----Original Message-----
> From: George Anzinger [mailto:[email protected]]
>
> Pallipadi, Venkatesh wrote:
> >
> >
> >>-----Original Message-----
> >>From: Andrew Morton [mailto:[email protected]]
> >>
> >>We seem to keep on proliferating home-grown x86 64-bit math
> functions.
> >>
> >>Do you really need these? Is it possible to use do_div() and
> >>the C 64x64
> >>`*' operator instead?
> >>
> >
> >
> >
> > We can change these handcoded 64 bit divs to do_div, with just an
> > additional data copy
>
> We already have this in .../include/asm-i386/div64.h. Check usage in
> .../posix-timers.c to cover archs that have not yet included it in
> there div64.h.
>
Yes. We can surely use div_long_long_rem from div64 in place of defining
this again. This kind of code is already there in the existing ia32 timer
code too. I will try and come up with a cleanup patch to replace all
these individual asm div statements.
> > (as do_div changes dividend in place). But, changing mul
> into 64x64 '*'
> > may be tricky.
> > Gcc seem to generate a combination of mul, 2imul and add,
> where as we
> > are happy with
> > using only one mull here.
>
> You just need to do the right casting. It should like
> u64=u32*(u64)u32 as in .../kernel/posix-timers.c. This
> could also be
> signed with the same results. If you really need to do a u64*u32, it
> will do that as well but takes two mpys. In this case you will need
> to do it unsigned to eliminate the third mpy.
Interesting. Is this casting to generate proper mul instruction
some sort of C standard or is it a gcc feature. I just want to
make sure doing this way won't break on some other compiler
(or on some other version of gcc itself).
Thanks,
-Venkatesh
Pallipadi, Venkatesh wrote:
>
>
>>-----Original Message-----
>>From: George Anzinger [mailto:[email protected]]
>>
>>Pallipadi, Venkatesh wrote:
>>
>>>
>>>>-----Original Message-----
>>>>From: Andrew Morton [mailto:[email protected]]
>>>>
>>>>We seem to keep on proliferating home-grown x86 64-bit math
>>
>>functions.
>>
>>>>Do you really need these? Is it possible to use do_div() and
>>>>the C 64x64
>>>>`*' operator instead?
>>>>
>>>
>>>
>>>
>>>We can change these handcoded 64 bit divs to do_div, with just an
>>>additional data copy
>>
>>We already have this in .../include/asm-i386/div64.h. Check usage in
>>.../posix-timers.c to cover archs that have not yet included it in
>>there div64.h.
>>
>
>
>
> Yes. We can surely use div_long_long_rem from div64 in place of defining
> this again. This kind of code is already there in the existing ia32 timer
> code too. I will try and come up with a cleanup patch to replace all
> these individual asm div statements.
>
>
>
>>>(as do_div changes dividend in place). But, changing mul
>>
>>into 64x64 '*'
>>
>>>may be tricky.
>>>Gcc seem to generate a combination of mul, 2imul and add,
>>
>>where as we
>>
>>>are happy with
>>>using only one mull here.
>>
>>You just need to do the right casting. It should like
>>u64=u32*(u64)u32 as in .../kernel/posix-timers.c. This
>>could also be
>>signed with the same results. If you really need to do a u64*u32, it
>>will do that as well but takes two mpys. In this case you will need
>>to do it unsigned to eliminate the third mpy.
>
>
>
> Interesting. Is this casting to generate proper mul instruction
> some sort of C standard or is it a gcc feature. I just want to
> make sure doing this way won't break on some other compiler
> (or on some other version of gcc itself).
I don't really know, but I suspect it is a gcc thing. Some how the
standards folks got in and messed up the original idea of keeping the
language close to the machine when they said that the data type in to
and out of a C operator should be the same, thus not allowing the true
mpy result to find expression in the language. The same thing applies
to the "/" and "%" operators, which to my knowledge, require either
really messy macros/c code or asm to allow the machine u64/u32 to work.
>
>
> Thanks,
> -Venkatesh
>
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml