Messages in this thread Patch in this message | | | Date | Tue, 21 Feb 2006 15:31:14 +0900 | From | Kenji Kaneshige <> | Subject | [PATCH 4/6] PCI legacy I/O port free driver (take2) - Update Documentation/pci.txt |
| |
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>
Documentation/pci.txt | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 50 insertions(+)
Index: linux-2.6.16-rc4/Documentation/pci.txt =================================================================== --- linux-2.6.16-rc4.orig/Documentation/pci.txt 2006-02-21 14:40:46.000000000 +0900 +++ linux-2.6.16-rc4/Documentation/pci.txt 2006-02-21 14:40:56.000000000 +0900 @@ -81,6 +81,8 @@ class, Device class to match. The class_mask tells which bits class_mask of the class are honored during the comparison. driver_data Data private to the driver. + device_flags Per device id flags. See mod_devicetable.h for + specific. Most drivers don't need to use the driver_data field. Best practice for use of driver_data is to use it as an index into a static list of @@ -269,3 +271,51 @@ 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 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +On the large servers, I/O port resources could not be assigned to all +PCI devices because it is limited (64KB on Intel Architecture[1]) and +it would be fragmented (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() for those devices will +fail because those functions try to enable all the regions. However, +it is a problem for some PCI devices which provide both I/O port and +MMIO interface because some of them can be handled without using I/O +port interface. The reason why such devices provide I/O port interface +is for compatibility to legacy OSs. So this kind of devices should +work even if enough I/O port resources are not assigned. The "PCI +Local Bus Specification Revision 3.0" also mentions about this topic +(Please see p.44, "IMPLEMENTATION NOTE"). + +This problem is solved by telling the kernel if your driver needs to +use I/O port to handle the device. If your driver doesn't need any I/O +port regions to handle the device, you can tell it to the kernel by +setting PCI_DEVICE_ID_FLAG_NOIOPORT flag in the ID table like below: + + struct pci_device_id your_id_table { + ..., + { + ..., + .device_flags = PCI_DEVICE_ID_FLAG_NOIOPORT, + ..., + }, + ..., + } + +If the PCI_DEVICE_ID_FLAG_NOIOPORT flag is set, kernel will never +touch the I/O port regions for the corresponding devices. + +By using ID table, you can tell the kernel whether to use I/O port by +per device ID basis. However, some drivers might need to check other +information than in table ID (e.g. revision ID) to see if they need to +use I/O port. In this case, you can use the no_ioport flag in struct +pci_dev. If the no_ioport flag is set, kernel will never touch I/O +port regions for the device. You would check some information to see +if your device needs I/O port, and you would set the no_ioport flag as +necessary. Please note that you need to set the no_ioport flag before +calling pci_enable_device() and pci_request_regions(). + +[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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |