All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Greg KH <greg@kroah.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	akpm@osdl.org, Rajesh Shah <rajesh.shah@intel.com>,
	Grant Grundler <grundler@parisc-linux.org>,
	"bibo,mao" <bibo.mao@intel.com>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: [PATCH 2/4] Update Documentation/pci.txt
Date: Wed, 07 Jun 2006 12:13:50 +0900	[thread overview]
Message-ID: <4486446E.6020407@jp.fujitsu.com> (raw)
In-Reply-To: <448643B9.2080805@jp.fujitsu.com>

This patch adds the description about legacy I/O port free driver into
Documentation/pci.txt.

Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

---
 Documentation/pci.txt |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 70 insertions(+)

Index: linux-2.6.17-rc6/Documentation/pci.txt
===================================================================
--- linux-2.6.17-rc6.orig/Documentation/pci.txt	2006-06-06 21:39:11.000000000 +0900
+++ linux-2.6.17-rc6/Documentation/pci.txt	2006-06-06 21:56:32.000000000 +0900
@@ -279,3 +279,73 @@
 pci_find_device()		Superseded by pci_get_device()
 pci_find_subsys()		Superseded by pci_get_subsys()
 pci_find_slot()			Superseded by pci_get_slot()
+
+
+9. Legacy I/O port free driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Large servers may not be able to provide I/O port resources to all PCI
+devices. I/O Port space is only 64KB on Intel Architecture[1] and is
+likely also fragmented since the I/O base register of PCI-to-PCI
+bridge will usually be aligned to a 4KB boundary[2]. On such systems,
+pci_enable_device() and pci_request_regions() will fail when
+attempting to enable I/O Port regions that don't have I/O Port
+resources assigned.
+
+Fortunately, many PCI devices which request I/O Port resources also
+provide access to the same registers via MMIO BARs. These devices can
+be handled without using I/O port space and the drivers typically
+offer a CONFIG_ option to only use MMIO regions
+(e.g. CONFIG_TULIP_MMIO). PCI devices typically provide I/O port
+interface for legacy OSs and will work when I/O port resources are not
+assigned. The "PCI Local Bus Specification Revision 3.0" discusses
+this on p.44, "IMPLEMENTATION NOTE".
+
+If your PCI device driver doesn't need I/O port resources assigned to
+I/O Port BARs, you should use pci_enable_device_bars() instead of
+pci_enable_device() in order not to enable I/O port regions for the
+corresponding devices. In addition, you should use
+pci_request_selected_regions()/pci_release_selected_regions() instead
+of pci_request_regions()/pci_release_regions() in order not to
+request/release I/O port regions for the corresponding devices.
+
+[1] Some systems support 64KB I/O port space per PCI segment.
+[2] Some PCI-to-PCI bridges support optional 1KB aligned I/O base.
+
+
+10. MMIO Space and "Write Posting"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Converting a driver from using I/O Port space to using MMIO space
+often requires some additional changes. Specifically, "write posting"
+needs to be handled. Most drivers (e.g. tg3, acenic, sym53c8xx_2)
+already do. I/O Port space guarantees write transactions reach the PCI
+device before the CPU can continue. Writes to MMIO space allow to CPU
+continue before the transaction reaches the PCI device. HW weenies
+call this "Write Posting" because the write completion is "posted" to
+the CPU before the transaction has reached it's destination.
+
+Thus, timing sensitive code should add readl() where the CPU is
+expected to wait before doing other work.  The classic "bit banging"
+sequence works fine for I/O Port space:
+
+	for (i=8; --i; val >>= 1) {
+		outb(val & 1, ioport_reg);	/* write bit */
+		udelay(10);
+	}
+
+The same sequence for MMIO space should be:
+
+	for (i=8; --i; val >>= 1) {
+		writeb(val & 1, mmio_reg);	/* write bit */
+		readb(safe_mmio_reg);		/* flush posted write */
+		udelay(10);
+	}
+
+It is important that "safe_mmio_reg" not have any side effects that
+interferes with the correct operation of the device.
+
+Another case to watch out for is when resetting a PCI device. Use PCI
+Configuration space reads to flush the writel(). This will gracefully
+handle the PCI master abort on all platforms if the PCI device is
+expected to not respond to a readl().  Most x86 platforms will allow
+MMIO reads to master abort (aka "Soft Fail") and return garbage
+(e.g. ~0). But many RISC platforms will crash (aka "Hard Fail").


  parent reply	other threads:[~2006-06-07  3:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-01  7:05 [BUG](-mm)pci_disable_device function clear bars_enabled element bibo,mao
2006-06-01  9:46 ` Rajesh Shah
2006-06-01 17:15   ` Grant Grundler
2006-06-01 18:36     ` Rajesh Shah
2006-06-02  2:57       ` Kenji Kaneshige
2006-06-02  5:56         ` Grant Grundler
2006-06-02  7:31           ` Kenji Kaneshige
2006-06-03 23:21             ` Grant Grundler
2006-06-04 21:01               ` Greg KH
2006-06-05 12:40         ` [BUG][PATCH 2.6.17-rc5-mm3] bugfix: PCI legacy I/O port free driver Kenji Kaneshige
2006-06-06  7:58           ` Greg KH
2006-06-06  8:17             ` Kenji Kaneshige
2006-06-07  3:10             ` Kenji Kaneshige
2006-06-07  3:12               ` [PATCH 1/4] Changes to generic pci code Kenji Kaneshige
2006-06-07  3:13               ` Kenji Kaneshige [this message]
2006-06-07  3:14               ` [PATCH 3/4] Make Intel e1000 driver legacy I/O port free Kenji Kaneshige
2006-06-07  5:10                 ` Auke Kok
2006-06-07  7:39                   ` Kenji Kaneshige
2006-06-07 14:40                     ` Auke Kok
2006-06-08 12:31                 ` Jeff Garzik
2006-06-08 13:35                   ` Kenji Kaneshige
2006-06-08 14:46                     ` Jeff Garzik
2006-06-08 17:00                       ` Kenji Kaneshige
2006-06-07  3:15               ` [PATCH 4/4] Make Emulex lpfc " Kenji Kaneshige
2006-06-07  8:24                 ` Christoph Hellwig
2006-06-07 12:23                   ` Kenji Kaneshige
2006-06-07 12:43                     ` Christoph Hellwig
2006-06-07 13:11                       ` Kenji Kaneshige
2006-06-07 13:40                         ` Christoph Hellwig
2006-06-07 13:56                           ` Kenji Kaneshige
2006-06-07 14:52                             ` Christoph Hellwig
2006-06-07 17:26                               ` Rajesh Shah
2006-06-02  4:42       ` [BUG](-mm)pci_disable_device function clear bars_enabled element Grant Grundler
2006-06-02 16:50         ` Rajesh Shah

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=4486446E.6020407@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=akpm@osdl.org \
    --cc=bibo.mao@intel.com \
    --cc=greg@kroah.com \
    --cc=grundler@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=rajesh.shah@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.