From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Tue, 20 Sep 2011 21:40:19 +1000
Subject: [U-Boot] [PATCH] arm: add 64-64 bit divider
In-Reply-To: <20110920112842.DFB301407969@gemini.denx.de>
References: <1314787130-1043-1-git-send-email-clchiou@chromium.org>
	<20110831200355.A71D018D30CE@gemini.denx.de>
	<CANJuy2+BB7tA70vHoTq3LJA-o4ymGCSdP9PnFzrx-uWret7nqQ@mail.gmail.com>
	<20110907211411.2C91C140875D@gemini.denx.de>
	<4E786EBA.5040805@gmail.com>
	<20110920112842.DFB301407969@gemini.denx.de>
Message-ID: <4E787BA3.4030606@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 20/09/11 21:28, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4E786EBA.5040805@gmail.com> you wrote:
>>
>> You'll laugh at this - the Intel High Performance Event Timers (HPET) are
>> defined to a resolution of femto-seconds and you end up with code in
>> get_timer() like:
> 
> I have to admit that I have never been able to laugh about x86 design
> issues.  But then, Intel told us the Pentium would have "RISK"
> features...

*ROFL*

Well actually, it's not really an x86 thing - Any architecture could
implement HPET. Using femto-seconds as the time-base and defining a 'tick'
as a number of femto-seconds makes a lot of sense - It allows preservation
of timer accuracy through the comparators so interrupts can be generated
with extreme precision while actually allowing the source clock to be
pretty much any frequency. They were, after all, designed for multi-media
applications to solve the horrendous sub-ms accuracy issue with the older
programmable timers

Regards,

Graeme