home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / sys5 / r4 / 1226 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.8 KB
  1. Xref: sparky comp.unix.sys5.r4:1226 comp.unix.pc-clone.32bit:1022 comp.sys.ibm.pc.misc:16543
  2. Newsgroups: comp.unix.sys5.r4,comp.unix.pc-clone.32bit,comp.sys.ibm.pc.misc
  3. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  4. From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
  5. Subject: Re: 386 device drivers: machine-independent I/O timing?
  6. Message-ID: <1993Jan11.190124.16891@klaava.Helsinki.FI>
  7. Organization: University of Helsinki
  8. References: <1993Jan11.120230.1322@smoke.marlboro.vt.us> <LILJEBER.93Jan11190510@hydra.Helsinki.FI>
  9. Date: Mon, 11 Jan 1993 19:01:24 GMT
  10. Lines: 49
  11.  
  12. In article <LILJEBER.93Jan11190510@hydra.Helsinki.FI> liljeber@hydra.Helsinki.FI (Mika Liljeberg) writes:
  13. >In article <1993Jan11.120230.1322@smoke.marlboro.vt.us> jhood@smoke.marlboro.vt.us (Lord Yertle) wrote:
  14. >> 
  15. >> Sometime in the deep murky mists of time (within the last two years,
  16. >> anyway) somebody from Compaq or Dell posted an article about I/O
  17. >> delays in (I think) Unix device drivers.  He suggested reading or
  18. >> writing some I/O port on the motherboard I/O bus to get ~ 1 us delays
  19. >> for I/O access timing, but I can't find the article (which I thought I
  20. >> saved) or remember what exactly he was suggesting.
  21. >
  22. >I didn't see the article, but Linux uses outb on port 0x80 for I/O
  23. >delays. It seems to work very well.
  24.  
  25. The outb to port 0x80 seems to be one of the better solutions (and
  26. thanks to James van Artsdalen for the tip..), although I have one report
  27. that says it leads to problems (but that's still a lot less than all the
  28. other solutions I've tried). 
  29.  
  30. Other possibilities:
  31.  
  32.  + inb from port 0x61 is reported to work well
  33.    - I tried it with one release of linux, but there were problems on
  34.      some hardware.  Also, this naturally messes up %al, which makes the
  35.      code look uglier (I usually want to take a look at the generated
  36.      assembler...)
  37.  
  38.  + no delay at all
  39.    - works on a lot of harware, and is likely to be the fastest solution
  40.      as long as it doesn't lead to other problems.  If it's something
  41.      meant to work only on your hardware, try it out.  I've found that
  42.      my machine is happy with just about anything I feed it, but not
  43.      everybody is as lucky.. 
  44.  
  45.  + short jumps
  46.    - doesn't work too well on 486's, and you might as well use no delay
  47.      at all.  Besides, it's hardware-dependent, and becomes less useful
  48.      just when the timings are getting more critical.
  49.  
  50.  + timing loops.  You might try to time your hardware, and use a
  51.    variable number loop. 
  52.    - probably isn't worth it for small delays, and gets confused if you
  53.      play around with a turbo button..
  54.  
  55. I've been happy with the "outb 0x80" trick: it works fine, and using
  56. four of them as a delay between IO instructions for critical things
  57. seems to be enough for almost everything (anything less has resulted in
  58. problems with the harddisk driver under linux). 
  59.  
  60.         Linus
  61.