diff options
| author | Bin Meng <bmeng.cn@gmail.com> | 2019-07-18 10:33:56 +0300 |
|---|---|---|
| committer | Tom Rini <trini@konsulko.com> | 2019-07-24 17:07:24 +0300 |
| commit | b598648947062a0707a53ab3aa72744e20e6732f (patch) | |
| tree | e89357361d1210cc84b006df0f235526abcc70cc | |
| parent | 45dbb4dd23a0bcbeee66540e5baa85d549ac95fb (diff) | |
| download | u-boot-b598648947062a0707a53ab3aa72744e20e6732f.tar.xz | |
doc: driver-model: Convert pci-info.txt to reST
Convert plain text documentation to reStructuredText format and add
it to Sphinx TOC tree. No essential content change.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
| -rw-r--r-- | doc/driver-model/index.rst | 1 | ||||
| -rw-r--r-- | doc/driver-model/pci-info.rst (renamed from doc/driver-model/pci-info.txt) | 21 |
2 files changed, 13 insertions, 9 deletions
diff --git a/doc/driver-model/index.rst b/doc/driver-model/index.rst index d1c19a4103..a83c648e97 100644 --- a/doc/driver-model/index.rst +++ b/doc/driver-model/index.rst @@ -13,3 +13,4 @@ Driver Model livetree migration of-plat + pci-info diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.rst index 14364c5c75..d93ab8b61d 100644 --- a/doc/driver-model/pci-info.txt +++ b/doc/driver-model/pci-info.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0+ + PCI with Driver Model ===================== @@ -7,8 +9,7 @@ How busses are scanned Any config read will end up at pci_read_config(). This uses uclass_get_device_by_seq() to get the PCI bus for a particular bus number. Bus number 0 will need to be requested first, and the alias in the device -tree file will point to the correct device: - +tree file will point to the correct device:: aliases { pci0 = &pci; @@ -45,7 +46,7 @@ present, matching on it takes precedence over PCI IDs and PCI classes. Note we must describe PCI devices with the same bus hierarchy as the hardware, otherwise driver model cannot detect the correct parent/children relationship during PCI bus enumeration thus PCI devices won't be bound to -their drivers accordingly. A working example like below: +their drivers accordingly. A working example like below:: pci { #address-cells = <3>; @@ -113,7 +114,7 @@ Sandbox With sandbox we need a device emulator for each device on the bus since there is no real PCI bus. This works by looking in the device tree node for a -driver. For example: +driver. For example:: pci@1f,0 { @@ -129,11 +130,11 @@ Note that the first cell in the 'reg' value is the bus/device/function. See PCI_BDF() for the encoding (it is also specified in the IEEE Std 1275-1994 PCI bus binding document, v2.1) -When this bus is scanned we will end up with something like this: +When this bus is scanned we will end up with something like this:: -`- * pci-controller @ 05c660c8, 0 - `- pci@1f,0 @ 05c661c8, 63488 - `- emul@1f,0 @ 05c662c8 + `- * pci-controller @ 05c660c8, 0 + `- pci@1f,0 @ 05c661c8, 63488 + `- emul@1f,0 @ 05c662c8 When accesses go to the pci@1f,0 device they are forwarded to its child, the emulator. @@ -144,6 +145,8 @@ eliminating the need to provide any device tree node under the host controller node. It is required a "sandbox,dev-info" property must be provided in the host controller node for this functionality to work. +.. code-block:: none + pci1: pci-controller1 { compatible = "sandbox,pci"; ... @@ -156,7 +159,7 @@ Each dynamic PCI device is encoded as 4 cells a group. The first and second cells are PCI device number and function number respectively. The third and fourth cells are PCI vendor ID and device ID respectively. -When this bus is scanned we will end up with something like this: +When this bus is scanned we will end up with something like this:: pci [ + ] pci_sandbo |-- pci-controller1 pci_emul [ ] sandbox_sw | |-- sandbox_swap_case_emul |