From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mike Frysinger <vapier@gentoo.org>
Date: Tue, 31 Mar 2009 05:13:07 -0400
Subject: [U-Boot] core ticks/timer code
In-Reply-To: <20090331081706.GA28787@game.jcrosoft.org>
References: <200903272130.26825.vapier@gentoo.org>
	<20090331081706.GA28787@game.jcrosoft.org>
Message-ID: <200903310513.09082.vapier@gentoo.org>
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 Tuesday 31 March 2009 04:17:06 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 21:30 Fri 27 Mar     , Mike Frysinger wrote:
> > the Blackfin core tick/timer code has been around since the start of the
> > original port, but i'm not sure it's entirely correct.  some common code
> > that uses timers seems to be misbehaving in that the timeout is pretty
> > much immediate.  makes me think that we've spent time on making udelay()
> > work, but then just glossed over the rest.
> >
> > unfortunately, there doesnt seem to be any docs on what exactly these
> > functions do so it's hard for me to verify/change any of it.
> >
> > my understanding is that:
> >  - get_ticks - return some notion of "cpu ticks"
> >  - get_tbclk - return number of "cpu ticks" that elapse in one second
> >  - timer_init - setup a core timer
> >  - get_timer(x) - not really sure what this is supposed to represent, or
> > how "x" is used
> >  - reset_timer - reset core timer to 0
> >  - CONFIG_SYS_HZ - no idea how this relates to ticks/timer in U-Boot as
> > in the Linux world, this is the core timer (scheduler) frequency (how
> > many times to execute per second)
>
> I've take a look on the current timer API and I've a lot of limitation on
> it as example on bitbanging we can not generate a clock over 200Khz or near
> as you said the API is dark
>
> I've in mind to partially import the clocksource linux API or create a new
> U-Boot api devired from it's design

the clocksource framework in linux sounds like extreme overkill for u-boot.  
where do you see realistic usage of more than one timer ?  u-boot is pretty 
much a single threaded app that polls.

> I'll propose a new design with the following Requierement
>
> Generic delay function implementation
>  - ndelay()
>  - udelay()
>  - mdelay()
>
> Generic helper
>  - khz2cycles()
>  - hz2cycles()
>  - cs2ns()
>
> Timer API
>  - timer_init()		- setup the timer
>  - timer_reset()	- reset the timer (use in case of overflow)
>  - get_ticks()		- return the current ticks
>  - get_cycles()		- return the ticks frequency in ns

do you have real use cases here ?  i'd actually propose the opposite: kill off 
the notion of "ticks", "cycles", and "hz".  i dont think ndelay() is really 
necessary, and mdelay() is a simple macro on top of udelay().  that leaves us 
with really only the three functions we have today: timer_init(), get_timer(), 
and reset_timer().  we clarify that the function operates in terms of 
milliseconds and blam, it's all so simple now.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090331/3752280a/attachment-0001.pgp