diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.arm64 | 35 | ||||
| -rw-r--r-- | doc/README.rockchip | 53 | ||||
| -rw-r--r-- | doc/README.x86 | 36 | ||||
| -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 | ||||
| -rw-r--r-- | doc/driver-model/serial-howto.txt | 2 |
12 files changed, 585 insertions, 49 deletions
diff --git a/doc/README.arm64 b/doc/README.arm64 index 75586dbaa70..f32108feb77 100644 --- a/doc/README.arm64 +++ b/doc/README.arm64 @@ -36,11 +36,34 @@ Notes 6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and aarch32 specific codes. +7. CONFIG_SYS_FULL_VA is used to enable 2-level page tables. For cores + supporting 64k pages it allows usage of full 48+ virtual/physical addresses + + Enabling this option requires the following ones to be defined: + - CONFIG_SYS_MEM_MAP - an array of 'struct mm_region' describing the + system memory map (start, length, attributes) + - CONFIG_SYS_MEM_MAP_SIZE - number of entries in CONFIG_SYS_MEM_MAP + - CONFIG_SYS_PTL1_ENTRIES - number of 1st level page table entries + - CONFIG_SYS_PTL2_ENTRIES - number of 1nd level page table entries + for the largest CONFIG_SYS_MEM_MAP entry + - CONFIG_COREID_MASK - the mask value used to get the core from the + MPIDR_EL1 register + - CONFIG_SYS_PTL2_BITS - number of bits addressed by the 2nd level + page tables + - CONFIG_SYS_BLOCK_SHIFT - number of bits addressed by a single block + entry from L2 page tables + - CONFIG_SYS_PGTABLE_SIZE - total size of the page table + - CONFIG_SYS_TCR_EL{1,2,3}_IPS_BITS - the IPS field of the TCR_EL{1,2,3} + + + + Contributor =========== - Tom Rini <trini@ti.com> - Scott Wood <scottwood@freescale.com> - York Sun <yorksun@freescale.com> - Simon Glass <sjg@chromium.org> - Sharma Bhupesh <bhupesh.sharma@freescale.com> - Rob Herring <robherring2@gmail.com> + Tom Rini <trini@ti.com> + Scott Wood <scottwood@freescale.com> + York Sun <yorksun@freescale.com> + Simon Glass <sjg@chromium.org> + Sharma Bhupesh <bhupesh.sharma@freescale.com> + Rob Herring <robherring2@gmail.com> + Sergey Temerkhanov <s.temerkhanov@gmail.com> diff --git a/doc/README.rockchip b/doc/README.rockchip index 9a2ebca95df..e0572c80b9c 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -14,7 +14,7 @@ many Rockchip devices [1] [2]. The current mainline support is experimental only and is not useful for anything. It should provide a base on which to build. -So far only support for the RK3288 is provided. +So far only support for the RK3288 and RK3036 is provided. Prerequisites @@ -22,7 +22,7 @@ Prerequisites You will need: - - Firefly RK3288 baord + - Firefly RK3288 board or something else with a supported RockChip SoC - Power connection to 5V using the supplied micro-USB power cable - Separate USB serial cable attached to your computer and the Firefly (connect to the micro-USB connector below the logo) @@ -39,12 +39,13 @@ Building At present three RK3288 boards are supported: - Firefly RK3288 - use firefly-rk3288 configuration - - Radxa Rock 2 - also uses firefly-rk3288 configuration - - Haier Chromebook - use chromebook_jerry configuration + - Radxa Rock 2 - use rock2 configuration + - Hisense Chromebook - use chromebook_jerry configuration -one RK3036 board is support: +Two RK3036 board are supported: - - EVB RK3036 - use evb-rk3036_defconfig configuration + - EVB RK3036 - use evb-rk3036 configuration + - Kylin - use kylin_rk3036 configuration For example: @@ -52,11 +53,6 @@ For example: (or you can use another cross compiler if you prefer) -Note that the Radxa Rock 2 uses the Firefly configuration for now as -device tree files are not yet available for the Rock 2. Clearly the two -have hardware differences, so this approach will break down as more drivers -are added. - Writing to the board with USB ============================= @@ -108,20 +104,23 @@ corresponds with this setting in U-Boot: Put this SD (or micro-SD) card into your board and reset it. You should see something like: - U-Boot SPL 2015.07-rc1-00383-ge345740-dirty (Jun 03 2015 - 11:04:40) - - - U-Boot 2015.07-rc1-00383-ge345740-dirty (Jun 03 2015 - 11:04:40) + U-Boot 2016.01-rc2-00309-ge5bad3b-dirty (Jan 02 2016 - 23:41:59 -0700) + Model: Radxa Rock 2 Square DRAM: 2 GiB - MMC: - Using default environment - - In: serial@ff690000 - Out: serial@ff690000 - Err: serial@ff690000 + MMC: dwmmc@ff0f0000: 0, dwmmc@ff0c0000: 1 + *** Warning - bad CRC, using default environment + + In: serial + Out: vop@ff940000.vidconsole + Err: serial + Net: Net Initialization Skipped + No ethernet found. + Hit any key to stop autoboot: 0 => +If you have an HDMI cable attached you should see a video console. + For evb_rk3036 board: ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d evb-rk3036/spl/u-boot-spl.bin out && \ cat evb-rk3036/u-boot-dtb.bin >> out && \ @@ -175,13 +174,9 @@ Future work Immediate priorities are: -- GPIO (driver exists but is lightly tested) -- I2C (driver exists but is non-functional) - USB host - USB device -- PMIC and regulators (only ACT8846 is supported at present) -- LCD and HDMI -- Run CPU at full speed +- Run CPU at full speed (code exists but we only see ~60 DMIPS maximum) - Ethernet - NAND flash - Support for other Rockchip parts @@ -243,6 +238,12 @@ SPI flash. See above for instructions on how to write a SPI image. +rkmux.py +-------- + +You can use this script to create #defines for SoC register access. See the +script for usage. + Device tree and driver model ---------------------------- diff --git a/doc/README.x86 b/doc/README.x86 index 1271e5edea3..6d9cb10edc8 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -295,9 +295,37 @@ show QEMU's VGA console window. Note this will disable QEMU's serial output. If you want to check both consoles, use '-serial stdio'. Multicore is also supported by QEMU via '-smp n' where n is the number of cores -to instantiate. Currently the default U-Boot built for QEMU supports 2 cores. -In order to support more cores, you need add additional cpu nodes in the device -tree and change CONFIG_MAX_CPUS accordingly. +to instantiate. Note, the maximum supported CPU number in QEMU is 255. + +The fw_cfg interface in QEMU also provides information about kernel data, initrd, +command-line arguments and more. U-Boot supports directly accessing these informtion +from fw_cfg interface, this saves the time of loading them from hard disk or +network again, through emulated devices. To use it , simply providing them in +QEMU command line: + +$ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 -kernel /path/to/bzImage + -append 'root=/dev/ram console=ttyS0' -initrd /path/to/initrd -smp 8 + +Note: -initrd and -smp are both optional + +Then start QEMU, in U-Boot command line use the following U-Boot command to setup kernel: + + => qfw +qfw - QEMU firmware interface + +Usage: +qfw <command> + - list : print firmware(s) currently loaded + - cpus : print online cpu number + - load <kernel addr> <initrd addr> : load kernel and initrd (if any) and setup for zboot + +=> qfw load +loading kernel to address 01000000 size 5d9d30 initrd 04000000 size 1b1ab50 + +Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then, 'zboot' +can be used to boot the kernel: + +=> zboot 02000000 - 04000000 1b1ab50 CPU Microcode ------------- @@ -678,7 +706,7 @@ the board, then you can use post_code() calls from C or assembler to monitor boot progress. This can be good for debugging. If not, you can try to get serial working as early as possible. The early -debug serial port may be useful here. See setup_early_uart() for an example. +debug serial port may be useful here. See setup_internal_uart() for an example. During the U-Boot porting, one of the important steps is to write correct PIRQ routing information in the board device tree. Without it, device drivers in the diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-bindings/chosen.txt new file mode 100644 index 00000000000..bf9a30a8f97 --- /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 b44b5b5431f..07fa46ef7ef 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 00000000000..b73c96d24f5 --- /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 00000000000..91d5ab0e60f --- /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 ef0b9aee6d0..00000000000 --- 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 00000000000..7a71b5de77d --- /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 00000000000..12bbe9f2256 --- /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 00000000000..d15753c8c38 --- /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>; + }; diff --git a/doc/driver-model/serial-howto.txt b/doc/driver-model/serial-howto.txt index 4706d56ea71..e5e482e30bc 100644 --- a/doc/driver-model/serial-howto.txt +++ b/doc/driver-model/serial-howto.txt @@ -11,12 +11,10 @@ is time for maintainers to start converting over the remaining serial drivers: opencores_yanu.c serial_bfin.c serial_imx.c - serial_lpuart.c serial_max3100.c serial_pxa.c serial_s3c24x0.c serial_sa1100.c - serial_xuartlite.c usbtty.c You should complete this by the end of January 2016. |