On Sat, Apr 04, 2009 at 11:14:09PM +0200, Wolfgang Denk wrote:
Dear Scott Wood,
In message 20090331213202.gb19...@ld0162-tx32.am.freescale.net you wrote:
Is there any particular reason not to change the powerpc get_timer
implementation to use the timebase (scaled down to ms)?
I think
Dear Scott,
In message 20090406191242.ga4...@ld0162-tx32.am.freescale.net you wrote:
Is there any particular reason not to change the powerpc get_timer
implementation to use the timebase (scaled down to ms)?
Side note: we already use the timebase for the implementation of
udelay()
Dear Scott Wood,
In message 20090331213202.gb19...@ld0162-tx32.am.freescale.net you wrote:
Is there any particular reason not to change the powerpc get_timer
implementation to use the timebase (scaled down to ms)?
I think so. There are some boards where we actually measure the system
clock
Hi,
Dear Scott Wood,
In message 20090331212514.ga19...@ld0162-tx32.am.freescale.net you wrote:
On Tue, Mar 31, 2009 at 05:48:01PM +0200, Wolfgang Denk wrote:
We still need some hint that the timer works in millisecond
resolution, though - no matter what you call it.
How about just
Dirk,
On Tue, Mar 31, 2009 at 05:55:13PM +0200, Dirk Behme wrote:
... I'd like that we split general ticks/timer code clean
up and bug fixes. I'd like that we implement the changes proposed by
Mike and Jean-Christophe independent and don't mix them with other
fixes for broken timer code
Wolfgang,
Can this be put in the ToDo list so anyone who looks to clean up their
CPU and/or architecture knows what it is exactly that we are trying to
achieve
Thanks,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
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
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
Dear Mike Frysinger,
In message 200903310513.09082.vap...@gentoo.org you wrote:
...
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
On Tuesday 31 March 2009 06:28:23 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
I'll propose a new design with the following Requierement
Generic delay function implementation
- ndelay()
- udelay()
- mdelay()
Generic helper
- khz2cycles()
- hz2cycles()
On 12:28 Tue 31 Mar , Wolfgang Denk wrote:
Dear Mike Frysinger,
In message 200903310513.09082.vap...@gentoo.org you wrote:
...
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
On 07:25 Tue 31 Mar , Mike Frysinger wrote:
On Tuesday 31 March 2009 06:28:23 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
I'll propose a new design with the following Requierement
Generic delay function implementation
- ndelay()
- udelay()
- mdelay()
Dear Mike Frysinger,
In message 200903310725.20652.vap...@gentoo.org you wrote:
Agreed (except that we probably cannot completely throw away the
tick; IIRC there are cases in early startup when nothing else is
available yet).
hrm, i can see that. but you agree that most use
Dear Scott McNutt,
In message 49d2014f.4070...@psyent.com you wrote:
so if we were to document things, it should read like this:
- CONFIG_SYS_HZ is required to be 1000
Can't this just be eliminated? It's stupid to have a configurable
option that is neither ;-)
And it doesn't do much
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090331113956.gd28...@game.jcrosoft.org you wrote:
Agreed (except that we probably cannot completely throw away the
tick; IIRC there are cases in early startup when nothing else is
available yet).
not necessarely you can
Jean-Christophe PLAGNIOL-VILLARD wrote:
i wouldnt mind starting a patch series for post 2009.05 to clean this up ...
I've in mind too maybe I'll send a first version within few days for a arm soc
and a blackfin based on u-boot-v2
In contrast to Jean-Christophe's plan
Dear Mike Frysinger,
In message 200903272130.26825.vap...@gentoo.org you wrote:
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.
If in doubt, look it up in the PowerPC implementation. That's the
reference for
On Tue, Mar 31, 2009 at 05:48:01PM +0200, Wolfgang Denk wrote:
We still need some hint that the timer works in millisecond
resolution, though - no matter what you call it.
How about just calling it HZ (or something more verbose like TIMER_HZ,
but the former makes it easier to share code with
Dear Scott Wood,
In message 20090331212514.ga19...@ld0162-tx32.am.freescale.net you wrote:
On Tue, Mar 31, 2009 at 05:48:01PM +0200, Wolfgang Denk wrote:
We still need some hint that the timer works in millisecond
resolution, though - no matter what you call it.
How about just calling it
On Tue, Mar 31, 2009 at 05:49:52PM +0200, Wolfgang Denk wrote:
Please check for example the PowerPC code, then.
Ther ethe timer implementation relies heavily on interrupts and is not
available in early stages, for example in NAND booting systems with
tight memory restrictions.
Is there any
so if we were to document things, it should read like this:
- CONFIG_SYS_HZ is required to be 1000
- get_ticks() / get_tbclk() should be deprecated -- use get_timer() instead
- get_timer(X) returns the number of milliseconds since the last call to
reset_timer(), minus X (which is in
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
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,
23 matches
Mail list logo
