diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/device-tree-bindings/leds/leds-bcm6858.txt | 51 | ||||
| -rw-r--r-- | doc/driver-model/fs_firmware_loader.txt | 62 |
2 files changed, 100 insertions, 13 deletions
diff --git a/doc/device-tree-bindings/leds/leds-bcm6858.txt b/doc/device-tree-bindings/leds/leds-bcm6858.txt new file mode 100644 index 0000000000..ea2fe23709 --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-bcm6858.txt @@ -0,0 +1,51 @@ +LEDs connected to Broadcom BCM6858 controller + +This controller is present on BCM6858, BCM6328, BCM6362 and BCM63268. +In these SoCs it's possible to control LEDs both as GPIOs or by hardware. + +Required properties: + - compatible : should be "brcm,bcm6858-leds". + - #address-cells : must be 1. + - #size-cells : must be 0. + - reg : BCM6858 LED controller address and size. + +Optional properties: + - brcm,serial-led-msb-first : Boolean, msb data come out first on serial data pin + Default : false + - brcm,serial-led-en-pol : Boolean, serial led polarity (true => active high) + Default : false + - brcm,serial-led-clk-pol : Boolean, serial clock polarity (true => active high) + Default : false + - brcm,serial-led-data-ppol : Boolean, serial data polarity (true => active high) + Default : false + - brcm,serial-shift-inv : Boolean, led test mode + Default : false + +Each LED is represented as a sub-node of the brcm,bcm6858-leds device. + +LED sub-node required properties: + - reg : LED pin number (only LEDs 0 to 32 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: +BCM6328 with 2 GPIO LEDs + leds0: led-controller@ff800800 { + compatible = "brcm,bcm6858-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x0 0xff800800 0x0 0xe4>; + + led@2 { + reg = <2>; + label = "green:inet"; + }; + + led@5 { + reg = <5>; + label = "red:alarm"; + }; + }; diff --git a/doc/driver-model/fs_firmware_loader.txt b/doc/driver-model/fs_firmware_loader.txt index b9aee848cc..8be6185371 100644 --- a/doc/driver-model/fs_firmware_loader.txt +++ b/doc/driver-model/fs_firmware_loader.txt @@ -1,4 +1,4 @@ -# Copyright (C) 2018 Intel Corporation <www.intel.com> +# Copyright (C) 2018-2019 Intel Corporation <www.intel.com> # # SPDX-License-Identifier: GPL-2.0 @@ -27,7 +27,7 @@ Firmware storage device described in device tree source defined in fs-loader node as shown in below: Example for block device: - fs_loader0: fs-loader@0 { + fs_loader0: fs-loader { u-boot,dm-pre-reloc; compatible = "u-boot,fs-loader"; phandlepart = <&mmc 1>; @@ -39,22 +39,55 @@ Firmware storage device described in device tree source device, it can be described in FDT as shown in below: Example for ubi: - fs_loader1: fs-loader@1 { + fs_loader1: fs-loader { u-boot,dm-pre-reloc; compatible = "u-boot,fs-loader"; mtdpart = "UBI", ubivol = "ubi0"; }; - Then, firmware_loader property would be set with the path of fs_loader - node under /chosen node such as: + Then, firmware-loader property can be added with any device node, which + driver would use the firmware loader for loading. + + The value of the firmware-loader property should be set with phandle + of the fs-loader node. + For example: + firmware-loader = <&fs_loader0>; + + If there are majority of devices using the same fs-loader node, then + firmware-loader property can be added under /chosen node instead of + adding to each of device node. + + For example: /{ chosen { - firmware_loader = &fs_loader0; + firmware-loader = <&fs_loader0>; }; }; - However, this driver is also designed to support U-boot environment + In each respective driver of devices using firmware loader, the firmware + loaded instance should be created by DT phandle. + + For example of getting DT phandle from /chosen and creating instance: + chosen_node = ofnode_path("/chosen"); + if (!ofnode_valid(chosen_node)) { + debug("/chosen node was not found.\n"); + return -ENOENT; + } + + phandle_p = ofnode_get_property(chosen_node, "firmware-loader", &size); + if (!phandle_p) { + debug("firmware-loader property was not found.\n"); + return -ENOENT; + } + + phandle = fdt32_to_cpu(*phandle_p); + ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER, + phandle, &dev); + if (ret) + return ret; + + Firmware loader driver is also designed to support U-boot environment variables, so all these data from FDT can be overwritten through the U-boot environment variable during run time. For examples: @@ -104,9 +137,12 @@ return: Description: The firmware is loaded directly into the buffer pointed to by buf -Example of creating firmware loader instance and calling -request_firmware_into_buf API: - if (uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, &dev)) { - request_firmware_into_buf(dev, filename, buffer_location, - buffer_size, offset_ofreading); - } +Example of calling request_firmware_into_buf API after creating firmware loader +instance: + ret = uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER, + phandle, &dev); + if (ret) + return ret; + + request_firmware_into_buf(dev, filename, buffer_location, buffer_size, + offset_ofreading); |