From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 23 May 2011 20:24:47 +0200 Subject: [U-Boot] [RFC] Review of U-Boot timer API In-Reply-To: <4DDA99BC.80809@comcast.net> References: <4DD7B245.5000008@gmail.com> <4DD8908E.7040501@emk-elektronik.de> <4DD8ABD3.2070506@gmail.com> <4DD8B993.3010704@comcast.net> <4DD8C639.30200@emk-elektronik.de> <4DD9A6F7.1040509@comcast.net> <4DD9B608.7080307@comcast.net> <20110523120912.493E01499BF6@gemini.denx.de> <4DDA5334.4060308@gmail.com> <20110523131959.9256D1499BF6@gemini.denx.de> <4DDA99BC.80809@comcast.net> Message-ID: <4DDAA66F.9020907@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 23/05/2011 19:30, J. William Campbell a ?crit : >> Did you have a look at the PowerPC implementation? I'd like to see >> this used as reference. > I have looked at it as a reference. However, there is one disadvantage > in using the PPC code as a reference. It has a 64 bit timestamp. Many > systems do not have a 64 bit timestamp, but rather a 32 bit timestamp. > It is possible to extend the 32 bit timestamp to a 64 bit timestamp if > get_timer is called often enough that there will only be a single > rollover of the bottom 32 bits between uses. However, if that condition > is met, there is no need to extend the timer to 64 bits. Well, there is one: making sure that drivers do not need to know if timestamps are 32 or 64 bits, or even what resolution they are. Granted, you could define a timestamp_t type to be either u32 or u64 depending on the actual timestamp width, so that the driver would not need to know the details; but extending u32 to u64, or subtracting two u64 values, are not so much of an effort, and that would mean a single API. Amicalement, -- Albert.