[U-Boot] [PATCH] [Timer]Remove calls to [get, reset]_timer outside arch/

[Graeme Russ]

On 24/05/11 06:49, J. William Campbell wrote:
> On 5/23/2011 1:10 PM, Graeme Russ wrote:
>> On 24/05/11 04:29, Scott McNutt wrote:
>>> Hi Bill,
>>>
>>> J. William Campbell wrote:
>>>> On 5/23/2011 6:12 AM, Scott McNutt wrote:
>>>>> Dear Graeme,
>>>>>
>>>>> Graeme Russ wrote:
>>>>>> On 23/05/11 22:19, Scott McNutt wrote:
>>>>>>> Hi Graeme,
>>>>>>>
>>>>>>> Graeme Russ wrote:
>>>>>>>> There is no need to use get_timer() and reset_timer() and there are
>>>>>>>> build
>>>>>>> I must have missed something WRT reset_timer() -- my apologies
>>>>>>> if I'm covering old ground.
>>>>>>>
>>>>>>> When the timestamp is incremented using an interrupt that occurs with
>>>>>>> a period greater than 1 ms, we can get early timeouts. reset_timer()
>>>>>>> solved the problem. What's the recommended approach for dealing with
>>>>>>> this without reset_timer() ?
>>>> Hi Scott,
>>>>            Are you saying that the interrupt frequency is greater than
>>>> 1000 times per second, or as I read it, the frequency is less than 1000
>>>> per second (period greater than 1 ms). If anything, that should make the
>>>> timer run slow, not fast.
>>>>   I wonder if it is a resolution issue. What are the typical delays in ms
>>>> you are using?
>>> Some older nios2 implementations have _fixed_ 10 msec timers.
>>> Basically, the timestamp is incremented asynchronous to get_timer(0).
>>> So a  10 msec timeout can occur, for example, almost immediately if
>>> the timer isn't reset just prior to calling get_timer(0). There are
>>> more details in the comments for the following commits:
>>>
>>> nios2: Reload timer count in reset_timer():
>>>    d8bc0a2889700ba063598de6d4e7d135360b537e
>>>
>>> cfi_flash: reset timer in flash status check:
>>>    22d6c8faac4e9fa43232b0cf4da427ec14d72ad3
>>>
>>> I'm totally in favor of cleaning this stuff up. It caused some
>>> headaches (and wasted time) about 13 months ago. My primary concern
>>> is to avoid breaking things that currently work for us nios2
>>> weenies ... at least for any length of time.
>>>
>>> Things are a bit tight for me until next week or so. I'll probably
>>> come up for air around June 1st ... and I'll be glad to help out.
>>>
>> Is there any reason why we cannot silently perform a reset_timer() any time
>> set_timer() is called with a parameter of 0?
> Hi All,
>      I assume you mean get_timer(0)?  In principle, you cannot do this

Yes - it's early, no coffee yet ;)
> because it could be inside another get_timer(0) loop that has already some
> time elapsed before you hit the inner get_timer(0). I think what needs to

Correct, but that is what is already happening for ALL arches in cfi due to
the reset_timer() before get_timer(0) - I am suggesting sandboxing the
problem to NIOS until we sort out the timer API properly

> happen on the old NIOS with 10 ms resolution on the interrupt times is that
> all timer intervals must have 10 ms added and then rounded up to the
> nearest multiple of 10. Thus, if you wanted to wait for 1 millisecond, you
> must use an argument of 20 ms to be sure you wait at all! If you use an
> argument of 10, it won't help because you could get an interrupt right away
> and exit. If these routines are nios2 specific, you could add a local
> reset_timer, but I assume they are generic. . Note that if these routines
> are not nios2 specific, is there any harm in waiting "too long"?

Well, we have no control over the argument in cfi driver (unless you plan
to put #ifdef NIOS all over the place)

Maybe we could round up the parameter inside get_timer() itself?

Regards,

Graeme