diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/driver-model/README.txt | 68 |
1 files changed, 67 insertions, 1 deletions
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index 11af35dcba..f9b68beb6f 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -95,7 +95,7 @@ are provided in test/dm. To run them, try: You should see something like this: <...U-Boot banner...> - Running 20 driver model tests + Running 21 driver model tests Test: dm_test_autobind Test: dm_test_autoprobe Test: dm_test_bus_children @@ -104,6 +104,7 @@ You should see something like this: Device 'c-test@1': seq 1 is in use by 'd-test' Test: dm_test_bus_children_funcs Test: dm_test_bus_parent_data + Test: dm_test_bus_parent_ops Test: dm_test_children Test: dm_test_fdt Device 'd-test': seq 3 is in use by 'b-test' @@ -425,6 +426,71 @@ entirely under the control of the board author so a conflict is generally an error. +Bus Drivers +----------- + +A common use of driver model is to implement a bus, a device which provides +access to other devices. Example of buses include SPI and I2C. Typically +the bus provides some sort of transport or translation that makes it +possible to talk to the devices on the bus. + +Driver model provides a few useful features to help with implementing +buses. Firstly, a bus can request that its children store some 'parent +data' which can be used to keep track of child state. Secondly, the bus can +define methods which are called when a child is probed or removed. This is +similar to the methods the uclass driver provides. + +Here an explanation of how a bus fits with a uclass may be useful. Consider +a USB bus with several devices attached to it, each from a different (made +up) uclass: + + xhci_usb (UCLASS_USB) + eth (UCLASS_ETHERNET) + camera (UCLASS_CAMERA) + flash (UCLASS_FLASH_STORAGE) + +Each of the devices is connected to a different address on the USB bus. +The bus device wants to store this address and some other information such +as the bus speed for each device. + +To achieve this, the bus device can use dev->parent_priv in each of its +three children. This can be auto-allocated if the bus driver has a non-zero +value for per_child_auto_alloc_size. If not, then the bus device can +allocate the space itself before the child device is probed. + +Also the bus driver can define the child_pre_probe() and child_post_remove() +methods to allow it to do some processing before the child is activated or +after it is deactivated. + +Note that the information that controls this behaviour is in the bus's +driver, not the child's. In fact it is possible that child has no knowledge +that it is connected to a bus. The same child device may even be used on two +different bus types. As an example. the 'flash' device shown above may also +be connected on a SATA bus or standalone with no bus: + + xhci_usb (UCLASS_USB) + flash (UCLASS_FLASH_STORAGE) - parent data/methods defined by USB bus + + sata (UCLASS_SATA) + flash (UCLASS_FLASH_STORAGE) - parent data/methods defined by SATA bus + + flash (UCLASS_FLASH_STORAGE) - no parent data/methods (not on a bus) + +Above you can see that the driver for xhci_usb/sata controls the child's +bus methods. In the third example the device is not on a bus, and therefore +will not have these methods at all. Consider the case where the flash +device defines child methods. These would be used for *its* children, and +would be quite separate from the methods defined by the driver for the bus +that the flash device is connetced to. The act of attaching a device to a +parent device which is a bus, causes the device to start behaving like a +bus device, regardless of its own views on the matter. + +The uclass for the device can also contain data private to that uclass. +But note that each device on the bus may be a memeber of a different +uclass, and this data has nothing to do with the child data for each child +on the bus. + + Driver Lifecycle ---------------- |