[U-Boot-Users] interrupts.s/udelay accuracy.
r-woodruff2 at ti.com
Thu May 29 18:39:06 CEST 2003
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.
> 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)
More information about the U-Boot