From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Sun, 17 Jul 2011 00:11:52 +1000
Subject: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
In-Reply-To: <4E20AB3E.7030803@comcast.net>
References: <1309261269-4363-1-git-send-email-graeme.russ@gmail.com>	<20110711215637.6BC6A1579E14@gemini.denx.de>	<4E1B88EE.9040104@gmail.com>
	<4E1BAED7.3070009@gmail.com>	<4E1C5A8F.50908@comcast.net>
	<4E1C718F.2020203@emk-elektronik.de>	<4E1CE7ED.7060500@gmail.com>
	<4E1CF2E0.1030702@comcast.net>	<20110714194122.68CD31593511@gemini.denx.de>	<4E1F8127.8030008@comcast.net>	<20110715071734.4364916F76F1@gemini.denx.de>	<4E208227.6010903@comcast.net>	<20110715183435.5123317A3205@gemini.denx.de>
	<4E20AB3E.7030803@comcast.net>
Message-ID: <4E219C28.90105@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

Wolfgang, Bill

This thread was getting a little long so I took the liberty to snip the lot ;)

Now, the way I see things we are looking at two entirely different issues -
udelay() and the Timer API. Unfortunately, they are somewhat intertwined
because:

 a) Some Architectures/SoCs/Boards etc do not implement udelay() in a
    manner that is either 'available early' or 'inaccurate' (or in some
    cases both) and
 b) There is a not insignificant amount of code that uses a counter/udelay
    combination to implement timeout detection

I think for the moment I would like to concentrate solely on the Timer API
and leave udelay out of it. I know some architectures use the existing
Timer API for udelay, but if you look at my patch series, I never actually
touched the existing architecture timer implementations. To date, the
series has mostly been a rename and tidy-up of the Timer API and it's usage.

So, I think it will be easier to progress if we forget about udelay for the
moment. We can identify where it is broken/being abused as a separate task.

I can expand the scope of this patch series to look at those instances
where an incrementing loop counter with a udelay in the loop is being used
where get_time() and friend(s) should be used instead.

So in future, any architecture that can both initialise the timer
sub-system 'early' and has a timer resolution of <= 1us can use the Timer
API for udelay, otherwise, udelay will need an implementation (for that
architecture) which is independent of the timer sub-system. As an aside,
the x86 code _used_ to have a conditional udelay. If the timer sub-system
was not initialised yet, udelay would be implemented as a NOP loop. After
timers were available, they were used as they are more accurate.

Regards,

Graeme