Merge tag 'dm-9oct18' of git://git.denx.de/u-boot-dm

[platform/kernel/u-boot.git] / doc / driver-model / README.txt

diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index 1b5ccec..3654163 100644 (file)
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -449,6 +449,15 @@ The driver model tree is intended to mirror that of the device tree. The
 root driver is at device tree offset 0 (the root node, '/'), and its
 children are the children of the root node.
 
+In order for a device tree to be valid, the content must be correct with
+respect to either device tree specification
+(https://www.devicetree.org/specifications/) or the device tree bindings that
+are found in the doc/device-tree-bindings directory.  When not U-Boot specific
+the bindings in this directory tend to come from the Linux Kernel.  As such
+certain design decisions may have been made already for us in terms of how
+specific devices are described and bound.  In most circumstances we wish to
+retain compatibility without additional changes being made to the device tree
+source files.
 
 Declaring Uclasses
 ------------------
@@ -684,7 +693,7 @@ steps (see device_probe()):
 
    g. If the driver provides an ofdata_to_platdata() method, then this is
    called to convert the device tree data into platform data. This should
-   do various calls like fdtdec_get_int(gd->fdt_blob, dev->of_offset, ...)
+   do various calls like fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev), ...)
    to access the node and store the resulting information into dev->platdata.
    After this point, the device works the same way whether it was bound
    using a device tree node or U_BOOT_DEVICE() structure. In either case,
@@ -695,7 +704,7 @@ steps (see device_probe()):
    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 ugliness of mixing configuration and run-time
-   data, one day it is possible that U-Boot will cache platformat data for
+   data, one day it is possible that U-Boot will cache platform data for
    devices which are regularly de/activated).
 
    h. The device's probe() method is called. This should do anything that
@@ -823,7 +832,14 @@ Pre-Relocation Support
 For pre-relocation we simply call the driver model init function. Only
 drivers marked with DM_FLAG_PRE_RELOC or the device tree
 'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps
-to reduce the driver model overhead.
+to reduce the driver model overhead. This flag applies to SPL and TPL as
+well, if device tree is enabled there.
+
+It is possible to limit this to specific relocation steps, by using
+the more specialized 'u-boot,dm-spl' and 'u-boot,dm-tpl' flags
+in the device tree node. For U-Boot proper you can use 'u-boot,dm-pre-proper'
+which means that it will be processed (and a driver bound) in U-Boot proper
+prior to relocation, but will not be available in SPL or TPL.
 
 Then post relocation we throw that away and re-init driver model again.
 For drivers which require some sort of continuity between pre- and