Hi Simon,
On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass s...@chromium.org wrote:
Hi Graeme,
On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
[snip]
BTW should the deltas return a signed value?
No - times are unsigned utilising the entire range of the u32 so (to -
On Wed, Jun 15, 2011 at 11:27 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Simon,
On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass s...@chromium.org wrote:
Hi Graeme,
On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ graeme.r...@gmail.com wrote:
[snip]
BTW should the deltas return a signed
Hi Wolfgang,
Since discussion seems to have died down, I have assumed pseudo consensus
and have started hitting the timer cleanup in earnest. All I can say is:
Wow! What a mess ;)
We could also design a more complicated API like this one, but I doubt
this is needed:
Well, it is needed if you
Hi Graeme,
On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Wolfgang,
...
/*
* round - used to control rounding:
* 0 : round down, return time that has passed AT LEAST
* =0 : don't round, provide raw time difference
* 0 : round
On 16/06/11 02:03, Simon Glass wrote:
Hi Graeme,
On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Wolfgang,
...
/*
* round - used to control rounding:
* 0 : round down, return time that has passed AT LEAST
* =0 : don't round,
Hi Graeme,
On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ graeme.r...@gmail.com wrote:
On 16/06/11 02:03, Simon Glass wrote:
- the common case is min I think, so let's get rid of the min prefix
so everyone will use it without question or needing to read screeds of
doc
I don't like this idea
Hi Simon,
On Thu, Jun 16, 2011 at 7:58 AM, Simon Glass s...@chromium.org wrote:
Hi Graeme,
On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ graeme.r...@gmail.com wrote:
On 16/06/11 02:03, Simon Glass wrote:
- the common case is min I think, so let's get rid of the min prefix
so everyone will
Dear Graeme Russ,
In message BANLkTikZUkk1EaYqCg=5mb2npva2ie6...@mail.gmail.com you wrote:
Don't forget the API will have a get_current_ms() so we can do duration
I don't think we will have this.
We have get_timer() (or, as recently suggested, renamed it into
time_read() or similar). We
Dear Reinhard Meyer,
In message 4de47ea1.1090...@emk-elektronik.de you wrote:
All you can throw into the timer discussion is critics and pointless remarks,
but I miss any productive input from you except sometimes pointing out how
powerpc does it.
Thanks you very much.
We DO have most of
Hi Wolfgang,
On Tue, May 31, 2011 at 4:03 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message BANLkTikZUkk1EaYqCg=5mb2npva2ie6...@mail.gmail.com you wrote:
Don't forget the API will have a get_current_ms() so we can do duration
I don't think we will have this.
We have
Hi Wolfgang,
On Tue, May 31, 2011 at 3:49 PM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message BANLkTi=t_pzb9toptqunzxarvqshn80...@mail.gmail.com you wrote:
I do think it would be nice to put a time_ prefix before all the time
functions, but this is a pretty minor point.
going to be critical for boot profiling and I see no reason to think
about it now rather than later.
going to be critical for boot profiling and I see no reason NOT to think
about it now rather than later.
Oops,
Regards,
Graeme
___
U-Boot mailing
Dear Simon Glass,
In message banlktim-jzymmzw_twhhhqqyovmk9mz...@mail.gmail.com you wrote:
Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be confident that
the time between the first and second increments is 10ms.
Hi Wolfgang,
On 30/05/11 20:57, Wolfgang Denk wrote:
Dear Simon Glass,
In message banlktim-jzymmzw_twhhhqqyovmk9mz...@mail.gmail.com you wrote:
Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be confident that
the
Dear Graeme Russ,
In message 4de383d3.7020...@gmail.com you wrote:
Some platforms are _way_ worse than this - I am sure I have seen a udelay()
done with the millisecond time - So udelay(100) could be closer to
udelay(1000) - So your above 5 second delay could take as long as 50
seconds!!!
Hi Wolfgang,
On 30/05/11 22:31, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4de383d3.7020...@gmail.com you wrote:
Some platforms are _way_ worse than this - I am sure I have seen a udelay()
done with the millisecond time - So udelay(100) could be closer to
udelay(1000) - So your
Dear ALL,
it still escapes me why everyone tries to make things so complicated INSIDE the
loop.
Why not just define an API like this:
u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */
u32 start = get_timer();
while ((get_timer() - start) timeout)
...
make_timeout() can
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear ALL,
it still escapes me why everyone tries to make things so complicated INSIDE
the loop.
Why not just define an API like this:
u32 timeout = make_timeout(5); /* minimum 5 millisecond
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear ALL,
it still escapes me why everyone tries to make things so complicated INSIDE
the loop.
Why not just define an API like this:
u32 timeout = make_timeout(5); /*
Hi Reinhard,
On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear ALL,
it still escapes me why everyone tries to make things so complicated
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
u-b...@emk-elektronik.dewrote:
Dear ALL,
it still escapes me why everyone tries to make
On Mon, May 30, 2011 at 5:24 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
...
make_timeout() can be arch/soc/platform specific and take into account to
return at least
such a value that the timeout is never cut short. (In case of
Hi Reinhard,
On Tue, May 31, 2011 at 2:36 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
Dear Simon Glass,
On Mon, May 30, 2011 at 5:24 PM, Graeme Russgraeme.r...@gmail.com wrote:
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
...
make_timeout() can be arch/soc/platform specific and take into account to
return at least
such a value that the timeout is never
On Mon, May 30, 2011 at 3:57 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message banlktim-jzymmzw_twhhhqqyovmk9mz...@mail.gmail.com you wrote:
Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be
On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Simon Glass,
On Mon, May 30, 2011 at 5:24 PM, Graeme Russgraeme.r...@gmail.com
wrote:
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
...
make_timeout() can be arch/soc/platform specific
Dear Graeme Russ,
On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer
u-b...@emk-elektronik.de wrote:
Dear Simon Glass,
On Mon, May 30, 2011 at 5:24 PM, Graeme Russgraeme.r...@gmail.com
wrote:
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
...
make_timeout() can be
Dear Reinhard Meyer,
In message 4de4743c.5040...@emk-elektronik.de you wrote:
Exactly! And (saying it silently) this would not mandate that the now hidden
internal
timer needs to be in ms units, it could be the bare natural tick of the
hardware...
Yes. We can throw everything away and
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message4de4743c.5040...@emk-elektronik.de you wrote:
Exactly! And (saying it silently) this would not mandate that the now hidden
internal
timer needs to be in ms units, it could be the bare natural tick of the
hardware...
Yes. We can throw
Dear Simon Glass,
In message BANLkTi=t_pzb9toptqunzxarvqshn80...@mail.gmail.com you wrote:
I do think it would be nice to put a time_ prefix before all the time
functions, but this is a pretty minor point.
Agree.
By now, I also find get_timer() kind of misleading - one might expect
from that
Dear Reinhard Meyer,
In message 4de47046.3010...@emk-elektronik.de you wrote:
Excuse me, but THIS API does not prevent the user to do a
(get_timer() - start) timeout inside the loop, making your argument moot.
You can be pretty sure that I will NAK any design that _prevents_ me
from doing
Dear Scott McNutt,
In message 4ddfa206.5050...@psyent.com you wrote:
Besides, Nios can return an increment of 10 (presumably ms) between
two immediately consecutive calls. This causes early timeouts in CFI
driver
...
And this is what reset_timer() corrected.
I cannot see how
On Sun, May 29, 2011 at 8:55 AM, Wolfgang Denk w...@denx.de wrote:
Dear Scott McNutt,
In message 4ddfa206.5050...@psyent.com you wrote:
Besides, Nios can return an increment of 10 (presumably ms) between
two immediately consecutive calls. This causes early timeouts in CFI
driver
...
Dear Graeme Russ,
u32 get_timer(u32 base)
{
if (base != 0) {
if (timer - base (CONFIG_MIN_TIMER_RESOLUTION * 2))
return 0;
else
return timer - base - CONFIG_MIN_TIMER_RESOLUTION;
} else {
On 28/05/11 16:18, Reinhard Meyer wrote:
Dear Graeme Russ,
u32 get_timer(u32 base)
{
if (base != 0) {
if (timer - base (CONFIG_MIN_TIMER_RESOLUTION * 2))
return 0;
else
return timer - base - CONFIG_MIN_TIMER_RESOLUTION;
} else {
On 5/27/2011 10:53 PM, Graeme Russ wrote:
Hi Bill,
On 28/05/11 00:23, J. William Campbell wrote:
On 5/27/2011 12:35 AM, Graeme Russ wrote:
Hi Wolfgang,
On 27/05/11 17:13, Wolfgang Denk wrote:
Dear Graeme Russ,
In messagebanlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote:
I
On 5/26/2011 9:33 PM, Graeme Russ wrote:
Hi Bill,
snip
get_ticks() does not care about the clock rate - It simply looks at the
current value of the hardware tick counter and the value of the hardware
tick counter the last time get_ticks() was called, calculates the difference
and adds that
On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 9:33 PM, Graeme Russ wrote:
Hi Bill,
snip
[massive snip]
OK, you have my ears pricked - Can you give me code samples for:
- get_ticks()
- sync_timbase() (no need to implement the whole
Dear Graeme Russ,
In message banlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote:
I think we will need to define get_timer() weak - Nios will have to
override the default implementation to cater for it's (Nios') limitations
Please don't - isn't the purpose of this whole discussion
Dear Graeme Russ,
In message BANLkTi=Nj09smJ+tTuE4p=rWFz=r9gb...@mail.gmail.com you wrote:
I think we should - If CONFIG_SYS_HZ _MUST_ be 1000 anyway, what is the
point. Also, get_timer() utilisation as it stands for the most part already
assumes a 1ms time base. Maybe we should change
Dear J. William Campbell,
In message 4ddefdbc.7050...@comcast.net you wrote:
I really STRONGLY disagree with this statement. If you actually needed
64 bit variables, fine use them. But as I have already shown, you do not
need them in general. We are computing a 32 bit result. There is some
Dear J. William Campbell,
In message 4ddf2072.5090...@comcast.net you wrote:
...
The problem is that the way we previously detected wrapping does not
work if the interrupt rate is == to the counter wrap time, which it
essentially always is. If get_ticks is trying to update the wrap count
Hi Wolfgang,
On 27/05/11 17:17, Wolfgang Denk wrote:
Dear Graeme Russ,
In message BANLkTi=Nj09smJ+tTuE4p=rWFz=r9gb...@mail.gmail.com you wrote:
I think we should - If CONFIG_SYS_HZ _MUST_ be 1000 anyway, what is the
point. Also, get_timer() utilisation as it stands for the most part
Hi Wolfgang,
On 27/05/11 17:13, Wolfgang Denk wrote:
Dear Graeme Russ,
In message banlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote:
I think we will need to define get_timer() weak - Nios will have to
override the default implementation to cater for it's (Nios') limitations
Dear Simon Glass,
In message banlktinxp1wua9+_evc0ppk+7uj89uk...@mail.gmail.com you wrote:
I guess you cannot, at least not in general. In worst case that would
mean we have to process 1e6 interrupts per second, which leaves little
time for anything useful.
Sorry Wolfgang I don't
Dear Graeme Russ,
In message 4ddf53d3.1060...@gmail.com you wrote:
No. At least not unless you also provide other get_some unit_timer()
functions which we most likely will not do.
I think you will find most platforms will support get_us_timer() trivially.
Those that can't can use
Dear Graeme Russ,
In message 4ddf543d.6020...@gmail.com you wrote:
I think we will need to define get_timer() weak - Nios will have to
override the default implementation to cater for it's (Nios') limitations
Please don't - isn't the purpose of this whole discussion to use
common
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message 4ddf543d.6020...@gmail.com you wrote:
I think we will need to define get_timer() weak - Nios will have to
override the default implementation to cater for it's (Nios') limitations
On Friday, May 27, 2011, Graeme Russ graeme.r...@gmail.com wrote:
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message 4ddf543d.6020...@gmail.com you wrote:
I think we will need to define get_timer() weak - Nios will have to
override the
Dear Graeme Russ,
In message banlktimb4ykkpk10gzkormluyqbpxth...@mail.gmail.com you wrote:
Nobody claims that get_timer() has any specific resolution. It is
perfectly legal that a loop like
for (;;) {
u32t = get_time();
printf(t=%ul\n, t);
Dear Graeme Russ,
In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com you wrote:
Besides, Nios can return an increment of 10 (presumably ms) between
two immediately consecutive calls. This causes early timeouts in CFI
driver
Now this in turn is a bug in the timer implementation
Graeme Russ wrote:
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com you wrote:
Besides, Nios can return an increment of 10 (presumably ms) between
two immediately consecutive calls. This
On 5/27/2011 12:28 AM, Wolfgang Denk wrote:
Dear J. William Campbell,
In message4ddefdbc.7050...@comcast.net you wrote:
I really STRONGLY disagree with this statement. If you actually needed
64 bit variables, fine use them. But as I have already shown, you do not
need them in general. We
On 5/27/2011 12:33 AM, Wolfgang Denk wrote:
Dear J. William Campbell,
In message4ddf2072.5090...@comcast.net you wrote:
...
The problem is that the way we previously detected wrapping does not
work if the interrupt rate is == to the counter wrap time, which it
essentially always is. If
On 5/27/2011 12:35 AM, Graeme Russ wrote:
Hi Wolfgang,
On 27/05/11 17:13, Wolfgang Denk wrote:
Dear Graeme Russ,
In messagebanlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote:
I think we will need to define get_timer() weak - Nios will have to
override the default implementation
On Fri, May 27, 2011 at 12:40 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message banlktinxp1wua9+_evc0ppk+7uj89uk...@mail.gmail.com you wrote:
I guess you cannot, at least not in general. In worst case that would
mean we have to process 1e6 interrupts per second, which
On Fri, May 27, 2011 at 12:45 AM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message 4ddf53d3.1060...@gmail.com you wrote:
No. At least not unless you also provide other get_some unit_timer()
functions which we most likely will not do.
I think you will find most platforms
On 5/27/2011 6:07 AM, Scott McNutt wrote:
Graeme Russ wrote:
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com you
wrote:
Besides, Nios can return an increment of 10 (presumably ms)
On Fri, May 27, 2011 at 8:00 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
[snip]
Hi All,
A more precise statement of the problem is that all timer delays
may be shortened by the timer resolution. So this means that if you have
a timeout of 1 ms in your get_time(0) { }
On 5/26/2011 11:54 PM, Graeme Russ wrote:
On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 9:33 PM, Graeme Russ wrote:
Hi Bill,
snip
[massive snip]
OK, you have my ears pricked - Can you give me code samples for:
- get_ticks()
-
J. William Campbell wrote:
On 5/27/2011 6:07 AM, Scott McNutt wrote:
Graeme Russ wrote:
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com you
wrote:
Besides, Nios can return an increment
On 5/27/2011 8:44 AM, Scott McNutt wrote:
J. William Campbell wrote:
On 5/27/2011 6:07 AM, Scott McNutt wrote:
Graeme Russ wrote:
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message banlktik2sum4sm8aljcrcmz+kcmgwge...@mail.gmail.com
you
On 5/27/2011 8:13 AM, Simon Glass wrote:
On Fri, May 27, 2011 at 8:00 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
[snip]
Hi All,
A more precise statement of the problem is that all timer delays
may be shortened by the timer resolution. So this means that if you have
a
On 28/05/11 01:49, J. William Campbell wrote:
On 5/26/2011 11:54 PM, Graeme Russ wrote:
On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 9:33 PM, Graeme Russ wrote:
Hi Bill,
snip
[massive snip]
[another big snip]
I just realised -
Hi Bill,
On 28/05/11 00:23, J. William Campbell wrote:
On 5/27/2011 12:35 AM, Graeme Russ wrote:
Hi Wolfgang,
On 27/05/11 17:13, Wolfgang Denk wrote:
Dear Graeme Russ,
In messagebanlktinwvy9b4qzelnawf7mkt9z1zem...@mail.gmail.com you wrote:
I think we will need to define get_timer() weak
Hi Graeme,
Thanks very much for doing this. I have been following the discussion
and am very happy that you have continued with it.
On Thu, May 26, 2011 at 6:27 AM, Graeme Russ graeme.r...@gmail.com wrote:
Hello Everyone,
OK - Starting a new thread to discuss implementation details. This is a
On 5/26/2011 6:27 AM, Graeme Russ wrote:
Hello Everyone,
OK - Starting a new thread to discuss implementation details. This is a
heads-up for arch/platform maintainers - Once this is a bit more stable, I
will put it on the wiki
Assumed Capabilities of the Platform
- Has a 'tick counter'
Dear Simon Glass,
In message BANLkTikWwuymrJtMEHBZkvNgNBK1e=r...@mail.gmail.com you wrote:
Can we have a microsecond one also please? Some sort of microsecond
I guess you cannot, at least not in general. In worst case that would
mean we have to process 1e6 interrupts per second, which leaves
Dear Graeme Russ,
In message 4dde5548.3020...@gmail.com you wrote:
Assumed Capabilities of the Platform
- Has a 'tick counter' that does not rely on software to increment
I think we should delete the does not rely on software to increment
part. It is not really essential.
- tick interval
Dear J. William Campbell,
In message 4dde8639.3090...@comcast.net you wrote:
I think it is the task of get_ticks to return the hardware tick counter
as an increasing counter, period. The counter may wrap at some final
count that is not all ones. That is ok. Sync_timebase deals with the
Dear J. William Campbell,
In message 4ddea165.9010...@comcast.net you wrote:
I think it is the task of get_ticks to return the hardware tick counter
as an increasing counter, period. The counter may wrap at some final
count that is not all ones. That is ok. Sync_timebase deals with the
On 5/26/2011 12:16 PM, Wolfgang Denk wrote:
Dear J. William Campbell,
In message4ddea165.9010...@comcast.net you wrote:
I think it is the task of get_ticks to return the hardware tick counter
as an increasing counter, period. The counter may wrap at some final
count that is not all ones.
Dear J. William Campbell,
In message 4ddeafe0.8060...@comcast.net you wrote:
I certainly agree using 64 bits for all calculations is vast overkill.
In fact, I think using 64 bit calculations on systems that have only a
32 bit or less timer register is probably overkill. :-) However, to
On 5/26/2011 1:27 PM, Wolfgang Denk wrote:
Dear J. William Campbell,
In message4ddeafe0.8060...@comcast.net you wrote:
I certainly agree using 64 bits for all calculations is vast overkill.
In fact, I think using 64 bit calculations on systems that have only a
32 bit or less timer register
On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message BANLkTikWwuymrJtMEHBZkvNgNBK1e=r...@mail.gmail.com you wrote:
Can we have a microsecond one also please? Some sort of microsecond
I guess you cannot, at least not in general. In worst case that
On Fri, May 27, 2011 at 3:49 AM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message 4dde5548.3020...@gmail.com you wrote:
Assumed Capabilities of the Platform
- Has a 'tick counter' that does not rely on software to increment
I think we should delete the does not rely on
On Fri, May 27, 2011 at 4:52 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
Dear J. William Campbell,
In message4dde8639.3090...@comcast.net you wrote:
I think it is the task of get_ticks to return the hardware tick counter
as an
Hi Bill,
On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 6:27 AM, Graeme Russ wrote:
Hello Everyone,
OK - Starting a new thread to discuss implementation details. This is a
heads-up for arch/platform maintainers - Once this is a bit more
On 5/26/2011 4:28 PM, Graeme Russ wrote:
Hi Bill,
On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 6:27 AM, Graeme Russ wrote:
Hello Everyone,
OK - Starting a new thread to discuss implementation details. This is a
heads-up for
Hi Bill,
On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 4:28 PM, Graeme Russ wrote:
Why mess around with bit shifting (which you would then have to cludge
into
your platform code) when carting around a 64-bit value is relatively
On 5/26/2011 6:51 PM, Graeme Russ wrote:
Hi Bill,
On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 4:28 PM, Graeme Russ wrote:
Why mess around with bit shifting (which you would then have to cludge
into
your platform code) when carting
Hi Bill,
On Fri, May 27, 2011 at 1:54 PM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
On 5/26/2011 6:51 PM, Graeme Russ wrote:
Hi Bill,
On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
jwilliamcampb...@comcast.net wrote:
[snip]
Yes, that is the problem. I have come to
On Thu, May 26, 2011 at 3:44 PM, Graeme Russ graeme.r...@gmail.com wrote:
On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message BANLkTikWwuymrJtMEHBZkvNgNBK1e=r...@mail.gmail.com you wrote:
Can we have a microsecond one also please? Some sort of
83 matches
Mail list logo
