diff options
Diffstat (limited to 'doc/device-tree-bindings')
| -rw-r--r-- | doc/device-tree-bindings/chosen.txt | 43 | ||||
| -rw-r--r-- | doc/device-tree-bindings/misc/intel,baytrail-fsp.txt | 31 | ||||
| -rw-r--r-- | doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt | 236 | ||||
| -rw-r--r-- | doc/device-tree-bindings/serial/8250.txt | 66 | ||||
| -rw-r--r-- | doc/device-tree-bindings/serial/ns16550.txt | 10 | ||||
| -rw-r--r-- | doc/device-tree-bindings/serial/omap_serial.txt | 33 | ||||
| -rw-r--r-- | doc/device-tree-bindings/serial/snps-dw-apb-uart.txt | 76 | ||||
| -rw-r--r-- | doc/device-tree-bindings/serial/xilinx_uartlite.txt | 13 |
8 files changed, 497 insertions, 11 deletions
diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-bindings/chosen.txt new file mode 100644 index 0000000000..bf9a30a8f9 --- /dev/null +++ b/doc/device-tree-bindings/chosen.txt @@ -0,0 +1,43 @@ +The chosen node +--------------- +The chosen node does not represent a real device, but serves as a place +for passing data like which serial device to used to print the logs etc + + +stdout-path property +-------------------- +Device trees may specify the device to be used for boot console output +with a stdout-path property under /chosen. + +Example +------- +/ { + chosen { + stdout-path = "/serial@f00:115200"; + }; + + serial@f00 { + compatible = "vendor,some-uart"; + reg = <0xf00 0x10>; + }; +}; + +tick-timer property +------------------- +In a system there are multiple timers, specify which timer to be used +as the tick-timer. Earlier it was hardcoded in the timer driver now +since device tree has all the timer nodes. Specify which timer to be +used as tick timer. + +Example +------- +/ { + chosen { + tick-timer = "/timer2@f00"; + }; + + timer2@f00 { + compatible = "vendor,some-timer"; + reg = <0xf00 0x10>; + }; +}; diff --git a/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt b/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt index b44b5b5431..07fa46ef7e 100644 --- a/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt +++ b/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt @@ -74,12 +74,41 @@ discovered by the FSP and used to setup main memory. # Integer properties: - - fsp,dram-speed + - fsp,dram-speed: + 0x0: "800 MHz" + 0x1: "1066 MHz" + 0x2: "1333 MHz" + 0x3: "1600 MHz" + - fsp,dram-type + 0x0: "DDR3" + 0x1: "DDR3L" + 0x2: "DDR3U" + 0x4: "LPDDR2" + 0x5: "LPDDR3" + 0x6: "DDR4" + - fsp,dimm-width + 0x0: "x8" + 0x1: "x16" + 0x2: "x32" + - fsp,dimm-density + 0x0: "1 Gbit" + 0x1: "2 Gbit" + 0x2: "4 Gbit" + 0x3: "8 Gbit" + - fsp,dimm-bus-width + 0x0: "8 bits" + 0x1: "16 bits" + 0x2: "32 bits" + 0x3: "64 bits" + - fsp,dimm-sides + 0x0: "1 rank" + 0x1: "2 ranks" + - fsp,dimm-tcl - fsp,dimm-trpt-rcd - fsp,dimm-twr diff --git a/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt b/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt new file mode 100644 index 0000000000..b73c96d24f --- /dev/null +++ b/doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt @@ -0,0 +1,236 @@ +== Introduction == + +Hardware modules that control pin multiplexing or configuration parameters +such as pull-up/down, tri-state, drive-strength etc are designated as pin +controllers. Each pin controller must be represented as a node in device tree, +just like any other hardware module. + +Hardware modules whose signals are affected by pin configuration are +designated client devices. Again, each client device must be represented as a +node in device tree, just like any other hardware module. + +For a client device to operate correctly, certain pin controllers must +set up certain specific pin configurations. Some client devices need a +single static pin configuration, e.g. set up during initialization. Others +need to reconfigure pins at run-time, for example to tri-state pins when the +device is inactive. Hence, each client device can define a set of named +states. The number and names of those states is defined by the client device's +own binding. + +The common pinctrl bindings defined in this file provide an infrastructure +for client device device tree nodes to map those state names to the pin +configuration used by those states. + +Note that pin controllers themselves may also be client devices of themselves. +For example, a pin controller may set up its own "active" state when the +driver loads. This would allow representing a board's static pin configuration +in a single place, rather than splitting it across multiple client device +nodes. The decision to do this or not somewhat rests with the author of +individual board device tree files, and any requirements imposed by the +bindings for the individual client devices in use by that board, i.e. whether +they require certain specific named states for dynamic pin configuration. + +== Pinctrl client devices == + +For each client device individually, every pin state is assigned an integer +ID. These numbers start at 0, and are contiguous. For each state ID, a unique +property exists to define the pin configuration. Each state may also be +assigned a name. When names are used, another property exists to map from +those names to the integer IDs. + +Each client device's own binding determines the set of states that must be +defined in its device tree node, and whether to define the set of state +IDs that must be provided, or whether to define the set of state names that +must be provided. + +Required properties: +pinctrl-0: List of phandles, each pointing at a pin configuration + node. These referenced pin configuration nodes must be child + nodes of the pin controller that they configure. Multiple + entries may exist in this list so that multiple pin + controllers may be configured, or so that a state may be built + from multiple nodes for a single pin controller, each + contributing part of the overall configuration. See the next + section of this document for details of the format of these + pin configuration nodes. + + In some cases, it may be useful to define a state, but for it + to be empty. This may be required when a common IP block is + used in an SoC either without a pin controller, or where the + pin controller does not affect the HW module in question. If + the binding for that IP block requires certain pin states to + exist, they must still be defined, but may be left empty. + +Optional properties: +pinctrl-1: List of phandles, each pointing at a pin configuration + node within a pin controller. +... +pinctrl-n: List of phandles, each pointing at a pin configuration + node within a pin controller. +pinctrl-names: The list of names to assign states. List entry 0 defines the + name for integer state ID 0, list entry 1 for state ID 1, and + so on. + +For example: + + /* For a client device requiring named states */ + device { + pinctrl-names = "active", "idle"; + pinctrl-0 = <&state_0_node_a>; + pinctrl-1 = <&state_1_node_a &state_1_node_b>; + }; + + /* For the same device if using state IDs */ + device { + pinctrl-0 = <&state_0_node_a>; + pinctrl-1 = <&state_1_node_a &state_1_node_b>; + }; + + /* + * For an IP block whose binding supports pin configuration, + * but in use on an SoC that doesn't have any pin control hardware + */ + device { + pinctrl-names = "active", "idle"; + pinctrl-0 = <>; + pinctrl-1 = <>; + }; + +== Pin controller devices == + +Pin controller devices should contain the pin configuration nodes that client +devices reference. + +For example: + + pincontroller { + ... /* Standard DT properties for the device itself elided */ + + state_0_node_a { + ... + }; + state_1_node_a { + ... + }; + state_1_node_b { + ... + }; + } + +The contents of each of those pin configuration child nodes is defined +entirely by the binding for the individual pin controller device. There +exists no common standard for this content. + +The pin configuration nodes need not be direct children of the pin controller +device; they may be grandchildren, for example. Whether this is legal, and +whether there is any interaction between the child and intermediate parent +nodes, is again defined entirely by the binding for the individual pin +controller device. + +== Generic pin multiplexing node content == + +pin multiplexing nodes: + +function - the mux function to select +groups - the list of groups to select with this function + (either this or "pins" must be specified) +pins - the list of pins to select with this function (either + this or "groups" must be specified) + +Example: + +state_0_node_a { + uart0 { + function = "uart0"; + groups = "u0rxtx", "u0rtscts"; + }; +}; +state_1_node_a { + spi0 { + function = "spi0"; + groups = "spi0pins"; + }; +}; +state_2_node_a { + function = "i2c0"; + pins = "mfio29", "mfio30"; +}; + +== Generic pin configuration node content == + +Many data items that are represented in a pin configuration node are common +and generic. Pin control bindings should use the properties defined below +where they are applicable; not all of these properties are relevant or useful +for all hardware or binding structures. Each individual binding document +should state which of these generic properties, if any, are used, and the +structure of the DT nodes that contain these properties. + +Supported generic properties are: + +pins - the list of pins that properties in the node + apply to (either this or "group" has to be + specified) +group - the group to apply the properties to, if the driver + supports configuration of whole groups rather than + individual pins (either this or "pins" has to be + specified) +bias-disable - disable any pin bias +bias-high-impedance - high impedance mode ("third-state", "floating") +bias-bus-hold - latch weakly +bias-pull-up - pull up the pin +bias-pull-down - pull down the pin +bias-pull-pin-default - use pin-default pull state +drive-push-pull - drive actively high and low +drive-open-drain - drive with open drain +drive-open-source - drive with open source +drive-strength - sink or source at most X mA +input-enable - enable input on pin (no effect on output) +input-disable - disable input on pin (no effect on output) +input-schmitt-enable - enable schmitt-trigger mode +input-schmitt-disable - disable schmitt-trigger mode +input-debounce - debounce mode with debound time X +power-source - select between different power supplies +low-power-enable - enable low power mode +low-power-disable - disable low power mode +output-low - set the pin to output mode with low level +output-high - set the pin to output mode with high level +slew-rate - set the slew rate + +For example: + +state_0_node_a { + cts_rxd { + pins = "GPIO0_AJ5", "GPIO2_AH4"; /* CTS+RXD */ + bias-pull-up; + }; +}; +state_1_node_a { + rts_txd { + pins = "GPIO1_AJ3", "GPIO3_AH3"; /* RTS+TXD */ + output-high; + }; +}; +state_2_node_a { + foo { + group = "foo-group"; + bias-pull-up; + }; +}; + +Some of the generic properties take arguments. For those that do, the +arguments are described below. + +- pins takes a list of pin names or IDs as a required argument. The specific + binding for the hardware defines: + - Whether the entries are integers or strings, and their meaning. + +- bias-pull-up, -down and -pin-default take as optional argument on hardware + supporting it the pull strength in Ohm. bias-disable will disable the pull. + +- drive-strength takes as argument the target strength in mA. + +- input-debounce takes the debounce time in usec as argument + or 0 to disable debouncing + +More in-depth documentation on these parameters can be found in +<include/linux/pinctrl/pinconf-generic.h> diff --git a/doc/device-tree-bindings/serial/8250.txt b/doc/device-tree-bindings/serial/8250.txt new file mode 100644 index 0000000000..91d5ab0e60 --- /dev/null +++ b/doc/device-tree-bindings/serial/8250.txt @@ -0,0 +1,66 @@ +* UART (Universal Asynchronous Receiver/Transmitter) + +Required properties: +- compatible : one of: + - "ns8250" + - "ns16450" + - "ns16550a" + - "ns16550" + - "ns16750" + - "ns16850" + - For Tegra20, must contain "nvidia,tegra20-uart" + - For other Tegra, must contain '"nvidia,<chip>-uart", + "nvidia,tegra20-uart"' where <chip> is tegra30, tegra114, tegra124, + tegra132, or tegra210. + - "nxp,lpc3220-uart" + - "ralink,rt2880-uart" + - "ibm,qpace-nwp-serial" + - "altr,16550-FIFO32" + - "altr,16550-FIFO64" + - "altr,16550-FIFO128" + - "fsl,16550-FIFO64" + - "fsl,ns16550" + - "serial" if the port type is unknown. +- reg : offset and length of the register set for the device. +- interrupts : should contain uart interrupt. +- clock-frequency : the input clock frequency for the UART + or + clocks phandle to refer to the clk used as per Documentation/devicetree + /bindings/clock/clock-bindings.txt + +Optional properties: +- current-speed : the current active speed of the UART. +- reg-offset : offset to apply to the mapbase from the start of the registers. +- reg-shift : quantity to shift the register offsets by. +- reg-io-width : the size (in bytes) of the IO accesses that should be + performed on the device. There are some systems that require 32-bit + accesses to the UART (e.g. TI davinci). +- used-by-rtas : set to indicate that the port is in use by the OpenFirmware + RTAS and should not be registered. +- no-loopback-test: set to indicate that the port does not implements loopback + test mode +- fifo-size: the fifo size of the UART. +- auto-flow-control: one way to enable automatic flow control support. The + driver is allowed to detect support for the capability even without this + property. + +Note: +* fsl,ns16550: + ------------ + Freescale DUART is very similar to the PC16552D (and to a + pair of NS16550A), albeit with some nonstandard behavior such as + erratum A-004737 (relating to incorrect BRK handling). + + Represents a single port that is compatible with the DUART found + on many Freescale chips (examples include mpc8349, mpc8548, + mpc8641d, p4080 and ls2085a). + +Example: + + uart@80230000 { + compatible = "ns8250"; + reg = <0x80230000 0x100>; + clock-frequency = <3686400>; + interrupts = <10>; + reg-shift = <2>; + }; diff --git a/doc/device-tree-bindings/serial/ns16550.txt b/doc/device-tree-bindings/serial/ns16550.txt deleted file mode 100644 index ef0b9aee6d..0000000000 --- a/doc/device-tree-bindings/serial/ns16550.txt +++ /dev/null @@ -1,10 +0,0 @@ -NS16550 UART - -This UART driver supports many chip variants and is used in mamy SoCs. - -Required properties: -- compatible: "ns16550" or "nvidia,tegra20-uart" -- reg: start address and size of registers -- reg-shift: shift value indicating register size: 0=byte, 1=16bit,2=32bit etc. -- clock-frequency: input clock frequency for the UART (used to calculate the - baud rate divisor) diff --git a/doc/device-tree-bindings/serial/omap_serial.txt b/doc/device-tree-bindings/serial/omap_serial.txt new file mode 100644 index 0000000000..7a71b5de77 --- /dev/null +++ b/doc/device-tree-bindings/serial/omap_serial.txt @@ -0,0 +1,33 @@ +OMAP UART controller + +Required properties: +- compatible : should be "ti,omap2-uart" for OMAP2 controllers +- compatible : should be "ti,omap3-uart" for OMAP3 controllers +- compatible : should be "ti,omap4-uart" for OMAP4 controllers +- compatible : should be "ti,am4372-uart" for AM437x controllers +- compatible : should be "ti,am3352-uart" for AM335x controllers +- compatible : should be "ti,dra742-uart" for DRA7x controllers +- reg : address and length of the register space +- interrupts or interrupts-extended : Should contain the uart interrupt + specifier or both the interrupt + controller phandle and interrupt + specifier. +- ti,hwmods : Must be "uart<n>", n being the instance number (1-based) + +Optional properties: +- clock-frequency : frequency of the clock input to the UART +- dmas : DMA specifier, consisting of a phandle to the DMA controller + node and a DMA channel number. +- dma-names : "rx" for receive channel, "tx" for transmit channel. + +Example: + + uart4: serial@49042000 { + compatible = "ti,omap3-uart"; + reg = <0x49042000 0x400>; + interrupts = <80>; + dmas = <&sdma 81 &sdma 82>; + dma-names = "tx", "rx"; + ti,hwmods = "uart4"; + clock-frequency = <48000000>; + }; diff --git a/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt b/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt new file mode 100644 index 0000000000..12bbe9f225 --- /dev/null +++ b/doc/device-tree-bindings/serial/snps-dw-apb-uart.txt @@ -0,0 +1,76 @@ +* Synopsys DesignWare ABP UART + +Required properties: +- compatible : "snps,dw-apb-uart" +- reg : offset and length of the register set for the device. +- interrupts : should contain uart interrupt. + +Clock handling: +The clock rate of the input clock needs to be supplied by one of +- clock-frequency : the input clock frequency for the UART. +- clocks : phandle to the input clock + +The supplying peripheral clock can also be handled, needing a second property +- clock-names: tuple listing input clock names. + Required elements: "baudclk", "apb_pclk" + +Optional properties: +- snps,uart-16550-compatible : reflects the value of UART_16550_COMPATIBLE + configuration parameter. Define this if your UART does not implement the busy + functionality. +- resets : phandle to the parent reset controller. +- reg-shift : quantity to shift the register offsets by. If this property is + not present then the register offsets are not shifted. +- reg-io-width : the size (in bytes) of the IO accesses that should be + performed on the device. If this property is not present then single byte + accesses are used. +- dcd-override : Override the DCD modem status signal. This signal will always + be reported as active instead of being obtained from the modem status + register. Define this if your serial port does not use this pin. +- dsr-override : Override the DTS modem status signal. This signal will always + be reported as active instead of being obtained from the modem status + register. Define this if your serial port does not use this pin. +- cts-override : Override the CTS modem status signal. This signal will always + be reported as active instead of being obtained from the modem status + register. Define this if your serial port does not use this pin. +- ri-override : Override the RI modem status signal. This signal will always be + reported as inactive instead of being obtained from the modem status register. + Define this if your serial port does not use this pin. + +Example: + + uart@80230000 { + compatible = "snps,dw-apb-uart"; + reg = <0x80230000 0x100>; + clock-frequency = <3686400>; + interrupts = <10>; + reg-shift = <2>; + reg-io-width = <4>; + dcd-override; + dsr-override; + cts-override; + ri-override; + }; + +Example with one clock: + + uart@80230000 { + compatible = "snps,dw-apb-uart"; + reg = <0x80230000 0x100>; + clocks = <&baudclk>; + interrupts = <10>; + reg-shift = <2>; + reg-io-width = <4>; + }; + +Example with two clocks: + + uart@80230000 { + compatible = "snps,dw-apb-uart"; + reg = <0x80230000 0x100>; + clocks = <&baudclk>, <&apb_pclk>; + clock-names = "baudclk", "apb_pclk"; + interrupts = <10>; + reg-shift = <2>; + reg-io-width = <4>; + }; diff --git a/doc/device-tree-bindings/serial/xilinx_uartlite.txt b/doc/device-tree-bindings/serial/xilinx_uartlite.txt new file mode 100644 index 0000000000..d15753c8c3 --- /dev/null +++ b/doc/device-tree-bindings/serial/xilinx_uartlite.txt @@ -0,0 +1,13 @@ +Binding for Xilinx Uartlite Controller + +Required properties: +- compatible : should be "xlnx,xps-uartlite-1.00.a", or "xlnx,opb-uartlite-1.00.b" +- reg: Should contain UART controller registers location and length. +- interrupts: Should contain UART controller interrupts. + +Example: + serial@40600000 { + compatible = "xlnx,xps-uartlite-1.00.a"; + interrupts = <1 0>; + reg = <0x40600000 0x10000>; + }; |