From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Thu, 26 May 2011 07:55:58 +0200
Subject: [U-Boot] [RFC] Review of U-Boot timer API
In-Reply-To: <BANLkTi=B1BRT-HR23xVPtOqufpdbiTxrRA@mail.gmail.com>
References: <4DD7B245.5000008@gmail.com>	<20110524141950.2AB1CCF5DBF@gemini.denx.de>	<4DDBE22D.6050806@gmail.com>	<20110524191948.401CBCF5DBF@gemini.denx.de>	<BANLkTinK+bxtZ+sumYZtvuHcd_Ft+jfyPw@mail.gmail.com>	<4DDC6F46.4090809@comcast.net>	<20110525052836.11A30CF5DBF@gemini.denx.de>	<BANLkTinZ_q8_vqd9mzm7BY64Hi=zuyFZTQ@mail.gmail.com>	<20110525080837.5925BCF5DBF@gemini.denx.de>	<4DDCBFF4.40002@gmail.com>	<20110525113738.E49DFCFB8A4@gemini.denx.de>	<4DDCED75.8030906@gmail.com>	<20110525122615.DBAA4CEFB5B@gemini.denx.de>	<4DDCF926.1050904@gmail.com>	<20110525125903.3C517CEFB5B@gemini.denx.de>	<BANLkTimhtqYNWgvwr6w8kNOSV4U_tZs7yw@mail.gmail.com>	<20110525133859.C420DCEFB5B@gemini.denx.de>	<4DDD7066.4000505@gmail.com>	<20110525211602.E7783101D42@gemini.denx.de>	<BANLkTikTxHFv3nJ0MeKSGV=9dK4AAwERrg@mail.gmail.com>	<4DDDD4D6.5010009@emk-elektronik.de>
	<4DDDDF2E.8070602@comcast.net>	<20110526051641.881D3DB7949@gemini.denx.de>
	<BANLkTi=B1BRT-HR23xVPtOqufpdbiTxrRA@mail.gmail.com>
Message-ID: <4DDDEB6E.7000506@aribaud.net>
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

Le 26/05/2011 07:25, Graeme Russ a ?crit :

> I think we can still rationalise the timer API as suggested which, as
> a minimum will:
>
>   - Not diminish current functionality for any platform
>   - Will dramatically reduce the current amount of code duplication
>   - Improve functionality on some platforms
>   - Simplify the whole API
>
> and then start banging on arch maintainers heads to implement the trivial
> ISR to kick the prescaler:

I personally am in favor of cooperation rather than coercion, so please, 
ask before banging on heads. :)

> void timer_isr(void *unused)
> {
> 	prescaler();
> }
>
> Regards,
>
> Graeme

Seems like we're asymptotically getting to some kind of agreement. For 
the sake of clarity, could someone summarize what the expected API would 
be, so that I save my scalp and start looking as the order in which 
changes should be done on ARM?

Amicalement,
-- 
Albert.