On 1/24/2011 5:02 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4d3d2942.4060...@free.fr> you wrote:
>> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't>
>> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would>
>> not go through the full 32
Dear Albert ARIBAUD,
In message <4d3d2942.4060...@free.fr> you wrote:
>
> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't >
> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would >
> not go through the full 32-bit range, which would cause issues with the
Dear Reinhard Meyer,
In message <4d3d2f34.6020...@emk-elektronik.de> you wrote:
> Dear all,
>
> its quite funny to see how we go around in circles here, this proposal of
> Albert
> now is quite close to my original proposal. Only that I factored the
> ms_to_ticks
> AND the comparison into the t
Hi Albert,
Am 24.01.2011 12:58, schrieb Albert ARIBAUD:
> Hi Andreas,
>
> Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>
>>> That's where I come back to one point of my proposal: if we can get a
>>> general framework for get_timer() to return a 64-bit free-running tick
>>> value, then we migh
Dear Albert ARIBAUD,
In message <4d3d2942.4060...@free.fr> you wrote:
>
> - get_timer() works in pure ticks, not ms, and thus does not need
> multiply/divide; it may at most need to implement a carry over from 32
> bit to 64 bits *if* the HW counter is 32 bits *and if* we want a 64-bit
> virtual c
Le 24/01/2011 12:58, Albert ARIBAUD a écrit :
> For instance, if at loop entry get_timer() was, say, 10 ticks to
> rollover and the loop timing was 12 ticks, you end up with an end date
> of 2. If your loop body runs long enough, get_timer() may already have
> gone past this and will this stay gre
Hi Andreas,
Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>> That's where I come back to one point of my proposal: if we can get a
>> general framework for get_timer() to return a 64-bit free-running tick
>> value, then we might not need a ms-based get_time() at all, because we
>> could use get
Dear Albert ARIBAUD,
Am 24.01.2011 um 08:24 schrieb Albert ARIBAUD:
> Le 24/01/2011 02:42, J. William Campbell a écrit :
>
>> Hi All,
>>In order to avoid doing 64 bit math, we can define a "jiffie"
>> or a "bogo_ms" that is the 64 bit timebase shifted right such that the
>> lsb of th
Dear all,
its quite funny to see how we go around in circles here, this proposal of Albert
now is quite close to my original proposal. Only that I factored the ms_to_ticks
AND the comparison into the timer calls:
u64 timer_setup(u32 timeout_in_ms)
{
return get_ticks() + ms_to_ticks(timeou
Le 24/01/2011 02:42, J. William Campbell a écrit :
> Hi All,
> In order to avoid doing 64 bit math, we can define a "jiffie"
> or a "bogo_ms" that is the 64 bit timebase shifted right such that the
> lsb of the bottom 32 bits has a resolution of between 0.5 ms and 1 ms.
> It is then po
On 1/23/2011 2:57 PM, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message<4d3c9bfc.1010...@emk-elektronik.de> you wrote:
get_timer() returns a monotonous upward counting time stamp with a
resolution of milliseconds. After reaching ULONG_MAX the timer wraps
around to 0.
>> Exa
Dear Reinhard Meyer,
In message <4d3c9bfc.1010...@emk-elektronik.de> you wrote:
>
> >> get_timer() returns a monotonous upward counting time stamp with a
> >> resolution of milliseconds. After reaching ULONG_MAX the timer wraps
> >> around to 0.
>
> Exactly that wrap makes the situation so compli
On 23.01.2011 22:22, Reinhard Meyer wrote:
> On 23.01.2011 21:59, Albert ARIBAUD wrote:
>> Le 23/01/2011 20:35, Wolfgang Denk a écrit :
>>
>>> At the moment I would suggest to change the existing interface like
>>> that:
>>>
>>> * Drop the set_timer() function.
>>>
>>> * Change get_timer() to take
On 23.01.2011 21:59, Albert ARIBAUD wrote:
> Le 23/01/2011 20:35, Wolfgang Denk a écrit :
>
>> At the moment I would suggest to change the existing interface like
>> that:
>>
>> * Drop the set_timer() function.
>>
>> * Change get_timer() to take no argument, i. e.:
>>
>> unsigned long get_timer(voi
Le 23/01/2011 20:35, Wolfgang Denk a écrit :
> At the moment I would suggest to change the existing interface like
> that:
>
> * Drop the set_timer() function.
>
> * Change get_timer() to take no argument, i. e.:
>
> unsigned long get_timer(void);
>
>get_timer() returns a monotonous upwa
Dear Reinhard Meyer,
In message <4d3c77bc.50...@emk-elektronik.de> you wrote:
>
> >> u32 timeout = timeout_init(100); /* 100ms timeout */
> >>
> >> do {...} while (!timed_out(timeout));
> >
> > I dislike this approach. I immediately fear the same problem I just
> > saw (incorrectly) in Albert's pr
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4d3c0271.4070...@emk-elektronik.de> you wrote:
>>
>> There were several suggestions about that in the past (including from me)
>> that involve rework everywhere HZ related timeouts are used. I still
>> prefer a method as follows (because it
Dear Reinhard Meyer,
In message <4d3c0271.4070...@emk-elektronik.de> you wrote:
>
> There were several suggestions about that in the past (including from me)
> that involve rework everywhere HZ related timeouts are used. I still
> prefer a method as follows (because it does not need repeated mul/d
Dear Albert ARIBAUD,
In message <4d3b568d.3080...@free.fr> you wrote:
>
> > You see the problem?
>
> Actually no, I don't. As a reminder, I am considering the following
> definitions:
>
> #define time(n) (ticks-n)
> #define ms_to_ticks(ms) (ms * fast_tick_rate) / CONFIG_SYS_HZ
Ah,
Dear Wolfgang Denk,
> In message<4d3b5171.7090...@emk-elektronik.de> you wrote:
>>
>> With all this half quoting and deleting of important parts,
>> my original proposal was lost again.
>
> This is a prettyu long running thread, and I am not exactly sure what
> your original proposal actually was.
Dear Reinhard Meyer,
In message <4d3b5171.7090...@emk-elektronik.de> you wrote:
>
> With all this half quoting and deleting of important parts,
> my original proposal was lost again.
This is a prettyu long running thread, and I am not exactly sure what
your original proposal actually was. Could
Le 22/01/2011 22:26, Wolfgang Denk a écrit :
>> Hmm... My idea with providing time() with an argument was that precisely
>> since we are interested only in elapsed time, not absolute time, our
>> basic time function should be able to tell us relative times.
>
> The disadvantage of this approach is
Dear Wolfgang Denk,
> Dear Albert ARIBAUD,
With all this half quoting and deleting of important parts,
my original proposal was lost again.
If you really care to look at it, it
1. does not have issues with rollover
2. does not have problems with nested timeouts
3. does 64 bit mul/div calculation
Dear Albert ARIBAUD,
In message <4d3b3b5c.2060...@free.fr> you wrote:
>
> > When attempting to come up with true generic code, we should probably
> > _always_ use a (virtual) unsigned 64 bit counter.
>
> That's fine with me. We'll just have to keep in mind that with a 32-bit
> HW counter, the u
Hi Wolfgang,
Le 22/01/2011 20:19, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and
>> should not IMO, when the HW has it.
>
> When attempting to come up with true generic code, we should probably
> _always_ use a (virtual) unsi
Dear Albert ARIBAUD,
In message <4d3aaf63.1030...@free.fr> you wrote:
>
> Agreed for unnecessary mult-div, but 64-bit we would not avoid, and
> should not IMO, when the HW has it.
When attempting to come up with true generic code, we should probably
_always_ use a (virtual) unsigned 64 bit coun
Le 22/01/2011 11:42, Reinhard Meyer a écrit :
> Dear Albert ARIBAUD,
>> Hi All,
>>
>> I am starting this thread to revive and, hopefully, come to a general
>> agreement on how timers should be implemented and used in the ARM
>> architecture, and get rid of current quick fixes. Let us start with
>>
Dear Albert ARIBAUD,
> Hi All,
>
> I am starting this thread to revive and, hopefully, come to a general
> agreement on how timers should be implemented and used in the ARM
> architecture, and get rid of current quick fixes. Let us start with
> Reinhard's proposal:
>
>> There were several suggestio
Hi All,
I am starting this thread to revive and, hopefully, come to a general
agreement on how timers should be implemented and used in the ARM
architecture, and get rid of current quick fixes. Let us start with
Reinhard's proposal:
> There were several suggestions about that in the past (incl
29 matches
Mail list logo
