[U-Boot] [PATCH 01/15] x86: Add function to read time stamp counter

[Simon Glass]

Hi Graeme,

On Tue, Oct 23, 2012 at 9:24 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> On Wed, Oct 24, 2012 at 3:04 PM, Simon Glass <sjg at chromium.org> wrote:
>> From: Vadim Bendebury <vbendeb at chromium.org>
>>
>> Put this function in the u-boot-x86.h header file. We could instead create
>> timer.h perhaps.
>>
>> We support setting a base time, and reading the time relative to this base.
>>
>> Signed-off-by: Vadim Bendebury <vbendeb at chromium.org>
>> Signed-off-by: Stefan Reinauer <reinauer at chromium.org>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> ---
>>  arch/x86/include/asm/u-boot-x86.h |   12 ++++++++++++
>>  arch/x86/lib/timer.c              |   17 +++++++++++++++++
>>  2 files changed, 29 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h
>> index a4a5ae0..11be5c3 100644
>> --- a/arch/x86/include/asm/u-boot-x86.h
>> +++ b/arch/x86/include/asm/u-boot-x86.h
>> @@ -68,4 +68,16 @@ int video_init(void);
>>  void   board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
>>  void   board_init_f_r(void) __attribute__ ((noreturn));
>>
>> +/* Read the time stamp counter */
>> +static inline uint64_t rdtsc(void)
>> +{
>> +       uint32_t high, low;
>> +       __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high));
>> +       return (((uint64_t)high) << 32) | low;
>> +}
>
> What CPUs support the rdtsc opcode? I know the AMD SC520 does not
> (it's a 486 core). Wikipedia tells me the Pentium CPU was the first to
> implement it. The Pentium was released in March 1993, so rdtsc is
> nearly 20 years now. But not all non-Intel CPUs are guaranteed to
> support it. Oh, and for CPUs that change speed, the internal clock
> read by rdtsc may not be constant.
>
> I'm happy to draw a line in the sand and say 'x86 CPUs before
> xx/xx/xxx are not supported' - If someone comes along later wanting to
> add support, we can mess with the plumbing then (the likelyhood is
> practically zero, so I'm not too concerned about how hard that will
> be). Given that, perhaps we should look at HPET instead? I have a
> patch I worked on 6 month ago (attached below) if you feel like using
> it

OK - well it seems that HPET is *very* new in comparison. Even so, it
seems to me that it should be safe to move to this since we are
probably not that interested in old hardware, but perhaps we should do
this in the next release to give us a chance to test, etc.?

Regards,
Simon