PCIEBUS-HOWTO.txt 8.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217
  1. The PCI Express Port Bus Driver Guide HOWTO
  2. Tom L Nguyen tom.l.nguyen@intel.com
  3. 11/03/2004
  4. 1. About this guide
  5. This guide describes the basics of the PCI Express Port Bus driver
  6. and provides information on how to enable the service drivers to
  7. register/unregister with the PCI Express Port Bus Driver.
  8. 2. Copyright 2004 Intel Corporation
  9. 3. What is the PCI Express Port Bus Driver
  10. A PCI Express Port is a logical PCI-PCI Bridge structure. There
  11. are two types of PCI Express Port: the Root Port and the Switch
  12. Port. The Root Port originates a PCI Express link from a PCI Express
  13. Root Complex and the Switch Port connects PCI Express links to
  14. internal logical PCI buses. The Switch Port, which has its secondary
  15. bus representing the switch's internal routing logic, is called the
  16. switch's Upstream Port. The switch's Downstream Port is bridging from
  17. switch's internal routing bus to a bus representing the downstream
  18. PCI Express link from the PCI Express Switch.
  19. A PCI Express Port can provide up to four distinct functions,
  20. referred to in this document as services, depending on its port type.
  21. PCI Express Port's services include native hotplug support (HP),
  22. power management event support (PME), advanced error reporting
  23. support (AER), and virtual channel support (VC). These services may
  24. be handled by a single complex driver or be individually distributed
  25. and handled by corresponding service drivers.
  26. 4. Why use the PCI Express Port Bus Driver?
  27. In existing Linux kernels, the Linux Device Driver Model allows a
  28. physical device to be handled by only a single driver. The PCI
  29. Express Port is a PCI-PCI Bridge device with multiple distinct
  30. services. To maintain a clean and simple solution each service
  31. may have its own software service driver. In this case several
  32. service drivers will compete for a single PCI-PCI Bridge device.
  33. For example, if the PCI Express Root Port native hotplug service
  34. driver is loaded first, it claims a PCI-PCI Bridge Root Port. The
  35. kernel therefore does not load other service drivers for that Root
  36. Port. In other words, it is impossible to have multiple service
  37. drivers load and run on a PCI-PCI Bridge device simultaneously
  38. using the current driver model.
  39. To enable multiple service drivers running simultaneously requires
  40. having a PCI Express Port Bus driver, which manages all populated
  41. PCI Express Ports and distributes all provided service requests
  42. to the corresponding service drivers as required. Some key
  43. advantages of using the PCI Express Port Bus driver are listed below:
  44. - Allow multiple service drivers to run simultaneously on
  45. a PCI-PCI Bridge Port device.
  46. - Allow service drivers implemented in an independent
  47. staged approach.
  48. - Allow one service driver to run on multiple PCI-PCI Bridge
  49. Port devices.
  50. - Manage and distribute resources of a PCI-PCI Bridge Port
  51. device to requested service drivers.
  52. 5. Configuring the PCI Express Port Bus Driver vs. Service Drivers
  53. 5.1 Including the PCI Express Port Bus Driver Support into the Kernel
  54. Including the PCI Express Port Bus driver depends on whether the PCI
  55. Express support is included in the kernel config. The kernel will
  56. automatically include the PCI Express Port Bus driver as a kernel
  57. driver when the PCI Express support is enabled in the kernel.
  58. 5.2 Enabling Service Driver Support
  59. PCI device drivers are implemented based on Linux Device Driver Model.
  60. All service drivers are PCI device drivers. As discussed above, it is
  61. impossible to load any service driver once the kernel has loaded the
  62. PCI Express Port Bus Driver. To meet the PCI Express Port Bus Driver
  63. Model requires some minimal changes on existing service drivers that
  64. imposes no impact on the functionality of existing service drivers.
  65. A service driver is required to use the two APIs shown below to
  66. register its service with the PCI Express Port Bus driver (see
  67. section 5.2.1 & 5.2.2). It is important that a service driver
  68. initializes the pcie_port_service_driver data structure, included in
  69. header file /include/linux/pcieport_if.h, before calling these APIs.
  70. Failure to do so will result an identity mismatch, which prevents
  71. the PCI Express Port Bus driver from loading a service driver.
  72. 5.2.1 pcie_port_service_register
  73. int pcie_port_service_register(struct pcie_port_service_driver *new)
  74. This API replaces the Linux Driver Model's pci_module_init API. A
  75. service driver should always calls pcie_port_service_register at
  76. module init. Note that after service driver being loaded, calls
  77. such as pci_enable_device(dev) and pci_set_master(dev) are no longer
  78. necessary since these calls are executed by the PCI Port Bus driver.
  79. 5.2.2 pcie_port_service_unregister
  80. void pcie_port_service_unregister(struct pcie_port_service_driver *new)
  81. pcie_port_service_unregister replaces the Linux Driver Model's
  82. pci_unregister_driver. It's always called by service driver when a
  83. module exits.
  84. 5.2.3 Sample Code
  85. Below is sample service driver code to initialize the port service
  86. driver data structure.
  87. static struct pcie_port_service_id service_id[] = { {
  88. .vendor = PCI_ANY_ID,
  89. .device = PCI_ANY_ID,
  90. .port_type = PCIE_RC_PORT,
  91. .service_type = PCIE_PORT_SERVICE_AER,
  92. }, { /* end: all zeroes */ }
  93. };
  94. static struct pcie_port_service_driver root_aerdrv = {
  95. .name = (char *)device_name,
  96. .id_table = &service_id[0],
  97. .probe = aerdrv_load,
  98. .remove = aerdrv_unload,
  99. .suspend = aerdrv_suspend,
  100. .resume = aerdrv_resume,
  101. };
  102. Below is a sample code for registering/unregistering a service
  103. driver.
  104. static int __init aerdrv_service_init(void)
  105. {
  106. int retval = 0;
  107. retval = pcie_port_service_register(&root_aerdrv);
  108. if (!retval) {
  109. /*
  110. * FIX ME
  111. */
  112. }
  113. return retval;
  114. }
  115. static void __exit aerdrv_service_exit(void)
  116. {
  117. pcie_port_service_unregister(&root_aerdrv);
  118. }
  119. module_init(aerdrv_service_init);
  120. module_exit(aerdrv_service_exit);
  121. 6. Possible Resource Conflicts
  122. Since all service drivers of a PCI-PCI Bridge Port device are
  123. allowed to run simultaneously, below lists a few of possible resource
  124. conflicts with proposed solutions.
  125. 6.1 MSI Vector Resource
  126. The MSI capability structure enables a device software driver to call
  127. pci_enable_msi to request MSI based interrupts. Once MSI interrupts
  128. are enabled on a device, it stays in this mode until a device driver
  129. calls pci_disable_msi to disable MSI interrupts and revert back to
  130. INTx emulation mode. Since service drivers of the same PCI-PCI Bridge
  131. port share the same physical device, if an individual service driver
  132. calls pci_enable_msi/pci_disable_msi it may result unpredictable
  133. behavior. For example, two service drivers run simultaneously on the
  134. same physical Root Port. Both service drivers call pci_enable_msi to
  135. request MSI based interrupts. A service driver may not know whether
  136. any other service drivers have run on this Root Port. If either one
  137. of them calls pci_disable_msi, it puts the other service driver
  138. in a wrong interrupt mode.
  139. To avoid this situation all service drivers are not permitted to
  140. switch interrupt mode on its device. The PCI Express Port Bus driver
  141. is responsible for determining the interrupt mode and this should be
  142. transparent to service drivers. Service drivers need to know only
  143. the vector IRQ assigned to the field irq of struct pcie_device, which
  144. is passed in when the PCI Express Port Bus driver probes each service
  145. driver. Service drivers should use (struct pcie_device*)dev->irq to
  146. call request_irq/free_irq. In addition, the interrupt mode is stored
  147. in the field interrupt_mode of struct pcie_device.
  148. 6.2 MSI-X Vector Resources
  149. Similar to the MSI a device driver for an MSI-X capable device can
  150. call pci_enable_msix to request MSI-X interrupts. All service drivers
  151. are not permitted to switch interrupt mode on its device. The PCI
  152. Express Port Bus driver is responsible for determining the interrupt
  153. mode and this should be transparent to service drivers. Any attempt
  154. by service driver to call pci_enable_msix/pci_disable_msix may
  155. result unpredictable behavior. Service drivers should use
  156. (struct pcie_device*)dev->irq and call request_irq/free_irq.
  157. 6.3 PCI Memory/IO Mapped Regions
  158. Service drivers for PCI Express Power Management (PME), Advanced
  159. Error Reporting (AER), Hot-Plug (HP) and Virtual Channel (VC) access
  160. PCI configuration space on the PCI Express port. In all cases the
  161. registers accessed are independent of each other. This patch assumes
  162. that all service drivers will be well behaved and not overwrite
  163. other service driver's configuration settings.
  164. 6.4 PCI Config Registers
  165. Each service driver runs its PCI config operations on its own
  166. capability structure except the PCI Express capability structure, in
  167. which Root Control register and Device Control register are shared
  168. between PME and AER. This patch assumes that all service drivers
  169. will be well behaved and not overwrite other service driver's
  170. configuration settings.