From 97f3ee34b6725f9fa5431e91db3223a53e55761c Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Mon, 6 Jul 2015 12:54:22 -0600 Subject: 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 --- doc/driver-model/README.txt | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'doc/driver-model') 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"; -- cgit v1.2.3