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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
