[U-Boot] U-Boot Timer Qualification

[Dirk Behme]

Wolfgang Denk wrote:
> Dear Ladislav Michl,
> 
> In message <20090428151147.GA19683 at linux-mips.org> you wrote:
>> a lot of changes are entering arm tree, many without any commit message.
>> And now we have some special cases which needs some special care for yet
>> unclear reason. OMAP3 timer precission was discussed to death and patch
>> still didn't went in, because it needs to be verified against some
>> document you are claiming is not mandatory.
> 
> Just in case there is any doubt here:
> 
> There is no, and I say *no*, mandatory verification of any timing
> precision in U-Boot.
> 
> We all agree that precision is a good thing to have, it it must come
> at a reasonable effort, and there is no reason to drive it into
> extreme precision.

To come back to the more practical part of this discussion ;) , my 
understanding of this is that we agree that

http://lists.denx.de/pipermail/u-boot/2009-April/051204.html

( http://lists.denx.de/pipermail/u-boot/2009-April/051237.html )

should be applied?

Best regards

Dirk

> Clock signals may need an accuracy of 1 or 2% or better - as we may
> see character corruption if the baudrate generators are off too far -
> but this is usually a hardware issue in the first place.
> 
> System timers (like udelay() etc.) in U-Boot do not need such a level
> of accuracy. That does not mean we should intentionally be inaccurate.
> 
> And of course actual testing is good, and documentation of the test
> results is even better.
> 
> But: it is not mandatory. Not in U-Boot (and also not in Linux, to the
> best of my knowledge).
> 
>> I'll omit more comments to this topic until my objections get answered.
>> Just one side note: Both methods can be easily set in code, freeing
>> every and each developer from reimplementing test case. Such code could
>> be one for all and selfexplaining. Is it worth doing using current timer
>> API?
> 
> See my previuous posting. I don;t think that a generic test method
> that works on all boards would be possible.
> 
> Best regards,
> 
> Wolfgang Denk
>