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

[J. William Campbell]

On 5/23/2011 2:02 PM, Graeme Russ wrote:
> 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?
Hi All,
        That would probably be the best way to go for now. It might slow 
things down a bit though, if these delays are all desired to be "short", 
like 1 ms. We would expand the 1 ms delay to 15 ms (average) while the 
current (illegal) solution would expand a 1 ms delay to 10 ms always. It 
is worth trying I think. It is also true that any other delays in the 
program will suffer from the 10 ms resolution problem, so your idea is I 
think a good one.

Best Regards,
Bill Campbell
> Regards,
>
> Graeme
>
>
>