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
ude
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)?
>
Dear Graeme Russ,
In message you
wrote:
>
> 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
Maybe you can summarize and submit a patch, please?
Best regards,
Wolfgang Denk
--
DENX Soft
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
cloc
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
http://lists.denx.de/mailman/lis
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
>> 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 HZ (
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
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
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 cal
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 L
Dear Dirk Behme,
In message <49cdccc1.5050...@googlemail.com> you wrote:
>
> > - get_ticks - return some notion of "cpu ticks"
>
> Yes. Returns the number of cpu ticks since power up. I.e. with 1000
> ticks per second (CONFIG_SYS_HZ) the number of elapsed ms since power up.
Hey. What a chance.
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 f
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
http://lists.denx.de/p
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 ca
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
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
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
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 framew
> 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 for my confidence when things stop working
(like my tftp downloads now that t
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
> > > - khz2c
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
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
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
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 millisecond
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,
27 matches
Mail list logo
