Simon Glass | b94dc89 | 2015-03-05 12:25:25 -0700 | [diff] [blame] | 1 | PCI with Driver Model |
| 2 | ===================== |
| 3 | |
| 4 | How busses are scanned |
| 5 | ---------------------- |
| 6 | |
| 7 | Any config read will end up at pci_read_config(). This uses |
| 8 | uclass_get_device_by_seq() to get the PCI bus for a particular bus number. |
Bin Meng | 8571ea5 | 2015-07-27 00:33:43 -0700 | [diff] [blame] | 9 | Bus number 0 will need to be requested first, and the alias in the device |
Simon Glass | b94dc89 | 2015-03-05 12:25:25 -0700 | [diff] [blame] | 10 | tree file will point to the correct device: |
| 11 | |
| 12 | |
| 13 | aliases { |
| 14 | pci0 = &pci; |
| 15 | }; |
| 16 | |
| 17 | pci: pci-controller { |
| 18 | compatible = "sandbox,pci"; |
| 19 | ... |
| 20 | }; |
| 21 | |
| 22 | |
| 23 | If there is no alias the devices will be numbered sequentially in the device |
| 24 | tree. |
| 25 | |
Bin Meng | 8571ea5 | 2015-07-27 00:33:43 -0700 | [diff] [blame] | 26 | The call to uclass_get_device() will cause the PCI bus to be probed. |
Simon Glass | b94dc89 | 2015-03-05 12:25:25 -0700 | [diff] [blame] | 27 | This does a scan of the bus to locate available devices. These devices are |
| 28 | bound to their appropriate driver if available. If there is no driver, then |
| 29 | they are bound to a generic PCI driver which does nothing. |
| 30 | |
| 31 | After probing a bus, the available devices will appear in the device tree |
| 32 | under that bus. |
| 33 | |
| 34 | Note that this is all done on a lazy basis, as needed, so until something is |
Bin Meng | 8571ea5 | 2015-07-27 00:33:43 -0700 | [diff] [blame] | 35 | touched on PCI (eg: a call to pci_find_devices()) it will not be probed. |
Simon Glass | b94dc89 | 2015-03-05 12:25:25 -0700 | [diff] [blame] | 36 | |
| 37 | PCI devices can appear in the device tree. If they do this serves to specify |
| 38 | the driver to use for the device. In this case they will be bound at |
| 39 | start-up. |
| 40 | |
| 41 | |
| 42 | Sandbox |
| 43 | ------- |
| 44 | |
| 45 | With sandbox we need a device emulator for each device on the bus since there |
| 46 | is no real PCI bus. This works by looking in the device tree node for a |
| 47 | driver. For example: |
| 48 | |
| 49 | |
| 50 | pci@1f,0 { |
| 51 | compatible = "pci-generic"; |
| 52 | reg = <0xf800 0 0 0 0>; |
| 53 | emul@1f,0 { |
| 54 | compatible = "sandbox,swap-case"; |
| 55 | }; |
| 56 | }; |
| 57 | |
| 58 | This means that there is a 'sandbox,swap-case' driver at that bus position. |
| 59 | Note that the first cell in the 'reg' value is the bus/device/function. See |
| 60 | PCI_BDF() for the encoding (it is also specified in the IEEE Std 1275-1994 |
| 61 | PCI bus binding document, v2.1) |
| 62 | |
| 63 | When this bus is scanned we will end up with something like this: |
| 64 | |
| 65 | `- * pci-controller @ 05c660c8, 0 |
| 66 | `- pci@1f,0 @ 05c661c8, 63488 |
| 67 | `- emul@1f,0 @ 05c662c8 |
| 68 | |
| 69 | When accesses go to the pci@1f,0 device they are forwarded to its child, the |
| 70 | emulator. |