On Wed, Jun 15, 2011 at 11:27 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass wrote:
>> Hi Graeme,
>>
>> On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote:
>> [snip]
BTW should the deltas return a signed value?
>>>
>>> No - times are unsigned utilis
Hi Simon,
On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote:
> [snip]
>>>
>>> BTW should the deltas return a signed value?
>>
>> No - times are unsigned utilising the entire range of the u32 so (to -
>> from) will always retur
Hi Graeme,
On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote:
[snip]
>>
>> BTW should the deltas return a signed value?
>
> No - times are unsigned utilising the entire range of the u32 so (to -
> from) will always returned the unsigned delta, even if there is a wrap
> between them. I cannot ima
Hi Simon,
On Thu, Jun 16, 2011 at 7:58 AM, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ 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 n
Hi Graeme,
On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ 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 - Extrapolate
On 16/06/11 02:03, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ wrote:
>> Hi Wolfgang,
> ...
>>>
>>> /*
>>>* round - used to control rounding:
>>>* <0 : round down, return time that has passed AT LEAST
>>>* =0 : don't round, provid
Hi Graeme,
On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ 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 up, ret
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 yo
> 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
Hi Wolfgang,
On Tue, May 31, 2011 at 3:49 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message 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 misl
Hi Wolfgang,
On Tue, May 31, 2011 at 4:03 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message 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
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 mo
Dear Graeme Russ,
In message 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 don't need yet another function that
dioes the same j
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
Dear Simon Glass,
In message 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 name that it allocates one of (eventually sever
Dear Wolfgang Denk,
> 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...
>
>
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 awa
Dear Graeme Russ,
> On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer
> wrote:
>> Dear Simon Glass,
>>
>>> On Mon, May 30, 2011 at 5:24 PM, Graeme Russ
>>> wrote:
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
>>>
>>> ...
>
> make_timeout() can be arch/so
On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer
wrote:
> Dear Simon Glass,
>
>> On Mon, May 30, 2011 at 5:24 PM, Graeme Russ
>> 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 ac
On Mon, May 30, 2011 at 3:57 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message 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 increm
Dear Simon Glass,
> On Mon, May 30, 2011 at 5:24 PM, Graeme Russ 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 sho
Hi Reinhard,
On Tue, May 31, 2011 at 2:36 PM, Reinhard Meyer
wrote:
> Dear Graeme Russ,
>
>> Hi Reinhard,
>>
>> On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
>> wrote:
>>>
>>> Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
wrote:
>>
On Mon, May 30, 2011 at 5:24 PM, Graeme Russ 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 a 10 ms NIOS
Dear Graeme Russ,
> Hi Reinhard,
>
> On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
> wrote:
>> Dear Graeme Russ,
>>>
>>> Hi Reinhard,
>>>
>>> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
>>> wrote:
Dear ALL,
it still escapes me why everyone tries to make things so co
Hi Reinhard,
On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer
wrote:
> Dear Graeme Russ,
>>
>> Hi Reinhard,
>>
>> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
>> wrote:
>>>
>>> Dear ALL,
>>>
>>> it still escapes me why everyone tries to make things so complicated
>>> INSIDE the loop.
>>>
>>>
Dear Graeme Russ,
> Hi Reinhard,
>
> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
> 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
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer
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 timeout */
> u32 start
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 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) -
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
> secon
Hi Wolfgang,
On 30/05/11 20:57, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message 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 increm
Dear Simon Glass,
In message 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.
OK. Good.
> But in general it is possible that
On Sun, May 29, 2011 at 8:55 AM, Wolfgang Denk 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 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 h
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 message you wrote:
> I think we will need to
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;
>> } e
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 {
>
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 message you wrote:
I think we will need to define get_timer() weak - Nios will have to
overri
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
>> wrote:
>>> On 5/26/2011 9:33 PM, Graeme Russ wrote:
Hi Bill,
>>>
>> [massive snip]
[another big snip]
>> I just realised - the ISR
On 5/27/2011 8:13 AM, Simon Glass wrote:
> On Fri, May 27, 2011 at 8:00 AM, J. William Campbell
> 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
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 wrote:
> Dear Graeme Russ,
>
> In message
> you wrote:
>> Besides, Nios
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 wrote:
Dear Graeme Russ,
In message you
wrote:
> Besides, Nios can return an increment of 10 (presumably ms) between
On 5/26/2011 11:54 PM, Graeme Russ wrote:
> On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
> wrote:
>> On 5/26/2011 9:33 PM, Graeme Russ wrote:
>>> Hi Bill,
>>>
>>
> [massive snip]
>
> OK, you have my ears pricked - Can you give me code samples for:
>
> - get_ticks()
> - sync_timbase()
On Fri, May 27, 2011 at 8:00 AM, J. William Campbell
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) { } while ( ... < 1), then your
>
On 5/27/2011 6:07 AM, Scott McNutt wrote:
> Graeme Russ wrote:
>> Hi Wolfgang
>>
>> On Friday, May 27, 2011, Wolfgang Denk wrote:
>>> Dear Graeme Russ,
>>>
>>> In message you
>>> wrote:
Besides, Nios can return an increment of 10 (presumably ms) between
two immediately consecutive call
On Fri, May 27, 2011 at 12:45 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4ddf53d3.1060...@gmail.com> you wrote:
>>
>> > No. At least not unless you also provide other get__timer()
>> > functions which we most likely will not do.
>>
>> I think you will find most platforms will sup
On Fri, May 27, 2011 at 12:40 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message 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.
>>
>> S
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 message 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') limitation
On 5/27/2011 12:33 AM, Wolfgang Denk wrote:
> 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 alwa
On 5/27/2011 12:28 AM, Wolfgang Denk wrote:
> 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 ge
Graeme Russ wrote:
> Hi Wolfgang
>
> On Friday, May 27, 2011, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message 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 t
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message 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
Dear Graeme Russ,
In message 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 that needs to be
fixed.
Best regards,
Wolfgang D
Dear Graeme Russ,
In message 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);
> > }
> >
> > returns 100 m
On Friday, May 27, 2011, Graeme Russ wrote:
> Hi Wolfgang
>
> On Friday, May 27, 2011, Wolfgang Denk 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 impl
Hi Wolfgang
On Friday, May 27, 2011, Wolfgang Denk 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
>> >
>>
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
Dear Graeme Russ,
In message <4ddf53d3.1060...@gmail.com> you wrote:
>
> > No. At least not unless you also provide other get__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 get_ms
Dear Simon Glass,
In message 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 really understand this. We would only proces
Hi Wolfgang,
On 27/05/11 17:13, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message 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
Hi Wolfgang,
On 27/05/11 17:17, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message 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 sho
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 cou
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
Dear Graeme Russ,
In message 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 get_timer() to
> get_ms_timer() to avoid any ambiguit
Dear Graeme Russ,
In message 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 code for this ?
Best regards,
Wo
On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
wrote:
> On 5/26/2011 9:33 PM, Graeme Russ wrote:
>>
>> Hi Bill,
>>
>
>>
[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 lot if that is too
m
On 5/26/2011 9:33 PM, Graeme Russ wrote:
> Hi Bill,
>
> 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 Thu, May 26, 2011 at 3:44 PM, Graeme Russ wrote:
> On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>>
>> In message 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 ca
Hi Bill,
On Fri, May 27, 2011 at 1:54 PM, J. William Campbell
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
>> wrote:
>>>
[snip]
>>>
>>> Yes, that is the problem. I have come to the view that two 32 bit words
>>>
On 5/26/2011 6:51 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
> 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-b
Hi Bill,
On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
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
>> cheap,
>> transparent a
On 5/26/2011 4:28 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
> 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 main
Hi Bill,
On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
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 stable, I
>> will
On Fri, May 27, 2011 at 4:52 AM, J. William Campbell
wrote:
> On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
>>
>> 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 increasin
On Fri, May 27, 2011 at 3:49 AM, Wolfgang Denk 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 soft
On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message 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 sec
On 5/26/2011 1:27 PM, Wolfgang Denk wrote:
> 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 tim
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,
On 5/26/2011 12:16 PM, Wolfgang Denk wrote:
> 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
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 dea
On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
> 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
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
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 i
Dear Simon Glass,
In message 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 little
time for anything useful.
Best regards,
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 co
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 wrote:
> Hello Everyone,
>
> OK - Starting a new thread to discuss implementation details. This is a
> heads-up for arc
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' that does not rely on software to increment
- ti
87 matches
Mail list logo
