[U-Boot-Users] interrupts.s/udelay accuracy.

[Woodruff, Richard]

Perhaps its not worth worrying about in this context.  Several of the ports
use a simple split /1000 /1000 along with CFG_HZ to convert microseconds to
ticks.  When I grepped the config files I saw a pretty wide range of raw
frequency's including some below the megahertz range which the /1000's are
normalizing for.   A simple grep of the sources also shows many functions
use udelay with input ranges from 1 to 100,000,000.  I called out ethernet,
but I was more wondering about protocols which might like to delay.  In
fairness most if not all which use this correction are in the mhz range.

In my case I can set the tick rate for the free running decrementer in the
KHz range or in the Mhz range.  To allow for a variable CFG_HZ setting it
would be nice if the normalization did not assume megahertz, and nice to
allow for a wide udelay input, such that tmo *= CFG_HZ, would not overflow a
32 bit number.  I had used some code in the past which did use long long's
to normalize from various input levels, sec/milli/micro/nano, and converted
it to clock ticks with out dropping bits.

When I reached the point of wondering if I should use a bit more code, I
started to wonder if it was worth my time to even do it...thus I asked if
anything really needed it.

Regards,

Richard W.

> 
> So - why are you asking? There is no problem  with  the  accuracy  of
> udelay() etc.
> 
> > enough of the basics ported for my arm925/omap based board 
> such that 
> > it comes to a u-boot shell, and things like sleep x work....I was 
> > thinking about moving on to getting my ethernet device 
> working, and am 
> > a little
> 
> What has udelay() or other timing functions to do with ethernet?
> 
> > uneasy about the way I (and it appears several others) have 
> hacked the 
> > time conversions.  Does gcc provide some nice 64 bit integer 
> > manipulation libraries which aren't huge?  If so I'd be tempted to 
> > bring in some code
> 
> Which sort of libraries do you need? If you really think you 
> must you could use "log long" data types, but I don't see any 
> need for that.
> 
> > which does the right thing and doesn't have to worry about integer 
> > over/under flows.
> 
> What exactly are you talking about?
> 
> Maybe you should explain the problem you are trying to solve. 
> I  feel you must be on a wrong track...
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: 
> wd at denx.de I can't say I've ever been lost, but I was 
> bewildered once for  three
> days.                                     - Daniel Boone (Attributed)
>