dm: Add platform data advice and admonishment

We should guide people more strongly towards device tree to avoid the
proliferation of platform data structures. Add documentation to the driver
model README, and also the platform data header file.

Signed-off-by: Simon Glass <sjg@chromium.org>

1 files changed, 15 insertions, 2 deletions

diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index f0276b1b46..b891e8459d 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -301,6 +301,15 @@ device tree) and probe.
 Platform Data
 -------------
 
+*** Note: platform data is the old way of doing things. It is
+*** basically a C structure which is passed to drivers to tell them about
+*** platform-specific settings like the address of its registers, bus
+*** speed, etc. Device tree is now the preferred way of handling this.
+*** Unless you have a good reason not to use device tree (the main one
+*** being you need serial support in SPL and don't have enough SRAM for
+*** the cut-down device tree and libfdt libraries) you should stay away
+*** from platform data.
+
 Platform data is like Linux platform data, if you are familiar with that.
 It provides the board-specific information to start up a device.
 
@@ -366,8 +375,12 @@ Device Tree
 -----------
 
 While platdata is useful, a more flexible way of providing device data is
-by using device tree. With device tree we replace the above code with the
-following device tree fragment:
+by using device tree. In U-Boot you should use this where possible. Avoid
+sending patches which make use of the U_BOOT_DEVICE() macro unless strictly
+necessary.
+
+With device tree we replace the above code with the following device tree
+fragment:
 
 	red-square {
 		compatible = "demo-shape";