On 25/05/11 18:06, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <BANLkTi==emvE+2Xu-R=hzh3tgfjxs9d...@mail.gmail.com> you wrote: >> >> Well, I think we can leave NTP out of the picture for U-Boot - What I am >> really getting at is are the time bases for udelay() and get_timer() the >> same, and are they always the most accurate which is readily available >> to U-Boot. > > Please assume "no" to both questions.
Thought so > > Even more important: stop worrying about this. The implementation is > noit supposed to make ANY such assumptions. I'm not really worrying about from the perspective of the new timer API, it's idle curiosity and getting a better understanding >> I mean udelay() clocked by a tick counter and get_timer() clocked by >> an interrupt versus both being clocked by the same phyiscal tick counter >> (even though both are clocked by the same on-board xtal) > > You really should not care about those low-level details. They can > and shall be ignored. Yes, but you find that there is another level of simplification available... >>> There are counters of many different sizes around. You cannot squeeze >>> a bigger counter into a smaller data ubit, but you can easily stick >>> smaller data into a bigger container. So it seems most natural to me >>> to chose that data type that fits all, i. e. a bigger one. >> >> Putting the smaller counter into a larger bit space causes problems because >> it wraps to "All 0's" before it gets to "All 1's" - This makes a simple >> unsigned 'current - last' calculation fail at the rollover point. The same >> problem does not occur if you truncate a larger counter into a smaller bit >> space > > But then you may significantly reduce the available time-span; you may > see the counter wrapping around every few seconds. You will not be > able to implement - say - a 10 second delay because you cannot know if > there were 1, 2, or more rollovers inbetween. > > > I see two options: > > 1) either we can have some signal when the timer wrapes around (like > an interrupt); in this case it does not matter how big the counter > itself is, we just increment our own local 64 bit timestamp. > > 2) Alternatively, I could imagine we use a 64 bit container plus a > mask which specifiec how many bits are actually used - then we can > accommodate counters with any numbers of valid bits. > 3) Keep calling get_timer() (which you do when checking protocol time-outs) - This keeps kicking the prescaler Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
