avionic design with actual uboot and tooling
submodule of avionic design uboot bootloader and with included tools to get you started , read readme.md and readme-tk1-loader.md
This commit is contained in:
28
u-boot/doc/device-tree-bindings/gpio/altera_pio.txt
Normal file
28
u-boot/doc/device-tree-bindings/gpio/altera_pio.txt
Normal file
@@ -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
|
||||
22
u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt
Normal file
22
u-boot/doc/device-tree-bindings/gpio/gpio-msm.txt
Normal file
@@ -0,0 +1,22 @@
|
||||
Qualcomm Snapdragon GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "qcom,msm8916-pinctrl" or "qcom,apq8016-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>;
|
||||
};
|
||||
41
u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt
Normal file
41
u-boot/doc/device-tree-bindings/gpio/gpio-samsung.txt
Normal file
@@ -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;
|
||||
};
|
||||
212
u-boot/doc/device-tree-bindings/gpio/gpio.txt
Normal file
212
u-boot/doc/device-tree-bindings/gpio/gpio.txt
Normal file
@@ -0,0 +1,212 @@
|
||||
Specifying GPIO information for devices
|
||||
============================================
|
||||
|
||||
1) gpios property
|
||||
-----------------
|
||||
|
||||
Nodes that makes use of GPIOs should specify them using one or more
|
||||
properties, each containing a 'gpio-list':
|
||||
|
||||
gpio-list ::= <single-gpio> [gpio-list]
|
||||
single-gpio ::= <gpio-phandle> <gpio-specifier>
|
||||
gpio-phandle : phandle to gpio controller node
|
||||
gpio-specifier : Array of #gpio-cells specifying specific gpio
|
||||
(controller specific)
|
||||
|
||||
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.
|
||||
|
||||
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>;
|
||||
};
|
||||
gpio2: gpio2 {
|
||||
gpio-controller
|
||||
#gpio-cells = <1>;
|
||||
};
|
||||
[...]
|
||||
|
||||
enable-gpios = <&gpio2 2>;
|
||||
data-gpios = <&gpio1 12 0>,
|
||||
<&gpio1 13 0>,
|
||||
<&gpio1 14 0>,
|
||||
<&gpio1 15 0>;
|
||||
|
||||
Note that gpio-specifier length is controller dependent. In the
|
||||
above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2
|
||||
only uses one.
|
||||
|
||||
gpio-specifier may encode: bank, pin position inside the bank,
|
||||
whether pin is open-drain and whether pin is logically inverted.
|
||||
Exact meaning of each specifier cell is controller specific, and must
|
||||
be documented in the device tree binding for the device. 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.
|
||||
|
||||
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.
|
||||
|
||||
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 useful to represent which GPIOs correspond to which pins on which pin
|
||||
controllers. The gpio-ranges property described below represents this, and
|
||||
contains information structures as follows:
|
||||
|
||||
gpio-range-list ::= <single-gpio-range> [gpio-range-list]
|
||||
single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range>
|
||||
numeric-gpio-range ::=
|
||||
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
|
||||
named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
|
||||
pinctrl-phandle : phandle to pin controller node
|
||||
gpio-base : Base GPIO ID in the GPIO controller
|
||||
pinctrl-base : Base pinctrl pin ID in the pin controller
|
||||
count : The number of GPIOs/pins in this range
|
||||
|
||||
The "pin controller node" mentioned above must conform to the bindings
|
||||
described in ../pinctrl/pinctrl-bindings.txt.
|
||||
|
||||
In case named gpio ranges are used (ranges with both <pinctrl-base> and
|
||||
<count> set to 0), the property gpio-ranges-group-names contains one string
|
||||
for every single-gpio-range in gpio-ranges:
|
||||
gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list]
|
||||
gpiorange-name : Name of the pingroup associated to the GPIO range in
|
||||
the respective pin controller.
|
||||
|
||||
Elements of gpiorange-names-list corresponding to numeric ranges contain
|
||||
the empty string. Elements of gpiorange-names-list corresponding to named
|
||||
ranges contain the name of a pin group defined in the respective pin
|
||||
controller. The number of pins/GPIOs in the range is the number of pins in
|
||||
that pin group.
|
||||
|
||||
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.
|
||||
|
||||
Example 1:
|
||||
|
||||
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..19 routed to pin controller pinctrl2's
|
||||
pins 50..59.
|
||||
|
||||
Example 2:
|
||||
|
||||
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 wrt. two pin controllers. pinctrl1 GPIO
|
||||
ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
|
||||
are named "foo" and "bar".
|
||||
@@ -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 */
|
||||
};
|
||||
};
|
||||
33
u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
Normal file
33
u-boot/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
Normal file
@@ -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>;
|
||||
};
|
||||
161
u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt
Normal file
161
u-boot/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt
Normal file
@@ -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>;
|
||||
};
|
||||
40
u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt
Normal file
40
u-boot/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt
Normal file
@@ -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;
|
||||
};
|
||||
48
u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt
Normal file
48
u-boot/doc/device-tree-bindings/gpio/pm8916_gpio.txt
Normal file
@@ -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;
|
||||
};
|
||||
Reference in New Issue
Block a user