Documentation/pci.txt

   1                          How To Write Linux PCI Drivers
   2
   3                   by Martin Mares <mj@suse.cz> on 07-Feb-2000
   4
   5 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   6 The world of PCI is vast and it's full of (mostly unpleasant) surprises.
   7 Different PCI devices have different requirements and different bugs --
   8 because of this, the PCI support layer in Linux kernel is not as trivial
   9 as one would wish. This short pamphlet tries to help all potential driver
  10 authors to find their way through the deep forests of PCI handling.
  11
  12
  13 0. Structure of PCI drivers
  14 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  15 There exist two kinds of PCI drivers: new-style ones (which leave most of
  16 probing for devices to the PCI layer and support online insertion and removal
  17 of devices [thus supporting PCI, hot-pluggable PCI and CardBus in single
  18 driver]) and old-style ones which just do all the probing themselves. Unless
  19 you have a very good reason to do so, please don't use the old way of probing
  20 in any new code. After the driver finds the devices it wishes to operate
  21 on (either the old or the new way), it needs to perform the following steps:
  22
  23         Enable the device
  24         Access device configuration space
  25         Discover resources (addresses and IRQ numbers) provided by the device
  26         Allocate these resources
  27         Communicate with the device
  28
  29 Most of these topics are covered by the following sections, for the rest
  30 look at <linux/pci.h>, it's hopefully well commented.
  31
  32 If the PCI subsystem is not configured (CONFIG_PCI is not set), most of
  33 the functions described below are defined as inline functions either completely
  34 empty or just returning an appropriate error codes to avoid lots of ifdefs
  35 in the drivers.
  36
  37
  38 1. New-style drivers
  39 ~~~~~~~~~~~~~~~~~~~~
  40 The new-style drivers just call pci_register_driver during their initialization
  41 with a pointer to a structure describing the driver (struct pci_driver) which
  42 contains:
  43
  44         name            Name of the driver
  45         id_table        Pointer to table of device ID's the driver is
  46                         interested in.  Most drivers should export this
  47                         table using MODULE_DEVICE_TABLE(pci,...).
  48                         Set to NULL to call probe() function for every
  49                         PCI device known to the system.
  50         probe           Pointer to a probing function which gets called (during
  51                         execution of pci_register_driver for already existing
  52                         devices or later if a new device gets inserted) for all
  53                         PCI devices which match the ID table and are not handled
  54                         by the other drivers yet. This function gets passed a pointer
  55                         to the pci_dev structure representing the device and also
  56                         which entry in the ID table did the device match. It returns
  57                         zero when the driver has accepted the device or an error
  58                         code (negative number) otherwise. This function always gets
  59                         called from process context, so it can sleep.
  60         remove          Pointer to a function which gets called whenever a device
  61                         being handled by this driver is removed (either during
  62                         deregistration of the driver or when it's manually pulled
  63                         out of a hot-pluggable slot). This function can be called
  64                         from interrupt context.
  65         suspend,        Power management hooks -- called when the device goes to
  66         resume          sleep or is resumed.
  67
  68 The ID table is an array of struct pci_device_id ending with a all-zero entry.
  69 Each entry consists of:
  70
  71         vendor, device  Vendor and device ID to match (or PCI_ANY_ID)
  72         subvendor,      Subsystem vendor and device ID to match (or PCI_ANY_ID)
  73         subdevice
  74         class,          Device class to match. The class_mask tells which bits
  75         class_mask      of the class are honored during the comparison.
  76         driver_data     Data private to the driver.
  77
  78 When the driver exits, it just calls pci_deregister_driver() and the PCI layer
  79 automatically calls the remove hook for all devices handled by the driver.
  80
  81 Please mark the initialization and cleanup functions where appropriate
  82 (the corresponding macros are defined in <linux/init.h>):
  83
  84         __init          Initialization code. Thrown away after the driver
  85                         initializes.
  86         __exit          Exit code. Ignored for non-modular drivers.
  87         __devinit       Device initialization code. Identical to __init if
  88                         the kernel is not compiled with CONFIG_HOTPLUG, normal
  89                         function otherwise.
  90         __devexit       The same for __exit.
  91
  92 Tips:
  93         The module_init()/module_exit() functions (and all initialization
  94         functions called only from these) should be marked __init/exit.
  95         The struct pci_driver shouldn't be marked with any of these tags.
  96         The ID table array should be marked __devinitdata.
  97         The probe() and remove() functions (and all initialization
  98         functions called only from these) should be marked __devinit/exit.
  99         If you are sure the driver is not a hotplug driver then use only
 100         __init/exit __initdata/exitdata.
 101
 102
 103 2. How to find PCI devices manually (the old style)
 104 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 105 PCI drivers not using the pci_register_driver() interface search
 106 for PCI devices manually using the following constructs:
 107
 108 Searching by vendor and device ID:
 109
 110         struct pci_dev *dev = NULL;
 111         while (dev = pci_find_device(VENDOR_ID, DEVICE_ID, dev))
 112                 configure_device(dev);
 113
 114 Searching by class ID (iterate in a similar way):
 115
 116         pci_find_class(CLASS_ID, dev)
 117
 118 Searching by both vendor/device and subsystem vendor/device ID:
 119
 120         pci_find_subsys(VENDOR_ID, DEVICE_ID, SUBSYS_VENDOR_ID, SUBSYS_DEVICE_ID, dev).
 121
 122    You can use the constant PCI_ANY_ID as a wildcard replacement for
 123 VENDOR_ID or DEVICE_ID.  This allows searching for any device from a
 124 specific vendor, for example.
 125
 126    In case you need to decide according to some more complex criteria,
 127 you can walk the list of all known PCI devices yourself:
 128
 129         struct pci_dev *dev;
 130         pci_for_each_dev(dev) {
 131                 ... do anything you want with dev ...
 132         }
 133
 134 For compatibility with device ordering in older kernels, you can also
 135 use pci_for_each_dev_reverse(dev) for walking the list in the opposite
 136 direction.
 137
 138
 139 3. Enabling devices
 140 ~~~~~~~~~~~~~~~~~~~
 141    Before you do anything with the device you've found, you need to enable
 142 it by calling pci_enable_device() which enables I/O and memory regions of
 143 the device, assigns missing resources if needed and wakes up the device
 144 if it was in suspended state. Please note that this function can fail.
 145
 146    If you want to use the device in bus mastering mode, call pci_set_master()
 147 which enables the bus master bit in PCI_COMMAND register and also fixes
 148 the latency timer value if it's set to something bogus by the BIOS.
 149
 150
 151 4. How to access PCI config space
 152 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 153    You can use pci_(read|write)_config_(byte|word|dword) to access the config
 154 space of a device represented by struct pci_dev *. All these functions return 0
 155 when successful or an error code (PCIBIOS_...) which can be translated to a text
 156 string by pcibios_strerror. Most drivers expect that accesses to valid PCI
 157 devices don't fail.
 158
 159    If you access fields in the standard portion of the config header, please
 160 use symbolic names of locations and bits declared in <linux/pci.h>.
 161
 162    If you need to access Extended PCI Capability registers, just call
 163 pci_find_capability() for the particular capability and it will find the
 164 corresponding register block for you.
 165
 166
 167 5. Addresses and interrupts
 168 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 169    Memory and port addresses and interrupt numbers should NOT be read from the
 170 config space. You should use the values in the pci_dev structure as they might
 171 have been remapped by the kernel.
 172
 173    See Documentation/IO-mapping.txt for how to access device memory.
 174
 175    You still need to call request_region() for I/O regions and request_mem_region()
 176 for memory regions to make sure nobody else is using the same device.
 177
 178    All interrupt handlers should be registered with SA_SHIRQ and use the devid
 179 to map IRQs to devices (remember that all PCI interrupts are shared).
 180
 181
 182 6. Other interesting functions
 183 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 184 pci_find_slot()                 Find pci_dev corresponding to given bus and
 185                                 slot numbers.
 186 pci_set_power_state()           Set PCI Power Management state (0=D0 ... 3=D3)
 187 pci_find_capability()           Find specified capability in device's capability
 188                                 list.
 189 pci_module_init()               Inline helper function for ensuring correct
 190                                 pci_driver initialization and error handling.
 191 pci_resource_start()            Returns bus start address for a given PCI region
 192 pci_resource_end()              Returns bus end address for a given PCI region
 193 pci_resource_len()              Returns the byte length of a PCI region
 194 pci_set_drvdata()               Set private driver data pointer for a pci_dev
 195 pci_get_drvdata()               Return private driver data pointer for a pci_dev
 196
 197
 198 7. Miscellaneous hints
 199 ~~~~~~~~~~~~~~~~~~~~~~
 200 When displaying PCI slot names to the user (for example when a driver wants
 201 to tell the user what card has it found), please use pci_dev->slot_name
 202 for this purpose.
 203
 204 Always refer to the PCI devices by a pointer to the pci_dev structure.
 205 All PCI layer functions use this identification and it's the only
 206 reasonable one. Don't use bus/slot/function numbers except for very
 207 special purposes -- on systems with multiple primary buses their semantics
 208 can be pretty complex.
 209
 210 If you're going to use PCI bus mastering DMA, take a look at
 211 Documentation/DMA-mapping.txt.
 212
 213
 214 8. Obsolete functions
 215 ~~~~~~~~~~~~~~~~~~~~~
 216 There are several functions kept only for compatibility with old drivers
 217 not updated to the new PCI interface. Please don't use them in new code.
 218
 219 pcibios_present()               Since ages, you don't need to test presence
 220                                 of PCI subsystem when trying to talk with it.
 221                                 If it's not there, the list of PCI devices
 222                                 is empty and all functions for searching for
 223                                 devices just return NULL.
 224 pcibios_(read|write)_*          Superseded by their pci_(read|write)_*
 225                                 counterparts.
 226 pcibios_find_*                  Superseded by their pci_find_* counterparts.