diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/driver-model/debugging.rst | 2 | ||||
| -rw-r--r-- | doc/driver-model/design.rst | 36 | ||||
| -rw-r--r-- | doc/driver-model/ethernet.rst | 2 | ||||
| -rw-r--r-- | doc/driver-model/of-plat.rst | 12 | ||||
| -rw-r--r-- | doc/driver-model/spi-howto.rst | 8 | ||||
| -rw-r--r-- | doc/driver-model/usb-info.rst | 4 |
6 files changed, 32 insertions, 32 deletions
diff --git a/doc/driver-model/debugging.rst b/doc/driver-model/debugging.rst index c59bf67..bbb2794 100644 --- a/doc/driver-model/debugging.rst +++ b/doc/driver-model/debugging.rst @@ -46,7 +46,7 @@ to see errors. Common ones are: going. - -EINVAL which typically indicates that something was missing or wrong in the device tree node. Check that everything is correct and look at the - ofdata_to_platdata() method in the driver. + of_to_plat() method in the driver. If there is no error, you should check if the device is actually bound. Call dm_dump_all() just before you locate the device to make sure it exists. diff --git a/doc/driver-model/design.rst b/doc/driver-model/design.rst index d552f46..b0da3ad 100644 --- a/doc/driver-model/design.rst +++ b/doc/driver-model/design.rst @@ -333,11 +333,11 @@ Briefly, they are: * bind - make the driver model aware of a device (bind it to its driver) * unbind - make the driver model forget the device - * ofdata_to_platdata - convert device tree data to plat - see later + * of_to_plat - convert device tree data to plat - see later * probe - make a device ready for use * remove - remove a device so it cannot be used until probed again -The sequence to get a device to work is bind, ofdata_to_platdata (if using +The sequence to get a device to work is bind, of_to_plat (if using device tree) and probe. @@ -449,23 +449,23 @@ The easiest way to make this work it to add a few members to the driver: .. code-block:: c .plat_auto = sizeof(struct dm_test_pdata), - .ofdata_to_platdata = testfdt_ofdata_to_platdata, + .of_to_plat = testfdt_of_to_plat, The 'auto' feature allowed space for the plat to be allocated -and zeroed before the driver's ofdata_to_platdata() method is called. The -ofdata_to_platdata() method, which the driver write supplies, should parse +and zeroed before the driver's of_to_plat() method is called. The +of_to_plat() method, which the driver write supplies, should parse the device tree node for this device and place it in dev->plat. Thus when the probe method is called later (to set up the device ready for use) the platform data will be present. -Note that both methods are optional. If you provide an ofdata_to_platdata +Note that both methods are optional. If you provide an of_to_plat method then it will be called first (during activation). If you provide a probe method it will be called next. See Driver Lifecycle below for more details. If you don't want to have the plat automatically allocated then you can leave out plat_auto. In this case you can use malloc -in your ofdata_to_platdata (or probe) method to allocate the required memory, +in your of_to_plat (or probe) method to allocate the required memory, and you should free it in the remove method. The driver model tree is intended to mirror that of the device tree. The @@ -690,7 +690,7 @@ Most devices have data in the device tree which they can read to find out the base address of hardware registers and parameters relating to driver operation. This is called 'ofdata' (Open-Firmware data). -The device's_ofdata_to_platdata() implemnents allocation and reading of +The device's of_to_plat() implemnents allocation and reading of plat. A parent's ofdata is always read before a child. The steps are: @@ -719,7 +719,7 @@ The steps are: space. The controller can hold information about the USB state of each of its children. - 5. If the driver provides an ofdata_to_platdata() method, then this is + 5. If the driver provides an of_to_plat() method, then this is called to convert the device tree data into platform data. This should do various calls like dev_read_u32(dev, ...) to access the node and store the resulting information into dev->plat. After this point, the device @@ -728,9 +728,9 @@ The steps are: in the plat structure. Typically you will use the plat_auto feature to specify the size of the platform data structure, and U-Boot will automatically allocate and zero it for you before - entry to ofdata_to_platdata(). But if not, you can allocate it yourself in - ofdata_to_platdata(). Note that it is preferable to do all the device tree - decoding in ofdata_to_platdata() rather than in probe(). (Apart from the + entry to of_to_plat(). But if not, you can allocate it yourself in + of_to_plat(). Note that it is preferable to do all the device tree + decoding in of_to_plat() rather than in probe(). (Apart from the ugliness of mixing configuration and run-time data, one day it is possible that U-Boot will cache platform data for devices which are regularly de/activated). @@ -744,7 +744,7 @@ the device up. Having probing separate from ofdata-reading helps deal with of-platdata, where the probe() method is common to both DT/of-platdata operation, but the -ofdata_to_platdata() method is implemented differently. +of_to_plat() method is implemented differently. Another case has come up where this separate is useful. Generation of ACPI tables uses the of-platdata but does not want to probe the device. Probing @@ -755,18 +755,18 @@ even be possible to probe the device - e.g. an SD card which is not present will cause an error on probe, yet we still must tell Linux about the SD card connector in case it is used while Linux is running. -It is important that the ofdata_to_platdata() method does not actually probe +It is important that the of_to_plat() method does not actually probe the device itself. However there are cases where other devices must be probed -in the ofdata_to_platdata() method. An example is where a device requires a +in the of_to_plat() method. An example is where a device requires a GPIO for it to operate. To select a GPIO obviously requires that the GPIO device is probed. This is OK when used by common, core devices such as GPIO, clock, interrupts, reset and the like. If your device relies on its parent setting up a suitable address space, so that dev_read_addr() works correctly, then make sure that the parent device -has its setup code in ofdata_to_platdata(). If it has it in the probe method, +has its setup code in of_to_plat(). If it has it in the probe method, then you cannot call dev_read_addr() from the child device's -ofdata_to_platdata() method. Move it to probe() instead. Buses like PCI can +of_to_plat() method. Move it to probe() instead. Buses like PCI can fall afoul of this rule. Activation/probe @@ -847,7 +847,7 @@ remove it. This performs the probe steps in reverse: happens automatically within the driver model core; or - when plat_auto is 0, both the allocation (in probe() - or preferably ofdata_to_platdata()) and the deallocation in remove() + or preferably of_to_plat()) and the deallocation in remove() are the responsibility of the driver author. 5. The device sequence number is set to -1, meaning that it no longer diff --git a/doc/driver-model/ethernet.rst b/doc/driver-model/ethernet.rst index 2444c5c..cdbccca 100644 --- a/doc/driver-model/ethernet.rst +++ b/doc/driver-model/ethernet.rst @@ -25,7 +25,7 @@ the UCLASS_ETH .id field in the U-Boot driver struct: .name = "eth_ape", .id = UCLASS_ETH, .of_match = eth_ape_ids, - .ofdata_to_platdata = eth_ape_ofdata_to_platdata, + .of_to_plat = eth_ape_of_to_plat, .probe = eth_ape_probe, .ops = ð_ape_ops, .priv_auto = sizeof(struct eth_ape_priv), diff --git a/doc/driver-model/of-plat.rst b/doc/driver-model/of-plat.rst index b9976ac..4436c4a 100644 --- a/doc/driver-model/of-plat.rst +++ b/doc/driver-model/of-plat.rst @@ -174,7 +174,7 @@ accessed using: struct dtd_rockchip_rk3288_dw_mshc *plat = dev_get_plat(dev); This avoids the code overhead of converting the device tree data to -platform data in the driver. The ofdata_to_platdata() method should +platform data in the driver. The of_to_plat() method should therefore do nothing in such a driver. Note that for the platform data to be matched with a driver, the 'name' @@ -222,7 +222,7 @@ all the limitations metioned in caveats above. Therefore it is recommended that the of-platdata structure should be used only in the probe() method of your driver. It cannot be used in the -ofdata_to_platdata() method since this is not called when platform data is +of_to_plat() method since this is not called when platform data is already present. @@ -234,7 +234,7 @@ feature is intended as a add-on to existing drivers. Your driver should convert the plat struct in its probe() method. The existing device tree decoding logic should be kept in the -ofdata_to_platdata() method and wrapped with #if. +of_to_plat() method and wrapped with #if. For example: @@ -254,7 +254,7 @@ For example: int fifo_depth; }; - static int mmc_ofdata_to_platdata(struct udevice *dev) + static int mmc_of_to_plat(struct udevice *dev) { #if !CONFIG_IS_ENABLED(OF_PLATDATA) /* Decode the device tree data */ @@ -291,7 +291,7 @@ For example: .name = "mmc_drv", .id = UCLASS_MMC, .of_match = mmc_ids, - .ofdata_to_platdata = mmc_ofdata_to_platdata, + .of_to_plat = mmc_of_to_plat, .probe = mmc_probe, .priv_auto = sizeof(struct mmc_priv), .plat_auto = sizeof(struct mmc_platdata), @@ -313,7 +313,7 @@ speaking it is a non-zero plat_size which triggers this). The of-platdata struct contents is copied from the C structure data to the start of the newly allocated area. In the case where device tree is used, the platform data is allocated, and starts zeroed. In this case the -ofdata_to_platdata() method should still set up the platform data (and the +of_to_plat() method should still set up the platform data (and the of-platdata struct will not be present). SPL must use either of-platdata or device tree. Drivers cannot use both at diff --git a/doc/driver-model/spi-howto.rst b/doc/driver-model/spi-howto.rst index b3b719f..0770a09 100644 --- a/doc/driver-model/spi-howto.rst +++ b/doc/driver-model/spi-howto.rst @@ -69,7 +69,7 @@ Put this code at the bottom of your existing driver file: return NULL; } - static int exynos_spi_ofdata_to_platdata(struct udevice *dev) + static int exynos_spi_of_to_plat(struct udevice *dev) { return -ENODEV; } @@ -138,7 +138,7 @@ Put this code at the bottom of your existing driver file: .id = UCLASS_SPI, .of_match = exynos_spi_ids, .ops = &exynos_spi_ops, - .ofdata_to_platdata = exynos_spi_ofdata_to_platdata, + .of_to_plat = exynos_spi_of_to_plat, .probe = exynos_spi_probe, .remove = exynos_spi_remove, }; @@ -217,7 +217,7 @@ DM tells you. The name is not quite right. So in this case we would use: }; -Write ofdata_to_platdata() [for device tree only] +Write of_to_plat() [for device tree only] ------------------------------------------------- This method will convert information in the device tree node into a C @@ -239,7 +239,7 @@ fills in the fields from device tree. .. code-block:: c - static int exynos_spi_ofdata_to_platdata(struct udevice *bus) + static int exynos_spi_of_to_plat(struct udevice *bus) { struct exynos_spi_platdata *plat = bus->plat; const void *blob = gd->fdt_blob; diff --git a/doc/driver-model/usb-info.rst b/doc/driver-model/usb-info.rst index ec8f317..e9fe9d2 100644 --- a/doc/driver-model/usb-info.rst +++ b/doc/driver-model/usb-info.rst @@ -39,7 +39,7 @@ as drivers in the USB uclass. For example: .name = "ehci_tegra", .id = UCLASS_USB, .of_match = ehci_usb_ids, - .ofdata_to_platdata = ehci_usb_ofdata_to_platdata, + .of_to_plat = ehci_usb_of_to_plat, .probe = tegra_ehci_usb_probe, .remove = tegra_ehci_usb_remove, .ops = &ehci_usb_ops, @@ -51,7 +51,7 @@ as drivers in the USB uclass. For example: Here ehci_usb_ids is used to list the controllers that the driver supports. Each has its own data value. Controllers must be in the UCLASS_USB uclass. -The ofdata_to_platdata() method allows the controller driver to grab any +The of_to_plat() method allows the controller driver to grab any necessary settings from the device tree. The ops here are ehci_usb_ops. All EHCI drivers will use these same ops in |