mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: Mark Hahn <hahn@coffee.psychology.mcmaster.ca>,
	linux-kernel@vger.kernel.org
Subject: Re: Linux Post codes during runtime, possibly OT
Date: Fri, 26 Jan 2001 17:22:56 +0100	[thread overview]
Message-ID: <20010126172256.A7500@pcep-jamie.cern.ch> (raw)
In-Reply-To: <20010126163103.F7096@pcep-jamie.cern.ch> <Pine.LNX.3.95.1010126104710.1321A-100000@chaos.analogic.com>
In-Reply-To: <Pine.LNX.3.95.1010126104710.1321A-100000@chaos.analogic.com>; from root@chaos.analogic.com on Fri, Jan 26, 2001 at 11:03:22AM -0500

Richard B. Johnson wrote:
> Slowing down I/O is absolutely necessary any time you set an index
> register or a page register. For instance, to access the CMOS chip,
> you write an index value out port 0x70, then you read or write from
> port 0x71. Modern CPUs can execute instructions MUCH faster than
> the port index can be switched. If you don't force the CPU to wait
> until the hardware has actually switched the port offset, then
> you read/write to/from the wrong location.
> 
> The same thing occurs with DMA page registers, i.e., 64 k chunks
> of addresses. If takes time for hardware to switch in a new page --
> a LOT more time than it takes to read/write RAM. If you don't wait,
> you read/write to the wrong place.

Ah, I've always wondered when it's appropriate to use outb_p and when to
use outb.  The lack of comments in <asm-i386/io.h> kept this a mystery.
Modern bus hardware doesn't need this sort of thing -- it enforces the
required delays itself.

Is the list of ports for which outb_p is appropriate a small and well
defined one?

> The delay must be sufficient for the hardware to have accomplished
> the switch. That's why writing to a hardware port is ideal. If you
> have fast hardware, the delay is low. If you have slow hardware, the
> delay is longer.
> 
> I'm not going to debate this. If you understand hardware there
> is nothing to debate.

Agreed, however it's not that obvious.  Not all delays are to
synchronise at bus rates.  Sometimes the delay is because some _other_
component on a board, not directly connected to the bus, needs a short
delay.  E.g. a chip that can only be clocked at max. 1MHz.  The driver
author uses outb_p because he thinks that limits the rate to 0.5MHz, and
there is no other way to get that sort of data rate, but no it limits
the rate to 3MHz on your board.  Ah well.

If it was really as simple as matching the bus rate, there would be no
need for REALLY_SLOW_IO on some machines would there?  (Are
REALLY_SLOW_IO and SLOW_IO_BY_JUMPING ever used?)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2001-01-26 16:24 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-26 15:41 Petr Vandrovec
2001-01-26 15:07 ` Richard B. Johnson
2001-01-26 15:15   ` Mark Hahn
2001-01-26 15:31     ` Jamie Lokier
2001-01-26 16:03       ` Richard B. Johnson
2001-01-26 16:22         ` Jamie Lokier [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-26 15:42 Manfred Spraul
2001-01-26 16:07 ` Richard B. Johnson
2001-01-26 16:33   ` Brian Gerst
2001-01-27 12:28     ` Pavel Machek
2001-01-25 21:46 Ian S. Nelson
2001-01-25 22:26 ` H. Peter Anvin
2001-01-25 22:31   ` Matthew Dharm
2001-01-25 22:32     ` H. Peter Anvin
2001-01-25 22:41       ` Matthew Dharm
2001-01-25 22:45         ` H. Peter Anvin
2001-01-25 23:08       ` Richard B. Johnson
2001-01-25 23:10         ` H. Peter Anvin
2001-01-26 13:58           ` Richard B. Johnson
2001-01-26 16:19             ` H. Peter Anvin
2001-01-26 17:54               ` David Welch
2001-01-29  2:35               ` Paul Gortmaker
2001-01-27 10:20   ` Rogier Wolff
2001-01-27 20:47     ` H. Peter Anvin
2001-01-27 21:01       ` Rogier Wolff
2001-01-27 21:24         ` H. Peter Anvin
2001-01-28 10:12           ` Rogier Wolff
2001-01-28 10:18             ` H. Peter Anvin
2001-01-28 11:03               ` Rogier Wolff
2001-01-28 17:22               ` Jamie Lokier
2001-01-28 22:34               ` Pavel Machek
2001-01-29 15:09                 ` Richard B. Johnson
2001-01-29 19:21                 ` H. Peter Anvin
2001-01-28 22:29         ` Pavel Machek
2001-01-30 17:44         ` Mark H. Wood
2001-01-30 18:10           ` Richard B. Johnson
2001-01-30 18:16           ` mirabilos
2001-01-30 18:36             ` Richard B. Johnson
2001-01-30 18:41               ` mirabilos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010126172256.A7500@pcep-jamie.cern.ch \
    --to=lk@tantalophile.demon.co.uk \
    --cc=hahn@coffee.psychology.mcmaster.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®