diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.uniphier | 54 | ||||
| -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 |
4 files changed, 140 insertions, 6 deletions
diff --git a/doc/README.uniphier b/doc/README.uniphier index 4902533544..52d681b57a 100644 --- a/doc/README.uniphier +++ b/doc/README.uniphier @@ -28,14 +28,18 @@ Tested toolchains Compile the source ------------------ -PH1-Pro4: - $ make ph1_pro4_defconfig +PH1-sLD3: + $ make ph1_sld3_defconfig $ make CROSS_COMPILE=arm-linux-gnueabi- PH1-LD4: $ make ph1_ld4_defconfig $ make CROSS_COMPILE=arm-linux-gnueabi- +PH1-Pro4: + $ make ph1_pro4_defconfig + $ make CROSS_COMPILE=arm-linux-gnueabi- + PH1-sLD8: $ make ph1_sld8_defconfig $ make CROSS_COMPILE=arm-linux-gnueabi- @@ -81,6 +85,48 @@ Supported devices - Support card (SRAM, NOR flash, some peripherals) +Micro Support Card +------------------ + +The recommended bit switch settings are as follows: + + SW2 OFF(1)/ON(0) Description + ------------------------------------------ + bit 1 <---- BKSZ[0] + bit 2 ----> BKSZ[1] + bit 3 <---- SoC Bus Width 16/32 + bit 4 <---- SERIAL_SEL[0] + bit 5 ----> SERIAL_SEL[1] + bit 6 ----> BOOTSWAP_EN + bit 7 <---- CS1/CS5 + bit 8 <---- SOC_SERIAL_DISABLE + + SW8 OFF(1)/ON(0) Description + ------------------------------------------ + bit 1 ----> CS1_SPLIT + bit 2 <---- CASE9_ON + bit 3 <---- CASE10_ON + bit 4 Don't Care Reserve + bit 5 Don't Care Reserve + bit 6 Don't Care Reserve + bit 7 ----> BURST_EN + bit 8 ----> FLASHBUS32_16 + +The BKSZ[1:0] specifies the address range of memory slot and peripherals +as follows: + + BKSZ Description RAM slot Peripherals + -------------------------------------------------------------------- + 0b00 15MB RAM / 1MB Peri 00000000-0effffff 0f000000-0fffffff + 0b01 31MB RAM / 1MB Peri 00000000-1effffff 1f000000-1fffffff + 0b10 64MB RAM / 1MB Peri 00000000-3effffff 3f000000-3fffffff + 0b11 127MB RAM / 1MB Peri 00000000-7effffff 7f000000-7fffffff + +Set BSKZ[1:0] to 0b01 for U-Boot. +This mode is the most handy because EA[24] is always supported by the save pin +mode of the system bus. On the other hand, EA[25] is not supported for some +newer SoCs. Even if it is, EA[25] is not connected on most of the boards. + -- -Masahiro Yamada <yamada.m@jp.panasonic.com> -Feb. 2015 +Masahiro Yamada <yamada.masahiro@socionext.com> +Jul. 2015 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"; |