> -----Original Message-----
> From: Marc Brekoo [mailto:kernelnewbie@brekoo.no-ip.com]
> Sent: Friday, November 02, 2001 2:48 PM
>
> > On Fri, Nov 02, 2001 at 12:26:18PM -0800, Christine Ames wrote:
<snip>
> > > I'm looking for a way to "busy wait" <= 400 nanoseconds.
> > >
> > > In _Linux_Device_Drivers_ I've found udelay(for micro
> > > seconds) and mdelay(for milli seconds), but they state (2nd
> > > edition, page 189) that "Currently, support for delays longer
> > > than a few microseconds and shorter than a timer tick is very
> > > inefficient." I found no further discussion.
> > >
> > > "Inefficient" or not, I need a cross-platform/cross-kernel
> > > way to stall <= 400ns while my hardware gets back to me. Am
> > > I stuck, or is there a way?
> >
> > There's no way currently to do that, the best you can do is
> udelay(1),
> which is
> > 1ns. Any more, and you'll need to write your own function, based on
> udelay, it's
> > not *that* difficult, divide the magic constant by 2 to get
> roughly 550ns,
> I'd
> > think...
>
> I thing you mean 1ms, not 1ns... or else it would just be udelay(400),
> wouldn't it? ;)
>
> Grs, Marc.
>
Thanks, Marc. I assumed that Mr. Zealey had committed a "typo".
I was thinking that if, every time I communicate with my device, I'm waiting 2-to-3 times longer than necessary to detect a "timeout" then the efficiency of my code would be impacted.
However, management feels that udelay(1) to get 1 microsecond of delay isn't too much of a performance hit.
The spec says wait 400 nanoseconds, but hey, it's their hardware!
Harmony,
Christine
