diff options
Diffstat (limited to 'roms/u-boot/doc/device-tree-bindings/gpio')
15 files changed, 1147 insertions, 0 deletions
diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt new file mode 100644 index 000000000..cf71eb282 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/altera_pio.txt @@ -0,0 +1,28 @@ +Altera GPIO controller bindings + +Required properties: +- compatible: + - "altr,pio-1.0" +- reg: Physical base address and length of the controller's registers. + +Optional properties: +- altr,gpio-bank-width: Width of the GPIO bank. This defines how many pins the + GPIO device has. Ranges between 1-32. Optional and defaults to 32 if not + specified. +- gpio-bank-name: bank name attached to this device. + +Example: + +user_led_pio_8out: gpio@0x4cc0 { + compatible = "altr,pio-1.0"; + reg = <0x00004cc0 0x00000010>; + resetvalue = <255>; + altr,gpio-bank-width = <8>; + #gpio-cells = <2>; + gpio-controller; + gpio-bank-name = "led"; +}; + +In this example, the gpio can be accessed as led[0..7] using gpio command of +u-boot. +==> gpio clear led0 diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt new file mode 100644 index 000000000..21e0610b3 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/bcm2835-gpio.txt @@ -0,0 +1,5 @@ +* Broadcom BCM283x GPIO controller + +Required properties: +- compatible: must be "brcm,bcm2835-gpio" +- reg: exactly one register range with length 0xb4 diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt b/roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt new file mode 100644 index 000000000..52d8bb0a5 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt @@ -0,0 +1,22 @@ +MPC83xx SPISEL_BOOT gpio controller + +Provide access to MPC83xx SPISEL_BOOT signal as a gpio to allow it to be +easily bound as a SPI controller chip select. + +The SPISEL_BOOT signal is always an output. + +Required properties: + +- compatible: must be "fsl,mpc83xx-spisel-boot" or "fsl,mpc8309-spisel-boot". +- reg: must point to the SPI_CS register in the SoC register map. +- ngpios: number of gpios provided by driver, normally 1. + +Example: + + spisel_boot: spisel_boot@14c { + compatible = "fsl,mpc8309-spisel-boot"; + reg = <0x14c 0x04>; + #gpio-cells = <2>; + device_type = "gpio"; + ngpios = <1>; + }; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt new file mode 100644 index 000000000..70a2c7f0d --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt @@ -0,0 +1,23 @@ +Qualcomm Snapdragon GPIO controller + +Required properties: +- compatible : "qcom,msm8916-pinctrl", "qcom,apq8016-pinctrl" or + "qcom,ipq4019-pinctrl" +- reg : Physical base address and length of the controller's registers. + This controller is called "Top Level Mode Multiplexing" in + Qualcomm documentation. +- #gpio-cells : Should be one (pin number). +- gpio-controller : Marks the device node as a GPIO controller. +- gpio-count: Number of GPIO pins. +- gpio-bank-name: (optional) name of gpio bank. As default "soc" is used. + +Example: + +soc_gpios: pinctrl@1000000 { + compatible = "qcom,msm8916-pinctrl"; + reg = <0x1000000 0x300000>; + gpio-controller; + gpio-count = <122>; + gpio-bank-name="soc"; + #gpio-cells = <1>; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt new file mode 100644 index 000000000..ada4e2973 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-pcf857x.txt @@ -0,0 +1,71 @@ +* PCF857x-compatible I/O expanders + +The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be +driven high by a pull-up current source or driven low to ground. This combines +the direction and output level into a single bit per line, which can't be read +back. We can't actually know at initialization time whether a line is configured +(a) as output and driving the signal low/high, or (b) as input and reporting a +low/high value, without knowing the last value written since the chip came out +of reset (if any). The only reliable solution for setting up line direction is +thus to do it explicitly. + +Required Properties: + + - compatible: should be one of the following. + - "maxim,max7328": For the Maxim MAX7378 + - "maxim,max7329": For the Maxim MAX7329 + - "nxp,pca8574": For the NXP PCA8574 + - "nxp,pca8575": For the NXP PCA8575 + - "nxp,pca9670": For the NXP PCA9670 + - "nxp,pca9671": For the NXP PCA9671 + - "nxp,pca9672": For the NXP PCA9672 + - "nxp,pca9673": For the NXP PCA9673 + - "nxp,pca9674": For the NXP PCA9674 + - "nxp,pca9675": For the NXP PCA9675 + - "nxp,pcf8574": For the NXP PCF8574 + - "nxp,pcf8574a": For the NXP PCF8574A + - "nxp,pcf8575": For the NXP PCF8575 + - "ti,tca9554": For the TI TCA9554 + + - reg: I2C slave address. + + - gpio-controller: Marks the device node as a gpio controller. + - #gpio-cells: Should be 2. The first cell is the GPIO number and the second + cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the + GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. + +Optional Properties: + + - lines-initial-states: Bitmask that specifies the initial state of each + line. When a bit is set to zero, the corresponding line will be initialized to + the input (pulled-up) state. When the bit is set to one, the line will be + initialized the low-level output state. If the property is not specified + all lines will be initialized to the input state. + + The I/O expander can detect input state changes, and thus optionally act as + an interrupt controller. When the expander interrupt line is connected all the + following properties must be set. For more information please see the + interrupt controller device tree bindings documentation available at + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt. + + - interrupt-controller: Identifies the node as an interrupt controller. + - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2. + - interrupt-parent: phandle of the parent interrupt controller. + - interrupts: Interrupt specifier for the controllers interrupt. + + +Please refer to gpio.txt in this directory for details of the common GPIO +bindings used by client devices. + +Example: PCF8575 I/O expander node + + pcf8575: gpio@20 { + compatible = "nxp,pcf8575"; + reg = <0x20>; + interrupt-parent = <&irqpin2>; + interrupts = <3 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt new file mode 100644 index 000000000..5375625e8 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt @@ -0,0 +1,41 @@ +Samsung Exynos4 GPIO Controller + +Required properties: +- compatible: Compatible property value should be "samsung,exynos4-gpio>". + +- reg: Physical base address of the controller and length of memory mapped + region. + +- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes + should be the following with values derived from the SoC user manual. + <[phandle of the gpio controller node] + [pin number within the gpio controller] + [mux function] + [flags and pull up/down] + [drive strength]> + + Values for gpio specifier: + - Pin number: is a value between 0 to 7. + - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled. + 1 - Pull Down Enabled. + 3 - Pull Up Enabled. + Bit 16 (0x00010000) - Input is active low. + - Drive Strength: 0 - 1x, + 1 - 3x, + 2 - 2x, + 3 - 4x + +- gpio-controller: Specifies that the node is a gpio controller. +- #address-cells: should be 1. +- #size-cells: should be 1. + +Example: + + gpa0: gpio-controller@11400000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "samsung,exynos4-gpio"; + reg = <0x11400000 0x20>; + #gpio-cells = <4>; + gpio-controller; + }; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt new file mode 100644 index 000000000..1481ed607 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/gpio.txt @@ -0,0 +1,324 @@ +Specifying GPIO information for devices +============================================ + +1) gpios property +----------------- + +GPIO properties should be named "[<name>-]gpios", with <name> being the purpose +of this GPIO for the device. While a non-existent <name> is considered valid +for compatibility reasons (resolving to the "gpios" property), it is not allowed +for new bindings. Also, GPIO properties named "[<name>-]gpio" are valid and old +bindings use it, but are only supported for compatibility reasons and should not +be used for newer bindings since it has been deprecated. + +GPIO properties can contain one or more GPIO phandles, but only in exceptional +cases should they contain more than one. If your device uses several GPIOs with +distinct functions, reference each of them under its own property, giving it a +meaningful name. The only case where an array of GPIOs is accepted is when +several GPIOs serve the same function (e.g. a parallel data line). + +The exact purpose of each gpios property must be documented in the device tree +binding of the device. + +The following example could be used to describe GPIO pins used as device enable +and bit-banged data signals: + + gpio1: gpio1 { + gpio-controller; + #gpio-cells = <2>; + }; + [...] + + data-gpios = <&gpio1 12 0>, + <&gpio1 13 0>, + <&gpio1 14 0>, + <&gpio1 15 0>; + +In the above example, &gpio1 uses 2 cells to specify a gpio. The first cell is +a local offset to the GPIO line and the second cell represent consumer flags, +such as if the consumer desire the line to be active low (inverted) or open +drain. This is the recommended practice. + +The exact meaning of each specifier cell is controller specific, and must be +documented in the device tree binding for the device, but it is strongly +recommended to use the two-cell approach. + +Most controllers are specifying a generic flag bitfield in the last cell, so +for these, use the macros defined in +include/dt-bindings/gpio/gpio.h whenever possible: + +Example of a node using GPIOs: + + node { + enable-gpios = <&qe_pio_e 18 GPIO_ACTIVE_HIGH>; + }; + +GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is "18 0" and encodes +GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller. + +Optional standard bitfield specifiers for the last cell: + +- Bit 0: 0 means active high, 1 means active low +- Bit 1: 0 mean push-pull wiring, see: + https://en.wikipedia.org/wiki/Push-pull_output + 1 means single-ended wiring, see: + https://en.wikipedia.org/wiki/Single-ended_triode +- Bit 2: 0 means open-source, 1 means open drain, see: + https://en.wikipedia.org/wiki/Open_collector +- Bit 3: 0 means the output should be maintained during sleep/low-power mode + 1 means the output state can be lost during sleep/low-power mode +- Bit 4: 0 means no pull-up resistor should be enabled + 1 means a pull-up resistor should be enabled + This setting only applies to hardware with a simple on/off + control for pull-up configuration. If the hardware has more + elaborate pull-up configuration, it should be represented + using a pin control binding. +- Bit 5: 0 means no pull-down resistor should be enabled + 1 means a pull-down resistor should be enabled + This setting only applies to hardware with a simple on/off + control for pull-down configuration. If the hardware has more + elaborate pull-down configuration, it should be represented + using a pin control binding. + +1.1) GPIO specifier best practices +---------------------------------- + +A gpio-specifier should contain a flag indicating the GPIO polarity; active- +high or active-low. If it does, the following best practices should be +followed: + +The gpio-specifier's polarity flag should represent the physical level at the +GPIO controller that achieves (or represents, for inputs) a logically asserted +value at the device. The exact definition of logically asserted should be +defined by the binding for the device. If the board inverts the signal between +the GPIO controller and the device, then the gpio-specifier will represent the +opposite physical level than the signal at the device's pin. + +When the device's signal polarity is configurable, the binding for the +device must either: + +a) Define a single static polarity for the signal, with the expectation that +any software using that binding would statically program the device to use +that signal polarity. + +The static choice of polarity may be either: + +a1) (Preferred) Dictated by a binding-specific DT property. + +or: + +a2) Defined statically by the DT binding itself. + +In particular, the polarity cannot be derived from the gpio-specifier, since +that would prevent the DT from separately representing the two orthogonal +concepts of configurable signal polarity in the device, and possible board- +level signal inversion. + +or: + +b) Pick a single option for device signal polarity, and document this choice +in the binding. The gpio-specifier should represent the polarity of the signal +(at the GPIO controller) assuming that the device is configured for this +particular signal polarity choice. If software chooses to program the device +to generate or receive a signal of the opposite polarity, software will be +responsible for correctly interpreting (inverting) the GPIO signal at the GPIO +controller. + +2) gpio-controller nodes +------------------------ + +Every GPIO controller node must contain both an empty "gpio-controller" +property, and a #gpio-cells integer property, which indicates the number of +cells in a gpio-specifier. + +Some system-on-chips (SoCs) use the concept of GPIO banks. A GPIO bank is an +instance of a hardware IP core on a silicon die, usually exposed to the +programmer as a coherent range of I/O addresses. Usually each such bank is +exposed in the device tree as an individual gpio-controller node, reflecting +the fact that the hardware was synthesized by reusing the same IP block a +few times over. + +Optionally, a GPIO controller may have a "ngpios" property. This property +indicates the number of in-use slots of available slots for GPIOs. The +typical example is something like this: the hardware register is 32 bits +wide, but only 18 of the bits have a physical counterpart. The driver is +generally written so that all 32 bits can be used, but the IP block is reused +in a lot of designs, some using all 32 bits, some using 18 and some using +12. In this case, setting "ngpios = <18>;" informs the driver that only the +first 18 GPIOs, at local offset 0 .. 17, are in use. + +If these GPIOs do not happen to be the first N GPIOs at offset 0...N-1, an +additional set of tuples is needed to specify which GPIOs are unusable, with +the gpio-reserved-ranges binding. This property indicates the start and size +of the GPIOs that can't be used. + +Optionally, a GPIO controller may have a "gpio-line-names" property. This is +an array of strings defining the names of the GPIO lines going out of the +GPIO controller. This name should be the most meaningful producer name +for the system, such as a rail name indicating the usage. Package names +such as pin name are discouraged: such lines have opaque names (since they +are by definition generic purpose) and such names are usually not very +helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are +reasonable line names as they describe what the line is used for. "GPIO0" +is not a good name to give to a GPIO line. Placeholders are discouraged: +rather use the "" (blank string) if the use of the GPIO line is undefined +in your design. The names are assigned starting from line offset 0 from +left to right from the passed array. An incomplete array (where the number +of passed named are less than ngpios) will still be used up until the last +provided valid line index. + +Example: + +gpio-controller@00000000 { + compatible = "foo"; + reg = <0x00000000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + ngpios = <18>; + gpio-reserved-ranges = <0 4>, <12 2>; + gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", + "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", + "Row A", "Row B", "Row C", "Row D", "NMI button", + "poweroff", "reset"; +} + +The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism +providing automatic GPIO request and configuration as part of the +gpio-controller's driver probe function. + +Each GPIO hog definition is represented as a child node of the GPIO controller. +Required properties: +- gpio-hog: A property specifying that this child node represents a GPIO hog. +- gpios: Store the GPIO information (id, flags, ...) for each GPIO to + affect. Shall contain an integer multiple of the number of cells + specified in its parent node (GPIO controller node). +Only one of the following properties scanned in the order shown below. +This means that when multiple properties are present they will be searched +in the order presented below and the first match is taken as the intended +configuration. +- input: A property specifying to set the GPIO direction as input. +- output-low A property specifying to set the GPIO direction as output with + the value low. +- output-high A property specifying to set the GPIO direction as output with + the value high. + +Optional properties: +- line-name: The GPIO label name. If not present the node name is used. + +Example of two SOC GPIO banks defined as gpio-controller nodes: + + qe_pio_a: gpio-controller@1400 { + compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank"; + reg = <0x1400 0x18>; + gpio-controller; + #gpio-cells = <2>; + }; + + qe_pio_e: gpio-controller@1460 { + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; + reg = <0x1460 0x18>; + gpio-controller; + #gpio-cells = <2>; + }; + +2.1) gpio- and pin-controller interaction +----------------------------------------- + +Some or all of the GPIOs provided by a GPIO controller may be routed to pins +on the package via a pin controller. This allows muxing those pins between +GPIO and other functions. It is a fairly common practice among silicon +engineers. + +2.2) Ordinary (numerical) GPIO ranges +------------------------------------- + +It is useful to represent which GPIOs correspond to which pins on which pin +controllers. The gpio-ranges property described below represents this with +a discrete set of ranges mapping pins from the pin controller local number space +to pins in the GPIO controller local number space. + +The format is: <[pin controller phandle], [GPIO controller offset], + [pin controller offset], [number of pins]>; + +The GPIO controller offset pertains to the GPIO controller node containing the +range definition. + +The pin controller node referenced by the phandle must conform to the bindings +described in pinctrl/pinctrl-bindings.txt. + +Each offset runs from 0 to N. It is perfectly fine to pile any number of +ranges with just one pin-to-GPIO line mapping if the ranges are concocted, but +in practice these ranges are often lumped in discrete sets. + +Example: + + gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>; + +This means: +- pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and +- pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29 + + +Verbose example: + + qe_pio_e: gpio-controller@1460 { + #gpio-cells = <2>; + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; + reg = <0x1460 0x18>; + gpio-controller; + gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>; + }; + +Here, a single GPIO controller has GPIOs 0..9 routed to pin controller +pinctrl1's pins 20..29, and GPIOs 10..29 routed to pin controller pinctrl2's +pins 50..69. + + +2.3) GPIO ranges from named pin groups +-------------------------------------- + +It is also possible to use pin groups for gpio ranges when pin groups are the +easiest and most convenient mapping. + +Both both <pinctrl-base> and <count> must set to 0 when using named pin groups +names. + +The property gpio-ranges-group-names must contain exactly one string for each +range. + +Elements of gpio-ranges-group-names must contain the name of a pin group +defined in the respective pin controller. The number of pins/GPIO lines in the +range is the number of pins in that pin group. The number of pins of that +group is defined int the implementation and not in the device tree. + +If numerical and named pin groups are mixed, the string corresponding to a +numerical pin range in gpio-ranges-group-names must be empty. + +Example: + + gpio_pio_i: gpio-controller@14b0 { + #gpio-cells = <2>; + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; + reg = <0x1480 0x18>; + gpio-controller; + gpio-ranges = <&pinctrl1 0 20 10>, + <&pinctrl2 10 0 0>, + <&pinctrl1 15 0 10>, + <&pinctrl2 25 0 0>; + gpio-ranges-group-names = "", + "foo", + "", + "bar"; + }; + +Here, three GPIO ranges are defined referring to two pin controllers. + +pinctrl1 GPIO ranges are defined using pin numbers whereas the GPIO ranges +in pinctrl2 are defined using the pin groups named "foo" and "bar". + +Previous versions of this binding required all pin controller nodes that +were referenced by any gpio-ranges property to contain a property named +#gpio-range-cells with value <3>. This requirement is now deprecated. +However, that property may still exist in older device trees for +compatibility reasons, and would still be required even in new device +trees that need to be compatible with older software. diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt new file mode 100644 index 000000000..8422ff63a --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/intel,apl-gpio.txt @@ -0,0 +1,55 @@ +Intel Apollo Lake GPIO controller + +The Apollo Lake (APL) GPIO controller is used to control GPIO functions of +the pins. + +Required properties: +- compatible: "intel,apl-gpio" +- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client + nodes should be the following with values derived from the SoC user manual. + <[phandle of the gpio controller node] + [pin number within the gpio controller] + [flags]> + + Values for gpio specifier: + - Pin number: is a GPIO pin number between 0 and 244 + - Flags: GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW + +- gpio-controller: Specifies that the node is a gpio controller. + +Example: + +... +{ + p2sb: p2sb@d,0 { + reg = <0x02006810 0 0 0 0>; + compatible = "intel,p2sb"; + early-regs = <IOMAP_P2SB_BAR 0x100000>; + + north { + compatible = "intel,apl-pinctrl"; + intel,p2sb-port-id = <PID_GPIO_N>; + gpio_n: gpio-n { + compatible = "intel,gpio"; + gpio-controller; + #gpio-cells = <2>; + }; + }; + }; + + i2c_2: i2c2@16,2 { + compatible = "intel,apl-i2c", "snps,designware-i2c-pci"; + reg = <0x0200b210 0 0 0 0>; + #address-cells = <1>; + #size-cells = <0>; + clock-frequency = <400000>; + tpm@50 { + reg = <0x50>; + compatible = "google,cr50"; + u-boot,i2c-offset-len = <0>; + ready-gpios = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>; + }; + }; + +}; +... diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt new file mode 100644 index 000000000..a644381e0 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt @@ -0,0 +1,208 @@ +Intel x86 PINCTRL/GPIO controller + +Pin-muxing on broadwell devices can be described with a node for the PINCTRL +master node and a set of child nodes for each required pin state on the SoC. +These pin states use phandles and are referred to but a configuration section +which lists all pins in the device. + +The PINCTRL master node requires the following properties: +- compatible : "intel,x86-broadwell-pinctrl" + +Pin state nodes must be sub-nodes of the pinctrl master node. The must have +a phandle. They can contain the following optional properties: +- mode-gpio - forces the pin into GPIO mode +- output-value - sets the default output value of the GPIO, 0 (low, default) + or 1 (high) +- direction - sets the direction of the gpio, either PIN_INPUT (default) + or PIN_OUTPUT +- invert - the input pin is inverted +- trigger - sets the trigger type, either TRIGGER_EDGE (default) or + TRIGGER_LEVEL +- sense-disable - the input state sense is disabled +- owner 0 sets the owner of the pin, either OWNER_ACPI (default) or + ONWER_GPIO +- route - sets whether the pin is routed, either PIRQ_APIC_MASK or + PIRQ_APIC_ROUTE +- irq-enable - the interrupt is enabled +- reset-rsmrst - the pin will only be reset by RSMRST +- pirq-apic - the pin will be routed to the IOxAPIC + +The first pin state will be the default, so pins without a configuration will +use that. + +The pin configuration node is also a sub-node of the pinctrl master node, but +does not have a phandle. It has a single property: + +- config - configuration to use for each pin. Each entry has of 3 cells: + - GPIO number (0..94) + - phandle of configuration (above) + - interrupt number (0..15) + + There should be one entry for each pin (i.e. 95 entries). + But missing pins will receive the default configuration. + +Example: + +pch_pinctrl { + compatible = "intel,x86-broadwell-pinctrl"; + + /* Put this first: it is the default */ + gpio_unused: gpio-unused { + mode-gpio; + direction = <PIN_INPUT>; + owner = <OWNER_GPIO>; + sense-disable; + }; + + gpio_acpi_sci: acpi-sci { + mode-gpio; + direction = <PIN_INPUT>; + invert; + route = <ROUTE_SCI>; + }; + + gpio_acpi_smi: acpi-smi { + mode-gpio; + direction = <PIN_INPUT>; + invert; + route = <ROUTE_SMI>; + }; + + gpio_input: gpio-input { + mode-gpio; + direction = <PIN_INPUT>; + owner = <OWNER_GPIO>; + }; + + gpio_input_invert: gpio-input-invert { + mode-gpio; + direction = <PIN_INPUT>; + owner = <OWNER_GPIO>; + invert; + }; + + gpio_native: gpio-native { + }; + + gpio_out_high: gpio-out-high { + mode-gpio; + direction = <PIN_OUTPUT>; + output-value = <1>; + owner = <OWNER_GPIO>; + sense-disable; + }; + + gpio_out_low: gpio-out-low { + mode-gpio; + direction = <PIN_OUTPUT>; + output-value = <0>; + owner = <OWNER_GPIO>; + sense-disable; + }; + + gpio_pirq: gpio-pirq { + mode-gpio; + direction = <PIN_INPUT>; + owner = <OWNER_GPIO>; + pirq-apic = <PIRQ_APIC_ROUTE>; + }; + + soc_gpio@0 { + config = + <0 &gpio_unused 0>, /* unused */ + <1 &gpio_unused 0>, /* unused */ + <2 &gpio_unused 0>, /* unused */ + <3 &gpio_unused 0>, /* unused */ + <4 &gpio_native 0>, /* native: i2c0_sda_gpio4 */ + <5 &gpio_native 0>, /* native: i2c0_scl_gpio5 */ + <6 &gpio_native 0>, /* native: i2c1_sda_gpio6 */ + <7 &gpio_native 0>, /* native: i2c1_scl_gpio7 */ + <8 &gpio_acpi_sci 0>, /* pch_lte_wake_l */ + <9 &gpio_input_invert 0>,/* trackpad_int_l (wake) */ + <10 &gpio_acpi_sci 0>, /* pch_wlan_wake_l */ + <11 &gpio_unused 0>, /* unused */ + <12 &gpio_unused 0>, /* unused */ + <13 &gpio_pirq 3>, /* trackpad_int_l (pirql) */ + <14 &gpio_pirq 4>, /* touch_int_l (pirqm) */ + <15 &gpio_unused 0>, /* unused (strap) */ + <16 &gpio_input 0>, /* pch_wp */ + <17 &gpio_unused 0>, /* unused */ + <18 &gpio_unused 0>, /* unused */ + <19 &gpio_unused 0>, /* unused */ + <20 &gpio_native 0>, /* pcie_wlan_clkreq_l */ + <21 &gpio_out_high 0>, /* pp3300_ssd_en */ + <22 &gpio_unused 0>, /* unused */ + <23 &gpio_out_low 0>, /* pp3300_autobahn_en */ + <24 &gpio_unused 0>, /* unused */ + <25 &gpio_input 0>, /* ec_in_rw */ + <26 &gpio_unused 0>, /* unused */ + <27 &gpio_acpi_sci 0>, /* pch_wake_l */ + <28 &gpio_unused 0>, /* unused */ + <29 &gpio_unused 0>, /* unused */ + <30 &gpio_native 0>, /* native: pch_suswarn_l */ + <31 &gpio_native 0>, /* native: acok_buf */ + <32 &gpio_native 0>, /* native: lpc_clkrun_l */ + <33 &gpio_native 0>, /* native: ssd_devslp */ + <34 &gpio_acpi_smi 0>, /* ec_smi_l */ + <35 &gpio_acpi_smi 0>, /* pch_nmi_dbg_l (route in nmi_en) */ + <36 &gpio_acpi_sci 0>, /* ec_sci_l */ + <37 &gpio_unused 0>, /* unused */ + <38 &gpio_unused 0>, /* unused */ + <39 &gpio_unused 0>, /* unused */ + <40 &gpio_native 0>, /* native: pch_usb1_oc_l */ + <41 &gpio_native 0>, /* native: pch_usb2_oc_l */ + <42 &gpio_unused 0>, /* wlan_disable_l */ + <43 &gpio_out_high 0>, /* pp1800_codec_en */ + <44 &gpio_unused 0>, /* unused */ + <45 &gpio_acpi_sci 0>, /* dsp_int - codec wake */ + <46 &gpio_pirq 6>, /* hotword_det_l_3v3 (pirqo) - codec irq */ + <47 &gpio_out_low 0>, /* ssd_reset_l */ + <48 &gpio_unused 0>, /* unused */ + <49 &gpio_unused 0>, /* unused */ + <50 &gpio_unused 0>, /* unused */ + <51 &gpio_unused 0>, /* unused */ + <52 &gpio_input 0>, /* sim_det */ + <53 &gpio_unused 0>, /* unused */ + <54 &gpio_unused 0>, /* unused */ + <55 &gpio_unused 0>, /* unused */ + <56 &gpio_unused 0>, /* unused */ + <57 &gpio_out_high 0>, /* codec_reset_l */ + <58 &gpio_unused 0>, /* unused */ + <59 &gpio_out_high 0>, /* lte_disable_l */ + <60 &gpio_unused 0>, /* unused */ + <61 &gpio_native 0>, /* native: pch_sus_stat */ + <62 &gpio_native 0>, /* native: pch_susclk */ + <63 &gpio_native 0>, /* native: pch_slp_s5_l */ + <64 &gpio_unused 0>, /* unused */ + <65 &gpio_input 0>, /* ram_id3 */ + <66 &gpio_input 0>, /* ram_id3_old (strap) */ + <67 &gpio_input 0>, /* ram_id0 */ + <68 &gpio_input 0>, /* ram_id1 */ + <69 &gpio_input 0>, /* ram_id2 */ + <70 &gpio_unused 0>, /* unused */ + <71 &gpio_native 0>, /* native: modphy_en */ + <72 &gpio_unused 0>, /* unused */ + <73 &gpio_unused 0>, /* unused */ + <74 &gpio_unused 0>, /* unused */ + <75 &gpio_unused 0>, /* unused */ + <76 &gpio_unused 0>, /* unused */ + <77 &gpio_unused 0>, /* unused */ + <78 &gpio_unused 0>, /* unused */ + <79 &gpio_unused 0>, /* unused */ + <80 &gpio_unused 0>, /* unused */ + <81 &gpio_unused 0>, /* unused */ + <82 &gpio_native 0>, /* native: ec_rcin_l */ + <83 &gpio_native 0>, /* gspi0_cs */ + <84 &gpio_native 0>, /* gspi0_clk */ + <85 &gpio_native 0>, /* gspi0_miso */ + <86 &gpio_native 0>, /* gspi0_mosi (strap) */ + <87 &gpio_unused 0>, /* unused */ + <88 &gpio_unused 0>, /* unused */ + <89 &gpio_out_high 0>, /* pp3300_sd_en */ + <90 &gpio_unused 0>, /* unused */ + <91 &gpio_unused 0>, /* unused */ + <92 &gpio_unused 0>, /* unused */ + <93 &gpio_unused 0>, /* unused */ + <94 &gpio_unused 0 >; /* unused */ + }; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt new file mode 100644 index 000000000..8c3a84caf --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt @@ -0,0 +1,33 @@ +Intel x86 PINCTRL/GPIO controller + +Pin-muxing on x86 can be described with a node for the PINCTRL master +node and a set of child nodes for each pin on the SoC. + +The PINCTRL master node requires the following properties: +- compatible : "intel,x86-pinctrl" + +Pin nodes must be children of the pinctrl master node and can +contain the following properties: +- pad-offset - (required) offset in the IOBASE for the pin to configure +- gpio-offset - (required only when 'mode-gpio' is set) 2 cells + - offset in the GPIOBASE for the pin to configure + - the bit shift in this register (4 = bit 4) +- mode-gpio - (optional) standalone property to force the pin into GPIO mode +- mode-func - (optional) function number to assign to the pin. If + 'mode-gpio' is set, this property will be ignored. +in case of 'mode-gpio' property set: +- output-value - (optional) this set the default output value of the GPIO +- direction - (optional) this set the direction of the gpio +- pull-strength - (optional) this set the pull strength of the pin +- pull-assign - (optional) this set the pull assignement (up/down) of the pin +- invert - (optional) this input pin is inverted + +Example: + +pin_usb_host_en0@0 { + gpio-offset = <0x80 8>; + pad-offset = <0x260>; + mode-gpio; + output-value = <1>; + direction = <PIN_OUTPUT>; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt new file mode 100644 index 000000000..3d344d64a --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/mscc_sgpio.txt @@ -0,0 +1,45 @@ +Microsemi Corporation (MSCC) Serial GPIO driver + +The MSCC serial GPIO extends the number or GPIO's on the system by +means of 4 dedicated pins: one input, one output, one clock and one +strobe pin. By attaching a number of (external) shift registers, the +effective GPIO count can be extended by up to 128 GPIO's per +controller. + +Required properties: +- compatible : "mscc,luton-sgpio" or "mscc,ocelot-sgpio" +- clock: Reference clock used to generate clock divider setting. See + mscc,sgpio-frequency property. +- reg : Physical base address and length of the controller's registers. +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. +- gpio-ranges: Standard gpio range(s): phandle, gpio base, pinctrl base + and count. + +Optional properties: +- ngpios: See gpio.txt +- mscc,sgpio-frequency: The frequency at which the serial bitstream is + generated and sampled. Default: 12500000 (Hz). +- mscc,sgpio-ports: A bitmask (32 bits) of which ports are enabled in + the serialized gpio stream. One 'port' will transport from 1 to 4 + gpio bits. Default: 0xFFFFFFFF. + +Typically the pinctrl-0 and pinctrl-names properties will also be +present to enable the use of the SIO CLK, LD, DI and DO for some +regular GPIO pins. + +Example: + +sgpio: gpio@10700f8 { + compatible = "mscc,ocelot-sgpio"; + pinctrl-0 = <&sgpio_pins>; + pinctrl-names = "default"; + reg = <0x10700f8 0x100>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&sgpio 0 0 64>; + mscc,sgpio-frequency = <12500>; + mscc,sgpio-ports = <0x000FFFFF>; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt new file mode 100644 index 000000000..c82a2e221 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt @@ -0,0 +1,161 @@ +NVIDIA Tegra186 GPIO controllers + +Tegra186 contains two GPIO controllers; a main controller and an "AON" +controller. This binding document applies to both controllers. The register +layouts for the controllers share many similarities, but also some significant +differences. Hence, this document describes closely related but different +bindings and compatible values. + +The Tegra186 GPIO controller allows software to set the IO direction of, and +read/write the value of, numerous GPIO signals. Routing of GPIO signals to +package balls is under the control of a separate pin controller HW block. Two +major sets of registers exist: + +a) Security registers, which allow configuration of allowed access to the GPIO +register set. These registers exist in a single contiguous block of physical +address space. The size of this block, and the security features available, +varies between the different GPIO controllers. + +Access to this set of registers is not necessary in all circumstances. Code +that wishes to configure access to the GPIO registers needs access to these +registers to do so. Code which simply wishes to read or write GPIO data does not +need access to these registers. + +b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO +controllers, these registers are exposed via multiple "physical aliases" in +address space, each of which access the same underlying state. See the hardware +documentation for rationale. Any particular GPIO client is expected to access +just one of these physical aliases. + +Tegra HW documentation describes a unified naming convention for all GPIOs +implemented by the SoC. Each GPIO is assigned to a port, and a port may control +a number of GPIOs. Thus, each GPIO is named according to an alphabetical port +name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6, +or GPIO_PCC3. + +The number of ports implemented by each GPIO controller varies. The number of +implemented GPIOs within each port varies. GPIO registers within a controller +are grouped and laid out according to the port they affect. + +The mapping from port name to the GPIO controller that implements that port, and +the mapping from port name to register offset within a controller, are both +extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h> +describes the port-level mapping. In that file, the naming convention for ports +matches the HW documentation. The values chosen for the names are alphabetically +sorted within a particular controller. Drivers need to map between the DT GPIO +IDs and HW register offsets using a lookup table. + +Each GPIO controller can generate a number of interrupt signals. Each signal +represents the aggregate status for all GPIOs within a set of ports. Thus, the +number of interrupt signals generated by a controller varies as a rough function +of the number of ports it implements. Note that the HW documentation refers to +both the overall controller HW module and the sets-of-ports as "controllers". + +Each GPIO controller in fact generates multiple interrupts signals for each set +of ports. Each GPIO may be configured to feed into a specific one of the +interrupt signals generated by a set-of-ports. The intent is for each generated +signal to be routed to a different CPU, thus allowing different CPUs to each +handle subsets of the interrupts within a port. The status of each of these +per-port-set signals is reported via a separate register. Thus, a driver needs +to know which status register to observe. This binding currently defines no +configuration mechanism for this. By default, drivers should use register +GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could +define a property to configure this. + +Required properties: +- compatible + Array of strings. + One of: + - "nvidia,tegra186-gpio". + - "nvidia,tegra186-gpio-aon". +- reg-names + Array of strings. + Contains a list of names for the register spaces described by the reg + property. May contain the following entries, in any order: + - "gpio": Mandatory. GPIO control registers. This may cover either: + a) The single physical alias that this OS should use. + b) All physical aliases that exist in the controller. This is + appropriate when the OS is responsible for managing assignment of + the physical aliases. + - "security": Optional. Security configuration registers. + Users of this binding MUST look up entries in the reg property by name, + using this reg-names property to do so. +- reg + Array of (physical base address, length) tuples. + Must contain one entry per entry in the reg-names property, in a matching + order. +- interrupts + Array of interrupt specifiers. + The interrupt outputs from the HW block, one per set of ports, in the + order the HW manual describes them. The number of entries required varies + depending on compatible value: + - "nvidia,tegra186-gpio": 6 entries. + - "nvidia,tegra186-gpio-aon": 1 entry. +- gpio-controller + Boolean. + Marks the device node as a GPIO controller/provider. +- #gpio-cells + Single-cell integer. + Must be <2>. + Indicates how many cells are used in a consumer's GPIO specifier. + In the specifier: + - The first cell is the pin number. + See <dt-bindings/gpio/tegra186-gpio.h>. + - The second cell contains flags: + - Bit 0 specifies polarity + - 0: Active-high (normal). + - 1: Active-low (inverted). +- interrupt-controller + Boolean. + Marks the device node as an interrupt controller/provider. +- #interrupt-cells + Single-cell integer. + Must be <2>. + Indicates how many cells are used in a consumer's interrupt specifier. + In the specifier: + - The first cell is the GPIO number. + See <dt-bindings/gpio/tegra186-gpio.h>. + - The second cell is contains flags: + - Bits [3:0] indicate trigger type and level: + - 1: Low-to-high edge triggered. + - 2: High-to-low edge triggered. + - 4: Active high level-sensitive. + - 8: Active low level-sensitive. + Valid combinations are 1, 2, 3, 4, 8. + +Example: + +#include <dt-bindings/interrupt-controller/irq.h> + +gpio@2200000 { + compatible = "nvidia,tegra186-gpio"; + reg-names = "security", "gpio"; + reg = + <0x0 0x2200000 0x0 0x10000>, + <0x0 0x2210000 0x0 0x10000>; + interrupts = + <0 47 IRQ_TYPE_LEVEL_HIGH>, + <0 50 IRQ_TYPE_LEVEL_HIGH>, + <0 53 IRQ_TYPE_LEVEL_HIGH>, + <0 56 IRQ_TYPE_LEVEL_HIGH>, + <0 59 IRQ_TYPE_LEVEL_HIGH>, + <0 180 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; +}; + +gpio@c2f0000 { + compatible = "nvidia,tegra186-gpio-aon"; + reg-names = "security", "gpio"; + reg = + <0x0 0xc2f0000 0x0 0x1000>, + <0x0 0xc2f1000 0x0 0x1000>; + interrupts = + <0 60 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt new file mode 100644 index 000000000..023c9526e --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt @@ -0,0 +1,40 @@ +NVIDIA Tegra GPIO controller + +Required properties: +- compatible : "nvidia,tegra<chip>-gpio" +- reg : Physical base address and length of the controller's registers. +- interrupts : The interrupt outputs from the controller. For Tegra20, + there should be 7 interrupts specified, and for Tegra30, there should + be 8 interrupts specified. +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. +- #interrupt-cells : Should be 2. + The first cell is the GPIO number. + The second cell is used to specify flags: + bits[3:0] trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. + Valid combinations are 1, 2, 3, 4, 8. +- interrupt-controller : Marks the device node as an interrupt controller. + +Example: + +gpio: gpio@6000d000 { + compatible = "nvidia,tegra20-gpio"; + reg = < 0x6000d000 0x1000 >; + interrupts = < 0 32 0x04 + 0 33 0x04 + 0 34 0x04 + 0 35 0x04 + 0 55 0x04 + 0 87 0x04 + 0 89 0x04 >; + #gpio-cells = <2>; + gpio-controller; + #interrupt-cells = <2>; + interrupt-controller; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt new file mode 100644 index 000000000..58185b833 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt @@ -0,0 +1,48 @@ +Driver for part of pm8916 PMIC - gpio and power/reset keys + +This device should be child of SPMI pmic. + +1) GPIO driver + +Required properties: +- compatible: "qcom,pm8916-gpio" +- reg: peripheral ID, size of register block +- gpio-controller +- gpio-count: number of GPIOs +- #gpio-cells: 2 + +Optional properties: +- gpio-bank-name: name of bank (as default "pm8916" is used) + +Example: + +pmic_gpios: gpios@c000 { + compatible = "qcom,pm8916-gpio"; + reg = <0xc000 0x400>; + gpio-controller; + gpio-count = <4>; + #gpio-cells = <2>; + gpio-bank-name="pmic"; +}; + + +2) Power/Reset key driver + +Required properties: +- compatible: "qcom,pm8916-pwrkey" +- reg: peripheral ID, size of register block +- gpio-controller +- #gpio-cells: 2 + +Optional properties: +- gpio-bank-name: name of bank (as default "pm8916_key" is used) + + +Example: + +pmic_pon: pon@800 { + compatible = "qcom,pm8916-pwrkey"; + reg = <0x800 0x96>; + #gpio-cells = <2>; + gpio-controller; +}; diff --git a/roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt b/roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt new file mode 100644 index 000000000..46ceb65c5 --- /dev/null +++ b/roms/u-boot/doc/device-tree-bindings/gpio/snps,creg-gpio.txt @@ -0,0 +1,43 @@ +GPIO via CREG (control registers) driver + +31 9 7 5 0 < bit number +| | | | | +[ not used | gpio-1 | gpio-0 | <-shift-> ] < 32 bit register + ^ ^ + | | + write 0x2 == set output to "1" (activate) + write 0x3 == set output to "0" (deactivate) + +Required properties: +- compatible : "snps,creg-gpio" +- reg : Exactly one register range with length 0x4. +- #gpio-cells : Should be one - the pin number. +- gpio-controller : Marks the device node as a GPIO controller. +- gpio-count: Number of GPIO pins. +- gpio-bit-per-line: Number of bits per gpio line (see picture). +- gpio-first-shift: Shift (in bits) of the first GPIO field in register + (see picture). +- gpio-activate-val: Value should be set in corresponding field to set + output to "1" (see picture). Applied to all GPIO ports. +- gpio-deactivate-val: Value should be set in corresponding field to set + output to "0" (see picture). Applied to all GPIO ports. + +Optional properties: +- gpio-bank-name: name of bank (as default driver name is used is used) +- gpio-default-val: array of default output values (must me 0 or 1) + +Example (see picture): + +gpio: gpio@f00014b0 { + compatible = "snps,creg-gpio"; + reg = <0xf00014b0 0x4>; + gpio-controller; + #gpio-cells = <1>; + gpio-bank-name = "hsdk-spi-cs"; + gpio-count = <2>; + gpio-first-shift = <5>; + gpio-bit-per-line = <2>; + gpio-activate-val = <2>; + gpio-deactivate-val = <3>; + gpio-default-val = <1 1>; +}; |