diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.fdt-control | 4 | ||||
| -rw-r--r-- | doc/README.omap-reset-time | 20 | ||||
| -rw-r--r-- | doc/README.x86 | 24 | ||||
| -rw-r--r-- | doc/device-tree-bindings/config.txt | 5 | ||||
| -rw-r--r-- | doc/device-tree-bindings/leds/leds-bcm6328.txt | 106 | ||||
| -rw-r--r-- | doc/device-tree-bindings/leds/leds-bcm6358.txt | 141 | ||||
| -rw-r--r-- | doc/device-tree-bindings/pwm/pwm.txt | 69 |
7 files changed, 343 insertions, 26 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control index c965629905..378b06b108 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -130,6 +130,10 @@ u-boot-dtb.bin which does the above step for you also. If you are using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device tree binary. +If CONFIG_OF_BOARD is defined, a board-specific routine will provide the +device tree at runtime, for example if an earlier bootloader stage creates +it and passes it to U-Boot. + If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on startup. This is only useful for sandbox. Use the -d flag to U-Boot to specify the file to read. diff --git a/doc/README.omap-reset-time b/doc/README.omap-reset-time deleted file mode 100644 index 0c974bacae..0000000000 --- a/doc/README.omap-reset-time +++ /dev/null @@ -1,20 +0,0 @@ -README on how reset time on OMAPs should be calculated - -CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC: -Most OMAPs' provide a way to specify the time for -which the reset should be held low while the voltages -and Oscillator outputs stabilize. - -This time is mostly board and PMIC dependent. Hence the -boards are expected to specify a pre-computed time -using the above option, (the details on how to compute -the value are given below) without which a default time -as specified by CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC -is used. - -The value for CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC -can be computed using a summation of the below 3 parameters --1- Time taken by the Osciallator to stop and restart --2- PMIC OTP time --3- Voltage ramp time, which can be derived using the -PMIC slew rate and value of voltage ramp needed. diff --git a/doc/README.x86 b/doc/README.x86 index a38cc1bc6c..c69dc1c511 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -1014,12 +1014,12 @@ compile ACPI DSDT table written in ASL format to AML format. You can get the compiler via "apt-get install iasl" if you are on Ubuntu or download the source from [17] to compile one by yourself. -Current ACPI support in U-Boot is not complete. More features will be added -in the future. The status as of today is: +Current ACPI support in U-Boot is basically complete. More optional features +can be added in the future. The status as of today is: * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables. * Support one static DSDT table only, compiled by Intel ACPI compiler. - * Support S0/S5, reboot and shutdown from OS. + * Support S0/S3/S4/S5, reboot and shutdown from OS. * Support booting a pre-installed Ubuntu distribution via 'zboot' command. * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with the help of SeaBIOS using legacy interface (non-UEFI mode). @@ -1027,9 +1027,6 @@ in the future. The status as of today is: of SeaBIOS using legacy interface (non-UEFI mode). * Support ACPI interrupts with SCI only. -Features not supported so far (to make it a complete ACPI solution): - * S3 (Suspend to RAM), S4 (Suspend to Disk). - Features that are optional: * Dynamic AML bytecodes insertion at run-time. We may need this to support SSDT table generation and DSDT fix up. @@ -1046,6 +1043,21 @@ command from the OS. For other platform boards, ACPI support status can be checked by examining their board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y. +The S3 sleeping state is a low wake latency sleeping state defined by ACPI +spec where all system context is lost except system memory. To test S3 resume +with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will +put the board to S3 state where the power is off. So when the power button is +pressed again, U-Boot runs as it does in cold boot and detects the sleeping +state via ACPI register to see if it is S3, if yes it means we are waking up. +U-Boot is responsible for restoring the machine state as it is before sleep. +When everything is done, U-Boot finds out the wakeup vector provided by OSes +and jump there. To determine whether ACPI S3 resume is supported, check to +see if CONFIG_HAVE_ACPI_RESUME is set for that specific board. + +Note for testing S3 resume with Windows, correct graphics driver must be +installed for your platform, otherwise you won't find "Sleep" option in +the "Power" submenu from the Windows start menu. + EFI Support ----------- U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. diff --git a/doc/device-tree-bindings/config.txt b/doc/device-tree-bindings/config.txt index 5640bae72f..d4bc1df553 100644 --- a/doc/device-tree-bindings/config.txt +++ b/doc/device-tree-bindings/config.txt @@ -20,3 +20,8 @@ u-boot,efi-partition-entries-offset is formatted. This setting will override any values configured via Kconfig. + +u-boot,spl-payload-offset + If present (and SPL is controlled by the device-tree), this allows + to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value + from the device-tree. diff --git a/doc/device-tree-bindings/leds/leds-bcm6328.txt b/doc/device-tree-bindings/leds/leds-bcm6328.txt new file mode 100644 index 0000000000..7f5597b737 --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-bcm6328.txt @@ -0,0 +1,106 @@ +LEDs connected to Broadcom BCM6328 controller + +This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268. +In these SoCs it's possible to control LEDs both as GPIOs or by hardware. +However, on some devices there are Serial LEDs (LEDs connected to a 74x164 +controller), which can either be controlled by software (exporting the 74x164 +as spi-gpio. See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or +by hardware using this driver. +Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and +exporting the 74x164 as spi-gpio prevents those LEDs to be hardware +controlled, so the only chance to keep them working is by using this driver. + +Required properties: + - compatible : should be "brcm,bcm6328-leds". + - #address-cells : must be 1. + - #size-cells : must be 0. + - reg : BCM6328 LED controller address and size. + +Optional properties: + - brcm,serial-leds : Boolean, enables Serial LEDs. + Default : false + - brcm,serial-mux : Boolean, enables Serial LEDs multiplexing. + Default : false + - brcm,serial-clk-low : Boolean, makes clock signal active low. + Default : false + - brcm,serial-dat-low : Boolean, makes data signal active low. + Default : false + - brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction. + Default : false + +Each LED is represented as a sub-node of the brcm,bcm6328-leds device. + +LED sub-node required properties: + - reg : LED pin number (only LEDs 0 to 23 are valid). + +LED sub-node optional properties: + - label : see Documentation/devicetree/bindings/leds/common.txt + - active-low : Boolean, makes LED active low. + Default : false + +Examples: +Scenario 1 : BCM6328 with 4 GPIO LEDs + leds0: led-controller@10000800 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10000800 0x24>; + + alarm_red@2 { + reg = <2>; + active-low; + label = "red:alarm"; + }; + inet_green@3 { + reg = <3>; + active-low; + label = "green:inet"; + }; + power_green@4 { + reg = <4>; + active-low; + label = "green:power"; + }; + }; + +Scenario 2 : BCM63268 with Serial LEDs + leds0: led-controller@10001900 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10001900 0x24>; + brcm,serial-leds; + brcm,serial-dat-low; + brcm,serial-shift-inv; + + inet_red@2 { + reg = <2>; + active-low; + label = "red:inet"; + }; + dsl_green@3 { + reg = <3>; + active-low; + label = "green:dsl"; + }; + usb_green@4 { + reg = <4>; + active-low; + label = "green:usb"; + }; + wps_green@7 { + reg = <7>; + active-low; + label = "green:wps"; + }; + inet_green@8 { + reg = <8>; + active-low; + label = "green:inet"; + }; + power_green@20 { + reg = <20>; + active-low; + label = "green:power"; + }; + }; diff --git a/doc/device-tree-bindings/leds/leds-bcm6358.txt b/doc/device-tree-bindings/leds/leds-bcm6358.txt new file mode 100644 index 0000000000..e394d9ebb4 --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-bcm6358.txt @@ -0,0 +1,141 @@ +LEDs connected to Broadcom BCM6358 controller + +This controller is present on BCM6358 and BCM6368. +In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller), +which can either be controlled by software (exporting the 74x164 as spi-gpio. +See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or +by hardware using this driver. + +Required properties: + - compatible : should be "brcm,bcm6358-leds". + - #address-cells : must be 1. + - #size-cells : must be 0. + - reg : BCM6358 LED controller address and size. + +Optional properties: + - brcm,clk-div : SCK signal divider. Possible values are 1, 2, 4 and 8. + Default : 1 + - brcm,clk-dat-low : Boolean, makes clock and data signals active low. + Default : false + +Each LED is represented as a sub-node of the brcm,bcm6358-leds device. + +LED sub-node required properties: + - reg : LED pin number (only LEDs 0 to 31 are valid). + +LED sub-node optional properties: + - label : see Documentation/devicetree/bindings/leds/common.txt + - active-low : Boolean, makes LED active low. + Default : false + +Examples: +Scenario 1 : BCM6358 + leds0: led-controller@fffe00d0 { + compatible = "brcm,bcm6358-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfffe00d0 0x8>; + + alarm_white { + reg = <0>; + active-low; + label = "white:alarm"; + }; + tv_white { + reg = <2>; + active-low; + label = "white:tv"; + }; + tel_white { + reg = <3>; + active-low; + label = "white:tel"; + }; + adsl_white { + reg = <4>; + active-low; + label = "white:adsl"; + }; + }; + +Scenario 2 : BCM6368 + leds0: led-controller@100000d0 { + compatible = "brcm,bcm6358-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x100000d0 0x8>; + brcm,pol-low; + brcm,clk-div = <4>; + + power_red { + reg = <0>; + active-low; + label = "red:power"; + }; + power_green { + reg = <1>; + active-low; + label = "green:power"; + default-state = "on"; + }; + power_blue { + reg = <2>; + label = "blue:power"; + }; + broadband_red { + reg = <3>; + active-low; + label = "red:broadband"; + }; + broadband_green { + reg = <4>; + label = "green:broadband"; + }; + broadband_blue { + reg = <5>; + active-low; + label = "blue:broadband"; + }; + wireless_red { + reg = <6>; + active-low; + label = "red:wireless"; + }; + wireless_green { + reg = <7>; + active-low; + label = "green:wireless"; + }; + wireless_blue { + reg = <8>; + label = "blue:wireless"; + }; + phone_red { + reg = <9>; + active-low; + label = "red:phone"; + }; + phone_green { + reg = <10>; + active-low; + label = "green:phone"; + }; + phone_blue { + reg = <11>; + label = "blue:phone"; + }; + upgrading_red { + reg = <12>; + active-low; + label = "red:upgrading"; + }; + upgrading_green { + reg = <13>; + active-low; + label = "green:upgrading"; + }; + upgrading_blue { + reg = <14>; + label = "blue:upgrading"; + }; + }; diff --git a/doc/device-tree-bindings/pwm/pwm.txt b/doc/device-tree-bindings/pwm/pwm.txt new file mode 100644 index 0000000000..8556263b85 --- /dev/null +++ b/doc/device-tree-bindings/pwm/pwm.txt @@ -0,0 +1,69 @@ +Specifying PWM information for devices +====================================== + +1) PWM user nodes +----------------- + +PWM users should specify a list of PWM devices that they want to use +with a property containing a 'pwm-list': + + pwm-list ::= <single-pwm> [pwm-list] + single-pwm ::= <pwm-phandle> <pwm-specifier> + pwm-phandle : phandle to PWM controller node + pwm-specifier : array of #pwm-cells specifying the given PWM + (controller specific) + +PWM properties should be named "pwms". The exact meaning of each pwms +property must be documented in the device tree binding for each device. +An optional property "pwm-names" may contain a list of strings to label +each of the PWM devices listed in the "pwms" property. If no "pwm-names" +property is given, the name of the user node will be used as fallback. + +Drivers for devices that use more than a single PWM device can use the +"pwm-names" property to map the name of the PWM device requested by the +pwm_get() call to an index into the list given by the "pwms" property. + +The following example could be used to describe a PWM-based backlight +device: + + pwm: pwm { + #pwm-cells = <2>; + }; + + [...] + + bl: backlight { + pwms = <&pwm 0 5000000>; + pwm-names = "backlight"; + }; + +Note that in the example above, specifying the "pwm-names" is redundant +because the name "backlight" would be used as fallback anyway. + +pwm-specifier typically encodes the chip-relative PWM number and the PWM +period in nanoseconds. + +Optionally, the pwm-specifier can encode a number of flags (defined in +<dt-bindings/pwm/pwm.h>) in a third cell: +- PWM_POLARITY_INVERTED: invert the PWM signal polarity + +Example with optional PWM specifier for inverse polarity + + bl: backlight { + pwms = <&pwm 0 5000000 PWM_POLARITY_INVERTED>; + pwm-names = "backlight"; + }; + +2) PWM controller nodes +----------------------- + +PWM controller nodes must specify the number of cells used for the +specifier using the '#pwm-cells' property. + +An example PWM controller might look like this: + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + }; |