Re: Very Short Delays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 02, 2001 at 03:05:19PM -0800, Christine Ames wrote:

> > -----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". 

jup :-)

> 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.

I tend to find that it's best to give hardware extra time to catch up, as most
hardware has some member of the family that is quite fucked, and exceeds the
specs etc, but, if you know that this will manage to get back to you within
400ns, go write your own high-res delay routine, this will make a difference if
you're doing something like video capture, IE need a high bandwidth, and have a
very fast processor, otherwise I'd doubt that it will hit your performance much.

Also, can you not poll the device for completion? Maybe that would be a better
option...

-- 

Mark Zealey (aka JALH on irc.openprojects.net: #zealos and many more)
mark@zealos.org
mark@itsolve.co.uk

UL++++>$ G!>(GCM/GCS/GS/GM) dpu? s:-@ a16! C++++>$ P++++>+++++$ L+++>+++++$
!E---? W+++>$ N- !o? !w--- O? !M? !V? !PS !PE--@ PGP+? r++ !t---?@ !X---?
!R- b+ !tv b+ DI+ D+? G+++ e>+++++ !h++* r!-- y--

(www.geekcode.com)
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux