diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/device-tree-bindings/leds/common.txt | 23 | ||||
| -rw-r--r-- | doc/device-tree-bindings/leds/leds-gpio.txt | 52 | ||||
| -rw-r--r-- | doc/driver-model/README.txt | 17 |
3 files changed, 90 insertions, 2 deletions
diff --git a/doc/device-tree-bindings/leds/common.txt b/doc/device-tree-bindings/leds/common.txt new file mode 100644 index 0000000000..2d88816dd5 --- /dev/null +++ b/doc/device-tree-bindings/leds/common.txt @@ -0,0 +1,23 @@ +Common leds properties. + +Optional properties for child nodes: +- label : The label for this LED. If omitted, the label is + taken from the node name (excluding the unit address). + +- linux,default-trigger : This parameter, if present, is a + string defining the trigger assigned to the LED. Current triggers are: + "backlight" - LED will act as a back-light, controlled by the framebuffer + system + "default-on" - LED will turn on (but for leds-gpio see "default-state" + property in Documentation/devicetree/bindings/gpio/led.txt) + "heartbeat" - LED "double" flashes at a load average based rate + "ide-disk" - LED indicates disk activity + "timer" - LED flashes at a fixed, configurable rate + +Examples: + +system-status { + label = "Status"; + linux,default-trigger = "heartbeat"; + ... +}; diff --git a/doc/device-tree-bindings/leds/leds-gpio.txt b/doc/device-tree-bindings/leds/leds-gpio.txt new file mode 100644 index 0000000000..df1b3080f6 --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-gpio.txt @@ -0,0 +1,52 @@ +LEDs connected to GPIO lines + +Required properties: +- compatible : should be "gpio-leds". + +Each LED is represented as a sub-node of the gpio-leds device. Each +node's name represents the name of the corresponding LED. + +LED sub-node properties: +- gpios : Should specify the LED's GPIO, see "gpios property" in + Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be + indicated using flags in the GPIO specifier. +- label : (optional) + see Documentation/devicetree/bindings/leds/common.txt +- linux,default-trigger : (optional) + see Documentation/devicetree/bindings/leds/common.txt +- default-state: (optional) The initial state of the LED. Valid + values are "on", "off", and "keep". If the LED is already on or off + and the default-state property is set the to same value, then no + glitch should be produced where the LED momentarily turns off (or + on). The "keep" setting will keep the LED at whatever its current + state is, without producing a glitch. The default is off if this + property is not present. + +Examples: + +leds { + compatible = "gpio-leds"; + hdd { + label = "IDE Activity"; + gpios = <&mcu_pio 0 1>; /* Active low */ + linux,default-trigger = "ide-disk"; + }; + + fault { + gpios = <&mcu_pio 1 0>; + /* Keep LED on if BIOS detected hardware fault */ + default-state = "keep"; + }; +}; + +run-control { + compatible = "gpio-leds"; + red { + gpios = <&mpc8572 6 0>; + default-state = "off"; + }; + green { + gpios = <&mpc8572 7 0>; + default-state = "on"; + }; +}; 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"; |