1PCI with Driver Model
2=====================
3
4How busses are scanned
5----------------------
6
7Any config read will end up at pci_read_config(). This uses
8uclass_get_device_by_seq() to get the PCI bus for a particular bus number.
9Bus number 0 will need to be requested first, and the alias in the device
10tree 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
23If there is no alias the devices will be numbered sequentially in the device
24tree.
25
26The call to uclass_get_device() will cause the PCI bus to be probed.
27This does a scan of the bus to locate available devices. These devices are
28bound to their appropriate driver if available. If there is no driver, then
29they are bound to a generic PCI driver which does nothing.
30
31After probing a bus, the available devices will appear in the device tree
32under that bus.
33
34Note that this is all done on a lazy basis, as needed, so until something is
35touched on PCI (eg: a call to pci_find_devices()) it will not be probed.
36
37PCI devices can appear in the flattened device tree. If they do, their node
38often contains extra information which cannot be derived from the PCI IDs or
39PCI class of the device. Each PCI device node must have a <reg> property, as
40defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible
41string list is optional and generally not needed, since PCI is discoverable
42bus, albeit there are justified exceptions. If the compatible string is
43present, matching on it takes precedence over PCI IDs and PCI classes.
44
45Note we must describe PCI devices with the same bus hierarchy as the
46hardware, otherwise driver model cannot detect the correct parent/children
47relationship during PCI bus enumeration thus PCI devices won't be bound to
48their drivers accordingly. A working example like below:
49
50	pci {
51		#address-cells = <3>;
52		#size-cells = <2>;
53		compatible = "pci-x86";
54		u-boot,dm-pre-reloc;
55		ranges = <0x02000000 0x0 0x40000000 0x40000000 0 0x80000000
56			  0x42000000 0x0 0xc0000000 0xc0000000 0 0x20000000
57			  0x01000000 0x0 0x2000 0x2000 0 0xe000>;
58
59		pcie@17,0 {
60			#address-cells = <3>;
61			#size-cells = <2>;
62			compatible = "pci-bridge";
63			u-boot,dm-pre-reloc;
64			reg = <0x0000b800 0x0 0x0 0x0 0x0>;
65
66			topcliff@0,0 {
67				#address-cells = <3>;
68				#size-cells = <2>;
69				compatible = "pci-bridge";
70				u-boot,dm-pre-reloc;
71				reg = <0x00010000 0x0 0x0 0x0 0x0>;
72
73				pciuart0: uart@a,1 {
74					compatible = "pci8086,8811.00",
75							"pci8086,8811",
76							"pciclass,070002",
77							"pciclass,0700",
78							"x86-uart";
79					u-boot,dm-pre-reloc;
80					reg = <0x00025100 0x0 0x0 0x0 0x0
81					       0x01025110 0x0 0x0 0x0 0x0>;
82					......
83				};
84
85				......
86			};
87		};
88
89		......
90	};
91
92In this example, the root PCI bus node is the "/pci" which matches "pci-x86"
93driver. It has a subnode "pcie@17,0" with driver "pci-bridge". "pcie@17,0"
94also has subnode "topcliff@0,0" which is a "pci-bridge" too. Under that bridge,
95a PCI UART device "uart@a,1" is described. This exactly reflects the hardware
96bus hierarchy: on the root PCI bus, there is a PCIe root port which connects
97to a downstream device Topcliff chipset. Inside Topcliff chipset, it has a
98PCIe-to-PCI bridge and all the chipset integrated devices like the PCI UART
99device are on the PCI bus. Like other devices in the device tree, if we want
100to bind PCI devices before relocation, "u-boot,dm-pre-reloc" must be declared
101in each of these nodes.
102
103If PCI devices are not listed in the device tree, U_BOOT_PCI_DEVICE can be used
104to specify the driver to use for the device. The device tree takes precedence
105over U_BOOT_PCI_DEVICE. Plese note with U_BOOT_PCI_DEVICE, only drivers with
106DM_FLAG_PRE_RELOC will be bound before relocation. If neither device tree nor
107U_BOOT_PCI_DEVICE is provided, the built-in driver (either pci_bridge_drv or
108pci_generic_drv) will be used.
109
110
111Sandbox
112-------
113
114With sandbox we need a device emulator for each device on the bus since there
115is no real PCI bus. This works by looking in the device tree node for a
116driver. For example:
117
118
119	pci@1f,0 {
120		compatible = "pci-generic";
121		reg = <0xf800 0 0 0 0>;
122		emul@1f,0 {
123			compatible = "sandbox,swap-case";
124		};
125	};
126
127This means that there is a 'sandbox,swap-case' driver at that bus position.
128Note that the first cell in the 'reg' value is the bus/device/function. See
129PCI_BDF() for the encoding (it is also specified in the IEEE Std 1275-1994
130PCI bus binding document, v2.1)
131
132When this bus is scanned we will end up with something like this:
133
134`- * pci-controller @ 05c660c8, 0
135 `-   pci@1f,0 @ 05c661c8, 63488
136  `-   emul@1f,0 @ 05c662c8
137
138When accesses go to the pci@1f,0 device they are forwarded to its child, the
139emulator.
140
141The sandbox PCI drivers also support dynamic driver binding, allowing device
142driver to declare the driver binding information via U_BOOT_PCI_DEVICE(),
143eliminating the need to provide any device tree node under the host controller
144node. It is required a "sandbox,dev-info" property must be provided in the
145host controller node for this functionality to work.
146
147	pci1: pci-controller1 {
148		compatible = "sandbox,pci";
149		...
150		sandbox,dev-info = <0x08 0x00 0x1234 0x5678
151				    0x0c 0x00 0x1234 0x5678>;
152	};
153
154The "sandbox,dev-info" property specifies all dynamic PCI devices on this bus.
155Each dynamic PCI device is encoded as 4 cells a group. The first and second
156cells are PCI device number and function number respectively. The third and
157fourth cells are PCI vendor ID and device ID respectively.
158
159When this bus is scanned we will end up with something like this:
160
161 pci        [ + ]   pci_sandbo  |-- pci-controller1
162 pci_emul   [   ]   sandbox_sw  |   |-- sandbox_swap_case_emul
163 pci_emul   [   ]   sandbox_sw  |   `-- sandbox_swap_case_emul
164
165Note the difference from the statically declared device nodes is that the
166device is directly attached to the host controller, instead of via a container
167device like pci@1f,0.
168