Linux 4.14-rc2 * tag 'v4.14-rc2': (12066 commits) Linux 4.14-rc2 tpm: ibmvtpm: simplify crq initialization and document crq format tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers Documentation: tpm: add powered-while-suspended binding documentation tpm: tpm_crb: constify acpi_device_id. tpm: vtpm: constify vio_device_id security: fix description of values returned by cap_inode_need_killpriv x86/asm: Fix inline asm call constraints for Clang objtool: Handle another GCC stack pointer adjustment bug inet: fix improper empty comparison net: use inet6_rcv_saddr to compare sockets net: set tb->fast_sk_family net: orphan frags on stand-alone ptype in dev_queue_xmit_nit MAINTAINERS: update git tree locations for ieee802154 subsystem SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags SMB3: handle new statx fields arch: remove unused *_segments() macros/functions parisc: Unbreak bootloader due to gcc-7 optimizations parisc: Reintroduce option to gzip-compress the kernel apparmor: fix apparmorfs DAC access permissions ...
Unified · Split
| @@ -2090,7 +2090,7 @@ S: Kuala Lumpur, Malaysia · 2089 unmodified lines | ||
| 2090 | 2090 | |
| 2091 | 2091 | N: Mohit Kumar |
| 2092 | 2092 | D: ST Microelectronics SPEAr13xx PCI host bridge driver |
| 2093 | −D: Synopsys Designware PCI host bridge driver | |
| 2093 | +D: Synopsys DesignWare PCI host bridge driver | |
| 2094 | 2094 | |
| 2095 | 2095 | N: Gabor Kuti |
| 2096 | 2096 | E: seasons@falcon.sch.bme.hu |
| @@ -2606,11 +2606,9 @@ E: tmolina@cablespeed.com · 509 unmodified lines | ||
| 2606 | 2606 | D: bug fixes, documentation, minor hackery |
| 2607 | 2607 | |
| 2608 | 2608 | N: Paul Moore |
| 2609 | −E: paul.moore@hp.com | |
| 2610 | −D: NetLabel author | |
| 2611 | −S: Hewlett-Packard | |
| 2612 | −S: 110 Spit Brook Road | |
| 2613 | −S: Nashua, NH 03062 | |
| 2609 | +E: paul@paul-moore.com | |
| 2610 | +W: http://www.paul-moore.com | |
| 2611 | +D: NetLabel, SELinux, audit | |
| 2614 | 2612 | |
| 2615 | 2613 | N: James Morris |
| 2616 | 2614 | E: jmorris@namei.org |
| @@ -0,0 +1,19 @@ | ||
| 1 | +What: /sys/bus/nvmem/devices/.../nvmem | |
| 2 | +Date: July 2015 | |
| 3 | +KernelVersion: 4.2 | |
| 4 | +Contact: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> | |
| 5 | +Description: | |
| 6 | + This file allows user to read/write the raw NVMEM contents. | |
| 7 | + Permissions for write to this file depends on the nvmem | |
| 8 | + provider configuration. | |
| 9 | + | |
| 10 | + ex: | |
| 11 | + hexdump /sys/bus/nvmem/devices/qfprom0/nvmem | |
| 12 | + | |
| 13 | + 0000000 0000 0000 0000 0000 0000 0000 0000 0000 | |
| 14 | + * | |
| 15 | + 00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00 | |
| 16 | + 0000000 0000 0000 0000 0000 0000 0000 0000 0000 | |
| 17 | + ... | |
| 18 | + * | |
| 19 | + 0001000 | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/cap | |
| 2 | +Date: December 3, 2009 | |
| 3 | +KernelVersion: 2.6.32 | |
| 4 | +Contact: dmaengine@vger.kernel.org | |
| 5 | +Description: Capabilities the DMA supports.Currently there are DMA_PQ, DMA_PQ_VAL, | |
| 6 | + DMA_XOR,DMA_XOR_VAL,DMA_INTERRUPT. | |
| 7 | + | |
| 8 | +What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_active | |
| 9 | +Date: December 3, 2009 | |
| 10 | +KernelVersion: 2.6.32 | |
| 11 | +Contact: dmaengine@vger.kernel.org | |
| 12 | +Description: The number of descriptors active in the ring. | |
| 13 | + | |
| 14 | +What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_size | |
| 15 | +Date: December 3, 2009 | |
| 16 | +KernelVersion: 2.6.32 | |
| 17 | +Contact: dmaengine@vger.kernel.org | |
| 18 | +Description: Descriptor ring size, total number of descriptors available. | |
| 19 | + | |
| 20 | +What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/version | |
| 21 | +Date: December 3, 2009 | |
| 22 | +KernelVersion: 2.6.32 | |
| 23 | +Contact: dmaengine@vger.kernel.org | |
| 24 | +Description: Version of ioatdma device. | |
| 25 | + | |
| 26 | +What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/intr_coalesce | |
| 27 | +Date: August 8, 2017 | |
| 28 | +KernelVersion: 4.14 | |
| 29 | +Contact: dmaengine@vger.kernel.org | |
| 30 | +Description: Tune-able interrupt delay value per channel basis. | |
| @@ -12,3 +12,6 @@ Description: · 11 unmodified lines | ||
| 12 | 12 | Ethernet over USB link |
| 13 | 13 | dev_addr - MAC address of device's end of this |
| 14 | 14 | Ethernet over USB link |
| 15 | + class - USB interface class, default is 02 (hex) | |
| 16 | + subclass - USB interface subclass, default is 06 (hex) | |
| 17 | + protocol - USB interface protocol, default is 00 (hex) | |
| @@ -0,0 +1,45 @@ | ||
| 1 | +What: /sys/kernel/debug/powerpc/memtrace | |
| 2 | +Date: Aug 2017 | |
| 3 | +KernelVersion: 4.14 | |
| 4 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 5 | +Description: This folder contains the relevant debugfs files for the | |
| 6 | + hardware trace macro to use. CONFIG_PPC64_HARDWARE_TRACING | |
| 7 | + must be set. | |
| 8 | + | |
| 9 | +What: /sys/kernel/debug/powerpc/memtrace/enable | |
| 10 | +Date: Aug 2017 | |
| 11 | +KernelVersion: 4.14 | |
| 12 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 13 | +Description: Write an integer containing the size in bytes of the memory | |
| 14 | + you want removed from each NUMA node to this file - it must be | |
| 15 | + aligned to the memblock size. This amount of RAM will be removed | |
| 16 | + from the kernel mappings and the following debugfs files will be | |
| 17 | + created. This can only be successfully done once per boot. Once | |
| 18 | + memory is successfully removed from each node, the following | |
| 19 | + files are created. | |
| 20 | + | |
| 21 | +What: /sys/kernel/debug/powerpc/memtrace/<node-id> | |
| 22 | +Date: Aug 2017 | |
| 23 | +KernelVersion: 4.14 | |
| 24 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 25 | +Description: This directory contains information about the removed memory | |
| 26 | + from the specific NUMA node. | |
| 27 | + | |
| 28 | +What: /sys/kernel/debug/powerpc/memtrace/<node-id>/size | |
| 29 | +Date: Aug 2017 | |
| 30 | +KernelVersion: 4.14 | |
| 31 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 32 | +Description: This contains the size of the memory removed from the node. | |
| 33 | + | |
| 34 | +What: /sys/kernel/debug/powerpc/memtrace/<node-id>/start | |
| 35 | +Date: Aug 2017 | |
| 36 | +KernelVersion: 4.14 | |
| 37 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 38 | +Description: This contains the start address of the removed memory. | |
| 39 | + | |
| 40 | +What: /sys/kernel/debug/powerpc/memtrace/<node-id>/trace | |
| 41 | +Date: Aug 2017 | |
| 42 | +KernelVersion: 4.14 | |
| 43 | +Contact: linuxppc-dev@lists.ozlabs.org | |
| 44 | +Description: This is where the hardware trace macro will output the trace | |
| 45 | + it generates. | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +What: /proc/pid/smaps_rollup | |
| 2 | +Date: August 2017 | |
| 3 | +Contact: Daniel Colascione <dancol@google.com> | |
| 4 | +Description: | |
| 5 | + This file provides pre-summed memory information for a | |
| 6 | + process. The format is identical to /proc/pid/smaps, | |
| 7 | + except instead of an entry for each VMA in a process, | |
| 8 | + smaps_rollup has a single entry (tagged "[rollup]") | |
| 9 | + for which each field is the sum of the corresponding | |
| 10 | + fields from all the maps in /proc/pid/smaps. | |
| 11 | + For more details, see the procfs man page. | |
| 12 | + | |
| 13 | + Typical output looks like this: | |
| 14 | + | |
| 15 | + 00100000-ff709000 ---p 00000000 00:00 0 [rollup] | |
| 16 | + Rss: 884 kB | |
| 17 | + Pss: 385 kB | |
| 18 | + Shared_Clean: 696 kB | |
| 19 | + Shared_Dirty: 0 kB | |
| 20 | + Private_Clean: 120 kB | |
| 21 | + Private_Dirty: 68 kB | |
| 22 | + Referenced: 884 kB | |
| 23 | + Anonymous: 68 kB | |
| 24 | + LazyFree: 0 kB | |
| 25 | + AnonHugePages: 0 kB | |
| 26 | + ShmemPmdMapped: 0 kB | |
| 27 | + Shared_Hugetlb: 0 kB | |
| 28 | + Private_Hugetlb: 0 kB | |
| 29 | + Swap: 0 kB | |
| 30 | + SwapPss: 0 kB | |
| 31 | + Locked: 385 kB | |
| @@ -90,3 +90,11 @@ Description: · 89 unmodified lines | ||
| 90 | 90 | device's debugging info useful for kernel developers. Its |
| 91 | 91 | format is not documented intentionally and may change |
| 92 | 92 | anytime without any notice. |
| 93 | + | |
| 94 | +What: /sys/block/zram<id>/backing_dev | |
| 95 | +Date: June 2017 | |
| 96 | +Contact: Minchan Kim <minchan@kernel.org> | |
| 97 | +Description: | |
| 98 | + The backing_dev file is read-write and set up backing | |
| 99 | + device for zram to write incompressible pages. | |
| 100 | + For using, user should enable CONFIG_ZRAM_WRITEBACK. | |
| @@ -119,6 +119,15 @@ Description: · 118 unmodified lines | ||
| 119 | 119 | unique to allow association with event codes. Units after |
| 120 | 120 | application of scale and offset are milliamps. |
| 121 | 121 | |
| 122 | +What: /sys/bus/iio/devices/iio:deviceX/in_powerY_raw | |
| 123 | +KernelVersion: 4.5 | |
| 124 | +Contact: linux-iio@vger.kernel.org | |
| 125 | +Description: | |
| 126 | + Raw (unscaled no bias removal etc.) power measurement from | |
| 127 | + channel Y. The number must always be specified and | |
| 128 | + unique to allow association with event codes. Units after | |
| 129 | + application of scale and offset are milliwatts. | |
| 130 | + | |
| 122 | 131 | What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw |
| 123 | 132 | KernelVersion: 3.2 |
| 124 | 133 | Contact: linux-iio@vger.kernel.org |
| @@ -0,0 +1,57 @@ | ||
| 1 | +What: /sys/bus/iio/devices/iio:deviceX/in_count0_preset | |
| 2 | +KernelVersion: 4.13 | |
| 3 | +Contact: fabrice.gasnier@st.com | |
| 4 | +Description: | |
| 5 | + Reading returns the current preset value. Writing sets the | |
| 6 | + preset value. Encoder counts continuously from 0 to preset | |
| 7 | + value, depending on direction (up/down). | |
| 8 | + | |
| 9 | +What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available | |
| 10 | +KernelVersion: 4.13 | |
| 11 | +Contact: fabrice.gasnier@st.com | |
| 12 | +Description: | |
| 13 | + Reading returns the list possible quadrature modes. | |
| 14 | + | |
| 15 | +What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode | |
| 16 | +KernelVersion: 4.13 | |
| 17 | +Contact: fabrice.gasnier@st.com | |
| 18 | +Description: | |
| 19 | + Configure the device counter quadrature modes: | |
| 20 | + - non-quadrature: | |
| 21 | + Encoder IN1 input servers as the count input (up | |
| 22 | + direction). | |
| 23 | + - quadrature: | |
| 24 | + Encoder IN1 and IN2 inputs are mixed to get direction | |
| 25 | + and count. | |
| 26 | + | |
| 27 | +What: /sys/bus/iio/devices/iio:deviceX/in_count_polarity_available | |
| 28 | +KernelVersion: 4.13 | |
| 29 | +Contact: fabrice.gasnier@st.com | |
| 30 | +Description: | |
| 31 | + Reading returns the list possible active edges. | |
| 32 | + | |
| 33 | +What: /sys/bus/iio/devices/iio:deviceX/in_count0_polarity | |
| 34 | +KernelVersion: 4.13 | |
| 35 | +Contact: fabrice.gasnier@st.com | |
| 36 | +Description: | |
| 37 | + Configure the device encoder/counter active edge: | |
| 38 | + - rising-edge | |
| 39 | + - falling-edge | |
| 40 | + - both-edges | |
| 41 | + | |
| 42 | + In non-quadrature mode, device counts up on active edge. | |
| 43 | + In quadrature mode, encoder counting scenarios are as follows: | |
| 44 | + ---------------------------------------------------------------- | |
| 45 | + | Active | Level on | IN1 signal | IN2 signal | | |
| 46 | + | edge | opposite |------------------------------------------ | |
| 47 | + | | signal | Rising | Falling | Rising | Falling | | |
| 48 | + ---------------------------------------------------------------- | |
| 49 | + | Rising | High -> | Down | - | Up | - | | |
| 50 | + | edge | Low -> | Up | - | Down | - | | |
| 51 | + ---------------------------------------------------------------- | |
| 52 | + | Falling | High -> | - | Up | - | Down | | |
| 53 | + | edge | Low -> | - | Down | - | Up | | |
| 54 | + ---------------------------------------------------------------- | |
| 55 | + | Both | High -> | Down | Up | Up | Down | | |
| 56 | + | edges | Low -> | Up | Down | Down | Up | | |
| 57 | + ---------------------------------------------------------------- | |
| @@ -45,6 +45,8 @@ Contact: thunderbolt-software@lists.01.org · 44 unmodified lines | ||
| 45 | 45 | Description: When a devices supports Thunderbolt secure connect it will |
| 46 | 46 | have this attribute. Writing 32 byte hex string changes |
| 47 | 47 | authorization to use the secure connection method instead. |
| 48 | + Writing an empty string clears the key and regular connection | |
| 49 | + method can be used again. | |
| 48 | 50 | |
| 49 | 51 | What: /sys/bus/thunderbolt/devices/.../device |
| 50 | 52 | Date: Sep 2017 |
| @@ -45,3 +45,16 @@ Contact: Pratyush Anand <pratyush.anand@gmail.com> · 44 unmodified lines | ||
| 45 | 45 | Description: |
| 46 | 46 | Write to this node to issue "U3 exit" for Link Layer |
| 47 | 47 | Validation device. It is needed for TD.7.36. |
| 48 | + | |
| 49 | +What: /sys/bus/usb/devices/.../enable_compliance | |
| 50 | +Date: July 2017 | |
| 51 | +Description: | |
| 52 | + Write to this node to set the port to compliance mode to test | |
| 53 | + with Link Layer Validation device. It is needed for TD.7.34. | |
| 54 | + | |
| 55 | +What: /sys/bus/usb/devices/.../warm_reset | |
| 56 | +Date: July 2017 | |
| 57 | +Description: | |
| 58 | + Write to this node to issue "Warm Reset" for Link Layer Validation | |
| 59 | + device. It may be needed to properly reset an xHCI 1.1 host port if | |
| 60 | + compliance mode needed to be explicitly enabled. | |
| @@ -0,0 +1,8 @@ | ||
| 1 | +What: /sys/bus/pci/drivers/altera-cvp/chkcfg | |
| 2 | +Date: May 2017 | |
| 3 | +Kernel Version: 4.13 | |
| 4 | +Contact: Anatolij Gustschin <agust@denx.de> | |
| 5 | +Description: | |
| 6 | + Contains either 1 or 0 and controls if configuration | |
| 7 | + error checking in altera-cvp driver is turned on or | |
| 8 | + off. | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +What: /sys/firmware/opal/powercap | |
| 2 | +Date: August 2017 | |
| 3 | +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> | |
| 4 | +Description: Powercap directory for Powernv (P8, P9) servers | |
| 5 | + | |
| 6 | + Each folder in this directory contains a | |
| 7 | + power-cappable component. | |
| 8 | + | |
| 9 | +What: /sys/firmware/opal/powercap/system-powercap | |
| 10 | + /sys/firmware/opal/powercap/system-powercap/powercap-min | |
| 11 | + /sys/firmware/opal/powercap/system-powercap/powercap-max | |
| 12 | + /sys/firmware/opal/powercap/system-powercap/powercap-current | |
| 13 | +Date: August 2017 | |
| 14 | +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> | |
| 15 | +Description: System powercap directory and attributes applicable for | |
| 16 | + Powernv (P8, P9) servers | |
| 17 | + | |
| 18 | + This directory provides powercap information. It | |
| 19 | + contains below sysfs attributes: | |
| 20 | + | |
| 21 | + - powercap-min : This file provides the minimum | |
| 22 | + possible powercap in Watt units | |
| 23 | + | |
| 24 | + - powercap-max : This file provides the maximum | |
| 25 | + possible powercap in Watt units | |
| 26 | + | |
| 27 | + - powercap-current : This file provides the current | |
| 28 | + powercap set on the system. Writing to this file | |
| 29 | + creates a request for setting a new-powercap. The | |
| 30 | + powercap requested must be between powercap-min | |
| 31 | + and powercap-max. | |
| @@ -0,0 +1,18 @@ | ||
| 1 | +What: /sys/firmware/opal/psr | |
| 2 | +Date: August 2017 | |
| 3 | +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> | |
| 4 | +Description: Power-Shift-Ratio directory for Powernv P9 servers | |
| 5 | + | |
| 6 | + Power-Shift-Ratio allows to provide hints the firmware | |
| 7 | + to shift/throttle power between different entities in | |
| 8 | + the system. Each attribute in this directory indicates | |
| 9 | + a settable PSR. | |
| 10 | + | |
| 11 | +What: /sys/firmware/opal/psr/cpu_to_gpu_X | |
| 12 | +Date: August 2017 | |
| 13 | +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> | |
| 14 | +Description: PSR sysfs attributes for Powernv P9 servers | |
| 15 | + | |
| 16 | + Power-Shift-Ratio between CPU and GPU for a given chip | |
| 17 | + with chip-id X. This file gives the ratio (0-100) | |
| 18 | + which is used by OCC for power-capping. | |
| @@ -57,6 +57,15 @@ Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> · 56 unmodified lines | ||
| 57 | 57 | Description: |
| 58 | 58 | Controls the issue rate of small discard commands. |
| 59 | 59 | |
| 60 | +What: /sys/fs/f2fs/<disk>/discard_granularity | |
| 61 | +Date: July 2017 | |
| 62 | +Contact: "Chao Yu" <yuchao0@huawei.com> | |
| 63 | +Description: | |
| 64 | + Controls discard granularity of inner discard thread, inner thread | |
| 65 | + will not issue discards with size that is smaller than granularity. | |
| 66 | + The unit size is one block, now only support configuring in range | |
| 67 | + of [1, 512]. | |
| 68 | + | |
| 60 | 69 | What: /sys/fs/f2fs/<disk>/max_victim_search |
| 61 | 70 | Date: January 2014 |
| 62 | 71 | Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> |
| @@ -130,3 +139,15 @@ Date: June 2017 · 67 unmodified lines | ||
| 130 | 139 | Contact: "Chao Yu" <yuchao0@huawei.com> |
| 131 | 140 | Description: |
| 132 | 141 | Controls current reserved blocks in system. |
| 142 | + | |
| 143 | +What: /sys/fs/f2fs/<disk>/gc_urgent | |
| 144 | +Date: August 2017 | |
| 145 | +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> | |
| 146 | +Description: | |
| 147 | + Do background GC agressively | |
| 148 | + | |
| 149 | +What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time | |
| 150 | +Date: August 2017 | |
| 151 | +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> | |
| 152 | +Description: | |
| 153 | + Controls sleep time of GC urgent mode | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +What: /sys/kernel/mm/swap/ | |
| 2 | +Date: August 2017 | |
| 3 | +Contact: Linux memory management mailing list <linux-mm@kvack.org> | |
| 4 | +Description: Interface for swapping | |
| 5 | + | |
| 6 | +What: /sys/kernel/mm/swap/vma_ra_enabled | |
| 7 | +Date: August 2017 | |
| 8 | +Contact: Linux memory management mailing list <linux-mm@kvack.org> | |
| 9 | +Description: Enable/disable VMA based swap readahead. | |
| 10 | + | |
| 11 | + If set to true, the VMA based swap readahead algorithm | |
| 12 | + will be used for swappable anonymous pages mapped in a | |
| 13 | + VMA, and the global swap readahead algorithm will be | |
| 14 | + still used for tmpfs etc. other users. If set to | |
| 15 | + false, the global swap readahead algorithm will be | |
| 16 | + used for all swappable pages. | |
| 17 | + | |
| 18 | +What: /sys/kernel/mm/swap/vma_ra_max_order | |
| 19 | +Date: August 2017 | |
| 20 | +Contact: Linux memory management mailing list <linux-mm@kvack.org> | |
| 21 | +Description: The max readahead size in order for VMA based swap readahead | |
| 22 | + | |
| 23 | + VMA based swap readahead algorithm will readahead at | |
| 24 | + most 1 << max_order pages for each readahead. The | |
| 25 | + real readahead size for each readahead will be scaled | |
| 26 | + according to the estimation algorithm. | |
| @@ -273,3 +273,15 @@ Description: · 272 unmodified lines | ||
| 273 | 273 | |
| 274 | 274 | This output is useful for system wakeup diagnostics of spurious |
| 275 | 275 | wakeup interrupts. |
| 276 | + | |
| 277 | +What: /sys/power/pm_debug_messages | |
| 278 | +Date: July 2017 | |
| 279 | +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> | |
| 280 | +Description: | |
| 281 | + The /sys/power/pm_debug_messages file controls the printing | |
| 282 | + of debug messages from the system suspend/hiberbation | |
| 283 | + infrastructure to the kernel log. | |
| 284 | + | |
| 285 | + Writing a "1" to this file enables the debug messages and | |
| 286 | + writing a "0" (default) to it disables them. Reads from | |
| 287 | + this file return the current value. | |
| @@ -515,14 +515,15 @@ API at all. · 514 unmodified lines | ||
| 515 | 515 | :: |
| 516 | 516 | |
| 517 | 517 | void * |
| 518 | − dma_alloc_noncoherent(struct device *dev, size_t size, | |
| 519 | − dma_addr_t *dma_handle, gfp_t flag) | |
| 518 | + dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle, | |
| 519 | + gfp_t flag, unsigned long attrs) | |
| 520 | 520 | |
| 521 | −Identical to dma_alloc_coherent() except that the platform will | |
| 522 | −choose to return either consistent or non-consistent memory as it sees | |
| 523 | −fit. By using this API, you are guaranteeing to the platform that you | |
| 524 | −have all the correct and necessary sync points for this memory in the | |
| 525 | −driver should it choose to return non-consistent memory. | |
| 521 | +Identical to dma_alloc_coherent() except that when the | |
| 522 | +DMA_ATTR_NON_CONSISTENT flags is passed in the attrs argument, the | |
| 523 | +platform will choose to return either consistent or non-consistent memory | |
| 524 | +as it sees fit. By using this API, you are guaranteeing to the platform | |
| 525 | +that you have all the correct and necessary sync points for this memory | |
| 526 | +in the driver should it choose to return non-consistent memory. | |
| 526 | 527 | |
| 527 | 528 | Note: where the platform can return consistent memory, it will |
| 528 | 529 | guarantee that the sync points become nops. |
| @@ -535,12 +536,13 @@ that simply cannot make consistent memory. · 6 unmodified lines | ||
| 535 | 536 | :: |
| 536 | 537 | |
| 537 | 538 | void |
| 538 | − dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr, | |
| 539 | − dma_addr_t dma_handle) | |
| 539 | + dma_free_attrs(struct device *dev, size_t size, void *cpu_addr, | |
| 540 | + dma_addr_t dma_handle, unsigned long attrs) | |
| 540 | 541 | |
| 541 | −Free memory allocated by the nonconsistent API. All parameters must | |
| 542 | −be identical to those passed in (and returned by | |
| 543 | −dma_alloc_noncoherent()). | |
| 542 | +Free memory allocated by the dma_alloc_attrs(). All parameters common | |
| 543 | +parameters must identical to those otherwise passed to dma_fre_coherent, | |
| 544 | +and the attrs argument must be identical to the attrs passed to | |
| 545 | +dma_alloc_attrs(). | |
| 544 | 546 | |
| 545 | 547 | :: |
| 546 | 548 | |
| @@ -564,8 +566,8 @@ memory or doing partial flushes. · 17 unmodified lines | ||
| 564 | 566 | dma_cache_sync(struct device *dev, void *vaddr, size_t size, |
| 565 | 567 | enum dma_data_direction direction) |
| 566 | 568 | |
| 567 | −Do a partial sync of memory that was allocated by | |
| 568 | −dma_alloc_noncoherent(), starting at virtual address vaddr and | |
| 569 | +Do a partial sync of memory that was allocated by dma_alloc_attrs() with | |
| 570 | +the DMA_ATTR_NON_CONSISTENT flag starting at virtual address vaddr and | |
| 569 | 571 | continuing on for size. Again, you *must* observe the cache line |
| 570 | 572 | boundaries when doing this. |
| 571 | 573 | |
| @@ -590,34 +592,11 @@ size is the size of the area (must be multiples of PAGE_SIZE). · 18 unmodified lines | ||
| 590 | 592 | |
| 591 | 593 | flags can be ORed together and are: |
| 592 | 594 | |
| 593 | −- DMA_MEMORY_MAP - request that the memory returned from | |
| 594 | − dma_alloc_coherent() be directly writable. | |
| 595 | − | |
| 596 | −- DMA_MEMORY_IO - request that the memory returned from | |
| 597 | − dma_alloc_coherent() be addressable using read()/write()/memcpy_toio() etc. | |
| 598 | − | |
| 599 | −One or both of these flags must be present. | |
| 600 | − | |
| 601 | −- DMA_MEMORY_INCLUDES_CHILDREN - make the declared memory be allocated by | |
| 602 | − dma_alloc_coherent of any child devices of this one (for memory residing | |
| 603 | − on a bridge). | |
| 604 | − | |
| 605 | 595 | - DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. |
| 606 | 596 | Do not allow dma_alloc_coherent() to fall back to system memory when |
| 607 | 597 | it's out of memory in the declared region. |
| 608 | 598 | |
| 609 | −The return value will be either DMA_MEMORY_MAP or DMA_MEMORY_IO and | |
| 610 | −must correspond to a passed in flag (i.e. no returning DMA_MEMORY_IO | |
| 611 | −if only DMA_MEMORY_MAP were passed in) for success or zero for | |
| 612 | −failure. | |
| 613 | − | |
| 614 | −Note, for DMA_MEMORY_IO returns, all subsequent memory returned by | |
| 615 | −dma_alloc_coherent() may no longer be accessed directly, but instead | |
| 616 | −must be accessed using the correct bus functions. If your driver | |
| 617 | −isn't prepared to handle this contingency, it should not specify | |
| 618 | −DMA_MEMORY_IO in the input flags. | |
| 619 | − | |
| 620 | −As a simplification for the platforms, only **one** such region of | |
| 599 | +As a simplification for the platforms, only *one* such region of | |
| 621 | 600 | memory may be declared per device. |
| 622 | 601 | |
| 623 | 602 | For reasons of efficiency, most platforms choose to track the declared |
| @@ -22,6 +22,8 @@ ifeq ($(HAVE_SPHINX),0) · 21 unmodified lines | ||
| 22 | 22 | |
| 23 | 23 | .DEFAULT: |
| 24 | 24 | $(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.) |
| 25 | + @echo | |
| 26 | + @./scripts/sphinx-pre-install | |
| 25 | 27 | @echo " SKIP Sphinx $@ target." |
| 26 | 28 | |
| 27 | 29 | else # HAVE_SPHINX |
| @@ -95,16 +97,6 @@ endif # HAVE_SPHINX · 67 unmodified lines | ||
| 95 | 97 | # The following targets are independent of HAVE_SPHINX, and the rules should |
| 96 | 98 | # work or silently pass without Sphinx. |
| 97 | 99 | |
| 98 | −# no-ops for the Sphinx toolchain | |
| 99 | −sgmldocs: | |
| 100 | − @: | |
| 101 | −psdocs: | |
| 102 | − @: | |
| 103 | −mandocs: | |
| 104 | − @: | |
| 105 | −installmandocs: | |
| 106 | − @: | |
| 107 | − | |
| 108 | 100 | cleandocs: |
| 109 | 101 | $(Q)rm -rf $(BUILDDIR) |
| 110 | 102 | $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean |
| @@ -2080,6 +2080,8 @@ Some of the relevant points of interest are as follows: · 2079 unmodified lines | ||
| 2080 | 2080 | <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>. |
| 2081 | 2081 | <li> <a href="#Tracing and RCU">Tracing and RCU</a>. |
| 2082 | 2082 | <li> <a href="#Energy Efficiency">Energy Efficiency</a>. |
| 2083 | +<li> <a href="#Scheduling-Clock Interrupts and RCU"> | |
| 2084 | + Scheduling-Clock Interrupts and RCU</a>. | |
| 2083 | 2085 | <li> <a href="#Memory Efficiency">Memory Efficiency</a>. |
| 2084 | 2086 | <li> <a href="#Performance, Scalability, Response Time, and Reliability"> |
| 2085 | 2087 | Performance, Scalability, Response Time, and Reliability</a>. |
| @@ -2532,6 +2534,134 @@ I learned of many of these requirements via angry phone calls: · 446 unmodified lines | ||
| 2532 | 2534 | Flaming me on the Linux-kernel mailing list was apparently not |
| 2533 | 2535 | sufficient to fully vent their ire at RCU's energy-efficiency bugs! |
| 2534 | 2536 | |
| 2537 | +<h3><a name="Scheduling-Clock Interrupts and RCU"> | |
| 2538 | +Scheduling-Clock Interrupts and RCU</a></h3> | |
| 2539 | + | |
| 2540 | +<p> | |
| 2541 | +The kernel transitions between in-kernel non-idle execution, userspace | |
| 2542 | +execution, and the idle loop. | |
| 2543 | +Depending on kernel configuration, RCU handles these states differently: | |
| 2544 | + | |
| 2545 | +<table border=3> | |
| 2546 | +<tr><th><tt>HZ</tt> Kconfig</th> | |
| 2547 | + <th>In-Kernel</th> | |
| 2548 | + <th>Usermode</th> | |
| 2549 | + <th>Idle</th></tr> | |
| 2550 | +<tr><th align="left"><tt>HZ_PERIODIC</tt></th> | |
| 2551 | + <td>Can rely on scheduling-clock interrupt.</td> | |
| 2552 | + <td>Can rely on scheduling-clock interrupt and its | |
| 2553 | + detection of interrupt from usermode.</td> | |
| 2554 | + <td>Can rely on RCU's dyntick-idle detection.</td></tr> | |
| 2555 | +<tr><th align="left"><tt>NO_HZ_IDLE</tt></th> | |
| 2556 | + <td>Can rely on scheduling-clock interrupt.</td> | |
| 2557 | + <td>Can rely on scheduling-clock interrupt and its | |
| 2558 | + detection of interrupt from usermode.</td> | |
| 2559 | + <td>Can rely on RCU's dyntick-idle detection.</td></tr> | |
| 2560 | +<tr><th align="left"><tt>NO_HZ_FULL</tt></th> | |
| 2561 | + <td>Can only sometimes rely on scheduling-clock interrupt. | |
| 2562 | + In other cases, it is necessary to bound kernel execution | |
| 2563 | + times and/or use IPIs.</td> | |
| 2564 | + <td>Can rely on RCU's dyntick-idle detection.</td> | |
| 2565 | + <td>Can rely on RCU's dyntick-idle detection.</td></tr> | |
| 2566 | +</table> | |
| 2567 | + | |
| 2568 | +<table> | |
| 2569 | +<tr><th> </th></tr> | |
| 2570 | +<tr><th align="left">Quick Quiz:</th></tr> | |
| 2571 | +<tr><td> | |
| 2572 | + Why can't <tt>NO_HZ_FULL</tt> in-kernel execution rely on the | |
| 2573 | + scheduling-clock interrupt, just like <tt>HZ_PERIODIC</tt> | |
| 2574 | + and <tt>NO_HZ_IDLE</tt> do? | |
| 2575 | +</td></tr> | |
| 2576 | +<tr><th align="left">Answer:</th></tr> | |
| 2577 | +<tr><td bgcolor="#ffffff"><font color="ffffff"> | |
| 2578 | + Because, as a performance optimization, <tt>NO_HZ_FULL</tt> | |
| 2579 | + does not necessarily re-enable the scheduling-clock interrupt | |
| 2580 | + on entry to each and every system call. | |
| 2581 | +</font></td></tr> | |
| 2582 | +<tr><td> </td></tr> | |
| 2583 | +</table> | |
| 2584 | + | |
| 2585 | +<p> | |
| 2586 | +However, RCU must be reliably informed as to whether any given | |
| 2587 | +CPU is currently in the idle loop, and, for <tt>NO_HZ_FULL</tt>, | |
| 2588 | +also whether that CPU is executing in usermode, as discussed | |
| 2589 | +<a href="#Energy Efficiency">earlier</a>. | |
| 2590 | +It also requires that the scheduling-clock interrupt be enabled when | |
| 2591 | +RCU needs it to be: | |
| 2592 | + | |
| 2593 | +<ol> | |
| 2594 | +<li> If a CPU is either idle or executing in usermode, and RCU believes | |
| 2595 | + it is non-idle, the scheduling-clock tick had better be running. | |
| 2596 | + Otherwise, you will get RCU CPU stall warnings. Or at best, | |
| 2597 | + very long (11-second) grace periods, with a pointless IPI waking | |
| 2598 | + the CPU from time to time. | |
| 2599 | +<li> If a CPU is in a portion of the kernel that executes RCU read-side | |
| 2600 | + critical sections, and RCU believes this CPU to be idle, you will get | |
| 2601 | + random memory corruption. <b>DON'T DO THIS!!!</b> | |
| 2602 | + | |
| 2603 | + <br>This is one reason to test with lockdep, which will complain | |
| 2604 | + about this sort of thing. | |
| 2605 | +<li> If a CPU is in a portion of the kernel that is absolutely | |
| 2606 | + positively no-joking guaranteed to never execute any RCU read-side | |
| 2607 | + critical sections, and RCU believes this CPU to to be idle, | |
| 2608 | + no problem. This sort of thing is used by some architectures | |
| 2609 | + for light-weight exception handlers, which can then avoid the | |
| 2610 | + overhead of <tt>rcu_irq_enter()</tt> and <tt>rcu_irq_exit()</tt> | |
| 2611 | + at exception entry and exit, respectively. | |
| 2612 | + Some go further and avoid the entireties of <tt>irq_enter()</tt> | |
| 2613 | + and <tt>irq_exit()</tt>. | |
| 2614 | + | |
| 2615 | + <br>Just make very sure you are running some of your tests with | |
| 2616 | + <tt>CONFIG_PROVE_RCU=y</tt>, just in case one of your code paths | |
| 2617 | + was in fact joking about not doing RCU read-side critical sections. | |
| 2618 | +<li> If a CPU is executing in the kernel with the scheduling-clock | |
| 2619 | + interrupt disabled and RCU believes this CPU to be non-idle, | |
| 2620 | + and if the CPU goes idle (from an RCU perspective) every few | |
| 2621 | + jiffies, no problem. It is usually OK for there to be the | |
| 2622 | + occasional gap between idle periods of up to a second or so. | |
| 2623 | + | |
| 2624 | + <br>If the gap grows too long, you get RCU CPU stall warnings. | |
| 2625 | +<li> If a CPU is either idle or executing in usermode, and RCU believes | |
| 2626 | + it to be idle, of course no problem. | |
| 2627 | +<li> If a CPU is executing in the kernel, the kernel code | |
| 2628 | + path is passing through quiescent states at a reasonable | |
| 2629 | + frequency (preferably about once per few jiffies, but the | |
| 2630 | + occasional excursion to a second or so is usually OK) and the | |
| 2631 | + scheduling-clock interrupt is enabled, of course no problem. | |
| 2632 | + | |
| 2633 | + <br>If the gap between a successive pair of quiescent states grows | |
| 2634 | + too long, you get RCU CPU stall warnings. | |
| 2635 | +</ol> | |
| 2636 | + | |
| 2637 | +<table> | |
| 2638 | +<tr><th> </th></tr> | |
| 2639 | +<tr><th align="left">Quick Quiz:</th></tr> | |
| 2640 | +<tr><td> | |
| 2641 | + But what if my driver has a hardware interrupt handler | |
| 2642 | + that can run for many seconds? | |
| 2643 | + I cannot invoke <tt>schedule()</tt> from an hardware | |
| 2644 | + interrupt handler, after all! | |
| 2645 | +</td></tr> | |
| 2646 | +<tr><th align="left">Answer:</th></tr> | |
| 2647 | +<tr><td bgcolor="#ffffff"><font color="ffffff"> | |
| 2648 | + One approach is to do <tt>rcu_irq_exit();rcu_irq_enter();</tt> | |
| 2649 | + every so often. | |
| 2650 | + But given that long-running interrupt handlers can cause | |
| 2651 | + other problems, not least for response time, shouldn't you | |
| 2652 | + work to keep your interrupt handler's runtime within reasonable | |
| 2653 | + bounds? | |
| 2654 | +</font></td></tr> | |
| 2655 | +<tr><td> </td></tr> | |
| 2656 | +</table> | |
| 2657 | + | |
| 2658 | +<p> | |
| 2659 | +But as long as RCU is properly informed of kernel state transitions between | |
| 2660 | +in-kernel execution, usermode execution, and idle, and as long as the | |
| 2661 | +scheduling-clock interrupt is enabled when RCU needs it to be, you | |
| 2662 | +can rest assured that the bugs you encounter will be in some other | |
| 2663 | +part of RCU or some other part of the kernel! | |
| 2664 | + | |
| 2535 | 2665 | <h3><a name="Memory Efficiency">Memory Efficiency</a></h3> |
| 2536 | 2666 | |
| 2537 | 2667 | <p> |
| @@ -23,6 +23,14 @@ over a rather long period of time, but improvements are always welcome! · 22 unmodified lines | ||
| 23 | 23 | Yet another exception is where the low real-time latency of RCU's |
| 24 | 24 | read-side primitives is critically important. |
| 25 | 25 | |
| 26 | + One final exception is where RCU readers are used to prevent | |
| 27 | + the ABA problem (https://en.wikipedia.org/wiki/ABA_problem) | |
| 28 | + for lockless updates. This does result in the mildly | |
| 29 | + counter-intuitive situation where rcu_read_lock() and | |
| 30 | + rcu_read_unlock() are used to protect updates, however, this | |
| 31 | + approach provides the same potential simplifications that garbage | |
| 32 | + collectors do. | |
| 33 | + | |
| 26 | 34 | 1. Does the update code have proper mutual exclusion? |
| 27 | 35 | |
| 28 | 36 | RCU does allow -readers- to run (almost) naked, but -writers- must |
| @@ -40,7 +48,9 @@ over a rather long period of time, but improvements are always welcome! · 11 unmodified lines | ||
| 40 | 48 | explain how this single task does not become a major bottleneck on |
| 41 | 49 | big multiprocessor machines (for example, if the task is updating |
| 42 | 50 | information relating to itself that other tasks can read, there |
| 43 | − by definition can be no bottleneck). | |
| 51 | + by definition can be no bottleneck). Note that the definition | |
| 52 | + of "large" has changed significantly: Eight CPUs was "large" | |
| 53 | + in the year 2000, but a hundred CPUs was unremarkable in 2017. | |
| 44 | 54 | |
| 45 | 55 | 2. Do the RCU read-side critical sections make proper use of |
| 46 | 56 | rcu_read_lock() and friends? These primitives are needed |
| @@ -55,6 +65,12 @@ over a rather long period of time, but improvements are always welcome! · 8 unmodified lines | ||
| 55 | 65 | Disabling of preemption can serve as rcu_read_lock_sched(), but |
| 56 | 66 | is less readable. |
| 57 | 67 | |
| 68 | + Letting RCU-protected pointers "leak" out of an RCU read-side | |
| 69 | + critical section is every bid as bad as letting them leak out | |
| 70 | + from under a lock. Unless, of course, you have arranged some | |
| 71 | + other means of protection, such as a lock or a reference count | |
| 72 | + -before- letting them out of the RCU read-side critical section. | |
| 73 | + | |
| 58 | 74 | 3. Does the update code tolerate concurrent accesses? |
| 59 | 75 | |
| 60 | 76 | The whole point of RCU is to permit readers to run without |
| @@ -78,10 +94,10 @@ over a rather long period of time, but improvements are always welcome! · 17 unmodified lines | ||
| 78 | 94 | |
| 79 | 95 | This works quite well, also. |
| 80 | 96 | |
| 81 | − c. Make updates appear atomic to readers. For example, | |
| 97 | + c. Make updates appear atomic to readers. For example, | |
| 82 | 98 | pointer updates to properly aligned fields will |
| 83 | 99 | appear atomic, as will individual atomic primitives. |
| 84 | − Sequences of perations performed under a lock will -not- | |
| 100 | + Sequences of operations performed under a lock will -not- | |
| 85 | 101 | appear to be atomic to RCU readers, nor will sequences |
| 86 | 102 | of multiple atomic primitives. |
| 87 | 103 | |
| @@ -168,8 +184,8 @@ over a rather long period of time, but improvements are always welcome! · 80 unmodified lines | ||
| 168 | 184 | |
| 169 | 185 | 5. If call_rcu(), or a related primitive such as call_rcu_bh(), |
| 170 | 186 | call_rcu_sched(), or call_srcu() is used, the callback function |
| 171 | − must be written to be called from softirq context. In particular, | |
| 172 | − it cannot block. | |
| 187 | + will be called from softirq context. In particular, it cannot | |
| 188 | + block. | |
| 173 | 189 | |
| 174 | 190 | 6. Since synchronize_rcu() can block, it cannot be called from |
| 175 | 191 | any sort of irq context. The same rule applies for |
| @@ -178,11 +194,14 @@ over a rather long period of time, but improvements are always welcome! · 2 unmodified lines | ||
| 178 | 194 | synchronize_sched_expedite(), and synchronize_srcu_expedited(). |
| 179 | 195 | |
| 180 | 196 | The expedited forms of these primitives have the same semantics |
| 181 | − as the non-expedited forms, but expediting is both expensive | |
| 182 | − and unfriendly to real-time workloads. Use of the expedited | |
| 183 | − primitives should be restricted to rare configuration-change | |
| 184 | − operations that would not normally be undertaken while a real-time | |
| 185 | − workload is running. | |
| 197 | + as the non-expedited forms, but expediting is both expensive and | |
| 198 | + (with the exception of synchronize_srcu_expedited()) unfriendly | |
| 199 | + to real-time workloads. Use of the expedited primitives should | |
| 200 | + be restricted to rare configuration-change operations that would | |
| 201 | + not normally be undertaken while a real-time workload is running. | |
| 202 | + However, real-time workloads can use rcupdate.rcu_normal kernel | |
| 203 | + boot parameter to completely disable expedited grace periods, | |
| 204 | + though this might have performance implications. | |
| 186 | 205 | |
| 187 | 206 | In particular, if you find yourself invoking one of the expedited |
| 188 | 207 | primitives repeatedly in a loop, please do everyone a favor: |
| @@ -193,11 +212,6 @@ over a rather long period of time, but improvements are always welcome! · 4 unmodified lines | ||
| 193 | 212 | of the system, especially to real-time workloads running on |
| 194 | 213 | the rest of the system. |
| 195 | 214 | |
| 196 | − In addition, it is illegal to call the expedited forms from | |
| 197 | − a CPU-hotplug notifier, or while holding a lock that is acquired | |
| 198 | − by a CPU-hotplug notifier. Failing to observe this restriction | |
| 199 | − will result in deadlock. | |
| 200 | − | |
| 201 | 215 | 7. If the updater uses call_rcu() or synchronize_rcu(), then the |
| 202 | 216 | corresponding readers must use rcu_read_lock() and |
| 203 | 217 | rcu_read_unlock(). If the updater uses call_rcu_bh() or |
| @@ -321,7 +335,7 @@ over a rather long period of time, but improvements are always welcome! · 117 unmodified lines | ||
| 321 | 335 | Similarly, disabling preemption is not an acceptable substitute |
| 322 | 336 | for rcu_read_lock(). Code that attempts to use preemption |
| 323 | 337 | disabling where it should be using rcu_read_lock() will break |
| 324 | − in real-time kernel builds. | |
| 338 | + in CONFIG_PREEMPT=y kernel builds. | |
| 325 | 339 | |
| 326 | 340 | If you want to wait for interrupt handlers, NMI handlers, and |
| 327 | 341 | code under the influence of preempt_disable(), you instead |
| @@ -356,23 +370,22 @@ over a rather long period of time, but improvements are always welcome! · 28 unmodified lines | ||
| 356 | 370 | not the case, a self-spawning RCU callback would prevent the |
| 357 | 371 | victim CPU from ever going offline.) |
| 358 | 372 | |
| 359 | −14. SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(), | |
| 360 | − synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu()) | |
| 361 | − may only be invoked from process context. Unlike other forms of | |
| 362 | − RCU, it -is- permissible to block in an SRCU read-side critical | |
| 363 | − section (demarked by srcu_read_lock() and srcu_read_unlock()), | |
| 364 | − hence the "SRCU": "sleepable RCU". Please note that if you | |
| 365 | − don't need to sleep in read-side critical sections, you should be | |
| 366 | − using RCU rather than SRCU, because RCU is almost always faster | |
| 367 | − and easier to use than is SRCU. | |
| 368 | − | |
| 369 | − Also unlike other forms of RCU, explicit initialization | |
| 370 | − and cleanup is required via init_srcu_struct() and | |
| 371 | − cleanup_srcu_struct(). These are passed a "struct srcu_struct" | |
| 372 | − that defines the scope of a given SRCU domain. Once initialized, | |
| 373 | − the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock() | |
| 374 | − synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu(). | |
| 375 | − A given synchronize_srcu() waits only for SRCU read-side critical | |
| 373 | +14. Unlike other forms of RCU, it -is- permissible to block in an | |
| 374 | + SRCU read-side critical section (demarked by srcu_read_lock() | |
| 375 | + and srcu_read_unlock()), hence the "SRCU": "sleepable RCU". | |
| 376 | + Please note that if you don't need to sleep in read-side critical | |
| 377 | + sections, you should be using RCU rather than SRCU, because RCU | |
| 378 | + is almost always faster and easier to use than is SRCU. | |
| 379 | + | |
| 380 | + Also unlike other forms of RCU, explicit initialization and | |
| 381 | + cleanup is required either at build time via DEFINE_SRCU() | |
| 382 | + or DEFINE_STATIC_SRCU() or at runtime via init_srcu_struct() | |
| 383 | + and cleanup_srcu_struct(). These last two are passed a | |
| 384 | + "struct srcu_struct" that defines the scope of a given | |
| 385 | + SRCU domain. Once initialized, the srcu_struct is passed | |
| 386 | + to srcu_read_lock(), srcu_read_unlock() synchronize_srcu(), | |
| 387 | + synchronize_srcu_expedited(), and call_srcu(). A given | |
| 388 | + synchronize_srcu() waits only for SRCU read-side critical | |
| 376 | 389 | sections governed by srcu_read_lock() and srcu_read_unlock() |
| 377 | 390 | calls that have been passed the same srcu_struct. This property |
| 378 | 391 | is what makes sleeping read-side critical sections tolerable -- |
| @@ -390,10 +403,16 @@ over a rather long period of time, but improvements are always welcome! · 11 unmodified lines | ||
| 390 | 403 | Therefore, SRCU should be used in preference to rw_semaphore |
| 391 | 404 | only in extremely read-intensive situations, or in situations |
| 392 | 405 | requiring SRCU's read-side deadlock immunity or low read-side |
| 393 | − realtime latency. | |
| 406 | + realtime latency. You should also consider percpu_rw_semaphore | |
| 407 | + when you need lightweight readers. | |
| 394 | 408 | |
| 395 | − Note that, rcu_assign_pointer() relates to SRCU just as it does | |
| 396 | − to other forms of RCU. | |
| 409 | + SRCU's expedited primitive (synchronize_srcu_expedited()) | |
| 410 | + never sends IPIs to other CPUs, so it is easier on | |
| 411 | + real-time workloads than is synchronize_rcu_expedited(), | |
| 412 | + synchronize_rcu_bh_expedited() or synchronize_sched_expedited(). | |
| 413 | + | |
| 414 | + Note that rcu_dereference() and rcu_assign_pointer() relate to | |
| 415 | + SRCU just as they do to other forms of RCU. | |
| 397 | 416 | |
| 398 | 417 | 15. The whole point of call_rcu(), synchronize_rcu(), and friends |
| 399 | 418 | is to wait until all pre-existing readers have finished before |
| @@ -435,3 +454,33 @@ over a rather long period of time, but improvements are always welcome! · 35 unmodified lines | ||
| 435 | 454 | |
| 436 | 455 | These debugging aids can help you find problems that are |
| 437 | 456 | otherwise extremely difficult to spot. |
| 457 | + | |
| 458 | +18. If you register a callback using call_rcu(), call_rcu_bh(), | |
| 459 | + call_rcu_sched(), or call_srcu(), and pass in a function defined | |
| 460 | + within a loadable module, then it in necessary to wait for | |
| 461 | + all pending callbacks to be invoked after the last invocation | |
| 462 | + and before unloading that module. Note that it is absolutely | |
| 463 | + -not- sufficient to wait for a grace period! The current (say) | |
| 464 | + synchronize_rcu() implementation waits only for all previous | |
| 465 | + callbacks registered on the CPU that synchronize_rcu() is running | |
| 466 | + on, but it is -not- guaranteed to wait for callbacks registered | |
| 467 | + on other CPUs. | |
| 468 | + | |
| 469 | + You instead need to use one of the barrier functions: | |
| 470 | + | |
| 471 | + o call_rcu() -> rcu_barrier() | |
| 472 | + o call_rcu_bh() -> rcu_barrier_bh() | |
| 473 | + o call_rcu_sched() -> rcu_barrier_sched() | |
| 474 | + o call_srcu() -> srcu_barrier() | |
| 475 | + | |
| 476 | + However, these barrier functions are absolutely -not- guaranteed | |
| 477 | + to wait for a grace period. In fact, if there are no call_rcu() | |
| 478 | + callbacks waiting anywhere in the system, rcu_barrier() is within | |
| 479 | + its rights to return immediately. | |
| 480 | + | |
| 481 | + So if you need to wait for both an RCU grace period and for | |
| 482 | + all pre-existing call_rcu() callbacks, you will need to execute | |
| 483 | + both rcu_barrier() and synchronize_rcu(), if necessary, using | |
| 484 | + something like workqueues to to execute them concurrently. | |
| 485 | + | |
| 486 | + See rcubarrier.txt for more information. | |
| @@ -76,15 +76,12 @@ o I hear that RCU is patented? What is with that? · 75 unmodified lines | ||
| 76 | 76 | Of these, one was allowed to lapse by the assignee, and the |
| 77 | 77 | others have been contributed to the Linux kernel under GPL. |
| 78 | 78 | There are now also LGPL implementations of user-level RCU |
| 79 | − available (http://lttng.org/?q=node/18). | |
| 79 | + available (http://liburcu.org/). | |
| 80 | 80 | |
| 81 | 81 | o I hear that RCU needs work in order to support realtime kernels? |
| 82 | 82 | |
| 83 | − This work is largely completed. Realtime-friendly RCU can be | |
| 84 | − enabled via the CONFIG_PREEMPT_RCU kernel configuration | |
| 85 | − parameter. However, work is in progress for enabling priority | |
| 86 | − boosting of preempted RCU read-side critical sections. This is | |
| 87 | − needed if you have CPU-bound realtime threads. | |
| 83 | + Realtime-friendly RCU can be enabled via the CONFIG_PREEMPT_RCU | |
| 84 | + kernel configuration parameter. | |
| 88 | 85 | |
| 89 | 86 | o Where can I find more information on RCU? |
| 90 | 87 | |
| @@ -25,35 +25,35 @@ o You must use one of the rcu_dereference() family of primitives · 24 unmodified lines | ||
| 25 | 25 | for an example where the compiler can in fact deduce the exact |
| 26 | 26 | value of the pointer, and thus cause misordering. |
| 27 | 27 | |
| 28 | +o You are only permitted to use rcu_dereference on pointer values. | |
| 29 | + The compiler simply knows too much about integral values to | |
| 30 | + trust it to carry dependencies through integer operations. | |
| 31 | + There are a very few exceptions, namely that you can temporarily | |
| 32 | + cast the pointer to uintptr_t in order to: | |
| 33 | + | |
| 34 | + o Set bits and clear bits down in the must-be-zero low-order | |
| 35 | + bits of that pointer. This clearly means that the pointer | |
| 36 | + must have alignment constraints, for example, this does | |
| 37 | + -not- work in general for char* pointers. | |
| 38 | + | |
| 39 | + o XOR bits to translate pointers, as is done in some | |
| 40 | + classic buddy-allocator algorithms. | |
| 41 | + | |
| 42 | + It is important to cast the value back to pointer before | |
| 43 | + doing much of anything else with it. | |
| 44 | + | |
| 28 | 45 | o Avoid cancellation when using the "+" and "-" infix arithmetic |
| 29 | 46 | operators. For example, for a given variable "x", avoid |
| 30 | − "(x-x)". There are similar arithmetic pitfalls from other | |
| 31 | − arithmetic operators, such as "(x*0)", "(x/(x+1))" or "(x%1)". | |
| 32 | − The compiler is within its rights to substitute zero for all of | |
| 33 | − these expressions, so that subsequent accesses no longer depend | |
| 34 | − on the rcu_dereference(), again possibly resulting in bugs due | |
| 35 | − to misordering. | |
| 47 | + "(x-(uintptr_t)x)" for char* pointers. The compiler is within its | |
| 48 | + rights to substitute zero for this sort of expression, so that | |
| 49 | + subsequent accesses no longer depend on the rcu_dereference(), | |
| 50 | + again possibly resulting in bugs due to misordering. | |
| 36 | 51 | |
| 37 | 52 | Of course, if "p" is a pointer from rcu_dereference(), and "a" |
| 38 | 53 | and "b" are integers that happen to be equal, the expression |
| 39 | 54 | "p+a-b" is safe because its value still necessarily depends on |
| 40 | 55 | the rcu_dereference(), thus maintaining proper ordering. |
| 41 | 56 | |
| 42 | −o Avoid all-zero operands to the bitwise "&" operator, and | |
| 43 | − similarly avoid all-ones operands to the bitwise "|" operator. | |
| 44 | − If the compiler is able to deduce the value of such operands, | |
| 45 | − it is within its rights to substitute the corresponding constant | |
| 46 | − for the bitwise operation. Once again, this causes subsequent | |
| 47 | − accesses to no longer depend on the rcu_dereference(), causing | |
| 48 | − bugs due to misordering. | |
| 49 | − | |
| 50 | − Please note that single-bit operands to bitwise "&" can also | |
| 51 | − be dangerous. At this point, the compiler knows that the | |
| 52 | − resulting value can only take on one of two possible values. | |
| 53 | − Therefore, a very small amount of additional information will | |
| 54 | − allow the compiler to deduce the exact value, which again can | |
| 55 | − result in misordering. | |
| 56 | − | |
| 57 | 57 | o If you are using RCU to protect JITed functions, so that the |
| 58 | 58 | "()" function-invocation operator is applied to a value obtained |
| 59 | 59 | (directly or indirectly) from rcu_dereference(), you may need to |
| @@ -61,25 +61,6 @@ o If you are using RCU to protect JITed functions, so that the · 1 unmodified line | ||
| 61 | 61 | This issue arises on some systems when a newly JITed function is |
| 62 | 62 | using the same memory that was used by an earlier JITed function. |
| 63 | 63 | |
| 64 | −o Do not use the results from the boolean "&&" and "||" when | |
| 65 | − dereferencing. For example, the following (rather improbable) | |
| 66 | − code is buggy: | |
| 67 | − | |
| 68 | − int *p; | |
| 69 | − int *q; | |
| 70 | − | |
| 71 | − ... | |
| 72 | − | |
| 73 | − p = rcu_dereference(gp) | |
| 74 | − q = &global_q; | |
| 75 | − q += p != &oom_p1 && p != &oom_p2; | |
| 76 | − r1 = *q; /* BUGGY!!! */ | |
| 77 | − | |
| 78 | − The reason this is buggy is that "&&" and "||" are often compiled | |
| 79 | − using branches. While weak-memory machines such as ARM or PowerPC | |
| 80 | − do order stores after such branches, they can speculate loads, | |
| 81 | − which can result in misordering bugs. | |
| 82 | − | |
| 83 | 64 | o Do not use the results from relational operators ("==", "!=", |
| 84 | 65 | ">", ">=", "<", or "<=") when dereferencing. For example, |
| 85 | 66 | the following (quite strange) code is buggy: |
| @@ -263,6 +263,11 @@ Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes · 262 unmodified lines | ||
| 263 | 263 | are delayed for a full grace period? Couldn't this result in |
| 264 | 264 | rcu_barrier() returning prematurely? |
| 265 | 265 | |
| 266 | +The current rcu_barrier() implementation is more complex, due to the need | |
| 267 | +to avoid disturbing idle CPUs (especially on battery-powered systems) | |
| 268 | +and the need to minimally disturb non-idle CPUs in real-time systems. | |
| 269 | +However, the code above illustrates the concepts. | |
| 270 | + | |
| 266 | 271 | |
| 267 | 272 | rcu_barrier() Summary |
| 268 | 273 | |
| @@ -276,15 +276,17 @@ o "Free-Block Circulation": Shows the number of torture structures · 275 unmodified lines | ||
| 276 | 276 | somehow gets incremented farther than it should. |
| 277 | 277 | |
| 278 | 278 | Different implementations of RCU can provide implementation-specific |
| 279 | −additional information. For example, SRCU provides the following | |
| 279 | +additional information. For example, Tree SRCU provides the following | |
| 280 | 280 | additional line: |
| 281 | 281 | |
| 282 | − srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1) | |
| 282 | + srcud-torture: Tree SRCU per-CPU(idx=0): 0(35,-21) 1(-4,24) 2(1,1) 3(-26,20) 4(28,-47) 5(-9,4) 6(-10,14) 7(-14,11) T(1,6) | |
| 283 | 283 | |
| 284 | −This line shows the per-CPU counter state. The numbers in parentheses are | |
| 285 | −the values of the "old" and "current" counters for the corresponding CPU. | |
| 286 | −The "idx" value maps the "old" and "current" values to the underlying | |
| 287 | −array, and is useful for debugging. | |
| 284 | +This line shows the per-CPU counter state, in this case for Tree SRCU | |
| 285 | +using a dynamically allocated srcu_struct (hence "srcud-" rather than | |
| 286 | +"srcu-"). The numbers in parentheses are the values of the "old" and | |
| 287 | +"current" counters for the corresponding CPU. The "idx" value maps the | |
| 288 | +"old" and "current" values to the underlying array, and is useful for | |
| 289 | +debugging. The final "T" entry contains the totals of the counters. | |
| 288 | 290 | |
| 289 | 291 | |
| 290 | 292 | USAGE |
| @@ -304,3 +306,9 @@ checked for such errors. The "rmmod" command forces a "SUCCESS", · 13 unmodified lines | ||
| 304 | 306 | "FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first |
| 305 | 307 | two are self-explanatory, while the last indicates that while there |
| 306 | 308 | were no RCU failures, CPU-hotplug problems were detected. |
| 309 | + | |
| 310 | +However, the tools/testing/selftests/rcutorture/bin/kvm.sh script | |
| 311 | +provides better automation, including automatic failure analysis. | |
| 312 | +It assumes a qemu/kvm-enabled platform, and runs guest OSes out of initrd. | |
| 313 | +See tools/testing/selftests/rcutorture/doc/initrd.txt for instructions | |
| 314 | +on setting up such an initrd. | |
| @@ -890,6 +890,8 @@ SRCU: Critical sections Grace period Barrier · 889 unmodified lines | ||
| 890 | 890 | srcu_read_lock_held |
| 891 | 891 | |
| 892 | 892 | SRCU: Initialization/cleanup |
| 893 | + DEFINE_SRCU | |
| 894 | + DEFINE_STATIC_SRCU | |
| 893 | 895 | init_srcu_struct |
| 894 | 896 | cleanup_srcu_struct |
| 895 | 897 | |
| @@ -913,7 +915,8 @@ a. Will readers need to block? If so, you need SRCU. · 17 unmodified lines | ||
| 913 | 915 | b. What about the -rt patchset? If readers would need to block |
| 914 | 916 | in an non-rt kernel, you need SRCU. If readers would block |
| 915 | 917 | in a -rt kernel, but not in a non-rt kernel, SRCU is not |
| 916 | − necessary. | |
| 918 | + necessary. (The -rt patchset turns spinlocks into sleeplocks, | |
| 919 | + hence this distinction.) | |
| 917 | 920 | |
| 918 | 921 | c. Do you need to treat NMI handlers, hardirq handlers, |
| 919 | 922 | and code segments with preemption disabled (whether |
| @@ -9,8 +9,8 @@ TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel. · 8 unmodified lines | ||
| 9 | 9 | |
| 10 | 10 | LiveCD-based tutorials are available at |
| 11 | 11 | |
| 12 | −http://tomoyo.sourceforge.jp/1.7/1st-step/ubuntu10.04-live/ | |
| 13 | −http://tomoyo.sourceforge.jp/1.7/1st-step/centos5-live/ | |
| 12 | +http://tomoyo.sourceforge.jp/1.8/ubuntu12.04-live.html | |
| 13 | +http://tomoyo.sourceforge.jp/1.8/centos6-live.html | |
| 14 | 14 | |
| 15 | 15 | Though these tutorials use non-LSM version of TOMOYO, they are useful for you |
| 16 | 16 | to know what TOMOYO is. |
| @@ -21,35 +21,35 @@ How to enable TOMOYO? · 4 unmodified lines | ||
| 21 | 21 | Build the kernel with ``CONFIG_SECURITY_TOMOYO=y`` and pass ``security=tomoyo`` on |
| 22 | 22 | kernel's command line. |
| 23 | 23 | |
| 24 | −Please see http://tomoyo.sourceforge.jp/2.3/ for details. | |
| 24 | +Please see http://tomoyo.osdn.jp/2.5/ for details. | |
| 25 | 25 | |
| 26 | 26 | Where is documentation? |
| 27 | 27 | ======================= |
| 28 | 28 | |
| 29 | 29 | User <-> Kernel interface documentation is available at |
| 30 | −http://tomoyo.sourceforge.jp/2.3/policy-reference.html . | |
| 30 | +http://tomoyo.osdn.jp/2.5/policy-specification/index.html . | |
| 31 | 31 | |
| 32 | 32 | Materials we prepared for seminars and symposiums are available at |
| 33 | −http://sourceforge.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . | |
| 33 | +http://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . | |
| 34 | 34 | Below lists are chosen from three aspects. |
| 35 | 35 | |
| 36 | 36 | What is TOMOYO? |
| 37 | 37 | TOMOYO Linux Overview |
| 38 | − http://sourceforge.jp/projects/tomoyo/docs/lca2009-takeda.pdf | |
| 38 | + http://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf | |
| 39 | 39 | TOMOYO Linux: pragmatic and manageable security for Linux |
| 40 | − http://sourceforge.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf | |
| 40 | + http://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf | |
| 41 | 41 | TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box |
| 42 | − http://sourceforge.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf | |
| 42 | + http://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf | |
| 43 | 43 | |
| 44 | 44 | What can TOMOYO do? |
| 45 | 45 | Deep inside TOMOYO Linux |
| 46 | − http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf | |
| 46 | + http://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf | |
| 47 | 47 | The role of "pathname based access control" in security. |
| 48 | − http://sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf | |
| 48 | + http://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf | |
| 49 | 49 | |
| 50 | 50 | History of TOMOYO? |
| 51 | 51 | Realities of Mainlining |
| 52 | − http://sourceforge.jp/projects/tomoyo/docs/lfj2008.pdf | |
| 52 | + http://osdn.jp/projects/tomoyo/docs/lfj2008.pdf | |
| 53 | 53 | |
| 54 | 54 | What is future plan? |
| 55 | 55 | ==================== |
| @@ -60,6 +60,6 @@ multiple LSM modules at the same time. We feel sorry that you have to give up · 4 unmodified lines | ||
| 60 | 60 | SELinux/SMACK/AppArmor etc. when you want to use TOMOYO. |
| 61 | 61 | |
| 62 | 62 | We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM |
| 63 | −version of TOMOYO, available at http://tomoyo.sourceforge.jp/1.7/ . | |
| 63 | +version of TOMOYO, available at http://tomoyo.osdn.jp/1.8/ . | |
| 64 | 64 | LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning |
| 65 | 65 | to port non-LSM version's functionalities to LSM versions. |
| @@ -3081,3 +3081,8 @@ · 3080 unmodified lines | ||
| 3081 | 3081 | 1 = /dev/osd1 Second OSD Device |
| 3082 | 3082 | ... |
| 3083 | 3083 | 255 = /dev/osd255 256th OSD Device |
| 3084 | + | |
| 3085 | + 384-511 char RESERVED FOR DYNAMIC ASSIGNMENT | |
| 3086 | + Character devices that request a dynamic allocation of major | |
| 3087 | + number will take numbers starting from 511 and downward, | |
| 3088 | + once the 234-254 range is full. | |
| @@ -138,6 +138,7 @@ parameter is applicable:: · 137 unmodified lines | ||
| 138 | 138 | PPT Parallel port support is enabled. |
| 139 | 139 | PS2 Appropriate PS/2 support is enabled. |
| 140 | 140 | RAM RAM disk support is enabled. |
| 141 | + RDT Intel Resource Director Technology. | |
| 141 | 142 | S390 S390 architecture is enabled. |
| 142 | 143 | SCSI Appropriate SCSI support is enabled. |
| 143 | 144 | A lot of drivers have their options described inside |
| @@ -2233,6 +2233,17 @@ · 2232 unmodified lines | ||
| 2233 | 2233 | memory contents and reserves bad memory |
| 2234 | 2234 | regions that are detected. |
| 2235 | 2235 | |
| 2236 | + mem_encrypt= [X86-64] AMD Secure Memory Encryption (SME) control | |
| 2237 | + Valid arguments: on, off | |
| 2238 | + Default (depends on kernel configuration option): | |
| 2239 | + on (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) | |
| 2240 | + off (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n) | |
| 2241 | + mem_encrypt=on: Activate SME | |
| 2242 | + mem_encrypt=off: Do not activate SME | |
| 2243 | + | |
| 2244 | + Refer to Documentation/x86/amd-memory-encryption.txt | |
| 2245 | + for details on when memory encryption can be activated. | |
| 2246 | + | |
| 2236 | 2247 | mem_sleep_default= [SUSPEND] Default system suspend mode: |
| 2237 | 2248 | s2idle - Suspend-To-Idle |
| 2238 | 2249 | shallow - Power-On Suspend or equivalent (if supported) |
| @@ -2633,9 +2644,10 @@ · 394 unmodified lines | ||
| 2633 | 2644 | In kernels built with CONFIG_NO_HZ_FULL=y, set |
| 2634 | 2645 | the specified list of CPUs whose tick will be stopped |
| 2635 | 2646 | whenever possible. The boot CPU will be forced outside |
| 2636 | − the range to maintain the timekeeping. | |
| 2637 | − The CPUs in this range must also be included in the | |
| 2638 | − rcu_nocbs= set. | |
| 2647 | + the range to maintain the timekeeping. Any CPUs | |
| 2648 | + in this list will have their RCU callbacks offloaded, | |
| 2649 | + just as if they had also been called out in the | |
| 2650 | + rcu_nocbs= boot parameter. | |
| 2639 | 2651 | |
| 2640 | 2652 | noiotrap [SH] Disables trapped I/O port accesses. |
| 2641 | 2653 | |
| @@ -2696,6 +2708,8 @@ · 54 unmodified lines | ||
| 2696 | 2708 | nopat [X86] Disable PAT (page attribute table extension of |
| 2697 | 2709 | pagetables) support. |
| 2698 | 2710 | |
| 2711 | + nopcid [X86-64] Disable the PCID cpu feature. | |
| 2712 | + | |
| 2699 | 2713 | norandmaps Don't use address space randomization. Equivalent to |
| 2700 | 2714 | echo 0 > /proc/sys/kernel/randomize_va_space |
| 2701 | 2715 | |
| @@ -2750,6 +2764,15 @@ · 48 unmodified lines | ||
| 2750 | 2764 | If the dependencies are under your control, you can |
| 2751 | 2765 | turn on cpu0_hotplug. |
| 2752 | 2766 | |
| 2767 | + nps_mtm_hs_ctr= [KNL,ARC] | |
| 2768 | + This parameter sets the maximum duration, in | |
| 2769 | + cycles, each HW thread of the CTOP can run | |
| 2770 | + without interruptions, before HW switches it. | |
| 2771 | + The actual maximum duration is 16 times this | |
| 2772 | + parameter's value. | |
| 2773 | + Format: integer between 1 and 255 | |
| 2774 | + Default: 255 | |
| 2775 | + | |
| 2753 | 2776 | nptcg= [IA-64] Override max number of concurrent global TLB |
| 2754 | 2777 | purges which is reported from either PAL_VM_SUMMARY or |
| 2755 | 2778 | SAL PALO. |
| @@ -2769,7 +2792,7 @@ · 13 unmodified lines | ||
| 2769 | 2792 | Allowed values are enable and disable |
| 2770 | 2793 | |
| 2771 | 2794 | numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. |
| 2772 | − one of ['zone', 'node', 'default'] can be specified | |
| 2795 | + 'node', 'default' can be specified | |
| 2773 | 2796 | This can be set from sysctl after boot. |
| 2774 | 2797 | See Documentation/sysctl/vm.txt for details. |
| 2775 | 2798 | |
| @@ -3598,6 +3621,12 @@ · 822 unmodified lines | ||
| 3598 | 3621 | Run specified binary instead of /init from the ramdisk, |
| 3599 | 3622 | used for early userspace startup. See initrd. |
| 3600 | 3623 | |
| 3624 | + rdt= [HW,X86,RDT] | |
| 3625 | + Turn on/off individual RDT features. List is: | |
| 3626 | + cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, mba. | |
| 3627 | + E.g. to turn on cmt and turn off mba use: | |
| 3628 | + rdt=cmt,!mba | |
| 3629 | + | |
| 3601 | 3630 | reboot= [KNL] |
| 3602 | 3631 | Format (x86 or x86_64): |
| 3603 | 3632 | [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ |
| @@ -4375,6 +4404,10 @@ · 771 unmodified lines | ||
| 4375 | 4404 | decrease the size and leave more room for directly |
| 4376 | 4405 | mapped kernel RAM. |
| 4377 | 4406 | |
| 4407 | + vmcp_cma=nn[MG] [KNL,S390] | |
| 4408 | + Sets the memory size reserved for contiguous memory | |
| 4409 | + allocations for the vmcp device driver. | |
| 4410 | + | |
| 4378 | 4411 | vmhalt= [KNL,S390] Perform z/VM CP command after system halt. |
| 4379 | 4412 | Format: <command> |
| 4380 | 4413 | |
| @@ -479,14 +479,6 @@ This governor exposes the following tunables: · 478 unmodified lines | ||
| 479 | 479 | |
| 480 | 480 | # echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate |
| 481 | 481 | |
| 482 | − | |
| 483 | −``min_sampling_rate`` | |
| 484 | − The minimum value of ``sampling_rate``. | |
| 485 | − | |
| 486 | − Equal to 10000 (10 ms) if :c:macro:`CONFIG_NO_HZ_COMMON` and | |
| 487 | − :c:data:`tick_nohz_active` are both set or to 20 times the value of | |
| 488 | − :c:data:`jiffies` in microseconds otherwise. | |
| 489 | − | |
| 490 | 482 | ``up_threshold`` |
| 491 | 483 | If the estimated CPU load is above this value (in percent), the governor |
| 492 | 484 | will set the frequency to the maximum value allowed for the policy. |
| @@ -5,12 +5,6 @@ Power Management · 4 unmodified lines | ||
| 5 | 5 | .. toctree:: |
| 6 | 6 | :maxdepth: 2 |
| 7 | 7 | |
| 8 | − cpufreq | |
| 9 | − intel_pstate | |
| 10 | − | |
| 11 | −.. only:: subproject and html | |
| 12 | − | |
| 13 | − Indices | |
| 14 | − ======= | |
| 15 | − | |
| 16 | − * :ref:`genindex` | |
| 8 | + strategies | |
| 9 | + system-wide | |
| 10 | + working-state | |
| @@ -167,35 +167,17 @@ is set. · 166 unmodified lines | ||
| 167 | 167 | ``powersave`` |
| 168 | 168 | ............. |
| 169 | 169 | |
| 170 | −Without HWP, this P-state selection algorithm generally depends on the | |
| 171 | −processor model and/or the system profile setting in the ACPI tables and there | |
| 172 | −are two variants of it. | |
| 173 | − | |
| 174 | −One of them is used with processors from the Atom line and (regardless of the | |
| 175 | −processor model) on platforms with the system profile in the ACPI tables set to | |
| 176 | −"mobile" (laptops mostly), "tablet", "appliance PC", "desktop", or | |
| 177 | −"workstation". It is also used with processors supporting the HWP feature if | |
| 178 | −that feature has not been enabled (that is, with the ``intel_pstate=no_hwp`` | |
| 179 | −argument in the kernel command line). It is similar to the algorithm | |
| 170 | +Without HWP, this P-state selection algorithm is similar to the algorithm | |
| 180 | 171 | implemented by the generic ``schedutil`` scaling governor except that the |
| 181 | 172 | utilization metric used by it is based on numbers coming from feedback |
| 182 | 173 | registers of the CPU. It generally selects P-states proportional to the |
| 183 | −current CPU utilization, so it is referred to as the "proportional" algorithm. | |
| 184 | − | |
| 185 | −The second variant of the ``powersave`` P-state selection algorithm, used in all | |
| 186 | −of the other cases (generally, on processors from the Core line, so it is | |
| 187 | −referred to as the "Core" algorithm), is based on the values read from the APERF | |
| 188 | −and MPERF feedback registers and the previously requested target P-state. | |
| 189 | −It does not really take CPU utilization into account explicitly, but as a rule | |
| 190 | −it causes the CPU P-state to ramp up very quickly in response to increased | |
| 191 | −utilization which is generally desirable in server environments. | |
| 192 | − | |
| 193 | −Regardless of the variant, this algorithm is run by the driver's utilization | |
| 194 | −update callback for the given CPU when it is invoked by the CPU scheduler, but | |
| 195 | −not more often than every 10 ms (that can be tweaked via ``debugfs`` in `this | |
| 196 | −particular case <Tuning Interface in debugfs_>`_). Like in the ``performance`` | |
| 197 | −case, the hardware configuration is not touched if the new P-state turns out to | |
| 198 | −be the same as the current one. | |
| 174 | +current CPU utilization. | |
| 175 | + | |
| 176 | +This algorithm is run by the driver's utilization update callback for the | |
| 177 | +given CPU when it is invoked by the CPU scheduler, but not more often than | |
| 178 | +every 10 ms. Like in the ``performance`` case, the hardware configuration | |
| 179 | +is not touched if the new P-state turns out to be the same as the current | |
| 180 | +one. | |
| 199 | 181 | |
| 200 | 182 | This is the default P-state selection algorithm if the |
| 201 | 183 | :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option |
| @@ -720,34 +702,7 @@ P-state is called, the ``ftrace`` filter can be set to to · 518 unmodified lines | ||
| 720 | 702 | gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func |
| 721 | 703 | <idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func |
| 722 | 704 | |
| 723 | −Tuning Interface in ``debugfs`` | |
| 724 | −------------------------------- | |
| 725 | − | |
| 726 | −The ``powersave`` algorithm provided by ``intel_pstate`` for `the Core line of | |
| 727 | −processors in the active mode <powersave_>`_ is based on a `PID controller`_ | |
| 728 | −whose parameters were chosen to address a number of different use cases at the | |
| 729 | −same time. However, it still is possible to fine-tune it to a specific workload | |
| 730 | −and the ``debugfs`` interface under ``/sys/kernel/debug/pstate_snb/`` is | |
| 731 | −provided for this purpose. [Note that the ``pstate_snb`` directory will be | |
| 732 | −present only if the specific P-state selection algorithm matching the interface | |
| 733 | −in it actually is in use.] | |
| 734 | − | |
| 735 | −The following files present in that directory can be used to modify the PID | |
| 736 | −controller parameters at run time: | |
| 737 | − | |
| 738 | −| ``deadband`` | |
| 739 | −| ``d_gain_pct`` | |
| 740 | −| ``i_gain_pct`` | |
| 741 | −| ``p_gain_pct`` | |
| 742 | −| ``sample_rate_ms`` | |
| 743 | −| ``setpoint`` | |
| 744 | − | |
| 745 | −Note, however, that achieving desirable results this way generally requires | |
| 746 | −expert-level understanding of the power vs performance tradeoff, so extra care | |
| 747 | −is recommended when attempting to do that. | |
| 748 | − | |
| 749 | 705 | |
| 750 | 706 | .. _LCEU2015: http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf |
| 751 | 707 | .. _SDM: http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html |
| 752 | 708 | .. _ACPI specification: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf |
| 753 | −.. _PID controller: https://en.wikipedia.org/wiki/PID_controller | |
| @@ -0,0 +1,245 @@ | ||
| 1 | +=================== | |
| 2 | +System Sleep States | |
| 3 | +=================== | |
| 4 | + | |
| 5 | +:: | |
| 6 | + | |
| 7 | + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 8 | + | |
| 9 | +Sleep states are global low-power states of the entire system in which user | |
| 10 | +space code cannot be executed and the overall system activity is significantly | |
| 11 | +reduced. | |
| 12 | + | |
| 13 | + | |
| 14 | +Sleep States That Can Be Supported | |
| 15 | +================================== | |
| 16 | + | |
| 17 | +Depending on its configuration and the capabilities of the platform it runs on, | |
| 18 | +the Linux kernel can support up to four system sleep states, includig | |
| 19 | +hibernation and up to three variants of system suspend. The sleep states that | |
| 20 | +can be supported by the kernel are listed below. | |
| 21 | + | |
| 22 | +.. _s2idle: | |
| 23 | + | |
| 24 | +Suspend-to-Idle | |
| 25 | +--------------- | |
| 26 | + | |
| 27 | +This is a generic, pure software, light-weight variant of system suspend (also | |
| 28 | +referred to as S2I or S2Idle). It allows more energy to be saved relative to | |
| 29 | +runtime idle by freezing user space, suspending the timekeeping and putting all | |
| 30 | +I/O devices into low-power states (possibly lower-power than available in the | |
| 31 | +working state), such that the processors can spend time in their deepest idle | |
| 32 | +states while the system is suspended. | |
| 33 | + | |
| 34 | +The system is woken up from this state by in-band interrupts, so theoretically | |
| 35 | +any devices that can cause interrupts to be generated in the working state can | |
| 36 | +also be set up as wakeup devices for S2Idle. | |
| 37 | + | |
| 38 | +This state can be used on platforms without support for :ref:`standby <standby>` | |
| 39 | +or :ref:`suspend-to-RAM <s2ram>`, or it can be used in addition to any of the | |
| 40 | +deeper system suspend variants to provide reduced resume latency. It is always | |
| 41 | +supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set. | |
| 42 | + | |
| 43 | +.. _standby: | |
| 44 | + | |
| 45 | +Standby | |
| 46 | +------- | |
| 47 | + | |
| 48 | +This state, if supported, offers moderate, but real, energy savings, while | |
| 49 | +providing a relatively straightforward transition back to the working state. No | |
| 50 | +operating state is lost (the system core logic retains power), so the system can | |
| 51 | +go back to where it left off easily enough. | |
| 52 | + | |
| 53 | +In addition to freezing user space, suspending the timekeeping and putting all | |
| 54 | +I/O devices into low-power states, which is done for :ref:`suspend-to-idle | |
| 55 | +<s2idle>` too, nonboot CPUs are taken offline and all low-level system functions | |
| 56 | +are suspended during transitions into this state. For this reason, it should | |
| 57 | +allow more energy to be saved relative to :ref:`suspend-to-idle <s2idle>`, but | |
| 58 | +the resume latency will generally be greater than for that state. | |
| 59 | + | |
| 60 | +The set of devices that can wake up the system from this state usually is | |
| 61 | +reduced relative to :ref:`suspend-to-idle <s2idle>` and it may be necessary to | |
| 62 | +rely on the platform for setting up the wakeup functionality as appropriate. | |
| 63 | + | |
| 64 | +This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration | |
| 65 | +option is set and the support for it is registered by the platform with the | |
| 66 | +core system suspend subsystem. On ACPI-based systems this state is mapped to | |
| 67 | +the S1 system state defined by ACPI. | |
| 68 | + | |
| 69 | +.. _s2ram: | |
| 70 | + | |
| 71 | +Suspend-to-RAM | |
| 72 | +-------------- | |
| 73 | + | |
| 74 | +This state (also referred to as STR or S2RAM), if supported, offers significant | |
| 75 | +energy savings as everything in the system is put into a low-power state, except | |
| 76 | +for memory, which should be placed into the self-refresh mode to retain its | |
| 77 | +contents. All of the steps carried out when entering :ref:`standby <standby>` | |
| 78 | +are also carried out during transitions to S2RAM. Additional operations may | |
| 79 | +take place depending on the platform capabilities. In particular, on ACPI-based | |
| 80 | +systems the kernel passes control to the platform firmware (BIOS) as the last | |
| 81 | +step during S2RAM transitions and that usually results in powering down some | |
| 82 | +more low-level components that are not directly controlled by the kernel. | |
| 83 | + | |
| 84 | +The state of devices and CPUs is saved and held in memory. All devices are | |
| 85 | +suspended and put into low-power states. In many cases, all peripheral buses | |
| 86 | +lose power when entering S2RAM, so devices must be able to handle the transition | |
| 87 | +back to the "on" state. | |
| 88 | + | |
| 89 | +On ACPI-based systems S2RAM requires some minimal boot-strapping code in the | |
| 90 | +platform firmware to resume the system from it. This may be the case on other | |
| 91 | +platforms too. | |
| 92 | + | |
| 93 | +The set of devices that can wake up the system from S2RAM usually is reduced | |
| 94 | +relative to :ref:`suspend-to-idle <s2idle>` and :ref:`standby <standby>` and it | |
| 95 | +may be necessary to rely on the platform for setting up the wakeup functionality | |
| 96 | +as appropriate. | |
| 97 | + | |
| 98 | +S2RAM is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option | |
| 99 | +is set and the support for it is registered by the platform with the core system | |
| 100 | +suspend subsystem. On ACPI-based systems it is mapped to the S3 system state | |
| 101 | +defined by ACPI. | |
| 102 | + | |
| 103 | +.. _hibernation: | |
| 104 | + | |
| 105 | +Hibernation | |
| 106 | +----------- | |
| 107 | + | |
| 108 | +This state (also referred to as Suspend-to-Disk or STD) offers the greatest | |
| 109 | +energy savings and can be used even in the absence of low-level platform support | |
| 110 | +for system suspend. However, it requires some low-level code for resuming the | |
| 111 | +system to be present for the underlying CPU architecture. | |
| 112 | + | |
| 113 | +Hibernation is significantly different from any of the system suspend variants. | |
| 114 | +It takes three system state changes to put it into hibernation and two system | |
| 115 | +state changes to resume it. | |
| 116 | + | |
| 117 | +First, when hibernation is triggered, the kernel stops all system activity and | |
| 118 | +creates a snapshot image of memory to be written into persistent storage. Next, | |
| 119 | +the system goes into a state in which the snapshot image can be saved, the image | |
| 120 | +is written out and finally the system goes into the target low-power state in | |
| 121 | +which power is cut from almost all of its hardware components, including memory, | |
| 122 | +except for a limited set of wakeup devices. | |
| 123 | + | |
| 124 | +Once the snapshot image has been written out, the system may either enter a | |
| 125 | +special low-power state (like ACPI S4), or it may simply power down itself. | |
| 126 | +Powering down means minimum power draw and it allows this mechanism to work on | |
| 127 | +any system. However, entering a special low-power state may allow additional | |
| 128 | +means of system wakeup to be used (e.g. pressing a key on the keyboard or | |
| 129 | +opening a laptop lid). | |
| 130 | + | |
| 131 | +After wakeup, control goes to the platform firmware that runs a boot loader | |
| 132 | +which boots a fresh instance of the kernel (control may also go directly to | |
| 133 | +the boot loader, depending on the system configuration, but anyway it causes | |
| 134 | +a fresh instance of the kernel to be booted). That new instance of the kernel | |
| 135 | +(referred to as the ``restore kernel``) looks for a hibernation image in | |
| 136 | +persistent storage and if one is found, it is loaded into memory. Next, all | |
| 137 | +activity in the system is stopped and the restore kernel overwrites itself with | |
| 138 | +the image contents and jumps into a special trampoline area in the original | |
| 139 | +kernel stored in the image (referred to as the ``image kernel``), which is where | |
| 140 | +the special architecture-specific low-level code is needed. Finally, the | |
| 141 | +image kernel restores the system to the pre-hibernation state and allows user | |
| 142 | +space to run again. | |
| 143 | + | |
| 144 | +Hibernation is supported if the :c:macro:`CONFIG_HIBERNATION` kernel | |
| 145 | +configuration option is set. However, this option can only be set if support | |
| 146 | +for the given CPU architecture includes the low-level code for system resume. | |
| 147 | + | |
| 148 | + | |
| 149 | +Basic ``sysfs`` Interfaces for System Suspend and Hibernation | |
| 150 | +============================================================= | |
| 151 | + | |
| 152 | +The following files located in the :file:`/sys/power/` directory can be used by | |
| 153 | +user space for sleep states control. | |
| 154 | + | |
| 155 | +``state`` | |
| 156 | + This file contains a list of strings representing sleep states supported | |
| 157 | + by the kernel. Writing one of these strings into it causes the kernel | |
| 158 | + to start a transition of the system into the sleep state represented by | |
| 159 | + that string. | |
| 160 | + | |
| 161 | + In particular, the strings "disk", "freeze" and "standby" represent the | |
| 162 | + :ref:`hibernation <hibernation>`, :ref:`suspend-to-idle <s2idle>` and | |
| 163 | + :ref:`standby <standby>` sleep states, respectively. The string "mem" | |
| 164 | + is interpreted in accordance with the contents of the ``mem_sleep`` file | |
| 165 | + described below. | |
| 166 | + | |
| 167 | + If the kernel does not support any system sleep states, this file is | |
| 168 | + not present. | |
| 169 | + | |
| 170 | +``mem_sleep`` | |
| 171 | + This file contains a list of strings representing supported system | |
| 172 | + suspend variants and allows user space to select the variant to be | |
| 173 | + associated with the "mem" string in the ``state`` file described above. | |
| 174 | + | |
| 175 | + The strings that may be present in this file are "s2idle", "shallow" | |
| 176 | + and "deep". The string "s2idle" always represents :ref:`suspend-to-idle | |
| 177 | + <s2idle>` and, by convention, "shallow" and "deep" represent | |
| 178 | + :ref:`standby <standby>` and :ref:`suspend-to-RAM <s2ram>`, | |
| 179 | + respectively. | |
| 180 | + | |
| 181 | + Writing one of the listed strings into this file causes the system | |
| 182 | + suspend variant represented by it to be associated with the "mem" string | |
| 183 | + in the ``state`` file. The string representing the suspend variant | |
| 184 | + currently associated with the "mem" string in the ``state`` file | |
| 185 | + is listed in square brackets. | |
| 186 | + | |
| 187 | + If the kernel does not support system suspend, this file is not present. | |
| 188 | + | |
| 189 | +``disk`` | |
| 190 | + This file contains a list of strings representing different operations | |
| 191 | + that can be carried out after the hibernation image has been saved. The | |
| 192 | + possible options are as follows: | |
| 193 | + | |
| 194 | + ``platform`` | |
| 195 | + Put the system into a special low-power state (e.g. ACPI S4) to | |
| 196 | + make additional wakeup options available and possibly allow the | |
| 197 | + platform firmware to take a simplified initialization path after | |
| 198 | + wakeup. | |
| 199 | + | |
| 200 | + ``shutdown`` | |
| 201 | + Power off the system. | |
| 202 | + | |
| 203 | + ``reboot`` | |
| 204 | + Reboot the system (useful for diagnostics mostly). | |
| 205 | + | |
| 206 | + ``suspend`` | |
| 207 | + Hybrid system suspend. Put the system into the suspend sleep | |
| 208 | + state selected through the ``mem_sleep`` file described above. | |
| 209 | + If the system is successfully woken up from that state, discard | |
| 210 | + the hibernation image and continue. Otherwise, use the image | |
| 211 | + to restore the previous state of the system. | |
| 212 | + | |
| 213 | + ``test_resume`` | |
| 214 | + Diagnostic operation. Load the image as though the system had | |
| 215 | + just woken up from hibernation and the currently running kernel | |
| 216 | + instance was a restore kernel and follow up with full system | |
| 217 | + resume. | |
| 218 | + | |
| 219 | + Writing one of the listed strings into this file causes the option | |
| 220 | + represented by it to be selected. | |
| 221 | + | |
| 222 | + The currently selected option is shown in square brackets which means | |
| 223 | + that the operation represented by it will be carried out after creating | |
| 224 | + and saving the image next time hibernation is triggered by writing | |
| 225 | + ``disk`` to :file:`/sys/power/state`. | |
| 226 | + | |
| 227 | + If the kernel does not support hibernation, this file is not present. | |
| 228 | + | |
| 229 | +According to the above, there are two ways to make the system go into the | |
| 230 | +:ref:`suspend-to-idle <s2idle>` state. The first one is to write "freeze" | |
| 231 | +directly to :file:`/sys/power/state`. The second one is to write "s2idle" to | |
| 232 | +:file:`/sys/power/mem_sleep` and then to write "mem" to | |
| 233 | +:file:`/sys/power/state`. Likewise, there are two ways to make the system go | |
| 234 | +into the :ref:`standby <standby>` state (the strings to write to the control | |
| 235 | +files in that case are "standby" or "shallow" and "mem", respectively) if that | |
| 236 | +state is supported by the platform. However, there is only one way to make the | |
| 237 | +system go into the :ref:`suspend-to-RAM <s2ram>` state (write "deep" into | |
| 238 | +:file:`/sys/power/mem_sleep` and "mem" into :file:`/sys/power/state`). | |
| 239 | + | |
| 240 | +The default suspend variant (ie. the one to be used without writing anything | |
| 241 | +into :file:`/sys/power/mem_sleep`) is either "deep" (on the majority of systems | |
| 242 | +supporting :ref:`suspend-to-RAM <s2ram>`) or "s2idle", but it can be overridden | |
| 243 | +by the value of the "mem_sleep_default" parameter in the kernel command line. | |
| 244 | +On some ACPI-based systems, depending on the information in the ACPI tables, the | |
| 245 | +default may be "s2idle" even if :ref:`suspend-to-RAM <s2ram>` is supported. | |
| @@ -0,0 +1,52 @@ | ||
| 1 | +=========================== | |
| 2 | +Power Management Strategies | |
| 3 | +=========================== | |
| 4 | + | |
| 5 | +:: | |
| 6 | + | |
| 7 | + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 8 | + | |
| 9 | +The Linux kernel supports two major high-level power management strategies. | |
| 10 | + | |
| 11 | +One of them is based on using global low-power states of the whole system in | |
| 12 | +which user space code cannot be executed and the overall system activity is | |
| 13 | +significantly reduced, referred to as :doc:`sleep states <sleep-states>`. The | |
| 14 | +kernel puts the system into one of these states when requested by user space | |
| 15 | +and the system stays in it until a special signal is received from one of | |
| 16 | +designated devices, triggering a transition to the ``working state`` in which | |
| 17 | +user space code can run. Because sleep states are global and the whole system | |
| 18 | +is affected by the state changes, this strategy is referred to as the | |
| 19 | +:doc:`system-wide power management <system-wide>`. | |
| 20 | + | |
| 21 | +The other strategy, referred to as the :doc:`working-state power management | |
| 22 | +<working-state>`, is based on adjusting the power states of individual hardware | |
| 23 | +components of the system, as needed, in the working state. In consequence, if | |
| 24 | +this strategy is in use, the working state of the system usually does not | |
| 25 | +correspond to any particular physical configuration of it, but can be treated as | |
| 26 | +a metastate covering a range of different power states of the system in which | |
| 27 | +the individual components of it can be either ``active`` (in use) or | |
| 28 | +``inactive`` (idle). If they are active, they have to be in power states | |
| 29 | +allowing them to process data and to be accessed by software. In turn, if they | |
| 30 | +are inactive, ideally, they should be in low-power states in which they may not | |
| 31 | +be accessible. | |
| 32 | + | |
| 33 | +If all of the system components are active, the system as a whole is regarded as | |
| 34 | +"runtime active" and that situation typically corresponds to the maximum power | |
| 35 | +draw (or maximum energy usage) of it. If all of them are inactive, the system | |
| 36 | +as a whole is regarded as "runtime idle" which may be very close to a sleep | |
| 37 | +state from the physical system configuration and power draw perspective, but | |
| 38 | +then it takes much less time and effort to start executing user space code than | |
| 39 | +for the same system in a sleep state. However, transitions from sleep states | |
| 40 | +back to the working state can only be started by a limited set of devices, so | |
| 41 | +typically the system can spend much more time in a sleep state than it can be | |
| 42 | +runtime idle in one go. For this reason, systems usually use less energy in | |
| 43 | +sleep states than when they are runtime idle most of the time. | |
| 44 | + | |
| 45 | +Moreover, the two power management strategies address different usage scenarios. | |
| 46 | +Namely, if the user indicates that the system will not be in use going forward, | |
| 47 | +for example by closing its lid (if the system is a laptop), it probably should | |
| 48 | +go into a sleep state at that point. On the other hand, if the user simply goes | |
| 49 | +away from the laptop keyboard, it probably should stay in the working state and | |
| 50 | +use the working-state power management in case it becomes idle, because the user | |
| 51 | +may come back to it at any time and then may want the system to be immediately | |
| 52 | +accessible. | |
| @@ -0,0 +1,8 @@ | ||
| 1 | +============================ | |
| 2 | +System-Wide Power Management | |
| 3 | +============================ | |
| 4 | + | |
| 5 | +.. toctree:: | |
| 6 | + :maxdepth: 2 | |
| 7 | + | |
| 8 | + sleep-states | |
| @@ -0,0 +1,9 @@ | ||
| 1 | +============================== | |
| 2 | +Working-State Power Management | |
| 3 | +============================== | |
| 4 | + | |
| 5 | +.. toctree:: | |
| 6 | + :maxdepth: 2 | |
| 7 | + | |
| 8 | + cpufreq | |
| 9 | + intel_pstate | |
| @@ -60,7 +60,7 @@ Example of using a firmware operation: · 59 unmodified lines | ||
| 60 | 60 | |
| 61 | 61 | /* some platform code, e.g. SMP initialization */ |
| 62 | 62 | |
| 63 | − __raw_writel(virt_to_phys(exynos4_secondary_startup), | |
| 63 | + __raw_writel(__pa_symbol(exynos4_secondary_startup), | |
| 64 | 64 | CPU1_BOOT_REG); |
| 65 | 65 | |
| 66 | 66 | /* Call Exynos specific smc call */ |
| @@ -179,6 +179,8 @@ infrastructure: · 178 unmodified lines | ||
| 179 | 179 | | FCMA | [19-16] | y | |
| 180 | 180 | |--------------------------------------------------| |
| 181 | 181 | | JSCVT | [15-12] | y | |
| 182 | + |--------------------------------------------------| | |
| 183 | + | DPB | [3-0] | y | | |
| 182 | 184 | x--------------------------------------------------x |
| 183 | 185 | |
| 184 | 186 | Appendix I: Example |
| @@ -0,0 +1,66 @@ | ||
| 1 | + | |
| 2 | +On atomic bitops. | |
| 3 | + | |
| 4 | + | |
| 5 | +While our bitmap_{}() functions are non-atomic, we have a number of operations | |
| 6 | +operating on single bits in a bitmap that are atomic. | |
| 7 | + | |
| 8 | + | |
| 9 | +API | |
| 10 | +--- | |
| 11 | + | |
| 12 | +The single bit operations are: | |
| 13 | + | |
| 14 | +Non-RMW ops: | |
| 15 | + | |
| 16 | + test_bit() | |
| 17 | + | |
| 18 | +RMW atomic operations without return value: | |
| 19 | + | |
| 20 | + {set,clear,change}_bit() | |
| 21 | + clear_bit_unlock() | |
| 22 | + | |
| 23 | +RMW atomic operations with return value: | |
| 24 | + | |
| 25 | + test_and_{set,clear,change}_bit() | |
| 26 | + test_and_set_bit_lock() | |
| 27 | + | |
| 28 | +Barriers: | |
| 29 | + | |
| 30 | + smp_mb__{before,after}_atomic() | |
| 31 | + | |
| 32 | + | |
| 33 | +All RMW atomic operations have a '__' prefixed variant which is non-atomic. | |
| 34 | + | |
| 35 | + | |
| 36 | +SEMANTICS | |
| 37 | +--------- | |
| 38 | + | |
| 39 | +Non-atomic ops: | |
| 40 | + | |
| 41 | +In particular __clear_bit_unlock() suffers the same issue as atomic_set(), | |
| 42 | +which is why the generic version maps to clear_bit_unlock(), see atomic_t.txt. | |
| 43 | + | |
| 44 | + | |
| 45 | +RMW ops: | |
| 46 | + | |
| 47 | +The test_and_{}_bit() operations return the original value of the bit. | |
| 48 | + | |
| 49 | + | |
| 50 | +ORDERING | |
| 51 | +-------- | |
| 52 | + | |
| 53 | +Like with atomic_t, the rule of thumb is: | |
| 54 | + | |
| 55 | + - non-RMW operations are unordered; | |
| 56 | + | |
| 57 | + - RMW operations that have no return value are unordered; | |
| 58 | + | |
| 59 | + - RMW operations that have a return value are fully ordered. | |
| 60 | + | |
| 61 | +Except for test_and_set_bit_lock() which has ACQUIRE semantics and | |
| 62 | +clear_bit_unlock() which has RELEASE semantics. | |
| 63 | + | |
| 64 | +Since a platform only has a single means of achieving atomic operations | |
| 65 | +the same barriers as for atomic_t are used, see atomic_t.txt. | |
| 66 | + | |
| @@ -0,0 +1,242 @@ | ||
| 1 | + | |
| 2 | +On atomic types (atomic_t atomic64_t and atomic_long_t). | |
| 3 | + | |
| 4 | +The atomic type provides an interface to the architecture's means of atomic | |
| 5 | +RMW operations between CPUs (atomic operations on MMIO are not supported and | |
| 6 | +can lead to fatal traps on some platforms). | |
| 7 | + | |
| 8 | +API | |
| 9 | +--- | |
| 10 | + | |
| 11 | +The 'full' API consists of (atomic64_ and atomic_long_ prefixes omitted for | |
| 12 | +brevity): | |
| 13 | + | |
| 14 | +Non-RMW ops: | |
| 15 | + | |
| 16 | + atomic_read(), atomic_set() | |
| 17 | + atomic_read_acquire(), atomic_set_release() | |
| 18 | + | |
| 19 | + | |
| 20 | +RMW atomic operations: | |
| 21 | + | |
| 22 | +Arithmetic: | |
| 23 | + | |
| 24 | + atomic_{add,sub,inc,dec}() | |
| 25 | + atomic_{add,sub,inc,dec}_return{,_relaxed,_acquire,_release}() | |
| 26 | + atomic_fetch_{add,sub,inc,dec}{,_relaxed,_acquire,_release}() | |
| 27 | + | |
| 28 | + | |
| 29 | +Bitwise: | |
| 30 | + | |
| 31 | + atomic_{and,or,xor,andnot}() | |
| 32 | + atomic_fetch_{and,or,xor,andnot}{,_relaxed,_acquire,_release}() | |
| 33 | + | |
| 34 | + | |
| 35 | +Swap: | |
| 36 | + | |
| 37 | + atomic_xchg{,_relaxed,_acquire,_release}() | |
| 38 | + atomic_cmpxchg{,_relaxed,_acquire,_release}() | |
| 39 | + atomic_try_cmpxchg{,_relaxed,_acquire,_release}() | |
| 40 | + | |
| 41 | + | |
| 42 | +Reference count (but please see refcount_t): | |
| 43 | + | |
| 44 | + atomic_add_unless(), atomic_inc_not_zero() | |
| 45 | + atomic_sub_and_test(), atomic_dec_and_test() | |
| 46 | + | |
| 47 | + | |
| 48 | +Misc: | |
| 49 | + | |
| 50 | + atomic_inc_and_test(), atomic_add_negative() | |
| 51 | + atomic_dec_unless_positive(), atomic_inc_unless_negative() | |
| 52 | + | |
| 53 | + | |
| 54 | +Barriers: | |
| 55 | + | |
| 56 | + smp_mb__{before,after}_atomic() | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | +SEMANTICS | |
| 61 | +--------- | |
| 62 | + | |
| 63 | +Non-RMW ops: | |
| 64 | + | |
| 65 | +The non-RMW ops are (typically) regular LOADs and STOREs and are canonically | |
| 66 | +implemented using READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and | |
| 67 | +smp_store_release() respectively. | |
| 68 | + | |
| 69 | +The one detail to this is that atomic_set{}() should be observable to the RMW | |
| 70 | +ops. That is: | |
| 71 | + | |
| 72 | + C atomic-set | |
| 73 | + | |
| 74 | + { | |
| 75 | + atomic_set(v, 1); | |
| 76 | + } | |
| 77 | + | |
| 78 | + P1(atomic_t *v) | |
| 79 | + { | |
| 80 | + atomic_add_unless(v, 1, 0); | |
| 81 | + } | |
| 82 | + | |
| 83 | + P2(atomic_t *v) | |
| 84 | + { | |
| 85 | + atomic_set(v, 0); | |
| 86 | + } | |
| 87 | + | |
| 88 | + exists | |
| 89 | + (v=2) | |
| 90 | + | |
| 91 | +In this case we would expect the atomic_set() from CPU1 to either happen | |
| 92 | +before the atomic_add_unless(), in which case that latter one would no-op, or | |
| 93 | +_after_ in which case we'd overwrite its result. In no case is "2" a valid | |
| 94 | +outcome. | |
| 95 | + | |
| 96 | +This is typically true on 'normal' platforms, where a regular competing STORE | |
| 97 | +will invalidate a LL/SC or fail a CMPXCHG. | |
| 98 | + | |
| 99 | +The obvious case where this is not so is when we need to implement atomic ops | |
| 100 | +with a lock: | |
| 101 | + | |
| 102 | + CPU0 CPU1 | |
| 103 | + | |
| 104 | + atomic_add_unless(v, 1, 0); | |
| 105 | + lock(); | |
| 106 | + ret = READ_ONCE(v->counter); // == 1 | |
| 107 | + atomic_set(v, 0); | |
| 108 | + if (ret != u) WRITE_ONCE(v->counter, 0); | |
| 109 | + WRITE_ONCE(v->counter, ret + 1); | |
| 110 | + unlock(); | |
| 111 | + | |
| 112 | +the typical solution is to then implement atomic_set{}() with atomic_xchg(). | |
| 113 | + | |
| 114 | + | |
| 115 | +RMW ops: | |
| 116 | + | |
| 117 | +These come in various forms: | |
| 118 | + | |
| 119 | + - plain operations without return value: atomic_{}() | |
| 120 | + | |
| 121 | + - operations which return the modified value: atomic_{}_return() | |
| 122 | + | |
| 123 | + these are limited to the arithmetic operations because those are | |
| 124 | + reversible. Bitops are irreversible and therefore the modified value | |
| 125 | + is of dubious utility. | |
| 126 | + | |
| 127 | + - operations which return the original value: atomic_fetch_{}() | |
| 128 | + | |
| 129 | + - swap operations: xchg(), cmpxchg() and try_cmpxchg() | |
| 130 | + | |
| 131 | + - misc; the special purpose operations that are commonly used and would, | |
| 132 | + given the interface, normally be implemented using (try_)cmpxchg loops but | |
| 133 | + are time critical and can, (typically) on LL/SC architectures, be more | |
| 134 | + efficiently implemented. | |
| 135 | + | |
| 136 | +All these operations are SMP atomic; that is, the operations (for a single | |
| 137 | +atomic variable) can be fully ordered and no intermediate state is lost or | |
| 138 | +visible. | |
| 139 | + | |
| 140 | + | |
| 141 | +ORDERING (go read memory-barriers.txt first) | |
| 142 | +-------- | |
| 143 | + | |
| 144 | +The rule of thumb: | |
| 145 | + | |
| 146 | + - non-RMW operations are unordered; | |
| 147 | + | |
| 148 | + - RMW operations that have no return value are unordered; | |
| 149 | + | |
| 150 | + - RMW operations that have a return value are fully ordered; | |
| 151 | + | |
| 152 | + - RMW operations that are conditional are unordered on FAILURE, | |
| 153 | + otherwise the above rules apply. | |
| 154 | + | |
| 155 | +Except of course when an operation has an explicit ordering like: | |
| 156 | + | |
| 157 | + {}_relaxed: unordered | |
| 158 | + {}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE | |
| 159 | + {}_release: the W of the RMW (or atomic_set) is a RELEASE | |
| 160 | + | |
| 161 | +Where 'unordered' is against other memory locations. Address dependencies are | |
| 162 | +not defeated. | |
| 163 | + | |
| 164 | +Fully ordered primitives are ordered against everything prior and everything | |
| 165 | +subsequent. Therefore a fully ordered primitive is like having an smp_mb() | |
| 166 | +before and an smp_mb() after the primitive. | |
| 167 | + | |
| 168 | + | |
| 169 | +The barriers: | |
| 170 | + | |
| 171 | + smp_mb__{before,after}_atomic() | |
| 172 | + | |
| 173 | +only apply to the RMW ops and can be used to augment/upgrade the ordering | |
| 174 | +inherent to the used atomic op. These barriers provide a full smp_mb(). | |
| 175 | + | |
| 176 | +These helper barriers exist because architectures have varying implicit | |
| 177 | +ordering on their SMP atomic primitives. For example our TSO architectures | |
| 178 | +provide full ordered atomics and these barriers are no-ops. | |
| 179 | + | |
| 180 | +Thus: | |
| 181 | + | |
| 182 | + atomic_fetch_add(); | |
| 183 | + | |
| 184 | +is equivalent to: | |
| 185 | + | |
| 186 | + smp_mb__before_atomic(); | |
| 187 | + atomic_fetch_add_relaxed(); | |
| 188 | + smp_mb__after_atomic(); | |
| 189 | + | |
| 190 | +However the atomic_fetch_add() might be implemented more efficiently. | |
| 191 | + | |
| 192 | +Further, while something like: | |
| 193 | + | |
| 194 | + smp_mb__before_atomic(); | |
| 195 | + atomic_dec(&X); | |
| 196 | + | |
| 197 | +is a 'typical' RELEASE pattern, the barrier is strictly stronger than | |
| 198 | +a RELEASE. Similarly for something like: | |
| 199 | + | |
| 200 | + atomic_inc(&X); | |
| 201 | + smp_mb__after_atomic(); | |
| 202 | + | |
| 203 | +is an ACQUIRE pattern (though very much not typical), but again the barrier is | |
| 204 | +strictly stronger than ACQUIRE. As illustrated: | |
| 205 | + | |
| 206 | + C strong-acquire | |
| 207 | + | |
| 208 | + { | |
| 209 | + } | |
| 210 | + | |
| 211 | + P1(int *x, atomic_t *y) | |
| 212 | + { | |
| 213 | + r0 = READ_ONCE(*x); | |
| 214 | + smp_rmb(); | |
| 215 | + r1 = atomic_read(y); | |
| 216 | + } | |
| 217 | + | |
| 218 | + P2(int *x, atomic_t *y) | |
| 219 | + { | |
| 220 | + atomic_inc(y); | |
| 221 | + smp_mb__after_atomic(); | |
| 222 | + WRITE_ONCE(*x, 1); | |
| 223 | + } | |
| 224 | + | |
| 225 | + exists | |
| 226 | + (r0=1 /\ r1=0) | |
| 227 | + | |
| 228 | +This should not happen; but a hypothetical atomic_inc_acquire() -- | |
| 229 | +(void)atomic_fetch_inc_acquire() for instance -- would allow the outcome, | |
| 230 | +since then: | |
| 231 | + | |
| 232 | + P1 P2 | |
| 233 | + | |
| 234 | + t = LL.acq *y (0) | |
| 235 | + t++; | |
| 236 | + *x = 1; | |
| 237 | + r0 = *x (1) | |
| 238 | + RMB | |
| 239 | + r1 = *y (0) | |
| 240 | + SC *y, t; | |
| 241 | + | |
| 242 | +is allowed. | |
| @@ -16,14 +16,16 @@ throughput. So, when needed for achieving a lower latency, BFQ builds · 15 unmodified lines | ||
| 16 | 16 | schedules that may lead to a lower throughput. If your main or only |
| 17 | 17 | goal, for a given device, is to achieve the maximum-possible |
| 18 | 18 | throughput at all times, then do switch off all low-latency heuristics |
| 19 | −for that device, by setting low_latency to 0. Full details in Section 3. | |
| 19 | +for that device, by setting low_latency to 0. See Section 3 for | |
| 20 | +details on how to configure BFQ for the desired tradeoff between | |
| 21 | +latency and throughput, or on how to maximize throughput. | |
| 20 | 22 | |
| 21 | 23 | On average CPUs, the current version of BFQ can handle devices |
| 22 | 24 | performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a |
| 23 | 25 | reference, 30-50 KIOPS correspond to very high bandwidths with |
| 24 | 26 | sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and |
| 25 | −to 120-200 MB/s with 4KB random I/O. BFQ has not yet been tested on | |
| 26 | −multi-queue devices. | |
| 27 | +to 120-200 MB/s with 4KB random I/O. BFQ is currently being tested on | |
| 28 | +multi-queue devices too. | |
| 27 | 29 | |
| 28 | 30 | The table of contents follow. Impatients can just jump to Section 3. |
| 29 | 31 | |
| @@ -33,7 +35,7 @@ CONTENTS · 3 unmodified lines | ||
| 33 | 35 | 1-1 Personal systems |
| 34 | 36 | 1-2 Server systems |
| 35 | 37 | 2. How does BFQ work? |
| 36 | −3. What are BFQ's tunable? | |
| 38 | +3. What are BFQ's tunables and how to properly configure BFQ? | |
| 37 | 39 | 4. BFQ group scheduling |
| 38 | 40 | 4-1 Service guarantees provided |
| 39 | 41 | 4-2 Interface |
| @@ -145,19 +147,28 @@ plus a lot of code, are borrowed from CFQ. · 105 unmodified lines | ||
| 145 | 147 | contrast, BFQ may idle the device for a short time interval, |
| 146 | 148 | giving the process the chance to go on being served if it issues |
| 147 | 149 | a new request in time. Device idling typically boosts the |
| 148 | − throughput on rotational devices, if processes do synchronous | |
| 149 | − and sequential I/O. In addition, under BFQ, device idling is | |
| 150 | − also instrumental in guaranteeing the desired throughput | |
| 151 | − fraction to processes issuing sync requests (see the description | |
| 152 | − of the slice_idle tunable in this document, or [1, 2], for more | |
| 153 | − details). | |
| 150 | + throughput on rotational devices and on non-queueing flash-based | |
| 151 | + devices, if processes do synchronous and sequential I/O. In | |
| 152 | + addition, under BFQ, device idling is also instrumental in | |
| 153 | + guaranteeing the desired throughput fraction to processes | |
| 154 | + issuing sync requests (see the description of the slice_idle | |
| 155 | + tunable in this document, or [1, 2], for more details). | |
| 154 | 156 | |
| 155 | 157 | - With respect to idling for service guarantees, if several |
| 156 | 158 | processes are competing for the device at the same time, but |
| 157 | − all processes (and groups, after the following commit) have | |
| 158 | − the same weight, then BFQ guarantees the expected throughput | |
| 159 | − distribution without ever idling the device. Throughput is | |
| 160 | − thus as high as possible in this common scenario. | |
| 159 | + all processes and groups have the same weight, then BFQ | |
| 160 | + guarantees the expected throughput distribution without ever | |
| 161 | + idling the device. Throughput is thus as high as possible in | |
| 162 | + this common scenario. | |
| 163 | + | |
| 164 | + - On flash-based storage with internal queueing of commands | |
| 165 | + (typically NCQ), device idling happens to be always detrimental | |
| 166 | + for throughput. So, with these devices, BFQ performs idling | |
| 167 | + only when strictly needed for service guarantees, i.e., for | |
| 168 | + guaranteeing low latency or fairness. In these cases, overall | |
| 169 | + throughput may be sub-optimal. No solution currently exists to | |
| 170 | + provide both strong service guarantees and optimal throughput | |
| 171 | + on devices with internal queueing. | |
| 161 | 172 | |
| 162 | 173 | - If low-latency mode is enabled (default configuration), BFQ |
| 163 | 174 | executes some special heuristics to detect interactive and soft |
| @@ -191,10 +202,7 @@ plus a lot of code, are borrowed from CFQ. · 27 unmodified lines | ||
| 191 | 202 | - Queues are scheduled according to a variant of WF2Q+, named |
| 192 | 203 | B-WF2Q+, and implemented using an augmented rb-tree to preserve an |
| 193 | 204 | O(log N) overall complexity. See [2] for more details. B-WF2Q+ is |
| 194 | − also ready for hierarchical scheduling. However, for a cleaner | |
| 195 | − logical breakdown, the code that enables and completes | |
| 196 | − hierarchical support is provided in the next commit, which focuses | |
| 197 | − exactly on this feature. | |
| 205 | + also ready for hierarchical scheduling, details in Section 4. | |
| 198 | 206 | |
| 199 | 207 | - B-WF2Q+ guarantees a tight deviation with respect to an ideal, |
| 200 | 208 | perfectly fair, and smooth service. In particular, B-WF2Q+ |
| @@ -249,13 +257,24 @@ plus a lot of code, are borrowed from CFQ. · 48 unmodified lines | ||
| 249 | 257 | the Idle class, to prevent it from starving. |
| 250 | 258 | |
| 251 | 259 | |
| 252 | −3. What are BFQ's tunable? | |
| 253 | −========================== | |
| 260 | +3. What are BFQ's tunables and how to properly configure BFQ? | |
| 261 | +============================================================= | |
| 262 | + | |
| 263 | +Most BFQ tunables affect service guarantees (basically latency and | |
| 264 | +fairness) and throughput. For full details on how to choose the | |
| 265 | +desired tradeoff between service guarantees and throughput, see the | |
| 266 | +parameters slice_idle, strict_guarantees and low_latency. For details | |
| 267 | +on how to maximise throughput, see slice_idle, timeout_sync and | |
| 268 | +max_budget. The other performance-related parameters have been | |
| 269 | +inherited from, and have been preserved mostly for compatibility with | |
| 270 | +CFQ. So far, no performance improvement has been reported after | |
| 271 | +changing the latter parameters in BFQ. | |
| 254 | 272 | |
| 255 | −The tunables back_seek-max, back_seek_penalty, fifo_expire_async and | |
| 256 | −fifo_expire_sync below are the same as in CFQ. Their description is | |
| 257 | −just copied from that for CFQ. Some considerations in the description | |
| 258 | −of slice_idle are copied from CFQ too. | |
| 273 | +In particular, the tunables back_seek-max, back_seek_penalty, | |
| 274 | +fifo_expire_async and fifo_expire_sync below are the same as in | |
| 275 | +CFQ. Their description is just copied from that for CFQ. Some | |
| 276 | +considerations in the description of slice_idle are copied from CFQ | |
| 277 | +too. | |
| 259 | 278 | |
| 260 | 279 | per-process ioprio and weight |
| 261 | 280 | ----------------------------- |
| @@ -285,15 +304,17 @@ number of seeks and see improved throughput. · 23 unmodified lines | ||
| 285 | 304 | |
| 286 | 305 | Setting slice_idle to 0 will remove all the idling on queues and one |
| 287 | 306 | should see an overall improved throughput on faster storage devices |
| 288 | −like multiple SATA/SAS disks in hardware RAID configuration. | |
| 307 | +like multiple SATA/SAS disks in hardware RAID configuration, as well | |
| 308 | +as flash-based storage with internal command queueing (and | |
| 309 | +parallelism). | |
| 289 | 310 | |
| 290 | 311 | So depending on storage and workload, it might be useful to set |
| 291 | 312 | slice_idle=0. In general for SATA/SAS disks and software RAID of |
| 292 | 313 | SATA/SAS disks keeping slice_idle enabled should be useful. For any |
| 293 | 314 | configurations where there are multiple spindles behind single LUN |
| 294 | −(Host based hardware RAID controller or for storage arrays), setting | |
| 295 | −slice_idle=0 might end up in better throughput and acceptable | |
| 296 | −latencies. | |
| 315 | +(Host based hardware RAID controller or for storage arrays), or with | |
| 316 | +flash-based fast storage, setting slice_idle=0 might end up in better | |
| 317 | +throughput and acceptable latencies. | |
| 297 | 318 | |
| 298 | 319 | Idling is however necessary to have service guarantees enforced in |
| 299 | 320 | case of differentiated weights or differentiated I/O-request lengths. |
| @@ -312,13 +333,14 @@ There is an important flipside for idling: apart from the above cases · 12 unmodified lines | ||
| 312 | 333 | where it is beneficial also for throughput, idling can severely impact |
| 313 | 334 | throughput. One important case is random workload. Because of this |
| 314 | 335 | issue, BFQ tends to avoid idling as much as possible, when it is not |
| 315 | −beneficial also for throughput. As a consequence of this behavior, and | |
| 316 | −of further issues described for the strict_guarantees tunable, | |
| 317 | −short-term service guarantees may be occasionally violated. And, in | |
| 318 | −some cases, these guarantees may be more important than guaranteeing | |
| 319 | −maximum throughput. For example, in video playing/streaming, a very | |
| 320 | −low drop rate may be more important than maximum throughput. In these | |
| 321 | −cases, consider setting the strict_guarantees parameter. | |
| 336 | +beneficial also for throughput (as detailed in Section 2). As a | |
| 337 | +consequence of this behavior, and of further issues described for the | |
| 338 | +strict_guarantees tunable, short-term service guarantees may be | |
| 339 | +occasionally violated. And, in some cases, these guarantees may be | |
| 340 | +more important than guaranteeing maximum throughput. For example, in | |
| 341 | +video playing/streaming, a very low drop rate may be more important | |
| 342 | +than maximum throughput. In these cases, consider setting the | |
| 343 | +strict_guarantees parameter. | |
| 322 | 344 | |
| 323 | 345 | strict_guarantees |
| 324 | 346 | ----------------- |
| @@ -420,6 +442,13 @@ The default value is 0, which enables auto-tuning: BFQ sets max_budget · 95 unmodified lines | ||
| 420 | 442 | to the maximum number of sectors that can be served during |
| 421 | 443 | timeout_sync, according to the estimated peak rate. |
| 422 | 444 | |
| 445 | +For specific devices, some users have occasionally reported to have | |
| 446 | +reached a higher throughput by setting max_budget explicitly, i.e., by | |
| 447 | +setting max_budget to a higher value than 0. In particular, they have | |
| 448 | +set max_budget to higher values than those to which BFQ would have set | |
| 449 | +it with auto-tuning. An alternative way to achieve this goal is to | |
| 450 | +just increase the value of timeout_sync, leaving max_budget equal to 0. | |
| 451 | + | |
| 423 | 452 | weights |
| 424 | 453 | ------- |
| 425 | 454 | |
| @@ -427,51 +456,6 @@ Read-only parameter, used to show the weights of the currently active · 1 unmodified line | ||
| 427 | 456 | BFQ queues. |
| 428 | 457 | |
| 429 | 458 | |
| 430 | −wr_ tunables | |
| 431 | −------------ | |
| 432 | − | |
| 433 | −BFQ exports a few parameters to control/tune the behavior of | |
| 434 | −low-latency heuristics. | |
| 435 | − | |
| 436 | −wr_coeff | |
| 437 | − | |
| 438 | −Factor by which the weight of a weight-raised queue is multiplied. If | |
| 439 | −the queue is deemed soft real-time, then the weight is further | |
| 440 | −multiplied by an additional, constant factor. | |
| 441 | − | |
| 442 | −wr_max_time | |
| 443 | − | |
| 444 | −Maximum duration of a weight-raising period for an interactive task | |
| 445 | −(ms). If set to zero (default value), then this value is computed | |
| 446 | −automatically, as a function of the peak rate of the device. In any | |
| 447 | −case, when the value of this parameter is read, it always reports the | |
| 448 | −current duration, regardless of whether it has been set manually or | |
| 449 | −computed automatically. | |
| 450 | − | |
| 451 | −wr_max_softrt_rate | |
| 452 | − | |
| 453 | −Maximum service rate below which a queue is deemed to be associated | |
| 454 | −with a soft real-time application, and is then weight-raised | |
| 455 | −accordingly (sectors/sec). | |
| 456 | − | |
| 457 | −wr_min_idle_time | |
| 458 | − | |
| 459 | −Minimum idle period after which interactive weight-raising may be | |
| 460 | −reactivated for a queue (in ms). | |
| 461 | − | |
| 462 | −wr_rt_max_time | |
| 463 | − | |
| 464 | −Maximum weight-raising duration for soft real-time queues (in ms). The | |
| 465 | −start time from which this duration is considered is automatically | |
| 466 | −moved forward if the queue is detected to be still soft real-time | |
| 467 | −before the current soft real-time weight-raising period finishes. | |
| 468 | − | |
| 469 | −wr_min_inter_arr_async | |
| 470 | − | |
| 471 | −Minimum period between I/O request arrivals after which weight-raising | |
| 472 | −may be reactivated for an already busy async queue (in ms). | |
| 473 | − | |
| 474 | − | |
| 475 | 459 | 4. Group scheduling with BFQ |
| 476 | 460 | ============================ |
| 477 | 461 | |
| @@ -1,194 +0,0 @@ | ||
| 1 | −This driver is for Compaq's SMART Array Controllers. | |
| 2 | − | |
| 3 | −Supported Cards: | |
| 4 | −---------------- | |
| 5 | − | |
| 6 | −This driver is known to work with the following cards: | |
| 7 | − | |
| 8 | − * SA 5300 | |
| 9 | − * SA 5i | |
| 10 | − * SA 532 | |
| 11 | − * SA 5312 | |
| 12 | − * SA 641 | |
| 13 | − * SA 642 | |
| 14 | − * SA 6400 | |
| 15 | − * SA 6400 U320 Expansion Module | |
| 16 | − * SA 6i | |
| 17 | − * SA P600 | |
| 18 | − * SA P800 | |
| 19 | − * SA E400 | |
| 20 | − * SA P400i | |
| 21 | − * SA E200 | |
| 22 | − * SA E200i | |
| 23 | − * SA E500 | |
| 24 | − * SA P700m | |
| 25 | − * SA P212 | |
| 26 | − * SA P410 | |
| 27 | − * SA P410i | |
| 28 | − * SA P411 | |
| 29 | − * SA P812 | |
| 30 | − * SA P712m | |
| 31 | − * SA P711m | |
| 32 | − | |
| 33 | −Detecting drive failures: | |
| 34 | −------------------------- | |
| 35 | − | |
| 36 | −To get the status of logical volumes and to detect physical drive | |
| 37 | −failures, you can use the cciss_vol_status program found here: | |
| 38 | −http://cciss.sourceforge.net/#cciss_utils | |
| 39 | − | |
| 40 | −Device Naming: | |
| 41 | −-------------- | |
| 42 | − | |
| 43 | −If nodes are not already created in the /dev/cciss directory, run as root: | |
| 44 | − | |
| 45 | −# cd /dev | |
| 46 | −# ./MAKEDEV cciss | |
| 47 | − | |
| 48 | −You need some entries in /dev for the cciss device. The MAKEDEV script | |
| 49 | −can make device nodes for you automatically. Currently the device setup | |
| 50 | −is as follows: | |
| 51 | − | |
| 52 | −Major numbers: | |
| 53 | − 104 cciss0 | |
| 54 | − 105 cciss1 | |
| 55 | − 106 cciss2 | |
| 56 | − 105 cciss3 | |
| 57 | − 108 cciss4 | |
| 58 | − 109 cciss5 | |
| 59 | − 110 cciss6 | |
| 60 | − 111 cciss7 | |
| 61 | − | |
| 62 | −Minor numbers: | |
| 63 | − b7 b6 b5 b4 b3 b2 b1 b0 | |
| 64 | − |----+----| |----+----| | |
| 65 | − | | | |
| 66 | − | +-------- Partition ID (0=wholedev, 1-15 partition) | |
| 67 | − | | |
| 68 | − +-------------------- Logical Volume number | |
| 69 | − | |
| 70 | −The device naming scheme is: | |
| 71 | −/dev/cciss/c0d0 Controller 0, disk 0, whole device | |
| 72 | −/dev/cciss/c0d0p1 Controller 0, disk 0, partition 1 | |
| 73 | −/dev/cciss/c0d0p2 Controller 0, disk 0, partition 2 | |
| 74 | −/dev/cciss/c0d0p3 Controller 0, disk 0, partition 3 | |
| 75 | − | |
| 76 | −/dev/cciss/c1d1 Controller 1, disk 1, whole device | |
| 77 | −/dev/cciss/c1d1p1 Controller 1, disk 1, partition 1 | |
| 78 | −/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 | |
| 79 | −/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3 | |
| 80 | − | |
| 81 | −CCISS simple mode support | |
| 82 | −------------------------- | |
| 83 | − | |
| 84 | −The "cciss_simple_mode=1" boot parameter may be used to prevent the driver | |
| 85 | −from putting the controller into "performant" mode. The difference is that | |
| 86 | −with simple mode, each command completion requires an interrupt, while with | |
| 87 | −"performant mode" (the default, and ordinarily better performing) it is | |
| 88 | −possible to have multiple command completions indicated by a single | |
| 89 | −interrupt. | |
| 90 | − | |
| 91 | −SCSI tape drive and medium changer support | |
| 92 | −------------------------------------------ | |
| 93 | − | |
| 94 | −SCSI sequential access devices and medium changer devices are supported and | |
| 95 | −appropriate device nodes are automatically created. (e.g. | |
| 96 | −/dev/st0, /dev/st1, etc. See the "st" man page for more details.) | |
| 97 | −You must enable "SCSI tape drive support for Smart Array 5xxx" and | |
| 98 | −"SCSI support" in your kernel configuration to be able to use SCSI | |
| 99 | −tape drives with your Smart Array 5xxx controller. | |
| 100 | − | |
| 101 | −Additionally, note that the driver will engage the SCSI core at init | |
| 102 | −time if any tape drives or medium changers are detected. The driver may | |
| 103 | −also be directed to dynamically engage the SCSI core via the /proc filesystem | |
| 104 | −entry which the "block" side of the driver creates as | |
| 105 | −/proc/driver/cciss/cciss* at runtime. This is best done via a script. | |
| 106 | − | |
| 107 | −For example: | |
| 108 | − | |
| 109 | − for x in /proc/driver/cciss/cciss[0-9]* | |
| 110 | − do | |
| 111 | − echo "engage scsi" > $x | |
| 112 | − done | |
| 113 | − | |
| 114 | −Once the SCSI core is engaged by the driver, it cannot be disengaged | |
| 115 | −(except by unloading the driver, if it happens to be linked as a module.) | |
| 116 | − | |
| 117 | −Note also that if no sequential access devices or medium changers are | |
| 118 | −detected, the SCSI core will not be engaged by the action of the above | |
| 119 | −script. | |
| 120 | − | |
| 121 | −Hot plug support for SCSI tape drives | |
| 122 | −------------------------------------- | |
| 123 | − | |
| 124 | −Hot plugging of SCSI tape drives is supported, with some caveats. | |
| 125 | −The cciss driver must be informed that changes to the SCSI bus | |
| 126 | −have been made. This may be done via the /proc filesystem. | |
| 127 | −For example: | |
| 128 | − | |
| 129 | − echo "rescan" > /proc/scsi/cciss0/1 | |
| 130 | − | |
| 131 | −This causes the driver to query the adapter about changes to the | |
| 132 | −physical SCSI buses and/or fibre channel arbitrated loop and the | |
| 133 | −driver to make note of any new or removed sequential access devices | |
| 134 | −or medium changers. The driver will output messages indicating what | |
| 135 | −devices have been added or removed and the controller, bus, target and | |
| 136 | −lun used to address the device. It then notifies the SCSI mid layer | |
| 137 | −of these changes. | |
| 138 | − | |
| 139 | −Note that the naming convention of the /proc filesystem entries | |
| 140 | −contains a number in addition to the driver name. (E.g. "cciss0" | |
| 141 | −instead of just "cciss" which you might expect.) | |
| 142 | − | |
| 143 | −Note: ONLY sequential access devices and medium changers are presented | |
| 144 | −as SCSI devices to the SCSI mid layer by the cciss driver. Specifically, | |
| 145 | −physical SCSI disk drives are NOT presented to the SCSI mid layer. The | |
| 146 | −physical SCSI disk drives are controlled directly by the array controller | |
| 147 | −hardware and it is important to prevent the kernel from attempting to directly | |
| 148 | −access these devices too, as if the array controller were merely a SCSI | |
| 149 | −controller in the same way that we are allowing it to access SCSI tape drives. | |
| 150 | − | |
| 151 | −SCSI error handling for tape drives and medium changers | |
| 152 | −------------------------------------------------------- | |
| 153 | − | |
| 154 | −The linux SCSI mid layer provides an error handling protocol which | |
| 155 | −kicks into gear whenever a SCSI command fails to complete within a | |
| 156 | −certain amount of time (which can vary depending on the command). | |
| 157 | −The cciss driver participates in this protocol to some extent. The | |
| 158 | −normal protocol is a four step process. First the device is told | |
| 159 | −to abort the command. If that doesn't work, the device is reset. | |
| 160 | −If that doesn't work, the SCSI bus is reset. If that doesn't work | |
| 161 | −the host bus adapter is reset. Because the cciss driver is a block | |
| 162 | −driver as well as a SCSI driver and only the tape drives and medium | |
| 163 | −changers are presented to the SCSI mid layer, and unlike more | |
| 164 | −straightforward SCSI drivers, disk i/o continues through the block | |
| 165 | −side during the SCSI error recovery process, the cciss driver only | |
| 166 | −implements the first two of these actions, aborting the command, and | |
| 167 | −resetting the device. Additionally, most tape drives will not oblige | |
| 168 | −in aborting commands, and sometimes it appears they will not even | |
| 169 | −obey a reset command, though in most circumstances they will. In | |
| 170 | −the case that the command cannot be aborted and the device cannot be | |
| 171 | −reset, the device will be set offline. | |
| 172 | − | |
| 173 | −In the event the error handling code is triggered and a tape drive is | |
| 174 | −successfully reset or the tardy command is successfully aborted, the | |
| 175 | −tape drive may still not allow i/o to continue until some command | |
| 176 | −is issued which positions the tape to a known position. Typically you | |
| 177 | −must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) | |
| 178 | −before i/o can proceed again to a tape drive which was reset. | |
| 179 | − | |
| 180 | −There is a cciss_tape_cmds module parameter which can be used to make cciss | |
| 181 | −allocate more commands for use by tape drives. Ordinarily only a few commands | |
| 182 | −(6) are allocated for tape drives because tape drives are slow and | |
| 183 | −infrequently used and the primary purpose of Smart Array controllers is to | |
| 184 | −act as a RAID controller for disk drives, so the vast majority of commands | |
| 185 | −are allocated for disk devices. However, if you have more than a few tape | |
| 186 | −drives attached to a smart array, the default number of commands may not be | |
| 187 | −enough (for example, if you have 8 tape drives, you could only rewind 6 | |
| 188 | −at one time with the default number of commands.) The cciss_tape_cmds module | |
| 189 | −parameter allows more commands (up to 16 more) to be allocated for use by | |
| 190 | −tape drives. For example: | |
| 191 | − | |
| 192 | − insmod cciss.ko cciss_tape_cmds=16 | |
| 193 | − | |
| 194 | −Or, as a kernel boot parameter passed in via grub: cciss.cciss_tape_cmds=8 | |
| @@ -168,6 +168,7 @@ max_comp_streams RW the number of possible concurrent compress operations · 167 unmodified lines | ||
| 168 | 168 | comp_algorithm RW show and change the compression algorithm |
| 169 | 169 | compact WO trigger memory compaction |
| 170 | 170 | debug_stat RO this file is used for zram debugging purposes |
| 171 | +backing_dev RW set up backend storage for zram to write out | |
| 171 | 172 | |
| 172 | 173 | |
| 173 | 174 | User space is advised to use the following files to read the device statistics. |
| @@ -231,5 +232,15 @@ line of text and contains the following stats separated by whitespace: · 57 unmodified lines | ||
| 231 | 232 | resets the disksize to zero. You must set the disksize again |
| 232 | 233 | before reusing the device. |
| 233 | 234 | |
| 235 | +* Optional Feature | |
| 236 | + | |
| 237 | += writeback | |
| 238 | + | |
| 239 | +With incompressible pages, there is no memory saving with zram. | |
| 240 | +Instead, with CONFIG_ZRAM_WRITEBACK, zram can write incompressible page | |
| 241 | +to backing storage rather than keeping it in memory. | |
| 242 | +User should set up backing device via /sys/block/zramX/backing_dev | |
| 243 | +before disksize setting. | |
| 244 | + | |
| 234 | 245 | Nitin Gupta |
| 235 | 246 | ngupta@vflare.org |
| @@ -18,7 +18,9 @@ v1 is available under Documentation/cgroup-v1/. · 17 unmodified lines | ||
| 18 | 18 | 1-2. What is cgroup? |
| 19 | 19 | 2. Basic Operations |
| 20 | 20 | 2-1. Mounting |
| 21 | − 2-2. Organizing Processes | |
| 21 | + 2-2. Organizing Processes and Threads | |
| 22 | + 2-2-1. Processes | |
| 23 | + 2-2-2. Threads | |
| 22 | 24 | 2-3. [Un]populated Notification |
| 23 | 25 | 2-4. Controlling Controllers |
| 24 | 26 | 2-4-1. Enabling and Disabling |
| @@ -167,8 +169,11 @@ cgroup v2 currently supports the following mount options. · 142 unmodified lines | ||
| 167 | 169 | Delegation section for details. |
| 168 | 170 | |
| 169 | 171 | |
| 170 | −Organizing Processes | |
| 171 | −-------------------- | |
| 172 | +Organizing Processes and Threads | |
| 173 | +-------------------------------- | |
| 174 | + | |
| 175 | +Processes | |
| 176 | +~~~~~~~~~ | |
| 172 | 177 | |
| 173 | 178 | Initially, only the root cgroup exists to which all processes belong. |
| 174 | 179 | A child cgroup can be created by creating a sub-directory:: |
| @@ -219,6 +224,105 @@ is removed subsequently, " (deleted)" is appended to the path:: · 44 unmodified lines | ||
| 219 | 224 | 0::/test-cgroup/test-cgroup-nested (deleted) |
| 220 | 225 | |
| 221 | 226 | |
| 227 | +Threads | |
| 228 | +~~~~~~~ | |
| 229 | + | |
| 230 | +cgroup v2 supports thread granularity for a subset of controllers to | |
| 231 | +support use cases requiring hierarchical resource distribution across | |
| 232 | +the threads of a group of processes. By default, all threads of a | |
| 233 | +process belong to the same cgroup, which also serves as the resource | |
| 234 | +domain to host resource consumptions which are not specific to a | |
| 235 | +process or thread. The thread mode allows threads to be spread across | |
| 236 | +a subtree while still maintaining the common resource domain for them. | |
| 237 | + | |
| 238 | +Controllers which support thread mode are called threaded controllers. | |
| 239 | +The ones which don't are called domain controllers. | |
| 240 | + | |
| 241 | +Marking a cgroup threaded makes it join the resource domain of its | |
| 242 | +parent as a threaded cgroup. The parent may be another threaded | |
| 243 | +cgroup whose resource domain is further up in the hierarchy. The root | |
| 244 | +of a threaded subtree, that is, the nearest ancestor which is not | |
| 245 | +threaded, is called threaded domain or thread root interchangeably and | |
| 246 | +serves as the resource domain for the entire subtree. | |
| 247 | + | |
| 248 | +Inside a threaded subtree, threads of a process can be put in | |
| 249 | +different cgroups and are not subject to the no internal process | |
| 250 | +constraint - threaded controllers can be enabled on non-leaf cgroups | |
| 251 | +whether they have threads in them or not. | |
| 252 | + | |
| 253 | +As the threaded domain cgroup hosts all the domain resource | |
| 254 | +consumptions of the subtree, it is considered to have internal | |
| 255 | +resource consumptions whether there are processes in it or not and | |
| 256 | +can't have populated child cgroups which aren't threaded. Because the | |
| 257 | +root cgroup is not subject to no internal process constraint, it can | |
| 258 | +serve both as a threaded domain and a parent to domain cgroups. | |
| 259 | + | |
| 260 | +The current operation mode or type of the cgroup is shown in the | |
| 261 | +"cgroup.type" file which indicates whether the cgroup is a normal | |
| 262 | +domain, a domain which is serving as the domain of a threaded subtree, | |
| 263 | +or a threaded cgroup. | |
| 264 | + | |
| 265 | +On creation, a cgroup is always a domain cgroup and can be made | |
| 266 | +threaded by writing "threaded" to the "cgroup.type" file. The | |
| 267 | +operation is single direction:: | |
| 268 | + | |
| 269 | + # echo threaded > cgroup.type | |
| 270 | + | |
| 271 | +Once threaded, the cgroup can't be made a domain again. To enable the | |
| 272 | +thread mode, the following conditions must be met. | |
| 273 | + | |
| 274 | +- As the cgroup will join the parent's resource domain. The parent | |
| 275 | + must either be a valid (threaded) domain or a threaded cgroup. | |
| 276 | + | |
| 277 | +- When the parent is an unthreaded domain, it must not have any domain | |
| 278 | + controllers enabled or populated domain children. The root is | |
| 279 | + exempt from this requirement. | |
| 280 | + | |
| 281 | +Topology-wise, a cgroup can be in an invalid state. Please consider | |
| 282 | +the following toplogy:: | |
| 283 | + | |
| 284 | + A (threaded domain) - B (threaded) - C (domain, just created) | |
| 285 | + | |
| 286 | +C is created as a domain but isn't connected to a parent which can | |
| 287 | +host child domains. C can't be used until it is turned into a | |
| 288 | +threaded cgroup. "cgroup.type" file will report "domain (invalid)" in | |
| 289 | +these cases. Operations which fail due to invalid topology use | |
| 290 | +EOPNOTSUPP as the errno. | |
| 291 | + | |
| 292 | +A domain cgroup is turned into a threaded domain when one of its child | |
| 293 | +cgroup becomes threaded or threaded controllers are enabled in the | |
| 294 | +"cgroup.subtree_control" file while there are processes in the cgroup. | |
| 295 | +A threaded domain reverts to a normal domain when the conditions | |
| 296 | +clear. | |
| 297 | + | |
| 298 | +When read, "cgroup.threads" contains the list of the thread IDs of all | |
| 299 | +threads in the cgroup. Except that the operations are per-thread | |
| 300 | +instead of per-process, "cgroup.threads" has the same format and | |
| 301 | +behaves the same way as "cgroup.procs". While "cgroup.threads" can be | |
| 302 | +written to in any cgroup, as it can only move threads inside the same | |
| 303 | +threaded domain, its operations are confined inside each threaded | |
| 304 | +subtree. | |
| 305 | + | |
| 306 | +The threaded domain cgroup serves as the resource domain for the whole | |
| 307 | +subtree, and, while the threads can be scattered across the subtree, | |
| 308 | +all the processes are considered to be in the threaded domain cgroup. | |
| 309 | +"cgroup.procs" in a threaded domain cgroup contains the PIDs of all | |
| 310 | +processes in the subtree and is not readable in the subtree proper. | |
| 311 | +However, "cgroup.procs" can be written to from anywhere in the subtree | |
| 312 | +to migrate all threads of the matching process to the cgroup. | |
| 313 | + | |
| 314 | +Only threaded controllers can be enabled in a threaded subtree. When | |
| 315 | +a threaded controller is enabled inside a threaded subtree, it only | |
| 316 | +accounts for and controls resource consumptions associated with the | |
| 317 | +threads in the cgroup and its descendants. All consumptions which | |
| 318 | +aren't tied to a specific thread belong to the threaded domain cgroup. | |
| 319 | + | |
| 320 | +Because a threaded subtree is exempt from no internal process | |
| 321 | +constraint, a threaded controller must be able to handle competition | |
| 322 | +between threads in a non-leaf cgroup and its child cgroups. Each | |
| 323 | +threaded controller defines how such competitions are handled. | |
| 324 | + | |
| 325 | + | |
| 222 | 326 | [Un]populated Notification |
| 223 | 327 | -------------------------- |
| 224 | 328 | |
| @@ -302,15 +406,15 @@ disabled if one or more children have it enabled. · 77 unmodified lines | ||
| 302 | 406 | No Internal Process Constraint |
| 303 | 407 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 304 | 408 | |
| 305 | −Non-root cgroups can only distribute resources to their children when | |
| 306 | −they don't have any processes of their own. In other words, only | |
| 307 | −cgroups which don't contain any processes can have controllers enabled | |
| 308 | −in their "cgroup.subtree_control" files. | |
| 409 | +Non-root cgroups can distribute domain resources to their children | |
| 410 | +only when they don't have any processes of their own. In other words, | |
| 411 | +only domain cgroups which don't contain any processes can have domain | |
| 412 | +controllers enabled in their "cgroup.subtree_control" files. | |
| 309 | 413 | |
| 310 | −This guarantees that, when a controller is looking at the part of the | |
| 311 | −hierarchy which has it enabled, processes are always only on the | |
| 312 | −leaves. This rules out situations where child cgroups compete against | |
| 313 | −internal processes of the parent. | |
| 414 | +This guarantees that, when a domain controller is looking at the part | |
| 415 | +of the hierarchy which has it enabled, processes are always only on | |
| 416 | +the leaves. This rules out situations where child cgroups compete | |
| 417 | +against internal processes of the parent. | |
| 314 | 418 | |
| 315 | 419 | The root cgroup is exempt from this restriction. Root contains |
| 316 | 420 | processes and anonymous resource consumption which can't be associated |
| @@ -334,10 +438,10 @@ Model of Delegation · 17 unmodified lines | ||
| 334 | 438 | ~~~~~~~~~~~~~~~~~~~ |
| 335 | 439 | |
| 336 | 440 | A cgroup can be delegated in two ways. First, to a less privileged |
| 337 | −user by granting write access of the directory and its "cgroup.procs" | |
| 338 | −and "cgroup.subtree_control" files to the user. Second, if the | |
| 339 | −"nsdelegate" mount option is set, automatically to a cgroup namespace | |
| 340 | −on namespace creation. | |
| 441 | +user by granting write access of the directory and its "cgroup.procs", | |
| 442 | +"cgroup.threads" and "cgroup.subtree_control" files to the user. | |
| 443 | +Second, if the "nsdelegate" mount option is set, automatically to a | |
| 444 | +cgroup namespace on namespace creation. | |
| 341 | 445 | |
| 342 | 446 | Because the resource control interface files in a given directory |
| 343 | 447 | control the distribution of the parent's resources, the delegatee |
| @@ -644,6 +748,29 @@ Core Interface Files · 300 unmodified lines | ||
| 644 | 748 | |
| 645 | 749 | All cgroup core files are prefixed with "cgroup." |
| 646 | 750 | |
| 751 | + cgroup.type | |
| 752 | + | |
| 753 | + A read-write single value file which exists on non-root | |
| 754 | + cgroups. | |
| 755 | + | |
| 756 | + When read, it indicates the current type of the cgroup, which | |
| 757 | + can be one of the following values. | |
| 758 | + | |
| 759 | + - "domain" : A normal valid domain cgroup. | |
| 760 | + | |
| 761 | + - "domain threaded" : A threaded domain cgroup which is | |
| 762 | + serving as the root of a threaded subtree. | |
| 763 | + | |
| 764 | + - "domain invalid" : A cgroup which is in an invalid state. | |
| 765 | + It can't be populated or have controllers enabled. It may | |
| 766 | + be allowed to become a threaded cgroup. | |
| 767 | + | |
| 768 | + - "threaded" : A threaded cgroup which is a member of a | |
| 769 | + threaded subtree. | |
| 770 | + | |
| 771 | + A cgroup can be turned into a threaded cgroup by writing | |
| 772 | + "threaded" to this file. | |
| 773 | + | |
| 647 | 774 | cgroup.procs |
| 648 | 775 | A read-write new-line separated values file which exists on |
| 649 | 776 | all cgroups. |
| @@ -658,9 +785,6 @@ All cgroup core files are prefixed with "cgroup." · 8 unmodified lines | ||
| 658 | 785 | the PID to the cgroup. The writer should match all of the |
| 659 | 786 | following conditions. |
| 660 | 787 | |
| 661 | − - Its euid is either root or must match either uid or suid of | |
| 662 | − the target process. | |
| 663 | − | |
| 664 | 788 | - It must have write access to the "cgroup.procs" file. |
| 665 | 789 | |
| 666 | 790 | - It must have write access to the "cgroup.procs" file of the |
| @@ -669,6 +793,35 @@ All cgroup core files are prefixed with "cgroup." · 2 unmodified lines | ||
| 669 | 793 | When delegating a sub-hierarchy, write access to this file |
| 670 | 794 | should be granted along with the containing directory. |
| 671 | 795 | |
| 796 | + In a threaded cgroup, reading this file fails with EOPNOTSUPP | |
| 797 | + as all the processes belong to the thread root. Writing is | |
| 798 | + supported and moves every thread of the process to the cgroup. | |
| 799 | + | |
| 800 | + cgroup.threads | |
| 801 | + A read-write new-line separated values file which exists on | |
| 802 | + all cgroups. | |
| 803 | + | |
| 804 | + When read, it lists the TIDs of all threads which belong to | |
| 805 | + the cgroup one-per-line. The TIDs are not ordered and the | |
| 806 | + same TID may show up more than once if the thread got moved to | |
| 807 | + another cgroup and then back or the TID got recycled while | |
| 808 | + reading. | |
| 809 | + | |
| 810 | + A TID can be written to migrate the thread associated with the | |
| 811 | + TID to the cgroup. The writer should match all of the | |
| 812 | + following conditions. | |
| 813 | + | |
| 814 | + - It must have write access to the "cgroup.threads" file. | |
| 815 | + | |
| 816 | + - The cgroup that the thread is currently in must be in the | |
| 817 | + same resource domain as the destination cgroup. | |
| 818 | + | |
| 819 | + - It must have write access to the "cgroup.procs" file of the | |
| 820 | + common ancestor of the source and destination cgroups. | |
| 821 | + | |
| 822 | + When delegating a sub-hierarchy, write access to this file | |
| 823 | + should be granted along with the containing directory. | |
| 824 | + | |
| 672 | 825 | cgroup.controllers |
| 673 | 826 | A read-only space separated values file which exists on all |
| 674 | 827 | cgroups. |
| @@ -701,6 +854,38 @@ All cgroup core files are prefixed with "cgroup." · 26 unmodified lines | ||
| 701 | 854 | 1 if the cgroup or its descendants contains any live |
| 702 | 855 | processes; otherwise, 0. |
| 703 | 856 | |
| 857 | + cgroup.max.descendants | |
| 858 | + A read-write single value files. The default is "max". | |
| 859 | + | |
| 860 | + Maximum allowed number of descent cgroups. | |
| 861 | + If the actual number of descendants is equal or larger, | |
| 862 | + an attempt to create a new cgroup in the hierarchy will fail. | |
| 863 | + | |
| 864 | + cgroup.max.depth | |
| 865 | + A read-write single value files. The default is "max". | |
| 866 | + | |
| 867 | + Maximum allowed descent depth below the current cgroup. | |
| 868 | + If the actual descent depth is equal or larger, | |
| 869 | + an attempt to create a new child cgroup will fail. | |
| 870 | + | |
| 871 | + cgroup.stat | |
| 872 | + A read-only flat-keyed file with the following entries: | |
| 873 | + | |
| 874 | + nr_descendants | |
| 875 | + Total number of visible descendant cgroups. | |
| 876 | + | |
| 877 | + nr_dying_descendants | |
| 878 | + Total number of dying descendant cgroups. A cgroup becomes | |
| 879 | + dying after being deleted by a user. The cgroup will remain | |
| 880 | + in dying state for some time undefined time (which can depend | |
| 881 | + on system load) before being completely destroyed. | |
| 882 | + | |
| 883 | + A process can't enter a dying cgroup under any circumstances, | |
| 884 | + a dying cgroup can't revive. | |
| 885 | + | |
| 886 | + A dying cgroup can consume system resources not exceeding | |
| 887 | + limits, which were active at the moment of cgroup deletion. | |
| 888 | + | |
| 704 | 889 | |
| 705 | 890 | Controllers |
| 706 | 891 | =========== |
| @@ -29,7 +29,7 @@ from load_config import loadConfig · 28 unmodified lines | ||
| 29 | 29 | # -- General configuration ------------------------------------------------ |
| 30 | 30 | |
| 31 | 31 | # If your documentation needs a minimal Sphinx version, state it here. |
| 32 | −needs_sphinx = '1.2' | |
| 32 | +needs_sphinx = '1.3' | |
| 33 | 33 | |
| 34 | 34 | # Add any Sphinx extension module names here, as strings. They can be |
| 35 | 35 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom |
| @@ -271,10 +271,29 @@ latex_elements = { · 235 unmodified lines | ||
| 271 | 271 | |
| 272 | 272 | # Additional stuff for the LaTeX preamble. |
| 273 | 273 | 'preamble': ''' |
| 274 | − \\usepackage{ifthen} | |
| 274 | + % Use some font with UTF-8 support with XeLaTeX | |
| 275 | + \\usepackage{fontspec} | |
| 276 | + \\setsansfont{DejaVu Serif} | |
| 277 | + \\setromanfont{DejaVu Sans} | |
| 278 | + \\setmonofont{DejaVu Sans Mono} | |
| 275 | 279 | |
| 276 | − % Allow generate some pages in landscape | |
| 277 | − \\usepackage{lscape} | |
| 280 | + ''' | |
| 281 | +} | |
| 282 | + | |
| 283 | +# Fix reference escape troubles with Sphinx 1.4.x | |
| 284 | +if major == 1 and minor > 3: | |
| 285 | + latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n' | |
| 286 | + | |
| 287 | +if major == 1 and minor <= 4: | |
| 288 | + latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}' | |
| 289 | +elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)): | |
| 290 | + latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in' | |
| 291 | + latex_elements['preamble'] += '\\fvset{fontsize=auto}\n' | |
| 292 | + | |
| 293 | +# Customize notice background colors on Sphinx < 1.6: | |
| 294 | +if major == 1 and minor < 6: | |
| 295 | + latex_elements['preamble'] += ''' | |
| 296 | + \\usepackage{ifthen} | |
| 278 | 297 | |
| 279 | 298 | % Put notes in color and let them be inside a table |
| 280 | 299 | \\definecolor{NoteColor}{RGB}{204,255,255} |
| @@ -325,27 +344,26 @@ latex_elements = { · 44 unmodified lines | ||
| 325 | 344 | } |
| 326 | 345 | \\makeatother |
| 327 | 346 | |
| 328 | − % Use some font with UTF-8 support with XeLaTeX | |
| 329 | − \\usepackage{fontspec} | |
| 330 | − \\setsansfont{DejaVu Serif} | |
| 331 | − \\setromanfont{DejaVu Sans} | |
| 332 | − \\setmonofont{DejaVu Sans Mono} | |
| 333 | − | |
| 334 | − % To allow adjusting table sizes | |
| 335 | − \\usepackage{adjustbox} | |
| 336 | − | |
| 337 | 347 | ''' |
| 338 | −} | |
| 339 | − | |
| 340 | −# Fix reference escape troubles with Sphinx 1.4.x | |
| 341 | −if major == 1 and minor > 3: | |
| 342 | − latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n' | |
| 343 | − | |
| 344 | −if major == 1 and minor <= 4: | |
| 345 | − latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}' | |
| 346 | −elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)): | |
| 347 | − latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=0.5in' | |
| 348 | 348 | |
| 349 | +# With Sphinx 1.6, it is possible to change the Bg color directly | |
| 350 | +# by using: | |
| 351 | +# \definecolor{sphinxnoteBgColor}{RGB}{204,255,255} | |
| 352 | +# \definecolor{sphinxwarningBgColor}{RGB}{255,204,204} | |
| 353 | +# \definecolor{sphinxattentionBgColor}{RGB}{255,255,204} | |
| 354 | +# \definecolor{sphinximportantBgColor}{RGB}{192,255,204} | |
| 355 | +# | |
| 356 | +# However, it require to use sphinx heavy box with: | |
| 357 | +# | |
| 358 | +# \renewenvironment{sphinxlightbox} {% | |
| 359 | +# \\begin{sphinxheavybox} | |
| 360 | +# } | |
| 361 | +# \\end{sphinxheavybox} | |
| 362 | +# } | |
| 363 | +# | |
| 364 | +# Unfortunately, the implementation is buggy: if a note is inside a | |
| 365 | +# table, it isn't displayed well. So, for now, let's use boring | |
| 366 | +# black and white notes. | |
| 349 | 367 | |
| 350 | 368 | # Grouping the document tree into LaTeX files. List of tuples |
| 351 | 369 | # (source start file, target name, title, |
| @@ -0,0 +1,144 @@ | ||
| 1 | +The genalloc/genpool subsystem | |
| 2 | +============================== | |
| 3 | + | |
| 4 | +There are a number of memory-allocation subsystems in the kernel, each | |
| 5 | +aimed at a specific need. Sometimes, however, a kernel developer needs to | |
| 6 | +implement a new allocator for a specific range of special-purpose memory; | |
| 7 | +often that memory is located on a device somewhere. The author of the | |
| 8 | +driver for that device can certainly write a little allocator to get the | |
| 9 | +job done, but that is the way to fill the kernel with dozens of poorly | |
| 10 | +tested allocators. Back in 2005, Jes Sorensen lifted one of those | |
| 11 | +allocators from the sym53c8xx_2 driver and posted_ it as a generic module | |
| 12 | +for the creation of ad hoc memory allocators. This code was merged | |
| 13 | +for the 2.6.13 release; it has been modified considerably since then. | |
| 14 | + | |
| 15 | +.. _posted: https://lwn.net/Articles/125842/ | |
| 16 | + | |
| 17 | +Code using this allocator should include <linux/genalloc.h>. The action | |
| 18 | +begins with the creation of a pool using one of: | |
| 19 | + | |
| 20 | +.. kernel-doc:: lib/genalloc.c | |
| 21 | + :functions: gen_pool_create | |
| 22 | + | |
| 23 | +.. kernel-doc:: lib/genalloc.c | |
| 24 | + :functions: devm_gen_pool_create | |
| 25 | + | |
| 26 | +A call to :c:func:`gen_pool_create` will create a pool. The granularity of | |
| 27 | +allocations is set with min_alloc_order; it is a log-base-2 number like | |
| 28 | +those used by the page allocator, but it refers to bytes rather than pages. | |
| 29 | +So, if min_alloc_order is passed as 3, then all allocations will be a | |
| 30 | +multiple of eight bytes. Increasing min_alloc_order decreases the memory | |
| 31 | +required to track the memory in the pool. The nid parameter specifies | |
| 32 | +which NUMA node should be used for the allocation of the housekeeping | |
| 33 | +structures; it can be -1 if the caller doesn't care. | |
| 34 | + | |
| 35 | +The "managed" interface :c:func:`devm_gen_pool_create` ties the pool to a | |
| 36 | +specific device. Among other things, it will automatically clean up the | |
| 37 | +pool when the given device is destroyed. | |
| 38 | + | |
| 39 | +A pool is shut down with: | |
| 40 | + | |
| 41 | +.. kernel-doc:: lib/genalloc.c | |
| 42 | + :functions: gen_pool_destroy | |
| 43 | + | |
| 44 | +It's worth noting that, if there are still allocations outstanding from the | |
| 45 | +given pool, this function will take the rather extreme step of invoking | |
| 46 | +BUG(), crashing the entire system. You have been warned. | |
| 47 | + | |
| 48 | +A freshly created pool has no memory to allocate. It is fairly useless in | |
| 49 | +that state, so one of the first orders of business is usually to add memory | |
| 50 | +to the pool. That can be done with one of: | |
| 51 | + | |
| 52 | +.. kernel-doc:: include/linux/genalloc.h | |
| 53 | + :functions: gen_pool_add | |
| 54 | + | |
| 55 | +.. kernel-doc:: lib/genalloc.c | |
| 56 | + :functions: gen_pool_add_virt | |
| 57 | + | |
| 58 | +A call to :c:func:`gen_pool_add` will place the size bytes of memory | |
| 59 | +starting at addr (in the kernel's virtual address space) into the given | |
| 60 | +pool, once again using nid as the node ID for ancillary memory allocations. | |
| 61 | +The :c:func:`gen_pool_add_virt` variant associates an explicit physical | |
| 62 | +address with the memory; this is only necessary if the pool will be used | |
| 63 | +for DMA allocations. | |
| 64 | + | |
| 65 | +The functions for allocating memory from the pool (and putting it back) | |
| 66 | +are: | |
| 67 | + | |
| 68 | +.. kernel-doc:: lib/genalloc.c | |
| 69 | + :functions: gen_pool_alloc | |
| 70 | + | |
| 71 | +.. kernel-doc:: lib/genalloc.c | |
| 72 | + :functions: gen_pool_dma_alloc | |
| 73 | + | |
| 74 | +.. kernel-doc:: lib/genalloc.c | |
| 75 | + :functions: gen_pool_free | |
| 76 | + | |
| 77 | +As one would expect, :c:func:`gen_pool_alloc` will allocate size< bytes | |
| 78 | +from the given pool. The :c:func:`gen_pool_dma_alloc` variant allocates | |
| 79 | +memory for use with DMA operations, returning the associated physical | |
| 80 | +address in the space pointed to by dma. This will only work if the memory | |
| 81 | +was added with :c:func:`gen_pool_add_virt`. Note that this function | |
| 82 | +departs from the usual genpool pattern of using unsigned long values to | |
| 83 | +represent kernel addresses; it returns a void * instead. | |
| 84 | + | |
| 85 | +That all seems relatively simple; indeed, some developers clearly found it | |
| 86 | +to be too simple. After all, the interface above provides no control over | |
| 87 | +how the allocation functions choose which specific piece of memory to | |
| 88 | +return. If that sort of control is needed, the following functions will be | |
| 89 | +of interest: | |
| 90 | + | |
| 91 | +.. kernel-doc:: lib/genalloc.c | |
| 92 | + :functions: gen_pool_alloc_algo | |
| 93 | + | |
| 94 | +.. kernel-doc:: lib/genalloc.c | |
| 95 | + :functions: gen_pool_set_algo | |
| 96 | + | |
| 97 | +Allocations with :c:func:`gen_pool_alloc_algo` specify an algorithm to be | |
| 98 | +used to choose the memory to be allocated; the default algorithm can be set | |
| 99 | +with :c:func:`gen_pool_set_algo`. The data value is passed to the | |
| 100 | +algorithm; most ignore it, but it is occasionally needed. One can, | |
| 101 | +naturally, write a special-purpose algorithm, but there is a fair set | |
| 102 | +already available: | |
| 103 | + | |
| 104 | +- gen_pool_first_fit is a simple first-fit allocator; this is the default | |
| 105 | + algorithm if none other has been specified. | |
| 106 | + | |
| 107 | +- gen_pool_first_fit_align forces the allocation to have a specific | |
| 108 | + alignment (passed via data in a genpool_data_align structure). | |
| 109 | + | |
| 110 | +- gen_pool_first_fit_order_align aligns the allocation to the order of the | |
| 111 | + size. A 60-byte allocation will thus be 64-byte aligned, for example. | |
| 112 | + | |
| 113 | +- gen_pool_best_fit, as one would expect, is a simple best-fit allocator. | |
| 114 | + | |
| 115 | +- gen_pool_fixed_alloc allocates at a specific offset (passed in a | |
| 116 | + genpool_data_fixed structure via the data parameter) within the pool. | |
| 117 | + If the indicated memory is not available the allocation fails. | |
| 118 | + | |
| 119 | +There is a handful of other functions, mostly for purposes like querying | |
| 120 | +the space available in the pool or iterating through chunks of memory. | |
| 121 | +Most users, however, should not need much beyond what has been described | |
| 122 | +above. With luck, wider awareness of this module will help to prevent the | |
| 123 | +writing of special-purpose memory allocators in the future. | |
| 124 | + | |
| 125 | +.. kernel-doc:: lib/genalloc.c | |
| 126 | + :functions: gen_pool_virt_to_phys | |
| 127 | + | |
| 128 | +.. kernel-doc:: lib/genalloc.c | |
| 129 | + :functions: gen_pool_for_each_chunk | |
| 130 | + | |
| 131 | +.. kernel-doc:: lib/genalloc.c | |
| 132 | + :functions: addr_in_gen_pool | |
| 133 | + | |
| 134 | +.. kernel-doc:: lib/genalloc.c | |
| 135 | + :functions: gen_pool_avail | |
| 136 | + | |
| 137 | +.. kernel-doc:: lib/genalloc.c | |
| 138 | + :functions: gen_pool_size | |
| 139 | + | |
| 140 | +.. kernel-doc:: lib/genalloc.c | |
| 141 | + :functions: gen_pool_get | |
| 142 | + | |
| 143 | +.. kernel-doc:: lib/genalloc.c | |
| 144 | + :functions: of_gen_pool_get | |
| @@ -20,6 +20,7 @@ Core utilities · 19 unmodified lines | ||
| 20 | 20 | genericirq |
| 21 | 21 | flexible-arrays |
| 22 | 22 | librs |
| 23 | + genalloc | |
| 23 | 24 | |
| 24 | 25 | Interfaces for kernel debugging |
| 25 | 26 | =============================== |
| @@ -344,3 +344,52 @@ codecs, and devices with strict requirements for interface clocking. · 343 unmodified lines | ||
| 344 | 344 | |
| 345 | 345 | .. kernel-doc:: include/linux/clk.h |
| 346 | 346 | :internal: |
| 347 | + | |
| 348 | +Synchronization Primitives | |
| 349 | +========================== | |
| 350 | + | |
| 351 | +Read-Copy Update (RCU) | |
| 352 | +---------------------- | |
| 353 | + | |
| 354 | +.. kernel-doc:: include/linux/rcupdate.h | |
| 355 | + :external: | |
| 356 | + | |
| 357 | +.. kernel-doc:: include/linux/rcupdate_wait.h | |
| 358 | + :external: | |
| 359 | + | |
| 360 | +.. kernel-doc:: include/linux/rcutree.h | |
| 361 | + :external: | |
| 362 | + | |
| 363 | +.. kernel-doc:: kernel/rcu/tree.c | |
| 364 | + :external: | |
| 365 | + | |
| 366 | +.. kernel-doc:: kernel/rcu/tree_plugin.h | |
| 367 | + :external: | |
| 368 | + | |
| 369 | +.. kernel-doc:: kernel/rcu/tree_exp.h | |
| 370 | + :external: | |
| 371 | + | |
| 372 | +.. kernel-doc:: kernel/rcu/update.c | |
| 373 | + :external: | |
| 374 | + | |
| 375 | +.. kernel-doc:: include/linux/srcu.h | |
| 376 | + :external: | |
| 377 | + | |
| 378 | +.. kernel-doc:: kernel/rcu/srcutree.c | |
| 379 | + :external: | |
| 380 | + | |
| 381 | +.. kernel-doc:: include/linux/rculist_bl.h | |
| 382 | + :external: | |
| 383 | + | |
| 384 | +.. kernel-doc:: include/linux/rculist.h | |
| 385 | + :external: | |
| 386 | + | |
| 387 | +.. kernel-doc:: include/linux/rculist_nulls.h | |
| 388 | + :external: | |
| 389 | + | |
| 390 | +.. kernel-doc:: include/linux/rcu_sync.h | |
| 391 | + :external: | |
| 392 | + | |
| 393 | +.. kernel-doc:: kernel/rcu/sync.c | |
| 394 | + :external: | |
| 395 | + | |
| @@ -243,11 +243,15 @@ throttling the number of active work items, specifying '0' is · 242 unmodified lines | ||
| 243 | 243 | recommended. |
| 244 | 244 | |
| 245 | 245 | Some users depend on the strict execution ordering of ST wq. The |
| 246 | −combination of ``@max_active`` of 1 and ``WQ_UNBOUND`` is used to | |
| 247 | −achieve this behavior. Work items on such wq are always queued to the | |
| 248 | −unbound worker-pools and only one work item can be active at any given | |
| 246 | +combination of ``@max_active`` of 1 and ``WQ_UNBOUND`` used to | |
| 247 | +achieve this behavior. Work items on such wq were always queued to the | |
| 248 | +unbound worker-pools and only one work item could be active at any given | |
| 249 | 249 | time thus achieving the same ordering property as ST wq. |
| 250 | 250 | |
| 251 | +In the current implementation the above configuration only guarantees | |
| 252 | +ST behavior within a given NUMA node. Instead alloc_ordered_queue should | |
| 253 | +be used to achieve system wide ST behavior. | |
| 254 | + | |
| 251 | 255 | |
| 252 | 256 | Example Execution Scenarios |
| 253 | 257 | =========================== |
| @@ -31,11 +31,13 @@ Setup · 30 unmodified lines | ||
| 31 | 31 | CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports |
| 32 | 32 | CONFIG_FRAME_POINTER, keep it enabled. |
| 33 | 33 | |
| 34 | −- Install that kernel on the guest. | |
| 34 | +- Install that kernel on the guest, turn off KASLR if necessary by adding | |
| 35 | + "nokaslr" to the kernel command line. | |
| 35 | 36 | Alternatively, QEMU allows to boot the kernel directly using -kernel, |
| 36 | 37 | -append, -initrd command line switches. This is generally only useful if |
| 37 | 38 | you do not depend on modules. See QEMU documentation for more details on |
| 38 | − this mode. | |
| 39 | + this mode. In this case, you should build the kernel with | |
| 40 | + CONFIG_RANDOMIZE_BASE disabled if the architecture supports KASLR. | |
| 39 | 41 | |
| 40 | 42 | - Enable the gdb stub of QEMU/KVM, either |
| 41 | 43 | |
| @@ -348,6 +348,15 @@ default behavior is always set to 0. · 347 unmodified lines | ||
| 348 | 348 | - ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot`` |
| 349 | 349 | - Enter the debugger on reboot notify. |
| 350 | 350 | |
| 351 | +Kernel parameter: ``nokaslr`` | |
| 352 | +----------------------------- | |
| 353 | + | |
| 354 | +If the architecture that you are using enable KASLR by default, | |
| 355 | +you should consider turning it off. KASLR randomizes the | |
| 356 | +virtual address where the kernel image is mapped and confuse | |
| 357 | +gdb which resolve kernel symbol address from symbol table | |
| 358 | +of vmlinux. | |
| 359 | + | |
| 351 | 360 | Using kdb |
| 352 | 361 | ========= |
| 353 | 362 | |
| @@ -358,7 +367,7 @@ This is a quick example of how to use kdb. · 4 unmodified lines | ||
| 358 | 367 | |
| 359 | 368 | 1. Configure kgdboc at boot using kernel parameters:: |
| 360 | 369 | |
| 361 | − console=ttyS0,115200 kgdboc=ttyS0,115200 | |
| 370 | + console=ttyS0,115200 kgdboc=ttyS0,115200 nokaslr | |
| 362 | 371 | |
| 363 | 372 | OR |
| 364 | 373 | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +Synopsys DesignWare ARC HS Development Kit Device Tree Bindings | |
| 2 | +--------------------------------------------------------------------------- | |
| 3 | + | |
| 4 | +ARC HSDK Board with quad-core ARC HS38x4 in silicon. | |
| 5 | + | |
| 6 | +Required root node properties: | |
| 7 | + - compatible = "snps,hsdk"; | |
| @@ -1,6 +1,18 @@ | ||
| 1 | 1 | Amlogic MesonX device tree bindings |
| 2 | 2 | ------------------------------------------- |
| 3 | 3 | |
| 4 | +Work in progress statement: | |
| 5 | + | |
| 6 | +Device tree files and bindings applying to Amlogic SoCs and boards are | |
| 7 | +considered "unstable". Any Amlogic device tree binding may change at | |
| 8 | +any time. Be sure to use a device tree binary and a kernel image | |
| 9 | +generated from the same source tree. | |
| 10 | + | |
| 11 | +Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a | |
| 12 | +stable binding/ABI. | |
| 13 | + | |
| 14 | +--------------------------------------------------------------- | |
| 15 | + | |
| 4 | 16 | Boards with the Amlogic Meson6 SoC shall have the following properties: |
| 5 | 17 | Required root node property: |
| 6 | 18 | compatible: "amlogic,meson6" |
| @@ -61,3 +73,32 @@ Board compatible values (alphabetically, grouped by SoC): · 54 unmodified lines | ||
| 61 | 73 | - "amlogic,q201" (Meson gxm s912) |
| 62 | 74 | - "kingnovel,r-box-pro" (Meson gxm S912) |
| 63 | 75 | - "nexbox,a1" (Meson gxm s912) |
| 76 | + | |
| 77 | +Amlogic Meson Firmware registers Interface | |
| 78 | +------------------------------------------ | |
| 79 | + | |
| 80 | +The Meson SoCs have a register bank with status and data shared with the | |
| 81 | +secure firmware. | |
| 82 | + | |
| 83 | +Required properties: | |
| 84 | + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon" | |
| 85 | + | |
| 86 | +Properties should indentify components of this register interface : | |
| 87 | + | |
| 88 | +Meson GX SoC Information | |
| 89 | +------------------------ | |
| 90 | +A firmware register encodes the SoC type, package and revision information on | |
| 91 | +the Meson GX SoCs. | |
| 92 | +If present, the following property should be added : | |
| 93 | + | |
| 94 | +Optional properties: | |
| 95 | + - amlogic,has-chip-id: If present, the interface gives the current SoC version. | |
| 96 | + | |
| 97 | +Example | |
| 98 | +------- | |
| 99 | + | |
| 100 | +ao-secure@140 { | |
| 101 | + compatible = "amlogic,meson-gx-ao-secure", "syscon"; | |
| 102 | + reg = <0x0 0x140 0x0 0x140>; | |
| 103 | + amlogic,has-chip-id; | |
| 104 | +}; | |
| @@ -108,6 +108,5 @@ Example: · 107 unmodified lines | ||
| 108 | 108 | frame-number = <1> |
| 109 | 109 | interrupts = <0 15 0x8>; |
| 110 | 110 | reg = <0xf0003000 0x1000>; |
| 111 | − status = "disabled"; | |
| 112 | 111 | }; |
| 113 | 112 | }; |
| @@ -42,6 +42,10 @@ Raspberry Pi Zero · 41 unmodified lines | ||
| 42 | 42 | Required root node properties: |
| 43 | 43 | compatible = "raspberrypi,model-zero", "brcm,bcm2835"; |
| 44 | 44 | |
| 45 | +Raspberry Pi Zero W | |
| 46 | +Required root node properties: | |
| 47 | +compatible = "raspberrypi,model-zero-w", "brcm,bcm2835"; | |
| 48 | + | |
| 45 | 49 | Generic BCM2835 board |
| 46 | 50 | Required root node properties: |
| 47 | 51 | compatible = "brcm,bcm2835"; |
| @@ -0,0 +1,6 @@ | ||
| 1 | +Beckhoff Automation Platforms Device Tree Bindings | |
| 2 | +-------------------------------------------------- | |
| 3 | + | |
| 4 | +CX9020 Embedded PC | |
| 5 | +Required root node properties: | |
| 6 | + - compatible = "bhf,cx9020", "fsl,imx53"; | |
| @@ -34,8 +34,8 @@ its hardware characteristcs. · 33 unmodified lines | ||
| 34 | 34 | - Embedded Trace Macrocell (version 4.x): |
| 35 | 35 | "arm,coresight-etm4x", "arm,primecell"; |
| 36 | 36 | |
| 37 | − - Qualcomm Configurable Replicator (version 1.x): | |
| 38 | − "qcom,coresight-replicator1x", "arm,primecell"; | |
| 37 | + - Coresight programmable Replicator : | |
| 38 | + "arm,coresight-dynamic-replicator", "arm,primecell"; | |
| 39 | 39 | |
| 40 | 40 | - System Trace Macrocell: |
| 41 | 41 | "arm,coresight-stm", "arm,primecell"; [1] |
| @@ -200,6 +200,7 @@ described below. · 199 unmodified lines | ||
| 200 | 200 | "arm,realview-smp" |
| 201 | 201 | "brcm,bcm11351-cpu-method" |
| 202 | 202 | "brcm,bcm23550" |
| 203 | + "brcm,bcm2836-smp" | |
| 203 | 204 | "brcm,bcm-nsp-smp" |
| 204 | 205 | "brcm,brahma-b15" |
| 205 | 206 | "marvell,armada-375-smp" |
| @@ -0,0 +1,15 @@ | ||
| 1 | +Marvell Armada 8KPlus Platforms Device Tree Bindings | |
| 2 | +---------------------------------------------------- | |
| 3 | + | |
| 4 | +Boards using a SoC of the Marvell Armada 8KP families must carry | |
| 5 | +the following root node property: | |
| 6 | + | |
| 7 | + - compatible, with one of the following values: | |
| 8 | + | |
| 9 | + - "marvell,armada-8080", "marvell,armada-ap810-octa", "marvell,armada-ap810" | |
| 10 | + when the SoC being used is the Armada 8080 | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +compatible = "marvell,armada-8080-db", "marvell,armada-8080", | |
| 15 | + "marvell,armada-ap810-octa", "marvell,armada-ap810" | |
| @@ -183,7 +183,6 @@ cpm_syscon0: system-controller@440000 { · 182 unmodified lines | ||
| 183 | 183 | gpio-controller; |
| 184 | 184 | #gpio-cells = <2>; |
| 185 | 185 | gpio-ranges = <&cpm_pinctrl 0 0 32>; |
| 186 | − status = "disabled"; | |
| 187 | 186 | }; |
| 188 | 187 | |
| 189 | 188 | }; |
| @@ -1,12 +1,12 @@ | ||
| 1 | −MediaTek mt65xx, mt67xx & mt81xx Platforms Device Tree Bindings | |
| 1 | +MediaTek SoC based Platforms Device Tree Bindings | |
| 2 | 2 | |
| 3 | −Boards with a MediaTek mt65xx/mt67xx/mt81xx SoC shall have the | |
| 4 | −following property: | |
| 3 | +Boards with a MediaTek SoC shall have the following property: | |
| 5 | 4 | |
| 6 | 5 | Required root node property: |
| 7 | 6 | |
| 8 | 7 | compatible: Must contain one of |
| 9 | 8 | "mediatek,mt2701" |
| 9 | + "mediatek,mt2712" | |
| 10 | 10 | "mediatek,mt6580" |
| 11 | 11 | "mediatek,mt6589" |
| 12 | 12 | "mediatek,mt6592" |
| @@ -14,7 +14,8 @@ compatible: Must contain one of · 1 unmodified line | ||
| 14 | 14 | "mediatek,mt6795" |
| 15 | 15 | "mediatek,mt6797" |
| 16 | 16 | "mediatek,mt7622" |
| 17 | − "mediatek,mt7623" | |
| 17 | + "mediatek,mt7623" which is referred to MT7623N SoC | |
| 18 | + "mediatek,mt7623a" | |
| 18 | 19 | "mediatek,mt8127" |
| 19 | 20 | "mediatek,mt8135" |
| 20 | 21 | "mediatek,mt8173" |
| @@ -25,6 +26,9 @@ Supported boards: · 4 unmodified lines | ||
| 25 | 26 | - Evaluation board for MT2701: |
| 26 | 27 | Required root node properties: |
| 27 | 28 | - compatible = "mediatek,mt2701-evb", "mediatek,mt2701"; |
| 29 | +- Evaluation board for MT2712: | |
| 30 | + Required root node properties: | |
| 31 | + - compatible = "mediatek,mt2712-evb", "mediatek,mt2712"; | |
| 28 | 32 | - Evaluation board for MT6580: |
| 29 | 33 | Required root node properties: |
| 30 | 34 | - compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580"; |
| @@ -46,9 +50,11 @@ Supported boards: · 15 unmodified lines | ||
| 46 | 50 | - Reference board variant 1 for MT7622: |
| 47 | 51 | Required root node properties: |
| 48 | 52 | - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622"; |
| 49 | −- Evaluation board for MT7623: | |
| 53 | +- Reference board for MT7623n with NAND: | |
| 50 | 54 | Required root node properties: |
| 51 | − - compatible = "mediatek,mt7623-evb", "mediatek,mt7623"; | |
| 55 | + - compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623"; | |
| 56 | +- Bananapi BPI-R2 board: | |
| 57 | + - compatible = "bananapi,bpi-r2", "mediatek,mt7623"; | |
| 52 | 58 | - MTK mt8127 tablet moose EVB: |
| 53 | 59 | Required root node properties: |
| 54 | 60 | - compatible = "mediatek,mt8127-moose", "mediatek,mt8127"; |
| @@ -80,6 +80,9 @@ SoCs: · 79 unmodified lines | ||
| 80 | 80 | - OMAP5432 |
| 81 | 81 | compatible = "ti,omap5432", "ti,omap5" |
| 82 | 82 | |
| 83 | +- DRA762 | |
| 84 | + compatible = "ti,dra762", "ti,dra7" | |
| 85 | + | |
| 83 | 86 | - DRA742 |
| 84 | 87 | compatible = "ti,dra742", "ti,dra74", "ti,dra7" |
| 85 | 88 | |
| @@ -154,6 +157,9 @@ Boards: · 68 unmodified lines | ||
| 154 | 157 | - AM335X phyCORE-AM335x: Development kit |
| 155 | 158 | compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx" |
| 156 | 159 | |
| 160 | +- AM335X UC-8100-ME-T: Communication-centric industrial computing platform | |
| 161 | + compatible = "moxa,uc-8100-me-t", "ti,am33xx"; | |
| 162 | + | |
| 157 | 163 | - OMAP5 EVM : Evaluation Module |
| 158 | 164 | compatible = "ti,omap5-evm", "ti,omap5" |
| 159 | 165 | |
| @@ -184,6 +190,9 @@ Boards: · 24 unmodified lines | ||
| 184 | 190 | - AM5718 IDK |
| 185 | 191 | compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7" |
| 186 | 192 | |
| 193 | +- DRA762 EVM: Software Development Board for DRA762 | |
| 194 | + compatible = "ti,dra76-evm", "ti,dra762", "ti,dra7" | |
| 195 | + | |
| 187 | 196 | - DRA742 EVM: Software Development Board for DRA742 |
| 188 | 197 | compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" |
| 189 | 198 | |
| @@ -9,9 +9,11 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - compatible : should be one of |
| 10 | 10 | "apm,potenza-pmu" |
| 11 | 11 | "arm,armv8-pmuv3" |
| 12 | + "arm,cortex-a73-pmu" | |
| 12 | 13 | "arm,cortex-a72-pmu" |
| 13 | 14 | "arm,cortex-a57-pmu" |
| 14 | 15 | "arm,cortex-a53-pmu" |
| 16 | + "arm,cortex-a35-pmu" | |
| 15 | 17 | "arm,cortex-a17-pmu" |
| 16 | 18 | "arm,cortex-a15-pmu" |
| 17 | 19 | "arm,cortex-a12-pmu" |
| @@ -25,6 +25,7 @@ The 'SoC' element must be one of the following strings: · 24 unmodified lines | ||
| 25 | 25 | msm8994 |
| 26 | 26 | msm8996 |
| 27 | 27 | mdm9615 |
| 28 | + ipq8074 | |
| 28 | 29 | |
| 29 | 30 | The 'board' element must be one of the following strings: |
| 30 | 31 | |
| @@ -33,6 +34,7 @@ The 'board' element must be one of the following strings: · 2 unmodified lines | ||
| 33 | 34 | dragonboard |
| 34 | 35 | mtp |
| 35 | 36 | sbc |
| 37 | + hk01 | |
| 36 | 38 | |
| 37 | 39 | The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor> |
| 38 | 40 | where the minor number may be omitted when it's zero, i.e. v1.0 is the same |
| @@ -134,6 +134,10 @@ Rockchip platforms device tree bindings · 133 unmodified lines | ||
| 134 | 134 | Required root node properties: |
| 135 | 135 | - compatible = "phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288"; |
| 136 | 136 | |
| 137 | +- Pine64 Rock64 board: | |
| 138 | + Required root node properties: | |
| 139 | + - compatible = "pine64,rock64", "rockchip,rk3328"; | |
| 140 | + | |
| 137 | 141 | - Rockchip PX3 Evaluation board: |
| 138 | 142 | Required root node properties: |
| 139 | 143 | - compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188"; |
| @@ -173,6 +177,14 @@ Rockchip platforms device tree bindings · 33 unmodified lines | ||
| 173 | 177 | Required root node properties: |
| 174 | 178 | - compatible = "rockchip,rk3399-evb", "rockchip,rk3399"; |
| 175 | 179 | |
| 180 | +- Rockchip RK3399 Sapphire Excavator board: | |
| 181 | + Required root node properties: | |
| 182 | + - compatible = "rockchip,rk3399-sapphire-excavator", "rockchip,rk3399"; | |
| 183 | + | |
| 184 | +- Theobroma Systems RK3399-Q7 Haikou Baseboard: | |
| 185 | + Required root node properties: | |
| 186 | + - compatible = "tsd,rk3399-q7-haikou", "rockchip,rk3399"; | |
| 187 | + | |
| 176 | 188 | - Tronsmart Orion R68 Meta |
| 177 | 189 | Required root node properties: |
| 178 | 190 | - compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368"; |
| @@ -39,6 +39,8 @@ SoCs: · 38 unmodified lines | ||
| 39 | 39 | compatible = "renesas,r8a7795" |
| 40 | 40 | - R-Car M3-W (R8A77960) |
| 41 | 41 | compatible = "renesas,r8a7796" |
| 42 | + - R-Car D3 (R8A77995) | |
| 43 | + compatible = "renesas,r8a77995" | |
| 42 | 44 | |
| 43 | 45 | |
| 44 | 46 | Boards: |
| @@ -53,6 +55,8 @@ Boards: · 8 unmodified lines | ||
| 53 | 55 | compatible = "renesas,blanche", "renesas,r8a7792" |
| 54 | 56 | - BOCK-W |
| 55 | 57 | compatible = "renesas,bockw", "renesas,r8a7778" |
| 58 | + - Draak (RTP0RC77995SEB0010S) | |
| 59 | + compatible = "renesas,draak", "renesas,r8a77995" | |
| 56 | 60 | - Genmai (RTK772100BC00000BR) |
| 57 | 61 | compatible = "renesas,genmai", "renesas,r7s72100" |
| 58 | 62 | - GR-Peach (X28A-M01-E/F) |
| @@ -64,6 +68,10 @@ Boards: · 5 unmodified lines | ||
| 64 | 68 | compatible = "renesas,h3ulcb", "renesas,r8a7795"; |
| 65 | 69 | - Henninger |
| 66 | 70 | compatible = "renesas,henninger", "renesas,r8a7791" |
| 71 | + - iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) | |
| 72 | + compatible = "iwave,g22d", "iwave,g22m", "renesas,r8a7745" | |
| 73 | + - iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) | |
| 74 | + compatible = "iwave,g22m", "renesas,r8a7745" | |
| 67 | 75 | - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) |
| 68 | 76 | compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" |
| 69 | 77 | - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) |
| @@ -0,0 +1,51 @@ | ||
| 1 | +MediaTek Serial ATA controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : Must be "mediatek,<chip>-ahci", "mediatek,mtk-ahci". | |
| 5 | + When using "mediatek,mtk-ahci" compatible strings, you | |
| 6 | + need SoC specific ones in addition, one of: | |
| 7 | + - "mediatek,mt7622-ahci" | |
| 8 | + - reg : Physical base addresses and length of register sets. | |
| 9 | + - interrupts : Interrupt associated with the SATA device. | |
| 10 | + - interrupt-names : Associated name must be: "hostc". | |
| 11 | + - clocks : A list of phandle and clock specifier pairs, one for each | |
| 12 | + entry in clock-names. | |
| 13 | + - clock-names : Associated names must be: "ahb", "axi", "asic", "rbc", "pm". | |
| 14 | + - phys : A phandle and PHY specifier pair for the PHY port. | |
| 15 | + - phy-names : Associated name must be: "sata-phy". | |
| 16 | + - ports-implemented : See ./ahci-platform.txt for details. | |
| 17 | + | |
| 18 | +Optional properties: | |
| 19 | + - power-domains : A phandle and power domain specifier pair to the power | |
| 20 | + domain which is responsible for collapsing and restoring | |
| 21 | + power to the peripheral. | |
| 22 | + - resets : Must contain an entry for each entry in reset-names. | |
| 23 | + See ../reset/reset.txt for details. | |
| 24 | + - reset-names : Associated names must be: "axi", "sw", "reg". | |
| 25 | + - mediatek,phy-mode : A phandle to the system controller, used to enable | |
| 26 | + SATA function. | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + | |
| 30 | + sata: sata@1a200000 { | |
| 31 | + compatible = "mediatek,mt7622-ahci", | |
| 32 | + "mediatek,mtk-ahci"; | |
| 33 | + reg = <0 0x1a200000 0 0x1100>; | |
| 34 | + interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>; | |
| 35 | + interrupt-names = "hostc"; | |
| 36 | + clocks = <&pciesys CLK_SATA_AHB_EN>, | |
| 37 | + <&pciesys CLK_SATA_AXI_EN>, | |
| 38 | + <&pciesys CLK_SATA_ASIC_EN>, | |
| 39 | + <&pciesys CLK_SATA_RBC_EN>, | |
| 40 | + <&pciesys CLK_SATA_PM_EN>; | |
| 41 | + clock-names = "ahb", "axi", "asic", "rbc", "pm"; | |
| 42 | + phys = <&u3port1 PHY_TYPE_SATA>; | |
| 43 | + phy-names = "sata-phy"; | |
| 44 | + ports-implemented = <0x1>; | |
| 45 | + power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>; | |
| 46 | + resets = <&pciesys MT7622_SATA_AXI_BUS_RST>, | |
| 47 | + <&pciesys MT7622_SATA_PHY_SW_RST>, | |
| 48 | + <&pciesys MT7622_SATA_PHY_REG_RST>; | |
| 49 | + reset-names = "axi", "sw", "reg"; | |
| 50 | + mediatek,phy-mode = <&pciesys>; | |
| 51 | + }; | |
| @@ -57,7 +57,6 @@ Example: · 56 unmodified lines | ||
| 57 | 57 | <0x0 0x1f227000 0x0 0x1000>; |
| 58 | 58 | interrupts = <0x0 0x87 0x4>; |
| 59 | 59 | dma-coherent; |
| 60 | − status = "ok"; | |
| 61 | 60 | clocks = <&sataclk 0>; |
| 62 | 61 | phys = <&phy2 0>; |
| 63 | 62 | phy-names = "sata-phy"; |
| @@ -72,7 +71,6 @@ Example: · 8 unmodified lines | ||
| 72 | 71 | <0x0 0x1f237000 0x0 0x1000>; |
| 73 | 72 | interrupts = <0x0 0x88 0x4>; |
| 74 | 73 | dma-coherent; |
| 75 | − status = "ok"; | |
| 76 | 74 | clocks = <&sataclk 0>; |
| 77 | 75 | phys = <&phy3 0>; |
| 78 | 76 | phy-names = "sata-phy"; |
| @@ -13,5 +13,4 @@ Example: · 12 unmodified lines | ||
| 13 | 13 | reg = <0x83fe0000 0x4000>; |
| 14 | 14 | interrupts = <70>; |
| 15 | 15 | clocks = <&clks 161>; |
| 16 | − status = "disabled"; | |
| 17 | 16 | }; |
| @@ -227,7 +227,6 @@ See the example below, where a more complete device tree is shown: · 226 unmodified lines | ||
| 227 | 227 | }; |
| 228 | 228 | |
| 229 | 229 | devbus-bootcs { |
| 230 | − status = "okay"; | |
| 231 | 230 | ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>; |
| 232 | 231 | |
| 233 | 232 | /* NOR */ |
| @@ -240,7 +239,6 @@ See the example below, where a more complete device tree is shown: · 6 unmodified lines | ||
| 240 | 239 | |
| 241 | 240 | pcie-controller { |
| 242 | 241 | compatible = "marvell,armada-xp-pcie"; |
| 243 | − status = "okay"; | |
| 244 | 242 | device_type = "pci"; |
| 245 | 243 | |
| 246 | 244 | #address-cells = <3>; |
| @@ -258,7 +256,6 @@ See the example below, where a more complete device tree is shown: · 11 unmodified lines | ||
| 258 | 256 | |
| 259 | 257 | pcie@1,0 { |
| 260 | 258 | /* Port 0, Lane 0 */ |
| 261 | − status = "okay"; | |
| 262 | 259 | }; |
| 263 | 260 | }; |
| 264 | 261 | |
| @@ -84,7 +84,6 @@ gmi@70090000 { · 83 unmodified lines | ||
| 84 | 84 | reset-names = "gmi"; |
| 85 | 85 | ranges = <4 0 0xd0000000 0xfffffff>; |
| 86 | 86 | |
| 87 | − status = "okay"; | |
| 88 | 87 | |
| 89 | 88 | bus@4,0 { |
| 90 | 89 | compatible = "simple-bus"; |
| @@ -121,7 +120,6 @@ gmi@70090000 { · 30 unmodified lines | ||
| 121 | 120 | reset-names = "gmi"; |
| 122 | 121 | ranges = <4 0 0xd0000000 0xfffffff>; |
| 123 | 122 | |
| 124 | − status = "okay"; | |
| 125 | 123 | |
| 126 | 124 | can@4,0 { |
| 127 | 125 | reg = <4 0 0x100>; |
| @@ -33,7 +33,6 @@ Example: · 32 unmodified lines | ||
| 33 | 33 | #size-cells = <1>; |
| 34 | 34 | ranges = <0x702c0000 0x0 0x702c0000 0x00040000>; |
| 35 | 35 | |
| 36 | − status = "disabled"; | |
| 37 | 36 | |
| 38 | 37 | child1 { |
| 39 | 38 | ... |
| @@ -5,9 +5,31 @@ The chosen node does not represent a real device, but serves as a place · 4 unmodified lines | ||
| 5 | 5 | for passing data between firmware and the operating system, like boot |
| 6 | 6 | arguments. Data in the chosen node does not represent the hardware. |
| 7 | 7 | |
| 8 | +The following properties are recognized: | |
| 8 | 9 | |
| 9 | −stdout-path property | |
| 10 | −-------------------- | |
| 10 | + | |
| 11 | +kaslr-seed | |
| 12 | +----------- | |
| 13 | + | |
| 14 | +This property is used when booting with CONFIG_RANDOMIZE_BASE as the | |
| 15 | +entropy used to randomize the kernel image base address location. Since | |
| 16 | +it is used directly, this value is intended only for KASLR, and should | |
| 17 | +not be used for other purposes (as it may leak information about KASLR | |
| 18 | +offsets). It is parsed as a u64 value, e.g. | |
| 19 | + | |
| 20 | +/ { | |
| 21 | + chosen { | |
| 22 | + kaslr-seed = <0xfeedbeef 0xc0def00d>; | |
| 23 | + }; | |
| 24 | +}; | |
| 25 | + | |
| 26 | +Note that if this property is set from UEFI (or a bootloader in EFI | |
| 27 | +mode) when EFI_RNG_PROTOCOL is supported, it will be overwritten by | |
| 28 | +the Linux EFI stub (which will populate the property itself, using | |
| 29 | +EFI_RNG_PROTOCOL). | |
| 30 | + | |
| 31 | +stdout-path | |
| 32 | +----------- | |
| 11 | 33 | |
| 12 | 34 | Device trees may specify the device to be used for boot console output |
| 13 | 35 | with a stdout-path property under /chosen, as described in the Devicetree |
| @@ -102,7 +102,6 @@ uart4: serial@80010000 { · 101 unmodified lines | ||
| 102 | 102 | reg = <0x80010000 0x4000>; |
| 103 | 103 | clocks = <&acc CLKID_SYS_UART4>, <&acc CLKID_AHB_UART4>; |
| 104 | 104 | interrupts = <19>; |
| 105 | − status = "disabled"; | |
| 106 | 105 | }; |
| 107 | 106 | |
| 108 | 107 | Clock consumer with only one, _AHB_ sink. |
| @@ -5,9 +5,11 @@ controllers within the Always-On part of the SoC. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | −- compatible: should be "amlogic,gxbb-aoclkc" | |
| 9 | −- reg: physical base address of the clock controller and length of memory | |
| 10 | − mapped region. | |
| 8 | +- compatible: value should be different for each SoC family as : | |
| 9 | + - GXBB (S905) : "amlogic,meson-gxbb-aoclkc" | |
| 10 | + - GXL (S905X, S905D) : "amlogic,meson-gxl-aoclkc" | |
| 11 | + - GXM (S912) : "amlogic,meson-gxm-aoclkc" | |
| 12 | + followed by the common "amlogic,meson-gx-aoclkc" | |
| 11 | 13 | |
| 12 | 14 | - #clock-cells: should be 1. |
| 13 | 15 | |
| @@ -23,14 +25,22 @@ to specify the reset which they consume. All available resets are defined as · 9 unmodified lines | ||
| 23 | 25 | preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be |
| 24 | 26 | used in device tree sources. |
| 25 | 27 | |
| 28 | +Parent node should have the following properties : | |
| 29 | +- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd" | |
| 30 | +- reg: base address and size of the AO system control register space. | |
| 31 | + | |
| 26 | 32 | Example: AO Clock controller node: |
| 27 | 33 | |
| 28 | − clkc_AO: clock-controller@040 { | |
| 29 | − compatible = "amlogic,gxbb-aoclkc"; | |
| 30 | − reg = <0x0 0x040 0x0 0x4>; | |
| 34 | +ao_sysctrl: sys-ctrl@0 { | |
| 35 | + compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"; | |
| 36 | + reg = <0x0 0x0 0x0 0x100>; | |
| 37 | + | |
| 38 | + clkc_AO: clock-controller { | |
| 39 | + compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc"; | |
| 31 | 40 | #clock-cells = <1>; |
| 32 | 41 | #reset-cells = <1>; |
| 33 | 42 | }; |
| 43 | +}; | |
| 34 | 44 | |
| 35 | 45 | Example: UART controller node that consumes the clock and reset generated |
| 36 | 46 | by the clock controller: |
| @@ -41,5 +51,4 @@ Example: UART controller node that consumes the clock and reset generated · 4 unmodified lines | ||
| 41 | 51 | interrupts = <0 90 1>; |
| 42 | 52 | clocks = <&clkc_AO CLKID_AO_UART1>; |
| 43 | 53 | resets = <&clkc_AO RESET_AO_UART1>; |
| 44 | − status = "disabled"; | |
| 45 | 54 | }; |
| @@ -33,5 +33,4 @@ Example: UART controller node that consumes the clock generated by the clock · 32 unmodified lines | ||
| 33 | 33 | reg = <0xc81004c0 0x14>; |
| 34 | 34 | interrupts = <0 90 1>; |
| 35 | 35 | clocks = <&clkc CLKID_CLK81>; |
| 36 | − status = "disabled"; | |
| 37 | 36 | }; |
| @@ -16,18 +16,25 @@ Required Properties: · 15 unmodified lines | ||
| 16 | 16 | mapped region. |
| 17 | 17 | |
| 18 | 18 | - #clock-cells: should be 1. |
| 19 | +- #reset-cells: should be 1. | |
| 19 | 20 | |
| 20 | 21 | Each clock is assigned an identifier and client nodes can use this identifier |
| 21 | 22 | to specify the clock which they consume. All available clocks are defined as |
| 22 | 23 | preprocessor macros in the dt-bindings/clock/meson8b-clkc.h header and can be |
| 23 | 24 | used in device tree sources. |
| 24 | 25 | |
| 26 | +Similarly a preprocessor macro for each reset line is defined in | |
| 27 | +dt-bindings/reset/amlogic,meson8b-clkc-reset.h (which can be used from the | |
| 28 | +device tree sources). | |
| 29 | + | |
| 30 | + | |
| 25 | 31 | Example: Clock controller node: |
| 26 | 32 | |
| 27 | 33 | clkc: clock-controller@c1104000 { |
| 28 | − #clock-cells = <1>; | |
| 29 | 34 | compatible = "amlogic,meson8b-clkc"; |
| 30 | 35 | reg = <0xc1108000 0x4>, <0xc1104000 0x460>; |
| 36 | + #clock-cells = <1>; | |
| 37 | + #reset-cells = <1>; | |
| 31 | 38 | }; |
| 32 | 39 | |
| 33 | 40 | |
| @@ -39,5 +46,4 @@ Example: UART controller node that consumes the clock generated by the clock · 5 unmodified lines | ||
| 39 | 46 | reg = <0xc81004c0 0x14>; |
| 40 | 47 | interrupts = <0 90 1>; |
| 41 | 48 | clocks = <&clkc CLKID_CLK81>; |
| 42 | − status = "disabled"; | |
| 43 | 49 | }; |
| @@ -81,6 +81,16 @@ Required properties: · 80 unmodified lines | ||
| 81 | 81 | "atmel,sama5d2-clk-generated": |
| 82 | 82 | at91 generated clock |
| 83 | 83 | |
| 84 | + "atmel,sama5d2-clk-audio-pll-frac": | |
| 85 | + at91 audio fractional pll | |
| 86 | + | |
| 87 | + "atmel,sama5d2-clk-audio-pll-pad": | |
| 88 | + at91 audio pll CLK_AUDIO output pin | |
| 89 | + | |
| 90 | + "atmel,sama5d2-clk-audio-pll-pmc" | |
| 91 | + at91 audio pll output on AUDIOPLLCLK that feeds the PMC | |
| 92 | + and can be used by peripheral clock or generic clock | |
| 93 | + | |
| 84 | 94 | Required properties for SCKC node: |
| 85 | 95 | - reg : defines the IO memory reserved for the SCKC. |
| 86 | 96 | - #size-cells : shall be 0 (reg is used to encode clk id). |
| @@ -46,7 +46,6 @@ Device tree example: · 45 unmodified lines | ||
| 46 | 46 | |
| 47 | 47 | uart@3e002000 { |
| 48 | 48 | compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; |
| 49 | − status = "disabled"; | |
| 50 | 49 | reg = <0x3e002000 0x1000>; |
| 51 | 50 | clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; |
| 52 | 51 | interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; |
| @@ -465,5 +465,4 @@ Example 3: UART controller node that consumes the clock generated by the clock · 464 unmodified lines | ||
| 465 | 465 | clock-names = "uart", "clk_uart_baud0"; |
| 466 | 466 | pinctrl-names = "default"; |
| 467 | 467 | pinctrl-0 = <&uart0_bus>; |
| 468 | − status = "disabled"; | |
| 469 | 468 | }; |
| @@ -38,5 +38,4 @@ Examples: · 37 unmodified lines | ||
| 38 | 38 | clocks = <&crg_ctrl HI3660_CLK_MUX_UART0>, |
| 39 | 39 | <&crg_ctrl HI3660_PCLK>; |
| 40 | 40 | clock-names = "uartclk", "apb_pclk"; |
| 41 | − status = "disabled"; | |
| 42 | 41 | }; |
| @@ -27,5 +27,4 @@ Examples: · 26 unmodified lines | ||
| 27 | 27 | interrupts = <0 49 4>; |
| 28 | 28 | clocks = <&clock HIX5HD2_FIXED_83M>; |
| 29 | 29 | clock-names = "apb_pclk"; |
| 30 | − status = "disabled"; | |
| 31 | 30 | }; |
| @@ -1,24 +1,32 @@ | ||
| 1 | −Binding for IDT VersaClock5 programmable i2c clock generator. | |
| 1 | +Binding for IDT VersaClock 5,6 programmable i2c clock generators. | |
| 2 | 2 | |
| 3 | −The IDT VersaClock5 are programmable i2c clock generators providing | |
| 4 | −from 3 to 12 output clocks. | |
| 3 | +The IDT VersaClock 5 and VersaClock 6 are programmable i2c clock | |
| 4 | +generators providing from 3 to 12 output clocks. | |
| 5 | 5 | |
| 6 | 6 | ==I2C device node== |
| 7 | 7 | |
| 8 | 8 | Required properties: |
| 9 | −- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933" , | |
| 10 | − "idt,5p49v5935". | |
| 9 | +- compatible: shall be one of | |
| 10 | + "idt,5p49v5923" | |
| 11 | + "idt,5p49v5925" | |
| 12 | + "idt,5p49v5933" | |
| 13 | + "idt,5p49v5935" | |
| 14 | + "idt,5p49v6901" | |
| 11 | 15 | - reg: i2c device address, shall be 0x68 or 0x6a. |
| 12 | 16 | - #clock-cells: from common clock binding; shall be set to 1. |
| 13 | 17 | - clocks: from common clock binding; list of parent clock handles, |
| 14 | − - 5p49v5923: (required) either or both of XTAL or CLKIN | |
| 18 | + - 5p49v5923 and | |
| 19 | + 5p49v5925 and | |
| 20 | + 5p49v6901: (required) either or both of XTAL or CLKIN | |
| 15 | 21 | reference clock. |
| 16 | 22 | - 5p49v5933 and |
| 17 | 23 | - 5p49v5935: (optional) property not present (internal |
| 18 | 24 | Xtal used) or CLKIN reference |
| 19 | 25 | clock. |
| 20 | 26 | - clock-names: from common clock binding; clock input names, can be |
| 21 | − - 5p49v5923: (required) either or both of "xin", "clkin". | |
| 27 | + - 5p49v5923 and | |
| 28 | + 5p49v5925 and | |
| 29 | + 5p49v6901: (required) either or both of "xin", "clkin". | |
| 22 | 30 | - 5p49v5933 and |
| 23 | 31 | - 5p49v5935: (optional) property not present or "clkin". |
| 24 | 32 | |
| @@ -37,6 +45,7 @@ clock specifier, the following mapping applies: · 12 unmodified lines | ||
| 37 | 45 | 1 -- OUT1 |
| 38 | 46 | 2 -- OUT4 |
| 39 | 47 | |
| 48 | +5P49V5925 and | |
| 40 | 49 | 5P49V5935: |
| 41 | 50 | 0 -- OUT0_SEL_I2CB |
| 42 | 51 | 1 -- OUT1 |
| @@ -44,6 +53,13 @@ clock specifier, the following mapping applies: · 1 unmodified line | ||
| 44 | 53 | 3 -- OUT3 |
| 45 | 54 | 4 -- OUT4 |
| 46 | 55 | |
| 56 | +5P49V6901: | |
| 57 | + 0 -- OUT0_SEL_I2CB | |
| 58 | + 1 -- OUT1 | |
| 59 | + 2 -- OUT2 | |
| 60 | + 3 -- OUT3 | |
| 61 | + 4 -- OUT4 | |
| 62 | + | |
| 47 | 63 | ==Example== |
| 48 | 64 | |
| 49 | 65 | /* 25MHz reference crystal */ |
| @@ -24,5 +24,4 @@ Examples: · 23 unmodified lines | ||
| 24 | 24 | clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, |
| 25 | 25 | <&clks IMX21_CLK_PER1>; |
| 26 | 26 | clock-names = "ipg", "per"; |
| 27 | − status = "disabled"; | |
| 28 | 27 | }; |
| @@ -67,5 +67,4 @@ auart0: serial@8006c000 { · 66 unmodified lines | ||
| 67 | 67 | reg = <0x8006c000 0x2000>; |
| 68 | 68 | interrupts = <24 25 23>; |
| 69 | 69 | clocks = <&clks 32>; |
| 70 | − status = "disabled"; | |
| 71 | 70 | }; |
| @@ -157,5 +157,4 @@ uart1: serial@43f90000 { · 156 unmodified lines | ||
| 157 | 157 | interrupts = <45>; |
| 158 | 158 | clocks = <&clks 79>, <&clks 50>; |
| 159 | 159 | clock-names = "ipg", "per"; |
| 160 | − status = "disabled"; | |
| 161 | 160 | }; |
| @@ -24,5 +24,4 @@ Examples: · 23 unmodified lines | ||
| 24 | 24 | clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, |
| 25 | 25 | <&clks IMX27_CLK_PER1_GATE>; |
| 26 | 26 | clock-names = "ipg", "per"; |
| 27 | − status = "disabled"; | |
| 28 | 27 | }; |
| @@ -90,5 +90,4 @@ auart0: serial@8006a000 { · 89 unmodified lines | ||
| 90 | 90 | reg = <0x8006a000 0x2000>; |
| 91 | 91 | interrupts = <112 70 71>; |
| 92 | 92 | clocks = <&clks 45>; |
| 93 | − status = "disabled"; | |
| 94 | 93 | }; |
| @@ -87,5 +87,4 @@ uart1: serial@43f90000 { · 86 unmodified lines | ||
| 87 | 87 | interrupts = <45>; |
| 88 | 88 | clocks = <&clks 10>, <&clks 30>; |
| 89 | 89 | clock-names = "ipg", "per"; |
| 90 | − status = "disabled"; | |
| 91 | 90 | }; |
| @@ -25,5 +25,4 @@ can1: can@53fc8000 { · 24 unmodified lines | ||
| 25 | 25 | interrupts = <82>; |
| 26 | 26 | clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>; |
| 27 | 27 | clock-names = "ipg", "per"; |
| 28 | − status = "disabled"; | |
| 29 | 28 | }; |
| @@ -27,5 +27,4 @@ uart1: serial@02020000 { · 26 unmodified lines | ||
| 27 | 27 | interrupts = <0 26 0x04>; |
| 28 | 28 | clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>; |
| 29 | 29 | clock-names = "ipg", "per"; |
| 30 | − status = "disabled"; | |
| 31 | 30 | }; |
| @@ -1,83 +0,0 @@ | ||
| 1 | −Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | −- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names. | |
| 5 | −- clock-names: Should contain the following: | |
| 6 | − "cpu" - The multiplexer for clock input of CPU cluster. | |
| 7 | − "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock | |
| 8 | − source (usually MAINPLL) when the original CPU PLL is under | |
| 9 | − transition and not stable yet. | |
| 10 | − Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for | |
| 11 | − generic clock consumer properties. | |
| 12 | −- proc-supply: Regulator for Vproc of CPU cluster. | |
| 13 | − | |
| 14 | −Optional properties: | |
| 15 | −- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver | |
| 16 | − needs to do "voltage tracking" to step by step scale up/down Vproc and | |
| 17 | − Vsram to fit SoC specific needs. When absent, the voltage scaling | |
| 18 | − flow is handled by hardware, hence no software "voltage tracking" is | |
| 19 | − needed. | |
| 20 | − | |
| 21 | −Example: | |
| 22 | −-------- | |
| 23 | − cpu0: cpu@0 { | |
| 24 | − device_type = "cpu"; | |
| 25 | − compatible = "arm,cortex-a53"; | |
| 26 | − reg = <0x000>; | |
| 27 | − enable-method = "psci"; | |
| 28 | − cpu-idle-states = <&CPU_SLEEP_0>; | |
| 29 | − clocks = <&infracfg CLK_INFRA_CA53SEL>, | |
| 30 | − <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 31 | − clock-names = "cpu", "intermediate"; | |
| 32 | − }; | |
| 33 | − | |
| 34 | − cpu1: cpu@1 { | |
| 35 | − device_type = "cpu"; | |
| 36 | − compatible = "arm,cortex-a53"; | |
| 37 | − reg = <0x001>; | |
| 38 | − enable-method = "psci"; | |
| 39 | − cpu-idle-states = <&CPU_SLEEP_0>; | |
| 40 | − clocks = <&infracfg CLK_INFRA_CA53SEL>, | |
| 41 | − <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 42 | − clock-names = "cpu", "intermediate"; | |
| 43 | − }; | |
| 44 | − | |
| 45 | − cpu2: cpu@100 { | |
| 46 | − device_type = "cpu"; | |
| 47 | − compatible = "arm,cortex-a57"; | |
| 48 | − reg = <0x100>; | |
| 49 | − enable-method = "psci"; | |
| 50 | − cpu-idle-states = <&CPU_SLEEP_0>; | |
| 51 | − clocks = <&infracfg CLK_INFRA_CA57SEL>, | |
| 52 | − <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 53 | − clock-names = "cpu", "intermediate"; | |
| 54 | − }; | |
| 55 | − | |
| 56 | − cpu3: cpu@101 { | |
| 57 | − device_type = "cpu"; | |
| 58 | − compatible = "arm,cortex-a57"; | |
| 59 | − reg = <0x101>; | |
| 60 | − enable-method = "psci"; | |
| 61 | − cpu-idle-states = <&CPU_SLEEP_0>; | |
| 62 | − clocks = <&infracfg CLK_INFRA_CA57SEL>, | |
| 63 | − <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 64 | − clock-names = "cpu", "intermediate"; | |
| 65 | − }; | |
| 66 | − | |
| 67 | − &cpu0 { | |
| 68 | − proc-supply = <&mt6397_vpca15_reg>; | |
| 69 | − }; | |
| 70 | − | |
| 71 | − &cpu1 { | |
| 72 | − proc-supply = <&mt6397_vpca15_reg>; | |
| 73 | − }; | |
| 74 | − | |
| 75 | − &cpu2 { | |
| 76 | − proc-supply = <&da9211_vcpu_reg>; | |
| 77 | − sram-supply = <&mt6397_vsramca7_reg>; | |
| 78 | − }; | |
| 79 | − | |
| 80 | − &cpu3 { | |
| 81 | − proc-supply = <&da9211_vcpu_reg>; | |
| 82 | − sram-supply = <&mt6397_vsramca7_reg>; | |
| 83 | − }; | |
| @@ -66,7 +66,6 @@ clock@70110000 { · 65 unmodified lines | ||
| 66 | 66 | #clock-cells = <0>; |
| 67 | 67 | clock-output-names = "dfllCPU_out"; |
| 68 | 68 | vdd-cpu-supply = <&vdd_cpu>; |
| 69 | − status = "okay"; | |
| 70 | 69 | |
| 71 | 70 | nvidia,sample-rate = <12500>; |
| 72 | 71 | nvidia,droop-ctrl = <0x00000f00>; |
| @@ -12,5 +12,4 @@ Examples: · 11 unmodified lines | ||
| 12 | 12 | pxa2xx_clks: pxa2xx_clks@41300004 { |
| 13 | 13 | compatible = "marvell,pxa-clocks"; |
| 14 | 14 | #clock-cells = <1>; |
| 15 | − status = "okay"; | |
| 16 | 15 | }; |
| @@ -22,6 +22,7 @@ Required Properties: · 21 unmodified lines | ||
| 22 | 22 | - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2) |
| 23 | 23 | - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3) |
| 24 | 24 | - "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W) |
| 25 | + - "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3) | |
| 25 | 26 | |
| 26 | 27 | - reg: Base address and length of the memory resource used by the CPG/MSSR |
| 27 | 28 | block |
| @@ -30,7 +31,7 @@ Required Properties: · 2 unmodified lines | ||
| 30 | 31 | clock-names |
| 31 | 32 | - clock-names: List of external parent clock names. Valid names are: |
| 32 | 33 | - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794, |
| 33 | − r8a7795, r8a7796) | |
| 34 | + r8a7795, r8a7796, r8a77995) | |
| 34 | 35 | - "extalr" (r8a7795, r8a7796) |
| 35 | 36 | - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794) |
| 36 | 37 | |
| @@ -81,5 +82,4 @@ Examples · 44 unmodified lines | ||
| 81 | 82 | dma-names = "tx", "rx"; |
| 82 | 83 | power-domains = <&cpg>; |
| 83 | 84 | resets = <&cpg 310>; |
| 84 | − status = "disabled"; | |
| 85 | 85 | }; |
| @@ -44,5 +44,4 @@ Examples · 43 unmodified lines | ||
| 44 | 44 | interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>; |
| 45 | 45 | clocks = <&mstp3_clks R8A7778_CLK_SDHI0>; |
| 46 | 46 | power-domains = <&cpg_clocks>; |
| 47 | − status = "disabled"; | |
| 48 | 47 | }; |
| @@ -0,0 +1,55 @@ | ||
| 1 | +* Renesas R-Car USB 2.0 clock selector | |
| 2 | + | |
| 3 | +This file provides information on what the device node for the R-Car USB 2.0 | |
| 4 | +clock selector. | |
| 5 | + | |
| 6 | +If you connect an external clock to the USB_EXTAL pin only, you should set | |
| 7 | +the clock rate to "usb_extal" node only. | |
| 8 | +If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module | |
| 9 | +is not needed because this is default setting. (Of course, you can set the | |
| 10 | +clock rates to both "usb_extal" and "usb_xtal" nodes. | |
| 11 | + | |
| 12 | +Case 1: An external clock connects to R-Car SoC | |
| 13 | + +----------+ +--- R-Car ---------------------+ | |
| 14 | + |External |---|USB_EXTAL ---> all usb channels| | |
| 15 | + |clock | |USB_XTAL | | |
| 16 | + +----------+ +-------------------------------+ | |
| 17 | +In this case, we need this driver with "usb_extal" clock. | |
| 18 | + | |
| 19 | +Case 2: An oscillator connects to R-Car SoC | |
| 20 | + +----------+ +--- R-Car ---------------------+ | |
| 21 | + |Oscillator|---|USB_EXTAL -+-> all usb channels| | |
| 22 | + | |---|USB_XTAL --+ | | |
| 23 | + +----------+ +-------------------------------+ | |
| 24 | +In this case, we don't need this selector. | |
| 25 | + | |
| 26 | +Required properties: | |
| 27 | +- compatible: "renesas,r8a7795-rcar-usb2-clock-sel" if the device is a part of | |
| 28 | + an R8A7795 SoC. | |
| 29 | + "renesas,r8a7796-rcar-usb2-clock-sel" if the device if a part of | |
| 30 | + an R8A7796 SoC. | |
| 31 | + "renesas,rcar-gen3-usb2-clock-sel" for a generic R-Car Gen3 | |
| 32 | + compatible device. | |
| 33 | + | |
| 34 | + When compatible with the generic version, nodes must list the | |
| 35 | + SoC-specific version corresponding to the platform first | |
| 36 | + followed by the generic version. | |
| 37 | + | |
| 38 | +- reg: offset and length of the USB 2.0 clock selector register block. | |
| 39 | +- clocks: A list of phandles and specifier pairs. | |
| 40 | +- clock-names: Name of the clocks. | |
| 41 | + - The functional clock must be "ehci_ohci" | |
| 42 | + - The USB_EXTAL clock pin must be "usb_extal" | |
| 43 | + - The USB_XTAL clock pin must be "usb_xtal" | |
| 44 | +- #clock-cells: Must be 0 | |
| 45 | + | |
| 46 | +Example (R-Car H3): | |
| 47 | + | |
| 48 | + usb2_clksel: clock-controller@e6590630 { | |
| 49 | + compatible = "renesas,r8a77950-rcar-usb2-clock-sel", | |
| 50 | + "renesas,rcar-gen3-usb2-clock-sel"; | |
| 51 | + reg = <0 0xe6590630 0 0x02>; | |
| 52 | + clocks = <&cpg CPG_MOD 703>, <&usb_extal>, <&usb_xtal>; | |
| 53 | + clock-names = "ehci_ohci", "usb_extal", "usb_xtal"; | |
| 54 | + #clock-cells = <0>; | |
| 55 | + }; | |
| @@ -50,5 +50,4 @@ Examples · 49 unmodified lines | ||
| 50 | 50 | clocks = <&mstp3_clks R7S72100_CLK_MTU2>; |
| 51 | 51 | clock-names = "fck"; |
| 52 | 52 | power-domains = <&cpg_clocks>; |
| 53 | − status = "disabled"; | |
| 54 | 53 | }; |
| @@ -1,12 +1,14 @@ | ||
| 1 | −* Rockchip RK3128 Clock and Reset Unit | |
| 1 | +* Rockchip RK3126/RK3128 Clock and Reset Unit | |
| 2 | 2 | |
| 3 | −The RK3128 clock controller generates and supplies clock to various | |
| 3 | +The RK3126/RK3128 clock controller generates and supplies clock to various | |
| 4 | 4 | controllers within the SoC and also implements a reset controller for SoC |
| 5 | 5 | peripherals. |
| 6 | 6 | |
| 7 | 7 | Required Properties: |
| 8 | 8 | |
| 9 | −- compatible: should be "rockchip,rk3128-cru" | |
| 9 | +- compatible: should be "rockchip,rk3126-cru" or "rockchip,rk3128-cru" | |
| 10 | + "rockchip,rk3126-cru" - controller compatible with RK3126 SoC. | |
| 11 | + "rockchip,rk3128-cru" - controller compatible with RK3128 SoC. | |
| 10 | 12 | - reg: physical base address of the controller and length of memory mapped |
| 11 | 13 | region. |
| 12 | 14 | - #clock-cells: should be 1. |
| @@ -46,5 +46,4 @@ Example: UART controller node that consumes the clock generated by the clock · 45 unmodified lines | ||
| 46 | 46 | interrupts = <1 23 3 4>, <1 23 4 4>; |
| 47 | 47 | clock-names = "uart", "clk_uart_baud2"; |
| 48 | 48 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>; |
| 49 | − status = "disabled"; | |
| 50 | 49 | }; |
| @@ -46,5 +46,4 @@ Example: UART controller node that consumes the clock generated by the clock · 45 unmodified lines | ||
| 46 | 46 | clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3"; |
| 47 | 47 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, |
| 48 | 48 | <&clocks SCLK_UART>; |
| 49 | − status = "disabled"; | |
| 50 | 49 | }; |
| @@ -52,5 +52,4 @@ Example: UART controller node that consumes the clock generated by the clock · 51 unmodified lines | ||
| 52 | 52 | "clk_uart_baud3"; |
| 53 | 53 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, |
| 54 | 54 | <&clocks SCLK_UART>; |
| 55 | − status = "disabled"; | |
| 56 | 55 | }; |
| @@ -73,5 +73,4 @@ Example: UART controller node that consumes the clock generated by the clock · 72 unmodified lines | ||
| 73 | 73 | "clk_uart_baud3"; |
| 74 | 74 | clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>, |
| 75 | 75 | <&clock SCLK_UART>; |
| 76 | − status = "disabled"; | |
| 77 | 76 | }; |
| @@ -74,5 +74,4 @@ Example: UART controller node that consumes the clock generated by the clock · 73 unmodified lines | ||
| 74 | 74 | "clk_uart_baud1"; |
| 75 | 75 | clocks = <&clocks UART0>, <&clocks UART0>, |
| 76 | 76 | <&clocks SCLK_UART0>; |
| 77 | − status = "disabled"; | |
| 78 | 77 | }; |
| @@ -12,7 +12,11 @@ generators can be found in [1]. · 11 unmodified lines | ||
| 12 | 12 | ==I2C device node== |
| 13 | 13 | |
| 14 | 14 | Required properties: |
| 15 | −- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}". | |
| 15 | +- compatible: shall be one of the following: | |
| 16 | + "silabs,si5351a" - Si5351a, QFN20 package | |
| 17 | + "silabs,si5351a-msop" - Si5351a, MSOP10 package | |
| 18 | + "silabs,si5351b" - Si5351b, QFN20 package | |
| 19 | + "silabs,si5351c" - Si5351c, QFN20 package | |
| 16 | 20 | - reg: i2c device address, shall be 0x60 or 0x61. |
| 17 | 21 | - #clock-cells: from common clock binding; shall be set to 1. |
| 18 | 22 | - clocks: from common clock binding; list of parent clock |
| @@ -0,0 +1,28 @@ | ||
| 1 | +Binding for the HSDK Generic PLL clock | |
| 2 | + | |
| 3 | +This binding uses the common clock binding[1]. | |
| 4 | + | |
| 5 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: should be "snps,hsdk-<name>-pll-clock" | |
| 9 | + "snps,hsdk-core-pll-clock" | |
| 10 | + "snps,hsdk-gp-pll-clock" | |
| 11 | + "snps,hsdk-hdmi-pll-clock" | |
| 12 | +- reg : should contain base register location and length. | |
| 13 | +- clocks: shall be the input parent clock phandle for the PLL. | |
| 14 | +- #clock-cells: from common clock binding; Should always be set to 0. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + input_clk: input-clk { | |
| 18 | + clock-frequency = <33333333>; | |
| 19 | + compatible = "fixed-clock"; | |
| 20 | + #clock-cells = <0>; | |
| 21 | + }; | |
| 22 | + | |
| 23 | + cpu_clk: cpu-clk@0 { | |
| 24 | + compatible = "snps,hsdk-core-pll-clock"; | |
| 25 | + reg = <0x00 0x10>; | |
| 26 | + #clock-cells = <0>; | |
| 27 | + clocks = <&input_clk>; | |
| 28 | + }; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +Binding for the AXS10X Generic PLL clock | |
| 2 | + | |
| 3 | +This binding uses the common clock binding[1]. | |
| 4 | + | |
| 5 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: should be "snps,axs10x-<name>-pll-clock" | |
| 9 | + "snps,axs10x-arc-pll-clock" | |
| 10 | + "snps,axs10x-pgu-pll-clock" | |
| 11 | +- reg: should always contain 2 pairs address - length: first for PLL config | |
| 12 | +registers and second for corresponding LOCK CGU register. | |
| 13 | +- clocks: shall be the input parent clock phandle for the PLL. | |
| 14 | +- #clock-cells: from common clock binding; Should always be set to 0. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + input-clk: input-clk { | |
| 18 | + clock-frequency = <33333333>; | |
| 19 | + compatible = "fixed-clock"; | |
| 20 | + #clock-cells = <0>; | |
| 21 | + }; | |
| 22 | + | |
| 23 | + core-clk: core-clk@80 { | |
| 24 | + compatible = "snps,axs10x-arc-pll-clock"; | |
| 25 | + reg = <0x80 0x10>, <0x100 0x10>; | |
| 26 | + #clock-cells = <0>; | |
| 27 | + clocks = <&input-clk>; | |
| 28 | + }; | |
| @@ -0,0 +1,71 @@ | ||
| 1 | +STMicroelectronics STM32H7 Reset and Clock Controller | |
| 2 | +===================================================== | |
| 3 | + | |
| 4 | +The RCC IP is both a reset and a clock controller. | |
| 5 | + | |
| 6 | +Please refer to clock-bindings.txt for common clock controller binding usage. | |
| 7 | +Please also refer to reset.txt for common reset controller binding usage. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Should be: | |
| 11 | + "st,stm32h743-rcc" | |
| 12 | + | |
| 13 | +- reg: should be register base and length as documented in the | |
| 14 | + datasheet | |
| 15 | + | |
| 16 | +- #reset-cells: 1, see below | |
| 17 | + | |
| 18 | +- #clock-cells : from common clock binding; shall be set to 1 | |
| 19 | + | |
| 20 | +- clocks: External oscillator clock phandle | |
| 21 | + - high speed external clock signal (HSE) | |
| 22 | + - low speed external clock signal (LSE) | |
| 23 | + - external I2S clock (I2S_CKIN) | |
| 24 | + | |
| 25 | +Optional properties: | |
| 26 | +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain | |
| 27 | + write protection (RTC clock). | |
| 28 | + | |
| 29 | +Example: | |
| 30 | + | |
| 31 | + rcc: reset-clock-controller@58024400 { | |
| 32 | + compatible = "st,stm32h743-rcc", "st,stm32-rcc"; | |
| 33 | + reg = <0x58024400 0x400>; | |
| 34 | + #reset-cells = <1>; | |
| 35 | + #clock-cells = <1>; | |
| 36 | + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>; | |
| 37 | + | |
| 38 | + st,syscfg = <&pwrcfg>; | |
| 39 | +}; | |
| 40 | + | |
| 41 | +The peripheral clock consumer should specify the desired clock by | |
| 42 | +having the clock ID in its "clocks" phandle cell. | |
| 43 | + | |
| 44 | +Example: | |
| 45 | + | |
| 46 | + timer5: timer@40000c00 { | |
| 47 | + compatible = "st,stm32-timer"; | |
| 48 | + reg = <0x40000c00 0x400>; | |
| 49 | + interrupts = <50>; | |
| 50 | + clocks = <&rcc TIM5_CK>; | |
| 51 | + }; | |
| 52 | + | |
| 53 | +Specifying softreset control of devices | |
| 54 | +======================================= | |
| 55 | + | |
| 56 | +Device nodes should specify the reset channel required in their "resets" | |
| 57 | +property, containing a phandle to the reset device node and an index specifying | |
| 58 | +which channel to use. | |
| 59 | +The index is the bit number within the RCC registers bank, starting from RCC | |
| 60 | +base address. | |
| 61 | +It is calculated as: index = register_offset / 4 * 32 + bit_offset. | |
| 62 | +Where bit_offset is the bit offset within the register. | |
| 63 | + | |
| 64 | +For example, for CRC reset: | |
| 65 | + crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107 | |
| 66 | + | |
| 67 | +Example: | |
| 68 | + | |
| 69 | + timer2 { | |
| 70 | + resets = <&rcc STM32H7_APB1L_RESET(TIM2)>; | |
| 71 | + }; | |
| @@ -3,18 +3,24 @@ Allwinner Clock Control Unit Binding · 2 unmodified lines | ||
| 3 | 3 | |
| 4 | 4 | Required properties : |
| 5 | 5 | - compatible: must contain one of the following compatibles: |
| 6 | + - "allwinner,sun4i-a10-ccu" | |
| 7 | + - "allwinner,sun5i-a10s-ccu" | |
| 8 | + - "allwinner,sun5i-a13-ccu" | |
| 6 | 9 | - "allwinner,sun6i-a31-ccu" |
| 10 | + - "allwinner,sun7i-a20-ccu" | |
| 7 | 11 | - "allwinner,sun8i-a23-ccu" |
| 8 | 12 | - "allwinner,sun8i-a33-ccu" |
| 9 | 13 | - "allwinner,sun8i-a83t-ccu" |
| 10 | 14 | - "allwinner,sun8i-a83t-r-ccu" |
| 11 | 15 | - "allwinner,sun8i-h3-ccu" |
| 12 | 16 | - "allwinner,sun8i-h3-r-ccu" |
| 17 | ++ - "allwinner,sun8i-r40-ccu" | |
| 13 | 18 | - "allwinner,sun8i-v3s-ccu" |
| 14 | 19 | - "allwinner,sun9i-a80-ccu" |
| 15 | 20 | - "allwinner,sun50i-a64-ccu" |
| 16 | 21 | - "allwinner,sun50i-a64-r-ccu" |
| 17 | 22 | - "allwinner,sun50i-h5-ccu" |
| 23 | + - "nextthing,gr8-ccu" | |
| 18 | 24 | |
| 19 | 25 | - reg: Must contain the registers base address and length |
| 20 | 26 | - clocks: phandle to the oscillators feeding the CCU. Two are needed: |
| @@ -14,10 +14,9 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | - compatible: Must be "ti,k2g-sci-clk" |
| 15 | 15 | - #clock-cells: Shall be 2. |
| 16 | 16 | In clock consumers, this cell represents the device ID and clock ID |
| 17 | − exposed by the PM firmware. The assignments can be found in the header | |
| 18 | − files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and | |
| 19 | − <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc> | |
| 20 | − is the SoC involved, for example 'k2g'. | |
| 17 | + exposed by the PM firmware. The list of valid values for the device IDs | |
| 18 | + and clocks IDs for 66AK2G SoC are documented at | |
| 19 | + http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data | |
| 21 | 20 | |
| 22 | 21 | Examples: |
| 23 | 22 | -------- |
| @@ -81,13 +81,11 @@ atl: atl@4843c000 { · 80 unmodified lines | ||
| 81 | 81 | <&atl_clkin2_ck>, <&atl_clkin3_ck>; |
| 82 | 82 | clocks = <&atl_gfclk_mux>; |
| 83 | 83 | clock-names = "fck"; |
| 84 | − status = "disabled"; | |
| 85 | 84 | }; |
| 86 | 85 | |
| 87 | 86 | #include <dt-bindings/clk/ti-dra7-atl.h> |
| 88 | 87 | |
| 89 | 88 | &atl { |
| 90 | − status = "okay"; | |
| 91 | 89 | |
| 92 | 90 | atl2 { |
| 93 | 91 | bws = <DRA7_ATL_WS_MCASP2_FSX>; |
| @@ -6,7 +6,6 @@ System clock · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: should be one of the following: |
| 9 | − "socionext,uniphier-sld3-clock" - for sLD3 SoC. | |
| 10 | 9 | "socionext,uniphier-ld4-clock" - for LD4 SoC. |
| 11 | 10 | "socionext,uniphier-pro4-clock" - for Pro4 SoC. |
| 12 | 11 | "socionext,uniphier-sld8-clock" - for sLD8 SoC. |
| @@ -14,6 +13,7 @@ Required properties: · 1 unmodified line | ||
| 14 | 13 | "socionext,uniphier-pxs2-clock" - for PXs2/LD6b SoC. |
| 15 | 14 | "socionext,uniphier-ld11-clock" - for LD11 SoC. |
| 16 | 15 | "socionext,uniphier-ld20-clock" - for LD20 SoC. |
| 16 | + "socionext,uniphier-pxs3-clock" - for PXs3 SoC | |
| 17 | 17 | - #clock-cells: should be 1. |
| 18 | 18 | |
| 19 | 19 | Example: |
| @@ -48,7 +48,6 @@ Media I/O (MIO) clock, SD clock · 28 unmodified lines | ||
| 48 | 48 | |
| 49 | 49 | Required properties: |
| 50 | 50 | - compatible: should be one of the following: |
| 51 | − "socionext,uniphier-sld3-mio-clock" - for sLD3 SoC. | |
| 52 | 51 | "socionext,uniphier-ld4-mio-clock" - for LD4 SoC. |
| 53 | 52 | "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC. |
| 54 | 53 | "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC. |
| @@ -56,6 +55,7 @@ Required properties: · 1 unmodified line | ||
| 56 | 55 | "socionext,uniphier-pxs2-sd-clock" - for PXs2/LD6b SoC. |
| 57 | 56 | "socionext,uniphier-ld11-mio-clock" - for LD11 SoC. |
| 58 | 57 | "socionext,uniphier-ld20-sd-clock" - for LD20 SoC. |
| 58 | + "socionext,uniphier-pxs3-sd-clock" - for PXs3 SoC | |
| 59 | 59 | - #clock-cells: should be 1. |
| 60 | 60 | |
| 61 | 61 | Example: |
| @@ -82,11 +82,9 @@ Provided clocks: · 20 unmodified lines | ||
| 82 | 82 | 8: USB2 ch0 host |
| 83 | 83 | 9: USB2 ch1 host |
| 84 | 84 | 10: USB2 ch2 host |
| 85 | −11: USB2 ch3 host | |
| 86 | 85 | 12: USB2 ch0 PHY |
| 87 | 86 | 13: USB2 ch1 PHY |
| 88 | 87 | 14: USB2 ch2 PHY |
| 89 | −15: USB2 ch3 PHY | |
| 90 | 88 | |
| 91 | 89 | |
| 92 | 90 | Peripheral clock |
| @@ -94,7 +92,6 @@ Peripheral clock · 1 unmodified line | ||
| 94 | 92 | |
| 95 | 93 | Required properties: |
| 96 | 94 | - compatible: should be one of the following: |
| 97 | − "socionext,uniphier-sld3-peri-clock" - for sLD3 SoC. | |
| 98 | 95 | "socionext,uniphier-ld4-peri-clock" - for LD4 SoC. |
| 99 | 96 | "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC. |
| 100 | 97 | "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC. |
| @@ -102,6 +99,7 @@ Required properties: · 1 unmodified line | ||
| 102 | 99 | "socionext,uniphier-pxs2-peri-clock" - for PXs2/LD6b SoC. |
| 103 | 100 | "socionext,uniphier-ld11-peri-clock" - for LD11 SoC. |
| 104 | 101 | "socionext,uniphier-ld20-peri-clock" - for LD20 SoC. |
| 102 | + "socionext,uniphier-pxs3-peri-clock" - for PXs3 SoC | |
| 105 | 103 | - #clock-cells: should be 1. |
| 106 | 104 | |
| 107 | 105 | Example: |
| @@ -31,5 +31,4 @@ uart0: serial@0x09405000 { · 30 unmodified lines | ||
| 31 | 31 | reg = <0x09405000 0x1000>; |
| 32 | 32 | interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; |
| 33 | 33 | clocks = <&lsp1clk ZX296702_UART0_PCLK>; |
| 34 | − status = "disabled"; | |
| 35 | 34 | }; |
| @@ -34,5 +34,4 @@ usbphy0:usb-phy0 { · 33 unmodified lines | ||
| 34 | 34 | #phy-cells = <0>; |
| 35 | 35 | clocks = <&topclk USB20_PHY_CLK>; |
| 36 | 36 | clock-names = "phyclk"; |
| 37 | − status = "okay"; | |
| 38 | 37 | }; |
| @@ -0,0 +1,247 @@ | ||
| 1 | +Binding for MediaTek's CPUFreq driver | |
| 2 | +===================================== | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names. | |
| 6 | +- clock-names: Should contain the following: | |
| 7 | + "cpu" - The multiplexer for clock input of CPU cluster. | |
| 8 | + "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock | |
| 9 | + source (usually MAINPLL) when the original CPU PLL is under | |
| 10 | + transition and not stable yet. | |
| 11 | + Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for | |
| 12 | + generic clock consumer properties. | |
| 13 | +- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt | |
| 14 | + for detail. | |
| 15 | +- proc-supply: Regulator for Vproc of CPU cluster. | |
| 16 | + | |
| 17 | +Optional properties: | |
| 18 | +- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver | |
| 19 | + needs to do "voltage tracking" to step by step scale up/down Vproc and | |
| 20 | + Vsram to fit SoC specific needs. When absent, the voltage scaling | |
| 21 | + flow is handled by hardware, hence no software "voltage tracking" is | |
| 22 | + needed. | |
| 23 | +- #cooling-cells: | |
| 24 | +- cooling-min-level: | |
| 25 | +- cooling-max-level: | |
| 26 | + Please refer to Documentation/devicetree/bindings/thermal/thermal.txt | |
| 27 | + for detail. | |
| 28 | + | |
| 29 | +Example 1 (MT7623 SoC): | |
| 30 | + | |
| 31 | + cpu_opp_table: opp_table { | |
| 32 | + compatible = "operating-points-v2"; | |
| 33 | + opp-shared; | |
| 34 | + | |
| 35 | + opp-598000000 { | |
| 36 | + opp-hz = /bits/ 64 <598000000>; | |
| 37 | + opp-microvolt = <1050000>; | |
| 38 | + }; | |
| 39 | + | |
| 40 | + opp-747500000 { | |
| 41 | + opp-hz = /bits/ 64 <747500000>; | |
| 42 | + opp-microvolt = <1050000>; | |
| 43 | + }; | |
| 44 | + | |
| 45 | + opp-1040000000 { | |
| 46 | + opp-hz = /bits/ 64 <1040000000>; | |
| 47 | + opp-microvolt = <1150000>; | |
| 48 | + }; | |
| 49 | + | |
| 50 | + opp-1196000000 { | |
| 51 | + opp-hz = /bits/ 64 <1196000000>; | |
| 52 | + opp-microvolt = <1200000>; | |
| 53 | + }; | |
| 54 | + | |
| 55 | + opp-1300000000 { | |
| 56 | + opp-hz = /bits/ 64 <1300000000>; | |
| 57 | + opp-microvolt = <1300000>; | |
| 58 | + }; | |
| 59 | + }; | |
| 60 | + | |
| 61 | + cpu0: cpu@0 { | |
| 62 | + device_type = "cpu"; | |
| 63 | + compatible = "arm,cortex-a7"; | |
| 64 | + reg = <0x0>; | |
| 65 | + clocks = <&infracfg CLK_INFRA_CPUSEL>, | |
| 66 | + <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 67 | + clock-names = "cpu", "intermediate"; | |
| 68 | + operating-points-v2 = <&cpu_opp_table>; | |
| 69 | + #cooling-cells = <2>; | |
| 70 | + cooling-min-level = <0>; | |
| 71 | + cooling-max-level = <7>; | |
| 72 | + }; | |
| 73 | + cpu@1 { | |
| 74 | + device_type = "cpu"; | |
| 75 | + compatible = "arm,cortex-a7"; | |
| 76 | + reg = <0x1>; | |
| 77 | + operating-points-v2 = <&cpu_opp_table>; | |
| 78 | + }; | |
| 79 | + cpu@2 { | |
| 80 | + device_type = "cpu"; | |
| 81 | + compatible = "arm,cortex-a7"; | |
| 82 | + reg = <0x2>; | |
| 83 | + operating-points-v2 = <&cpu_opp_table>; | |
| 84 | + }; | |
| 85 | + cpu@3 { | |
| 86 | + device_type = "cpu"; | |
| 87 | + compatible = "arm,cortex-a7"; | |
| 88 | + reg = <0x3>; | |
| 89 | + operating-points-v2 = <&cpu_opp_table>; | |
| 90 | + }; | |
| 91 | + | |
| 92 | +Example 2 (MT8173 SoC): | |
| 93 | + cpu_opp_table_a: opp_table_a { | |
| 94 | + compatible = "operating-points-v2"; | |
| 95 | + opp-shared; | |
| 96 | + | |
| 97 | + opp-507000000 { | |
| 98 | + opp-hz = /bits/ 64 <507000000>; | |
| 99 | + opp-microvolt = <859000>; | |
| 100 | + }; | |
| 101 | + | |
| 102 | + opp-702000000 { | |
| 103 | + opp-hz = /bits/ 64 <702000000>; | |
| 104 | + opp-microvolt = <908000>; | |
| 105 | + }; | |
| 106 | + | |
| 107 | + opp-1001000000 { | |
| 108 | + opp-hz = /bits/ 64 <1001000000>; | |
| 109 | + opp-microvolt = <983000>; | |
| 110 | + }; | |
| 111 | + | |
| 112 | + opp-1105000000 { | |
| 113 | + opp-hz = /bits/ 64 <1105000000>; | |
| 114 | + opp-microvolt = <1009000>; | |
| 115 | + }; | |
| 116 | + | |
| 117 | + opp-1183000000 { | |
| 118 | + opp-hz = /bits/ 64 <1183000000>; | |
| 119 | + opp-microvolt = <1028000>; | |
| 120 | + }; | |
| 121 | + | |
| 122 | + opp-1404000000 { | |
| 123 | + opp-hz = /bits/ 64 <1404000000>; | |
| 124 | + opp-microvolt = <1083000>; | |
| 125 | + }; | |
| 126 | + | |
| 127 | + opp-1508000000 { | |
| 128 | + opp-hz = /bits/ 64 <1508000000>; | |
| 129 | + opp-microvolt = <1109000>; | |
| 130 | + }; | |
| 131 | + | |
| 132 | + opp-1573000000 { | |
| 133 | + opp-hz = /bits/ 64 <1573000000>; | |
| 134 | + opp-microvolt = <1125000>; | |
| 135 | + }; | |
| 136 | + }; | |
| 137 | + | |
| 138 | + cpu_opp_table_b: opp_table_b { | |
| 139 | + compatible = "operating-points-v2"; | |
| 140 | + opp-shared; | |
| 141 | + | |
| 142 | + opp-507000000 { | |
| 143 | + opp-hz = /bits/ 64 <507000000>; | |
| 144 | + opp-microvolt = <828000>; | |
| 145 | + }; | |
| 146 | + | |
| 147 | + opp-702000000 { | |
| 148 | + opp-hz = /bits/ 64 <702000000>; | |
| 149 | + opp-microvolt = <867000>; | |
| 150 | + }; | |
| 151 | + | |
| 152 | + opp-1001000000 { | |
| 153 | + opp-hz = /bits/ 64 <1001000000>; | |
| 154 | + opp-microvolt = <927000>; | |
| 155 | + }; | |
| 156 | + | |
| 157 | + opp-1209000000 { | |
| 158 | + opp-hz = /bits/ 64 <1209000000>; | |
| 159 | + opp-microvolt = <968000>; | |
| 160 | + }; | |
| 161 | + | |
| 162 | + opp-1404000000 { | |
| 163 | + opp-hz = /bits/ 64 <1007000000>; | |
| 164 | + opp-microvolt = <1028000>; | |
| 165 | + }; | |
| 166 | + | |
| 167 | + opp-1612000000 { | |
| 168 | + opp-hz = /bits/ 64 <1612000000>; | |
| 169 | + opp-microvolt = <1049000>; | |
| 170 | + }; | |
| 171 | + | |
| 172 | + opp-1807000000 { | |
| 173 | + opp-hz = /bits/ 64 <1807000000>; | |
| 174 | + opp-microvolt = <1089000>; | |
| 175 | + }; | |
| 176 | + | |
| 177 | + opp-1989000000 { | |
| 178 | + opp-hz = /bits/ 64 <1989000000>; | |
| 179 | + opp-microvolt = <1125000>; | |
| 180 | + }; | |
| 181 | + }; | |
| 182 | + | |
| 183 | + cpu0: cpu@0 { | |
| 184 | + device_type = "cpu"; | |
| 185 | + compatible = "arm,cortex-a53"; | |
| 186 | + reg = <0x000>; | |
| 187 | + enable-method = "psci"; | |
| 188 | + cpu-idle-states = <&CPU_SLEEP_0>; | |
| 189 | + clocks = <&infracfg CLK_INFRA_CA53SEL>, | |
| 190 | + <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 191 | + clock-names = "cpu", "intermediate"; | |
| 192 | + operating-points-v2 = <&cpu_opp_table_a>; | |
| 193 | + }; | |
| 194 | + | |
| 195 | + cpu1: cpu@1 { | |
| 196 | + device_type = "cpu"; | |
| 197 | + compatible = "arm,cortex-a53"; | |
| 198 | + reg = <0x001>; | |
| 199 | + enable-method = "psci"; | |
| 200 | + cpu-idle-states = <&CPU_SLEEP_0>; | |
| 201 | + clocks = <&infracfg CLK_INFRA_CA53SEL>, | |
| 202 | + <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 203 | + clock-names = "cpu", "intermediate"; | |
| 204 | + operating-points-v2 = <&cpu_opp_table_a>; | |
| 205 | + }; | |
| 206 | + | |
| 207 | + cpu2: cpu@100 { | |
| 208 | + device_type = "cpu"; | |
| 209 | + compatible = "arm,cortex-a57"; | |
| 210 | + reg = <0x100>; | |
| 211 | + enable-method = "psci"; | |
| 212 | + cpu-idle-states = <&CPU_SLEEP_0>; | |
| 213 | + clocks = <&infracfg CLK_INFRA_CA57SEL>, | |
| 214 | + <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 215 | + clock-names = "cpu", "intermediate"; | |
| 216 | + operating-points-v2 = <&cpu_opp_table_b>; | |
| 217 | + }; | |
| 218 | + | |
| 219 | + cpu3: cpu@101 { | |
| 220 | + device_type = "cpu"; | |
| 221 | + compatible = "arm,cortex-a57"; | |
| 222 | + reg = <0x101>; | |
| 223 | + enable-method = "psci"; | |
| 224 | + cpu-idle-states = <&CPU_SLEEP_0>; | |
| 225 | + clocks = <&infracfg CLK_INFRA_CA57SEL>, | |
| 226 | + <&apmixedsys CLK_APMIXED_MAINPLL>; | |
| 227 | + clock-names = "cpu", "intermediate"; | |
| 228 | + operating-points-v2 = <&cpu_opp_table_b>; | |
| 229 | + }; | |
| 230 | + | |
| 231 | + &cpu0 { | |
| 232 | + proc-supply = <&mt6397_vpca15_reg>; | |
| 233 | + }; | |
| 234 | + | |
| 235 | + &cpu1 { | |
| 236 | + proc-supply = <&mt6397_vpca15_reg>; | |
| 237 | + }; | |
| 238 | + | |
| 239 | + &cpu2 { | |
| 240 | + proc-supply = <&da9211_vcpu_reg>; | |
| 241 | + sram-supply = <&mt6397_vsramca7_reg>; | |
| 242 | + }; | |
| 243 | + | |
| 244 | + &cpu3 { | |
| 245 | + proc-supply = <&da9211_vcpu_reg>; | |
| 246 | + sram-supply = <&mt6397_vsramca7_reg>; | |
| 247 | + }; | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +Axis crypto engine with PDMA interface. | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : Should be one of the following strings: | |
| 5 | + "axis,artpec6-crypto" for the version in the Axis ARTPEC-6 SoC | |
| 6 | + "axis,artpec7-crypto" for the version in the Axis ARTPEC-7 SoC. | |
| 7 | +- reg: Base address and size for the PDMA register area. | |
| 8 | +- interrupts: Interrupt handle for the PDMA interrupt line. | |
| 9 | + | |
| 10 | +Example: | |
| 11 | + | |
| 12 | +crypto@f4264000 { | |
| 13 | + compatible = "axis,artpec6-crypto"; | |
| 14 | + reg = <0xf4264000 0x1000>; | |
| 15 | + interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>; | |
| 16 | +}; | |
| @@ -66,3 +66,16 @@ sha@f8034000 { · 65 unmodified lines | ||
| 66 | 66 | dmas = <&dma1 2 17>; |
| 67 | 67 | dma-names = "tx"; |
| 68 | 68 | }; |
| 69 | + | |
| 70 | +* Eliptic Curve Cryptography (I2C) | |
| 71 | + | |
| 72 | +Required properties: | |
| 73 | +- compatible : must be "atmel,atecc508a". | |
| 74 | +- reg: I2C bus address of the device. | |
| 75 | +- clock-frequency: must be present in the i2c controller node. | |
| 76 | + | |
| 77 | +Example: | |
| 78 | +atecc508a@C0 { | |
| 79 | + compatible = "atmel,atecc508a"; | |
| 80 | + reg = <0xC0>; | |
| 81 | +}; | |
| @@ -13,5 +13,4 @@ dcp@80028000 { · 12 unmodified lines | ||
| 13 | 13 | compatible = "fsl,imx28-dcp", "fsl,imx23-dcp"; |
| 14 | 14 | reg = <0x80028000 0x2000>; |
| 15 | 15 | interrupts = <52 53>; |
| 16 | − status = "okay"; | |
| 17 | 16 | }; |
| @@ -23,5 +23,4 @@ Example: · 22 unmodified lines | ||
| 23 | 23 | interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", |
| 24 | 24 | "eip"; |
| 25 | 25 | clocks = <&cpm_syscon0 1 26>; |
| 26 | − status = "disabled"; | |
| 27 | 26 | }; |
| @@ -41,5 +41,4 @@ Examples: · 40 unmodified lines | ||
| 41 | 41 | clock-names = "cesa0", "cesa1"; |
| 42 | 42 | marvell,crypto-srams = <&crypto_sram0>, <&crypto_sram1>; |
| 43 | 43 | marvell,crypto-sram-size = <0x600>; |
| 44 | − status = "okay"; | |
| 45 | 44 | }; |
| @@ -29,5 +29,4 @@ Examples: · 28 unmodified lines | ||
| 29 | 29 | interrupts = <22>; |
| 30 | 30 | marvell,crypto-srams = <&crypto_sram>; |
| 31 | 31 | marvell,crypto-sram-size = <0x600>; |
| 32 | − status = "okay"; | |
| 33 | 32 | }; |
| @@ -25,5 +25,4 @@ Examples: · 24 unmodified lines | ||
| 25 | 25 | clock-names = "aclk", "hclk", "sclk", "apb_pclk"; |
| 26 | 26 | resets = <&cru SRST_CRYPTO>; |
| 27 | 27 | reset-names = "crypto-rst"; |
| 28 | − status = "okay"; | |
| 29 | 28 | }; |
| @@ -0,0 +1,30 @@ | ||
| 1 | +* STMicroelectronics STM32 HASH | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should contain entries for this and backward compatible | |
| 5 | + HASH versions: | |
| 6 | + - "st,stm32f456-hash" for stm32 F456. | |
| 7 | + - "st,stm32f756-hash" for stm32 F756. | |
| 8 | +- reg: The address and length of the peripheral registers space | |
| 9 | +- interrupts: the interrupt specifier for the HASH | |
| 10 | +- clocks: The input clock of the HASH instance | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- resets: The input reset of the HASH instance | |
| 14 | +- dmas: DMA specifiers for the HASH. See the DMA client binding, | |
| 15 | + Documentation/devicetree/bindings/dma/dma.txt | |
| 16 | +- dma-names: DMA request name. Should be "in" if a dma is present. | |
| 17 | +- dma-maxburst: Set number of maximum dma burst supported | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | +hash1: hash@50060400 { | |
| 22 | + compatible = "st,stm32f756-hash"; | |
| 23 | + reg = <0x50060400 0x400>; | |
| 24 | + interrupts = <80>; | |
| 25 | + clocks = <&rcc 0 STM32F7_AHB2_CLOCK(HASH)>; | |
| 26 | + resets = <&rcc STM32F7_AHB2_RESET(HASH)>; | |
| 27 | + dmas = <&dma2 7 2 0x400 0x0>; | |
| 28 | + dma-names = "in"; | |
| 29 | + dma-maxburst = <0>; | |
| 30 | +}; | |
| @@ -15,5 +15,4 @@ Example: · 14 unmodified lines | ||
| 15 | 15 | rockchip,pmu = <&pmugrf>; |
| 16 | 16 | clocks = <&cru PCLK_DDR_MON>; |
| 17 | 17 | clock-names = "pclk_ddr_mon"; |
| 18 | − status = "disabled"; | |
| 19 | 18 | }; |
| @@ -205,5 +205,4 @@ Example: · 204 unmodified lines | ||
| 205 | 205 | rockchip,phy_lpddr4_ck_cs_drv = <PHY_DRV_ODT_80>; |
| 206 | 206 | rockchip,phy_lpddr4_dq_drv = <PHY_DRV_ODT_80>; |
| 207 | 207 | rockchip,phy_lpddr4_odt = <PHY_DRV_ODT_60>; |
| 208 | − status = "disabled"; | |
| 209 | 208 | }; |
| @@ -34,7 +34,6 @@ Example: · 33 unmodified lines | ||
| 34 | 34 | pinctrl-names = "default"; |
| 35 | 35 | pinctrl-0 = <&pinctrl_fb>; |
| 36 | 36 | display = <&display0>; |
| 37 | − status = "okay"; | |
| 38 | 37 | #address-cells = <1>; |
| 39 | 38 | #size-cells = <1>; |
| 40 | 39 | |
| @@ -23,7 +23,6 @@ Example: · 22 unmodified lines | ||
| 23 | 23 | interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; |
| 24 | 24 | clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; |
| 25 | 25 | clock-names = "periph_clk","sys_clk", "slow_clk"; |
| 26 | − status = "disabled"; | |
| 27 | 26 | |
| 28 | 27 | hlcdc-display-controller { |
| 29 | 28 | compatible = "atmel,hlcdc-display-controller"; |
| @@ -0,0 +1,32 @@ | ||
| 1 | +Synopsys DesignWare MIPI DSI host controller | |
| 2 | +============================================ | |
| 3 | + | |
| 4 | +This document defines device tree properties for the Synopsys DesignWare MIPI | |
| 5 | +DSI host controller. It doesn't constitue a device tree binding specification | |
| 6 | +by itself but is meant to be referenced by platform-specific device tree | |
| 7 | +bindings. | |
| 8 | + | |
| 9 | +When referenced from platform device tree bindings the properties defined in | |
| 10 | +this document are defined as follows. The platform device tree bindings are | |
| 11 | +responsible for defining whether each optional property is used or not. | |
| 12 | + | |
| 13 | +- reg: Memory mapped base address and length of the DesignWare MIPI DSI | |
| 14 | + host controller registers. (mandatory) | |
| 15 | + | |
| 16 | +- clocks: References to all the clocks specified in the clock-names property | |
| 17 | + as specified in [1]. (mandatory) | |
| 18 | + | |
| 19 | +- clock-names: | |
| 20 | + - "pclk" is the peripheral clock for either AHB and APB. (mandatory) | |
| 21 | + - "px_clk" is the pixel clock for the DPI/RGB input. (optional) | |
| 22 | + | |
| 23 | +- resets: References to all the resets specified in the reset-names property | |
| 24 | + as specified in [2]. (optional) | |
| 25 | + | |
| 26 | +- reset-names: string reset name, must be "apb" if used. (optional) | |
| 27 | + | |
| 28 | +- panel or bridge node: see [3]. (mandatory) | |
| 29 | + | |
| 30 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 31 | +[2] Documentation/devicetree/bindings/reset/reset.txt | |
| 32 | +[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt | |
| @@ -33,7 +33,6 @@ stdp2690-ge-b850v3-fw required properties: · 32 unmodified lines | ||
| 33 | 33 | Example: |
| 34 | 34 | |
| 35 | 35 | &mux2_i2c2 { |
| 36 | − status = "okay"; | |
| 37 | 36 | clock-frequency = <100000>; |
| 38 | 37 | |
| 39 | 38 | stdp4028@73 { |
| @@ -13,6 +13,7 @@ Required properties: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | - compatible : Shall contain one or more of |
| 15 | 15 | - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX |
| 16 | + - "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX | |
| 16 | 17 | - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX |
| 17 | 18 | |
| 18 | 19 | When compatible with generic versions, nodes must list the SoC-specific |
| @@ -43,7 +44,6 @@ Example: · 24 unmodified lines | ||
| 43 | 44 | clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>; |
| 44 | 45 | clock-names = "iahb", "isfr"; |
| 45 | 46 | power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; |
| 46 | − status = "disabled"; | |
| 47 | 47 | |
| 48 | 48 | ports { |
| 49 | 49 | #address-cells = <1>; |
| @@ -25,12 +25,6 @@ Required properties: · 24 unmodified lines | ||
| 25 | 25 | size-cells must 1 and 0, respectively. |
| 26 | 26 | - port: contains an endpoint node which is connected to the endpoint in the mic |
| 27 | 27 | node. The reg value muset be 0. |
| 28 | −- i80-if-timings: specify whether the panel which is connected to decon uses | |
| 29 | − i80 lcd interface or mipi video interface. This node contains | |
| 30 | − no timing information as that of fimd does. Because there is | |
| 31 | − no register in decon to specify i80 interface timing value, | |
| 32 | − it is not needed, but make it remain to use same kind of node | |
| 33 | − in fimd and exynos7 decon. | |
| 34 | 28 | |
| 35 | 29 | Example: |
| 36 | 30 | SoC specific DT entry: |
| @@ -59,9 +53,3 @@ decon: decon@13800000 { · 22 unmodified lines | ||
| 59 | 53 | }; |
| 60 | 54 | }; |
| 61 | 55 | }; |
| 62 | − | |
| 63 | −Board specific DT entry: | |
| 64 | −&decon { | |
| 65 | − i80-if-timings { | |
| 66 | − }; | |
| 67 | −}; | |
| @@ -14,5 +14,4 @@ timing-controller@4003d000 { · 13 unmodified lines | ||
| 14 | 14 | reg = <0x4003d000 0x1000>; |
| 15 | 15 | clocks = <&clks VF610_CLK_TCON0>; |
| 16 | 16 | clock-names = "ipg"; |
| 17 | − status = "okay"; | |
| 18 | 17 | }; |
| @@ -116,7 +116,7 @@ Parallel display support · 115 unmodified lines | ||
| 116 | 116 | Required properties: |
| 117 | 117 | - compatible: Should be "fsl,imx-parallel-display" |
| 118 | 118 | Optional properties: |
| 119 | −- interface_pix_fmt: How this display is connected to the | |
| 119 | +- interface-pix-fmt: How this display is connected to the | |
| 120 | 120 | display interface. Currently supported types: "rgb24", "rgb565", "bgr666" |
| 121 | 121 | and "lvds666". |
| 122 | 122 | - edid: verbatim EDID data block describing attached display. |
| @@ -23,7 +23,6 @@ Example: · 22 unmodified lines | ||
| 23 | 23 | reg = <0x44000000 0x10000>; |
| 24 | 24 | interrupts = <17>; |
| 25 | 25 | clocks = <&clks CLK_LCD>; |
| 26 | − status = "okay"; | |
| 27 | 26 | |
| 28 | 27 | port { |
| 29 | 28 | lcdc_out: endpoint { |
| @@ -18,6 +18,5 @@ Example: · 17 unmodified lines | ||
| 18 | 18 | power-supply = <...>; |
| 19 | 19 | backlight = <&backlight>; |
| 20 | 20 | enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; |
| 21 | − status = "okay"; | |
| 22 | 21 | }; |
| 23 | 22 | }; |
| @@ -36,8 +36,10 @@ Required Properties: · 35 unmodified lines | ||
| 36 | 36 | When supplied they must be named "dclkin.x" with "x" being the input |
| 37 | 37 | clock numerical index. |
| 38 | 38 | |
| 39 | − - vsps: A list of phandles to the VSP nodes that handle the memory | |
| 40 | − interfaces for the DU channels. | |
| 39 | + - vsps: A list of phandle and channel index tuples to the VSPs that handle | |
| 40 | + the memory interfaces for the DU channels. The phandle identifies the VSP | |
| 41 | + instance that serves the DU channel, and the channel index identifies the | |
| 42 | + LIF instance in that VSP. | |
| 41 | 43 | |
| 42 | 44 | Required nodes: |
| 43 | 45 | |
| @@ -59,24 +61,24 @@ corresponding to each DU output. · 15 unmodified lines | ||
| 59 | 61 | R8A7796 (M3-W) DPAD HDMI LVDS - |
| 60 | 62 | |
| 61 | 63 | |
| 62 | −Example: R8A7790 (R-Car H2) DU | |
| 64 | +Example: R8A7795 (R-Car H3) ES2.0 DU | |
| 63 | 65 | |
| 64 | − du: du@feb00000 { | |
| 65 | − compatible = "renesas,du-r8a7790"; | |
| 66 | − reg = <0 0xfeb00000 0 0x70000>, | |
| 67 | − <0 0xfeb90000 0 0x1c>, | |
| 68 | − <0 0xfeb94000 0 0x1c>; | |
| 69 | − reg-names = "du", "lvds.0", "lvds.1"; | |
| 70 | − interrupt-parent = <&gic>; | |
| 71 | − interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>, | |
| 72 | − <0 268 IRQ_TYPE_LEVEL_HIGH>, | |
| 73 | − <0 269 IRQ_TYPE_LEVEL_HIGH>; | |
| 74 | − clocks = <&mstp7_clks R8A7790_CLK_DU0>, | |
| 75 | − <&mstp7_clks R8A7790_CLK_DU1>, | |
| 76 | − <&mstp7_clks R8A7790_CLK_DU2>, | |
| 77 | − <&mstp7_clks R8A7790_CLK_LVDS0>, | |
| 78 | − <&mstp7_clks R8A7790_CLK_LVDS1>; | |
| 79 | − clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1"; | |
| 66 | + du: display@feb00000 { | |
| 67 | + compatible = "renesas,du-r8a7795"; | |
| 68 | + reg = <0 0xfeb00000 0 0x80000>, | |
| 69 | + <0 0xfeb90000 0 0x14>; | |
| 70 | + reg-names = "du", "lvds.0"; | |
| 71 | + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, | |
| 72 | + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>, | |
| 73 | + <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>, | |
| 74 | + <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>; | |
| 75 | + clocks = <&cpg CPG_MOD 724>, | |
| 76 | + <&cpg CPG_MOD 723>, | |
| 77 | + <&cpg CPG_MOD 722>, | |
| 78 | + <&cpg CPG_MOD 721>, | |
| 79 | + <&cpg CPG_MOD 727>; | |
| 80 | + clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; | |
| 81 | + vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>; | |
| 80 | 82 | |
| 81 | 83 | ports { |
| 82 | 84 | #address-cells = <1>; |
| @@ -89,12 +91,19 @@ Example: R8A7790 (R-Car H2) DU · 6 unmodified lines | ||
| 89 | 91 | }; |
| 90 | 92 | port@1 { |
| 91 | 93 | reg = <1>; |
| 92 | − du_out_lvds0: endpoint { | |
| 94 | + du_out_hdmi0: endpoint { | |
| 95 | + remote-endpoint = <&dw_hdmi0_in>; | |
| 93 | 96 | }; |
| 94 | 97 | }; |
| 95 | 98 | port@2 { |
| 96 | 99 | reg = <2>; |
| 97 | − du_out_lvds1: endpoint { | |
| 100 | + du_out_hdmi1: endpoint { | |
| 101 | + remote-endpoint = <&dw_hdmi1_in>; | |
| 102 | + }; | |
| 103 | + }; | |
| 104 | + port@3 { | |
| 105 | + reg = <3>; | |
| 106 | + du_out_lvds0: endpoint { | |
| 98 | 107 | }; |
| 99 | 108 | }; |
| 100 | 109 | }; |
| @@ -0,0 +1,52 @@ | ||
| 1 | +Pervasive Displays RePaper branded e-ink displays | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "pervasive,e1144cs021" for 1.44" display | |
| 5 | + "pervasive,e1190cs021" for 1.9" display | |
| 6 | + "pervasive,e2200cs021" for 2.0" display | |
| 7 | + "pervasive,e2271cs021" for 2.7" display | |
| 8 | + | |
| 9 | +- panel-on-gpios: Timing controller power control | |
| 10 | +- discharge-gpios: Discharge control | |
| 11 | +- reset-gpios: RESET pin | |
| 12 | +- busy-gpios: BUSY pin | |
| 13 | + | |
| 14 | +Required property for e2271cs021: | |
| 15 | +- border-gpios: Border control | |
| 16 | + | |
| 17 | +The node for this driver must be a child node of a SPI controller, hence | |
| 18 | +all mandatory properties described in ../spi/spi-bus.txt must be specified. | |
| 19 | + | |
| 20 | +Optional property: | |
| 21 | +- pervasive,thermal-zone: name of thermometer's thermal zone | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + | |
| 25 | + display_temp: lm75@48 { | |
| 26 | + compatible = "lm75b"; | |
| 27 | + reg = <0x48>; | |
| 28 | + #thermal-sensor-cells = <0>; | |
| 29 | + }; | |
| 30 | + | |
| 31 | + thermal-zones { | |
| 32 | + display { | |
| 33 | + polling-delay-passive = <0>; | |
| 34 | + polling-delay = <0>; | |
| 35 | + thermal-sensors = <&display_temp>; | |
| 36 | + }; | |
| 37 | + }; | |
| 38 | + | |
| 39 | + papirus27@0{ | |
| 40 | + compatible = "pervasive,e2271cs021"; | |
| 41 | + reg = <0>; | |
| 42 | + | |
| 43 | + spi-max-frequency = <8000000>; | |
| 44 | + | |
| 45 | + panel-on-gpios = <&gpio 23 0>; | |
| 46 | + border-gpios = <&gpio 14 0>; | |
| 47 | + discharge-gpios = <&gpio 15 0>; | |
| 48 | + reset-gpios = <&gpio 24 0>; | |
| 49 | + busy-gpios = <&gpio 25 0>; | |
| 50 | + | |
| 51 | + pervasive,thermal-zone = "display"; | |
| 52 | + }; | |
| @@ -59,7 +59,6 @@ Example: · 58 unmodified lines | ||
| 59 | 59 | pinctrl-names = "default"; |
| 60 | 60 | pinctrl-0 = <&edp_hpd>; |
| 61 | 61 | |
| 62 | − status = "disabled"; | |
| 63 | 62 | |
| 64 | 63 | ports { |
| 65 | 64 | #address-cells = <1>; |
| @@ -11,7 +11,9 @@ following device-specific properties. · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | Required properties: |
| 13 | 13 | |
| 14 | −- compatible: Shall contain "rockchip,rk3288-dw-hdmi". | |
| 14 | +- compatible: should be one of the following: | |
| 15 | + "rockchip,rk3288-dw-hdmi" | |
| 16 | + "rockchip,rk3399-dw-hdmi" | |
| 15 | 17 | - reg: See dw_hdmi.txt. |
| 16 | 18 | - reg-io-width: See dw_hdmi.txt. Shall be 4. |
| 17 | 19 | - interrupts: HDMI interrupt number |
| @@ -30,7 +32,8 @@ Optional properties · 12 unmodified lines | ||
| 30 | 32 | I2C master controller. |
| 31 | 33 | - clock-names: See dw_hdmi.txt. The "cec" clock is optional. |
| 32 | 34 | - clock-names: May contain "cec" as defined in dw_hdmi.txt. |
| 33 | − | |
| 35 | +- clock-names: May contain "grf", power for grf io. | |
| 36 | +- clock-names: May contain "vpll", external clock for some hdmi phy. | |
| 34 | 37 | |
| 35 | 38 | Example: |
| 36 | 39 | |
| @@ -43,7 +46,6 @@ hdmi: hdmi@ff980000 { · 6 unmodified lines | ||
| 43 | 46 | interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; |
| 44 | 47 | clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>; |
| 45 | 48 | clock-names = "iahb", "isfr"; |
| 46 | − status = "disabled"; | |
| 47 | 49 | ports { |
| 48 | 50 | hdmi_in: port { |
| 49 | 51 | #address-cells = <1>; |
| @@ -36,7 +36,6 @@ Example: · 35 unmodified lines | ||
| 36 | 36 | resets = <&cru SRST_MIPIDSI0>; |
| 37 | 37 | reset-names = "apb"; |
| 38 | 38 | rockchip,grf = <&grf>; |
| 39 | − status = "okay"; | |
| 40 | 39 | |
| 41 | 40 | ports { |
| 42 | 41 | #address-cells = <1>; |
| @@ -65,6 +64,5 @@ Example: · 22 unmodified lines | ||
| 65 | 64 | pinctrl-names = "default"; |
| 66 | 65 | pinctrl-0 = <&lcd_en>; |
| 67 | 66 | backlight = <&backlight>; |
| 68 | − status = "okay"; | |
| 69 | 67 | }; |
| 70 | 68 | }; |
| @@ -25,7 +25,6 @@ hdmi: hdmi@20034000 { · 24 unmodified lines | ||
| 25 | 25 | clock-names = "pclk"; |
| 26 | 26 | pinctrl-names = "default"; |
| 27 | 27 | pinctrl-0 = <&hdmi_ctl>; |
| 28 | − status = "disabled"; | |
| 29 | 28 | |
| 30 | 29 | hdmi_in: port { |
| 31 | 30 | #address-cells = <1>; |
| @@ -8,8 +8,12 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: value should be one of the following |
| 9 | 9 | "rockchip,rk3036-vop"; |
| 10 | 10 | "rockchip,rk3288-vop"; |
| 11 | + "rockchip,rk3368-vop"; | |
| 12 | + "rockchip,rk3366-vop"; | |
| 11 | 13 | "rockchip,rk3399-vop-big"; |
| 12 | 14 | "rockchip,rk3399-vop-lit"; |
| 15 | + "rockchip,rk3228-vop"; | |
| 16 | + "rockchip,rk3328-vop"; | |
| 13 | 17 | |
| 14 | 18 | - interrupts: should contain a list of all VOP IP block interrupts in the |
| 15 | 19 | order: VSYNC, LCD_SYSTEM. The interrupt specifier |
| @@ -28,6 +28,5 @@ chosen { · 27 unmodified lines | ||
| 28 | 28 | allwinner,pipeline = "de_be0-lcd0-hdmi"; |
| 29 | 29 | clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>, |
| 30 | 30 | <&ahb_gates 44>; |
| 31 | − status = "disabled"; | |
| 32 | 31 | }; |
| 33 | 32 | }; |
| @@ -0,0 +1,22 @@ | ||
| 1 | +Sitronix ST7586 display panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "lego,ev3-lcd". | |
| 5 | +- a0-gpios: The A0 signal (since this binding is for serial mode, this is | |
| 6 | + the pin labeled D1 on the controller, not the pin labeled A0) | |
| 7 | +- reset-gpios: Reset pin | |
| 8 | + | |
| 9 | +The node for this driver must be a child node of a SPI controller, hence | |
| 10 | +all mandatory properties described in ../spi/spi-bus.txt must be specified. | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- rotation: panel rotation in degrees counter clockwise (0,90,180,270) | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + display@0{ | |
| 17 | + compatible = "lego,ev3-lcd"; | |
| 18 | + reg = <0>; | |
| 19 | + spi-max-frequency = <10000000>; | |
| 20 | + a0-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>; | |
| 21 | + reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>; | |
| 22 | + }; | |
| @@ -1,7 +1,6 @@ | ||
| 1 | 1 | * STMicroelectronics STM32 lcd-tft display controller |
| 2 | 2 | |
| 3 | 3 | - ltdc: lcd-tft display controller host |
| 4 | − must be a sub-node of st-display-subsystem | |
| 5 | 4 | Required properties: |
| 6 | 5 | - compatible: "st,stm32-ltdc" |
| 7 | 6 | - reg: Physical base address of the IP registers and length of memory mapped region. |
| @@ -13,8 +12,40 @@ · 5 unmodified lines | ||
| 13 | 12 | Required nodes: |
| 14 | 13 | - Video port for RGB output. |
| 15 | 14 | |
| 16 | −Example: | |
| 15 | +* STMicroelectronics STM32 DSI controller specific extensions to Synopsys | |
| 16 | + DesignWare MIPI DSI host controller | |
| 17 | 17 | |
| 18 | +The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI | |
| 19 | +DSI host controller. For all mandatory properties & nodes, please refer | |
| 20 | +to the related documentation in [5]. | |
| 21 | + | |
| 22 | +Mandatory properties specific to STM32 DSI: | |
| 23 | +- #address-cells: Should be <1>. | |
| 24 | +- #size-cells: Should be <0>. | |
| 25 | +- compatible: "st,stm32-dsi". | |
| 26 | +- clock-names: | |
| 27 | + - phy pll reference clock string name, must be "ref". | |
| 28 | +- resets: see [5]. | |
| 29 | +- reset-names: see [5]. | |
| 30 | + | |
| 31 | +Mandatory nodes specific to STM32 DSI: | |
| 32 | +- ports: A node containing DSI input & output port nodes with endpoint | |
| 33 | + definitions as documented in [3] & [4]. | |
| 34 | + - port@0: DSI input port node, connected to the ltdc rgb output port. | |
| 35 | + - port@1: DSI output port node, connected to a panel or a bridge input port. | |
| 36 | +- panel or bridge node: A node containing the panel or bridge description as | |
| 37 | + documented in [6]. | |
| 38 | + - port: panel or bridge port node, connected to the DSI output port (port@1). | |
| 39 | + | |
| 40 | +Note: You can find more documentation in the following references | |
| 41 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 42 | +[2] Documentation/devicetree/bindings/reset/reset.txt | |
| 43 | +[3] Documentation/devicetree/bindings/media/video-interfaces.txt | |
| 44 | +[4] Documentation/devicetree/bindings/graph.txt | |
| 45 | +[5] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt | |
| 46 | +[6] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt | |
| 47 | + | |
| 48 | +Example 1: RGB panel | |
| 18 | 49 | / { |
| 19 | 50 | ... |
| 20 | 51 | soc { |
| @@ -34,3 +65,73 @@ Example: · 13 unmodified lines | ||
| 34 | 65 | }; |
| 35 | 66 | }; |
| 36 | 67 | }; |
| 68 | + | |
| 69 | +Example 2: DSI panel | |
| 70 | + | |
| 71 | +/ { | |
| 72 | + ... | |
| 73 | + soc { | |
| 74 | + ... | |
| 75 | + ltdc: display-controller@40016800 { | |
| 76 | + compatible = "st,stm32-ltdc"; | |
| 77 | + reg = <0x40016800 0x200>; | |
| 78 | + interrupts = <88>, <89>; | |
| 79 | + resets = <&rcc STM32F4_APB2_RESET(LTDC)>; | |
| 80 | + clocks = <&rcc 1 CLK_LCD>; | |
| 81 | + clock-names = "lcd"; | |
| 82 | + | |
| 83 | + port { | |
| 84 | + ltdc_out_dsi: endpoint { | |
| 85 | + remote-endpoint = <&dsi_in>; | |
| 86 | + }; | |
| 87 | + }; | |
| 88 | + }; | |
| 89 | + | |
| 90 | + | |
| 91 | + dsi: dsi@40016c00 { | |
| 92 | + #address-cells = <1>; | |
| 93 | + #size-cells = <0>; | |
| 94 | + compatible = "st,stm32-dsi"; | |
| 95 | + reg = <0x40016c00 0x800>; | |
| 96 | + clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>; | |
| 97 | + clock-names = "ref", "pclk"; | |
| 98 | + resets = <&rcc STM32F4_APB2_RESET(DSI)>; | |
| 99 | + reset-names = "apb"; | |
| 100 | + | |
| 101 | + ports { | |
| 102 | + #address-cells = <1>; | |
| 103 | + #size-cells = <0>; | |
| 104 | + | |
| 105 | + port@0 { | |
| 106 | + reg = <0>; | |
| 107 | + dsi_in: endpoint { | |
| 108 | + remote-endpoint = <<dc_out_dsi>; | |
| 109 | + }; | |
| 110 | + }; | |
| 111 | + | |
| 112 | + port@1 { | |
| 113 | + reg = <1>; | |
| 114 | + dsi_out: endpoint { | |
| 115 | + remote-endpoint = <&dsi_in_panel>; | |
| 116 | + }; | |
| 117 | + }; | |
| 118 | + | |
| 119 | + }; | |
| 120 | + | |
| 121 | + panel-dsi@0 { | |
| 122 | + reg = <0>; /* dsi virtual channel (0..3) */ | |
| 123 | + compatible = ...; | |
| 124 | + enable-gpios = ...; | |
| 125 | + | |
| 126 | + port { | |
| 127 | + dsi_in_panel: endpoint { | |
| 128 | + remote-endpoint = <&dsi_out>; | |
| 129 | + }; | |
| 130 | + }; | |
| 131 | + | |
| 132 | + }; | |
| 133 | + | |
| 134 | + }; | |
| 135 | + | |
| 136 | + }; | |
| 137 | +}; | |
| @@ -4,15 +4,33 @@ Allwinner A10 Display Pipeline · 3 unmodified lines | ||
| 4 | 4 | The Allwinner A10 Display pipeline is composed of several components |
| 5 | 5 | that are going to be documented below: |
| 6 | 6 | |
| 7 | −For the input port of all components up to the TCON in the display | |
| 8 | −pipeline, if there are multiple components, the local endpoint IDs | |
| 9 | −must correspond to the index of the upstream block. For example, if | |
| 10 | −the remote endpoint is Frontend 1, then the local endpoint ID must | |
| 11 | −be 1. | |
| 12 | − | |
| 13 | −Conversely, for the output ports of the same group, the remote endpoint | |
| 14 | −ID must be the index of the local hardware block. If the local backend | |
| 15 | −is backend 1, then the remote endpoint ID must be 1. | |
| 7 | +For all connections between components up to the TCONs in the display | |
| 8 | +pipeline, when there are multiple components of the same type at the | |
| 9 | +same depth, the local endpoint ID must be the same as the remote | |
| 10 | +component's index. For example, if the remote endpoint is Frontend 1, | |
| 11 | +then the local endpoint ID must be 1. | |
| 12 | + | |
| 13 | + Frontend 0 [0] ------- [0] Backend 0 [0] ------- [0] TCON 0 | |
| 14 | + [1] -- -- [1] [1] -- -- [1] | |
| 15 | + \ / \ / | |
| 16 | + X X | |
| 17 | + / \ / \ | |
| 18 | + [0] -- -- [0] [0] -- -- [0] | |
| 19 | + Frontend 1 [1] ------- [1] Backend 1 [1] ------- [1] TCON 1 | |
| 20 | + | |
| 21 | +For a two pipeline system such as the one depicted above, the lines | |
| 22 | +represent the connections between the components, while the numbers | |
| 23 | +within the square brackets corresponds to the ID of the local endpoint. | |
| 24 | + | |
| 25 | +The same rule also applies to DE 2.0 mixer-TCON connections: | |
| 26 | + | |
| 27 | + Mixer 0 [0] ----------- [0] TCON 0 | |
| 28 | + [1] ---- ---- [1] | |
| 29 | + \ / | |
| 30 | + X | |
| 31 | + / \ | |
| 32 | + [0] ---- ---- [0] | |
| 33 | + Mixer 1 [1] ----------- [1] TCON 1 | |
| 16 | 34 | |
| 17 | 35 | HDMI Encoder |
| 18 | 36 | ------------ |
| @@ -260,7 +278,6 @@ hdmi: hdmi@01c16000 { · 241 unmodified lines | ||
| 260 | 278 | <&dma SUN4I_DMA_NORMAL 16>, |
| 261 | 279 | <&dma SUN4I_DMA_DEDICATED 24>; |
| 262 | 280 | dma-names = "ddc-tx", "ddc-rx", "audio-tx"; |
| 263 | − status = "disabled"; | |
| 264 | 281 | |
| 265 | 282 | ports { |
| 266 | 283 | #address-cells = <1>; |
| @@ -72,5 +72,4 @@ sai2: sai@40031000 { · 71 unmodified lines | ||
| 72 | 72 | dma-names = "tx", "rx"; |
| 73 | 73 | dmas = <&edma0 0 21>, |
| 74 | 74 | <&edma0 0 20>; |
| 75 | − status = "disabled"; | |
| 76 | 75 | }; |
| @@ -30,7 +30,6 @@ xor@d0060900 { · 29 unmodified lines | ||
| 30 | 30 | reg = <0xd0060900 0x100 |
| 31 | 31 | 0xd0060b00 0x100>; |
| 32 | 32 | clocks = <&coreclk 0>; |
| 33 | − status = "okay"; | |
| 34 | 33 | |
| 35 | 34 | xor00 { |
| 36 | 35 | interrupts = <51>; |
| @@ -48,7 +48,6 @@ Each dmas request consists of 3 cells: · 47 unmodified lines | ||
| 48 | 48 | Example: |
| 49 | 49 | |
| 50 | 50 | spi4: spi@1a280000 { |
| 51 | − status = "ok"; | |
| 52 | 51 | spi-max-frequency = <50000000>; |
| 53 | 52 | |
| 54 | 53 | pinctrl-0 = <&spi_pins>; |
| @@ -25,6 +25,7 @@ Required Properties: · 24 unmodified lines | ||
| 25 | 25 | - "renesas,dmac-r8a7794" (R-Car E2) |
| 26 | 26 | - "renesas,dmac-r8a7795" (R-Car H3) |
| 27 | 27 | - "renesas,dmac-r8a7796" (R-Car M3-W) |
| 28 | + - "renesas,dmac-r8a77970" (R-Car V3M) | |
| 28 | 29 | |
| 29 | 30 | - reg: base address and length of the registers block for the DMAC |
| 30 | 31 | |
| @@ -8,6 +8,7 @@ Required Properties: · 7 unmodified lines | ||
| 8 | 8 | - "renesas,r8a7793-usb-dmac" (R-Car M2-N) |
| 9 | 9 | - "renesas,r8a7794-usb-dmac" (R-Car E2) |
| 10 | 10 | - "renesas,r8a7795-usb-dmac" (R-Car H3) |
| 11 | + - "renesas,r8a7796-usb-dmac" (R-Car M3-W) | |
| 11 | 12 | - reg: base address and length of the registers block for the DMAC |
| 12 | 13 | - interrupts: interrupt specifiers for the DMAC, one for each entry in |
| 13 | 14 | interrupt-names. |
| @@ -63,7 +63,6 @@ Example: · 62 unmodified lines | ||
| 63 | 63 | compatible = "arm,pl011", "arm,primecell"; |
| 64 | 64 | reg = <0xe0000000 0x1000>; |
| 65 | 65 | interrupts = <0 35 0x4>; |
| 66 | − status = "disabled"; | |
| 67 | 66 | dmas = <&dmahost 12 0 1>, |
| 68 | 67 | <&dmahost 13 0 1 0>; |
| 69 | 68 | dma-names = "rx", "rx"; |
| @@ -69,7 +69,6 @@ Example: · 68 unmodified lines | ||
| 69 | 69 | |
| 70 | 70 | sti_uni_player2: sti-uni-player@2 { |
| 71 | 71 | compatible = "st,sti-uni-player"; |
| 72 | − status = "disabled"; | |
| 73 | 72 | #sound-dai-cells = <0>; |
| 74 | 73 | st,syscfg = <&syscfg_core>; |
| 75 | 74 | clocks = <&clk_s_d0_flexgen CLK_PCM_2>; |
| @@ -135,5 +135,4 @@ Example: · 134 unmodified lines | ||
| 135 | 135 | <&dma 13 0 0x0>; /* Logical - MemToDev */ |
| 136 | 136 | dma-names = "rx", "rx"; |
| 137 | 137 | |
| 138 | − status = "disabled"; | |
| 139 | 138 | }; |
| @@ -40,7 +40,6 @@ Example: · 39 unmodified lines | ||
| 40 | 40 | clock-names = "ahb", "mod"; |
| 41 | 41 | dmas = <&dma 1 29>, <&dma 1 28>; |
| 42 | 42 | dma-names = "rx", "tx"; |
| 43 | − status = "disabled"; | |
| 44 | 43 | #address-cells = <1>; |
| 45 | 44 | #size-cells = <0>; |
| 46 | 45 | }; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | "allwinner,sun8i-a23-dma" |
| 10 | 10 | "allwinner,sun8i-a83t-dma" |
| 11 | 11 | "allwinner,sun8i-h3-dma" |
| 12 | + "allwinner,sun8i-v3s-dma" | |
| 12 | 13 | - reg: Should contain the registers base address and length |
| 13 | 14 | - interrupts: Should contain a reference to the interrupt used by this device |
| 14 | 15 | - clocks: Should contain a reference to the parent AHB clock |
| @@ -62,7 +62,6 @@ uart1: serial@4806a000 { · 61 unmodified lines | ||
| 62 | 62 | interrupts-extended = <&gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; |
| 63 | 63 | ti,hwmods = "uart1"; |
| 64 | 64 | clock-frequency = <48000000>; |
| 65 | − status = "disabled"; | |
| 66 | 65 | /* Requesting crossbar input 49 and 50 */ |
| 67 | 66 | dmas = <&sdma_xbar 49>, <&sdma_xbar 50>; |
| 68 | 67 | dma-names = "tx", "rx"; |
| @@ -9,7 +9,12 @@ execute the actual DMA tansfer. · 8 unmodified lines | ||
| 9 | 9 | eDMA3 Channel Controller |
| 10 | 10 | |
| 11 | 11 | Required properties: |
| 12 | −- compatible: "ti,edma3-tpcc" for the channel controller(s) | |
| 12 | +-------------------- | |
| 13 | +- compatible: Should be: | |
| 14 | + - "ti,edma3-tpcc" for the channel controller(s) on OMAP, | |
| 15 | + AM33xx and AM43xx SoCs. | |
| 16 | + - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the | |
| 17 | + channel controller(s) on 66AK2G. | |
| 13 | 18 | - #dma-cells: Should be set to <2>. The first number is the DMA request |
| 14 | 19 | number and the second is the TC the channel is serviced on. |
| 15 | 20 | - reg: Memory map of eDMA CC |
| @@ -19,8 +24,19 @@ Required properties: · 3 unmodified lines | ||
| 19 | 24 | - ti,tptcs: List of TPTCs associated with the eDMA in the following form: |
| 20 | 25 | <&tptc_phandle TC_priority_number>. The highest priority is 0. |
| 21 | 26 | |
| 27 | +SoC-specific Required properties: | |
| 28 | +-------------------------------- | |
| 29 | +The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only: | |
| 30 | +- ti,hwmods: Name of the hwmods associated to the eDMA CC. | |
| 31 | + | |
| 32 | +The following are mandatory properties for 66AK2G SoCs only: | |
| 33 | +- power-domains:Should contain a phandle to a PM domain provider node | |
| 34 | + and an args specifier containing the device id | |
| 35 | + value. This property is as per the binding, | |
| 36 | + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt | |
| 37 | + | |
| 22 | 38 | Optional properties: |
| 23 | −- ti,hwmods: Name of the hwmods associated to the eDMA CC | |
| 39 | +------------------- | |
| 24 | 40 | - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow |
| 25 | 41 | these channels will be SW triggered channels. See example. |
| 26 | 42 | - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by |
| @@ -31,17 +47,34 @@ Optional properties: · 4 unmodified lines | ||
| 31 | 47 | eDMA3 Transfer Controller |
| 32 | 48 | |
| 33 | 49 | Required properties: |
| 34 | −- compatible: "ti,edma3-tptc" for the transfer controller(s) | |
| 50 | +-------------------- | |
| 51 | +- compatible: Should be: | |
| 52 | + - "ti,edma3-tptc" for the transfer controller(s) on OMAP, | |
| 53 | + AM33xx and AM43xx SoCs. | |
| 54 | + - "ti,k2g-edma3-tptc", "ti,edma3-tptc" for the | |
| 55 | + transfer controller(s) on 66AK2G. | |
| 35 | 56 | - reg: Memory map of eDMA TC |
| 36 | 57 | - interrupts: Interrupt number for TCerrint. |
| 37 | 58 | |
| 59 | +SoC-specific Required properties: | |
| 60 | +-------------------------------- | |
| 61 | +The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only: | |
| 62 | +- ti,hwmods: Name of the hwmods associated to the eDMA TC. | |
| 63 | + | |
| 64 | +The following are mandatory properties for 66AK2G SoCs only: | |
| 65 | +- power-domains:Should contain a phandle to a PM domain provider node | |
| 66 | + and an args specifier containing the device id | |
| 67 | + value. This property is as per the binding, | |
| 68 | + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt | |
| 69 | + | |
| 38 | 70 | Optional properties: |
| 39 | −- ti,hwmods: Name of the hwmods associated to the given eDMA TC | |
| 71 | +------------------- | |
| 40 | 72 | - interrupt-names: "edma3_tcerrint" |
| 41 | 73 | |
| 42 | 74 | ------------------------------------------------------------------------------ |
| 43 | −Example: | |
| 75 | +Examples: | |
| 44 | 76 | |
| 77 | +1. | |
| 45 | 78 | edma: edma@49000000 { |
| 46 | 79 | compatible = "ti,edma3-tpcc"; |
| 47 | 80 | ti,hwmods = "tpcc"; |
| @@ -102,13 +135,64 @@ mcasp0: mcasp@48038000 { · 54 unmodified lines | ||
| 102 | 135 | reg-names = "mpu", "dat"; |
| 103 | 136 | interrupts = <80>, <81>; |
| 104 | 137 | interrupt-names = "tx", "rx"; |
| 105 | − status = "disabled"; | |
| 106 | 138 | /* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */ |
| 107 | 139 | dmas = <&edma 8 2>, |
| 108 | 140 | <&edma 9 2>; |
| 109 | 141 | dma-names = "tx", "rx"; |
| 110 | 142 | }; |
| 111 | 143 | |
| 144 | +2. | |
| 145 | +edma1: edma@02728000 { | |
| 146 | + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; | |
| 147 | + reg = <0x02728000 0x8000>; | |
| 148 | + reg-names = "edma3_cc"; | |
| 149 | + interrupts = <GIC_SPI 208 IRQ_TYPE_EDGE_RISING>, | |
| 150 | + <GIC_SPI 219 IRQ_TYPE_EDGE_RISING>, | |
| 151 | + <GIC_SPI 220 IRQ_TYPE_EDGE_RISING>; | |
| 152 | + interrupt-names = "edma3_ccint", "emda3_mperr", | |
| 153 | + "edma3_ccerrint"; | |
| 154 | + dma-requests = <64>; | |
| 155 | + #dma-cells = <2>; | |
| 156 | + | |
| 157 | + ti,tptcs = <&edma1_tptc0 7>, <&edma1_tptc1 0>; | |
| 158 | + | |
| 159 | + /* | |
| 160 | + * memcpy is disabled, can be enabled with: | |
| 161 | + * ti,edma-memcpy-channels = <12 13 14 15>; | |
| 162 | + * for example. | |
| 163 | + */ | |
| 164 | + | |
| 165 | + power-domains = <&k2g_pds 0x4f>; | |
| 166 | +}; | |
| 167 | + | |
| 168 | +edma1_tptc0: tptc@027b0000 { | |
| 169 | + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; | |
| 170 | + reg = <0x027b0000 0x400>; | |
| 171 | + power-domains = <&k2g_pds 0x4f>; | |
| 172 | +}; | |
| 173 | + | |
| 174 | +edma1_tptc1: tptc@027b8000 { | |
| 175 | + compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc"; | |
| 176 | + reg = <0x027b8000 0x400>; | |
| 177 | + power-domains = <&k2g_pds 0x4f>; | |
| 178 | +}; | |
| 179 | + | |
| 180 | +mmc0: mmc@23000000 { | |
| 181 | + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; | |
| 182 | + reg = <0x23000000 0x400>; | |
| 183 | + interrupts = <GIC_SPI 96 IRQ_TYPE_EDGE_RISING>; | |
| 184 | + dmas = <&edma1 24 0>, <&edma1 25 0>; | |
| 185 | + dma-names = "tx", "rx"; | |
| 186 | + bus-width = <4>; | |
| 187 | + ti,needs-special-reset; | |
| 188 | + no-1-8-v; | |
| 189 | + max-frequency = <96000000>; | |
| 190 | + power-domains = <&k2g_pds 0xb>; | |
| 191 | + clocks = <&k2g_clks 0xb 1>, <&k2g_clks 0xb 2>; | |
| 192 | + clock-names = "fck", "mmchsdb_fck"; | |
| 193 | + status = "disabled"; | |
| 194 | +}; | |
| 195 | + | |
| 112 | 196 | ------------------------------------------------------------------------------ |
| 113 | 197 | DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc |
| 114 | 198 | binding. |
| @@ -16,8 +16,12 @@ Required properties: · 15 unmodified lines | ||
| 16 | 16 | |
| 17 | 17 | "renesas,r1ex24002" |
| 18 | 18 | |
| 19 | + The following manufacturers values have been deprecated: | |
| 20 | + "at", "at24" | |
| 21 | + | |
| 19 | 22 | If there is no specific driver for <manufacturer>, a generic |
| 20 | − driver based on <type> is selected. Possible types are: | |
| 23 | + device with <type> and manufacturer "atmel" should be used. | |
| 24 | + Possible types are: | |
| 21 | 25 | "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64", |
| 22 | 26 | "24c128", "24c256", "24c512", "24c1024", "spd" |
| 23 | 27 | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +ChromeOS EC USB Type-C cable and accessories detection | |
| 2 | + | |
| 3 | +On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is | |
| 4 | +able to detect the state of external accessories such as display adapters | |
| 5 | +or USB devices when said accessories are attached or detached. | |
| 6 | + | |
| 7 | +The node for this device must be under a cros-ec node like google,cros-ec-spi | |
| 8 | +or google,cros-ec-i2c. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible: Should be "google,extcon-usbc-cros-ec". | |
| 12 | +- google,usb-port-id: Specifies the USB port ID to use. | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + cros-ec@0 { | |
| 16 | + compatible = "google,cros-ec-i2c"; | |
| 17 | + | |
| 18 | + ... | |
| 19 | + | |
| 20 | + extcon { | |
| 21 | + compatible = "google,extcon-usbc-cros-ec"; | |
| 22 | + google,usb-port-id = <0>; | |
| 23 | + }; | |
| 24 | + } | |
| @@ -0,0 +1,29 @@ | ||
| 1 | +Altera Passive Serial SPI FPGA Manager | |
| 2 | + | |
| 3 | +Altera FPGAs support a method of loading the bitstream over what is | |
| 4 | +referred to as "passive serial". | |
| 5 | +The passive serial link is not technically SPI, and might require extra | |
| 6 | +circuits in order to play nicely with other SPI slaves on the same bus. | |
| 7 | + | |
| 8 | +See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | +- compatible: Must be one of the following: | |
| 12 | + "altr,fpga-passive-serial", | |
| 13 | + "altr,fpga-arria10-passive-serial" | |
| 14 | +- reg: SPI chip select of the FPGA | |
| 15 | +- nconfig-gpios: config pin (referred to as nCONFIG in the manual) | |
| 16 | +- nstat-gpios: status pin (referred to as nSTATUS in the manual) | |
| 17 | + | |
| 18 | +Optional properties: | |
| 19 | +- confd-gpios: confd pin (referred to as CONF_DONE in the manual) | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + fpga: fpga@0 { | |
| 23 | + compatible = "altr,fpga-passive-serial"; | |
| 24 | + spi-max-frequency = <20000000>; | |
| 25 | + reg = <0>; | |
| 26 | + nconfig-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>; | |
| 27 | + nstat-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>; | |
| 28 | + confd-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>; | |
| 29 | + }; | |
| @@ -0,0 +1,36 @@ | ||
| 1 | +Xilinx LogiCORE Partial Reconfig Decoupler Softcore | |
| 2 | + | |
| 3 | +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more | |
| 4 | +decouplers / fpga bridges. | |
| 5 | +The controller can decouple/disable the bridges which prevents signal | |
| 6 | +changes from passing through the bridge. The controller can also | |
| 7 | +couple / enable the bridges which allows traffic to pass through the | |
| 8 | +bridge normally. | |
| 9 | + | |
| 10 | +The Driver supports only MMIO handling. A PR region can have multiple | |
| 11 | +PR Decouplers which can be handled independently or chained via decouple/ | |
| 12 | +decouple_status signals. | |
| 13 | + | |
| 14 | +Required properties: | |
| 15 | +- compatible : Should contain "xlnx,pr-decoupler-1.00" followed by | |
| 16 | + "xlnx,pr-decoupler" | |
| 17 | +- regs : base address and size for decoupler module | |
| 18 | +- clocks : input clock to IP | |
| 19 | +- clock-names : should contain "aclk" | |
| 20 | + | |
| 21 | +Optional properties: | |
| 22 | +- bridge-enable : 0 if driver should disable bridge at startup | |
| 23 | + 1 if driver should enable bridge at startup | |
| 24 | + Default is to leave bridge in current state. | |
| 25 | + | |
| 26 | +See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic bindings. | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + fpga-bridge@100000450 { | |
| 30 | + compatible = "xlnx,pr-decoupler-1.00", | |
| 31 | + "xlnx-pr-decoupler"; | |
| 32 | + regs = <0x10000045 0x10>; | |
| 33 | + clocks = <&clkc 15>; | |
| 34 | + clock-names = "aclk"; | |
| 35 | + bridge-enable = <0>; | |
| 36 | + }; | |
| @@ -31,7 +31,6 @@ Example for full FPGA configuration: · 30 unmodified lines | ||
| 31 | 31 | cell-index = <1>; |
| 32 | 32 | interrupts = <92>; |
| 33 | 33 | clocks = <&coreclk 0>; |
| 34 | − status = "okay"; | |
| 35 | 34 | |
| 36 | 35 | fpga_mgr_spi: fpga-mgr@0 { |
| 37 | 36 | compatible = "xlnx,fpga-slave-serial"; |
| @@ -12,6 +12,9 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | 1 = active low |
| 13 | 13 | - registers-number: Number of daisy-chained shift registers |
| 14 | 14 | |
| 15 | +Optional properties: | |
| 16 | +- enable-gpios: GPIO connected to the OE (Output Enable) pin. | |
| 17 | + | |
| 15 | 18 | Example: |
| 16 | 19 | |
| 17 | 20 | gpio5: gpio5@0 { |
| @@ -18,7 +18,7 @@ Required properties: · 17 unmodified lines | ||
| 18 | 18 | Optional properties: |
| 19 | 19 | |
| 20 | 20 | - interrupt-parent : The parent interrupt controller, optional if inherited |
| 21 | −- clocks : A phandle to the HPLL clock node for debounce timings | |
| 21 | +- clocks : A phandle to the clock to use for debounce timings | |
| 22 | 22 | |
| 23 | 23 | The gpio and interrupt properties are further described in their respective |
| 24 | 24 | bindings documentation: |
| @@ -1,7 +1,10 @@ | ||
| 1 | 1 | Davinci/Keystone GPIO controller bindings |
| 2 | 2 | |
| 3 | 3 | Required Properties: |
| 4 | −- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio" | |
| 4 | +- compatible: should be "ti,dm6441-gpio": for Davinci da850 SoCs | |
| 5 | + "ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L, | |
| 6 | + 66AK2E SoCs | |
| 7 | + "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G | |
| 5 | 8 | |
| 6 | 9 | - reg: Physical base address of the controller and the size of memory mapped |
| 7 | 10 | registers. |
| @@ -20,7 +23,21 @@ Required Properties: · 12 unmodified lines | ||
| 20 | 23 | - ti,ngpio: The number of GPIO pins supported. |
| 21 | 24 | |
| 22 | 25 | - ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt |
| 23 | − line to processor. | |
| 26 | + line to processor. | |
| 27 | + | |
| 28 | +- clocks: Should contain the device's input clock, and should be defined as per | |
| 29 | + the appropriate clock bindings consumer usage in, | |
| 30 | + | |
| 31 | + Documentation/devicetree/bindings/clock/keystone-gate.txt | |
| 32 | + for 66AK2HK/66AK2L/66AK2E SoCs or, | |
| 33 | + | |
| 34 | + Documentation/devicetree/bindings/clock/ti,sci-clk.txt | |
| 35 | + for 66AK2G SoCs | |
| 36 | + | |
| 37 | +- clock-names: Name should be "gpio"; | |
| 38 | + | |
| 39 | +Currently clock-names and clocks are needed for all keystone 2 platforms | |
| 40 | +Davinci platforms do not have DT clocks as of now. | |
| 24 | 41 | |
| 25 | 42 | The GPIO controller also acts as an interrupt controller. It uses the default |
| 26 | 43 | two cells specifier as described in Documentation/devicetree/bindings/ |
| @@ -60,3 +77,73 @@ leds { · 33 unmodified lines | ||
| 60 | 77 | ... |
| 61 | 78 | }; |
| 62 | 79 | }; |
| 80 | + | |
| 81 | +Example for 66AK2G: | |
| 82 | + | |
| 83 | +gpio0: gpio@2603000 { | |
| 84 | + compatible = "ti,k2g-gpio", "ti,keystone-gpio"; | |
| 85 | + reg = <0x02603000 0x100>; | |
| 86 | + gpio-controller; | |
| 87 | + #gpio-cells = <2>; | |
| 88 | + interrupts = <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>, | |
| 89 | + <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>, | |
| 90 | + <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>, | |
| 91 | + <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>, | |
| 92 | + <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>, | |
| 93 | + <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>, | |
| 94 | + <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>, | |
| 95 | + <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>, | |
| 96 | + <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>; | |
| 97 | + interrupt-controller; | |
| 98 | + #interrupt-cells = <2>; | |
| 99 | + ti,ngpio = <144>; | |
| 100 | + ti,davinci-gpio-unbanked = <0>; | |
| 101 | + clocks = <&k2g_clks 0x001b 0x0>; | |
| 102 | + clock-names = "gpio"; | |
| 103 | +}; | |
| 104 | + | |
| 105 | +Example for 66AK2HK/66AK2L/66AK2E: | |
| 106 | + | |
| 107 | +gpio0: gpio@260bf00 { | |
| 108 | + compatible = "ti,keystone-gpio"; | |
| 109 | + reg = <0x0260bf00 0x100>; | |
| 110 | + gpio-controller; | |
| 111 | + #gpio-cells = <2>; | |
| 112 | + /* HW Interrupts mapped to GPIO pins */ | |
| 113 | + interrupts = <GIC_SPI 120 IRQ_TYPE_EDGE_RISING>, | |
| 114 | + <GIC_SPI 121 IRQ_TYPE_EDGE_RISING>, | |
| 115 | + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, | |
| 116 | + <GIC_SPI 123 IRQ_TYPE_EDGE_RISING>, | |
| 117 | + <GIC_SPI 124 IRQ_TYPE_EDGE_RISING>, | |
| 118 | + <GIC_SPI 125 IRQ_TYPE_EDGE_RISING>, | |
| 119 | + <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>, | |
| 120 | + <GIC_SPI 127 IRQ_TYPE_EDGE_RISING>, | |
| 121 | + <GIC_SPI 128 IRQ_TYPE_EDGE_RISING>, | |
| 122 | + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>, | |
| 123 | + <GIC_SPI 130 IRQ_TYPE_EDGE_RISING>, | |
| 124 | + <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>, | |
| 125 | + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>, | |
| 126 | + <GIC_SPI 133 IRQ_TYPE_EDGE_RISING>, | |
| 127 | + <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>, | |
| 128 | + <GIC_SPI 135 IRQ_TYPE_EDGE_RISING>, | |
| 129 | + <GIC_SPI 136 IRQ_TYPE_EDGE_RISING>, | |
| 130 | + <GIC_SPI 137 IRQ_TYPE_EDGE_RISING>, | |
| 131 | + <GIC_SPI 138 IRQ_TYPE_EDGE_RISING>, | |
| 132 | + <GIC_SPI 139 IRQ_TYPE_EDGE_RISING>, | |
| 133 | + <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>, | |
| 134 | + <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>, | |
| 135 | + <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>, | |
| 136 | + <GIC_SPI 143 IRQ_TYPE_EDGE_RISING>, | |
| 137 | + <GIC_SPI 144 IRQ_TYPE_EDGE_RISING>, | |
| 138 | + <GIC_SPI 145 IRQ_TYPE_EDGE_RISING>, | |
| 139 | + <GIC_SPI 146 IRQ_TYPE_EDGE_RISING>, | |
| 140 | + <GIC_SPI 147 IRQ_TYPE_EDGE_RISING>, | |
| 141 | + <GIC_SPI 148 IRQ_TYPE_EDGE_RISING>, | |
| 142 | + <GIC_SPI 149 IRQ_TYPE_EDGE_RISING>, | |
| 143 | + <GIC_SPI 150 IRQ_TYPE_EDGE_RISING>, | |
| 144 | + <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; | |
| 145 | + clocks = <&clkgpio>; | |
| 146 | + clock-names = "gpio"; | |
| 147 | + ti,ngpio = <32>; | |
| 148 | + ti,davinci-gpio-unbanked = <32>; | |
| 149 | +}; | |
| @@ -23,7 +23,6 @@ gpio0: gpio@1100 { · 22 unmodified lines | ||
| 23 | 23 | #gpio-cells = <2>; |
| 24 | 24 | reg = <0x1100 0x080>; |
| 25 | 25 | interrupts = <78 0x8>; |
| 26 | − status = "okay"; | |
| 27 | 26 | }; |
| 28 | 27 | |
| 29 | 28 | Example of gpio-controller node for a ls2080a SoC: |
| @@ -5,7 +5,9 @@ functionality. Each pair serves 32 GPIOs. The VF610 has 5 instances of · 4 unmodified lines | ||
| 5 | 5 | each, and each PORT module has its own interrupt. |
| 6 | 6 | |
| 7 | 7 | Required properties for GPIO node: |
| 8 | −- compatible : Should be "fsl,<soc>-gpio", currently "fsl,vf610-gpio" | |
| 8 | +- compatible : Should be "fsl,<soc>-gpio", below is supported list: | |
| 9 | + "fsl,vf610-gpio" | |
| 10 | + "fsl,imx7ulp-gpio" | |
| 9 | 11 | - reg : The first reg tuple represents the PORT module, the second tuple |
| 10 | 12 | the GPIO module. |
| 11 | 13 | - interrupts : Should be the port interrupt shared by all 32 pins. |
| @@ -2,8 +2,9 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required Properties: |
| 4 | 4 | |
| 5 | − - compatible: should contain one of the following. | |
| 5 | + - compatible: should contain one or more of the following: | |
| 6 | 6 | - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller. |
| 7 | + - "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO controller. | |
| 7 | 8 | - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller. |
| 8 | 9 | - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. |
| 9 | 10 | - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. |
| @@ -13,7 +14,14 @@ Required Properties: · 3 unmodified lines | ||
| 13 | 14 | - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller. |
| 14 | 15 | - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. |
| 15 | 16 | - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO controller. |
| 16 | − - "renesas,gpio-rcar": for generic R-Car GPIO controller. | |
| 17 | + - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller. | |
| 18 | + - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO controller. | |
| 19 | + - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 GPIO controller. | |
| 20 | + - "renesas,gpio-rcar": deprecated. | |
| 21 | + | |
| 22 | + When compatible with the generic version nodes must list the | |
| 23 | + SoC-specific version corresponding to the platform first followed by | |
| 24 | + the generic version. | |
| 17 | 25 | |
| 18 | 26 | - reg: Base address and length of each memory resource used by the GPIO |
| 19 | 27 | controller hardware module. |
| @@ -43,7 +51,7 @@ interrupt-controller/interrupts.txt. · 23 unmodified lines | ||
| 43 | 51 | Example: R8A7779 (R-Car H1) GPIO controller nodes |
| 44 | 52 | |
| 45 | 53 | gpio0: gpio@ffc40000 { |
| 46 | − compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar"; | |
| 54 | + compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio"; | |
| 47 | 55 | reg = <0xffc40000 0x2c>; |
| 48 | 56 | interrupt-parent = <&gic>; |
| 49 | 57 | interrupts = <0 141 0x4>; |
| @@ -55,7 +63,7 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes · 5 unmodified lines | ||
| 55 | 63 | }; |
| 56 | 64 | ... |
| 57 | 65 | gpio6: gpio@ffc46000 { |
| 58 | − compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar"; | |
| 66 | + compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio"; | |
| 59 | 67 | reg = <0xffc46000 0x2c>; |
| 60 | 68 | interrupt-parent = <&gic>; |
| 61 | 69 | interrupts = <0 147 0x4>; |
| @@ -42,7 +42,6 @@ spics: spics@e0700000{ · 41 unmodified lines | ||
| 42 | 42 | |
| 43 | 43 | |
| 44 | 44 | spi0: spi@e0100000 { |
| 45 | − status = "okay"; | |
| 46 | 45 | num-cs = <3>; |
| 47 | 46 | cs-gpios = <&gpio1 7 0>, <&spics 0>, |
| 48 | 47 | <&spics 1>; |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | * which must be preceded by one of the following vendor specifics: |
| 18 | 18 | + "amlogic,meson-gxm-mali" |
| 19 | 19 | + "rockchip,rk3288-mali" |
| 20 | + + "rockchip,rk3399-mali" | |
| 20 | 21 | |
| 21 | 22 | - reg : Physical base address of the device and length of the register area. |
| 22 | 23 | |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | * And, optionally, one of the vendor specific compatible: |
| 11 | 11 | + allwinner,sun4i-a10-mali |
| 12 | 12 | + allwinner,sun7i-a20-mali |
| 13 | + + allwinner,sun50i-h5-mali | |
| 13 | 14 | + amlogic,meson-gxbb-mali |
| 14 | 15 | + amlogic,meson-gxl-mali |
| 15 | 16 | + stericsson,db8500-mali |
| @@ -58,6 +59,10 @@ to specify one more vendor-specific compatible, among: · 42 unmodified lines | ||
| 58 | 59 | Required properties: |
| 59 | 60 | * resets: phandle to the reset line for the GPU |
| 60 | 61 | |
| 62 | + - allwinner,sun50i-h5-mali | |
| 63 | + Required properties: | |
| 64 | + * resets: phandle to the reset line for the GPU | |
| 65 | + | |
| 61 | 66 | - stericsson,db8500-mali |
| 62 | 67 | Required properties: |
| 63 | 68 | * interrupt-names and interrupts: |
| @@ -51,7 +51,6 @@ Example for GK20A: · 50 unmodified lines | ||
| 51 | 51 | resets = <&tegra_car 184>; |
| 52 | 52 | reset-names = "gpu"; |
| 53 | 53 | iommus = <&mc TEGRA_SWGROUP_GPU>; |
| 54 | − status = "disabled"; | |
| 55 | 54 | }; |
| 56 | 55 | |
| 57 | 56 | Example for GM20B: |
| @@ -70,7 +69,6 @@ Example for GM20B: · 12 unmodified lines | ||
| 70 | 69 | resets = <&tegra_car 184>; |
| 71 | 70 | reset-names = "gpu"; |
| 72 | 71 | iommus = <&mc TEGRA_SWGROUP_GPU>; |
| 73 | − status = "disabled"; | |
| 74 | 72 | }; |
| 75 | 73 | |
| 76 | 74 | Example for GP10B: |
| @@ -89,5 +87,4 @@ Example for GP10B: · 12 unmodified lines | ||
| 89 | 87 | reset-names = "gpu"; |
| 90 | 88 | power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>; |
| 91 | 89 | iommus = <&smmu TEGRA186_SID_GPU>; |
| 92 | − status = "disabled"; | |
| 93 | 90 | }; |
| @@ -24,5 +24,4 @@ Example: · 23 unmodified lines | ||
| 24 | 24 | interrupts = <0 89 0>; |
| 25 | 25 | clocks = <&clock 177>, <&clock 277>; |
| 26 | 26 | clock-names = "sclk_fimg2d", "fimg2d"; |
| 27 | − status = "disabled"; | |
| 28 | 27 | }; |
| @@ -92,6 +92,5 @@ ssi-controller@48058000 { · 91 unmodified lines | ||
| 92 | 92 | interrupts = <69>, |
| 93 | 93 | <70>; |
| 94 | 94 | |
| 95 | − status = "disabled"; /* second port is not used on N900 */ | |
| 96 | 95 | } |
| 97 | 96 | } |
| @@ -11,6 +11,8 @@ Required properties for pwm-tacho node: · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | - #size-cells : should be 1. |
| 13 | 13 | |
| 14 | +- #cooling-cells: should be 2. | |
| 15 | + | |
| 14 | 16 | - reg : address and length of the register set for the device. |
| 15 | 17 | |
| 16 | 18 | - pinctrl-names : a pinctrl state named "default" must be defined. |
| @@ -28,12 +30,17 @@ fan subnode format: · 11 unmodified lines | ||
| 28 | 30 | Under fan subnode there can upto 8 child nodes, with each child node |
| 29 | 31 | representing a fan. If there are 8 fans each fan can have one PWM port and |
| 30 | 32 | one/two Fan tach inputs. |
| 33 | +For PWM port can be configured cooling-levels to create cooling device. | |
| 34 | +Cooling device could be bound to a thermal zone for the thermal control. | |
| 31 | 35 | |
| 32 | 36 | Required properties for each child node: |
| 33 | 37 | - reg : should specify PWM source port. |
| 34 | 38 | integer value in the range 0 to 7 with 0 indicating PWM port A and |
| 35 | 39 | 7 indicating PWM port H. |
| 36 | 40 | |
| 41 | +- cooling-levels: PWM duty cycle values in a range from 0 to 255 | |
| 42 | + which correspond to thermal cooling states. | |
| 43 | + | |
| 37 | 44 | - aspeed,fan-tach-ch : should specify the Fan tach input channel. |
| 38 | 45 | integer value in the range 0 through 15, with 0 indicating |
| 39 | 46 | Fan tach channel 0 and 15 indicating Fan tach channel 15. |
| @@ -50,6 +57,7 @@ pwm_tacho_fixed_clk: fixedclk { · 10 unmodified lines | ||
| 50 | 57 | pwm_tacho: pwmtachocontroller@1e786000 { |
| 51 | 58 | #address-cells = <1>; |
| 52 | 59 | #size-cells = <1>; |
| 60 | + #cooling-cells = <2>; | |
| 53 | 61 | reg = <0x1E786000 0x1000>; |
| 54 | 62 | compatible = "aspeed,ast2500-pwm-tacho"; |
| 55 | 63 | clocks = <&pwm_tacho_fixed_clk>; |
| @@ -58,6 +66,7 @@ pwm_tacho: pwmtachocontroller@1e786000 { · 2 unmodified lines | ||
| 58 | 66 | |
| 59 | 67 | fan@0 { |
| 60 | 68 | reg = <0x00>; |
| 69 | + cooling-levels = /bits/ 8 <125 151 177 203 229 255>; | |
| 61 | 70 | aspeed,fan-tach-ch = /bits/ 8 <0x00>; |
| 62 | 71 | }; |
| 63 | 72 | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Device-tree bindings for IBM Common Form Factor Power Supply Version 1 | |
| 2 | +---------------------------------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + - compatible = "ibm,cffps1"; | |
| 6 | + - reg = < I2C bus address >; : Address of the power supply on the | |
| 7 | + I2C bus. | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + | |
| 11 | + i2c-bus@100 { | |
| 12 | + #address-cells = <1>; | |
| 13 | + #size-cells = <0>; | |
| 14 | + #interrupt-cells = <1>; | |
| 15 | + < more properties > | |
| 16 | + | |
| 17 | + power-supply@68 { | |
| 18 | + compatible = "ibm,cffps1"; | |
| 19 | + reg = <0x68>; | |
| 20 | + }; | |
| 21 | + }; | |
| @@ -0,0 +1,10 @@ | ||
| 1 | +Lantiq cpu temperatur sensor | |
| 2 | + | |
| 3 | +Requires node properties: | |
| 4 | +- compatible value : | |
| 5 | + "lantiq,cputemp" | |
| 6 | + | |
| 7 | +Example: | |
| 8 | + cputemp@0 { | |
| 9 | + compatible = "lantiq,cputemp"; | |
| 10 | + }; | |
| @@ -0,0 +1,39 @@ | ||
| 1 | +* Altera I2C Controller | |
| 2 | +* This is Altera's synthesizable logic block I2C Controller for use | |
| 3 | +* in Altera's FPGAs. | |
| 4 | + | |
| 5 | +Required properties : | |
| 6 | + - compatible : should be "altr,softip-i2c-v1.0" | |
| 7 | + - reg : Offset and length of the register set for the device | |
| 8 | + - interrupts : <IRQ> where IRQ is the interrupt number. | |
| 9 | + - clocks : phandle to input clock. | |
| 10 | + - #address-cells = <1>; | |
| 11 | + - #size-cells = <0>; | |
| 12 | + | |
| 13 | +Recommended properties : | |
| 14 | + - clock-frequency : desired I2C bus clock frequency in Hz. | |
| 15 | + | |
| 16 | +Optional properties : | |
| 17 | + - fifo-size : Size of the RX and TX FIFOs in bytes. | |
| 18 | + - Child nodes conforming to i2c bus binding | |
| 19 | + | |
| 20 | +Example : | |
| 21 | + | |
| 22 | + i2c@100080000 { | |
| 23 | + compatible = "altr,softip-i2c-v1.0"; | |
| 24 | + reg = <0x00000001 0x00080000 0x00000040>; | |
| 25 | + interrupt-parent = <&intc>; | |
| 26 | + interrupts = <0 43 4>; | |
| 27 | + clocks = <&clk_0>; | |
| 28 | + clock-frequency = <100000>; | |
| 29 | + #address-cells = <1>; | |
| 30 | + #size-cells = <0>; | |
| 31 | + fifo-size = <4>; | |
| 32 | + | |
| 33 | + eeprom@51 { | |
| 34 | + compatible = "atmel,24c32"; | |
| 35 | + reg = <0x51>; | |
| 36 | + pagesize = <32>; | |
| 37 | + }; | |
| 38 | + }; | |
| 39 | + | |
| @@ -20,8 +20,8 @@ i2c@0 { · 19 unmodified lines | ||
| 20 | 20 | #address-cells = <1>; |
| 21 | 21 | #size-cells = <0>; |
| 22 | 22 | |
| 23 | − retu-mfd: retu@1 { | |
| 24 | − compatible = "retu-mfd"; | |
| 23 | + retu: retu@1 { | |
| 24 | + compatible = "nokia,retu"; | |
| 25 | 25 | reg = <0x1>; |
| 26 | 26 | }; |
| 27 | 27 | }; |
| @@ -102,7 +102,6 @@ And for clarification, here are the snipplets for the i2c-parents: · 101 unmodified lines | ||
| 102 | 102 | #address-cells = <1>; |
| 103 | 103 | #size-cells = <0>; |
| 104 | 104 | compatible = "i2c-gpio"; |
| 105 | − status = "disabled"; | |
| 106 | 105 | gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */ |
| 107 | 106 | &gpio5 5 GPIO_ACTIVE_HIGH /* scl */ |
| 108 | 107 | >; |
| @@ -22,7 +22,6 @@ Example: · 21 unmodified lines | ||
| 22 | 22 | interrupts = <9>; |
| 23 | 23 | clocks = <&cmu clk_HFPERCLKI2C0>; |
| 24 | 24 | clock-frequency = <100000>; |
| 25 | − status = "ok"; | |
| 26 | 25 | energymicro,location = <3>; |
| 27 | 26 | |
| 28 | 27 | eeprom@50 { |
| @@ -1,14 +1,15 @@ | ||
| 1 | −* Mediatek's I2C controller | |
| 1 | +* MediaTek's I2C controller | |
| 2 | 2 | |
| 3 | −The Mediatek's I2C controller is used to interface with I2C devices. | |
| 3 | +The MediaTek's I2C controller is used to interface with I2C devices. | |
| 4 | 4 | |
| 5 | 5 | Required properties: |
| 6 | 6 | - compatible: value should be either of the following. |
| 7 | − "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701 | |
| 8 | − "mediatek,mt6577-i2c": for i2c compatible with mt6577. | |
| 9 | − "mediatek,mt6589-i2c": for i2c compatible with mt6589. | |
| 10 | − "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with mt7623. | |
| 11 | − "mediatek,mt8173-i2c": for i2c compatible with mt8173. | |
| 7 | + "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701 | |
| 8 | + "mediatek,mt6577-i2c": for MediaTek MT6577 | |
| 9 | + "mediatek,mt6589-i2c": for MediaTek MT6589 | |
| 10 | + "mediatek,mt7622-i2c": for MediaTek MT7622 | |
| 11 | + "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 | |
| 12 | + "mediatek,mt8173-i2c": for MediaTek MT8173 | |
| 12 | 13 | - reg: physical base address of the controller and dma base, length of memory |
| 13 | 14 | mapped region. |
| 14 | 15 | - interrupts: interrupt number to the cpu. |
| @@ -2,6 +2,8 @@ I2C for R-Car platforms · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: |
| 5 | + "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC. | |
| 6 | + "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC. | |
| 5 | 7 | "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. |
| 6 | 8 | "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. |
| 7 | 9 | "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. |
| @@ -12,7 +14,8 @@ Required properties: · 4 unmodified lines | ||
| 12 | 14 | "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC. |
| 13 | 15 | "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC. |
| 14 | 16 | "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device. |
| 15 | − "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device. | |
| 17 | + "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible | |
| 18 | + device. | |
| 16 | 19 | "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device. |
| 17 | 20 | "renesas,i2c-rcar" (deprecated) |
| 18 | 21 | |
| @@ -7,6 +7,7 @@ Required properties : · 6 unmodified lines | ||
| 7 | 7 | |
| 8 | 8 | - reg : Offset and length of the register set for the device |
| 9 | 9 | - compatible: should be one of the following: |
| 10 | + - "rockchip,rv1108-i2c": for rv1108 | |
| 10 | 11 | - "rockchip,rk3066-i2c": for rk3066 |
| 11 | 12 | - "rockchip,rk3188-i2c": for rk3188 |
| 12 | 13 | - "rockchip,rk3228-i2c": for rk3228 |
| @@ -4,6 +4,8 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : |
| 5 | 5 | - "renesas,iic-r8a73a4" (R-Mobile APE6) |
| 6 | 6 | - "renesas,iic-r8a7740" (R-Mobile A1) |
| 7 | + - "renesas,iic-r8a7743" (RZ/G1M) | |
| 8 | + - "renesas,iic-r8a7745" (RZ/G1E) | |
| 7 | 9 | - "renesas,iic-r8a7790" (R-Car H2) |
| 8 | 10 | - "renesas,iic-r8a7791" (R-Car M2-W) |
| 9 | 11 | - "renesas,iic-r8a7792" (R-Car V2H) |
| @@ -12,7 +14,8 @@ Required properties: · 2 unmodified lines | ||
| 12 | 14 | - "renesas,iic-r8a7795" (R-Car H3) |
| 13 | 15 | - "renesas,iic-r8a7796" (R-Car M3-W) |
| 14 | 16 | - "renesas,iic-sh73a0" (SH-Mobile AG5) |
| 15 | − - "renesas,rcar-gen2-iic" (generic R-Car Gen2 compatible device) | |
| 17 | + - "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1 | |
| 18 | + compatible device) | |
| 16 | 19 | - "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device) |
| 17 | 20 | - "renesas,rmobile-iic" (generic device) |
| 18 | 21 | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +I2C for Spreadtrum platforms | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should be "sprd,sc9860-i2c". | |
| 5 | +- reg: Specify the physical base address of the controller and length | |
| 6 | + of memory mapped region. | |
| 7 | +- interrupts: Should contain I2C interrupt. | |
| 8 | +- clock-names: Should contain following entries: | |
| 9 | + "i2c" for I2C clock, | |
| 10 | + "source" for I2C source (parent) clock, | |
| 11 | + "enable" for I2C module enable clock. | |
| 12 | +- clocks: Should contain a clock specifier for each entry in clock-names. | |
| 13 | +- clock-frequency: Constains desired I2C bus clock frequency in Hz. | |
| 14 | +- #address-cells: Should be 1 to describe address cells for I2C device address. | |
| 15 | +- #size-cells: Should be 0 means no size cell for I2C device address. | |
| 16 | + | |
| 17 | +Optional properties: | |
| 18 | +- Child nodes conforming to I2C bus binding | |
| 19 | + | |
| 20 | +Examples: | |
| 21 | +i2c0: i2c@70500000 { | |
| 22 | + compatible = "sprd,sc9860-i2c"; | |
| 23 | + reg = <0 0x70500000 0 0x1000>; | |
| 24 | + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; | |
| 25 | + clock-names = "i2c", "source", "enable"; | |
| 26 | + clocks = <&clk_i2c3>, <&ext_26m>, <&clk_ap_apb_gates 11>; | |
| 27 | + clock-frequency = <400000>; | |
| 28 | + #address-cells = <1>; | |
| 29 | + #size-cells = <0>; | |
| 30 | +}; | |
| 31 | + | |
| @@ -1,7 +1,9 @@ | ||
| 1 | 1 | * I2C controller embedded in STMicroelectronics STM32 I2C platform |
| 2 | 2 | |
| 3 | 3 | Required properties : |
| 4 | −- compatible : Must be "st,stm32f4-i2c" | |
| 4 | +- compatible : Must be one of the following | |
| 5 | + - "st,stm32f4-i2c" | |
| 6 | + - "st,stm32f7-i2c" | |
| 5 | 7 | - reg : Offset and length of the register set for the device |
| 6 | 8 | - interrupts : Must contain the interrupt id for I2C event and then the |
| 7 | 9 | interrupt id for I2C error. |
| @@ -14,8 +16,16 @@ Required properties : · 6 unmodified lines | ||
| 14 | 16 | |
| 15 | 17 | Optional properties : |
| 16 | 18 | - clock-frequency : Desired I2C bus clock frequency in Hz. If not specified, |
| 17 | − the default 100 kHz frequency will be used. As only Normal and Fast modes | |
| 18 | − are supported, possible values are 100000 and 400000. | |
| 19 | + the default 100 kHz frequency will be used. | |
| 20 | + For STM32F4 SoC Standard-mode and Fast-mode are supported, possible values are | |
| 21 | + 100000 and 400000. | |
| 22 | + For STM32F7 SoC, Standard-mode, Fast-mode and Fast-mode Plus are supported, | |
| 23 | + possible values are 100000, 400000 and 1000000. | |
| 24 | +- i2c-scl-rising-time-ns : Only for STM32F7, I2C SCL Rising time for the board | |
| 25 | + (default: 25) | |
| 26 | +- i2c-scl-falling-time-ns : Only for STM32F7, I2C SCL Falling time for the board | |
| 27 | + (default: 10) | |
| 28 | + I2C Timings are derived from these 2 values | |
| 19 | 29 | |
| 20 | 30 | Example : |
| 21 | 31 | |
| @@ -31,3 +41,16 @@ Example : · 9 unmodified lines | ||
| 31 | 41 | pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>; |
| 32 | 42 | pinctrl-names = "default"; |
| 33 | 43 | }; |
| 44 | + | |
| 45 | + i2c@40005400 { | |
| 46 | + compatible = "st,stm32f7-i2c"; | |
| 47 | + #address-cells = <1>; | |
| 48 | + #size-cells = <0>; | |
| 49 | + reg = <0x40005400 0x400>; | |
| 50 | + interrupts = <31>, | |
| 51 | + <32>; | |
| 52 | + resets = <&rcc STM32F7_APB1_RESET(I2C1)>; | |
| 53 | + clocks = <&rcc 1 CLK_I2C1>; | |
| 54 | + pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>; | |
| 55 | + pinctrl-names = "default"; | |
| 56 | + }; | |
| @@ -71,5 +71,4 @@ Example: · 70 unmodified lines | ||
| 71 | 71 | reset-names = "i2c"; |
| 72 | 72 | dmas = <&apbdma 16>, <&apbdma 16>; |
| 73 | 73 | dma-names = "rx", "tx"; |
| 74 | − status = "disabled"; | |
| 75 | 74 | }; |
| @@ -11,6 +11,11 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | - atmel,min-sample-rate-hz: Minimum sampling rate, it depends on SoC. |
| 12 | 12 | - atmel,max-sample-rate-hz: Maximum sampling rate, it depends on SoC. |
| 13 | 13 | - atmel,startup-time-ms: Startup time expressed in ms, it depends on SoC. |
| 14 | + - atmel,trigger-edge-type: One of possible edge types for the ADTRG hardware | |
| 15 | + trigger pin. When the specific edge type is detected, the conversion will | |
| 16 | + start. Possible values are rising, falling, or both. | |
| 17 | + This property uses the IRQ edge types values: IRQ_TYPE_EDGE_RISING , | |
| 18 | + IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH | |
| 14 | 19 | |
| 15 | 20 | Example: |
| 16 | 21 | |
| @@ -25,4 +30,5 @@ adc: adc@fc030000 { · 8 unmodified lines | ||
| 25 | 30 | atmel,startup-time-ms = <4>; |
| 26 | 31 | vddana-supply = <&vdd_3v3_lp_reg>; |
| 27 | 32 | vref-supply = <&vdd_3v3_lp_reg>; |
| 33 | + atmel,trigger-edge-type = <IRQ_TYPE_EDGE_BOTH>; | |
| 28 | 34 | } |
| @@ -37,5 +37,4 @@ For example: · 36 unmodified lines | ||
| 37 | 37 | clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>; |
| 38 | 38 | clock-names = "tsc_clk"; |
| 39 | 39 | interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; |
| 40 | − status = "disabled"; | |
| 41 | 40 | }; |
| @@ -17,5 +17,4 @@ adc0: adc@400e3000 { · 16 unmodified lines | ||
| 17 | 17 | clocks = <&ccu1 CLK_APB3_ADC0>; |
| 18 | 18 | vref-supply = <®_vdda>; |
| 19 | 19 | resets = <&rgu 40>; |
| 20 | − status = "disabled"; | |
| 21 | 20 | }; |
| @@ -12,6 +12,7 @@ for the Thermal Controller which holds a phandle to the AUXADC. · 11 unmodified lines | ||
| 12 | 12 | Required properties: |
| 13 | 13 | - compatible: Should be one of: |
| 14 | 14 | - "mediatek,mt2701-auxadc": For MT2701 family of SoCs |
| 15 | + - "mediatek,mt7622-auxadc": For MT7622 family of SoCs | |
| 15 | 16 | - "mediatek,mt8173-auxadc": For MT8173 family of SoCs |
| 16 | 17 | - reg: Address range of the AUXADC unit. |
| 17 | 18 | - clocks: Should contain a clock specifier for each entry in clock-names |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - "rockchip,rk3066-tsadc": for rk3036 |
| 7 | 7 | - "rockchip,rk3328-saradc", "rockchip,rk3399-saradc": for rk3328 |
| 8 | 8 | - "rockchip,rk3399-saradc": for rk3399 |
| 9 | + - "rockchip,rv1108-saradc", "rockchip,rk3399-saradc": for rv1108 | |
| 9 | 10 | |
| 10 | 11 | - reg: physical base address of the controller and length of memory mapped |
| 11 | 12 | region. |
| @@ -74,6 +74,11 @@ Optional properties: · 73 unmodified lines | ||
| 74 | 74 | * can be 6, 8, 10 or 12 on stm32f4 |
| 75 | 75 | * can be 8, 10, 12, 14 or 16 on stm32h7 |
| 76 | 76 | Default is maximum resolution if unset. |
| 77 | +- st,min-sample-time-nsecs: Minimum sampling time in nanoseconds. | |
| 78 | + Depending on hardware (board) e.g. high/low analog input source impedance, | |
| 79 | + fine tune of ADC sampling time may be recommended. | |
| 80 | + This can be either one value or an array that matches 'st,adc-channels' list, | |
| 81 | + to set sample time resp. for all channels, or independently for each channel. | |
| 77 | 82 | |
| 78 | 83 | Example: |
| 79 | 84 | adc: adc@40012000 { |
| @@ -0,0 +1,27 @@ | ||
| 1 | +STMicroelectronics STM32 Low-Power Timer quadrature encoder and counter | |
| 2 | + | |
| 3 | +STM32 Low-Power Timer provides several counter modes. It can be used as: | |
| 4 | +- quadrature encoder to detect angular position and direction of rotary | |
| 5 | + elements, from IN1 and IN2 input signals. | |
| 6 | +- simple counter from IN1 input signal. | |
| 7 | + | |
| 8 | +Must be a sub-node of an STM32 Low-Power Timer device tree node. | |
| 9 | +See ../mfd/stm32-lptimer.txt for details about the parent node. | |
| 10 | + | |
| 11 | +Required properties: | |
| 12 | +- compatible: Must be "st,stm32-lptimer-counter". | |
| 13 | +- pinctrl-names: Set to "default". | |
| 14 | +- pinctrl-0: List of phandles pointing to pin configuration nodes, | |
| 15 | + to set IN1/IN2 pins in mode of operation for Low-Power | |
| 16 | + Timer input on external pin. | |
| 17 | + | |
| 18 | +Example: | |
| 19 | + timer@40002400 { | |
| 20 | + compatible = "st,stm32-lptimer"; | |
| 21 | + ... | |
| 22 | + counter { | |
| 23 | + compatible = "st,stm32-lptimer-counter"; | |
| 24 | + pinctrl-names = "default"; | |
| 25 | + pinctrl-0 = <&lptim1_in_pins>; | |
| 26 | + }; | |
| 27 | + }; | |
| @@ -16,5 +16,4 @@ dac: dac@400e1000 { · 15 unmodified lines | ||
| 16 | 16 | clocks = <&ccu1 CLK_APB3_DAC>; |
| 17 | 17 | vref-supply = <®_vdda>; |
| 18 | 18 | resets = <&rgu 42>; |
| 19 | − status = "disabled"; | |
| 20 | 19 | }; |
| @@ -10,7 +10,9 @@ current. · 9 unmodified lines | ||
| 10 | 10 | Contents of a stm32 dac root node: |
| 11 | 11 | ----------------------------------- |
| 12 | 12 | Required properties: |
| 13 | −- compatible: Must be "st,stm32h7-dac-core". | |
| 13 | +- compatible: Should be one of: | |
| 14 | + "st,stm32f4-dac-core" | |
| 15 | + "st,stm32h7-dac-core" | |
| 14 | 16 | - reg: Offset and length of the device's register set. |
| 15 | 17 | - clocks: Must contain an entry for pclk (which feeds the peripheral bus |
| 16 | 18 | interface) |
| @@ -0,0 +1,17 @@ | ||
| 1 | +* HDC100x temperature + humidity sensors | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should contain one of the following: | |
| 5 | + ti,hdc1000 | |
| 6 | + ti,hdc1008 | |
| 7 | + ti,hdc1010 | |
| 8 | + ti,hdc1050 | |
| 9 | + ti,hdc1080 | |
| 10 | + - reg: i2c address of the sensor | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +hdc100x@40 { | |
| 15 | + compatible = "ti,hdc1000"; | |
| 16 | + reg = <0x40>; | |
| 17 | +}; | |
| @@ -5,9 +5,18 @@ Required properties: · 4 unmodified lines | ||
| 5 | 5 | - reg: i2c address of the sensor / spi cs line |
| 6 | 6 | |
| 7 | 7 | Optional properties: |
| 8 | +- drive-open-drain: the interrupt/data ready line will be configured | |
| 9 | + as open drain, which is useful if several sensors share the same | |
| 10 | + interrupt line. This is a boolean property. | |
| 11 | + If the requested interrupt is configured as IRQ_TYPE_LEVEL_HIGH or | |
| 12 | + IRQ_TYPE_EDGE_RISING a pull-down resistor is needed to drive the line | |
| 13 | + when it is not active, whereas a pull-up one is needed when interrupt | |
| 14 | + line is configured as IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_EDGE_FALLING. | |
| 15 | + Refer to pinctrl/pinctrl-bindings.txt for the property description. | |
| 8 | 16 | - interrupt-parent: should be the phandle for the interrupt controller |
| 9 | 17 | - interrupts: interrupt mapping for IRQ. It should be configured with |
| 10 | − flags IRQ_TYPE_LEVEL_HIGH or IRQ_TYPE_EDGE_RISING. | |
| 18 | + flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or | |
| 19 | + IRQ_TYPE_EDGE_FALLING. | |
| 11 | 20 | |
| 12 | 21 | Refer to interrupt-controller/interrupts.txt for generic interrupt |
| 13 | 22 | client node bindings. |
| @@ -0,0 +1,13 @@ | ||
| 1 | +*HTU21 - Measurement-Specialties htu21 temperature & humidity sensor and humidity part of MS8607 sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible: should be "meas,htu21" or "meas,ms8607-humidity" | |
| 6 | + - reg: I2C address of the sensor | |
| 7 | + | |
| 8 | +Example: | |
| 9 | + | |
| 10 | +htu21@40 { | |
| 11 | + compatible = "meas,htu21"; | |
| 12 | + reg = <0x40>; | |
| 13 | +}; | |
| @@ -11,6 +11,14 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | Optional properties: |
| 12 | 12 | - st,drdy-int-pin: the pin on the package that will be used to signal |
| 13 | 13 | "data ready" (valid values: 1 or 2). |
| 14 | +- drive-open-drain: the interrupt/data ready line will be configured | |
| 15 | + as open drain, which is useful if several sensors share the same | |
| 16 | + interrupt line. This is a boolean property. | |
| 17 | + (This binding is taken from pinctrl/pinctrl-bindings.txt) | |
| 18 | + If the requested interrupt is configured as IRQ_TYPE_LEVEL_HIGH or | |
| 19 | + IRQ_TYPE_EDGE_RISING a pull-down resistor is needed to drive the line | |
| 20 | + when it is not active, whereas a pull-up one is needed when interrupt | |
| 21 | + line is configured as IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_EDGE_FALLING. | |
| 14 | 22 | - interrupt-parent: should be the phandle for the interrupt controller |
| 15 | 23 | - interrupts: interrupt mapping for IRQ. It should be configured with |
| 16 | 24 | flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or |
| @@ -0,0 +1,17 @@ | ||
| 1 | +* MS5637 - Measurement-Specialties MS5637, MS5805, MS5837 and MS8607 pressure & temperature sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + -compatible: should be one of the following | |
| 6 | + meas,ms5637 | |
| 7 | + meas,ms5805 | |
| 8 | + meas,ms5837 | |
| 9 | + meas,ms8607-temppressure | |
| 10 | + -reg: I2C address of the sensor | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +ms5637@76 { | |
| 15 | + compatible = "meas,ms5637"; | |
| 16 | + reg = <0x76>; | |
| 17 | +}; | |
| @@ -45,6 +45,7 @@ Accelerometers: · 44 unmodified lines | ||
| 45 | 45 | - st,lis2dh12-accel |
| 46 | 46 | - st,h3lis331dl-accel |
| 47 | 47 | - st,lng2dm-accel |
| 48 | +- st,lis3l02dq | |
| 48 | 49 | |
| 49 | 50 | Gyroscopes: |
| 50 | 51 | - st,l3g4200d-gyro |
| @@ -52,6 +53,7 @@ Gyroscopes: · 1 unmodified line | ||
| 52 | 53 | - st,lsm330dl-gyro |
| 53 | 54 | - st,lsm330dlc-gyro |
| 54 | 55 | - st,l3gd20-gyro |
| 56 | +- st,l3gd20h-gyro | |
| 55 | 57 | - st,l3g4is-gyro |
| 56 | 58 | - st,lsm330-gyro |
| 57 | 59 | - st,lsm9ds0-gyro |
| @@ -62,6 +64,7 @@ Magnetometers: · 4 unmodified lines | ||
| 62 | 64 | - st,lsm303dlhc-magn |
| 63 | 65 | - st,lsm303dlm-magn |
| 64 | 66 | - st,lis3mdl-magn |
| 67 | +- st,lis2mdl | |
| 65 | 68 | |
| 66 | 69 | Pressure sensors: |
| 67 | 70 | - st,lps001wp-press |
| @@ -0,0 +1,19 @@ | ||
| 1 | +* TSYS01 - Measurement Specialties temperature sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible: should be "meas,tsys01" | |
| 6 | + - reg: I2C address of the sensor (changeable via CSB pin) | |
| 7 | + | |
| 8 | + ------------------------ | |
| 9 | + | CSB | Device Address | | |
| 10 | + ------------------------ | |
| 11 | + 1 0x76 | |
| 12 | + 0 0x77 | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | +tsys01@76 { | |
| 17 | + compatible = "meas,tsys01"; | |
| 18 | + reg = <0x76>; | |
| 19 | +}; | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +STMicroelectronics STM32 Low-Power Timer Trigger | |
| 2 | + | |
| 3 | +STM32 Low-Power Timer provides trigger source (LPTIM output) that can be used | |
| 4 | +by STM32 internal ADC and/or DAC. | |
| 5 | + | |
| 6 | +Must be a sub-node of an STM32 Low-Power Timer device tree node. | |
| 7 | +See ../mfd/stm32-lptimer.txt for details about the parent node. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Must be "st,stm32-lptimer-trigger". | |
| 11 | +- reg: Identify trigger hardware block. Must be 0, 1 or 2 | |
| 12 | + respectively for lptimer1, lptimer2 or lptimer3 | |
| 13 | + trigger output. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + timer@40002400 { | |
| 17 | + compatible = "st,stm32-lptimer"; | |
| 18 | + ... | |
| 19 | + trigger@0 { | |
| 20 | + compatible = "st,stm32-lptimer-trigger"; | |
| 21 | + reg = <0>; | |
| 22 | + }; | |
| 23 | + }; | |
| @@ -4,7 +4,9 @@ Must be a sub-node of an STM32 Timers device tree node. · 3 unmodified lines | ||
| 4 | 4 | See ../mfd/stm32-timers.txt for details about the parent node. |
| 5 | 5 | |
| 6 | 6 | Required parameters: |
| 7 | −- compatible: Must be "st,stm32-timer-trigger". | |
| 7 | +- compatible: Must be one of: | |
| 8 | + "st,stm32-timer-trigger" | |
| 9 | + "st,stm32h7-timer-trigger" | |
| 8 | 10 | - reg: Identify trigger hardware block. |
| 9 | 11 | |
| 10 | 12 | Example: |
| @@ -14,7 +16,7 @@ Example: · 3 unmodified lines | ||
| 14 | 16 | compatible = "st,stm32-timers"; |
| 15 | 17 | reg = <0x40010000 0x400>; |
| 16 | 18 | clocks = <&rcc 0 160>; |
| 17 | − clock-names = "clk_int"; | |
| 19 | + clock-names = "int"; | |
| 18 | 20 | |
| 19 | 21 | timer@0 { |
| 20 | 22 | compatible = "st,stm32-timer-trigger"; |
| @@ -22,6 +22,8 @@ Optional properties for main touchpad device: · 21 unmodified lines | ||
| 22 | 22 | experiment to determine which bit corresponds to which input. Use |
| 23 | 23 | KEY_RESERVED for unused padding values. |
| 24 | 24 | |
| 25 | +- reset-gpios: GPIO specifier for the touchscreen's reset pin (active low) | |
| 26 | + | |
| 25 | 27 | Example: |
| 26 | 28 | |
| 27 | 29 | touch@4b { |
| @@ -72,7 +72,6 @@ Example: · 71 unmodified lines | ||
| 72 | 72 | /* Required Board specific properties */ |
| 73 | 73 | keypad,num-rows = <5>; |
| 74 | 74 | keypad,num-columns = <5>; |
| 75 | − status = "okay"; | |
| 76 | 75 | |
| 77 | 76 | linux,keymap = <MATRIX_KEY(0x00, 0x02, KEY_F) /* key_forward */ |
| 78 | 77 | MATRIX_KEY(0x00, 0x03, KEY_HOME) /* key_home */ |
| @@ -0,0 +1,66 @@ | ||
| 1 | +* PWM vibrator device tree bindings | |
| 2 | + | |
| 3 | +Registers a PWM device as vibrator. It is expected, that the vibrator's | |
| 4 | +strength increases based on the duty cycle of the enable PWM channel | |
| 5 | +(100% duty cycle meaning strongest vibration, 0% meaning no vibration). | |
| 6 | + | |
| 7 | +The binding supports an optional direction PWM channel, that can be | |
| 8 | +driven at fixed duty cycle. If available this is can be used to increase | |
| 9 | +the vibration effect of some devices. | |
| 10 | + | |
| 11 | +Required properties: | |
| 12 | +- compatible: should contain "pwm-vibrator" | |
| 13 | +- pwm-names: Should contain "enable" and optionally "direction" | |
| 14 | +- pwms: Should contain a PWM handle for each entry in pwm-names | |
| 15 | + | |
| 16 | +Optional properties: | |
| 17 | +- vcc-supply: Phandle for the regulator supplying power | |
| 18 | +- direction-duty-cycle-ns: Duty cycle of the direction PWM channel in | |
| 19 | + nanoseconds, defaults to 50% of the channel's | |
| 20 | + period. | |
| 21 | + | |
| 22 | +Example from Motorola Droid 4: | |
| 23 | + | |
| 24 | +&omap4_pmx_core { | |
| 25 | + vibrator_direction_pin: pinmux_vibrator_direction_pin { | |
| 26 | + pinctrl-single,pins = < | |
| 27 | + OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE1) /* dmtimer8_pwm_evt (gpio_27) */ | |
| 28 | + >; | |
| 29 | + }; | |
| 30 | + | |
| 31 | + vibrator_enable_pin: pinmux_vibrator_enable_pin { | |
| 32 | + pinctrl-single,pins = < | |
| 33 | + OMAP4_IOPAD(0X1d0, PIN_OUTPUT | MUX_MODE1) /* dmtimer9_pwm_evt (gpio_28) */ | |
| 34 | + >; | |
| 35 | + }; | |
| 36 | +}; | |
| 37 | + | |
| 38 | +/ { | |
| 39 | + pwm8: dmtimer-pwm { | |
| 40 | + pinctrl-names = "default"; | |
| 41 | + pinctrl-0 = <&vibrator_direction_pin>; | |
| 42 | + | |
| 43 | + compatible = "ti,omap-dmtimer-pwm"; | |
| 44 | + #pwm-cells = <3>; | |
| 45 | + ti,timers = <&timer8>; | |
| 46 | + ti,clock-source = <0x01>; | |
| 47 | + }; | |
| 48 | + | |
| 49 | + pwm9: dmtimer-pwm { | |
| 50 | + pinctrl-names = "default"; | |
| 51 | + pinctrl-0 = <&vibrator_enable_pin>; | |
| 52 | + | |
| 53 | + compatible = "ti,omap-dmtimer-pwm"; | |
| 54 | + #pwm-cells = <3>; | |
| 55 | + ti,timers = <&timer9>; | |
| 56 | + ti,clock-source = <0x01>; | |
| 57 | + }; | |
| 58 | + | |
| 59 | + vibrator { | |
| 60 | + compatible = "pwm-vibrator"; | |
| 61 | + pwms = <&pwm8 0 1000000000 0>, | |
| 62 | + <&pwm9 0 1000000000 0>; | |
| 63 | + pwm-names = "enable", "direction"; | |
| 64 | + direction-duty-cycle-ns = <1000000000>; | |
| 65 | + }; | |
| 66 | +}; | |
| @@ -43,7 +43,7 @@ haptics: haptics@5a { · 42 unmodified lines | ||
| 43 | 43 | mode = <DRV260X_LRA_MODE>; |
| 44 | 44 | library-sel = <DRV260X_LIB_LRA>; |
| 45 | 45 | vib-rated-mv = <3200>; |
| 46 | − vib-overdriver-mv = <3200>; | |
| 46 | + vib-overdrive-mv = <3200>; | |
| 47 | 47 | } |
| 48 | 48 | |
| 49 | 49 | For more product information please see the link below: |
| @@ -32,5 +32,4 @@ Example: · 31 unmodified lines | ||
| 32 | 32 | pinctrl-1 = <&pinctrl_touchctrl_default>; |
| 33 | 33 | pinctrl-2 = <&pinctrl_touchctrl_gpios>; |
| 34 | 34 | vf50-ts-min-pressure = <200>; |
| 35 | − status = "disabled"; | |
| 36 | 35 | }; |
| @@ -35,5 +35,4 @@ Example: · 34 unmodified lines | ||
| 35 | 35 | measure-delay-time = <0xfff>; |
| 36 | 36 | pre-charge-time = <0xffff>; |
| 37 | 37 | touchscreen-average-samples = <32>; |
| 38 | − status = "okay"; | |
| 39 | 38 | }; |
| @@ -4,8 +4,10 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | - compatible: should be "fsl,<soc-name>-msi" to identify |
| 6 | 6 | Layerscape PCIe MSI controller block such as: |
| 7 | − "fsl,1s1021a-msi" | |
| 8 | − "fsl,1s1043a-msi" | |
| 7 | + "fsl,ls1021a-msi" | |
| 8 | + "fsl,ls1043a-msi" | |
| 9 | + "fsl,ls1046a-msi" | |
| 10 | + "fsl,ls1043a-v1.1-msi" | |
| 9 | 11 | - msi-controller: indicates that this is a PCIe MSI controller node |
| 10 | 12 | - reg: physical base address of the controller and length of memory mapped. |
| 11 | 13 | - interrupts: an interrupt to the parent interrupt controller. |
| @@ -23,7 +25,7 @@ MSI controller node · 11 unmodified lines | ||
| 23 | 25 | Examples: |
| 24 | 26 | |
| 25 | 27 | msi1: msi-controller@1571000 { |
| 26 | − compatible = "fsl,1s1043a-msi"; | |
| 28 | + compatible = "fsl,ls1043a-msi"; | |
| 27 | 29 | reg = <0x0 0x1571000 0x0 0x8>, |
| 28 | 30 | msi-controller; |
| 29 | 31 | interrupts = <0 116 0x4>; |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | "mediatek,mt6582-sysirq", "mediatek,mt6577-sysirq": for MT6582 |
| 18 | 18 | "mediatek,mt6580-sysirq", "mediatek,mt6577-sysirq": for MT6580 |
| 19 | 19 | "mediatek,mt6577-sysirq": for MT6577 |
| 20 | + "mediatek,mt2712-sysirq", "mediatek,mt6577-sysirq": for MT2712 | |
| 20 | 21 | "mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701 |
| 21 | 22 | - interrupt-controller : Identifies the node as an interrupt controller |
| 22 | 23 | - #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt. |
| @@ -0,0 +1,32 @@ | ||
| 1 | +UniPhier AIDET | |
| 2 | + | |
| 3 | +UniPhier AIDET (ARM Interrupt Detector) is an add-on block for ARM GIC (Generic | |
| 4 | +Interrupt Controller). GIC itself can handle only high level and rising edge | |
| 5 | +interrupts. The AIDET provides logic inverter to support low level and falling | |
| 6 | +edge interrupts. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: Should be one of the following: | |
| 10 | + "socionext,uniphier-ld4-aidet" - for LD4 SoC | |
| 11 | + "socionext,uniphier-pro4-aidet" - for Pro4 SoC | |
| 12 | + "socionext,uniphier-sld8-aidet" - for sLD8 SoC | |
| 13 | + "socionext,uniphier-pro5-aidet" - for Pro5 SoC | |
| 14 | + "socionext,uniphier-pxs2-aidet" - for PXs2/LD6b SoC | |
| 15 | + "socionext,uniphier-ld11-aidet" - for LD11 SoC | |
| 16 | + "socionext,uniphier-ld20-aidet" - for LD20 SoC | |
| 17 | + "socionext,uniphier-pxs3-aidet" - for PXs3 SoC | |
| 18 | +- reg: Specifies offset and length of the register set for the device. | |
| 19 | +- interrupt-controller: Identifies the node as an interrupt controller | |
| 20 | +- #interrupt-cells : Specifies the number of cells needed to encode an interrupt | |
| 21 | + source. The value should be 2. The first cell defines the interrupt number | |
| 22 | + (corresponds to the SPI interrupt number of GIC). The second cell specifies | |
| 23 | + the trigger type as defined in interrupts.txt in this directory. | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + | |
| 27 | + aidet: aidet@5fc20000 { | |
| 28 | + compatible = "socionext,uniphier-pro4-aidet"; | |
| 29 | + reg = <0x5fc20000 0x200>; | |
| 30 | + interrupt-controller; | |
| 31 | + #interrupt-cells = <2>; | |
| 32 | + }; | |
| @@ -0,0 +1,121 @@ | ||
| 1 | +* QCOM IOMMU v1 Implementation | |
| 2 | + | |
| 3 | +Qualcomm "B" family devices which are not compatible with arm-smmu have | |
| 4 | +a similar looking IOMMU but without access to the global register space, | |
| 5 | +and optionally requiring additional configuration to route context irqs | |
| 6 | +to non-secure vs secure interrupt line. | |
| 7 | + | |
| 8 | +** Required properties: | |
| 9 | + | |
| 10 | +- compatible : Should be one of: | |
| 11 | + | |
| 12 | + "qcom,msm8916-iommu" | |
| 13 | + | |
| 14 | + Followed by "qcom,msm-iommu-v1". | |
| 15 | + | |
| 16 | +- clock-names : Should be a pair of "iface" (required for IOMMUs | |
| 17 | + register group access) and "bus" (required for | |
| 18 | + the IOMMUs underlying bus access). | |
| 19 | + | |
| 20 | +- clocks : Phandles for respective clocks described by | |
| 21 | + clock-names. | |
| 22 | + | |
| 23 | +- #address-cells : must be 1. | |
| 24 | + | |
| 25 | +- #size-cells : must be 1. | |
| 26 | + | |
| 27 | +- #iommu-cells : Must be 1. Index identifies the context-bank #. | |
| 28 | + | |
| 29 | +- ranges : Base address and size of the iommu context banks. | |
| 30 | + | |
| 31 | +- qcom,iommu-secure-id : secure-id. | |
| 32 | + | |
| 33 | +- List of sub-nodes, one per translation context bank. Each sub-node | |
| 34 | + has the following required properties: | |
| 35 | + | |
| 36 | + - compatible : Should be one of: | |
| 37 | + - "qcom,msm-iommu-v1-ns" : non-secure context bank | |
| 38 | + - "qcom,msm-iommu-v1-sec" : secure context bank | |
| 39 | + - reg : Base address and size of context bank within the iommu | |
| 40 | + - interrupts : The context fault irq. | |
| 41 | + | |
| 42 | +** Optional properties: | |
| 43 | + | |
| 44 | +- reg : Base address and size of the SMMU local base, should | |
| 45 | + be only specified if the iommu requires configuration | |
| 46 | + for routing of context bank irq's to secure vs non- | |
| 47 | + secure lines. (Ie. if the iommu contains secure | |
| 48 | + context banks) | |
| 49 | + | |
| 50 | + | |
| 51 | +** Examples: | |
| 52 | + | |
| 53 | + apps_iommu: iommu@1e20000 { | |
| 54 | + #address-cells = <1>; | |
| 55 | + #size-cells = <1>; | |
| 56 | + #iommu-cells = <1>; | |
| 57 | + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; | |
| 58 | + ranges = <0 0x1e20000 0x40000>; | |
| 59 | + reg = <0x1ef0000 0x3000>; | |
| 60 | + clocks = <&gcc GCC_SMMU_CFG_CLK>, | |
| 61 | + <&gcc GCC_APSS_TCU_CLK>; | |
| 62 | + clock-names = "iface", "bus"; | |
| 63 | + qcom,iommu-secure-id = <17>; | |
| 64 | + | |
| 65 | + // mdp_0: | |
| 66 | + iommu-ctx@4000 { | |
| 67 | + compatible = "qcom,msm-iommu-v1-ns"; | |
| 68 | + reg = <0x4000 0x1000>; | |
| 69 | + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; | |
| 70 | + }; | |
| 71 | + | |
| 72 | + // venus_ns: | |
| 73 | + iommu-ctx@5000 { | |
| 74 | + compatible = "qcom,msm-iommu-v1-sec"; | |
| 75 | + reg = <0x5000 0x1000>; | |
| 76 | + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; | |
| 77 | + }; | |
| 78 | + }; | |
| 79 | + | |
| 80 | + gpu_iommu: iommu@1f08000 { | |
| 81 | + #address-cells = <1>; | |
| 82 | + #size-cells = <1>; | |
| 83 | + #iommu-cells = <1>; | |
| 84 | + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; | |
| 85 | + ranges = <0 0x1f08000 0x10000>; | |
| 86 | + clocks = <&gcc GCC_SMMU_CFG_CLK>, | |
| 87 | + <&gcc GCC_GFX_TCU_CLK>; | |
| 88 | + clock-names = "iface", "bus"; | |
| 89 | + qcom,iommu-secure-id = <18>; | |
| 90 | + | |
| 91 | + // gfx3d_user: | |
| 92 | + iommu-ctx@1000 { | |
| 93 | + compatible = "qcom,msm-iommu-v1-ns"; | |
| 94 | + reg = <0x1000 0x1000>; | |
| 95 | + interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>; | |
| 96 | + }; | |
| 97 | + | |
| 98 | + // gfx3d_priv: | |
| 99 | + iommu-ctx@2000 { | |
| 100 | + compatible = "qcom,msm-iommu-v1-ns"; | |
| 101 | + reg = <0x2000 0x1000>; | |
| 102 | + interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>; | |
| 103 | + }; | |
| 104 | + }; | |
| 105 | + | |
| 106 | + ... | |
| 107 | + | |
| 108 | + venus: video-codec@1d00000 { | |
| 109 | + ... | |
| 110 | + iommus = <&apps_iommu 5>; | |
| 111 | + }; | |
| 112 | + | |
| 113 | + mdp: mdp@1a01000 { | |
| 114 | + ... | |
| 115 | + iommus = <&apps_iommu 4>; | |
| 116 | + }; | |
| 117 | + | |
| 118 | + gpu@01c00000 { | |
| 119 | + ... | |
| 120 | + iommus = <&gpu_iommu 1>, <&gpu_iommu 2>; | |
| 121 | + }; | |
| @@ -15,6 +15,11 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | to associate with its master device. See: |
| 16 | 16 | Documentation/devicetree/bindings/iommu/iommu.txt |
| 17 | 17 | |
| 18 | +Optional properties: | |
| 19 | +- rockchip,disable-mmu-reset : Don't use the mmu reset operation. | |
| 20 | + Some mmu instances may produce unexpected results | |
| 21 | + when the reset operation is used. | |
| 22 | + | |
| 18 | 23 | Example: |
| 19 | 24 | |
| 20 | 25 | vopl_mmu: iommu@ff940300 { |
| @@ -18,6 +18,9 @@ LED sub-node properties: · 17 unmodified lines | ||
| 18 | 18 | see Documentation/devicetree/bindings/leds/common.txt |
| 19 | 19 | - retain-state-suspended: (optional) The suspend state can be retained.Such |
| 20 | 20 | as charge-led gpio. |
| 21 | +- retain-state-shutdown: (optional) Retain the state of the LED on shutdown. | |
| 22 | + Useful in BMC systems, for example when the BMC is rebooted while the host | |
| 23 | + remains up. | |
| 21 | 24 | - panic-indicator : (optional) |
| 22 | 25 | see Documentation/devicetree/bindings/leds/common.txt |
| 23 | 26 | |
| @@ -0,0 +1,88 @@ | ||
| 1 | +* NXP - pca955x LED driver | |
| 2 | + | |
| 3 | +The PCA955x family of chips are I2C LED blinkers whose pins not used | |
| 4 | +to control LEDs can be used as general purpose I/Os. The GPIO pins can | |
| 5 | +be input or output, and output pins can also be pulse-width controlled. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : should be one of : | |
| 9 | + "nxp,pca9550" | |
| 10 | + "nxp,pca9551" | |
| 11 | + "nxp,pca9552" | |
| 12 | + "nxp,pca9553" | |
| 13 | +- #address-cells: must be 1 | |
| 14 | +- #size-cells: must be 0 | |
| 15 | +- reg: I2C slave address. depends on the model. | |
| 16 | + | |
| 17 | +Optional properties: | |
| 18 | +- gpio-controller: allows pins to be used as GPIOs. | |
| 19 | +- #gpio-cells: must be 2. | |
| 20 | +- gpio-line-names: define the names of the GPIO lines | |
| 21 | + | |
| 22 | +LED sub-node properties: | |
| 23 | +- reg : number of LED line. | |
| 24 | + from 0 to 1 for the pca9550 | |
| 25 | + from 0 to 7 for the pca9551 | |
| 26 | + from 0 to 15 for the pca9552 | |
| 27 | + from 0 to 3 for the pca9553 | |
| 28 | +- type: (optional) either | |
| 29 | + PCA9532_TYPE_NONE | |
| 30 | + PCA9532_TYPE_LED | |
| 31 | + PCA9532_TYPE_GPIO | |
| 32 | + see dt-bindings/leds/leds-pca955x.h (default to LED) | |
| 33 | +- label : (optional) | |
| 34 | + see Documentation/devicetree/bindings/leds/common.txt | |
| 35 | +- linux,default-trigger : (optional) | |
| 36 | + see Documentation/devicetree/bindings/leds/common.txt | |
| 37 | + | |
| 38 | +Examples: | |
| 39 | + | |
| 40 | +pca9552: pca9552@60 { | |
| 41 | + compatible = "nxp,pca9552"; | |
| 42 | + #address-cells = <1>; | |
| 43 | + #size-cells = <0>; | |
| 44 | + reg = <0x60>; | |
| 45 | + | |
| 46 | + gpio-controller; | |
| 47 | + #gpio-cells = <2>; | |
| 48 | + gpio-line-names = "GPIO12", "GPIO13", "GPIO14", "GPIO15"; | |
| 49 | + | |
| 50 | + gpio@12 { | |
| 51 | + reg = <12>; | |
| 52 | + type = <PCA955X_TYPE_GPIO>; | |
| 53 | + }; | |
| 54 | + gpio@13 { | |
| 55 | + reg = <13>; | |
| 56 | + type = <PCA955X_TYPE_GPIO>; | |
| 57 | + }; | |
| 58 | + gpio@14 { | |
| 59 | + reg = <14>; | |
| 60 | + type = <PCA955X_TYPE_GPIO>; | |
| 61 | + }; | |
| 62 | + gpio@15 { | |
| 63 | + reg = <15>; | |
| 64 | + type = <PCA955X_TYPE_GPIO>; | |
| 65 | + }; | |
| 66 | + | |
| 67 | + led@0 { | |
| 68 | + label = "red:power"; | |
| 69 | + linux,default-trigger = "default-on"; | |
| 70 | + reg = <0>; | |
| 71 | + type = <PCA955X_TYPE_LED>; | |
| 72 | + }; | |
| 73 | + led@1 { | |
| 74 | + label = "green:power"; | |
| 75 | + reg = <1>; | |
| 76 | + type = <PCA955X_TYPE_LED>; | |
| 77 | + }; | |
| 78 | + led@2 { | |
| 79 | + label = "pca9552:yellow"; | |
| 80 | + reg = <2>; | |
| 81 | + type = <PCA955X_TYPE_LED>; | |
| 82 | + }; | |
| 83 | + led@3 { | |
| 84 | + label = "pca9552:white"; | |
| 85 | + reg = <3>; | |
| 86 | + type = <PCA955X_TYPE_LED>; | |
| 87 | + }; | |
| 88 | +}; | |
| @@ -24,7 +24,6 @@ Example: · 23 unmodified lines | ||
| 24 | 24 | clock-frequency = <50000000>; |
| 25 | 25 | clock-output-names = "qci_mclk"; |
| 26 | 26 | |
| 27 | − status = "okay"; | |
| 28 | 27 | |
| 29 | 28 | port { |
| 30 | 29 | #address-cells = <1>; |
| @@ -33,5 +33,4 @@ hdmicec: cec@100B0000 { · 32 unmodified lines | ||
| 33 | 33 | hdmi-phandle = <&hdmi>; |
| 34 | 34 | pinctrl-names = "default"; |
| 35 | 35 | pinctrl-0 = <&hdmi_cec>; |
| 36 | − status = "okay"; | |
| 37 | 36 | }; |
| @@ -166,7 +166,6 @@ Example: · 165 unmodified lines | ||
| 166 | 166 | clock-output-names = "cam_a_clkout", "cam_b_clkout"; |
| 167 | 167 | pinctrl-names = "default"; |
| 168 | 168 | pinctrl-0 = <&cam_port_a_clk_active>; |
| 169 | − status = "okay"; | |
| 170 | 169 | #address-cells = <1>; |
| 171 | 170 | #size-cells = <1>; |
| 172 | 171 | |
| @@ -189,7 +188,6 @@ Example: · 16 unmodified lines | ||
| 189 | 188 | compatible = "samsung,exynos4210-fimc"; |
| 190 | 189 | reg = <0x11800000 0x1000>; |
| 191 | 190 | interrupts = <0 85 0>; |
| 192 | − status = "okay"; | |
| 193 | 191 | }; |
| 194 | 192 | |
| 195 | 193 | csis_0: csis@11880000 { |
| @@ -52,7 +52,6 @@ Example: · 51 unmodified lines | ||
| 52 | 52 | |
| 53 | 53 | c8sectpfe@08a20000 { |
| 54 | 54 | compatible = "st,stih407-c8sectpfe"; |
| 55 | − status = "okay"; | |
| 56 | 55 | reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>; |
| 57 | 56 | reg-names = "stfe", "stfe-ram"; |
| 58 | 57 | interrupts = <GIC_SPI 34 IRQ_TYPE_NONE>, <GIC_SPI 35 IRQ_TYPE_NONE>; |
| @@ -59,7 +59,6 @@ I2C-connected TVP5147 decoder: · 58 unmodified lines | ||
| 59 | 59 | tvp5147@5d { |
| 60 | 60 | compatible = "ti,tvp5147"; |
| 61 | 61 | reg = <0x5d>; |
| 62 | − status = "okay"; | |
| 63 | 62 | |
| 64 | 63 | port { |
| 65 | 64 | composite_in: endpoint { |
| @@ -15,6 +15,9 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | the register. |
| 16 | 16 | - "smi" : It's the clock for transfer data and command. |
| 17 | 17 | |
| 18 | +Required property for mt2701: | |
| 19 | +- mediatek,larb-id :the hardware id of this larb. | |
| 20 | + | |
| 18 | 21 | Example: |
| 19 | 22 | larb1: larb@16010000 { |
| 20 | 23 | compatible = "mediatek,mt8173-smi-larb"; |
| @@ -25,3 +28,15 @@ Example: · 4 unmodified lines | ||
| 25 | 28 | <&vdecsys CLK_VDEC_LARB_CKEN>; |
| 26 | 29 | clock-names = "apb", "smi"; |
| 27 | 30 | }; |
| 31 | + | |
| 32 | +Example for mt2701: | |
| 33 | + larb0: larb@14010000 { | |
| 34 | + compatible = "mediatek,mt2701-smi-larb"; | |
| 35 | + reg = <0 0x14010000 0 0x1000>; | |
| 36 | + mediatek,smi = <&smi_common>; | |
| 37 | + mediatek,larb-id = <0>; | |
| 38 | + clocks = <&mmsys CLK_MM_SMI_LARB0>, | |
| 39 | + <&mmsys CLK_MM_SMI_LARB0>; | |
| 40 | + clock-names = "apb", "smi"; | |
| 41 | + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; | |
| 42 | + }; | |
| @@ -130,7 +130,6 @@ The reg property implicitly specifies the chip select as this: · 129 unmodified lines | ||
| 130 | 130 | Example: |
| 131 | 131 | |
| 132 | 132 | devbus-bootcs@d0010400 { |
| 133 | − status = "okay"; | |
| 134 | 133 | ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */ |
| 135 | 134 | #address-cells = <1>; |
| 136 | 135 | #size-cells = <1>; |
| @@ -12,7 +12,6 @@ Example: · 11 unmodified lines | ||
| 12 | 12 | pmic@5b { |
| 13 | 13 | compatible = "active-semi,act8945a"; |
| 14 | 14 | reg = <0x5b>; |
| 15 | − status = "okay"; | |
| 16 | 15 | |
| 17 | 16 | active-semi,vsel-high; |
| 18 | 17 | |
| @@ -79,6 +78,5 @@ Example: · 60 unmodified lines | ||
| 79 | 78 | active-semi,input-voltage-threshold-microvolt = <6600>; |
| 80 | 79 | active-semi,precondition-timeout = <40>; |
| 81 | 80 | active-semi,total-timeout = <3>; |
| 82 | − status = "okay"; | |
| 83 | 81 | }; |
| 84 | 82 | }; |
| @@ -25,7 +25,6 @@ Example: · 24 unmodified lines | ||
| 25 | 25 | clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; |
| 26 | 26 | clock-names = "periph_clk","sys_clk", "slow_clk"; |
| 27 | 27 | interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; |
| 28 | − status = "disabled"; | |
| 29 | 28 | |
| 30 | 29 | hlcdc-display-controller { |
| 31 | 30 | compatible = "atmel,hlcdc-display-controller"; |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: Should be one of the following |
| 9 | 9 | "atmel,at91sam9260-smc", "syscon" |
| 10 | 10 | "atmel,sama5d3-smc", "syscon" |
| 11 | + "atmel,sama5d2-smc", "syscon" | |
| 11 | 12 | - reg: Contains offset/length value of the SMC memory |
| 12 | 13 | region. |
| 13 | 14 | |
| @@ -7,7 +7,14 @@ axp209 (X-Powers) · 6 unmodified lines | ||
| 7 | 7 | axp221 (X-Powers) |
| 8 | 8 | axp223 (X-Powers) |
| 9 | 9 | axp803 (X-Powers) |
| 10 | +axp806 (X-Powers) | |
| 10 | 11 | axp809 (X-Powers) |
| 12 | +axp813 (X-Powers) | |
| 13 | + | |
| 14 | +The AXP813 is 2 chips packaged into 1. The 2 chips do not share anything | |
| 15 | +other than the packaging. Pins are routed separately. As such they should | |
| 16 | +be treated as separate entities. The other half is an AC100 RTC/codec | |
| 17 | +combo chip. Please see ./ac100.txt for its bindings. | |
| 11 | 18 | |
| 12 | 19 | Required properties: |
| 13 | 20 | - compatible: should be one of: |
| @@ -19,6 +26,7 @@ Required properties: · 5 unmodified lines | ||
| 19 | 26 | * "x-powers,axp803" |
| 20 | 27 | * "x-powers,axp806" |
| 21 | 28 | * "x-powers,axp809" |
| 29 | + * "x-powers,axp813" | |
| 22 | 30 | - reg: The I2C slave address or RSB hardware address for the AXP chip |
| 23 | 31 | - interrupt-parent: The parent interrupt controller |
| 24 | 32 | - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin |
| @@ -28,12 +36,14 @@ Required properties: · 3 unmodified lines | ||
| 28 | 36 | Optional properties: |
| 29 | 37 | - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz |
| 30 | 38 | AXP152/20X: range: 750-1875, Default: 1.5 MHz |
| 31 | − AXP22X/80X: range: 1800-4050, Default: 3 MHz | |
| 39 | + AXP22X/8XX: range: 1800-4050, Default: 3 MHz | |
| 32 | 40 | |
| 33 | −- x-powers,drive-vbus-en: axp221 / axp223 only boolean, set this when the | |
| 34 | − N_VBUSEN pin is used as an output pin to control an external | |
| 35 | − regulator to drive the OTG VBus, rather then as an input pin | |
| 36 | − which signals whether the board is driving OTG VBus or not. | |
| 41 | +- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is | |
| 42 | + used as an output pin to control an external | |
| 43 | + regulator to drive the OTG VBus, rather then | |
| 44 | + as an input pin which signals whether the | |
| 45 | + board is driving OTG VBus or not. | |
| 46 | + (axp221 / axp223 / axp813 only) | |
| 37 | 47 | |
| 38 | 48 | - x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is |
| 39 | 49 | wired for master mode. The default is slave mode. |
| @@ -171,6 +181,36 @@ LDO_IO1 : LDO : ips-supply : GPIO 1 · 131 unmodified lines | ||
| 171 | 181 | RTC_LDO : LDO : ips-supply : always on |
| 172 | 182 | SW : On/Off Switch : swin-supply |
| 173 | 183 | |
| 184 | +AXP813 regulators, type, and corresponding input supply names: | |
| 185 | + | |
| 186 | +Regulator Type Supply Name Notes | |
| 187 | +--------- ---- ----------- ----- | |
| 188 | +DCDC1 : DC-DC buck : vin1-supply | |
| 189 | +DCDC2 : DC-DC buck : vin2-supply : poly-phase capable | |
| 190 | +DCDC3 : DC-DC buck : vin3-supply : poly-phase capable | |
| 191 | +DCDC4 : DC-DC buck : vin4-supply | |
| 192 | +DCDC5 : DC-DC buck : vin5-supply : poly-phase capable | |
| 193 | +DCDC6 : DC-DC buck : vin6-supply : poly-phase capable | |
| 194 | +DCDC7 : DC-DC buck : vin7-supply | |
| 195 | +ALDO1 : LDO : aldoin-supply : shared supply | |
| 196 | +ALDO2 : LDO : aldoin-supply : shared supply | |
| 197 | +ALDO3 : LDO : aldoin-supply : shared supply | |
| 198 | +DLDO1 : LDO : dldoin-supply : shared supply | |
| 199 | +DLDO2 : LDO : dldoin-supply : shared supply | |
| 200 | +DLDO3 : LDO : dldoin-supply : shared supply | |
| 201 | +DLDO4 : LDO : dldoin-supply : shared supply | |
| 202 | +ELDO1 : LDO : eldoin-supply : shared supply | |
| 203 | +ELDO2 : LDO : eldoin-supply : shared supply | |
| 204 | +ELDO3 : LDO : eldoin-supply : shared supply | |
| 205 | +FLDO1 : LDO : fldoin-supply : shared supply | |
| 206 | +FLDO2 : LDO : fldoin-supply : shared supply | |
| 207 | +FLDO3 : LDO : fldoin-supply : shared supply | |
| 208 | +LDO_IO0 : LDO : ips-supply : GPIO 0 | |
| 209 | +LDO_IO1 : LDO : ips-supply : GPIO 1 | |
| 210 | +RTC_LDO : LDO : ips-supply : always on | |
| 211 | +SW : On/Off Switch : swin-supply | |
| 212 | +DRIVEVBUS : Enable output : drivevbus-supply : external regulator | |
| 213 | + | |
| 174 | 214 | Example: |
| 175 | 215 | |
| 176 | 216 | axp209: pmic@34 { |
| @@ -0,0 +1,49 @@ | ||
| 1 | +* ROHM BD9571MWV Power Management Integrated Circuit (PMIC) bindings | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : Should be "rohm,bd9571mwv". | |
| 5 | + - reg : I2C slave address. | |
| 6 | + - interrupt-parent : Phandle to the parent interrupt controller. | |
| 7 | + - interrupts : The interrupt line the device is connected to. | |
| 8 | + - interrupt-controller : Marks the device node as an interrupt controller. | |
| 9 | + - #interrupt-cells : The number of cells to describe an IRQ, should be 2. | |
| 10 | + The first cell is the IRQ number. | |
| 11 | + The second cell is the flags, encoded as trigger | |
| 12 | + masks from ../interrupt-controller/interrupts.txt. | |
| 13 | + - gpio-controller : Marks the device node as a GPIO Controller. | |
| 14 | + - #gpio-cells : Should be two. The first cell is the pin number and | |
| 15 | + the second cell is used to specify flags. | |
| 16 | + See ../gpio/gpio.txt for more information. | |
| 17 | + - regulators: : List of child nodes that specify the regulator | |
| 18 | + initialization data. Child nodes must be named | |
| 19 | + after their hardware counterparts: | |
| 20 | + - vd09 | |
| 21 | + - vd18 | |
| 22 | + - vd25 | |
| 23 | + - vd33 | |
| 24 | + - dvfs | |
| 25 | + Each child node is defined using the standard | |
| 26 | + binding for regulators. | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + | |
| 30 | + pmic: pmic@30 { | |
| 31 | + compatible = "rohm,bd9571mwv"; | |
| 32 | + reg = <0x30>; | |
| 33 | + interrupt-parent = <&gpio2>; | |
| 34 | + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; | |
| 35 | + interrupt-controller; | |
| 36 | + #interrupt-cells = <2>; | |
| 37 | + gpio-controller; | |
| 38 | + #gpio-cells = <2>; | |
| 39 | + | |
| 40 | + regulators { | |
| 41 | + dvfs: dvfs { | |
| 42 | + regulator-name = "dvfs"; | |
| 43 | + regulator-min-microvolt = <750000>; | |
| 44 | + regulator-max-microvolt = <1030000>; | |
| 45 | + regulator-boot-on; | |
| 46 | + regulator-always-on; | |
| 47 | + }; | |
| 48 | + }; | |
| 49 | + }; | |
| @@ -4,6 +4,14 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : Should be "dlg,da9052", "dlg,da9053-aa", |
| 5 | 5 | "dlg,da9053-ab", or "dlg,da9053-bb" |
| 6 | 6 | |
| 7 | +Optional properties: | |
| 8 | +- dlg,tsi-as-adc : Boolean, if set the X+, X-, Y+, Y- touchscreen | |
| 9 | + input lines are used as general purpose analogue | |
| 10 | + input. | |
| 11 | +- tsiref-supply: Phandle to the regulator, which provides the reference | |
| 12 | + voltage for the TSIREF pin. Must be provided when the | |
| 13 | + touchscreen pins are used for ADC purposes. | |
| 14 | + | |
| 7 | 15 | Sub-nodes: |
| 8 | 16 | - regulators : Contain the regulator nodes. The DA9052/53 regulators are |
| 9 | 17 | bound using their names as listed below: |
| @@ -29,7 +37,6 @@ Sub-nodes: · 19 unmodified lines | ||
| 29 | 37 | Examples: |
| 30 | 38 | |
| 31 | 39 | i2c@63fc8000 { /* I2C1 */ |
| 32 | − status = "okay"; | |
| 33 | 40 | |
| 34 | 41 | pmic: dialog@48 { |
| 35 | 42 | compatible = "dlg,da9053-aa"; |
| @@ -116,7 +116,6 @@ ecspi@70010000 { /* ECSPI1 */ · 115 unmodified lines | ||
| 116 | 116 | fsl,spi-num-chipselects = <2>; |
| 117 | 117 | cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */ |
| 118 | 118 | <&gpio4 25 0>; /* GPIO4_25 */ |
| 119 | − status = "okay"; | |
| 120 | 119 | |
| 121 | 120 | pmic: mc13892@0 { |
| 122 | 121 | #address-cells = <1>; |
| @@ -26,7 +26,6 @@ Example for i.MX23 SoC: · 25 unmodified lines | ||
| 26 | 26 | compatible = "fsl,imx23-lradc"; |
| 27 | 27 | reg = <0x80050000 0x2000>; |
| 28 | 28 | interrupts = <36 37 38 39 40 41 42 43 44>; |
| 29 | − status = "okay"; | |
| 30 | 29 | fsl,lradc-touchscreen-wires = <4>; |
| 31 | 30 | fsl,ave-ctrl = <4>; |
| 32 | 31 | fsl,ave-delay = <2>; |
| @@ -39,7 +38,6 @@ Example for i.MX28 SoC: · 6 unmodified lines | ||
| 39 | 38 | compatible = "fsl,imx28-lradc"; |
| 40 | 39 | reg = <0x80050000 0x2000>; |
| 41 | 40 | interrupts = <10 14 15 16 17 18 19 20 21 22 23 24 25>; |
| 42 | − status = "okay"; | |
| 43 | 41 | fsl,lradc-touchscreen-wires = <5>; |
| 44 | 42 | fsl,ave-ctrl = <4>; |
| 45 | 43 | fsl,ave-delay = <2>; |
| @@ -0,0 +1,25 @@ | ||
| 1 | +* Device tree bindings for Nokia Retu and Tahvo multi-function device | |
| 2 | + | |
| 3 | +Retu and Tahvo are a multi-function devices found on Nokia Internet | |
| 4 | +Tablets (770, N800 and N810). The Retu chip provides watchdog timer | |
| 5 | +and power button control functionalities while Tahvo chip provides | |
| 6 | +USB transceiver functionality. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: "nokia,retu" or "nokia,tahvo" | |
| 10 | +- reg: Specifies the CBUS slave address of the ASIC chip | |
| 11 | +- interrupts: The interrupt line the device is connected to | |
| 12 | +- interrupt-parent: The parent interrupt controller | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | +cbus0 { | |
| 17 | + compatible = "i2c-cbus-gpio"; | |
| 18 | + ... | |
| 19 | + retu: retu@1 { | |
| 20 | + compatible = "nokia,retu"; | |
| 21 | + interrupt-parent = <&gpio4>; | |
| 22 | + interrupts = <12 IRQ_TYPE_EDGE_RISING>; | |
| 23 | + reg = <0x1>; | |
| 24 | + }; | |
| 25 | +}; | |
| @@ -1,11 +1,14 @@ | ||
| 1 | 1 | RK8XX Power Management Integrated Circuit |
| 2 | 2 | |
| 3 | 3 | The rk8xx family current members: |
| 4 | +rk805 | |
| 4 | 5 | rk808 |
| 5 | 6 | rk818 |
| 6 | 7 | |
| 7 | 8 | Required properties: |
| 8 | −- compatible: "rockchip,rk808", "rockchip,rk818" | |
| 9 | +- compatible: "rockchip,rk805" | |
| 10 | +- compatible: "rockchip,rk808" | |
| 11 | +- compatible: "rockchip,rk818" | |
| 9 | 12 | - reg: I2C slave address |
| 10 | 13 | - interrupt-parent: The parent interrupt controller. |
| 11 | 14 | - interrupts: the interrupt outputs of the controller. |
| @@ -18,6 +21,14 @@ Optional properties: · 6 unmodified lines | ||
| 18 | 21 | - rockchip,system-power-controller: Telling whether or not this pmic is controlling |
| 19 | 22 | the system power. |
| 20 | 23 | |
| 24 | +Optional RK805 properties: | |
| 25 | +- vcc1-supply: The input supply for DCDC_REG1 | |
| 26 | +- vcc2-supply: The input supply for DCDC_REG2 | |
| 27 | +- vcc3-supply: The input supply for DCDC_REG3 | |
| 28 | +- vcc4-supply: The input supply for DCDC_REG4 | |
| 29 | +- vcc5-supply: The input supply for LDO_REG1 and LDO_REG2 | |
| 30 | +- vcc6-supply: The input supply for LDO_REG3 | |
| 31 | + | |
| 21 | 32 | Optional RK808 properties: |
| 22 | 33 | - vcc1-supply: The input supply for DCDC_REG1 |
| 23 | 34 | - vcc2-supply: The input supply for DCDC_REG2 |
| @@ -56,6 +67,15 @@ by a child node of the 'regulators' node. · 32 unmodified lines | ||
| 56 | 67 | /* standard regulator bindings here */ |
| 57 | 68 | }; |
| 58 | 69 | |
| 70 | +Following regulators of the RK805 PMIC regulators are supported. Note that | |
| 71 | +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO | |
| 72 | +number as described in RK805 datasheet. | |
| 73 | + | |
| 74 | + - DCDC_REGn | |
| 75 | + - valid values for n are 1 to 4. | |
| 76 | + - LDO_REGn | |
| 77 | + - valid values for n are 1 to 3 | |
| 78 | + | |
| 59 | 79 | Following regulators of the RK808 PMIC block are supported. Note that |
| 60 | 80 | the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO |
| 61 | 81 | number as described in RK808 datasheet. |
| @@ -57,7 +57,6 @@ audio-subsystem { · 56 unmodified lines | ||
| 57 | 57 | clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; |
| 58 | 58 | pinctrl-names = "default"; |
| 59 | 59 | pinctrl-0 = <&i2s0_bus>; |
| 60 | − status = "disabled"; | |
| 61 | 60 | }; |
| 62 | 61 | |
| 63 | 62 | serial_3: serial@11460000 { |
| @@ -69,6 +68,5 @@ audio-subsystem { · 5 unmodified lines | ||
| 69 | 68 | clock-names = "uart", "clk_uart_baud0"; |
| 70 | 69 | pinctrl-names = "default"; |
| 71 | 70 | pinctrl-0 = <&uart_aud_bus>; |
| 72 | − status = "disabled"; | |
| 73 | 71 | }; |
| 74 | 72 | }; |
| @@ -0,0 +1,48 @@ | ||
| 1 | +STMicroelectronics STM32 Low-Power Timer | |
| 2 | + | |
| 3 | +The STM32 Low-Power Timer (LPTIM) is a 16-bit timer that provides several | |
| 4 | +functions: | |
| 5 | +- PWM output (with programmable prescaler, configurable polarity) | |
| 6 | +- Quadrature encoder, counter | |
| 7 | +- Trigger source for STM32 ADC/DAC (LPTIM_OUT) | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Must be "st,stm32-lptimer". | |
| 11 | +- reg: Offset and length of the device's register set. | |
| 12 | +- clocks: Phandle to the clock used by the LP Timer module. | |
| 13 | +- clock-names: Must be "mux". | |
| 14 | +- #address-cells: Should be '<1>'. | |
| 15 | +- #size-cells: Should be '<0>'. | |
| 16 | + | |
| 17 | +Optional subnodes: | |
| 18 | +- pwm: See ../pwm/pwm-stm32-lp.txt | |
| 19 | +- counter: See ../iio/timer/stm32-lptimer-cnt.txt | |
| 20 | +- trigger: See ../iio/timer/stm32-lptimer-trigger.txt | |
| 21 | + | |
| 22 | +Example: | |
| 23 | + | |
| 24 | + timer@40002400 { | |
| 25 | + compatible = "st,stm32-lptimer"; | |
| 26 | + reg = <0x40002400 0x400>; | |
| 27 | + clocks = <&timer_clk>; | |
| 28 | + clock-names = "mux"; | |
| 29 | + #address-cells = <1>; | |
| 30 | + #size-cells = <0>; | |
| 31 | + | |
| 32 | + pwm { | |
| 33 | + compatible = "st,stm32-pwm-lp"; | |
| 34 | + pinctrl-names = "default"; | |
| 35 | + pinctrl-0 = <&lppwm1_pins>; | |
| 36 | + }; | |
| 37 | + | |
| 38 | + trigger@0 { | |
| 39 | + compatible = "st,stm32-lptimer-trigger"; | |
| 40 | + reg = <0>; | |
| 41 | + }; | |
| 42 | + | |
| 43 | + counter { | |
| 44 | + compatible = "st,stm32-lptimer-counter"; | |
| 45 | + pinctrl-names = "default"; | |
| 46 | + pinctrl-0 = <&lptim1_in_pins>; | |
| 47 | + }; | |
| 48 | + }; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +* Device tree bindings for TI TPS61050/61052 Boost Converters | |
| 2 | + | |
| 3 | +The TP61050/TPS61052 is a high-power "white LED driver". The | |
| 4 | +device provides LED, GPIO and regulator functionalities. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: "ti,tps61050" or "ti,tps61052" | |
| 8 | +- reg: Specifies the I2C slave address | |
| 9 | + | |
| 10 | +Example: | |
| 11 | + | |
| 12 | +i2c0 { | |
| 13 | + tps61052@33 { | |
| 14 | + compatible = "ti,tps61052"; | |
| 15 | + reg = <0x33>; | |
| 16 | + }; | |
| 17 | +}; | |
| @@ -31,6 +31,7 @@ Required properties: · 30 unmodified lines | ||
| 31 | 31 | ../interrupt-controller/interrupts.txt |
| 32 | 32 | |
| 33 | 33 | Optional sub-nodes: |
| 34 | + - phys : Contains a phandle to the USB PHY. | |
| 34 | 35 | - regulators : Contains sub-nodes for each of the regulators supplied by |
| 35 | 36 | the device. The regulators are bound using their names listed below: |
| 36 | 37 | |
| @@ -0,0 +1,39 @@ | ||
| 1 | +Zodiac Inflight Innovations RAVE Supervisory Processor | |
| 2 | + | |
| 3 | +RAVE Supervisory Processor communicates with SoC over UART. It is | |
| 4 | +expected that its Device Tree node is specified as a child of a node | |
| 5 | +corresponding to UART controller used for communication. | |
| 6 | + | |
| 7 | +Required parent device properties: | |
| 8 | + | |
| 9 | + - compatible: Should be one of: | |
| 10 | + - "zii,rave-sp-niu" | |
| 11 | + - "zii,rave-sp-mezz" | |
| 12 | + - "zii,rave-sp-esb" | |
| 13 | + - "zii,rave-sp-rdu1" | |
| 14 | + - "zii,rave-sp-rdu2" | |
| 15 | + | |
| 16 | + - current-speed: Should be set to baud rate SP device is using | |
| 17 | + | |
| 18 | +RAVE SP consists of the following sub-devices: | |
| 19 | + | |
| 20 | +Device Description | |
| 21 | +------ ----------- | |
| 22 | +rave-sp-wdt : Watchdog | |
| 23 | +rave-sp-nvmem : Interface to onborad EEPROM | |
| 24 | +rave-sp-backlight : Display backlight | |
| 25 | +rave-sp-hwmon : Interface to onboard hardware sensors | |
| 26 | +rave-sp-leds : Interface to onboard LEDs | |
| 27 | +rave-sp-input : Interface to onboard power button | |
| 28 | + | |
| 29 | +Example of usage: | |
| 30 | + | |
| 31 | + rdu { | |
| 32 | + compatible = "zii,rave-sp-rdu2"; | |
| 33 | + current-speed = <1000000>; | |
| 34 | + | |
| 35 | + watchdog { | |
| 36 | + compatible = "zii,rave-sp-watchdog"; | |
| 37 | + }; | |
| 38 | + }; | |
| 39 | + | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +Lantiq XWAY SoC FPI BUS binding | |
| 2 | +============================ | |
| 3 | + | |
| 4 | + | |
| 5 | +------------------------------------------------------------------------------- | |
| 6 | +Required properties: | |
| 7 | +- compatible : Should be one of | |
| 8 | + "lantiq,xrx200-fpi" | |
| 9 | +- reg : The address and length of the XBAR | |
| 10 | + configuration register. | |
| 11 | + Address and length of the FPI bus itself. | |
| 12 | +- lantiq,rcu : A phandle to the RCU syscon | |
| 13 | +- lantiq,offset-endianness : Offset of the endianness configuration | |
| 14 | + register | |
| 15 | + | |
| 16 | +------------------------------------------------------------------------------- | |
| 17 | +Example for the FPI on the xrx200 SoCs: | |
| 18 | + fpi@10000000 { | |
| 19 | + compatible = "lantiq,xrx200-fpi"; | |
| 20 | + ranges = <0x0 0x10000000 0xf000000>; | |
| 21 | + reg = <0x1f400000 0x1000>, | |
| 22 | + <0x10000000 0xf000000>; | |
| 23 | + lantiq,rcu = <&rcu0>; | |
| 24 | + lantiq,offset-endianness = <0x4c>; | |
| 25 | + #address-cells = <1>; | |
| 26 | + #size-cells = <1>; | |
| 27 | + | |
| 28 | + gptu@e100a00 { | |
| 29 | + ...... | |
| 30 | + }; | |
| 31 | + }; | |
| @@ -0,0 +1,36 @@ | ||
| 1 | +Lantiq XWAY SoC GPHY binding | |
| 2 | +============================ | |
| 3 | + | |
| 4 | +This binding describes a software-defined ethernet PHY, provided by the RCU | |
| 5 | +module on newer Lantiq XWAY SoCs (xRX200 and newer). | |
| 6 | + | |
| 7 | +------------------------------------------------------------------------------- | |
| 8 | +Required properties: | |
| 9 | +- compatible : Should be one of | |
| 10 | + "lantiq,xrx200a1x-gphy" | |
| 11 | + "lantiq,xrx200a2x-gphy" | |
| 12 | + "lantiq,xrx300-gphy" | |
| 13 | + "lantiq,xrx330-gphy" | |
| 14 | +- reg : Addrress of the GPHY FW load address register | |
| 15 | +- resets : Must reference the RCU GPHY reset bit | |
| 16 | +- reset-names : One entry, value must be "gphy" or optional "gphy2" | |
| 17 | +- clocks : A reference to the (PMU) GPHY clock gate | |
| 18 | + | |
| 19 | +Optional properties: | |
| 20 | +- lantiq,gphy-mode : GPHY_MODE_GE (default) or GPHY_MODE_FE as defined in | |
| 21 | + <dt-bindings/mips/lantiq_xway_gphy.h> | |
| 22 | + | |
| 23 | + | |
| 24 | +------------------------------------------------------------------------------- | |
| 25 | +Example for the GPHys on the xRX200 SoCs: | |
| 26 | + | |
| 27 | +#include <dt-bindings/mips/lantiq_rcu_gphy.h> | |
| 28 | + gphy0: gphy@20 { | |
| 29 | + compatible = "lantiq,xrx200a2x-gphy"; | |
| 30 | + reg = <0x20 0x4>; | |
| 31 | + | |
| 32 | + resets = <&reset0 31 30>, <&reset1 7 7>; | |
| 33 | + reset-names = "gphy", "gphy2"; | |
| 34 | + clocks = <&pmu0 XRX200_PMU_GATE_GPHY>; | |
| 35 | + lantiq,gphy-mode = <GPHY_MODE_GE>; | |
| 36 | + }; | |
| @@ -0,0 +1,89 @@ | ||
| 1 | +Lantiq XWAY SoC RCU binding | |
| 2 | +=========================== | |
| 3 | + | |
| 4 | +This binding describes the RCU (reset controller unit) multifunction device, | |
| 5 | +where each sub-device has it's own set of registers. | |
| 6 | + | |
| 7 | +The RCU register range is used for multiple purposes. Mostly one device | |
| 8 | +uses one or multiple register exclusively, but for some registers some | |
| 9 | +bits are for one driver and some other bits are for a different driver. | |
| 10 | +With this patch all accesses to the RCU registers will go through | |
| 11 | +syscon. | |
| 12 | + | |
| 13 | + | |
| 14 | +------------------------------------------------------------------------------- | |
| 15 | +Required properties: | |
| 16 | +- compatible : The first and second values must be: | |
| 17 | + "lantiq,xrx200-rcu", "simple-mfd", "syscon" | |
| 18 | +- reg : The address and length of the system control registers | |
| 19 | + | |
| 20 | + | |
| 21 | +------------------------------------------------------------------------------- | |
| 22 | +Example of the RCU bindings on a xRX200 SoC: | |
| 23 | + rcu0: rcu@203000 { | |
| 24 | + compatible = "lantiq,xrx200-rcu", "simple-mfd", "syscon"; | |
| 25 | + reg = <0x203000 0x100>; | |
| 26 | + ranges = <0x0 0x203000 0x100>; | |
| 27 | + big-endian; | |
| 28 | + | |
| 29 | + gphy0: gphy@20 { | |
| 30 | + compatible = "lantiq,xrx200a2x-gphy"; | |
| 31 | + reg = <0x20 0x4>; | |
| 32 | + | |
| 33 | + resets = <&reset0 31 30>, <&reset1 7 7>; | |
| 34 | + reset-names = "gphy", "gphy2"; | |
| 35 | + lantiq,gphy-mode = <GPHY_MODE_GE>; | |
| 36 | + }; | |
| 37 | + | |
| 38 | + gphy1: gphy@68 { | |
| 39 | + compatible = "lantiq,xrx200a2x-gphy"; | |
| 40 | + reg = <0x68 0x4>; | |
| 41 | + | |
| 42 | + resets = <&reset0 29 28>, <&reset1 6 6>; | |
| 43 | + reset-names = "gphy", "gphy2"; | |
| 44 | + lantiq,gphy-mode = <GPHY_MODE_GE>; | |
| 45 | + }; | |
| 46 | + | |
| 47 | + reset0: reset-controller@10 { | |
| 48 | + compatible = "lantiq,xrx200-reset"; | |
| 49 | + reg = <0x10 4>, <0x14 4>; | |
| 50 | + | |
| 51 | + #reset-cells = <2>; | |
| 52 | + }; | |
| 53 | + | |
| 54 | + reset1: reset-controller@48 { | |
| 55 | + compatible = "lantiq,xrx200-reset"; | |
| 56 | + reg = <0x48 4>, <0x24 4>; | |
| 57 | + | |
| 58 | + #reset-cells = <2>; | |
| 59 | + }; | |
| 60 | + | |
| 61 | + usb_phy0: usb2-phy@18 { | |
| 62 | + compatible = "lantiq,xrx200-usb2-phy"; | |
| 63 | + reg = <0x18 4>, <0x38 4>; | |
| 64 | + status = "disabled"; | |
| 65 | + | |
| 66 | + resets = <&reset1 4 4>, <&reset0 4 4>; | |
| 67 | + reset-names = "phy", "ctrl"; | |
| 68 | + #phy-cells = <0>; | |
| 69 | + }; | |
| 70 | + | |
| 71 | + usb_phy1: usb2-phy@34 { | |
| 72 | + compatible = "lantiq,xrx200-usb2-phy"; | |
| 73 | + reg = <0x34 4>, <0x3C 4>; | |
| 74 | + status = "disabled"; | |
| 75 | + | |
| 76 | + resets = <&reset1 5 4>, <&reset0 4 4>; | |
| 77 | + reset-names = "phy", "ctrl"; | |
| 78 | + #phy-cells = <0>; | |
| 79 | + }; | |
| 80 | + | |
| 81 | + reboot@10 { | |
| 82 | + compatible = "syscon-reboot"; | |
| 83 | + reg = <0x10 4>; | |
| 84 | + | |
| 85 | + regmap = <&rcu0>; | |
| 86 | + offset = <0x10>; | |
| 87 | + mask = <0x40000000>; | |
| 88 | + }; | |
| 89 | + }; | |
| @@ -0,0 +1,7 @@ | ||
| 1 | +National Instruments MIPS platforms | |
| 2 | + | |
| 3 | +required root node properties: | |
| 4 | + - compatible: must be "ni,169445" | |
| 5 | + | |
| 6 | +CPU Nodes | |
| 7 | + - compatible: must be "mti,mips14KEc" | |
| @@ -15,3 +15,4 @@ value must be one of the following values: · 14 unmodified lines | ||
| 15 | 15 | ralink,rt5350-soc |
| 16 | 16 | ralink,mt7620a-soc |
| 17 | 17 | ralink,mt7620n-soc |
| 18 | + ralink,mt7628a-soc | |
| @@ -47,5 +47,4 @@ ssc0: ssc@f0010000 { · 46 unmodified lines | ||
| 47 | 47 | dma-names = "tx", "rx"; |
| 48 | 48 | pinctrl-names = "default"; |
| 49 | 49 | pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; |
| 50 | − status = "disabled"; | |
| 51 | 50 | }; |
| @@ -74,5 +74,4 @@ Example: · 73 unmodified lines | ||
| 74 | 74 | phys = <&emmc_phy>; |
| 75 | 75 | phy-names = "phy_arasan"; |
| 76 | 76 | #clock-cells = <0>; |
| 77 | − status = "disabled"; | |
| 78 | 77 | }; |
| @@ -24,7 +24,6 @@ mmc0: mmc@1c40000 { · 23 unmodified lines | ||
| 24 | 24 | compatible = "ti,da830-mmc", |
| 25 | 25 | reg = <0x40000 0x1000>; |
| 26 | 26 | interrupts = <16>; |
| 27 | − status = "okay"; | |
| 28 | 27 | bus-width = <4>; |
| 29 | 28 | max-frequency = <50000000>; |
| 30 | 29 | dmas = <&edma 16 |
| @@ -20,5 +20,4 @@ sdhci1: sdhci@10014000 { · 19 unmodified lines | ||
| 20 | 20 | dma-names = "rx-tx"; |
| 21 | 21 | bus-width = <4>; |
| 22 | 22 | cd-gpios = <&gpio3 29>; |
| 23 | − status = "okay"; | |
| 24 | 23 | }; |
| @@ -21,7 +21,6 @@ Example: · 20 unmodified lines | ||
| 21 | 21 | vmmc-supply = <®_vcc3v3>; |
| 22 | 22 | bus-width = <8>; |
| 23 | 23 | non-removable; |
| 24 | − status = "okay"; | |
| 25 | 24 | |
| 26 | 25 | mmccard: mmccard@0 { |
| 27 | 26 | reg = <0>; |
| @@ -153,7 +153,6 @@ mmc3: mmc@01c12000 { · 152 unmodified lines | ||
| 153 | 153 | bus-width = <4>; |
| 154 | 154 | non-removable; |
| 155 | 155 | mmc-pwrseq = <&sdhci0_pwrseq> |
| 156 | − status = "okay"; | |
| 157 | 156 | |
| 158 | 157 | brcmf: bcrmf@1 { |
| 159 | 158 | reg = <1>; |
| @@ -13,5 +13,4 @@ Example: · 12 unmodified lines | ||
| 13 | 13 | reg = <0xd00d4000 0x200>; |
| 14 | 14 | interrupts = <54>; |
| 15 | 15 | clocks = <&gateclk 17>; |
| 16 | − status = "disabled"; | |
| 17 | 16 | }; |
| @@ -11,6 +11,8 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs |
| 12 | 12 | - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs |
| 13 | 13 | - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs |
| 14 | + - "renesas,mmcif-r8a7743" for the MMCIF found in r8a7743 SoCs | |
| 15 | + - "renesas,mmcif-r8a7745" for the MMCIF found in r8a7745 SoCs | |
| 14 | 16 | - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs |
| 15 | 17 | - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs |
| 16 | 18 | - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs |
| @@ -21,7 +23,7 @@ Required properties: · 4 unmodified lines | ||
| 21 | 23 | - interrupts: Some SoCs have only 1 shared interrupt, while others have either |
| 22 | 24 | 2 or 3 individual interrupts (error, int, card detect). Below is the number |
| 23 | 25 | of interrupts for each SoC: |
| 24 | − 1: r8a73a4, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794 | |
| 26 | + 1: r8a73a4, r8a7743, r8a7745, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794 | |
| 25 | 27 | 2: r8a7740, sh73a0 |
| 26 | 28 | 3: r7s72100 |
| 27 | 29 | |
| @@ -15,6 +15,7 @@ Required Properties: · 14 unmodified lines | ||
| 15 | 15 | - "rockchip,rk3288-dw-mshc": for Rockchip RK3288 |
| 16 | 16 | - "rockchip,rv1108-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RV1108 |
| 17 | 17 | - "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036 |
| 18 | + - "rockchip,rk3228-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK322x | |
| 18 | 19 | - "rockchip,rk3328-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3328 |
| 19 | 20 | - "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368 |
| 20 | 21 | - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399 |
| @@ -63,7 +63,6 @@ Example: · 62 unmodified lines | ||
| 63 | 63 | |
| 64 | 64 | mmc0: sdhci@fe81e000 { |
| 65 | 65 | compatible = "st,sdhci"; |
| 66 | − status = "disabled"; | |
| 67 | 66 | reg = <0xfe81e000 0x1000>; |
| 68 | 67 | interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>; |
| 69 | 68 | interrupt-names = "mmcirq"; |
| @@ -77,7 +76,6 @@ mmc0: sdhci@fe81e000 { · 7 unmodified lines | ||
| 77 | 76 | |
| 78 | 77 | mmc1: sdhci@09080000 { |
| 79 | 78 | compatible = "st,sdhci-stih407", "st,sdhci"; |
| 80 | − status = "disabled"; | |
| 81 | 79 | reg = <0x09080000 0x7ff>; |
| 82 | 80 | reg-names = "mmc"; |
| 83 | 81 | interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>; |
| @@ -94,7 +92,6 @@ mmc1: sdhci@09080000 { · 10 unmodified lines | ||
| 94 | 92 | |
| 95 | 93 | mmc0: sdhci@09060000 { |
| 96 | 94 | compatible = "st,sdhci-stih407", "st,sdhci"; |
| 97 | − status = "disabled"; | |
| 98 | 95 | reg = <0x09060000 0x7ff>, <0x9061008 0x20>; |
| 99 | 96 | reg-names = "mmc", "top-mmc-delay"; |
| 100 | 97 | interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>; |
| @@ -12,6 +12,7 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | * "allwinner,sun4i-a10-mmc" |
| 13 | 13 | * "allwinner,sun5i-a13-mmc" |
| 14 | 14 | * "allwinner,sun7i-a20-mmc" |
| 15 | + * "allwinner,sun8i-a83t-emmc" | |
| 15 | 16 | * "allwinner,sun9i-a80-mmc" |
| 16 | 17 | * "allwinner,sun50i-a64-emmc" |
| 17 | 18 | * "allwinner,sun50i-a64-mmc" |
| @@ -1,33 +1,55 @@ | ||
| 1 | −* TI Highspeed MMC host controller for OMAP | |
| 1 | +* TI Highspeed MMC host controller for OMAP and 66AK2G family. | |
| 2 | 2 | |
| 3 | −The Highspeed MMC Host Controller on TI OMAP family | |
| 3 | +The Highspeed MMC Host Controller on TI OMAP and 66AK2G family | |
| 4 | 4 | provides an interface for MMC, SD, and SDIO types of memory cards. |
| 5 | 5 | |
| 6 | 6 | This file documents differences between the core properties described |
| 7 | 7 | by mmc.txt and the properties used by the omap_hsmmc driver. |
| 8 | 8 | |
| 9 | 9 | Required properties: |
| 10 | +-------------------- | |
| 10 | 11 | - compatible: |
| 11 | 12 | Should be "ti,omap2-hsmmc", for OMAP2 controllers |
| 12 | 13 | Should be "ti,omap3-hsmmc", for OMAP3 controllers |
| 13 | 14 | Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 |
| 14 | 15 | Should be "ti,omap4-hsmmc", for OMAP4 controllers |
| 15 | 16 | Should be "ti,am33xx-hsmmc", for AM335x controllers |
| 16 | −- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1 | |
| 17 | + Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers. | |
| 18 | + | |
| 19 | +SoC specific required properties: | |
| 20 | +--------------------------------- | |
| 21 | +The following are mandatory properties for OMAPs, AM33xx and AM43xx SoCs only: | |
| 22 | +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1. | |
| 23 | + | |
| 24 | +The following are mandatory properties for 66AK2G SoCs only: | |
| 25 | +- power-domains:Should contain a phandle to a PM domain provider node | |
| 26 | + and an args specifier containing the MMC device id | |
| 27 | + value. This property is as per the binding, | |
| 28 | + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt | |
| 29 | +- clocks: Must contain an entry for each entry in clock-names. Should | |
| 30 | + be defined as per the he appropriate clock bindings consumer | |
| 31 | + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt | |
| 32 | +- clock-names: Shall be "fck" for the functional clock, | |
| 33 | + and "mmchsdb_fck" for the debounce clock. | |
| 34 | + | |
| 17 | 35 | |
| 18 | 36 | Optional properties: |
| 19 | −ti,dual-volt: boolean, supports dual voltage cards | |
| 20 | −<supply-name>-supply: phandle to the regulator device tree node | |
| 21 | −"supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc | |
| 22 | −ti,non-removable: non-removable slot (like eMMC) | |
| 23 | −ti,needs-special-reset: Requires a special softreset sequence | |
| 24 | −ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed | |
| 25 | −dmas: List of DMA specifiers with the controller specific format | |
| 26 | −as described in the generic DMA client binding. A tx and rx | |
| 27 | −specifier is required. | |
| 28 | −dma-names: List of DMA request names. These strings correspond | |
| 29 | −1:1 with the DMA specifiers listed in dmas. The string naming is | |
| 30 | −to be "rx" and "tx" for RX and TX DMA requests, respectively. | |
| 37 | +-------------------- | |
| 38 | +- ti,dual-volt: boolean, supports dual voltage cards | |
| 39 | +- <supply-name>-supply: phandle to the regulator device tree node | |
| 40 | + "supply-name" examples are "vmmc", | |
| 41 | + "vmmc_aux"(deprecated)/"vqmmc" etc | |
| 42 | +- ti,non-removable: non-removable slot (like eMMC) | |
| 43 | +- ti,needs-special-reset: Requires a special softreset sequence | |
| 44 | +- ti,needs-special-hs-handling: HSMMC IP needs special setting | |
| 45 | + for handling High Speed | |
| 46 | +- dmas: List of DMA specifiers with the controller specific | |
| 47 | + format as described in the generic DMA client | |
| 48 | + binding. A tx and rx specifier is required. | |
| 49 | +- dma-names: List of DMA request names. These strings correspond | |
| 50 | + 1:1 with the DMA specifiers listed in dmas. | |
| 51 | + The string naming is to be "rx" and "tx" for | |
| 52 | + RX and TX DMA requests, respectively. | |
| 31 | 53 | |
| 32 | 54 | Examples: |
| 33 | 55 | |
| @@ -15,6 +15,8 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC |
| 16 | 16 | "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC |
| 17 | 17 | "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC |
| 18 | + "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC | |
| 19 | + "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC | |
| 18 | 20 | "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC |
| 19 | 21 | "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC |
| 20 | 22 | "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC |
| @@ -33,10 +35,8 @@ Required properties: · 12 unmodified lines | ||
| 33 | 35 | If 2 clocks are specified by the hardware, you must name them as |
| 34 | 36 | "core" and "cd". If the controller only has 1 clock, naming is not |
| 35 | 37 | required. |
| 36 | − Below is the number clocks for each supported SoC: | |
| 37 | − 1: SH73A0, R8A73A4, R8A7740, R8A7778, R8A7779, R8A7790 | |
| 38 | − R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796 | |
| 39 | − 2: R7S72100 | |
| 38 | + Devices which have more than 1 clock are listed below: | |
| 39 | + 2: R7S72100 | |
| 40 | 40 | |
| 41 | 41 | Optional properties: |
| 42 | 42 | - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable |
| @@ -28,5 +28,4 @@ Example: · 27 unmodified lines | ||
| 28 | 28 | max-frequency = <50000000>; |
| 29 | 29 | cap-sdio-irq; |
| 30 | 30 | cap-sd-highspeed; |
| 31 | − status = "disabled"; | |
| 32 | 31 | }; |
| @@ -24,7 +24,6 @@ spi@f0020000 { · 23 unmodified lines | ||
| 24 | 24 | #size-cells = <0>; |
| 25 | 25 | pinctrl-names = "default"; |
| 26 | 26 | pinctrl-0 = <&pinctrl_spi0_default>; |
| 27 | − status = "okay"; | |
| 28 | 27 | |
| 29 | 28 | m25p80@0 { |
| 30 | 29 | ... |
| @@ -37,7 +37,6 @@ nor_flash: spi@1100d000 { · 36 unmodified lines | ||
| 37 | 37 | clock-names = "spi", "sf"; |
| 38 | 38 | #address-cells = <1>; |
| 39 | 39 | #size-cells = <0>; |
| 40 | − status = "disabled"; | |
| 41 | 40 | |
| 42 | 41 | flash@0 { |
| 43 | 42 | compatible = "jedec,spi-nor"; |
| @@ -1,11 +1,20 @@ | ||
| 1 | 1 | * Qualcomm NAND controller |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible: should be "qcom,ipq806x-nand" | |
| 4 | +- compatible: must be one of the following: | |
| 5 | + * "qcom,ipq806x-nand" - for EBI2 NAND controller being used in IPQ806x | |
| 6 | + SoC and it uses ADM DMA | |
| 7 | + * "qcom,ipq4019-nand" - for QPIC NAND controller v1.4.0 being used in | |
| 8 | + IPQ4019 SoC and it uses BAM DMA | |
| 9 | + * "qcom,ipq8074-nand" - for QPIC NAND controller v1.5.0 being used in | |
| 10 | + IPQ8074 SoC and it uses BAM DMA | |
| 11 | + | |
| 5 | 12 | - reg: MMIO address range |
| 6 | 13 | - clocks: must contain core clock and always on clock |
| 7 | 14 | - clock-names: must contain "core" for the core clock and "aon" for the |
| 8 | 15 | always on clock |
| 16 | + | |
| 17 | +EBI2 specific properties: | |
| 9 | 18 | - dmas: DMA specifier, consisting of a phandle to the ADM DMA |
| 10 | 19 | controller node and the channel number to be used for |
| 11 | 20 | NAND. Refer to dma.txt and qcom_adm.txt for more details |
| @@ -16,6 +25,12 @@ Required properties: · 4 unmodified lines | ||
| 16 | 25 | - qcom,data-crci: must contain the ADM data type CRCI block instance |
| 17 | 26 | number specified for the NAND controller on the given |
| 18 | 27 | platform |
| 28 | + | |
| 29 | +QPIC specific properties: | |
| 30 | +- dmas: DMA specifier, consisting of a phandle to the BAM DMA | |
| 31 | + and the channel number to be used for NAND. Refer to | |
| 32 | + dma.txt, qcom_bam_dma.txt for more details | |
| 33 | +- dma-names: must contain all 3 channel names : "tx", "rx", "cmd" | |
| 19 | 34 | - #address-cells: <1> - subnodes give the chip-select number |
| 20 | 35 | - #size-cells: <0> |
| 21 | 36 | |
| @@ -26,7 +41,6 @@ chip-selects which (may) contain NAND flash chips. Their properties are as · 4 unmodified lines | ||
| 26 | 41 | follows. |
| 27 | 42 | |
| 28 | 43 | Required properties: |
| 29 | −- compatible: should contain "qcom,nandcs" | |
| 30 | 44 | - reg: a single integer representing the chip-select |
| 31 | 45 | number (e.g., 0, 1, 2, etc.) |
| 32 | 46 | - #address-cells: see partition.txt |
| @@ -43,8 +57,8 @@ partition.txt for more detail. · 10 unmodified lines | ||
| 43 | 57 | |
| 44 | 58 | Example: |
| 45 | 59 | |
| 46 | −nand@1ac00000 { | |
| 47 | − compatible = "qcom,ebi2-nandc"; | |
| 60 | +nand-controller@1ac00000 { | |
| 61 | + compatible = "qcom,ipq806x-nand"; | |
| 48 | 62 | reg = <0x1ac00000 0x800>; |
| 49 | 63 | |
| 50 | 64 | clocks = <&gcc EBI2_CLK>, |
| @@ -59,8 +73,7 @@ nand@1ac00000 { · 8 unmodified lines | ||
| 59 | 73 | #address-cells = <1>; |
| 60 | 74 | #size-cells = <0>; |
| 61 | 75 | |
| 62 | − nandcs@0 { | |
| 63 | − compatible = "qcom,nandcs"; | |
| 76 | + nand@0 { | |
| 64 | 77 | reg = <0>; |
| 65 | 78 | |
| 66 | 79 | nand-ecc-strength = <4>; |
| @@ -84,3 +97,43 @@ nand@1ac00000 { · 17 unmodified lines | ||
| 84 | 97 | }; |
| 85 | 98 | }; |
| 86 | 99 | }; |
| 100 | + | |
| 101 | +nand-controller@79b0000 { | |
| 102 | + compatible = "qcom,ipq4019-nand"; | |
| 103 | + reg = <0x79b0000 0x1000>; | |
| 104 | + | |
| 105 | + clocks = <&gcc GCC_QPIC_CLK>, | |
| 106 | + <&gcc GCC_QPIC_AHB_CLK>; | |
| 107 | + clock-names = "core", "aon"; | |
| 108 | + | |
| 109 | + dmas = <&qpicbam 0>, | |
| 110 | + <&qpicbam 1>, | |
| 111 | + <&qpicbam 2>; | |
| 112 | + dma-names = "tx", "rx", "cmd"; | |
| 113 | + | |
| 114 | + #address-cells = <1>; | |
| 115 | + #size-cells = <0>; | |
| 116 | + | |
| 117 | + nand@0 { | |
| 118 | + reg = <0>; | |
| 119 | + nand-ecc-strength = <4>; | |
| 120 | + nand-ecc-step-size = <512>; | |
| 121 | + nand-bus-width = <8>; | |
| 122 | + | |
| 123 | + partitions { | |
| 124 | + compatible = "fixed-partitions"; | |
| 125 | + #address-cells = <1>; | |
| 126 | + #size-cells = <1>; | |
| 127 | + | |
| 128 | + partition@0 { | |
| 129 | + label = "boot-nand"; | |
| 130 | + reg = <0 0x58a0000>; | |
| 131 | + }; | |
| 132 | + | |
| 133 | + partition@58a0000 { | |
| 134 | + label = "fs-nand"; | |
| 135 | + reg = <0x58a0000 0x4000000>; | |
| 136 | + }; | |
| 137 | + }; | |
| 138 | + }; | |
| 139 | +}; | |
| @@ -21,6 +21,5 @@ Example: · 20 unmodified lines | ||
| 21 | 21 | st,syscfg = <&syscfg_rear>; |
| 22 | 22 | st,boot-device-reg = <0x958>; |
| 23 | 23 | st,boot-device-spi = <0x1a>; |
| 24 | − status = "okay"; | |
| 25 | 24 | }; |
| 26 | 25 | |
| @@ -41,7 +41,6 @@ nfc: nand@01c03000 { · 40 unmodified lines | ||
| 41 | 41 | #size-cells = <0>; |
| 42 | 42 | pinctrl-names = "default"; |
| 43 | 43 | pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>; |
| 44 | − status = "okay"; | |
| 45 | 44 | |
| 46 | 45 | nand@0 { |
| 47 | 46 | reg = <0>; |
| @@ -0,0 +1,25 @@ | ||
| 1 | +* Adaptrum Anarion ethernet controller | |
| 2 | + | |
| 3 | +This device is a platform glue layer for stmmac. | |
| 4 | +Please see stmmac.txt for the other unchanged properties. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | + - compatible: Should be "adaptrum,anarion-gmac", "snps,dwmac" | |
| 8 | + - phy-mode: Should be "rgmii". Other modes are not currently supported. | |
| 9 | + | |
| 10 | + | |
| 11 | +Examples: | |
| 12 | + | |
| 13 | + gmac1: ethernet@f2014000 { | |
| 14 | + compatible = "adaptrum,anarion-gmac", "snps,dwmac"; | |
| 15 | + reg = <0xf2014000 0x4000>, <0xf2018100 8>; | |
| 16 | + | |
| 17 | + interrupt-parent = <&core_intc>; | |
| 18 | + interrupts = <21>; | |
| 19 | + interrupt-names = "macirq"; | |
| 20 | + | |
| 21 | + clocks = <&core_clk>; | |
| 22 | + clock-names = "stmmaceth"; | |
| 23 | + | |
| 24 | + phy-mode = "rgmii"; | |
| 25 | + }; | |
| @@ -27,5 +27,4 @@ amac0: ethernet@18022000 { · 26 unmodified lines | ||
| 27 | 27 | <0x18110000 0x1000>; |
| 28 | 28 | reg-names = "amac_base", "idm_base"; |
| 29 | 29 | interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; |
| 30 | − status = "disabled"; | |
| 31 | 30 | }; |
| @@ -0,0 +1,35 @@ | ||
| 1 | +Broadcom Bluetooth Chips | |
| 2 | +--------------------- | |
| 3 | + | |
| 4 | +This documents the binding structure and common properties for serial | |
| 5 | +attached Broadcom devices. | |
| 6 | + | |
| 7 | +Serial attached Broadcom devices shall be a child node of the host UART | |
| 8 | +device the slave device is attached to. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | + | |
| 12 | + - compatible: should contain one of the following: | |
| 13 | + * "brcm,bcm43438-bt" | |
| 14 | + | |
| 15 | +Optional properties: | |
| 16 | + | |
| 17 | + - max-speed: see Documentation/devicetree/bindings/serial/slave-device.txt | |
| 18 | + - shutdown-gpios: GPIO specifier, used to enable the BT module | |
| 19 | + - device-wakeup-gpios: GPIO specifier, used to wakeup the controller | |
| 20 | + - host-wakeup-gpios: GPIO specifier, used to wakeup the host processor | |
| 21 | + - clocks: clock specifier if external clock provided to the controller | |
| 22 | + - clock-names: should be "extclk" | |
| 23 | + | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + | |
| 27 | +&uart2 { | |
| 28 | + pinctrl-names = "default"; | |
| 29 | + pinctrl-0 = <&uart2_pins>; | |
| 30 | + | |
| 31 | + bluetooth { | |
| 32 | + compatible = "brcm,bcm43438-bt"; | |
| 33 | + max-speed = <921600>; | |
| 34 | + }; | |
| 35 | +}; | |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | ||
| 29 | 29 | Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt: |
| 30 | 30 | |
| 31 | 31 | &usb_host1_ehci { |
| 32 | − status = "okay"; | |
| 33 | 32 | #address-cells = <1>; |
| 34 | 33 | #size-cells = <0>; |
| 35 | 34 | |
| @@ -11,9 +11,20 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | - interrupts : property with a value describing the interrupt |
| 12 | 12 | number |
| 13 | 13 | |
| 14 | −Optional properties: | |
| 14 | +The following are mandatory properties for DRA7x, AM33xx and AM43xx SoCs only: | |
| 15 | 15 | - ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the |
| 16 | 16 | instance number |
| 17 | + | |
| 18 | +The following are mandatory properties for Keystone 2 66AK2G SoCs only: | |
| 19 | +- power-domains : Should contain a phandle to a PM domain provider node | |
| 20 | + and an args specifier containing the DCAN device id | |
| 21 | + value. This property is as per the binding, | |
| 22 | + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt | |
| 23 | +- clocks : CAN functional clock phandle. This property is as per the | |
| 24 | + binding, | |
| 25 | + Documentation/devicetree/bindings/clock/ti,sci-clk.txt | |
| 26 | + | |
| 27 | +Optional properties: | |
| 17 | 28 | - syscon-raminit : Handle to system control region that contains the |
| 18 | 29 | RAMINIT register, register offset to the RAMINIT |
| 19 | 30 | register and the CAN instance number (0 offset). |
| @@ -56,7 +56,6 @@ m_can1: can@020e8000 { · 55 unmodified lines | ||
| 56 | 56 | <&clks IMX6SX_CLK_CANFD>; |
| 57 | 57 | clock-names = "hclk", "cclk"; |
| 58 | 58 | bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>; |
| 59 | − status = "disabled"; | |
| 60 | 59 | }; |
| 61 | 60 | |
| 62 | 61 | Board dts: |
| @@ -24,7 +24,6 @@ Ethernet switch connected via SPI to the host, CPU port wired to eth0: · 23 unmodified lines | ||
| 24 | 24 | pinctrl-0 = <&pinctrl_spi_ksz>; |
| 25 | 25 | cs-gpios = <&pioC 25 0>; |
| 26 | 26 | id = <1>; |
| 27 | − status = "okay"; | |
| 28 | 27 | |
| 29 | 28 | ksz9477: ksz9477@0 { |
| 30 | 29 | compatible = "microchip,ksz9477"; |
| @@ -34,7 +33,6 @@ Ethernet switch connected via SPI to the host, CPU port wired to eth0: · 3 unmodified lines | ||
| 34 | 33 | spi-cpha; |
| 35 | 34 | spi-cpol; |
| 36 | 35 | |
| 37 | − status = "okay"; | |
| 38 | 36 | ports { |
| 39 | 37 | #address-cells = <1>; |
| 40 | 38 | #size-cells = <0>; |
| @@ -27,7 +27,6 @@ Example: · 26 unmodified lines | ||
| 27 | 27 | I2C managed mode: |
| 28 | 28 | |
| 29 | 29 | master: masterdevice@X { |
| 30 | − status = "okay"; | |
| 31 | 30 | |
| 32 | 31 | fixed-link { /* RMII fixed link to LAN9303 */ |
| 33 | 32 | speed = <100>; |
| @@ -38,7 +37,6 @@ I2C managed mode: · 4 unmodified lines | ||
| 38 | 37 | switch: switch@a { |
| 39 | 38 | compatible = "smsc,lan9303-i2c"; |
| 40 | 39 | reg = <0xa>; |
| 41 | − status = "okay"; | |
| 42 | 40 | reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>; |
| 43 | 41 | reset-duration = <200>; |
| 44 | 42 | |
| @@ -67,7 +65,6 @@ I2C managed mode: · 22 unmodified lines | ||
| 67 | 65 | MDIO managed mode: |
| 68 | 66 | |
| 69 | 67 | master: masterdevice@X { |
| 70 | − status = "okay"; | |
| 71 | 68 | phy-handle = <&switch>; |
| 72 | 69 | |
| 73 | 70 | mdio { |
| @@ -1,84 +0,0 @@ | ||
| 1 | −* Allwinner sun8i GMAC ethernet controller | |
| 2 | − | |
| 3 | −This device is a platform glue layer for stmmac. | |
| 4 | −Please see stmmac.txt for the other unchanged properties. | |
| 5 | − | |
| 6 | −Required properties: | |
| 7 | −- compatible: should be one of the following string: | |
| 8 | − "allwinner,sun8i-a83t-emac" | |
| 9 | − "allwinner,sun8i-h3-emac" | |
| 10 | − "allwinner,sun8i-v3s-emac" | |
| 11 | − "allwinner,sun50i-a64-emac" | |
| 12 | −- reg: address and length of the register for the device. | |
| 13 | −- interrupts: interrupt for the device | |
| 14 | −- interrupt-names: should be "macirq" | |
| 15 | −- clocks: A phandle to the reference clock for this device | |
| 16 | −- clock-names: should be "stmmaceth" | |
| 17 | −- resets: A phandle to the reset control for this device | |
| 18 | −- reset-names: should be "stmmaceth" | |
| 19 | −- phy-mode: See ethernet.txt | |
| 20 | −- phy-handle: See ethernet.txt | |
| 21 | −- #address-cells: shall be 1 | |
| 22 | −- #size-cells: shall be 0 | |
| 23 | −- syscon: A phandle to the syscon of the SoC with one of the following | |
| 24 | − compatible string: | |
| 25 | − - allwinner,sun8i-h3-system-controller | |
| 26 | − - allwinner,sun8i-v3s-system-controller | |
| 27 | − - allwinner,sun50i-a64-system-controller | |
| 28 | − - allwinner,sun8i-a83t-system-controller | |
| 29 | − | |
| 30 | −Optional properties: | |
| 31 | −- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0) | |
| 32 | −- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0) | |
| 33 | −Both delay properties need to be a multiple of 100. They control the delay for | |
| 34 | −external PHY. | |
| 35 | − | |
| 36 | −Optional properties for the following compatibles: | |
| 37 | − - "allwinner,sun8i-h3-emac", | |
| 38 | − - "allwinner,sun8i-v3s-emac": | |
| 39 | −- allwinner,leds-active-low: EPHY LEDs are active low | |
| 40 | − | |
| 41 | −Required child node of emac: | |
| 42 | −- mdio bus node: should be named mdio | |
| 43 | − | |
| 44 | −Required properties of the mdio node: | |
| 45 | −- #address-cells: shall be 1 | |
| 46 | −- #size-cells: shall be 0 | |
| 47 | − | |
| 48 | −The device node referenced by "phy" or "phy-handle" should be a child node | |
| 49 | −of the mdio node. See phy.txt for the generic PHY bindings. | |
| 50 | − | |
| 51 | −Required properties of the phy node with the following compatibles: | |
| 52 | − - "allwinner,sun8i-h3-emac", | |
| 53 | − - "allwinner,sun8i-v3s-emac": | |
| 54 | −- clocks: a phandle to the reference clock for the EPHY | |
| 55 | −- resets: a phandle to the reset control for the EPHY | |
| 56 | − | |
| 57 | −Example: | |
| 58 | − | |
| 59 | −emac: ethernet@1c0b000 { | |
| 60 | − compatible = "allwinner,sun8i-h3-emac"; | |
| 61 | − syscon = <&syscon>; | |
| 62 | − reg = <0x01c0b000 0x104>; | |
| 63 | − interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; | |
| 64 | − interrupt-names = "macirq"; | |
| 65 | − resets = <&ccu RST_BUS_EMAC>; | |
| 66 | − reset-names = "stmmaceth"; | |
| 67 | − clocks = <&ccu CLK_BUS_EMAC>; | |
| 68 | − clock-names = "stmmaceth"; | |
| 69 | − #address-cells = <1>; | |
| 70 | − #size-cells = <0>; | |
| 71 | − | |
| 72 | − phy-handle = <&int_mii_phy>; | |
| 73 | − phy-mode = "mii"; | |
| 74 | − allwinner,leds-active-low; | |
| 75 | − mdio: mdio { | |
| 76 | − #address-cells = <1>; | |
| 77 | − #size-cells = <0>; | |
| 78 | − int_mii_phy: ethernet-phy@1 { | |
| 79 | − reg = <1>; | |
| 80 | − clocks = <&ccu CLK_BUS_EPHY>; | |
| 81 | − resets = <&ccu RST_BUS_EPHY>; | |
| 82 | − }; | |
| 83 | − }; | |
| 84 | −}; | |
| @@ -1,5 +1,9 @@ | ||
| 1 | 1 | The following properties are common to the Ethernet controllers: |
| 2 | 2 | |
| 3 | +NOTE: All 'phy*' properties documented below are Ethernet specific. For the | |
| 4 | +generic PHY 'phys' property, see | |
| 5 | +Documentation/devicetree/bindings/phy/phy-bindings.txt. | |
| 6 | + | |
| 3 | 7 | - local-mac-address: array of 6 bytes, specifies the MAC address that was |
| 4 | 8 | assigned to the network device; |
| 5 | 9 | - mac-address: array of 6 bytes, specifies the MAC address that was last used by |
| @@ -30,6 +30,5 @@ Example: · 29 unmodified lines | ||
| 30 | 30 | compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; |
| 31 | 31 | reg = <0x1e660000 0x180>; |
| 32 | 32 | interrupts = <2>; |
| 33 | − status = "okay"; | |
| 34 | 33 | use-ncsi; |
| 35 | 34 | }; |
| @@ -41,7 +41,6 @@ ethernet@70000 { · 40 unmodified lines | ||
| 41 | 41 | interrupts = <8>; |
| 42 | 42 | clocks = <&gate_clk 4>; |
| 43 | 43 | tx-csum-limit = <9800> |
| 44 | − status = "okay"; | |
| 45 | 44 | phy = <&phy0>; |
| 46 | 45 | phy-mode = "rgmii-id"; |
| 47 | 46 | buffer-manager = <&bm>; |
| @@ -44,7 +44,6 @@ Example for SDIO device follows (calibration data is also available in · 43 unmodified lines | ||
| 44 | 44 | below example). |
| 45 | 45 | |
| 46 | 46 | &mmc3 { |
| 47 | − status = "okay"; | |
| 48 | 47 | vmmc-supply = <&wlan_en_reg>; |
| 49 | 48 | bus-width = <4>; |
| 50 | 49 | cap-power-off-card; |
| @@ -70,7 +69,6 @@ below example). · 19 unmodified lines | ||
| 70 | 69 | Example for USB device: |
| 71 | 70 | |
| 72 | 71 | &usb_host1_ohci { |
| 73 | − status = "okay"; | |
| 74 | 72 | #address-cells = <1>; |
| 75 | 73 | #size-cells = <0>; |
| 76 | 74 | |
| @@ -31,7 +31,6 @@ bm: bm@c8000 { · 30 unmodified lines | ||
| 31 | 31 | reg = <0xc8000 0xac>; |
| 32 | 32 | clocks = <&gateclk 13>; |
| 33 | 33 | internal-mem = <&bm_bppi>; |
| 34 | − status = "okay"; | |
| 35 | 34 | pool2,capacity = <4096>; |
| 36 | 35 | pool1,pkt-size = <512>; |
| 37 | 36 | }; |
| @@ -45,5 +44,4 @@ bm_bppi: bm-bppi { · 7 unmodified lines | ||
| 45 | 44 | #address-cells = <1>; |
| 46 | 45 | #size-cells = <1>; |
| 47 | 46 | clocks = <&gateclk 13>; |
| 48 | − status = "okay"; | |
| 49 | 47 | }; |
| @@ -41,6 +41,11 @@ Optional properties (port): · 40 unmodified lines | ||
| 41 | 41 | - marvell,loopback: port is loopback mode |
| 42 | 42 | - phy: a phandle to a phy node defining the PHY address (as the reg |
| 43 | 43 | property, a single integer). |
| 44 | +- interrupt-names: if more than a single interrupt for rx is given, must | |
| 45 | + be the name associated to the interrupts listed. Valid | |
| 46 | + names are: "tx-cpu0", "tx-cpu1", "tx-cpu2", "tx-cpu3", | |
| 47 | + "rx-shared", "link". | |
| 48 | +- marvell,system-controller: a phandle to the system controller. | |
| 44 | 49 | |
| 45 | 50 | Example for marvell,armada-375-pp2: |
| 46 | 51 | |
| @@ -52,12 +57,10 @@ ethernet@f0000 { · 5 unmodified lines | ||
| 52 | 57 | <0xc5000 0x100>; |
| 53 | 58 | clocks = <&gateclk 3>, <&gateclk 19>; |
| 54 | 59 | clock-names = "pp_clk", "gop_clk"; |
| 55 | − status = "okay"; | |
| 56 | 60 | |
| 57 | 61 | eth0: eth0@c4000 { |
| 58 | 62 | interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; |
| 59 | 63 | port-id = <0>; |
| 60 | − status = "okay"; | |
| 61 | 64 | phy = <&phy0>; |
| 62 | 65 | phy-mode = "gmii"; |
| 63 | 66 | }; |
| @@ -65,7 +68,6 @@ ethernet@f0000 { · 1 unmodified line | ||
| 65 | 68 | eth1: eth1@c5000 { |
| 66 | 69 | interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; |
| 67 | 70 | port-id = <1>; |
| 68 | − status = "okay"; | |
| 69 | 71 | phy = <&phy3>; |
| 70 | 72 | phy-mode = "gmii"; |
| 71 | 73 | }; |
| @@ -80,19 +82,37 @@ cpm_ethernet: ethernet@0 { · 8 unmodified lines | ||
| 80 | 82 | clock-names = "pp_clk", "gop_clk", "gp_clk"; |
| 81 | 83 | |
| 82 | 84 | eth0: eth0 { |
| 83 | − interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; | |
| 85 | + interrupts = <ICU_GRP_NSR 39 IRQ_TYPE_LEVEL_HIGH>, | |
| 86 | + <ICU_GRP_NSR 43 IRQ_TYPE_LEVEL_HIGH>, | |
| 87 | + <ICU_GRP_NSR 47 IRQ_TYPE_LEVEL_HIGH>, | |
| 88 | + <ICU_GRP_NSR 51 IRQ_TYPE_LEVEL_HIGH>, | |
| 89 | + <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>; | |
| 90 | + interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", | |
| 91 | + "tx-cpu3", "rx-shared"; | |
| 84 | 92 | port-id = <0>; |
| 85 | 93 | gop-port-id = <0>; |
| 86 | 94 | }; |
| 87 | 95 | |
| 88 | 96 | eth1: eth1 { |
| 89 | − interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; | |
| 97 | + interrupts = <ICU_GRP_NSR 40 IRQ_TYPE_LEVEL_HIGH>, | |
| 98 | + <ICU_GRP_NSR 44 IRQ_TYPE_LEVEL_HIGH>, | |
| 99 | + <ICU_GRP_NSR 48 IRQ_TYPE_LEVEL_HIGH>, | |
| 100 | + <ICU_GRP_NSR 52 IRQ_TYPE_LEVEL_HIGH>, | |
| 101 | + <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>; | |
| 102 | + interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", | |
| 103 | + "tx-cpu3", "rx-shared"; | |
| 90 | 104 | port-id = <1>; |
| 91 | 105 | gop-port-id = <2>; |
| 92 | 106 | }; |
| 93 | 107 | |
| 94 | 108 | eth2: eth2 { |
| 95 | − interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; | |
| 109 | + interrupts = <ICU_GRP_NSR 41 IRQ_TYPE_LEVEL_HIGH>, | |
| 110 | + <ICU_GRP_NSR 45 IRQ_TYPE_LEVEL_HIGH>, | |
| 111 | + <ICU_GRP_NSR 49 IRQ_TYPE_LEVEL_HIGH>, | |
| 112 | + <ICU_GRP_NSR 53 IRQ_TYPE_LEVEL_HIGH>, | |
| 113 | + <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>; | |
| 114 | + interrupt-names = "tx-cpu0", "tx-cpu1", "tx-cpu2", | |
| 115 | + "tx-cpu3", "rx-shared"; | |
| 96 | 116 | port-id = <2>; |
| 97 | 117 | gop-port-id = <3>; |
| 98 | 118 | }; |
| @@ -7,24 +7,32 @@ have dual GMAC each represented by a child node.. · 6 unmodified lines | ||
| 7 | 7 | * Ethernet controller node |
| 8 | 8 | |
| 9 | 9 | Required properties: |
| 10 | −- compatible: Should be "mediatek,mt2701-eth" | |
| 10 | +- compatible: Should be | |
| 11 | + "mediatek,mt2701-eth": for MT2701 SoC | |
| 12 | + "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC | |
| 13 | + "mediatek,mt7622-eth": for MT7622 SoC | |
| 11 | 14 | - reg: Address and length of the register set for the device |
| 12 | 15 | - interrupts: Should contain the three frame engines interrupts in numeric |
| 13 | 16 | order. These are fe_int0, fe_int1 and fe_int2. |
| 14 | 17 | - clocks: the clock used by the core |
| 15 | 18 | - clock-names: the names of the clock listed in the clocks property. These are |
| 16 | − "ethif", "esw", "gp2", "gp1" | |
| 19 | + "ethif", "esw", "gp2", "gp1" : For MT2701 and MT7623 SoC | |
| 20 | + "ethif", "esw", "gp0", "gp1", "gp2", "sgmii_tx250m", "sgmii_rx250m", | |
| 21 | + "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", "eth2pll" : For MT7622 SoC | |
| 17 | 22 | - power-domains: phandle to the power domain that the ethernet is part of |
| 18 | −- resets: Should contain a phandle to the ethsys reset signal | |
| 19 | −- reset-names: Should contain the reset signal name "eth" | |
| 23 | +- resets: Should contain phandles to the ethsys reset signals | |
| 24 | +- reset-names: Should contain the names of reset signal listed in the resets | |
| 25 | + property | |
| 26 | + These are "fe", "gmac" and "ppe" | |
| 20 | 27 | - mediatek,ethsys: phandle to the syscon node that handles the port setup |
| 28 | +- mediatek,sgmiisys: phandle to the syscon node that handles the SGMII setup | |
| 29 | + which is required for those SoCs equipped with SGMII such as MT7622 SoC. | |
| 21 | 30 | - mediatek,pctl: phandle to the syscon node that handles the ports slew rate |
| 22 | 31 | and driver current |
| 23 | 32 | |
| 24 | 33 | Optional properties: |
| 25 | 34 | - interrupt-parent: Should be the phandle for the interrupt controller |
| 26 | 35 | that services interrupts for this device |
| 27 | − | |
| 28 | 36 | * Ethernet MAC node |
| 29 | 37 | |
| 30 | 38 | Required properties: |
| @@ -66,5 +66,4 @@ Example for GXBB: · 65 unmodified lines | ||
| 66 | 66 | <&clkc CLKID_MPLL2>; |
| 67 | 67 | clock-names = "stmmaceth", "clkin0", "clkin1"; |
| 68 | 68 | phy-mode = "rgmii"; |
| 69 | − status = "disabled"; | |
| 70 | 69 | }; |
| @@ -69,7 +69,6 @@ Examples: · 68 unmodified lines | ||
| 69 | 69 | }; |
| 70 | 70 | }; |
| 71 | 71 | ethernet@70000 { |
| 72 | − status = "okay"; | |
| 73 | 72 | phy = <&phy0>; |
| 74 | 73 | phy-mode = "rgmii-id"; |
| 75 | 74 | }; |
| @@ -33,7 +33,6 @@ Example (for NXP i.MX28 with pin control stuff for GPIO irq): · 32 unmodified lines | ||
| 33 | 33 | compatible = "fsl,imx28-spi"; |
| 34 | 34 | pinctrl-names = "default"; |
| 35 | 35 | pinctrl-0 = <&spi2_pins_b &spi2_sck_cfg>; |
| 36 | − status = "okay"; | |
| 37 | 36 | |
| 38 | 37 | enc28j60: ethernet@0 { |
| 39 | 38 | compatible = "microchip,enc28j60"; |
| @@ -25,7 +25,6 @@ Optional I2C-based chip specific properties: · 24 unmodified lines | ||
| 25 | 25 | Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): |
| 26 | 26 | |
| 27 | 27 | &uart5 { |
| 28 | − status = "okay"; | |
| 29 | 28 | |
| 30 | 29 | nfcmrvluart: nfcmrvluart@5 { |
| 31 | 30 | compatible = "marvell,nfc-uart"; |
| @@ -41,7 +40,6 @@ Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): · 9 unmodified lines | ||
| 41 | 40 | Example (for ARM-based BeagleBoard Black with 88W8887 on I2C1): |
| 42 | 41 | |
| 43 | 42 | &i2c1 { |
| 44 | − status = "okay"; | |
| 45 | 43 | clock-frequency = <400000>; |
| 46 | 44 | |
| 47 | 45 | nfcmrvli2c0: i2c@1 { |
| @@ -17,7 +17,6 @@ Example (for ARM-based BeagleBone with NPC100 NFC controller on I2C2): · 16 unmodified lines | ||
| 17 | 17 | |
| 18 | 18 | &i2c2 { |
| 19 | 19 | |
| 20 | − status = "okay"; | |
| 21 | 20 | |
| 22 | 21 | npc100: npc100@29 { |
| 23 | 22 | |
| @@ -15,7 +15,6 @@ Example (for ARM-based BeagleBone with PN532 on I2C2): · 14 unmodified lines | ||
| 15 | 15 | |
| 16 | 16 | &i2c2 { |
| 17 | 17 | |
| 18 | − status = "okay"; | |
| 19 | 18 | |
| 20 | 19 | pn532: pn532@24 { |
| 21 | 20 | |
| @@ -17,7 +17,6 @@ Example (for ARM-based BeagleBone with PN544 on I2C2): · 16 unmodified lines | ||
| 17 | 17 | |
| 18 | 18 | &i2c2 { |
| 19 | 19 | |
| 20 | − status = "okay"; | |
| 21 | 20 | |
| 22 | 21 | pn544: pn544@28 { |
| 23 | 22 | |
| @@ -12,7 +12,6 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | Example: |
| 13 | 13 | |
| 14 | 14 | &hsi2c_4 { |
| 15 | − status = "okay"; | |
| 16 | 15 | s3fwrn5@27 { |
| 17 | 16 | compatible = "samsung,s3fwrn5-i2c"; |
| 18 | 17 | |
| @@ -20,7 +20,6 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2): · 19 unmodified lines | ||
| 20 | 20 | |
| 21 | 21 | &i2c2 { |
| 22 | 22 | |
| 23 | − status = "okay"; | |
| 24 | 23 | |
| 25 | 24 | st21nfcb: st21nfcb@8 { |
| 26 | 25 | |
| @@ -19,7 +19,6 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on SPI4): · 18 unmodified lines | ||
| 19 | 19 | |
| 20 | 20 | &mcspi4 { |
| 21 | 21 | |
| 22 | − status = "okay"; | |
| 23 | 22 | |
| 24 | 23 | st21nfcb: st21nfcb@0 { |
| 25 | 24 | |
| @@ -20,7 +20,6 @@ Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2): · 19 unmodified lines | ||
| 20 | 20 | |
| 21 | 21 | &i2c2 { |
| 22 | 22 | |
| 23 | − status = "okay"; | |
| 24 | 23 | |
| 25 | 24 | st21nfca: st21nfca@1 { |
| 26 | 25 | |
| @@ -35,12 +35,10 @@ spi@9840000 { · 34 unmodified lines | ||
| 35 | 35 | #address-cells = <1>; |
| 36 | 36 | #size-cells = <0>; |
| 37 | 37 | cs-gpios = <&pio0 4>; |
| 38 | − status = "okay"; | |
| 39 | 38 | |
| 40 | 39 | st95hf@0{ |
| 41 | 40 | reg = <0>; |
| 42 | 41 | compatible = "st,st95hf"; |
| 43 | − status = "okay"; | |
| 44 | 42 | spi-max-frequency = <1000000>; |
| 45 | 43 | enable-gpio = <&pio4 0>; |
| 46 | 44 | interrupt-parent = <&pio0>; |
| @@ -23,7 +23,6 @@ Optional SoC Specific Properties: · 22 unmodified lines | ||
| 23 | 23 | Example (for ARM-based BeagleBone with TRF7970A on SPI1): |
| 24 | 24 | |
| 25 | 25 | &spi1 { |
| 26 | − status = "okay"; | |
| 27 | 26 | |
| 28 | 27 | nfc@0 { |
| 29 | 28 | compatible = "ti,trf7970a"; |
| @@ -41,6 +40,5 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1): · 11 unmodified lines | ||
| 41 | 40 | irq-status-read-quirk; |
| 42 | 41 | en2-rf-quirk; |
| 43 | 42 | clock-frequency = <27120000>; |
| 44 | − status = "okay"; | |
| 45 | 43 | }; |
| 46 | 44 | }; |
| @@ -35,5 +35,4 @@ etha: ethernet@40400000 { · 34 unmodified lines | ||
| 35 | 35 | /* Regmap for sys registers */ |
| 36 | 36 | oxsemi,sys-ctrl = <&sys>; |
| 37 | 37 | |
| 38 | − status = "disabled"; | |
| 39 | 38 | }; |
| @@ -2,11 +2,7 @@ PHY nodes · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | − - interrupts : <a b> where a is the interrupt number and b is a | |
| 6 | − field that represents an encoding of the sense and level | |
| 7 | − information for the interrupt. This should be encoded based on | |
| 8 | − the information in section 2) depending on the type of interrupt | |
| 9 | − controller you have. | |
| 5 | + - interrupts : interrupt specifier for the sole interrupt. | |
| 10 | 6 | - interrupt-parent : the phandle for the interrupt controller that |
| 11 | 7 | services interrupts for this device. |
| 12 | 8 | - reg : The ID number for the phy, usually a small integer |
| @@ -52,11 +48,16 @@ Optional Properties: · 39 unmodified lines | ||
| 52 | 48 | Mark the corresponding energy efficient ethernet mode as broken and |
| 53 | 49 | request the ethernet to stop advertising it. |
| 54 | 50 | |
| 51 | +- phy-is-integrated: If set, indicates that the PHY is integrated into the same | |
| 52 | + physical package as the Ethernet MAC. If needed, muxers should be configured | |
| 53 | + to ensure the integrated PHY is used. The absence of this property indicates | |
| 54 | + the muxers should be configured so that the external PHY is used. | |
| 55 | + | |
| 55 | 56 | Example: |
| 56 | 57 | |
| 57 | 58 | ethernet-phy@0 { |
| 58 | 59 | compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22"; |
| 59 | − interrupt-parent = <40000>; | |
| 60 | − interrupts = <35 1>; | |
| 60 | + interrupt-parent = <&PIC>; | |
| 61 | + interrupts = <35 IRQ_TYPE_EDGE_RISING>; | |
| 61 | 62 | reg = <0>; |
| 62 | 63 | }; |
| @@ -41,7 +41,6 @@ ssp2: spi@80014000 { · 40 unmodified lines | ||
| 41 | 41 | compatible = "fsl,imx28-spi"; |
| 42 | 42 | pinctrl-names = "default"; |
| 43 | 43 | pinctrl-0 = <&spi2_pins_a>; |
| 44 | − status = "okay"; | |
| 45 | 44 | |
| 46 | 45 | qca7000: ethernet@0 { |
| 47 | 46 | compatible = "qca,qca7000"; |
| @@ -78,7 +77,6 @@ auart0: serial@8006a000 { · 30 unmodified lines | ||
| 78 | 77 | reg = <0x8006a000 0x2000>; |
| 79 | 78 | pinctrl-names = "default"; |
| 80 | 79 | pinctrl-0 = <&auart0_2pins_a>; |
| 81 | − status = "okay"; | |
| 82 | 80 | |
| 83 | 81 | qca7000: ethernet { |
| 84 | 82 | compatible = "qca,qca7000"; |
| @@ -4,19 +4,25 @@ This file provides information on what the device node for the Ethernet AVB · 3 unmodified lines | ||
| 4 | 4 | interface contains. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | −- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC. | |
| 8 | − "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC. | |
| 9 | − "renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC. | |
| 10 | − "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC. | |
| 11 | − "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. | |
| 12 | − "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC. | |
| 13 | − "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC. | |
| 14 | − "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible interface. | |
| 15 | − "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible interface. | |
| 7 | +- compatible: Must contain one or more of the following: | |
| 8 | + - "renesas,etheravb-r8a7743" for the R8A7743 SoC. | |
| 9 | + - "renesas,etheravb-r8a7745" for the R8A7745 SoC. | |
| 10 | + - "renesas,etheravb-r8a7790" for the R8A7790 SoC. | |
| 11 | + - "renesas,etheravb-r8a7791" for the R8A7791 SoC. | |
| 12 | + - "renesas,etheravb-r8a7792" for the R8A7792 SoC. | |
| 13 | + - "renesas,etheravb-r8a7793" for the R8A7793 SoC. | |
| 14 | + - "renesas,etheravb-r8a7794" for the R8A7794 SoC. | |
| 15 | + - "renesas,etheravb-rcar-gen2" as a fallback for the above | |
| 16 | + R-Car Gen2 and RZ/G1 devices. | |
| 16 | 17 | |
| 17 | − When compatible with the generic version, nodes must list the | |
| 18 | − SoC-specific version corresponding to the platform first | |
| 19 | − followed by the generic version. | |
| 18 | + - "renesas,etheravb-r8a7795" for the R8A7795 SoC. | |
| 19 | + - "renesas,etheravb-r8a7796" for the R8A7796 SoC. | |
| 20 | + - "renesas,etheravb-rcar-gen3" as a fallback for the above | |
| 21 | + R-Car Gen3 devices. | |
| 22 | + | |
| 23 | + When compatible with the generic version, nodes must list the | |
| 24 | + SoC-specific version corresponding to the platform first followed by | |
| 25 | + the generic version. | |
| 20 | 26 | |
| 21 | 27 | - reg: offset and length of (1) the register block and (2) the stream buffer. |
| 22 | 28 | - interrupts: A list of interrupt-specifiers, one for each entry in |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | "rockchip,rk3366-gmac": found on RK3366 SoCs |
| 11 | 11 | "rockchip,rk3368-gmac": found on RK3368 SoCs |
| 12 | 12 | "rockchip,rk3399-gmac": found on RK3399 SoCs |
| 13 | + "rockchip,rv1108-gmac": found on RV1108 SoCs | |
| 13 | 14 | - reg: addresses and length of the register sets for the device. |
| 14 | 15 | - interrupts: Should contain the GMAC interrupts. |
| 15 | 16 | - interrupt-names: Should contain the interrupt names "macirq". |
| @@ -70,5 +71,4 @@ gmac: ethernet@ff290000 { · 54 unmodified lines | ||
| 70 | 71 | tx_delay = <0x30>; |
| 71 | 72 | rx_delay = <0x10>; |
| 72 | 73 | |
| 73 | − status = "ok"; | |
| 74 | 74 | }; |
| @@ -0,0 +1,76 @@ | ||
| 1 | +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP) | |
| 2 | +Transceiver | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + | |
| 6 | +- compatible : must be "sff,sfp" | |
| 7 | + | |
| 8 | +Optional Properties: | |
| 9 | + | |
| 10 | +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial | |
| 11 | + interface | |
| 12 | + | |
| 13 | +- mod-def0-gpios : GPIO phandle and a specifier of the MOD-DEF0 (AKA Mod_ABS) | |
| 14 | + module presence input gpio signal, active (module absent) high | |
| 15 | + | |
| 16 | +- los-gpios : GPIO phandle and a specifier of the Receiver Loss of Signal | |
| 17 | + Indication input gpio signal, active (signal lost) high | |
| 18 | + | |
| 19 | +- tx-fault-gpios : GPIO phandle and a specifier of the Module Transmitter | |
| 20 | + Fault input gpio signal, active (fault condition) high | |
| 21 | + | |
| 22 | +- tx-disable-gpios : GPIO phandle and a specifier of the Transmitter Disable | |
| 23 | + output gpio signal, active (Tx disable) high | |
| 24 | + | |
| 25 | +- rate-select0-gpios : GPIO phandle and a specifier of the Rx Signaling Rate | |
| 26 | + Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx rate | |
| 27 | + | |
| 28 | +- rate-select1-gpios : GPIO phandle and a specifier of the Tx Signaling Rate | |
| 29 | + Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate, high: | |
| 30 | + high Tx rate | |
| 31 | + | |
| 32 | +Example #1: Direct serdes to SFP connection | |
| 33 | + | |
| 34 | +sfp_eth3: sfp-eth3 { | |
| 35 | + compatible = "sff,sfp"; | |
| 36 | + i2c-bus = <&sfp_1g_i2c>; | |
| 37 | + los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>; | |
| 38 | + mod-def0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>; | |
| 39 | + pinctrl-names = "default"; | |
| 40 | + pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>; | |
| 41 | + tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>; | |
| 42 | + tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>; | |
| 43 | +}; | |
| 44 | + | |
| 45 | +&cps_emac3 { | |
| 46 | + phy-names = "comphy"; | |
| 47 | + phys = <&cps_comphy5 0>; | |
| 48 | + sfp = <&sfp_eth3>; | |
| 49 | +}; | |
| 50 | + | |
| 51 | +Example #2: Serdes to PHY to SFP connection | |
| 52 | + | |
| 53 | +sfp_eth0: sfp-eth0 { | |
| 54 | + compatible = "sff,sfp"; | |
| 55 | + i2c-bus = <&sfpp0_i2c>; | |
| 56 | + los-gpios = <&cps_gpio1 28 GPIO_ACTIVE_HIGH>; | |
| 57 | + mod-def0-gpios = <&cps_gpio1 27 GPIO_ACTIVE_LOW>; | |
| 58 | + pinctrl-names = "default"; | |
| 59 | + pinctrl-0 = <&cps_sfpp0_pins>; | |
| 60 | + tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>; | |
| 61 | + tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>; | |
| 62 | +}; | |
| 63 | + | |
| 64 | +p0_phy: ethernet-phy@0 { | |
| 65 | + compatible = "ethernet-phy-ieee802.3-c45"; | |
| 66 | + pinctrl-names = "default"; | |
| 67 | + pinctrl-0 = <&cpm_phy0_pins &cps_phy0_pins>; | |
| 68 | + reg = <0>; | |
| 69 | + interrupt = <&cpm_gpio2 18 IRQ_TYPE_EDGE_FALLING>; | |
| 70 | + sfp = <&sfp_eth0>; | |
| 71 | +}; | |
| 72 | + | |
| 73 | +&cpm_eth0 { | |
| 74 | + phy = <&p0_phy>; | |
| 75 | + phy-mode = "10gbase-kr"; | |
| 76 | +}; | |
| @@ -15,7 +15,6 @@ smsc phy with disabled energy detect mode on an am335x based board. · 14 unmodified lines | ||
| 15 | 15 | pinctrl-names = "default", "sleep"; |
| 16 | 16 | pinctrl-0 = <&davinci_mdio_default>; |
| 17 | 17 | pinctrl-1 = <&davinci_mdio_sleep>; |
| 18 | − status = "okay"; | |
| 19 | 18 | |
| 20 | 19 | ethernetphy0: ethernet-phy@0 { |
| 21 | 20 | reg = <0>; |
| @@ -40,7 +40,6 @@ gmii_to_sgmii_converter: phy@0x100000240 { · 39 unmodified lines | ||
| 40 | 40 | gmac0: ethernet@ff700000 { |
| 41 | 41 | compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac"; |
| 42 | 42 | altr,sysmgr-syscon = <&sysmgr 0x60 0>; |
| 43 | − status = "disabled"; | |
| 44 | 43 | reg = <0xff700000 0x2000>; |
| 45 | 44 | interrupts = <0 115 4>; |
| 46 | 45 | interrupt-names = "macirq"; |
| @@ -34,7 +34,6 @@ Example: · 33 unmodified lines | ||
| 34 | 34 | |
| 35 | 35 | ethernet0: dwmac@9630000 { |
| 36 | 36 | device_type = "network"; |
| 37 | − status = "disabled"; | |
| 38 | 37 | compatible = "st,stih407-dwmac", "snps,dwmac", "snps,dwmac-3.710"; |
| 39 | 38 | reg = <0x9630000 0x8000>; |
| 40 | 39 | reg-names = "stmmaceth"; |
| @@ -18,7 +18,6 @@ Example: · 17 unmodified lines | ||
| 18 | 18 | |
| 19 | 19 | ethernet@40028000 { |
| 20 | 20 | compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; |
| 21 | − status = "disabled"; | |
| 22 | 21 | reg = <0x40028000 0x8000>; |
| 23 | 22 | reg-names = "stmmaceth"; |
| 24 | 23 | interrupts = <0 61 0>, <0 62 0>; |
| @@ -29,7 +29,6 @@ mmc3: mmc@01c12000 { · 28 unmodified lines | ||
| 29 | 29 | vmmc-supply = <®_vmmc3>; |
| 30 | 30 | bus-width = <4>; |
| 31 | 31 | non-removable; |
| 32 | − status = "okay"; | |
| 33 | 32 | |
| 34 | 33 | brcmf: wifi@1 { |
| 35 | 34 | reg = <1>; |
| @@ -21,7 +21,6 @@ Example: · 20 unmodified lines | ||
| 21 | 21 | mmc-pwrseq = <&wifi_pwrseq>; |
| 22 | 22 | bus-width = <4>; |
| 23 | 23 | non-removable; |
| 24 | − status = "okay"; | |
| 25 | 24 | |
| 26 | 25 | esp8089: sdio_wifi@1 { |
| 27 | 26 | compatible = "esp,esp8089"; |
| @@ -48,7 +48,6 @@ IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is configured · 47 unmodified lines | ||
| 48 | 48 | so that firmware can wakeup host using this device side pin. |
| 49 | 49 | |
| 50 | 50 | &mmc3 { |
| 51 | − status = "okay"; | |
| 52 | 51 | vmmc-supply = <&wlan_en_reg>; |
| 53 | 52 | mmc-pwrseq = <&wifi_pwrseq>; |
| 54 | 53 | bus-width = <4>; |
| @@ -31,7 +31,6 @@ clock, new bindings (for parsing the clock nodes) have to be added. · 30 unmodified lines | ||
| 31 | 31 | Example: |
| 32 | 32 | |
| 33 | 33 | &mmc3 { |
| 34 | − status = "okay"; | |
| 35 | 34 | vmmc-supply = <&wlan_en_reg>; |
| 36 | 35 | bus-width = <4>; |
| 37 | 36 | cap-power-off-card; |
| @@ -0,0 +1,55 @@ | ||
| 1 | +XILINX AXI ETHERNET Device Tree Bindings | |
| 2 | +-------------------------------------------------------- | |
| 3 | + | |
| 4 | +Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core | |
| 5 | +provides connectivity to an external ethernet PHY supporting different | |
| 6 | +interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two | |
| 7 | +segments of memory for buffering TX and RX, as well as the capability of | |
| 8 | +offloading TX/RX checksum calculation off the processor. | |
| 9 | + | |
| 10 | +Management configuration is done through the AXI interface, while payload is | |
| 11 | +sent and received through means of an AXI DMA controller. This driver | |
| 12 | +includes the DMA driver code, so this driver is incompatible with AXI DMA | |
| 13 | +driver. | |
| 14 | + | |
| 15 | +For more details about mdio please refer phy.txt file in the same directory. | |
| 16 | + | |
| 17 | +Required properties: | |
| 18 | +- compatible : Must be one of "xlnx,axi-ethernet-1.00.a", | |
| 19 | + "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a" | |
| 20 | +- reg : Address and length of the IO space. | |
| 21 | +- interrupts : Should be a list of two interrupt, TX and RX. | |
| 22 | +- phy-handle : Should point to the external phy device. | |
| 23 | + See ethernet.txt file in the same directory. | |
| 24 | +- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware | |
| 25 | + | |
| 26 | +Optional properties: | |
| 27 | +- phy-mode : See ethernet.txt | |
| 28 | +- xlnx,phy-type : Deprecated, do not use, but still accepted in preference | |
| 29 | + to phy-mode. | |
| 30 | +- xlnx,txcsum : 0 or empty for disabling TX checksum offload, | |
| 31 | + 1 to enable partial TX checksum offload, | |
| 32 | + 2 to enable full TX checksum offload | |
| 33 | +- xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum offload | |
| 34 | + | |
| 35 | +Example: | |
| 36 | + axi_ethernet_eth: ethernet@40c00000 { | |
| 37 | + compatible = "xlnx,axi-ethernet-1.00.a"; | |
| 38 | + device_type = "network"; | |
| 39 | + interrupt-parent = <µblaze_0_axi_intc>; | |
| 40 | + interrupts = <2 0>; | |
| 41 | + phy-mode = "mii"; | |
| 42 | + reg = <0x40c00000 0x40000>; | |
| 43 | + xlnx,rxcsum = <0x2>; | |
| 44 | + xlnx,rxmem = <0x800>; | |
| 45 | + xlnx,txcsum = <0x2>; | |
| 46 | + phy-handle = <&phy0>; | |
| 47 | + axi_ethernetlite_0_mdio: mdio { | |
| 48 | + #address-cells = <1>; | |
| 49 | + #size-cells = <0>; | |
| 50 | + phy0: phy@0 { | |
| 51 | + device_type = "ethernet-phy"; | |
| 52 | + reg = <1>; | |
| 53 | + }; | |
| 54 | + }; | |
| 55 | + }; | |
| @@ -3,7 +3,10 @@ · 2 unmodified lines | ||
| 3 | 3 | This binding is intended to represent MTK-EFUSE which is found in most Mediatek SOCs. |
| 4 | 4 | |
| 5 | 5 | Required properties: |
| 6 | −- compatible: should be "mediatek,mt8173-efuse" or "mediatek,efuse" | |
| 6 | +- compatible: should be | |
| 7 | + "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622 | |
| 8 | + "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623 | |
| 9 | + "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173 | |
| 7 | 10 | - reg: Should contain registers location and length |
| 8 | 11 | |
| 9 | 12 | = Data cells = |
| @@ -21,5 +21,4 @@ Example for i.MX28: · 20 unmodified lines | ||
| 21 | 21 | #size-cells = <1>; |
| 22 | 22 | reg = <0x8002c000 0x2000>; |
| 23 | 23 | clocks = <&clks 25>; |
| 24 | − status = "okay"; | |
| 25 | 24 | }; |
| @@ -464,7 +464,6 @@ Example 5: opp-supported-hw · 463 unmodified lines | ||
| 464 | 464 | |
| 465 | 465 | opp_table { |
| 466 | 466 | compatible = "operating-points-v2"; |
| 467 | − status = "okay"; | |
| 468 | 467 | opp-shared; |
| 469 | 468 | |
| 470 | 469 | opp-600000000 { |
| @@ -1,11 +1,11 @@ | ||
| 1 | 1 | * Freescale 83xx and 512x PCI bridges |
| 2 | 2 | |
| 3 | −Freescale 83xx and 512x SOCs include the same pci bridge core. | |
| 3 | +Freescale 83xx and 512x SOCs include the same PCI bridge core. | |
| 4 | 4 | |
| 5 | 5 | 83xx/512x specific notes: |
| 6 | 6 | - reg: should contain two address length tuples |
| 7 | − The first is for the internal pci bridge registers | |
| 8 | − The second is for the pci config space access registers | |
| 7 | + The first is for the internal PCI bridge registers | |
| 8 | + The second is for the PCI config space access registers | |
| 9 | 9 | |
| 10 | 10 | Example (MPC8313ERDB) |
| 11 | 11 | pci0: pci@e0008500 { |
| @@ -33,7 +33,6 @@ Example: · 32 unmodified lines | ||
| 33 | 33 | pcie0: pcie@d0070000 { |
| 34 | 34 | compatible = "marvell,armada-3700-pcie"; |
| 35 | 35 | device_type = "pci"; |
| 36 | − status = "disabled"; | |
| 37 | 36 | reg = <0 0xd0070000 0 0x20000>; |
| 38 | 37 | #address-cells = <3>; |
| 39 | 38 | #size-cells = <2>; |
| @@ -7,21 +7,21 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | "Txs": TX slave port region |
| 8 | 8 | "Cra": Control register access region |
| 9 | 9 | - interrupt-parent: interrupt source phandle. |
| 10 | −- interrupts: specifies the interrupt source of the parent interrupt controller. | |
| 11 | − The format of the interrupt specifier depends on the parent interrupt | |
| 12 | − controller. | |
| 10 | +- interrupts: specifies the interrupt source of the parent interrupt | |
| 11 | + controller. The format of the interrupt specifier depends | |
| 12 | + on the parent interrupt controller. | |
| 13 | 13 | - device_type: must be "pci" |
| 14 | 14 | - #address-cells: set to <3> |
| 15 | −- #size-cells: set to <2> | |
| 15 | +- #size-cells: set to <2> | |
| 16 | 16 | - #interrupt-cells: set to <1> |
| 17 | −- ranges: describes the translation of addresses for root ports and standard | |
| 18 | − PCI regions. | |
| 17 | +- ranges: describes the translation of addresses for root ports and | |
| 18 | + standard PCI regions. | |
| 19 | 19 | - interrupt-map-mask and interrupt-map: standard PCI properties to define the |
| 20 | 20 | mapping of the PCIe interface to interrupt numbers. |
| 21 | 21 | |
| 22 | 22 | Optional properties: |
| 23 | −- msi-parent: Link to the hardware entity that serves as the MSI controller for this PCIe | |
| 24 | − controller. | |
| 23 | +- msi-parent: Link to the hardware entity that serves as the MSI controller | |
| 24 | + for this PCIe controller. | |
| 25 | 25 | - bus-range: PCI bus numbers covered |
| 26 | 26 | |
| 27 | 27 | Example |
| @@ -45,5 +45,5 @@ Example · 17 unmodified lines | ||
| 45 | 45 | <0 0 0 3 &pcie_0 3>, |
| 46 | 46 | <0 0 0 4 &pcie_0 4>; |
| 47 | 47 | ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000 |
| 48 | − 0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>; | |
| 48 | + 0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>; | |
| 49 | 49 | }; |
| @@ -6,7 +6,7 @@ and thus inherits all the common properties defined in designware-pcie.txt. · 5 unmodified lines | ||
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: "axis,artpec6-pcie", "snps,dw-pcie" |
| 8 | 8 | - reg: base addresses and lengths of the PCIe controller (DBI), |
| 9 | − the phy controller, and configuration address space. | |
| 9 | + the PHY controller, and configuration address space. | |
| 10 | 10 | - reg-names: Must include the following entries: |
| 11 | 11 | - "dbi" |
| 12 | 12 | - "phy" |
| @@ -1,4 +1,4 @@ | ||
| 1 | −* Synopsys Designware PCIe interface | |
| 1 | +* Synopsys DesignWare PCIe interface | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: should contain "snps,dw-pcie" to identify the core. |
| @@ -17,29 +17,27 @@ RC mode: · 12 unmodified lines | ||
| 17 | 17 | properties to define the mapping of the PCIe interface to interrupt |
| 18 | 18 | numbers. |
| 19 | 19 | EP mode: |
| 20 | −- num-ib-windows: number of inbound address translation | |
| 21 | − windows | |
| 22 | −- num-ob-windows: number of outbound address translation | |
| 23 | − windows | |
| 20 | +- num-ib-windows: number of inbound address translation windows | |
| 21 | +- num-ob-windows: number of outbound address translation windows | |
| 24 | 22 | |
| 25 | 23 | Optional properties: |
| 26 | 24 | - num-lanes: number of lanes to use (this property should be specified unless |
| 27 | 25 | the link is brought already up in BIOS) |
| 28 | −- reset-gpio: gpio pin number of power good signal | |
| 26 | +- reset-gpio: GPIO pin number of power good signal | |
| 29 | 27 | - clocks: Must contain an entry for each entry in clock-names. |
| 30 | 28 | See ../clocks/clock-bindings.txt for details. |
| 31 | 29 | - clock-names: Must include the following entries: |
| 32 | 30 | - "pcie" |
| 33 | 31 | - "pcie_bus" |
| 34 | 32 | RC mode: |
| 35 | −- num-viewport: number of view ports configured in | |
| 36 | − hardware. If a platform does not specify it, the driver assumes 2. | |
| 37 | −- bus-range: PCI bus numbers covered (it is recommended | |
| 38 | − for new devicetrees to specify this property, to keep backwards | |
| 39 | − compatibility a range of 0x00-0xff is assumed if not present) | |
| 33 | +- num-viewport: number of view ports configured in hardware. If a platform | |
| 34 | + does not specify it, the driver assumes 2. | |
| 35 | +- bus-range: PCI bus numbers covered (it is recommended for new devicetrees | |
| 36 | + to specify this property, to keep backwards compatibility a range of | |
| 37 | + 0x00-0xff is assumed if not present) | |
| 38 | + | |
| 40 | 39 | EP mode: |
| 41 | −- max-functions: maximum number of functions that can be | |
| 42 | − configured | |
| 40 | +- max-functions: maximum number of functions that can be configured | |
| 43 | 41 | |
| 44 | 42 | Example configuration: |
| 45 | 43 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | * Freescale i.MX6 PCIe interface |
| 2 | 2 | |
| 3 | −This PCIe host controller is based on the Synopsis Designware PCIe IP | |
| 3 | +This PCIe host controller is based on the Synopsys DesignWare PCIe IP | |
| 4 | 4 | and thus inherits all the common properties defined in designware-pcie.txt. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| @@ -1,7 +1,7 @@ | ||
| 1 | 1 | HiSilicon Hip05 and Hip06 PCIe host bridge DT description |
| 2 | 2 | |
| 3 | −HiSilicon PCIe host controller is based on Designware PCI core. | |
| 4 | −It shares common functions with PCIe Designware core driver and inherits | |
| 3 | +HiSilicon PCIe host controller is based on the Synopsys DesignWare PCI core. | |
| 4 | +It shares common functions with the PCIe DesignWare core driver and inherits | |
| 5 | 5 | common properties defined in |
| 6 | 6 | Documentation/devicetree/bindings/pci/designware-pci.txt. |
| 7 | 7 | |
| @@ -40,7 +40,6 @@ Hip05 Example (note that Hip06 is the same except compatible): · 32 unmodified lines | ||
| 40 | 40 | 0x0 0 0 2 &mbigen_pcie 2 11 |
| 41 | 41 | 0x0 0 0 3 &mbigen_pcie 3 12 |
| 42 | 42 | 0x0 0 0 4 &mbigen_pcie 4 13>; |
| 43 | − status = "ok"; | |
| 44 | 43 | }; |
| 45 | 44 | |
| 46 | 45 | HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description. |
| @@ -83,5 +82,4 @@ Example: · 36 unmodified lines | ||
| 83 | 82 | 0x0 0 0 2 &mbigen_pcie0 650 4 |
| 84 | 83 | 0x0 0 0 3 &mbigen_pcie0 650 4 |
| 85 | 84 | 0x0 0 0 4 &mbigen_pcie0 650 4>; |
| 86 | − status = "ok"; | |
| 87 | 85 | }; |
| @@ -1,8 +1,8 @@ | ||
| 1 | 1 | HiSilicon Kirin SoCs PCIe host DT description |
| 2 | 2 | |
| 3 | −Kirin PCIe host controller is based on Designware PCI core. | |
| 4 | −It shares common functions with PCIe Designware core driver | |
| 5 | −and inherits common properties defined in | |
| 3 | +Kirin PCIe host controller is based on the Synopsys DesignWare PCI core. | |
| 4 | +It shares common functions with the PCIe DesignWare core driver and | |
| 5 | +inherits common properties defined in | |
| 6 | 6 | Documentation/devicetree/bindings/pci/designware-pci.txt. |
| 7 | 7 | |
| 8 | 8 | Additional properties are described here: |
| @@ -16,7 +16,7 @@ Required properties · 7 unmodified lines | ||
| 16 | 16 | "apb": apb Ctrl register defined by Kirin; |
| 17 | 17 | "phy": apb PHY register defined by Kirin; |
| 18 | 18 | "config": PCIe configuration space registers. |
| 19 | −- reset-gpios: The gpio to generate PCIe perst assert and deassert signal. | |
| 19 | +- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal. | |
| 20 | 20 | |
| 21 | 21 | Optional properties: |
| 22 | 22 | |
| @@ -15,8 +15,10 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | - compatible: should contain the platform identifier such as: |
| 16 | 16 | "fsl,ls1021a-pcie", "snps,dw-pcie" |
| 17 | 17 | "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie" |
| 18 | + "fsl,ls2088a-pcie" | |
| 19 | + "fsl,ls1088a-pcie" | |
| 18 | 20 | "fsl,ls1046a-pcie" |
| 19 | −- reg: base addresses and lengths of the PCIe controller | |
| 21 | +- reg: base addresses and lengths of the PCIe controller register blocks. | |
| 20 | 22 | - interrupts: A list of interrupt outputs of the controller. Must contain an |
| 21 | 23 | entry for each entry in the interrupt-names property. |
| 22 | 24 | - interrupt-names: Must include the following entries: |
| @@ -1,130 +0,0 @@ | ||
| 1 | −MediaTek Gen2 PCIe controller which is available on MT7623 series SoCs | |
| 2 | − | |
| 3 | −PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root | |
| 4 | −ports supports a Gen2 1-lane Link and has PIPE interface to PHY. | |
| 5 | − | |
| 6 | −Required properties: | |
| 7 | −- compatible: Should contain "mediatek,mt7623-pcie". | |
| 8 | −- device_type: Must be "pci" | |
| 9 | −- reg: Base addresses and lengths of the PCIe controller. | |
| 10 | −- #address-cells: Address representation for root ports (must be 3) | |
| 11 | −- #size-cells: Size representation for root ports (must be 2) | |
| 12 | −- #interrupt-cells: Size representation for interrupts (must be 1) | |
| 13 | −- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties | |
| 14 | − Please refer to the standard PCI bus binding document for a more detailed | |
| 15 | − explanation. | |
| 16 | −- clocks: Must contain an entry for each entry in clock-names. | |
| 17 | − See ../clocks/clock-bindings.txt for details. | |
| 18 | −- clock-names: Must include the following entries: | |
| 19 | − - free_ck :for reference clock of PCIe subsys | |
| 20 | − - sys_ck0 :for clock of Port0 | |
| 21 | − - sys_ck1 :for clock of Port1 | |
| 22 | − - sys_ck2 :for clock of Port2 | |
| 23 | −- resets: Must contain an entry for each entry in reset-names. | |
| 24 | − See ../reset/reset.txt for details. | |
| 25 | −- reset-names: Must include the following entries: | |
| 26 | − - pcie-rst0 :port0 reset | |
| 27 | − - pcie-rst1 :port1 reset | |
| 28 | − - pcie-rst2 :port2 reset | |
| 29 | −- phys: List of PHY specifiers (used by generic PHY framework). | |
| 30 | −- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the | |
| 31 | − number of PHYs as specified in *phys* property. | |
| 32 | −- power-domains: A phandle and power domain specifier pair to the power domain | |
| 33 | − which is responsible for collapsing and restoring power to the peripheral. | |
| 34 | −- bus-range: Range of bus numbers associated with this controller. | |
| 35 | −- ranges: Ranges for the PCI memory and I/O regions. | |
| 36 | − | |
| 37 | −In addition, the device tree node must have sub-nodes describing each | |
| 38 | −PCIe port interface, having the following mandatory properties: | |
| 39 | − | |
| 40 | −Required properties: | |
| 41 | −- device_type: Must be "pci" | |
| 42 | −- reg: Only the first four bytes are used to refer to the correct bus number | |
| 43 | − and device number. | |
| 44 | −- #address-cells: Must be 3 | |
| 45 | −- #size-cells: Must be 2 | |
| 46 | −- #interrupt-cells: Must be 1 | |
| 47 | −- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties | |
| 48 | − Please refer to the standard PCI bus binding document for a more detailed | |
| 49 | − explanation. | |
| 50 | −- ranges: Sub-ranges distributed from the PCIe controller node. An empty | |
| 51 | − property is sufficient. | |
| 52 | −- num-lanes: Number of lanes to use for this port. | |
| 53 | − | |
| 54 | −Examples: | |
| 55 | − | |
| 56 | − hifsys: syscon@1a000000 { | |
| 57 | − compatible = "mediatek,mt7623-hifsys", | |
| 58 | − "mediatek,mt2701-hifsys", | |
| 59 | − "syscon"; | |
| 60 | − reg = <0 0x1a000000 0 0x1000>; | |
| 61 | − #clock-cells = <1>; | |
| 62 | − #reset-cells = <1>; | |
| 63 | − }; | |
| 64 | − | |
| 65 | − pcie: pcie-controller@1a140000 { | |
| 66 | − compatible = "mediatek,mt7623-pcie"; | |
| 67 | − device_type = "pci"; | |
| 68 | − reg = <0 0x1a140000 0 0x1000>, /* PCIe shared registers */ | |
| 69 | − <0 0x1a142000 0 0x1000>, /* Port0 registers */ | |
| 70 | − <0 0x1a143000 0 0x1000>, /* Port1 registers */ | |
| 71 | − <0 0x1a144000 0 0x1000>; /* Port2 registers */ | |
| 72 | − #address-cells = <3>; | |
| 73 | − #size-cells = <2>; | |
| 74 | − #interrupt-cells = <1>; | |
| 75 | − interrupt-map-mask = <0xf800 0 0 0>; | |
| 76 | − interrupt-map = <0x0000 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>, | |
| 77 | − <0x0800 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>, | |
| 78 | − <0x1000 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>; | |
| 79 | − clocks = <&topckgen CLK_TOP_ETHIF_SEL>, | |
| 80 | − <&hifsys CLK_HIFSYS_PCIE0>, | |
| 81 | − <&hifsys CLK_HIFSYS_PCIE1>, | |
| 82 | − <&hifsys CLK_HIFSYS_PCIE2>; | |
| 83 | − clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2"; | |
| 84 | − resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>, | |
| 85 | − <&hifsys MT2701_HIFSYS_PCIE1_RST>, | |
| 86 | − <&hifsys MT2701_HIFSYS_PCIE2_RST>; | |
| 87 | − reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2"; | |
| 88 | − phys = <&pcie0_phy>, <&pcie1_phy>, <&pcie2_phy>; | |
| 89 | − phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2"; | |
| 90 | − power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>; | |
| 91 | − bus-range = <0x00 0xff>; | |
| 92 | − ranges = <0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000 /* I/O space */ | |
| 93 | − 0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>; /* memory space */ | |
| 94 | − | |
| 95 | − pcie@0,0 { | |
| 96 | − device_type = "pci"; | |
| 97 | − reg = <0x0000 0 0 0 0>; | |
| 98 | − #address-cells = <3>; | |
| 99 | − #size-cells = <2>; | |
| 100 | − #interrupt-cells = <1>; | |
| 101 | − interrupt-map-mask = <0 0 0 0>; | |
| 102 | − interrupt-map = <0 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>; | |
| 103 | − ranges; | |
| 104 | − num-lanes = <1>; | |
| 105 | − }; | |
| 106 | − | |
| 107 | − pcie@1,0 { | |
| 108 | − device_type = "pci"; | |
| 109 | − reg = <0x0800 0 0 0 0>; | |
| 110 | − #address-cells = <3>; | |
| 111 | − #size-cells = <2>; | |
| 112 | − #interrupt-cells = <1>; | |
| 113 | − interrupt-map-mask = <0 0 0 0>; | |
| 114 | − interrupt-map = <0 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>; | |
| 115 | − ranges; | |
| 116 | − num-lanes = <1>; | |
| 117 | − }; | |
| 118 | − | |
| 119 | − pcie@2,0 { | |
| 120 | − device_type = "pci"; | |
| 121 | − reg = <0x1000 0 0 0 0>; | |
| 122 | − #address-cells = <3>; | |
| 123 | − #size-cells = <2>; | |
| 124 | − #interrupt-cells = <1>; | |
| 125 | − interrupt-map-mask = <0 0 0 0>; | |
| 126 | − interrupt-map = <0 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>; | |
| 127 | − ranges; | |
| 128 | − num-lanes = <1>; | |
| 129 | − }; | |
| 130 | − }; | |
| @@ -0,0 +1,284 @@ | ||
| 1 | +MediaTek Gen2 PCIe controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should contain one of the following strings: | |
| 5 | + "mediatek,mt2701-pcie" | |
| 6 | + "mediatek,mt2712-pcie" | |
| 7 | + "mediatek,mt7622-pcie" | |
| 8 | + "mediatek,mt7623-pcie" | |
| 9 | +- device_type: Must be "pci" | |
| 10 | +- reg: Base addresses and lengths of the PCIe subsys and root ports. | |
| 11 | +- reg-names: Names of the above areas to use during resource lookup. | |
| 12 | +- #address-cells: Address representation for root ports (must be 3) | |
| 13 | +- #size-cells: Size representation for root ports (must be 2) | |
| 14 | +- clocks: Must contain an entry for each entry in clock-names. | |
| 15 | + See ../clocks/clock-bindings.txt for details. | |
| 16 | +- clock-names: | |
| 17 | + Mandatory entries: | |
| 18 | + - sys_ckN :transaction layer and data link layer clock | |
| 19 | + Required entries for MT2701/MT7623: | |
| 20 | + - free_ck :for reference clock of PCIe subsys | |
| 21 | + Required entries for MT2712/MT7622: | |
| 22 | + - ahb_ckN :AHB slave interface operating clock for CSR access and RC | |
| 23 | + initiated MMIO access | |
| 24 | + Required entries for MT7622: | |
| 25 | + - axi_ckN :application layer MMIO channel operating clock | |
| 26 | + - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when | |
| 27 | + pcie_mac_ck/pcie_pipe_ck is turned off | |
| 28 | + - obff_ckN :OBFF functional block operating clock | |
| 29 | + - pipe_ckN :LTSSM and PHY/MAC layer operating clock | |
| 30 | + where N starting from 0 to one less than the number of root ports. | |
| 31 | +- phys: List of PHY specifiers (used by generic PHY framework). | |
| 32 | +- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the | |
| 33 | + number of PHYs as specified in *phys* property. | |
| 34 | +- power-domains: A phandle and power domain specifier pair to the power domain | |
| 35 | + which is responsible for collapsing and restoring power to the peripheral. | |
| 36 | +- bus-range: Range of bus numbers associated with this controller. | |
| 37 | +- ranges: Ranges for the PCI memory and I/O regions. | |
| 38 | + | |
| 39 | +Required properties for MT7623/MT2701: | |
| 40 | +- #interrupt-cells: Size representation for interrupts (must be 1) | |
| 41 | +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties | |
| 42 | + Please refer to the standard PCI bus binding document for a more detailed | |
| 43 | + explanation. | |
| 44 | +- resets: Must contain an entry for each entry in reset-names. | |
| 45 | + See ../reset/reset.txt for details. | |
| 46 | +- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the | |
| 47 | + number of root ports. | |
| 48 | + | |
| 49 | +Required properties for MT2712/MT7622: | |
| 50 | +-interrupts: A list of interrupt outputs of the controller, must have one | |
| 51 | + entry for each PCIe port | |
| 52 | + | |
| 53 | +In addition, the device tree node must have sub-nodes describing each | |
| 54 | +PCIe port interface, having the following mandatory properties: | |
| 55 | + | |
| 56 | +Required properties: | |
| 57 | +- device_type: Must be "pci" | |
| 58 | +- reg: Only the first four bytes are used to refer to the correct bus number | |
| 59 | + and device number. | |
| 60 | +- #address-cells: Must be 3 | |
| 61 | +- #size-cells: Must be 2 | |
| 62 | +- #interrupt-cells: Must be 1 | |
| 63 | +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties | |
| 64 | + Please refer to the standard PCI bus binding document for a more detailed | |
| 65 | + explanation. | |
| 66 | +- ranges: Sub-ranges distributed from the PCIe controller node. An empty | |
| 67 | + property is sufficient. | |
| 68 | +- num-lanes: Number of lanes to use for this port. | |
| 69 | + | |
| 70 | +Examples for MT7623: | |
| 71 | + | |
| 72 | + hifsys: syscon@1a000000 { | |
| 73 | + compatible = "mediatek,mt7623-hifsys", | |
| 74 | + "mediatek,mt2701-hifsys", | |
| 75 | + "syscon"; | |
| 76 | + reg = <0 0x1a000000 0 0x1000>; | |
| 77 | + #clock-cells = <1>; | |
| 78 | + #reset-cells = <1>; | |
| 79 | + }; | |
| 80 | + | |
| 81 | + pcie: pcie-controller@1a140000 { | |
| 82 | + compatible = "mediatek,mt7623-pcie"; | |
| 83 | + device_type = "pci"; | |
| 84 | + reg = <0 0x1a140000 0 0x1000>, /* PCIe shared registers */ | |
| 85 | + <0 0x1a142000 0 0x1000>, /* Port0 registers */ | |
| 86 | + <0 0x1a143000 0 0x1000>, /* Port1 registers */ | |
| 87 | + <0 0x1a144000 0 0x1000>; /* Port2 registers */ | |
| 88 | + reg-names = "subsys", "port0", "port1", "port2"; | |
| 89 | + #address-cells = <3>; | |
| 90 | + #size-cells = <2>; | |
| 91 | + #interrupt-cells = <1>; | |
| 92 | + interrupt-map-mask = <0xf800 0 0 0>; | |
| 93 | + interrupt-map = <0x0000 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>, | |
| 94 | + <0x0800 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>, | |
| 95 | + <0x1000 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>; | |
| 96 | + clocks = <&topckgen CLK_TOP_ETHIF_SEL>, | |
| 97 | + <&hifsys CLK_HIFSYS_PCIE0>, | |
| 98 | + <&hifsys CLK_HIFSYS_PCIE1>, | |
| 99 | + <&hifsys CLK_HIFSYS_PCIE2>; | |
| 100 | + clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2"; | |
| 101 | + resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>, | |
| 102 | + <&hifsys MT2701_HIFSYS_PCIE1_RST>, | |
| 103 | + <&hifsys MT2701_HIFSYS_PCIE2_RST>; | |
| 104 | + reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2"; | |
| 105 | + phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>, | |
| 106 | + <&pcie2_phy PHY_TYPE_PCIE>; | |
| 107 | + phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2"; | |
| 108 | + power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>; | |
| 109 | + bus-range = <0x00 0xff>; | |
| 110 | + ranges = <0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000 /* I/O space */ | |
| 111 | + 0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>; /* memory space */ | |
| 112 | + | |
| 113 | + pcie@0,0 { | |
| 114 | + device_type = "pci"; | |
| 115 | + reg = <0x0000 0 0 0 0>; | |
| 116 | + #address-cells = <3>; | |
| 117 | + #size-cells = <2>; | |
| 118 | + #interrupt-cells = <1>; | |
| 119 | + interrupt-map-mask = <0 0 0 0>; | |
| 120 | + interrupt-map = <0 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>; | |
| 121 | + ranges; | |
| 122 | + num-lanes = <1>; | |
| 123 | + }; | |
| 124 | + | |
| 125 | + pcie@1,0 { | |
| 126 | + device_type = "pci"; | |
| 127 | + reg = <0x0800 0 0 0 0>; | |
| 128 | + #address-cells = <3>; | |
| 129 | + #size-cells = <2>; | |
| 130 | + #interrupt-cells = <1>; | |
| 131 | + interrupt-map-mask = <0 0 0 0>; | |
| 132 | + interrupt-map = <0 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>; | |
| 133 | + ranges; | |
| 134 | + num-lanes = <1>; | |
| 135 | + }; | |
| 136 | + | |
| 137 | + pcie@2,0 { | |
| 138 | + device_type = "pci"; | |
| 139 | + reg = <0x1000 0 0 0 0>; | |
| 140 | + #address-cells = <3>; | |
| 141 | + #size-cells = <2>; | |
| 142 | + #interrupt-cells = <1>; | |
| 143 | + interrupt-map-mask = <0 0 0 0>; | |
| 144 | + interrupt-map = <0 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>; | |
| 145 | + ranges; | |
| 146 | + num-lanes = <1>; | |
| 147 | + }; | |
| 148 | + }; | |
| 149 | + | |
| 150 | +Examples for MT2712: | |
| 151 | + pcie: pcie@11700000 { | |
| 152 | + compatible = "mediatek,mt2712-pcie"; | |
| 153 | + device_type = "pci"; | |
| 154 | + reg = <0 0x11700000 0 0x1000>, | |
| 155 | + <0 0x112ff000 0 0x1000>; | |
| 156 | + reg-names = "port0", "port1"; | |
| 157 | + #address-cells = <3>; | |
| 158 | + #size-cells = <2>; | |
| 159 | + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, | |
| 160 | + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; | |
| 161 | + clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>, | |
| 162 | + <&topckgen CLK_TOP_PE2_MAC_P1_SEL>, | |
| 163 | + <&pericfg CLK_PERI_PCIE0>, | |
| 164 | + <&pericfg CLK_PERI_PCIE1>; | |
| 165 | + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1"; | |
| 166 | + phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>; | |
| 167 | + phy-names = "pcie-phy0", "pcie-phy1"; | |
| 168 | + bus-range = <0x00 0xff>; | |
| 169 | + ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>; | |
| 170 | + | |
| 171 | + pcie0: pcie@0,0 { | |
| 172 | + device_type = "pci"; | |
| 173 | + reg = <0x0000 0 0 0 0>; | |
| 174 | + #address-cells = <3>; | |
| 175 | + #size-cells = <2>; | |
| 176 | + #interrupt-cells = <1>; | |
| 177 | + ranges; | |
| 178 | + num-lanes = <1>; | |
| 179 | + interrupt-map-mask = <0 0 0 7>; | |
| 180 | + interrupt-map = <0 0 0 1 &pcie_intc0 0>, | |
| 181 | + <0 0 0 2 &pcie_intc0 1>, | |
| 182 | + <0 0 0 3 &pcie_intc0 2>, | |
| 183 | + <0 0 0 4 &pcie_intc0 3>; | |
| 184 | + pcie_intc0: interrupt-controller { | |
| 185 | + interrupt-controller; | |
| 186 | + #address-cells = <0>; | |
| 187 | + #interrupt-cells = <1>; | |
| 188 | + }; | |
| 189 | + }; | |
| 190 | + | |
| 191 | + pcie1: pcie@1,0 { | |
| 192 | + device_type = "pci"; | |
| 193 | + reg = <0x0800 0 0 0 0>; | |
| 194 | + #address-cells = <3>; | |
| 195 | + #size-cells = <2>; | |
| 196 | + #interrupt-cells = <1>; | |
| 197 | + ranges; | |
| 198 | + num-lanes = <1>; | |
| 199 | + interrupt-map-mask = <0 0 0 7>; | |
| 200 | + interrupt-map = <0 0 0 1 &pcie_intc1 0>, | |
| 201 | + <0 0 0 2 &pcie_intc1 1>, | |
| 202 | + <0 0 0 3 &pcie_intc1 2>, | |
| 203 | + <0 0 0 4 &pcie_intc1 3>; | |
| 204 | + pcie_intc1: interrupt-controller { | |
| 205 | + interrupt-controller; | |
| 206 | + #address-cells = <0>; | |
| 207 | + #interrupt-cells = <1>; | |
| 208 | + }; | |
| 209 | + }; | |
| 210 | + }; | |
| 211 | + | |
| 212 | +Examples for MT7622: | |
| 213 | + pcie: pcie@1a140000 { | |
| 214 | + compatible = "mediatek,mt7622-pcie"; | |
| 215 | + device_type = "pci"; | |
| 216 | + reg = <0 0x1a140000 0 0x1000>, | |
| 217 | + <0 0x1a143000 0 0x1000>, | |
| 218 | + <0 0x1a145000 0 0x1000>; | |
| 219 | + reg-names = "subsys", "port0", "port1"; | |
| 220 | + #address-cells = <3>; | |
| 221 | + #size-cells = <2>; | |
| 222 | + interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>, | |
| 223 | + <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>; | |
| 224 | + clocks = <&pciesys CLK_PCIE_P0_MAC_EN>, | |
| 225 | + <&pciesys CLK_PCIE_P1_MAC_EN>, | |
| 226 | + <&pciesys CLK_PCIE_P0_AHB_EN>, | |
| 227 | + <&pciesys CLK_PCIE_P1_AHB_EN>, | |
| 228 | + <&pciesys CLK_PCIE_P0_AUX_EN>, | |
| 229 | + <&pciesys CLK_PCIE_P1_AUX_EN>, | |
| 230 | + <&pciesys CLK_PCIE_P0_AXI_EN>, | |
| 231 | + <&pciesys CLK_PCIE_P1_AXI_EN>, | |
| 232 | + <&pciesys CLK_PCIE_P0_OBFF_EN>, | |
| 233 | + <&pciesys CLK_PCIE_P1_OBFF_EN>, | |
| 234 | + <&pciesys CLK_PCIE_P0_PIPE_EN>, | |
| 235 | + <&pciesys CLK_PCIE_P1_PIPE_EN>; | |
| 236 | + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1", | |
| 237 | + "aux_ck0", "aux_ck1", "axi_ck0", "axi_ck1", | |
| 238 | + "obff_ck0", "obff_ck1", "pipe_ck0", "pipe_ck1"; | |
| 239 | + phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>; | |
| 240 | + phy-names = "pcie-phy0", "pcie-phy1"; | |
| 241 | + power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>; | |
| 242 | + bus-range = <0x00 0xff>; | |
| 243 | + ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>; | |
| 244 | + | |
| 245 | + pcie0: pcie@0,0 { | |
| 246 | + device_type = "pci"; | |
| 247 | + reg = <0x0000 0 0 0 0>; | |
| 248 | + #address-cells = <3>; | |
| 249 | + #size-cells = <2>; | |
| 250 | + #interrupt-cells = <1>; | |
| 251 | + ranges; | |
| 252 | + num-lanes = <1>; | |
| 253 | + interrupt-map-mask = <0 0 0 7>; | |
| 254 | + interrupt-map = <0 0 0 1 &pcie_intc0 0>, | |
| 255 | + <0 0 0 2 &pcie_intc0 1>, | |
| 256 | + <0 0 0 3 &pcie_intc0 2>, | |
| 257 | + <0 0 0 4 &pcie_intc0 3>; | |
| 258 | + pcie_intc0: interrupt-controller { | |
| 259 | + interrupt-controller; | |
| 260 | + #address-cells = <0>; | |
| 261 | + #interrupt-cells = <1>; | |
| 262 | + }; | |
| 263 | + }; | |
| 264 | + | |
| 265 | + pcie1: pcie@1,0 { | |
| 266 | + device_type = "pci"; | |
| 267 | + reg = <0x0800 0 0 0 0>; | |
| 268 | + #address-cells = <3>; | |
| 269 | + #size-cells = <2>; | |
| 270 | + #interrupt-cells = <1>; | |
| 271 | + ranges; | |
| 272 | + num-lanes = <1>; | |
| 273 | + interrupt-map-mask = <0 0 0 7>; | |
| 274 | + interrupt-map = <0 0 0 1 &pcie_intc1 0>, | |
| 275 | + <0 0 0 2 &pcie_intc1 1>, | |
| 276 | + <0 0 0 3 &pcie_intc1 2>, | |
| 277 | + <0 0 0 4 &pcie_intc1 3>; | |
| 278 | + pcie_intc1: interrupt-controller { | |
| 279 | + interrupt-controller; | |
| 280 | + #address-cells = <0>; | |
| 281 | + #interrupt-cells = <1>; | |
| 282 | + }; | |
| 283 | + }; | |
| 284 | + }; | |
| @@ -77,7 +77,7 @@ and the following optional properties: · 76 unmodified lines | ||
| 77 | 77 | - marvell,pcie-lane: the physical PCIe lane number, for ports having |
| 78 | 78 | multiple lanes. If this property is not found, we assume that the |
| 79 | 79 | value is 0. |
| 80 | −- reset-gpios: optional gpio to PERST# | |
| 80 | +- reset-gpios: optional GPIO to PERST# | |
| 81 | 81 | - reset-delay-us: delay in us to wait after reset de-assertion, if not |
| 82 | 82 | specified will default to 100ms, as required by the PCIe specification. |
| 83 | 83 | |
| @@ -85,7 +85,6 @@ Example: · 1 unmodified line | ||
| 85 | 85 | |
| 86 | 86 | pcie-controller { |
| 87 | 87 | compatible = "marvell,armada-xp-pcie"; |
| 88 | − status = "disabled"; | |
| 89 | 88 | device_type = "pci"; |
| 90 | 89 | |
| 91 | 90 | #address-cells = <3>; |
| @@ -147,7 +146,6 @@ pcie-controller { · 55 unmodified lines | ||
| 147 | 146 | /* wait 20ms for device settle after reset deassertion */ |
| 148 | 147 | reset-delay-us = <20000>; |
| 149 | 148 | clocks = <&gateclk 5>; |
| 150 | − status = "disabled"; | |
| 151 | 149 | }; |
| 152 | 150 | |
| 153 | 151 | pcie@2,0 { |
| @@ -164,7 +162,6 @@ pcie-controller { · 10 unmodified lines | ||
| 164 | 162 | marvell,pcie-port = <0>; |
| 165 | 163 | marvell,pcie-lane = <1>; |
| 166 | 164 | clocks = <&gateclk 6>; |
| 167 | − status = "disabled"; | |
| 168 | 165 | }; |
| 169 | 166 | |
| 170 | 167 | pcie@3,0 { |
| @@ -181,7 +178,6 @@ pcie-controller { · 10 unmodified lines | ||
| 181 | 178 | marvell,pcie-port = <0>; |
| 182 | 179 | marvell,pcie-lane = <2>; |
| 183 | 180 | clocks = <&gateclk 7>; |
| 184 | − status = "disabled"; | |
| 185 | 181 | }; |
| 186 | 182 | |
| 187 | 183 | pcie@4,0 { |
| @@ -198,7 +194,6 @@ pcie-controller { · 10 unmodified lines | ||
| 198 | 194 | marvell,pcie-port = <0>; |
| 199 | 195 | marvell,pcie-lane = <3>; |
| 200 | 196 | clocks = <&gateclk 8>; |
| 201 | − status = "disabled"; | |
| 202 | 197 | }; |
| 203 | 198 | |
| 204 | 199 | pcie@5,0 { |
| @@ -215,7 +210,6 @@ pcie-controller { · 10 unmodified lines | ||
| 215 | 210 | marvell,pcie-port = <1>; |
| 216 | 211 | marvell,pcie-lane = <0>; |
| 217 | 212 | clocks = <&gateclk 9>; |
| 218 | − status = "disabled"; | |
| 219 | 213 | }; |
| 220 | 214 | |
| 221 | 215 | pcie@6,0 { |
| @@ -232,7 +226,6 @@ pcie-controller { · 10 unmodified lines | ||
| 232 | 226 | marvell,pcie-port = <1>; |
| 233 | 227 | marvell,pcie-lane = <1>; |
| 234 | 228 | clocks = <&gateclk 10>; |
| 235 | − status = "disabled"; | |
| 236 | 229 | }; |
| 237 | 230 | |
| 238 | 231 | pcie@7,0 { |
| @@ -249,7 +242,6 @@ pcie-controller { · 10 unmodified lines | ||
| 249 | 242 | marvell,pcie-port = <1>; |
| 250 | 243 | marvell,pcie-lane = <2>; |
| 251 | 244 | clocks = <&gateclk 11>; |
| 252 | − status = "disabled"; | |
| 253 | 245 | }; |
| 254 | 246 | |
| 255 | 247 | pcie@8,0 { |
| @@ -266,7 +258,6 @@ pcie-controller { · 10 unmodified lines | ||
| 266 | 258 | marvell,pcie-port = <1>; |
| 267 | 259 | marvell,pcie-lane = <3>; |
| 268 | 260 | clocks = <&gateclk 12>; |
| 269 | − status = "disabled"; | |
| 270 | 261 | }; |
| 271 | 262 | |
| 272 | 263 | pcie@9,0 { |
| @@ -283,10 +274,9 @@ pcie-controller { · 10 unmodified lines | ||
| 283 | 274 | marvell,pcie-port = <2>; |
| 284 | 275 | marvell,pcie-lane = <0>; |
| 285 | 276 | clocks = <&gateclk 26>; |
| 286 | − status = "disabled"; | |
| 287 | 277 | }; |
| 288 | 278 | |
| 289 | − pcie@10,0 { | |
| 279 | + pcie@a,0 { | |
| 290 | 280 | device_type = "pci"; |
| 291 | 281 | assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; |
| 292 | 282 | reg = <0x5000 0 0 0 0>; |
| @@ -300,6 +290,5 @@ pcie-controller { · 7 unmodified lines | ||
| 300 | 290 | marvell,pcie-port = <3>; |
| 301 | 291 | marvell,pcie-lane = <0>; |
| 302 | 292 | clocks = <&gateclk 27>; |
| 303 | − status = "disabled"; | |
| 304 | 293 | }; |
| 305 | 294 | }; |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | * Marvell Armada 7K/8K PCIe interface |
| 2 | 2 | |
| 3 | −This PCIe host controller is based on the Synopsis Designware PCIe IP | |
| 3 | +This PCIe host controller is based on the Synopsys DesignWare PCIe IP | |
| 4 | 4 | and thus inherits all the common properties defined in designware-pcie.txt. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| @@ -34,5 +34,4 @@ Example: · 27 unmodified lines | ||
| 34 | 34 | interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; |
| 35 | 35 | num-lanes = <1>; |
| 36 | 36 | clocks = <&cpm_syscon0 1 13>; |
| 37 | − status = "disabled"; | |
| 38 | 37 | }; |
| @@ -1,12 +1,12 @@ | ||
| 1 | 1 | TI Keystone PCIe interface |
| 2 | 2 | |
| 3 | −Keystone PCI host Controller is based on Designware PCI h/w version 3.65. | |
| 4 | −It shares common functions with PCIe Designware core driver and inherit | |
| 5 | −common properties defined in | |
| 3 | +Keystone PCI host Controller is based on the Synopsys DesignWare PCI | |
| 4 | +hardware version 3.65. It shares common functions with the PCIe DesignWare | |
| 5 | +core driver and inherits common properties defined in | |
| 6 | 6 | Documentation/devicetree/bindings/pci/designware-pci.txt |
| 7 | 7 | |
| 8 | 8 | Please refer to Documentation/devicetree/bindings/pci/designware-pci.txt |
| 9 | −for the details of Designware DT bindings. Additional properties are | |
| 9 | +for the details of DesignWare DT bindings. Additional properties are | |
| 10 | 10 | described here as well as properties that are not applicable. |
| 11 | 11 | |
| 12 | 12 | Required Properties:- |
| @@ -52,13 +52,12 @@ pcie_intc: Interrupt controller device node for Legacy IRQ chip · 39 unmodified lines | ||
| 52 | 52 | }; |
| 53 | 53 | |
| 54 | 54 | Optional properties:- |
| 55 | − phys: phandle to Generic Keystone SerDes phy for PCI | |
| 56 | − phy-names: name of the Generic Keystine SerDes phy for PCI | |
| 55 | + phys: phandle to generic Keystone SerDes PHY for PCI | |
| 56 | + phy-names: name of the generic Keystone SerDes PHY for PCI | |
| 57 | 57 | - If boot loader already does PCI link establishment, then phys and |
| 58 | 58 | phy-names shouldn't be present. |
| 59 | 59 | interrupts: platform interrupt for error interrupts. |
| 60 | 60 | |
| 61 | −Designware DT Properties not applicable for Keystone PCI | |
| 61 | +DesignWare DT Properties not applicable for Keystone PCI | |
| 62 | 62 | |
| 63 | 63 | 1. pcie_bus clock-names not used. Instead, a phandle to phys is used. |
| 64 | − | |
| @@ -6,11 +6,14 @@ AHB. There is one bridge instance per USB port connected to the internal · 5 unmodified lines | ||
| 6 | 6 | OHCI and EHCI controllers. |
| 7 | 7 | |
| 8 | 8 | Required properties: |
| 9 | −- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC; | |
| 9 | +- compatible: "renesas,pci-r8a7743" for the R8A7743 SoC; | |
| 10 | + "renesas,pci-r8a7745" for the R8A7745 SoC; | |
| 11 | + "renesas,pci-r8a7790" for the R8A7790 SoC; | |
| 10 | 12 | "renesas,pci-r8a7791" for the R8A7791 SoC; |
| 11 | 13 | "renesas,pci-r8a7793" for the R8A7793 SoC; |
| 12 | 14 | "renesas,pci-r8a7794" for the R8A7794 SoC; |
| 13 | − "renesas,pci-rcar-gen2" for a generic R-Car Gen2 compatible device | |
| 15 | + "renesas,pci-rcar-gen2" for a generic R-Car Gen2 or | |
| 16 | + RZ/G1 compatible device. | |
| 14 | 17 | |
| 15 | 18 | |
| 16 | 19 | When compatible with the generic version, nodes must list the |
| @@ -1,12 +1,12 @@ | ||
| 1 | 1 | PCI bus bridges have standardized Device Tree bindings: |
| 2 | 2 | |
| 3 | 3 | PCI Bus Binding to: IEEE Std 1275-1994 |
| 4 | −http://www.firmware.org/1275/bindings/pci/pci2_1.pdf | |
| 4 | +http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf | |
| 5 | 5 | |
| 6 | 6 | And for the interrupt mapping part: |
| 7 | 7 | |
| 8 | 8 | Open Firmware Recommended Practice: Interrupt Mapping |
| 9 | −http://www.firmware.org/1275/practice/imap/imap0_9d.pdf | |
| 9 | +http://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf | |
| 10 | 10 | |
| 11 | 11 | Additionally to the properties specified in the above standards a host bridge |
| 12 | 12 | driver implementation may support the following properties: |
| @@ -9,6 +9,7 @@ · 8 unmodified lines | ||
| 9 | 9 | - "qcom,pcie-apq8084" for apq8084 |
| 10 | 10 | - "qcom,pcie-msm8996" for msm8996 or apq8096 |
| 11 | 11 | - "qcom,pcie-ipq4019" for ipq4019 |
| 12 | + - "qcom,pcie-ipq8074" for ipq8074 | |
| 12 | 13 | |
| 13 | 14 | - reg: |
| 14 | 15 | Usage: required |
| @@ -20,7 +21,7 @@ · 5 unmodified lines | ||
| 20 | 21 | Value type: <stringlist> |
| 21 | 22 | Definition: Must include the following entries |
| 22 | 23 | - "parf" Qualcomm specific registers |
| 23 | − - "dbi" Designware PCIe registers | |
| 24 | + - "dbi" DesignWare PCIe registers | |
| 24 | 25 | - "elbi" External local bus interface registers |
| 25 | 26 | - "config" PCIe configuration space |
| 26 | 27 | |
| @@ -105,6 +106,16 @@ · 78 unmodified lines | ||
| 105 | 106 | - "bus_master" Master AXI clock |
| 106 | 107 | - "bus_slave" Slave AXI clock |
| 107 | 108 | |
| 109 | +- clock-names: | |
| 110 | + Usage: required for ipq8074 | |
| 111 | + Value type: <stringlist> | |
| 112 | + Definition: Should contain the following entries | |
| 113 | + - "iface" PCIe to SysNOC BIU clock | |
| 114 | + - "axi_m" AXI Master clock | |
| 115 | + - "axi_s" AXI Slave clock | |
| 116 | + - "ahb" AHB clock | |
| 117 | + - "aux" Auxiliary clock | |
| 118 | + | |
| 108 | 119 | - resets: |
| 109 | 120 | Usage: required |
| 110 | 121 | Value type: <prop-encoded-array> |
| @@ -144,6 +155,18 @@ · 33 unmodified lines | ||
| 144 | 155 | - "ahb" AHB reset |
| 145 | 156 | - "phy_ahb" PHY AHB reset |
| 146 | 157 | |
| 158 | +- reset-names: | |
| 159 | + Usage: required for ipq8074 | |
| 160 | + Value type: <stringlist> | |
| 161 | + Definition: Should contain the following entries | |
| 162 | + - "pipe" PIPE reset | |
| 163 | + - "sleep" Sleep reset | |
| 164 | + - "sticky" Core Sticky reset | |
| 165 | + - "axi_m" AXI Master reset | |
| 166 | + - "axi_s" AXI Slave reset | |
| 167 | + - "ahb" AHB Reset | |
| 168 | + - "axi_m_sticky" AXI Master Sticky reset | |
| 169 | + | |
| 147 | 170 | - power-domains: |
| 148 | 171 | Usage: required for apq8084 and msm8996/apq8096 |
| 149 | 172 | Value type: <prop-encoded-array> |
| @@ -180,7 +203,7 @@ · 30 unmodified lines | ||
| 180 | 203 | - <name>-gpios: |
| 181 | 204 | Usage: optional |
| 182 | 205 | Value type: <prop-encoded-array> |
| 183 | − Definition: List of phandle and gpio specifier pairs. Should contain | |
| 206 | + Definition: List of phandle and GPIO specifier pairs. Should contain | |
| 184 | 207 | - "perst-gpios" PCIe endpoint reset signal line |
| 185 | 208 | - "wake-gpios" PCIe endpoint wake signal line |
| 186 | 209 | |
| @@ -71,7 +71,7 @@ · 70 unmodified lines | ||
| 71 | 71 | - interrupt-map: standard PCI properties to define the mapping of the |
| 72 | 72 | PCI interface to interrupt numbers. |
| 73 | 73 | |
| 74 | − The PCI host bridge node migh have additional sub-nodes representing | |
| 74 | + The PCI host bridge node might have additional sub-nodes representing | |
| 75 | 75 | the onboard PCI devices/PCI slots. Each such sub-node must have the |
| 76 | 76 | following mandatory properties: |
| 77 | 77 | |
| @@ -14,7 +14,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC; · 13 unmodified lines | ||
| 14 | 14 | SoC-specific version corresponding to the platform first |
| 15 | 15 | followed by the generic version. |
| 16 | 16 | |
| 17 | −- reg: base address and length of the pcie controller registers. | |
| 17 | +- reg: base address and length of the PCIe controller registers. | |
| 18 | 18 | - #address-cells: set to <3> |
| 19 | 19 | - #size-cells: set to <2> |
| 20 | 20 | - bus-range: PCI bus numbers covered |
| @@ -25,15 +25,14 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC; · 4 unmodified lines | ||
| 25 | 25 | source for hardware related interrupts (e.g. link speed change). |
| 26 | 26 | - #interrupt-cells: set to <1> |
| 27 | 27 | - interrupt-map-mask and interrupt-map: standard PCI properties |
| 28 | − to define the mapping of the PCIe interface to interrupt | |
| 29 | − numbers. | |
| 28 | + to define the mapping of the PCIe interface to interrupt numbers. | |
| 30 | 29 | - clocks: from common clock binding: clock specifiers for the PCIe controller |
| 31 | 30 | and PCIe bus clocks. |
| 32 | 31 | - clock-names: from common clock binding: should be "pcie" and "pcie_bus". |
| 33 | 32 | |
| 34 | 33 | Example: |
| 35 | 34 | |
| 36 | −SoC specific DT Entry: | |
| 35 | +SoC-specific DT Entry: | |
| 37 | 36 | |
| 38 | 37 | pcie: pcie@fe000000 { |
| 39 | 38 | compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2"; |
| @@ -54,5 +53,4 @@ SoC specific DT Entry: · 14 unmodified lines | ||
| 54 | 53 | interrupt-map = <0 0 0 0 &gic 0 116 4>; |
| 55 | 54 | clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; |
| 56 | 55 | clock-names = "pcie", "pcie_bus"; |
| 57 | − status = "disabled"; | |
| 58 | 56 | }; |
| @@ -19,8 +19,6 @@ Required properties: · 18 unmodified lines | ||
| 19 | 19 | - "pm" |
| 20 | 20 | - msi-map: Maps a Requester ID to an MSI controller and associated |
| 21 | 21 | msi-specifier data. See ./pci-msi.txt |
| 22 | −- phys: From PHY bindings: Phandle for the Generic PHY for PCIe. | |
| 23 | −- phy-names: MUST be "pcie-phy". | |
| 24 | 22 | - interrupts: Three interrupt entries must be specified. |
| 25 | 23 | - interrupt-names: Must include the following names |
| 26 | 24 | - "sys" |
| @@ -42,11 +40,24 @@ Required properties: · 15 unmodified lines | ||
| 42 | 40 | interrupt source. The value must be 1. |
| 43 | 41 | - interrupt-map-mask and interrupt-map: standard PCI properties |
| 44 | 42 | |
| 43 | +Required properties for legacy PHY model (deprecated): | |
| 44 | +- phys: From PHY bindings: Phandle for the Generic PHY for PCIe. | |
| 45 | +- phy-names: MUST be "pcie-phy". | |
| 46 | + | |
| 47 | +Required properties for per-lane PHY model (preferred): | |
| 48 | +- phys: Must contain an phandle to a PHY for each entry in phy-names. | |
| 49 | +- phy-names: Must include 4 entries for all 4 lanes even if some of | |
| 50 | + them won't be used for your cases. Entries are of the form "pcie-phy-N": | |
| 51 | + where N ranges from 0 to 3. | |
| 52 | + (see example below and you MUST also refer to ../phy/rockchip-pcie-phy.txt | |
| 53 | + for changing the #phy-cells of phy node to support it) | |
| 54 | + | |
| 45 | 55 | Optional Property: |
| 46 | 56 | - aspm-no-l0s: RC won't support ASPM L0s. This property is needed if |
| 47 | 57 | using 24MHz OSC for RC's PHY. |
| 48 | −- ep-gpios: contain the entry for pre-reset gpio | |
| 58 | +- ep-gpios: contain the entry for pre-reset GPIO | |
| 49 | 59 | - num-lanes: number of lanes to use |
| 60 | +- vpcie12v-supply: The phandle to the 12v regulator to use for PCIe. | |
| 50 | 61 | - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe. |
| 51 | 62 | - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe. |
| 52 | 63 | - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe. |
| @@ -95,6 +106,7 @@ pcie0: pcie@f8000000 { · 42 unmodified lines | ||
| 95 | 106 | <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>; |
| 96 | 107 | reset-names = "core", "mgmt", "mgmt-sticky", "pipe", |
| 97 | 108 | "pm", "pclk", "aclk"; |
| 109 | + /* deprecated legacy PHY model */ | |
| 98 | 110 | phys = <&pcie_phy>; |
| 99 | 111 | phy-names = "pcie-phy"; |
| 100 | 112 | pinctrl-names = "default"; |
| @@ -111,3 +123,13 @@ pcie0: pcie@f8000000 { · 10 unmodified lines | ||
| 111 | 123 | #interrupt-cells = <1>; |
| 112 | 124 | }; |
| 113 | 125 | }; |
| 126 | + | |
| 127 | +pcie0: pcie@f8000000 { | |
| 128 | + ... | |
| 129 | + | |
| 130 | + /* preferred per-lane PHY model */ | |
| 131 | + phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>; | |
| 132 | + phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3"; | |
| 133 | + | |
| 134 | + ... | |
| 135 | +}; | |
| @@ -1,29 +1,29 @@ | ||
| 1 | 1 | * Samsung Exynos 5440 PCIe interface |
| 2 | 2 | |
| 3 | −This PCIe host controller is based on the Synopsis Designware PCIe IP | |
| 3 | +This PCIe host controller is based on the Synopsys DesignWare PCIe IP | |
| 4 | 4 | and thus inherits all the common properties defined in designware-pcie.txt. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: "samsung,exynos5440-pcie" |
| 8 | −- reg: base addresses and lengths of the pcie controller, | |
| 9 | − the phy controller, additional register for the phy controller. | |
| 10 | − (Registers for the phy controller are DEPRECATED. | |
| 8 | +- reg: base addresses and lengths of the PCIe controller, | |
| 9 | + the PHY controller, additional register for the PHY controller. | |
| 10 | + (Registers for the PHY controller are DEPRECATED. | |
| 11 | 11 | Use the PHY framework.) |
| 12 | 12 | - reg-names : First name should be set to "elbi". |
| 13 | − And use the "config" instead of getting the confgiruation address space | |
| 13 | + And use the "config" instead of getting the configuration address space | |
| 14 | 14 | from "ranges". |
| 15 | − NOTE: When use the "config" property, reg-names must be set. | |
| 15 | + NOTE: When using the "config" property, reg-names must be set. | |
| 16 | 16 | - interrupts: A list of interrupt outputs for level interrupt, |
| 17 | 17 | pulse interrupt, special interrupt. |
| 18 | −- phys: From PHY binding. Phandle for the Generic PHY. | |
| 18 | +- phys: From PHY binding. Phandle for the generic PHY. | |
| 19 | 19 | Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt |
| 20 | 20 | |
| 21 | −Other common properties refer to | |
| 22 | − Documentation/devicetree/binding/pci/designware-pcie.txt | |
| 21 | +For other common properties, refer to | |
| 22 | + Documentation/devicetree/bindings/pci/designware-pcie.txt | |
| 23 | 23 | |
| 24 | 24 | Example: |
| 25 | 25 | |
| 26 | −SoC specific DT Entry: | |
| 26 | +SoC-specific DT Entry: | |
| 27 | 27 | |
| 28 | 28 | pcie@290000 { |
| 29 | 29 | compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; |
| @@ -83,7 +83,7 @@ With using PHY framework: · 53 unmodified lines | ||
| 83 | 83 | ... |
| 84 | 84 | }; |
| 85 | 85 | |
| 86 | −Board specific DT Entry: | |
| 86 | +Board-specific DT Entry: | |
| 87 | 87 | |
| 88 | 88 | pcie@290000 { |
| 89 | 89 | reset-gpio = <&pin_ctrl 5 0>; |
| @@ -1,12 +1,12 @@ | ||
| 1 | 1 | SPEAr13XX PCIe DT detail: |
| 2 | 2 | ================================ |
| 3 | 3 | |
| 4 | −SPEAr13XX uses synopsis designware PCIe controller and ST MiPHY as phy | |
| 4 | +SPEAr13XX uses the Synopsys DesignWare PCIe controller and ST MiPHY as PHY | |
| 5 | 5 | controller. |
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | −- compatible : should be "st,spear1340-pcie", "snps,dw-pcie". | |
| 9 | −- phys : phandle to phy node associated with pcie controller | |
| 8 | +- compatible : should be "st,spear1340-pcie", "snps,dw-pcie". | |
| 9 | +- phys : phandle to PHY node associated with PCIe controller | |
| 10 | 10 | - phy-names : must be "pcie-phy" |
| 11 | 11 | - All other definitions as per generic PCI bindings |
| 12 | 12 | |
| @@ -1,6 +1,6 @@ | ||
| 1 | 1 | TI PCI Controllers |
| 2 | 2 | |
| 3 | −PCIe Designware Controller | |
| 3 | +PCIe DesignWare Controller | |
| 4 | 4 | - compatible: Should be "ti,dra7-pcie" for RC |
| 5 | 5 | Should be "ti,dra7-pcie-ep" for EP |
| 6 | 6 | - phys : list of PHY specifiers (used by generic PHY framework) |
| @@ -13,7 +13,7 @@ PCIe Designware Controller · 6 unmodified lines | ||
| 13 | 13 | HOST MODE |
| 14 | 14 | ========= |
| 15 | 15 | - reg : Two register ranges as listed in the reg-names property |
| 16 | − - reg-names : The first entry must be "ti-conf" for the TI specific registers | |
| 16 | + - reg-names : The first entry must be "ti-conf" for the TI-specific registers | |
| 17 | 17 | The second entry must be "rc-dbics" for the DesignWare PCIe |
| 18 | 18 | registers |
| 19 | 19 | The third entry must be "config" for the PCIe configuration space |
| @@ -30,7 +30,7 @@ HOST MODE · 10 unmodified lines | ||
| 30 | 30 | DEVICE MODE |
| 31 | 31 | =========== |
| 32 | 32 | - reg : Four register ranges as listed in the reg-names property |
| 33 | − - reg-names : "ti-conf" for the TI specific registers | |
| 33 | + - reg-names : "ti-conf" for the TI-specific registers | |
| 34 | 34 | "ep_dbics" for the standard configuration registers as |
| 35 | 35 | they are locally accessed within the DIF CS space |
| 36 | 36 | "ep_dbics2" for the standard configuration registers as |
| @@ -46,7 +46,7 @@ DEVICE MODE · 9 unmodified lines | ||
| 46 | 46 | access. |
| 47 | 47 | |
| 48 | 48 | Optional Property: |
| 49 | − - gpios : Should be added if a gpio line is required to drive PERST# line | |
| 49 | + - gpios : Should be added if a GPIO line is required to drive PERST# line | |
| 50 | 50 | |
| 51 | 51 | NOTE: Two DT nodes may be added for each PCI controller; one for host |
| 52 | 52 | mode and another for device mode. So in order for PCI to |
| @@ -5,7 +5,7 @@ PCI host controller found on the ARM Versatile PB board's FPGA. · 4 unmodified lines | ||
| 5 | 5 | Required properties: |
| 6 | 6 | - compatible: should contain "arm,versatile-pci" to identify the Versatile PCI |
| 7 | 7 | controller. |
| 8 | −- reg: base addresses and lengths of the pci controller. There must be 3 | |
| 8 | +- reg: base addresses and lengths of the PCI controller. There must be 3 | |
| 9 | 9 | entries: |
| 10 | 10 | - Versatile-specific registers |
| 11 | 11 | - Self Config space |
| @@ -4,7 +4,7 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | |
| 5 | 5 | - compatible: should be "apm,xgene1-msi" to identify |
| 6 | 6 | X-Gene v1 PCIe MSI controller block. |
| 7 | −- msi-controller: indicates that this is X-Gene v1 PCIe MSI controller node | |
| 7 | +- msi-controller: indicates that this is an X-Gene v1 PCIe MSI controller node | |
| 8 | 8 | - reg: physical base address (0x79000000) and length (0x900000) for controller |
| 9 | 9 | registers. These registers include the MSI termination address and data |
| 10 | 10 | registers as well as the MSI interrupt status registers. |
| @@ -13,7 +13,8 @@ Required properties: · 2 unmodified lines | ||
| 13 | 13 | interrupt number 0x10 to 0x1f. |
| 14 | 14 | - interrupt-names: not required |
| 15 | 15 | |
| 16 | −Each PCIe node needs to have property msi-parent that points to msi controller node | |
| 16 | +Each PCIe node needs to have property msi-parent that points to an MSI | |
| 17 | +controller node | |
| 17 | 18 | |
| 18 | 19 | Examples: |
| 19 | 20 | |
| @@ -44,7 +45,6 @@ SoC DTSI: · 24 unmodified lines | ||
| 44 | 45 | |
| 45 | 46 | + PCIe controller node with msi-parent property pointing to MSI node: |
| 46 | 47 | pcie0: pcie@1f2b0000 { |
| 47 | − status = "disabled"; | |
| 48 | 48 | device_type = "pci"; |
| 49 | 49 | compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie"; |
| 50 | 50 | #interrupt-cells = <1>; |
| @@ -8,7 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | property. |
| 9 | 9 | - reg-names: Must include the following entries: |
| 10 | 10 | "csr": controller configuration registers. |
| 11 | − "cfg": pcie configuration space registers. | |
| 11 | + "cfg": PCIe configuration space registers. | |
| 12 | 12 | - #address-cells: set to <3> |
| 13 | 13 | - #size-cells: set to <2> |
| 14 | 14 | - ranges: ranges for the outbound memory, I/O regions. |
| @@ -21,11 +21,11 @@ Required properties: · 6 unmodified lines | ||
| 21 | 21 | |
| 22 | 22 | Optional properties: |
| 23 | 23 | - status: Either "ok" or "disabled". |
| 24 | −- dma-coherent: Present if dma operations are coherent | |
| 24 | +- dma-coherent: Present if DMA operations are coherent | |
| 25 | 25 | |
| 26 | 26 | Example: |
| 27 | 27 | |
| 28 | −SoC specific DT Entry: | |
| 28 | +SoC-specific DT Entry: | |
| 29 | 29 | |
| 30 | 30 | pcie0: pcie@1f2b0000 { |
| 31 | 31 | status = "disabled"; |
| @@ -51,7 +51,7 @@ SoC specific DT Entry: · 19 unmodified lines | ||
| 51 | 51 | }; |
| 52 | 52 | |
| 53 | 53 | |
| 54 | −Board specific DT Entry: | |
| 54 | +Board-specific DT Entry: | |
| 55 | 55 | &pcie0 { |
| 56 | 56 | status = "ok"; |
| 57 | 57 | }; |
| @@ -15,9 +15,9 @@ Required properties: · 14 unmodified lines | ||
| 15 | 15 | - device_type: must be "pci" |
| 16 | 16 | - interrupts: Should contain NWL PCIe interrupt |
| 17 | 17 | - interrupt-names: Must include the following entries: |
| 18 | − "msi1, msi0": interrupt asserted when MSI is received | |
| 18 | + "msi1, msi0": interrupt asserted when an MSI is received | |
| 19 | 19 | "intx": interrupt asserted when a legacy interrupt is received |
| 20 | − "misc": interrupt asserted when miscellaneous is received | |
| 20 | + "misc": interrupt asserted when miscellaneous interrupt is received | |
| 21 | 21 | - interrupt-map-mask and interrupt-map: standard PCI properties to define the |
| 22 | 22 | mapping of the PCI interface to interrupt numbers. |
| 23 | 23 | - ranges: ranges for the PCI memory regions (I/O space region is not |
| @@ -26,7 +26,8 @@ Required properties: · 2 unmodified lines | ||
| 26 | 26 | detailed explanation |
| 27 | 27 | - msi-controller: indicates that this is MSI controller node |
| 28 | 28 | - msi-parent: MSI parent of the root complex itself |
| 29 | −- legacy-interrupt-controller: Interrupt controller device node for Legacy interrupts | |
| 29 | +- legacy-interrupt-controller: Interrupt controller device node for Legacy | |
| 30 | + interrupts | |
| 30 | 31 | - interrupt-controller: identifies the node as an interrupt controller |
| 31 | 32 | - #interrupt-cells: should be set to 1 |
| 32 | 33 | - #address-cells: specifies the number of cells needed to encode an |
| @@ -61,19 +61,16 @@ Example: · 60 unmodified lines | ||
| 61 | 61 | compatible = "apm,xgene-phy"; |
| 62 | 62 | reg = <0x0 0x1f21a000 0x0 0x100>; |
| 63 | 63 | #phy-cells = <1>; |
| 64 | − status = "disabled"; | |
| 65 | 64 | }; |
| 66 | 65 | |
| 67 | 66 | phy2: phy@1f22a000 { |
| 68 | 67 | compatible = "apm,xgene-phy"; |
| 69 | 68 | reg = <0x0 0x1f22a000 0x0 0x100>; |
| 70 | 69 | #phy-cells = <1>; |
| 71 | − status = "ok"; | |
| 72 | 70 | }; |
| 73 | 71 | |
| 74 | 72 | phy3: phy@1f23a000 { |
| 75 | 73 | compatible = "apm,xgene-phy"; |
| 76 | 74 | reg = <0x0 0x1f23a000 0x0 0x100>; |
| 77 | 75 | #phy-cells = <1>; |
| 78 | − status = "ok"; | |
| 79 | 76 | }; |
| @@ -16,5 +16,4 @@ usb_phy: usb_phy@2620738 { · 15 unmodified lines | ||
| 16 | 16 | #address-cells = <1>; |
| 17 | 17 | #size-cells = <1>; |
| 18 | 18 | reg = <0x2620738 32>; |
| 19 | − status = "disabled"; | |
| 20 | 19 | }; |
| @@ -34,7 +34,9 @@ PHY user node · 33 unmodified lines | ||
| 34 | 34 | ============= |
| 35 | 35 | |
| 36 | 36 | Required Properties: |
| 37 | −phys : the phandle for the PHY device (used by the PHY subsystem) | |
| 37 | +phys : the phandle for the PHY device (used by the PHY subsystem; not to be | |
| 38 | + confused with the Ethernet specific 'phy' and 'phy-handle' properties, | |
| 39 | + see Documentation/devicetree/bindings/net/ethernet.txt for these) | |
| 38 | 40 | phy-names : the names of the PHY corresponding to the PHYs present in the |
| 39 | 41 | *phys* phandle |
| 40 | 42 | |
| @@ -0,0 +1,40 @@ | ||
| 1 | +Lantiq XWAY SoC RCU USB 1.1/2.0 PHY binding | |
| 2 | +=========================================== | |
| 3 | + | |
| 4 | +This binding describes the USB PHY hardware provided by the RCU module on the | |
| 5 | +Lantiq XWAY SoCs. | |
| 6 | + | |
| 7 | +This node has to be a sub node of the Lantiq RCU block. | |
| 8 | + | |
| 9 | +------------------------------------------------------------------------------- | |
| 10 | +Required properties (controller (parent) node): | |
| 11 | +- compatible : Should be one of | |
| 12 | + "lantiq,ase-usb2-phy" | |
| 13 | + "lantiq,danube-usb2-phy" | |
| 14 | + "lantiq,xrx100-usb2-phy" | |
| 15 | + "lantiq,xrx200-usb2-phy" | |
| 16 | + "lantiq,xrx300-usb2-phy" | |
| 17 | +- reg : Defines the following sets of registers in the parent | |
| 18 | + syscon device | |
| 19 | + - Offset of the USB PHY configuration register | |
| 20 | + - Offset of the USB Analog configuration | |
| 21 | + register (only for xrx200 and xrx200) | |
| 22 | +- clocks : References to the (PMU) "phy" clk gate. | |
| 23 | +- clock-names : Must be "phy" | |
| 24 | +- resets : References to the RCU USB configuration reset bits. | |
| 25 | +- reset-names : Must be one of the following: | |
| 26 | + "phy" (optional) | |
| 27 | + "ctrl" (shared) | |
| 28 | + | |
| 29 | +------------------------------------------------------------------------------- | |
| 30 | +Example for the USB PHYs on an xRX200 SoC: | |
| 31 | + usb_phy0: usb2-phy@18 { | |
| 32 | + compatible = "lantiq,xrx200-usb2-phy"; | |
| 33 | + reg = <0x18 4>, <0x38 4>; | |
| 34 | + | |
| 35 | + clocks = <&pmu PMU_GATE_USB0_PHY>; | |
| 36 | + clock-names = "phy"; | |
| 37 | + resets = <&reset1 4 4>, <&reset0 4 4>; | |
| 38 | + reset-names = "phy", "ctrl"; | |
| 39 | + #phy-cells = <0>; | |
| 40 | + }; | |
| @@ -1,13 +1,18 @@ | ||
| 1 | −mt65xx USB3.0 PHY binding | |
| 1 | +MediaTek T-PHY binding | |
| 2 | 2 | -------------------------- |
| 3 | 3 | |
| 4 | −This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC. | |
| 4 | +T-phy controller supports physical layer functionality for a number of | |
| 5 | +controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, and SATA. | |
| 5 | 6 | |
| 6 | 7 | Required properties (controller (parent) node): |
| 7 | 8 | - compatible : should be one of |
| 8 | − "mediatek,mt2701-u3phy" | |
| 9 | − "mediatek,mt2712-u3phy" | |
| 10 | − "mediatek,mt8173-u3phy" | |
| 9 | + "mediatek,generic-tphy-v1" | |
| 10 | + "mediatek,generic-tphy-v2" | |
| 11 | + "mediatek,mt2701-u3phy" (deprecated) | |
| 12 | + "mediatek,mt2712-u3phy" (deprecated) | |
| 13 | + "mediatek,mt8173-u3phy"; | |
| 14 | + make use of "mediatek,generic-tphy-v1" on mt2701 instead and | |
| 15 | + "mediatek,generic-tphy-v2" on mt2712 instead. | |
| 11 | 16 | - clocks : (deprecated, use port's clocks instead) a list of phandle + |
| 12 | 17 | clock-specifier pairs, one for each entry in clock-names |
| 13 | 18 | - clock-names : (deprecated, use port's one instead) must contain |
| @@ -35,6 +40,8 @@ Required properties (port (child) node): · 21 unmodified lines | ||
| 35 | 40 | cell after port phandle is phy type from: |
| 36 | 41 | - PHY_TYPE_USB2 |
| 37 | 42 | - PHY_TYPE_USB3 |
| 43 | + - PHY_TYPE_PCIE | |
| 44 | + - PHY_TYPE_SATA | |
| 38 | 45 | |
| 39 | 46 | Example: |
| 40 | 47 | |
| @@ -44,14 +51,12 @@ u3phy: usb-phy@11290000 { · 3 unmodified lines | ||
| 44 | 51 | #address-cells = <2>; |
| 45 | 52 | #size-cells = <2>; |
| 46 | 53 | ranges; |
| 47 | − status = "okay"; | |
| 48 | 54 | |
| 49 | 55 | u2port0: usb-phy@11290800 { |
| 50 | 56 | reg = <0 0x11290800 0 0x100>; |
| 51 | 57 | clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; |
| 52 | 58 | clock-names = "ref"; |
| 53 | 59 | #phy-cells = <1>; |
| 54 | − status = "okay"; | |
| 55 | 60 | }; |
| 56 | 61 | |
| 57 | 62 | u3port0: usb-phy@11290900 { |
| @@ -59,7 +64,6 @@ u3phy: usb-phy@11290000 { · 1 unmodified line | ||
| 59 | 64 | clocks = <&clk26m>; |
| 60 | 65 | clock-names = "ref"; |
| 61 | 66 | #phy-cells = <1>; |
| 62 | − status = "okay"; | |
| 63 | 67 | }; |
| 64 | 68 | |
| 65 | 69 | u2port1: usb-phy@11291000 { |
| @@ -67,7 +71,6 @@ u3phy: usb-phy@11290000 { · 1 unmodified line | ||
| 67 | 71 | clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; |
| 68 | 72 | clock-names = "ref"; |
| 69 | 73 | #phy-cells = <1>; |
| 70 | − status = "okay"; | |
| 71 | 74 | }; |
| 72 | 75 | }; |
| 73 | 76 | |
| @@ -0,0 +1,43 @@ | ||
| 1 | +mvebu comphy driver | |
| 2 | +------------------- | |
| 3 | + | |
| 4 | +A comphy controller can be found on Marvell Armada 7k/8k on the CP110. It | |
| 5 | +provides a number of shared PHYs used by various interfaces (network, sata, | |
| 6 | +usb, PCIe...). | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | + | |
| 10 | +- compatible: should be "marvell,comphy-cp110" | |
| 11 | +- reg: should contain the comphy register location and length. | |
| 12 | +- marvell,system-controller: should contain a phandle to the | |
| 13 | + system controller node. | |
| 14 | +- #address-cells: should be 1. | |
| 15 | +- #size-cells: should be 0. | |
| 16 | + | |
| 17 | +A sub-node is required for each comphy lane provided by the comphy. | |
| 18 | + | |
| 19 | +Required properties (child nodes): | |
| 20 | + | |
| 21 | +- reg: comphy lane number. | |
| 22 | +- #phy-cells : from the generic phy bindings, must be 1. Defines the | |
| 23 | + input port to use for a given comphy lane. | |
| 24 | + | |
| 25 | +Example: | |
| 26 | + | |
| 27 | + cpm_comphy: phy@120000 { | |
| 28 | + compatible = "marvell,comphy-cp110"; | |
| 29 | + reg = <0x120000 0x6000>; | |
| 30 | + marvell,system-controller = <&cpm_syscon0>; | |
| 31 | + #address-cells = <1>; | |
| 32 | + #size-cells = <0>; | |
| 33 | + | |
| 34 | + cpm_comphy0: phy@0 { | |
| 35 | + reg = <0>; | |
| 36 | + #phy-cells = <1>; | |
| 37 | + }; | |
| 38 | + | |
| 39 | + cpm_comphy1: phy@1 { | |
| 40 | + reg = <1>; | |
| 41 | + #phy-cells = <1>; | |
| 42 | + }; | |
| 43 | + }; | |
| @@ -18,7 +18,6 @@ Example: · 17 unmodified lines | ||
| 18 | 18 | clocks = <&gate_clk 15>; |
| 19 | 19 | clock-names = "sata"; |
| 20 | 20 | #phy-cells = <0>; |
| 21 | − status = "ok"; | |
| 22 | 21 | }; |
| 23 | 22 | |
| 24 | 23 | Armada 375 USB cluster |
| @@ -6,6 +6,7 @@ Required properties (phy (parent) node): · 5 unmodified lines | ||
| 6 | 6 | * "rockchip,rk3328-usb2phy" |
| 7 | 7 | * "rockchip,rk3366-usb2phy" |
| 8 | 8 | * "rockchip,rk3399-usb2phy" |
| 9 | + * "rockchip,rv1108-usb2phy" | |
| 9 | 10 | - reg : the address offset of grf for usb-phy configuration. |
| 10 | 11 | - #clock-cells : should be 0. |
| 11 | 12 | - clock-output-names : specify the 480m output clock name. |
| @@ -18,6 +19,10 @@ Optional properties: · 6 unmodified lines | ||
| 18 | 19 | usb-phy output 480m and xin24m. |
| 19 | 20 | Refer to clk/clock-bindings.txt for generic clock |
| 20 | 21 | consumer properties. |
| 22 | + - rockchip,usbgrf : phandle to the syscon managing the "usb general | |
| 23 | + register files". When set driver will request its | |
| 24 | + phandle as one companion-grf for some special SoCs | |
| 25 | + (e.g RV1108). | |
| 21 | 26 | |
| 22 | 27 | Required nodes : a sub-node is required for each port the phy provides. |
| 23 | 28 | The sub-node name is used to identify host or otg port, |
| @@ -28,10 +33,14 @@ Required nodes : a sub-node is required for each port the phy provides. · 4 unmodified lines | ||
| 28 | 33 | Required properties (port (child) node): |
| 29 | 34 | - #phy-cells : must be 0. See ./phy-bindings.txt for details. |
| 30 | 35 | - interrupts : specify an interrupt for each entry in interrupt-names. |
| 31 | − - interrupt-names : a list which shall be the following entries: | |
| 36 | + - interrupt-names : a list which should be one of the following cases: | |
| 37 | + Regular case: | |
| 32 | 38 | * "otg-id" : for the otg id interrupt. |
| 33 | 39 | * "otg-bvalid" : for the otg vbus interrupt. |
| 34 | 40 | * "linestate" : for the host/otg linestate interrupt. |
| 41 | + Some SoCs use one interrupt with the above muxed together, so for these | |
| 42 | + * "otg-mux" : otg-port interrupt, which mux otg-id/otg-bvalid/linestate | |
| 43 | + to one. | |
| 35 | 44 | |
| 36 | 45 | Optional properties: |
| 37 | 46 | - phy-supply : phandle to a regulator that provides power to VBUS. |
| @@ -58,14 +67,12 @@ grf: syscon@ff770000 { · 20 unmodified lines | ||
| 58 | 67 | <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, |
| 59 | 68 | <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; |
| 60 | 69 | interrupt-names = "otg-id", "otg-bvalid", "linestate"; |
| 61 | − status = "okay"; | |
| 62 | 70 | }; |
| 63 | 71 | |
| 64 | 72 | u2phy_host: host-port { |
| 65 | 73 | #phy-cells = <0>; |
| 66 | 74 | interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; |
| 67 | 75 | interrupt-names = "linestate"; |
| 68 | − status = "okay"; | |
| 69 | 76 | }; |
| 70 | 77 | }; |
| 71 | 78 | }; |
| @@ -25,7 +25,6 @@ Example: · 24 unmodified lines | ||
| 25 | 25 | clock-names = "ref"; |
| 26 | 26 | #phy-cells = <0>; |
| 27 | 27 | |
| 28 | − status = "ok"; | |
| 29 | 28 | }; |
| 30 | 29 | |
| 31 | 30 | phy@100f8830 { |
| @@ -35,5 +34,4 @@ Example: · 3 unmodified lines | ||
| 35 | 34 | clock-names = "ref"; |
| 36 | 35 | #phy-cells = <0>; |
| 37 | 36 | |
| 38 | − status = "ok"; | |
| 39 | 37 | }; |
| @@ -6,6 +6,7 @@ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: compatible list, contains: |
| 9 | + "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 | |
| 9 | 10 | "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, |
| 10 | 11 | "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996. |
| 11 | 12 | |
| @@ -38,6 +39,8 @@ Required properties: · 26 unmodified lines | ||
| 38 | 39 | "phy", "common", "cfg". |
| 39 | 40 | For "qcom,msm8996-qmp-usb3-phy" must contain |
| 40 | 41 | "phy", "common". |
| 42 | + For "qcom,ipq8074-qmp-pcie-phy" must contain: | |
| 43 | + "phy", "common". | |
| 41 | 44 | |
| 42 | 45 | - vdda-phy-supply: Phandle to a regulator supply to PHY core block. |
| 43 | 46 | - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block. |
| @@ -60,6 +63,13 @@ Required properties for child node: · 16 unmodified lines | ||
| 60 | 63 | one for each entry in clock-names. |
| 61 | 64 | - clock-names: Must contain following for pcie and usb qmp phys: |
| 62 | 65 | "pipe<lane-number>" for pipe clock specific to each lane. |
| 66 | + - clock-output-names: Name of the PHY clock that will be the parent for | |
| 67 | + the above pipe clock. | |
| 68 | + | |
| 69 | + For "qcom,ipq8074-qmp-pcie-phy": | |
| 70 | + - "pcie20_phy0_pipe_clk" Pipe Clock parent | |
| 71 | + (or) | |
| 72 | + "pcie20_phy1_pipe_clk" | |
| 63 | 73 | |
| 64 | 74 | - resets: a list of phandles and reset controller specifier pairs, |
| 65 | 75 | one for each entry in reset-names. |
| @@ -96,6 +106,7 @@ Example: · 30 unmodified lines | ||
| 96 | 106 | |
| 97 | 107 | clocks = <&gcc GCC_PCIE_0_PIPE_CLK>; |
| 98 | 108 | clock-names = "pipe0"; |
| 109 | + clock-output-names = "pcie_0_pipe_clk_src"; | |
| 99 | 110 | resets = <&gcc GCC_PCIE_0_PHY_BCR>; |
| 100 | 111 | reset-names = "lane0"; |
| 101 | 112 | }; |
| @@ -0,0 +1,23 @@ | ||
| 1 | +Mediatek/Ralink USB PHY | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "ralink,rt3352-usbphy" | |
| 5 | + "mediatek,mt7620-usbphy" | |
| 6 | + "mediatek,mt7628-usbphy" | |
| 7 | + - reg: required for "mediatek,mt7628-usbphy", unused otherwise | |
| 8 | + - #phy-cells: should be 0 | |
| 9 | + - ralink,sysctl: a phandle to a ralink syscon register region | |
| 10 | + - resets: the two reset controllers for host and device | |
| 11 | + - reset-names: the names of the 2 reset controllers | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | +usbphy: phy { | |
| 16 | + compatible = "mediatek,mt7628-usbphy"; | |
| 17 | + reg = <0x10120000 0x1000>; | |
| 18 | + #phy-cells = <0>; | |
| 19 | + | |
| 20 | + ralink,sysctl = <&sysc>; | |
| 21 | + resets = <&rstctrl 22 &rstctrl 25>; | |
| 22 | + reset-names = "host", "device"; | |
| 23 | +}; | |
| @@ -3,7 +3,6 @@ Rockchip PCIE PHY · 2 unmodified lines | ||
| 3 | 3 | |
| 4 | 4 | Required properties: |
| 5 | 5 | - compatible: rockchip,rk3399-pcie-phy |
| 6 | − - #phy-cells: must be 0 | |
| 7 | 6 | - clocks: Must contain an entry in clock-names. |
| 8 | 7 | See ../clocks/clock-bindings.txt for details. |
| 9 | 8 | - clock-names: Must be "refclk" |
| @@ -11,6 +10,12 @@ Required properties: · 1 unmodified line | ||
| 11 | 10 | See ../reset/reset.txt for details. |
| 12 | 11 | - reset-names: Must be "phy" |
| 13 | 12 | |
| 13 | +Required properties for legacy PHY mode (deprecated): | |
| 14 | + - #phy-cells: must be 0 | |
| 15 | + | |
| 16 | +Required properties for per-lane PHY mode (preferred): | |
| 17 | + - #phy-cells: must be 1 | |
| 18 | + | |
| 14 | 19 | Example: |
| 15 | 20 | |
| 16 | 21 | grf: syscon@ff770000 { |
| @@ -82,7 +82,6 @@ usbphy: phy@125b0000 { · 81 unmodified lines | ||
| 82 | 82 | reg = <0x125b0000 0x100>; |
| 83 | 83 | clocks = <&clock 305>, <&clock 2>; |
| 84 | 84 | clock-names = "phy", "ref"; |
| 85 | − status = "okay"; | |
| 86 | 85 | #phy-cells = <1>; |
| 87 | 86 | samsung,sysreg-phandle = <&sys_reg>; |
| 88 | 87 | samsung,pmureg-phandle = <&pmu_reg>; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | * allwinner,sun7i-a20-usb-phy |
| 10 | 10 | * allwinner,sun8i-a23-usb-phy |
| 11 | 11 | * allwinner,sun8i-a33-usb-phy |
| 12 | + * allwinner,sun8i-a83t-usb-phy | |
| 12 | 13 | * allwinner,sun8i-h3-usb-phy |
| 13 | 14 | * allwinner,sun8i-v3s-usb-phy |
| 14 | 15 | * allwinner,sun50i-a64-usb-phy |
| @@ -17,18 +18,22 @@ Required properties: · 2 unmodified lines | ||
| 17 | 18 | * "phy_ctrl" |
| 18 | 19 | * "pmu0" for H3, V3s and A64 |
| 19 | 20 | * "pmu1" |
| 20 | − * "pmu2" for sun4i, sun6i or sun7i | |
| 21 | + * "pmu2" for sun4i, sun6i, sun7i, sun8i-a83t or sun8i-h3 | |
| 22 | + * "pmu3" for sun8i-h3 | |
| 21 | 23 | - #phy-cells : from the generic phy bindings, must be 1 |
| 22 | 24 | - clocks : phandle + clock specifier for the phy clocks |
| 23 | 25 | - clock-names : |
| 24 | 26 | * "usb_phy" for sun4i, sun5i or sun7i |
| 25 | 27 | * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i |
| 26 | 28 | * "usb0_phy", "usb1_phy" for sun8i |
| 29 | + * "usb0_phy", "usb1_phy", "usb2_phy" and "usb2_hsic_12M" for sun8i-a83t | |
| 30 | + * "usb0_phy", "usb1_phy", "usb2_phy" and "usb3_phy" for sun8i-h3 | |
| 27 | 31 | - resets : a list of phandle + reset specifier pairs |
| 28 | 32 | - reset-names : |
| 29 | 33 | * "usb0_reset" |
| 30 | 34 | * "usb1_reset" |
| 31 | − * "usb2_reset" for sun4i, sun6i or sun7i | |
| 35 | + * "usb2_reset" for sun4i, sun6i, sun7i, sun8i-a83t or sun8i-h3 | |
| 36 | + * "usb3_reset" for sun8i-h3 | |
| 32 | 37 | |
| 33 | 38 | Optional properties: |
| 34 | 39 | - usb0_id_det-gpios : gpio phandle for reading the otg id pin value |
| @@ -37,6 +42,7 @@ Optional properties: · 2 unmodified lines | ||
| 37 | 42 | - usb0_vbus-supply : regulator phandle for controller usb0 vbus |
| 38 | 43 | - usb1_vbus-supply : regulator phandle for controller usb1 vbus |
| 39 | 44 | - usb2_vbus-supply : regulator phandle for controller usb2 vbus |
| 45 | +- usb3_vbus-supply : regulator phandle for controller usb3 vbus | |
| 40 | 46 | |
| 41 | 47 | Example: |
| 42 | 48 | usbphy: phy@0x01c13400 { |
| @@ -33,6 +33,5 @@ Example: · 32 unmodified lines | ||
| 33 | 33 | clock-names = "hsic_480M", "hsic_12M", "phy"; |
| 34 | 34 | resets = <&usb_phy_clk 18>, <&usb_phy_clk 19>; |
| 35 | 35 | reset-names = "hsic", "phy"; |
| 36 | − status = "disabled"; | |
| 37 | 36 | #phy-cells = <0>; |
| 38 | 37 | }; |
| @@ -148,5 +148,4 @@ dbgu: serial@fffff200 { · 147 unmodified lines | ||
| 148 | 148 | interrupts = <1 4 7>; |
| 149 | 149 | pinctrl-names = "default"; |
| 150 | 150 | pinctrl-0 = <&pinctrl_dbgu>; |
| 151 | − status = "disabled"; | |
| 152 | 151 | }; |
| @@ -0,0 +1,59 @@ | ||
| 1 | +Cortina Systems Gemini pin controller | |
| 2 | + | |
| 3 | +This pin controller is found in the Cortina Systems Gemini SoC family, | |
| 4 | +see further arm/gemini.txt. It is a purely group-based multiplexing pin | |
| 5 | +controller. | |
| 6 | + | |
| 7 | +The pin controller node must be a subnode of the system controller node. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: "cortina,gemini-pinctrl" | |
| 11 | + | |
| 12 | +Subnodes of the pin controller contain pin control multiplexing set-up. | |
| 13 | +Please refer to pinctrl-bindings.txt for generic pin multiplexing nodes. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | + | |
| 18 | +syscon { | |
| 19 | + compatible = "cortina,gemini-syscon"; | |
| 20 | + ... | |
| 21 | + pinctrl { | |
| 22 | + compatible = "cortina,gemini-pinctrl"; | |
| 23 | + pinctrl-names = "default"; | |
| 24 | + pinctrl-0 = <&dram_default_pins>, <&system_default_pins>, | |
| 25 | + <&vcontrol_default_pins>; | |
| 26 | + | |
| 27 | + dram_default_pins: pinctrl-dram { | |
| 28 | + mux { | |
| 29 | + function = "dram"; | |
| 30 | + groups = "dramgrp"; | |
| 31 | + }; | |
| 32 | + }; | |
| 33 | + rtc_default_pins: pinctrl-rtc { | |
| 34 | + mux { | |
| 35 | + function = "rtc"; | |
| 36 | + groups = "rtcgrp"; | |
| 37 | + }; | |
| 38 | + }; | |
| 39 | + power_default_pins: pinctrl-power { | |
| 40 | + mux { | |
| 41 | + function = "power"; | |
| 42 | + groups = "powergrp"; | |
| 43 | + }; | |
| 44 | + }; | |
| 45 | + system_default_pins: pinctrl-system { | |
| 46 | + mux { | |
| 47 | + function = "system"; | |
| 48 | + groups = "systemgrp"; | |
| 49 | + }; | |
| 50 | + }; | |
| 51 | + (...) | |
| 52 | + uart_default_pins: pinctrl-uart { | |
| 53 | + mux { | |
| 54 | + function = "uart"; | |
| 55 | + groups = "uartrxtxgrp"; | |
| 56 | + }; | |
| 57 | + }; | |
| 58 | + }; | |
| 59 | +}; | |
| @@ -61,7 +61,6 @@ Examples: · 60 unmodified lines | ||
| 61 | 61 | usdhc@0219c000 { /* uSDHC4 */ |
| 62 | 62 | non-removable; |
| 63 | 63 | vmmc-supply = <®_3p3v>; |
| 64 | − status = "okay"; | |
| 65 | 64 | pinctrl-names = "default"; |
| 66 | 65 | pinctrl-0 = <&pinctrl_usdhc4_1>; |
| 67 | 66 | }; |
| @@ -61,7 +61,6 @@ iomuxc-lpsr controller and SDA pad from iomuxc controller as: · 60 unmodified lines | ||
| 61 | 61 | i2c1: i2c@30a20000 { |
| 62 | 62 | pinctrl-names = "default"; |
| 63 | 63 | pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>; |
| 64 | − status = "okay"; | |
| 65 | 64 | }; |
| 66 | 65 | |
| 67 | 66 | iomuxc-lpsr@302c0000 { |
| @@ -0,0 +1,61 @@ | ||
| 1 | +* Freescale i.MX7ULP IOMUX Controller | |
| 2 | + | |
| 3 | +i.MX 7ULP has three IOMUXC instances: IOMUXC0 for M4 ports, IOMUXC1 for A7 | |
| 4 | +ports and IOMUXC DDR for DDR interface. | |
| 5 | + | |
| 6 | +Note: | |
| 7 | +This binding doc is only for the IOMUXC1 support in A7 Domain and it only | |
| 8 | +supports generic pin config. | |
| 9 | + | |
| 10 | +Please also refer pinctrl-bindings.txt in this directory for generic pinctrl | |
| 11 | +binding. | |
| 12 | + | |
| 13 | +=== Pin Controller Node === | |
| 14 | + | |
| 15 | +Required properties: | |
| 16 | +- compatible: "fsl,imx7ulp-iomuxc1" | |
| 17 | +- reg: Should contain the base physical address and size of the iomuxc | |
| 18 | + registers. | |
| 19 | + | |
| 20 | +=== Pin Configuration Node === | |
| 21 | +- pinmux: One integers array, represents a group of pins mux setting. | |
| 22 | + The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on | |
| 23 | + a specific function. | |
| 24 | + | |
| 25 | + NOTE: i.MX7ULP PIN_FUNC_ID consists of 4 integers as it shares one mux | |
| 26 | + and config register as follows: | |
| 27 | + <mux_conf_reg input_reg mux_mode input_val> | |
| 28 | + | |
| 29 | + Refer to imx7ulp-pinfunc.h in in device tree source folder for all | |
| 30 | + available imx7ulp PIN_FUNC_ID. | |
| 31 | + | |
| 32 | +Optional Properties: | |
| 33 | +- drive-strength Integer. Controls Drive Strength | |
| 34 | + 0: Standard | |
| 35 | + 1: Hi Driver | |
| 36 | +- drive-push-pull Bool. Enable Pin Push-pull | |
| 37 | +- drive-open-drain Bool. Enable Pin Open-drian | |
| 38 | +- slew-rate: Integer. Controls Slew Rate | |
| 39 | + 0: Standard | |
| 40 | + 1: Slow | |
| 41 | +- bias-disable: Bool. Pull disabled | |
| 42 | +- bias-pull-down: Bool. Pull down on pin | |
| 43 | +- bias-pull-up: Bool. Pull up on pin | |
| 44 | + | |
| 45 | +Examples: | |
| 46 | +#include "imx7ulp-pinfunc.h" | |
| 47 | + | |
| 48 | +/* Pin Controller Node */ | |
| 49 | +iomuxc1: iomuxc@40ac0000 { | |
| 50 | + compatible = "fsl,imx7ulp-iomuxc1"; | |
| 51 | + reg = <0x40ac0000 0x1000>; | |
| 52 | + | |
| 53 | + /* Pin Configuration Node */ | |
| 54 | + pinctrl_lpuart4: lpuart4grp { | |
| 55 | + pinmux = < | |
| 56 | + IMX7ULP_PAD_PTC3__LPUART4_RX | |
| 57 | + IMX7ULP_PAD_PTC2__LPUART4_TX | |
| 58 | + >; | |
| 59 | + bias-pull-up; | |
| 60 | + }; | |
| 61 | +}; | |
| @@ -56,5 +56,4 @@ Example: · 55 unmodified lines | ||
| 56 | 56 | pinctrl-0 = <&state_dpaux_i2c>; |
| 57 | 57 | pinctrl-1 = <&state_dpaux_off>; |
| 58 | 58 | pinctrl-names = "default", "idle"; |
| 59 | − status = "disabled"; | |
| 60 | 59 | }; |
| @@ -50,7 +50,6 @@ uart2: serial@900000 { · 49 unmodified lines | ||
| 50 | 50 | reg-io-width = <1>; |
| 51 | 51 | current-speed = <115200>; |
| 52 | 52 | no-loopback-test; |
| 53 | − status = "disabled"; | |
| 54 | 53 | resets = <&reset 22>; |
| 55 | 54 | pinctrl-names = "default"; |
| 56 | 55 | pinctrl-0 = <&pinctrl_uart2>; |
| @@ -69,8 +69,9 @@ PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 ROM16 ROM8 ROMCS1 · 68 unmodified lines | ||
| 69 | 69 | ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK |
| 70 | 70 | SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ |
| 71 | 71 | SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4 |
| 72 | −TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USBCKI VGABIOS_ROM VGAHS | |
| 73 | −VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2 | |
| 72 | +TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USB11D1 USB11H2 USB2D1 | |
| 73 | +USB2H1 USBCKI VGABIOS_ROM VGAHS VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 | |
| 74 | +WDTRST2 | |
| 74 | 75 | |
| 75 | 76 | aspeed,ast2500-pinctrl, aspeed,g5-pinctrl: |
| 76 | 77 | |
| @@ -86,7 +87,8 @@ SALT11 SALT12 SALT13 SALT14 SALT2 SALT3 SALT4 SALT5 SALT6 SALT7 SALT8 SALT9 · 9 unmodified lines | ||
| 86 | 87 | SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ |
| 87 | 88 | SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0 |
| 88 | 89 | SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 |
| 89 | −TXD3 TXD4 UART6 USBCKI VGABIOSROM VGAHS VGAVS VPI24 VPO WDTRST1 WDTRST2 | |
| 90 | +TXD3 TXD4 UART6 USB11BHID USB2AD USB2AH USB2BD USB2BH USBCKI VGABIOSROM VGAHS | |
| 91 | +VGAVS VPI24 VPO WDTRST1 WDTRST2 | |
| 90 | 92 | |
| 91 | 93 | Examples |
| 92 | 94 | ======== |
| @@ -268,6 +268,8 @@ output-enable - enable output on a pin without actively driving it · 267 unmodified lines | ||
| 268 | 268 | (such as enabling an output buffer) |
| 269 | 269 | output-low - set the pin to output mode with low level |
| 270 | 270 | output-high - set the pin to output mode with high level |
| 271 | +sleep-hardware-state - indicate this is sleep related state which will be programmed | |
| 272 | + into the registers for the sleep state. | |
| 271 | 273 | slew-rate - set the slew rate |
| 272 | 274 | |
| 273 | 275 | For example: |
| @@ -5,6 +5,7 @@ The Mediatek's Pin controller is used to control SoC pins. · 4 unmodified lines | ||
| 5 | 5 | Required properties: |
| 6 | 6 | - compatible: value should be one of the following. |
| 7 | 7 | "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl. |
| 8 | + "mediatek,mt2712-pinctrl", compatible with mt2712 pinctrl. | |
| 8 | 9 | "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. |
| 9 | 10 | "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl. |
| 10 | 11 | "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. |
| @@ -0,0 +1,63 @@ | ||
| 1 | +Pincontrol driver for RK805 Power management IC. | |
| 2 | + | |
| 3 | +RK805 has 2 pins which can be configured as GPIO output only. | |
| 4 | + | |
| 5 | +Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt> | |
| 6 | +for details of the common pinctrl bindings used by client devices, | |
| 7 | +including the meaning of the phrase "pin configuration node". | |
| 8 | + | |
| 9 | +Optional Pinmux properties: | |
| 10 | +-------------------------- | |
| 11 | +Following properties are required if default setting of pins are required | |
| 12 | +at boot. | |
| 13 | +- pinctrl-names: A pinctrl state named per <pinctrl-binding.txt>. | |
| 14 | +- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per | |
| 15 | + <pinctrl-binding.txt>. | |
| 16 | + | |
| 17 | +The pin configurations are defined as child of the pinctrl states node. Each | |
| 18 | +sub-node have following properties: | |
| 19 | + | |
| 20 | +Required properties: | |
| 21 | +------------------ | |
| 22 | +- #gpio-cells: Should be two. The first cell is the pin number and the | |
| 23 | + second is the GPIO flags. | |
| 24 | + | |
| 25 | +- gpio-controller: Marks the device node as a GPIO controller. | |
| 26 | + | |
| 27 | +- pins: List of pins. Valid values of pins properties are: gpio0, gpio1. | |
| 28 | + | |
| 29 | +First 2 properties must be added in the RK805 PMIC node, documented in | |
| 30 | +Documentation/devicetree/bindings/mfd/rk808.txt | |
| 31 | + | |
| 32 | +Optional properties: | |
| 33 | +------------------- | |
| 34 | +Following are optional properties defined as pinmux DT binding document | |
| 35 | +<pinctrl-bindings.txt>. Absence of properties will leave the configuration | |
| 36 | +on default. | |
| 37 | + function, | |
| 38 | + output-low, | |
| 39 | + output-high. | |
| 40 | + | |
| 41 | +Valid values for function properties are: gpio. | |
| 42 | + | |
| 43 | +Theres is also not customised properties for any GPIO. | |
| 44 | + | |
| 45 | +Example: | |
| 46 | +-------- | |
| 47 | +rk805: rk805@18 { | |
| 48 | + compatible = "rockchip,rk805"; | |
| 49 | + ... | |
| 50 | + gpio-controller; | |
| 51 | + #gpio-cells = <2>; | |
| 52 | + | |
| 53 | + pinctrl-names = "default"; | |
| 54 | + pinctrl-0 = <&pmic_int_l>, <&rk805_default>; | |
| 55 | + | |
| 56 | + rk805_default: pinmux { | |
| 57 | + gpio01 { | |
| 58 | + pins = "gpio0", "gpio1"; | |
| 59 | + function = "gpio"; | |
| 60 | + output-high; | |
| 61 | + }; | |
| 62 | + }; | |
| 63 | +}; | |
| @@ -81,5 +81,4 @@ pmm: pin-controller@1462000 { · 80 unmodified lines | ||
| 81 | 81 | &vga { |
| 82 | 82 | pinctrl-names = "default"; |
| 83 | 83 | pinctrl-0 = <&vga_pins>; |
| 84 | − status = "okay"; | |
| 85 | 84 | }; |
| @@ -46,7 +46,8 @@ Valid values for pins are: · 45 unmodified lines | ||
| 46 | 46 | gpio0-gpio89 |
| 47 | 47 | |
| 48 | 48 | Valid values for function are: |
| 49 | − cam_mclk, codec_mic_i2s, codec_spkr_i2s, gpio, gsbi1, gsbi2, gsbi3, gsbi4, | |
| 49 | + cam_mclk, codec_mic_i2s, codec_spkr_i2s, gp_clk_0a, gp_clk_0b, gp_clk_1a, | |
| 50 | + gp_clk_1b, gp_clk_2a, gp_clk_2b, gpio, gsbi1, gsbi2, gsbi3, gsbi4, | |
| 50 | 51 | gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, |
| 51 | 52 | gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, |
| 52 | 53 | gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, |
| @@ -50,7 +50,11 @@ Valid values for qcom,pins are: · 49 unmodified lines | ||
| 50 | 50 | Supports mux, bias and drive-strength |
| 51 | 51 | |
| 52 | 52 | Valid values for qcom,function are: |
| 53 | −gpio, blsp_uart1, blsp_i2c0, blsp_i2c1, blsp_uart0, blsp_spi1, blsp_spi0 | |
| 53 | +aud_pin, audio_pwm, blsp_i2c0, blsp_i2c1, blsp_spi0, blsp_spi1, blsp_uart0, | |
| 54 | +blsp_uart1, chip_rst, gpio, i2s_rx, i2s_spdif_in, i2s_spdif_out, i2s_td, i2s_tx, | |
| 55 | +jtag, led0, led1, led2, led3, led4, led5, led6, led7, led8, led9, led10, led11, | |
| 56 | +mdc, mdio, pcie, pmu, prng_rosc, qpic, rgmii, rmii, sdio, smart0, smart1, | |
| 57 | +smart2, smart3, tm, wifi0, wifi1 | |
| 54 | 58 | |
| 55 | 59 | Example: |
| 56 | 60 | |
| @@ -16,6 +16,7 @@ PMIC's from Qualcomm. · 15 unmodified lines | ||
| 16 | 16 | "qcom,pm8941-gpio" |
| 17 | 17 | "qcom,pm8994-gpio" |
| 18 | 18 | "qcom,pma8084-gpio" |
| 19 | + "qcom,pmi8994-gpio" | |
| 19 | 20 | |
| 20 | 21 | And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" |
| 21 | 22 | if the device is on an spmi bus or an ssbi bus respectively |
| @@ -85,6 +86,7 @@ to specify in a pin configuration subnode: · 63 unmodified lines | ||
| 85 | 86 | gpio1-gpio36 for pm8941 |
| 86 | 87 | gpio1-gpio22 for pm8994 |
| 87 | 88 | gpio1-gpio22 for pma8084 |
| 89 | + gpio1-gpio10 for pmi8994 | |
| 88 | 90 | |
| 89 | 91 | - function: |
| 90 | 92 | Usage: required |
| @@ -98,7 +100,10 @@ to specify in a pin configuration subnode: · 7 unmodified lines | ||
| 98 | 100 | "dtest1", |
| 99 | 101 | "dtest2", |
| 100 | 102 | "dtest3", |
| 101 | − "dtest4" | |
| 103 | + "dtest4", | |
| 104 | + And following values are supported by LV/MV GPIO subtypes: | |
| 105 | + "func3", | |
| 106 | + "func4" | |
| 102 | 107 | |
| 103 | 108 | - bias-disable: |
| 104 | 109 | Usage: optional |
| @@ -183,6 +188,25 @@ to specify in a pin configuration subnode: · 78 unmodified lines | ||
| 183 | 188 | Value type: <none> |
| 184 | 189 | Definition: The specified pins are configured in open-source mode. |
| 185 | 190 | |
| 191 | +- qcom,analog-pass: | |
| 192 | + Usage: optional | |
| 193 | + Value type: <none> | |
| 194 | + Definition: The specified pins are configured in analog-pass-through mode. | |
| 195 | + | |
| 196 | +- qcom,atest: | |
| 197 | + Usage: optional | |
| 198 | + Value type: <u32> | |
| 199 | + Definition: Selects ATEST rail to route to GPIO when it's configured | |
| 200 | + in analog-pass-through mode. | |
| 201 | + Valid values are 1-4 corresponding to ATEST1 to ATEST4. | |
| 202 | + | |
| 203 | +- qcom,dtest-buffer: | |
| 204 | + Usage: optional | |
| 205 | + Value type: <u32> | |
| 206 | + Definition: Selects DTEST rail to route to GPIO when it's configured | |
| 207 | + as digital input. | |
| 208 | + Valid values are 1-4 corresponding to DTEST1 to DTEST4. | |
| 209 | + | |
| 186 | 210 | Example: |
| 187 | 211 | |
| 188 | 212 | pm8921_gpio: gpio@150 { |
| @@ -24,6 +24,7 @@ Required Properties: · 23 unmodified lines | ||
| 24 | 24 | - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. |
| 25 | 25 | - "renesas,pfc-r8a7795": for R8A7795 (R-Car H3) compatible pin-controller. |
| 26 | 26 | - "renesas,pfc-r8a7796": for R8A7796 (R-Car M3-W) compatible pin-controller. |
| 27 | + - "renesas,pfc-r8a77995": for R8A77995 (R-Car D3) compatible pin-controller. | |
| 27 | 28 | - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. |
| 28 | 29 | |
| 29 | 30 | - reg: Base address and length of each memory resource used by the pin |
| @@ -111,7 +112,7 @@ Examples · 81 unmodified lines | ||
| 111 | 112 | |
| 112 | 113 | Example 1: SH73A0 (SH-Mobile AG5) pin controller node |
| 113 | 114 | |
| 114 | − pfc: pfc@e6050000 { | |
| 115 | + pfc: pin-controller@e6050000 { | |
| 115 | 116 | compatible = "renesas,pfc-sh73a0"; |
| 116 | 117 | reg = <0xe6050000 0x8000>, |
| 117 | 118 | <0xe605801c 0x1c>; |
| @@ -172,5 +173,4 @@ Example 4: KZM-A9-GT (SH-Mobile AG5) default pin state for the MMCIF device · 54 unmodified lines | ||
| 172 | 173 | |
| 173 | 174 | bus-width = <8>; |
| 174 | 175 | vmmc-supply = <®_1p8v>; |
| 175 | − status = "okay"; | |
| 176 | 176 | }; |
| @@ -24,6 +24,7 @@ Required properties for iomux controller: · 23 unmodified lines | ||
| 24 | 24 | "rockchip,rk2928-pinctrl": for Rockchip RK2928 |
| 25 | 25 | "rockchip,rk3066a-pinctrl": for Rockchip RK3066a |
| 26 | 26 | "rockchip,rk3066b-pinctrl": for Rockchip RK3066b |
| 27 | + "rockchip,rk3128-pinctrl": for Rockchip RK3128 | |
| 27 | 28 | "rockchip,rk3188-pinctrl": for Rockchip RK3188 |
| 28 | 29 | "rockchip,rk3228-pinctrl": for Rockchip RK3228 |
| 29 | 30 | "rockchip,rk3288-pinctrl": for Rockchip RK3288 |
| @@ -120,7 +121,6 @@ uart2: serial@20064000 { · 90 unmodified lines | ||
| 120 | 121 | reg-shift = <2>; |
| 121 | 122 | reg-io-width = <1>; |
| 122 | 123 | clocks = <&mux_uart2>; |
| 123 | − status = "okay"; | |
| 124 | 124 | |
| 125 | 125 | pinctrl-names = "default"; |
| 126 | 126 | pinctrl-0 = <&uart2_xfer>; |
| @@ -0,0 +1,83 @@ | ||
| 1 | +* Spreadtrum Pin Controller | |
| 2 | + | |
| 3 | +The Spreadtrum pin controller are organized in 3 blocks (types). | |
| 4 | + | |
| 5 | +The first block comprises some global control registers, and each | |
| 6 | +register contains several bit fields with one bit or several bits | |
| 7 | +to configure for some global common configuration, such as domain | |
| 8 | +pad driving level, system control select and so on ("domain pad | |
| 9 | +driving level": One pin can output 3.0v or 1.8v, depending on the | |
| 10 | +related domain pad driving selection, if the related domain pad | |
| 11 | +slect 3.0v, then the pin can output 3.0v. "system control" is used | |
| 12 | +to choose one function (like: UART0) for which system, since we | |
| 13 | +have several systems (AP/CP/CM4) on one SoC.). | |
| 14 | + | |
| 15 | +There are too much various configuration that we can not list all | |
| 16 | +of them, so we can not make every Spreadtrum-special configuration | |
| 17 | +as one generic configuration, and maybe it will add more strange | |
| 18 | +global configuration in future. Then we add one "sprd,control" to | |
| 19 | +set these various global control configuration, and we need use | |
| 20 | +magic number for this property. | |
| 21 | + | |
| 22 | +Moreover we recognise every fields comprising one bit or several | |
| 23 | +bits in one global control register as one pin, thus we should | |
| 24 | +record every pin's bit offset, bit width and register offset to | |
| 25 | +configure this field (pin). | |
| 26 | + | |
| 27 | +The second block comprises some common registers which have unified | |
| 28 | +register definition, and each register described one pin is used | |
| 29 | +to configure the pin sleep mode, function select and sleep related | |
| 30 | +configuration. | |
| 31 | + | |
| 32 | +Now we have 4 systems for sleep mode on SC9860 SoC: AP system, | |
| 33 | +PUBCP system, TGLDSP system and AGDSP system. And the pin sleep | |
| 34 | +related configuration are: | |
| 35 | +- input-enable | |
| 36 | +- input-disable | |
| 37 | +- output-high | |
| 38 | +- output-low | |
| 39 | +- bias-pull-up | |
| 40 | +- bias-pull-down | |
| 41 | + | |
| 42 | +In some situation we need set the pin sleep mode and pin sleep related | |
| 43 | +configuration, to set the pin sleep related configuration automatically | |
| 44 | +by hardware when the system specified by sleep mode goes into deep | |
| 45 | +sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP | |
| 46 | +and set the pin sleep related configuration as "input-enable", which | |
| 47 | +means when PUBCP system goes into deep sleep mode, this pin will be set | |
| 48 | +input enable automatically. | |
| 49 | + | |
| 50 | +Moreover we can not use the "sleep" state, since some systems (like: | |
| 51 | +PUBCP system) do not run linux kernel OS (only AP system run linux | |
| 52 | +kernel on SC9860 platform), then we can not select "sleep" state | |
| 53 | +when the PUBCP system goes into deep sleep mode. Thus we introduce | |
| 54 | +"sprd,sleep-mode" property to set pin sleep mode. | |
| 55 | + | |
| 56 | +The last block comprises some misc registers which also have unified | |
| 57 | +register definition, and each register described one pin is used to | |
| 58 | +configure drive strength, pull up/down and so on. Especially for pull | |
| 59 | +up, we have two kind pull up resistor: 20K and 4.7K. | |
| 60 | + | |
| 61 | +Required properties for Spreadtrum pin controller: | |
| 62 | +- compatible: "sprd,<soc>-pinctrl" | |
| 63 | + Please refer to each sprd,<soc>-pinctrl.txt binding doc for supported SoCs. | |
| 64 | +- reg: The register address of pin controller device. | |
| 65 | +- pins : An array of pin names. | |
| 66 | + | |
| 67 | +Optional properties: | |
| 68 | +- function: Specified the function name. | |
| 69 | +- drive-strength: Drive strength in mA. | |
| 70 | +- input-schmitt-disable: Enable schmitt-trigger mode. | |
| 71 | +- input-schmitt-enable: Disable schmitt-trigger mode. | |
| 72 | +- bias-disable: Disable pin bias. | |
| 73 | +- bias-pull-down: Pull down on pin. | |
| 74 | +- bias-pull-up: Pull up on pin. | |
| 75 | +- input-enable: Enable pin input. | |
| 76 | +- input-disable: Enable pin output. | |
| 77 | +- output-high: Set the pin as an output level high. | |
| 78 | +- output-low: Set the pin as an output level low. | |
| 79 | +- sleep-hardware-state: Indicate these configs in this state are sleep related. | |
| 80 | +- sprd,control: Control values referring to databook for global control pins. | |
| 81 | +- sprd,sleep-mode: Sleep mode selection. | |
| 82 | + | |
| 83 | +Please refer to each sprd,<soc>-pinctrl.txt binding doc for supported values. | |
| @@ -0,0 +1,70 @@ | ||
| 1 | +* Spreadtrum SC9860 Pin Controller | |
| 2 | + | |
| 3 | +Please refer to sprd,pinctrl.txt in this directory for common binding part | |
| 4 | +and usage. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: Must be "sprd,sc9860-pinctrl". | |
| 8 | +- reg: The register address of pin controller device. | |
| 9 | +- pins : An array of strings, each string containing the name of a pin. | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | +- function: A string containing the name of the function, values must be | |
| 13 | + one of: "func1", "func2", "func3" and "func4". | |
| 14 | +- drive-strength: Drive strength in mA. Supported values: 2, 4, 6, 8, 10, | |
| 15 | + 12, 14, 16, 20, 21, 24, 25, 27, 29, 31 and 33. | |
| 16 | +- input-schmitt-disable: Enable schmitt-trigger mode. | |
| 17 | +- input-schmitt-enable: Disable schmitt-trigger mode. | |
| 18 | +- bias-disable: Disable pin bias. | |
| 19 | +- bias-pull-down: Pull down on pin. | |
| 20 | +- bias-pull-up: Pull up on pin. Supported values: 20000 for pull-up resistor | |
| 21 | + is 20K and 4700 for pull-up resistor is 4.7K. | |
| 22 | +- input-enable: Enable pin input. | |
| 23 | +- input-disable: Enable pin output. | |
| 24 | +- output-high: Set the pin as an output level high. | |
| 25 | +- output-low: Set the pin as an output level low. | |
| 26 | +- sleep-hardware-state: Indicate these configs in this state are sleep related. | |
| 27 | +- sprd,control: Control values referring to databook for global control pins. | |
| 28 | +- sprd,sleep-mode: Choose the pin sleep mode, and supported values are: | |
| 29 | + AP_SLEEP, PUBCP_SLEEP, TGLDSP_SLEEP and AGDSP_SLEEP. | |
| 30 | + | |
| 31 | +Pin sleep mode definition: | |
| 32 | +enum pin_sleep_mode { | |
| 33 | + AP_SLEEP = BIT(0), | |
| 34 | + PUBCP_SLEEP = BIT(1), | |
| 35 | + TGLDSP_SLEEP = BIT(2), | |
| 36 | + AGDSP_SLEEP = BIT(3), | |
| 37 | +}; | |
| 38 | + | |
| 39 | +Example: | |
| 40 | +pin_controller: pinctrl@402a0000 { | |
| 41 | + compatible = "sprd,sc9860-pinctrl"; | |
| 42 | + reg = <0x402a0000 0x10000>; | |
| 43 | + | |
| 44 | + grp1: sd0 { | |
| 45 | + pins = "SC9860_VIO_SD2_IRTE", "SC9860_VIO_SD0_IRTE"; | |
| 46 | + sprd,control = <0x1>; | |
| 47 | + }; | |
| 48 | + | |
| 49 | + grp2: rfctl_33 { | |
| 50 | + pins = "SC9860_RFCTL33"; | |
| 51 | + function = "func2"; | |
| 52 | + sprd,sleep-mode = <AP_SLEEP | PUBCP_SLEEP>; | |
| 53 | + grp2_sleep_mode: rfctl_33_sleep { | |
| 54 | + pins = "SC9860_RFCTL33"; | |
| 55 | + sleep-hardware-state; | |
| 56 | + output-low; | |
| 57 | + } | |
| 58 | + }; | |
| 59 | + | |
| 60 | + grp3: rfctl_misc_20 { | |
| 61 | + pins = "SC9860_RFCTL20_MISC"; | |
| 62 | + drive-strength = <10>; | |
| 63 | + bias-pull-up = <4700>; | |
| 64 | + grp3_sleep_mode: rfctl_misc_sleep { | |
| 65 | + pins = "SC9860_RFCTL20_MISC"; | |
| 66 | + sleep-hardware-state; | |
| 67 | + bias-pull-up; | |
| 68 | + } | |
| 69 | + }; | |
| 70 | +}; | |
| @@ -180,5 +180,4 @@ pin-controller { · 179 unmodified lines | ||
| 180 | 180 | &usart1 { |
| 181 | 181 | pinctrl-0 = <&usart1_pins_a>; |
| 182 | 182 | pinctrl-names = "default"; |
| 183 | − status = "okay"; | |
| 184 | 183 | }; |
| @@ -13,6 +13,5 @@ Example: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | act8846: act8846@5 { |
| 15 | 15 | compatible = "active-semi,act8846"; |
| 16 | − status = "okay"; | |
| 17 | 16 | system-power-controller; |
| 18 | 17 | } |
| @@ -1,12 +1,13 @@ | ||
| 1 | 1 | DT bindings for the Renesas Advanced Power Management Unit |
| 2 | 2 | |
| 3 | −Renesas R-Car line of SoCs utilize one or more APMU hardware units | |
| 3 | +Renesas R-Car and RZ/G1 SoCs utilize one or more APMU hardware units | |
| 4 | 4 | for CPU core power domain control including SMP boot and CPU Hotplug. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | 7 | |
| 8 | 8 | - compatible: Should be "renesas,<soctype>-apmu", "renesas,apmu" as fallback. |
| 9 | 9 | Examples with soctypes are: |
| 10 | + - "renesas,r8a7743-apmu" (RZ/G1M) | |
| 10 | 11 | - "renesas,r8a7790-apmu" (R-Car H2) |
| 11 | 12 | - "renesas,r8a7791-apmu" (R-Car M2-W) |
| 12 | 13 | - "renesas,r8a7792-apmu" (R-Car V2H) |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | - "renesas,r8a7794-sysc" (R-Car E2) |
| 18 | 18 | - "renesas,r8a7795-sysc" (R-Car H3) |
| 19 | 19 | - "renesas,r8a7796-sysc" (R-Car M3-W) |
| 20 | + - "renesas,r8a77995-sysc" (R-Car D3) | |
| 20 | 21 | - reg: Address start and address range for the device. |
| 21 | 22 | - #power-domain-cells: Must be 1. |
| 22 | 23 | |
| @@ -8,5 +8,4 @@ Example node: · 7 unmodified lines | ||
| 8 | 8 | restart { |
| 9 | 9 | compatible = "st,stih407-restart"; |
| 10 | 10 | st,syscfg = <&syscfg_sbc_reg>; |
| 11 | − status = "okay"; | |
| 12 | 11 | }; |
| @@ -39,6 +39,8 @@ Required properties: · 38 unmodified lines | ||
| 39 | 39 | - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains |
| 40 | 40 | - "rockchip,rk3399-io-voltage-domain" for rk3399 |
| 41 | 41 | - "rockchip,rk3399-pmu-io-voltage-domain" for rk3399 pmu-domains |
| 42 | + - "rockchip,rv1108-io-voltage-domain" for rv1108 | |
| 43 | + - "rockchip,rv1108-pmu-io-voltage-domain" for rv1108 pmu-domains | |
| 42 | 44 | |
| 43 | 45 | Deprecated properties: |
| 44 | 46 | - rockchip,grf: phandle to the syscon managing the "general register files" |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | ||
| 29 | 29 | pmic@5b { |
| 30 | 30 | compatible = "active-semi,act8945a"; |
| 31 | 31 | reg = <0x5b>; |
| 32 | − status = "okay"; | |
| 33 | 32 | |
| 34 | 33 | charger { |
| 35 | 34 | compatible = "active-semi,act8945a-charger"; |
| @@ -43,6 +42,5 @@ Example: · 7 unmodified lines | ||
| 43 | 42 | active-semi,input-voltage-threshold-microvolt = <6600>; |
| 44 | 43 | active-semi,precondition-timeout = <40>; |
| 45 | 44 | active-semi,total-timeout = <3>; |
| 46 | − status = "okay"; | |
| 47 | 45 | }; |
| 48 | 46 | }; |
| @@ -0,0 +1,51 @@ | ||
| 1 | +TI BQ24190 Li-Ion Battery Charger | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: contains one of the following: | |
| 5 | + * "ti,bq24190" | |
| 6 | + * "ti,bq24192i" | |
| 7 | +- reg: integer, I2C address of the charger. | |
| 8 | +- interrupts[-extended]: configuration for charger INT pin. | |
| 9 | + | |
| 10 | +Optional properties: | |
| 11 | +- monitored-battery: phandle of battery characteristics devicetree node | |
| 12 | + The charger uses the following battery properties: | |
| 13 | + + precharge-current-microamp: maximum charge current during precharge | |
| 14 | + phase (typically 20% of battery capacity). | |
| 15 | + + charge-term-current-microamp: a charge cycle terminates when the | |
| 16 | + battery voltage is above recharge threshold, and the current is below | |
| 17 | + this setting (typically 10% of battery capacity). | |
| 18 | + See also Documentation/devicetree/bindings/power/supply/battery.txt | |
| 19 | +- ti,system-minimum-microvolt: when power is connected and the battery is below | |
| 20 | + minimum system voltage, the system will be regulated above this setting. | |
| 21 | + | |
| 22 | +Notes: | |
| 23 | +- Some circuit boards wire the chip's "OTG" pin high (enabling 500mA default | |
| 24 | + charge current on USB SDP ports, among other features). To simulate this on | |
| 25 | + boards that wire the pin to a GPIO, set a gpio-hog. | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + | |
| 29 | + bat: battery { | |
| 30 | + compatible = "simple-battery"; | |
| 31 | + precharge-current-microamp = <256000>; | |
| 32 | + charge-term-current-microamp = <128000>; | |
| 33 | + // etc. | |
| 34 | + }; | |
| 35 | + | |
| 36 | + bq24190: charger@6a { | |
| 37 | + compatible = "ti,bq24190"; | |
| 38 | + reg = <0x6a>; | |
| 39 | + interrupts-extended = <&gpiochip 10 IRQ_TYPE_EDGE_FALLING>; | |
| 40 | + monitored-battery = <&bat>; | |
| 41 | + ti,system-minimum-microvolt = <3200000>; | |
| 42 | + }; | |
| 43 | + | |
| 44 | + &twl_gpio { | |
| 45 | + otg { | |
| 46 | + gpio-hog; | |
| 47 | + gpios = <6 0>; | |
| 48 | + output-high; | |
| 49 | + line-name = "otg-gpio"; | |
| 50 | + }; | |
| 51 | + }; | |
| @@ -1,13 +1,14 @@ | ||
| 1 | −binding for LTC2941 and LTC2943 battery gauges | |
| 1 | +binding for LTC2941, LTC2942, LTC2943 and LTC2944 battery gauges | |
| 2 | 2 | |
| 3 | −Both the LTC2941 and LTC2943 measure battery capacity. | |
| 4 | −The LTC2943 is compatible with the LTC2941, it adds voltage and | |
| 5 | −temperature monitoring, and uses a slightly different conversion | |
| 6 | −formula for the charge counter. | |
| 3 | +All chips measure battery capacity. | |
| 4 | +The LTC2942 is pin compatible with the LTC2941, it adds voltage and | |
| 5 | +temperature monitoring, and is runtime detected. LTC2943 and LTC2944 | |
| 6 | +is software compatible, uses a slightly different conversion formula | |
| 7 | +for the charge counter and adds voltage, current and temperature monitoring. | |
| 7 | 8 | |
| 8 | 9 | Required properties: |
| 9 | −- compatible: Should contain "lltc,ltc2941" or "lltc,ltc2943" which also | |
| 10 | − indicates the type of I2C chip attached. | |
| 10 | +- compatible: Should contain "lltc,ltc2941", "lltc,ltc2942", "lltc,ltc2943" | |
| 11 | + or "lltc,ltc2944" which also indicates the type of I2C chip attached. | |
| 11 | 12 | - reg: The 7-bit I2C address. |
| 12 | 13 | - lltc,resistor-sense: The sense resistor value in milli-ohms. Can be a 32-bit |
| 13 | 14 | negative value when the battery has been connected to the wrong end of the |
| @@ -21,5 +21,4 @@ Example: · 20 unmodified lines | ||
| 21 | 21 | flt-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>; |
| 22 | 22 | chg-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; |
| 23 | 23 | cen-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; |
| 24 | − status = "okay"; | |
| 25 | 24 | }; |
| @@ -12,7 +12,6 @@ Example: · 11 unmodified lines | ||
| 12 | 12 | clock-frequency = <50000>; |
| 13 | 13 | pinctrl-names = "default"; |
| 14 | 14 | pinctrl-0 = <&pinctrl_i2c2>; |
| 15 | − status = "okay"; | |
| 16 | 15 | |
| 17 | 16 | max14656@35 { |
| 18 | 17 | compatible = "maxim,max14656"; |
| @@ -20,13 +20,12 @@ List of legacy properties and respective binding document · 19 unmodified lines | ||
| 20 | 20 | 1. "enable-sdio-wakeup" Documentation/devicetree/bindings/mmc/mmc.txt |
| 21 | 21 | 2. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt |
| 22 | 22 | 3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt |
| 23 | −4. "isil,irq2-can-wakeup-machine" Documentation/devicetree/bindings/rtc/isil,isl12057.txt | |
| 24 | −5. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt | |
| 23 | +4. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt | |
| 25 | 24 | Documentation/devicetree/bindings/mfd/tc3589x.txt |
| 26 | 25 | Documentation/devicetree/bindings/input/ads7846.txt |
| 27 | −6. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt | |
| 28 | −7. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt | |
| 29 | −8. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | |
| 26 | +5. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt | |
| 27 | +6. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt | |
| 28 | +7. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | |
| 30 | 29 | |
| 31 | 30 | Examples |
| 32 | 31 | -------- |
| @@ -0,0 +1,22 @@ | ||
| 1 | +* IBM Powerpc Virtual Accelerator Switchboard (VAS) | |
| 2 | + | |
| 3 | +VAS is a hardware mechanism that allows kernel subsystems and user processes | |
| 4 | +to directly submit compression and other requests to Nest accelerators (NX) | |
| 5 | +or other coprocessors functions. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : should be "ibm,vas". | |
| 9 | +- ibm,vas-id : A unique identifier for each instance of VAS in the system | |
| 10 | +- reg : Should contain 4 pairs of 64-bit fields specifying the Hypervisor | |
| 11 | + window context start and length, OS/User window context start and length, | |
| 12 | + "Paste address" start and length, "Paste window id" start bit and number | |
| 13 | + of bits) | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | + vas@6019100000000 { | |
| 18 | + compatible = "ibm,vas", "ibm,power9-vas"; | |
| 19 | + reg = <0x6019100000000 0x2000000 0x6019000000000 0x100000000 0x8000000000000 0x100000000 0x20 0x10>; | |
| 20 | + name = "vas"; | |
| 21 | + ibm,vas-id = <0x1>; | |
| 22 | + }; | |
| @@ -0,0 +1,27 @@ | ||
| 1 | +IBM OPAL Sensor Groups Binding | |
| 2 | +------------------------------- | |
| 3 | + | |
| 4 | +Node: /ibm,opal/sensor-groups | |
| 5 | + | |
| 6 | +Description: Contains sensor groups available in the Powernv P9 | |
| 7 | +servers. Each child node indicates a sensor group. | |
| 8 | + | |
| 9 | +- compatible : Should be "ibm,opal-sensor-group" | |
| 10 | + | |
| 11 | +Each child node contains below properties: | |
| 12 | + | |
| 13 | +- type : String to indicate the type of sensor-group | |
| 14 | + | |
| 15 | +- sensor-group-id: Abstract unique identifier provided by firmware of | |
| 16 | + type <u32> which is used for sensor-group | |
| 17 | + operations like clearing the min/max history of all | |
| 18 | + sensors belonging to the group. | |
| 19 | + | |
| 20 | +- ibm,chip-id : Chip ID | |
| 21 | + | |
| 22 | +- sensors : Phandle array of child nodes of /ibm,opal/sensor/ | |
| 23 | + belonging to this group | |
| 24 | + | |
| 25 | +- ops : Array of opal-call numbers indicating available operations on | |
| 26 | + sensor groups like clearing min/max, enabling/disabling sensor | |
| 27 | + group. | |
| @@ -13,8 +13,12 @@ Optional properties: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | Example: |
| 15 | 15 | pps { |
| 16 | − compatible = "pps-gpio"; | |
| 17 | − gpios = <&gpio2 6 0>; | |
| 16 | + pinctrl-names = "default"; | |
| 17 | + pinctrl-0 = <&pinctrl_pps>; | |
| 18 | 18 | |
| 19 | + gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; | |
| 19 | 20 | assert-falling-edge; |
| 21 | + | |
| 22 | + compatible = "pps-gpio"; | |
| 23 | + status = "okay"; | |
| 20 | 24 | }; |
| @@ -16,5 +16,4 @@ Example: · 15 unmodified lines | ||
| 16 | 16 | ptp: ptp-dte@180af650 { |
| 17 | 17 | compatible = "brcm,iproc-ptp-dte", "brcm,ptp-dte"; |
| 18 | 18 | reg = <0x180af650 0x10>; |
| 19 | − status = "okay"; | |
| 20 | 19 | }; |
| @@ -6,7 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - clocks: This clock defines the base clock frequency of the PWM hardware |
| 7 | 7 | system, the period and the duty_cycle of the PWM signal is a multiple of |
| 8 | 8 | the base period. |
| 9 | −- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of | |
| 9 | +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of | |
| 10 | 10 | the cells format. |
| 11 | 11 | |
| 12 | 12 | Examples: |
| @@ -15,7 +15,7 @@ pwm@2020c000 { · 2 unmodified lines | ||
| 15 | 15 | compatible = "brcm,bcm2835-pwm"; |
| 16 | 16 | reg = <0x2020c000 0x28>; |
| 17 | 17 | clocks = <&clk_pwm>; |
| 18 | − #pwm-cells = <2>; | |
| 18 | + #pwm-cells = <3>; | |
| 19 | 19 | }; |
| 20 | 20 | |
| 21 | 21 | clocks { |
| @@ -2,6 +2,8 @@ MediaTek PWM controller · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: should be "mediatek,<name>-pwm": |
| 5 | + - "mediatek,mt2712-pwm": found on mt2712 SoC. | |
| 6 | + - "mediatek,mt7622-pwm": found on mt7622 SoC. | |
| 5 | 7 | - "mediatek,mt7623-pwm": found on mt7623 SoC. |
| 6 | 8 | - reg: physical base address and length of the controller's registers. |
| 7 | 9 | - #pwm-cells: must be 2. See pwm.txt in this directory for a description of |
| @@ -10,7 +12,9 @@ Required properties: · 2 unmodified lines | ||
| 10 | 12 | - clock-names: must contain the following: |
| 11 | 13 | - "top": the top clock generator |
| 12 | 14 | - "main": clock used by the PWM core |
| 13 | − - "pwm1-5": the five per PWM clocks | |
| 15 | + - "pwm1-8": the eight per PWM clocks for mt2712 | |
| 16 | + - "pwm1-6": the six per PWM clocks for mt7622 | |
| 17 | + - "pwm1-5": the five per PWM clocks for mt7623 | |
| 14 | 18 | - pinctrl-names: Must contain a "default" entry. |
| 15 | 19 | - pinctrl-0: One property must exist for each entry in pinctrl-names. |
| 16 | 20 | See pinctrl/pinctrl-bindings.txt for details of the property values. |
| @@ -19,7 +19,6 @@ Example: · 18 unmodified lines | ||
| 19 | 19 | compatible = "amlogic,meson-gxbb-pwm"; |
| 20 | 20 | reg = <0x0 0x08550 0x0 0x10>; |
| 21 | 21 | #pwm-cells = <3>; |
| 22 | − status = "disabled"; | |
| 23 | 22 | clocks = <&xtal>, <&xtal>; |
| 24 | 23 | clock-names = "clkin0", "clkin1"; |
| 25 | 24 | } |
| @@ -3,10 +3,17 @@ Rockchip PWM controller · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: should be "rockchip,<name>-pwm" |
| 5 | 5 | "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs |
| 6 | − "rockchip,rk3288-pwm": found on RK3288 SoC | |
| 6 | + "rockchip,rk3288-pwm": found on RK3288 SOC | |
| 7 | + "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC | |
| 7 | 8 | "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC |
| 8 | 9 | - reg: physical base address and length of the controller's registers |
| 9 | − - clocks: phandle and clock specifier of the PWM reference clock | |
| 10 | + - clocks: See ../clock/clock-bindings.txt | |
| 11 | + - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399): | |
| 12 | + - There is one clock that's used both to derive the functional clock | |
| 13 | + for the device and as the bus clock. | |
| 14 | + - For newer hardware (rk3328 and future socs): specified by name | |
| 15 | + - "pwm": This is used to derive the functional clock. | |
| 16 | + - "pclk": This is the APB bus clock. | |
| 10 | 17 | - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.txt in this directory |
| 11 | 18 | for a description of the cell format. |
| 12 | 19 | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +STMicroelectronics STM32 Low-Power Timer PWM | |
| 2 | + | |
| 3 | +STM32 Low-Power Timer provides single channel PWM. | |
| 4 | + | |
| 5 | +Must be a sub-node of an STM32 Low-Power Timer device tree node. | |
| 6 | +See ../mfd/stm32-lptimer.txt for details about the parent node. | |
| 7 | + | |
| 8 | +Required parameters: | |
| 9 | +- compatible: Must be "st,stm32-pwm-lp". | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | +- pinctrl-names: Set to "default". | |
| 13 | +- pinctrl-0: Phandle pointing to pin configuration node for PWM. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + timer@40002400 { | |
| 17 | + compatible = "st,stm32-lptimer"; | |
| 18 | + ... | |
| 19 | + pwm { | |
| 20 | + compatible = "st,stm32-pwm-lp"; | |
| 21 | + pinctrl-names = "default"; | |
| 22 | + pinctrl-0 = <&lppwm1_pins>; | |
| 23 | + }; | |
| 24 | + }; | |
| @@ -19,5 +19,4 @@ Example: · 18 unmodified lines | ||
| 19 | 19 | reg = <0x01c20e00 0xc>; |
| 20 | 20 | clocks = <&osc24M>; |
| 21 | 21 | #pwm-cells = <3>; |
| 22 | − status = "disabled"; | |
| 23 | 22 | }; |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | for am4372 - compatible = "ti,am4372-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; |
| 7 | 7 | for da850 - compatible = "ti,da850-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; |
| 8 | 8 | for dra746 - compatible = "ti,dra746-ecap", "ti,am3352-ecap"; |
| 9 | + for 66ak2g - compatible = "ti,k2g-ecap", "ti,am3352-ecap"; | |
| 9 | 10 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
| 10 | 11 | the cells format. The PWM channel index ranges from 0 to 4. The only third |
| 11 | 12 | cell flag supported by this binding is PWM_POLARITY_INVERTED. |
| @@ -26,7 +26,6 @@ epwmss0: epwmss@48300000 { /* PWMSS for am33xx */ · 25 unmodified lines | ||
| 26 | 26 | ti,hwmods = "epwmss0"; |
| 27 | 27 | #address-cells = <1>; |
| 28 | 28 | #size-cells = <1>; |
| 29 | − status = "disabled"; | |
| 30 | 29 | ranges = <0x48300100 0x48300100 0x80 /* ECAP */ |
| 31 | 30 | 0x48300180 0x48300180 0x80 /* EQEP */ |
| 32 | 31 | 0x48300200 0x48300200 0x80>; /* EHRPWM */ |
| @@ -40,7 +39,6 @@ epwmss0: epwmss@48300000 { /* PWMSS for am4372 */ · 7 unmodified lines | ||
| 40 | 39 | ti,hwmods = "epwmss0"; |
| 41 | 40 | #address-cells = <1>; |
| 42 | 41 | #size-cells = <1>; |
| 43 | − status = "disabled"; | |
| 44 | 42 | ranges = <0x48300100 0x48300100 0x80 /* ECAP */ |
| 45 | 43 | 0x48300180 0x48300180 0x80 /* EQEP */ |
| 46 | 44 | 0x48300200 0x48300200 0x80>; /* EHRPWM */ |
| @@ -0,0 +1,22 @@ | ||
| 1 | +ZTE ZX PWM controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be "zte,zx296718-pwm". | |
| 5 | + - reg: Physical base address and length of the controller's registers. | |
| 6 | + - clocks : The phandle and specifier referencing the controller's clocks. | |
| 7 | + - clock-names: "pclk" for PCLK, "wclk" for WCLK to the PWM controller. The | |
| 8 | + PCLK is for register access, while WCLK is the reference clock for | |
| 9 | + calculating period and duty cycles. | |
| 10 | + - #pwm-cells: Should be 3. See pwm.txt in this directory for a description of | |
| 11 | + the cells format. | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | + pwm: pwm@1439000 { | |
| 16 | + compatible = "zte,zx296718-pwm"; | |
| 17 | + reg = <0x1439000 0x1000>; | |
| 18 | + clocks = <&lsp1crm LSP1_PWM_PCLK>, | |
| 19 | + <&lsp1crm LSP1_PWM_WCLK>; | |
| 20 | + clock-names = "pclk", "wclk"; | |
| 21 | + #pwm-cells = <3>; | |
| 22 | + }; | |
| @@ -6,7 +6,6 @@ Required Properties: · 5 unmodified lines | ||
| 6 | 6 | - "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller. |
| 7 | 7 | - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller. |
| 8 | 8 | - "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller. |
| 9 | − - "renesas,tpu-sh7372": for SH7372 (SH-Mobile AP4) compatible PWM controller. | |
| 10 | 9 | - "renesas,tpu": for generic R-Car TPU PWM controller. |
| 11 | 10 | |
| 12 | 11 | - reg: Base address and length of each memory resource used by the PWM |
| @@ -52,7 +52,6 @@ Example: · 51 unmodified lines | ||
| 52 | 52 | compatible = "active-semi,act8865"; |
| 53 | 53 | reg = <0x5b>; |
| 54 | 54 | active-semi,vsel-high; |
| 55 | − status = "disabled"; | |
| 56 | 55 | |
| 57 | 56 | regulators { |
| 58 | 57 | vcc_1v8_reg: DCDC_REG1 { |
| @@ -23,7 +23,6 @@ Example: · 22 unmodified lines | ||
| 23 | 23 | pmic@5b { |
| 24 | 24 | compatible = "active-semi,act8945a"; |
| 25 | 25 | reg = <0x5b>; |
| 26 | − status = "okay"; | |
| 27 | 26 | |
| 28 | 27 | active-semi,vsel-high; |
| 29 | 28 | |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Mediatek MT6311 Regulator Driver | |
| 1 | +Mediatek MT6311 Regulator | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: "mediatek,mt6311-regulator" |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Mediatek MT6323 Regulator Driver | |
| 1 | +Mediatek MT6323 Regulator | |
| 2 | 2 | |
| 3 | 3 | All voltage regulators are defined as subnodes of the regulators node. A list |
| 4 | 4 | of regulators provided by this controller are defined as subnodes of the |
| @@ -0,0 +1,89 @@ | ||
| 1 | +MediaTek MT6380 Regulator | |
| 2 | + | |
| 3 | +All voltage regulators provided by the MT6380 PMIC are described as the | |
| 4 | +subnodes of the MT6380 regulators node. Each regulator is named according | |
| 5 | +to its regulator type, buck-<name> and ldo-<name>. The definition for each | |
| 6 | +of these nodes is defined using the standard binding for regulators at | |
| 7 | +Documentation/devicetree/bindings/regulator/regulator.txt. | |
| 8 | + | |
| 9 | +The valid names for regulators are: | |
| 10 | +BUCK: | |
| 11 | + buck-core1, buck-vcore, buck-vrf | |
| 12 | +LDO: | |
| 13 | + ldo-vm ,ldo-va , ldo-vphy, ldo-vddr, ldo-vt | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | + regulators { | |
| 18 | + compatible = "mediatek,mt6380-regulator"; | |
| 19 | + | |
| 20 | + mt6380_vcpu_reg: buck-vcore1 { | |
| 21 | + regulator-name = "vcore1"; | |
| 22 | + regulator-min-microvolt = < 600000>; | |
| 23 | + regulator-max-microvolt = <1393750>; | |
| 24 | + regulator-ramp-delay = <6250>; | |
| 25 | + regulator-always-on; | |
| 26 | + regulator-boot-on; | |
| 27 | + }; | |
| 28 | + | |
| 29 | + mt6380_vcore_reg: buck-vcore { | |
| 30 | + regulator-name = "vcore"; | |
| 31 | + regulator-min-microvolt = <600000>; | |
| 32 | + regulator-max-microvolt = <1393750>; | |
| 33 | + regulator-ramp-delay = <6250>; | |
| 34 | + }; | |
| 35 | + | |
| 36 | + mt6380_vrf_reg: buck-vrf { | |
| 37 | + regulator-name = "vrf"; | |
| 38 | + regulator-min-microvolt = <1200000>; | |
| 39 | + regulator-max-microvolt = <1575000>; | |
| 40 | + regulator-ramp-delay = <0>; | |
| 41 | + regulator-always-on; | |
| 42 | + regulator-boot-on; | |
| 43 | + }; | |
| 44 | + | |
| 45 | + mt6380_vm_reg: ldo-vm { | |
| 46 | + regulator-name = "vm"; | |
| 47 | + regulator-min-microvolt = <1050000>; | |
| 48 | + regulator-max-microvolt = <1400000>; | |
| 49 | + regulator-ramp-delay = <0>; | |
| 50 | + regulator-always-on; | |
| 51 | + regulator-boot-on; | |
| 52 | + }; | |
| 53 | + | |
| 54 | + mt6380_va_reg: ldo-va { | |
| 55 | + regulator-name = "va"; | |
| 56 | + regulator-min-microvolt = <2200000>; | |
| 57 | + regulator-max-microvolt = <3300000>; | |
| 58 | + regulator-ramp-delay = <0>; | |
| 59 | + regulator-always-on; | |
| 60 | + regulator-boot-on; | |
| 61 | + }; | |
| 62 | + | |
| 63 | + mt6380_vphy_reg: ldo-vphy { | |
| 64 | + regulator-name = "vphy"; | |
| 65 | + regulator-min-microvolt = <1800000>; | |
| 66 | + regulator-max-microvolt = <1800000>; | |
| 67 | + regulator-ramp-delay = <0>; | |
| 68 | + regulator-always-on; | |
| 69 | + regulator-boot-on; | |
| 70 | + }; | |
| 71 | + | |
| 72 | + mt6380_vddr_reg: ldo-vddr { | |
| 73 | + regulator-name = "vddr"; | |
| 74 | + regulator-min-microvolt = <1240000>; | |
| 75 | + regulator-max-microvolt = <1840000>; | |
| 76 | + regulator-ramp-delay = <0>; | |
| 77 | + regulator-always-on; | |
| 78 | + regulator-boot-on; | |
| 79 | + }; | |
| 80 | + | |
| 81 | + mt6380_vt_reg: ldo-vt { | |
| 82 | + regulator-name = "vt"; | |
| 83 | + regulator-min-microvolt = <2200000>; | |
| 84 | + regulator-max-microvolt = <3300000>; | |
| 85 | + regulator-ramp-delay = <0>; | |
| 86 | + regulator-always-on; | |
| 87 | + regulator-boot-on; | |
| 88 | + }; | |
| 89 | + }; | |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Mediatek MT6397 Regulator Driver | |
| 1 | +Mediatek MT6397 Regulator | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: "mediatek,mt6397-regulator" |
| @@ -71,7 +71,7 @@ Continuous Voltage With Enable GPIO Example: · 70 unmodified lines | ||
| 71 | 71 | * Inverted PWM logic, and the duty cycle range is limited |
| 72 | 72 | * to 30%-70%. |
| 73 | 73 | */ |
| 74 | − pwm-dutycycle-range <700 300>; /* */ | |
| 74 | + pwm-dutycycle-range = <700 300>; /* */ | |
| 75 | 75 | }; |
| 76 | 76 | |
| 77 | 77 | Voltage Table Example: |
| @@ -0,0 +1,20 @@ | ||
| 1 | +STM32 VREFBUF - Voltage reference buffer | |
| 2 | + | |
| 3 | +Some STM32 devices embed a voltage reference buffer which can be used as | |
| 4 | +voltage reference for ADCs, DACs and also as voltage reference for external | |
| 5 | +components through the dedicated VREF+ pin. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: Must be "st,stm32-vrefbuf". | |
| 9 | +- reg: Offset and length of VREFBUF register set. | |
| 10 | +- clocks: Must contain an entry for peripheral clock. | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + vrefbuf: regulator@58003C00 { | |
| 14 | + compatible = "st,stm32-vrefbuf"; | |
| 15 | + reg = <0x58003C00 0x8>; | |
| 16 | + clocks = <&rcc VREF_CK>; | |
| 17 | + regulator-min-microvolt = <1500000>; | |
| 18 | + regulator-max-microvolt = <2500000>; | |
| 19 | + vdda-supply = <&vdda>; | |
| 20 | + }; | |
| @@ -0,0 +1,33 @@ | ||
| 1 | +NXP iMX6SX/iMX7D Co-Processor Bindings | |
| 2 | +---------------------------------------- | |
| 3 | + | |
| 4 | +This binding provides support for ARM Cortex M4 Co-processor found on some | |
| 5 | +NXP iMX SoCs. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible Should be one of: | |
| 9 | + "fsl,imx7d-cm4" | |
| 10 | + "fsl,imx6sx-cm4" | |
| 11 | +- clocks Clock for co-processor (See: ../clock/clock-bindings.txt) | |
| 12 | +- syscon Phandle to syscon block which provide access to | |
| 13 | + System Reset Controller | |
| 14 | + | |
| 15 | +Optional properties: | |
| 16 | +- memory-region list of phandels to the reserved memory regions. | |
| 17 | + (See: ../reserved-memory/reserved-memory.txt) | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + m4_reserved_sysmem1: cm4@80000000 { | |
| 21 | + reg = <0x80000000 0x80000>; | |
| 22 | + }; | |
| 23 | + | |
| 24 | + m4_reserved_sysmem2: cm4@81000000 { | |
| 25 | + reg = <0x81000000 0x80000>; | |
| 26 | + }; | |
| 27 | + | |
| 28 | + imx7d-cm4 { | |
| 29 | + compatible = "fsl,imx7d-cm4"; | |
| 30 | + memory-region = <&m4_reserved_sysmem1>, <&m4_reserved_sysmem2>; | |
| 31 | + syscon = <&src>; | |
| 32 | + clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>; | |
| 33 | + }; | |
| @@ -63,9 +63,10 @@ on the Qualcomm ADSP Hexagon core. · 62 unmodified lines | ||
| 63 | 63 | |
| 64 | 64 | |
| 65 | 65 | = SUBNODES |
| 66 | −The adsp node may have an subnode named "smd-edge" that describes the SMD edge, | |
| 67 | −channels and devices related to the ADSP. See ../soc/qcom/qcom,smd.txt for | |
| 68 | −details on how to describe the SMD edge. | |
| 66 | +The adsp node may have an subnode named either "smd-edge" or "glink-edge" that | |
| 67 | +describes the communication edge, channels and devices related to the ADSP. | |
| 68 | +See ../soc/qcom/qcom,smd.txt and ../soc/qcom/qcom,glink.txt for details on how | |
| 69 | +to describe these. | |
| 69 | 70 | |
| 70 | 71 | |
| 71 | 72 | = EXAMPLE |
| @@ -90,6 +90,11 @@ the memory regions used by the Hexagon firmware. Each sub-node must contain: · 89 unmodified lines | ||
| 90 | 90 | Value type: <phandle> |
| 91 | 91 | Definition: reference to the reserved-memory for the region |
| 92 | 92 | |
| 93 | +The Hexagon node may also have an subnode named either "smd-edge" or | |
| 94 | +"glink-edge" that describes the communication edge, channels and devices | |
| 95 | +related to the Hexagon. See ../soc/qcom/qcom,smd.txt and | |
| 96 | +../soc/qcom/qcom,glink.txt for details on how to describe these. | |
| 97 | + | |
| 93 | 98 | = EXAMPLE |
| 94 | 99 | The following example describes the resources needed to boot control the |
| 95 | 100 | Hexagon, as it is found on MSM8974 boards. |
| @@ -0,0 +1,86 @@ | ||
| 1 | +TI Davinci DSP devices | |
| 2 | +======================= | |
| 3 | + | |
| 4 | +Binding status: Unstable - Subject to changes for DT representation of clocks | |
| 5 | + and resets | |
| 6 | + | |
| 7 | +The TI Davinci family of SoCs usually contains a TI DSP Core sub-system that | |
| 8 | +is used to offload some of the processor-intensive tasks or algorithms, for | |
| 9 | +achieving various system level goals. | |
| 10 | + | |
| 11 | +The processor cores in the sub-system usually contain additional sub-modules | |
| 12 | +like L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory | |
| 13 | +controller, a dedicated local power/sleep controller etc. The DSP processor | |
| 14 | +core used in Davinci SoCs is usually a C674x DSP CPU. | |
| 15 | + | |
| 16 | +DSP Device Node: | |
| 17 | +================ | |
| 18 | +Each DSP Core sub-system is represented as a single DT node. | |
| 19 | + | |
| 20 | +Required properties: | |
| 21 | +-------------------- | |
| 22 | +The following are the mandatory properties: | |
| 23 | + | |
| 24 | +- compatible: Should be one of the following, | |
| 25 | + "ti,da850-dsp" for DSPs on OMAP-L138 SoCs | |
| 26 | + | |
| 27 | +- reg: Should contain an entry for each value in 'reg-names'. | |
| 28 | + Each entry should have the memory region's start address | |
| 29 | + and the size of the region, the representation matching | |
| 30 | + the parent node's '#address-cells' and '#size-cells' values. | |
| 31 | + | |
| 32 | +- reg-names: Should contain strings with the following names, each | |
| 33 | + representing a specific internal memory region or a | |
| 34 | + specific register space, | |
| 35 | + "l2sram", "l1pram", "l1dram", "host1cfg", "chipsig_base" | |
| 36 | + | |
| 37 | +- interrupts: Should contain the interrupt number used to receive the | |
| 38 | + interrupts from the DSP. The value should follow the | |
| 39 | + interrupt-specifier format as dictated by the | |
| 40 | + 'interrupt-parent' node. | |
| 41 | + | |
| 42 | +- memory-region: phandle to the reserved memory node to be associated | |
| 43 | + with the remoteproc device. The reserved memory node | |
| 44 | + can be a CMA memory node, and should be defined as | |
| 45 | + per the bindings in | |
| 46 | + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt | |
| 47 | + | |
| 48 | +Optional properties: | |
| 49 | +-------------------- | |
| 50 | +- interrupt-parent: phandle to the interrupt controller node. This property | |
| 51 | + is needed if the device node hierarchy doesn't have an | |
| 52 | + interrupt controller. | |
| 53 | + | |
| 54 | + | |
| 55 | +Example: | |
| 56 | +-------- | |
| 57 | + | |
| 58 | + /* DSP Reserved Memory node */ | |
| 59 | + reserved-memory { | |
| 60 | + #address-cells = <1>; | |
| 61 | + #size-cells = <1>; | |
| 62 | + ranges; | |
| 63 | + | |
| 64 | + dsp_memory_region: dsp-memory@c3000000 { | |
| 65 | + compatible = "shared-dma-pool"; | |
| 66 | + reg = <0xc3000000 0x1000000>; | |
| 67 | + reusable; | |
| 68 | + }; | |
| 69 | + }; | |
| 70 | + | |
| 71 | + /* DSP node */ | |
| 72 | + { | |
| 73 | + dsp: dsp@11800000 { | |
| 74 | + compatible = "ti,da850-dsp"; | |
| 75 | + reg = <0x11800000 0x40000>, | |
| 76 | + <0x11e00000 0x8000>, | |
| 77 | + <0x11f00000 0x8000>, | |
| 78 | + <0x01c14044 0x4>, | |
| 79 | + <0x01c14174 0x8>; | |
| 80 | + reg-names = "l2sram", "l1pram", "l1dram", "host1cfg", | |
| 81 | + "chipsig"; | |
| 82 | + interrupt-parent = <&intc>; | |
| 83 | + interrupts = <28>; | |
| 84 | + memory-region = <&dsp_memory_region>; | |
| 85 | + }; | |
| 86 | + }; | |
| @@ -26,6 +26,7 @@ The following are the mandatory properties: · 25 unmodified lines | ||
| 26 | 26 | "ti,k2hk-dsp" for DSPs on Keystone 2 66AK2H/K SoCs |
| 27 | 27 | "ti,k2l-dsp" for DSPs on Keystone 2 66AK2L SoCs |
| 28 | 28 | "ti,k2e-dsp" for DSPs on Keystone 2 66AK2E SoCs |
| 29 | + "ti,k2g-dsp" for DSPs on Keystone 2 66AK2G SoCs | |
| 29 | 30 | |
| 30 | 31 | - reg: Should contain an entry for each value in 'reg-names'. |
| 31 | 32 | Each entry should have the memory region's start address |
| @@ -37,20 +38,18 @@ The following are the mandatory properties: · 5 unmodified lines | ||
| 37 | 38 | should be defined in this order, |
| 38 | 39 | "l2sram", "l1pram", "l1dram" |
| 39 | 40 | |
| 40 | −- clocks: Should contain the device's input clock, and should be | |
| 41 | − defined as per the bindings in, | |
| 42 | − Documentation/devicetree/bindings/clock/keystone-gate.txt | |
| 43 | − | |
| 44 | 41 | - ti,syscon-dev: Should be a pair of the phandle to the Keystone Device |
| 45 | 42 | State Control node, and the register offset of the DSP |
| 46 | 43 | boot address register within that node's address space. |
| 47 | 44 | |
| 48 | 45 | - resets: Should contain the phandle to the reset controller node |
| 49 | 46 | managing the resets for this device, and a reset |
| 50 | − specifier. Please refer to the following reset bindings | |
| 51 | − for the reset argument specifier as per SoC, | |
| 47 | + specifier. Please refer to either of the following reset | |
| 48 | + bindings for the reset argument specifier as per SoC, | |
| 52 | 49 | Documentation/devicetree/bindings/reset/ti-syscon-reset.txt |
| 53 | − for 66AK2HK/66AK2L/66AK2E SoCs | |
| 50 | + for 66AK2HK/66AK2L/66AK2E SoCs or, | |
| 51 | + Documentation/devicetree/bindings/reset/ti,sci-reset.txt | |
| 52 | + for 66AK2G SoCs | |
| 54 | 53 | |
| 55 | 54 | - interrupt-parent: Should contain a phandle to the Keystone 2 IRQ controller |
| 56 | 55 | IP node that is used by the ARM CorePac processor to |
| @@ -75,6 +74,22 @@ The following are the mandatory properties: · 18 unmodified lines | ||
| 75 | 74 | The gpio device to be used is as per the bindings in, |
| 76 | 75 | Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt |
| 77 | 76 | |
| 77 | +SoC-specific Required properties: | |
| 78 | +--------------------------------- | |
| 79 | +The following are mandatory properties for Keystone 2 66AK2HK, 66AK2L and 66AK2E | |
| 80 | +SoCs only: | |
| 81 | + | |
| 82 | +- clocks: Should contain the device's input clock, and should be | |
| 83 | + defined as per the bindings in, | |
| 84 | + Documentation/devicetree/bindings/clock/keystone-gate.txt | |
| 85 | + | |
| 86 | +The following are mandatory properties for Keystone 2 66AK2G SoCs only: | |
| 87 | + | |
| 88 | +- power-domains: Should contain a phandle to a PM domain provider node | |
| 89 | + and an args specifier containing the DSP device id | |
| 90 | + value. This property is as per the binding, | |
| 91 | + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt | |
| 92 | + | |
| 78 | 93 | Optional properties: |
| 79 | 94 | -------------------- |
| 80 | 95 | |
| @@ -85,8 +100,10 @@ Optional properties: · 4 unmodified lines | ||
| 85 | 100 | Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt |
| 86 | 101 | |
| 87 | 102 | |
| 88 | −Example: | |
| 89 | −-------- | |
| 103 | +Examples: | |
| 104 | +--------- | |
| 105 | + | |
| 106 | +1. | |
| 90 | 107 | /* 66AK2H/K DSP aliases */ |
| 91 | 108 | aliases { |
| 92 | 109 | rproc0 = &dsp0; |
| @@ -131,3 +148,41 @@ Example: · 38 unmodified lines | ||
| 131 | 148 | }; |
| 132 | 149 | |
| 133 | 150 | }; |
| 151 | + | |
| 152 | +2. | |
| 153 | + /* 66AK2G DSP alias */ | |
| 154 | + aliases { | |
| 155 | + rproc0 = &dsp0; | |
| 156 | + }; | |
| 157 | + | |
| 158 | + /* 66AK2G DSP memory node */ | |
| 159 | + reserved-memory { | |
| 160 | + #address-cells = <2>; | |
| 161 | + #size-cells = <2>; | |
| 162 | + ranges; | |
| 163 | + | |
| 164 | + dsp_common_memory: dsp-common-memory@81f800000 { | |
| 165 | + compatible = "shared-dma-pool"; | |
| 166 | + reg = <0x00000008 0x1f800000 0x00000000 0x800000>; | |
| 167 | + reusable; | |
| 168 | + }; | |
| 169 | + }; | |
| 170 | + | |
| 171 | + /* 66AK2G DSP node */ | |
| 172 | + soc { | |
| 173 | + dsp0: dsp@10800000 { | |
| 174 | + compatible = "ti,k2g-dsp"; | |
| 175 | + reg = <0x10800000 0x00100000>, | |
| 176 | + <0x10e00000 0x00008000>, | |
| 177 | + <0x10f00000 0x00008000>; | |
| 178 | + reg-names = "l2sram", "l1pram", "l1dram"; | |
| 179 | + power-domains = <&k2g_pds 0x0046>; | |
| 180 | + ti,syscon-dev = <&devctrl 0x40>; | |
| 181 | + resets = <&k2g_reset 0x0046 0x1>; | |
| 182 | + interrupt-parent = <&kirq0>; | |
| 183 | + interrupts = <0 8>; | |
| 184 | + interrupt-names = "vring", "exception"; | |
| 185 | + kick-gpios = <&dspgpio0 27 0>; | |
| 186 | + memory-region = <&dsp_common_memory>; | |
| 187 | + }; | |
| 188 | + }; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +Lantiq XWAY SoC RCU reset controller binding | |
| 2 | +============================================ | |
| 3 | + | |
| 4 | +This binding describes a reset-controller found on the RCU module on Lantiq | |
| 5 | +XWAY SoCs. | |
| 6 | + | |
| 7 | +This node has to be a sub node of the Lantiq RCU block. | |
| 8 | + | |
| 9 | +------------------------------------------------------------------------------- | |
| 10 | +Required properties: | |
| 11 | +- compatible : Should be one of | |
| 12 | + "lantiq,danube-reset" | |
| 13 | + "lantiq,xrx200-reset" | |
| 14 | +- reg : Defines the following sets of registers in the parent | |
| 15 | + syscon device | |
| 16 | + - Offset of the reset set register | |
| 17 | + - Offset of the reset status register | |
| 18 | +- #reset-cells : Specifies the number of cells needed to encode the | |
| 19 | + reset line, should be 2. | |
| 20 | + The first cell takes the reset set bit and the | |
| 21 | + second cell takes the status bit. | |
| 22 | + | |
| 23 | +------------------------------------------------------------------------------- | |
| 24 | +Example for the reset-controllers on the xRX200 SoCs: | |
| 25 | + reset0: reset-controller@10 { | |
| 26 | + compatible = "lantiq,xrx200-reset"; | |
| 27 | + reg <0x10 0x04>, <0x14 0x04>; | |
| 28 | + | |
| 29 | + #reset-cells = <2>; | |
| 30 | + }; | |
| @@ -80,5 +80,4 @@ mac: ethernet@40010000 { · 79 unmodified lines | ||
| 80 | 80 | clock-names = "stmmaceth"; |
| 81 | 81 | resets = <&rgu 22>; |
| 82 | 82 | reset-names = "stmmaceth"; |
| 83 | − status = "disabled"; | |
| 84 | 83 | }; |
| @@ -26,6 +26,7 @@ Required properties: · 25 unmodified lines | ||
| 26 | 26 | - "renesas,r8a7794-rst" (R-Car E2) |
| 27 | 27 | - "renesas,r8a7795-rst" (R-Car H3) |
| 28 | 28 | - "renesas,r8a7796-rst" (R-Car M3-W) |
| 29 | + - "renesas,r8a77995-rst" (R-Car D3) | |
| 29 | 30 | - reg: Address start and address range for the device. |
| 30 | 31 | |
| 31 | 32 | |
| @@ -6,7 +6,6 @@ System reset · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: should be one of the following: |
| 9 | − "socionext,uniphier-sld3-reset" - for sLD3 SoC | |
| 10 | 9 | "socionext,uniphier-ld4-reset" - for LD4 SoC |
| 11 | 10 | "socionext,uniphier-pro4-reset" - for Pro4 SoC |
| 12 | 11 | "socionext,uniphier-sld8-reset" - for sLD8 SoC |
| @@ -37,7 +36,6 @@ Media I/O (MIO) reset, SD reset · 24 unmodified lines | ||
| 37 | 36 | |
| 38 | 37 | Required properties: |
| 39 | 38 | - compatible: should be one of the following: |
| 40 | − "socionext,uniphier-sld3-mio-reset" - for sLD3 SoC | |
| 41 | 39 | "socionext,uniphier-ld4-mio-reset" - for LD4 SoC |
| 42 | 40 | "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC |
| 43 | 41 | "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC |
| @@ -92,3 +90,28 @@ Example: · 48 unmodified lines | ||
| 92 | 90 | |
| 93 | 91 | other nodes ... |
| 94 | 92 | }; |
| 93 | + | |
| 94 | + | |
| 95 | +Analog signal amplifier reset | |
| 96 | +----------------------------- | |
| 97 | + | |
| 98 | +Required properties: | |
| 99 | +- compatible: should be one of the following: | |
| 100 | + "socionext,uniphier-ld11-adamv-reset" - for LD11 SoC | |
| 101 | + "socionext,uniphier-ld20-adamv-reset" - for LD20 SoC | |
| 102 | +- #reset-cells: should be 1. | |
| 103 | + | |
| 104 | +Example: | |
| 105 | + | |
| 106 | + adamv@57920000 { | |
| 107 | + compatible = "socionext,uniphier-ld11-adamv", | |
| 108 | + "simple-mfd", "syscon"; | |
| 109 | + reg = <0x57920000 0x1000>; | |
| 110 | + | |
| 111 | + adamv_rst: reset { | |
| 112 | + compatible = "socionext,uniphier-ld11-adamv-reset"; | |
| 113 | + #reset-cells = <1>; | |
| 114 | + }; | |
| 115 | + | |
| 116 | + other nodes ... | |
| 117 | + }; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Freescale RNGC (Random Number Generator Version C) | |
| 2 | + | |
| 3 | +The driver also supports version B, which is mostly compatible | |
| 4 | +to version C. | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible : should be one of | |
| 8 | + "fsl,imx25-rngb" | |
| 9 | + "fsl,imx35-rngc" | |
| 10 | +- reg : offset and length of the register set of this block | |
| 11 | +- interrupts : the interrupt number for the RNGC block | |
| 12 | +- clocks : the RNGC clk source | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | +rng@53fb0000 { | |
| 17 | + compatible = "fsl,imx25-rngb"; | |
| 18 | + reg = <0x53fb0000 0x4000>; | |
| 19 | + interrupts = <22>; | |
| 20 | + clocks = <&trng_clk>; | |
| 21 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +Android Goldfish RTC | |
| 2 | + | |
| 3 | +Android Goldfish RTC device used by Android emulator. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : should contain "google,goldfish-rtc" | |
| 8 | +- reg : <registers mapping> | |
| 9 | +- interrupts : <interrupt mapping> | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | + goldfish_timer@9020000 { | |
| 14 | + compatible = "google,goldfish-rtc"; | |
| 15 | + reg = <0x9020000 0x1000>; | |
| 16 | + interrupts = <0x3>; | |
| 17 | + }; | |
| @@ -24,7 +24,6 @@ Optional properties: · 23 unmodified lines | ||
| 24 | 24 | |
| 25 | 25 | - "wakeup-source": mark the chip as a wakeup source, independently of |
| 26 | 26 | the availability of an IRQ line connected to the SoC. |
| 27 | − (Legacy property supported: "isil,irq2-can-wakeup-machine") | |
| 28 | 27 | |
| 29 | 28 | - "interrupt-parent", "interrupts": for passing the interrupt line |
| 30 | 29 | of the SoC connected to IRQ#2 of the RTC chip. |
| @@ -0,0 +1,16 @@ | ||
| 1 | +Realtek RTD129x Real-Time Clock | |
| 2 | +=============================== | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible : Should be "realtek,rtd1295-rtc" | |
| 6 | +- reg : Specifies the physical base address and size | |
| 7 | +- clocks : Specifies the clock gate | |
| 8 | + | |
| 9 | + | |
| 10 | +Example: | |
| 11 | + | |
| 12 | + rtc@9801b600 { | |
| 13 | + compatible = "realtek,rtd1295-clk"; | |
| 14 | + reg = <0x9801b600 0x100>; | |
| 15 | + clocks = <&clkc RTD1295_CLK_EN_MISC_RTC>; | |
| 16 | + }; | |
| @@ -45,5 +45,4 @@ Example: · 44 unmodified lines | ||
| 45 | 45 | interrupts = <17 1>; |
| 46 | 46 | interrupt-names = "alarm"; |
| 47 | 47 | st,syscfg = <&pwrcfg>; |
| 48 | − status = "disabled"; | |
| 49 | 48 | }; |
| @@ -10,7 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | |
| 11 | 11 | Required properties for new device trees |
| 12 | 12 | - clocks : phandle to the 32kHz external oscillator |
| 13 | −- clock-output-names : name of the LOSC clock created | |
| 13 | +- clock-output-names : names of the LOSC and its external output clocks created | |
| 14 | 14 | - #clock-cells : must be equals to 1. The RTC provides two clocks: the |
| 15 | 15 | LOSC and its external output, with index 0 and 1 |
| 16 | 16 | respectively. |
| @@ -21,7 +21,7 @@ rtc: rtc@01f00000 { · 4 unmodified lines | ||
| 21 | 21 | compatible = "allwinner,sun6i-a31-rtc"; |
| 22 | 22 | reg = <0x01f00000 0x54>; |
| 23 | 23 | interrupts = <0 40 4>, <0 41 4>; |
| 24 | − clock-output-names = "osc32k"; | |
| 24 | + clock-output-names = "osc32k", "osc32k-out"; | |
| 25 | 25 | clocks = <&ext_osc32k>; |
| 26 | 26 | #clock-cells = <1>; |
| 27 | 27 | }; |
| @@ -85,5 +85,4 @@ Example: · 84 unmodified lines | ||
| 85 | 85 | <366 1>,<367 1>/* cq30-31 */ |
| 86 | 86 | <376 4>,/* fatal ecc */ |
| 87 | 87 | <381 4>;/* fatal axi */ |
| 88 | − status = "disabled"; | |
| 89 | 88 | }; |
| @@ -19,7 +19,6 @@ Example (for ARM-based BeagleBoard xM with ST33ZP24 on I2C2): · 18 unmodified lines | ||
| 19 | 19 | |
| 20 | 20 | &i2c2 { |
| 21 | 21 | |
| 22 | − status = "okay"; | |
| 23 | 22 | |
| 24 | 23 | st33zp24: st33zp24@13 { |
| 25 | 24 | |
| @@ -18,7 +18,6 @@ Example (for ARM-based BeagleBoard xM with ST33ZP24 on SPI4): · 17 unmodified lines | ||
| 18 | 18 | |
| 19 | 19 | &mcspi4 { |
| 20 | 20 | |
| 21 | − status = "okay"; | |
| 22 | 21 | |
| 23 | 22 | st33zp24@0 { |
| 24 | 23 | |
| @@ -8,6 +8,12 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | the firmware event log |
| 9 | 9 | - linux,sml-size : size of the memory allocated for the firmware event log |
| 10 | 10 | |
| 11 | +Optional properties: | |
| 12 | + | |
| 13 | +- powered-while-suspended: present when the TPM is left powered on between | |
| 14 | + suspend and resume (makes the suspend/resume | |
| 15 | + callbacks do nothing). | |
| 16 | + | |
| 11 | 17 | Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C) |
| 12 | 18 | ---------------------------------------------------------- |
| 13 | 19 | |
| @@ -17,5 +23,4 @@ tpm@57 { · 3 unmodified lines | ||
| 17 | 23 | compatible = "nuvoton,npct650", "nuvoton,npct601"; |
| 18 | 24 | linux,sml-base = <0x7f 0xfd450000>; |
| 19 | 25 | linux,sml-size = <0x10000>; |
| 20 | − status = "okay"; | |
| 21 | 26 | }; |
| @@ -13,7 +13,6 @@ Example (for ARM-based BeagleBoard xM with TPM_TIS on SPI4): · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | &mcspi4 { |
| 15 | 15 | |
| 16 | − status = "okay"; | |
| 17 | 16 | |
| 18 | 17 | tpm_tis@0 { |
| 19 | 18 | |
| @@ -14,6 +14,8 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | tegra132, or tegra210. |
| 15 | 15 | - "nxp,lpc3220-uart" |
| 16 | 16 | - "ralink,rt2880-uart" |
| 17 | + - For MediaTek BTIF, must contain '"mediatek,<chip>-btif", | |
| 18 | + "mediatek,mtk-btif"' where <chip> is mt7622, mt7623. | |
| 17 | 19 | - "altr,16550-FIFO32" |
| 18 | 20 | - "altr,16550-FIFO64" |
| 19 | 21 | - "altr,16550-FIFO128" |
| @@ -15,7 +15,6 @@ arcuart0: serial@c0fc1000 { · 14 unmodified lines | ||
| 15 | 15 | interrupts = <5>; |
| 16 | 16 | clock-frequency = <80000000>; |
| 17 | 17 | current-speed = <115200>; |
| 18 | − status = "okay"; | |
| 19 | 18 | }; |
| 20 | 19 | |
| 21 | 20 | Note: Each port should have an alias correctly numbered in "aliases" node. |
| @@ -15,7 +15,6 @@ serial@b00260000 { · 14 unmodified lines | ||
| 15 | 15 | compatible = "axis,etraxfs-uart"; |
| 16 | 16 | reg = <0xb0026000 0x1000>; |
| 17 | 17 | interrupts = <68>; |
| 18 | − status = "disabled"; | |
| 19 | 18 | dtr-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>; |
| 20 | 19 | dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>; |
| 21 | 20 | rng-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>; |
| @@ -3,6 +3,7 @@ · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible should contain: |
| 5 | 5 | * "mediatek,mt2701-uart" for MT2701 compatible UARTS |
| 6 | + * "mediatek,mt2712-uart" for MT2712 compatible UARTS | |
| 6 | 7 | * "mediatek,mt6580-uart" for MT6580 compatible UARTS |
| 7 | 8 | * "mediatek,mt6582-uart" for MT6582 compatible UARTS |
| 8 | 9 | * "mediatek,mt6589-uart" for MT6589 compatible UARTS |
| @@ -33,5 +33,4 @@ serial@70006000 { · 32 unmodified lines | ||
| 33 | 33 | reset-names = "serial"; |
| 34 | 34 | dmas = <&apbdma 8>, <&apbdma 8>; |
| 35 | 35 | dma-names = "rx", "tx"; |
| 36 | − status = "disabled"; | |
| 37 | 36 | }; |
| @@ -72,13 +72,10 @@ Examples: · 71 unmodified lines | ||
| 72 | 72 | }; |
| 73 | 73 | |
| 74 | 74 | uarta: serial@12490000 { |
| 75 | − status = "ok"; | |
| 76 | 75 | }; |
| 77 | 76 | |
| 78 | 77 | uartb: serial@16340000 { |
| 79 | − status = "ok"; | |
| 80 | 78 | }; |
| 81 | 79 | |
| 82 | 80 | uartc: serial@1a240000 { |
| 83 | − status = "ok"; | |
| 84 | 81 | }; |
| @@ -41,6 +41,8 @@ Required properties: · 40 unmodified lines | ||
| 41 | 41 | - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART. |
| 42 | 42 | - "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART. |
| 43 | 43 | - "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART. |
| 44 | + - "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART. | |
| 45 | + - "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART. | |
| 44 | 46 | - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. |
| 45 | 47 | - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. |
| 46 | 48 | - "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART, |
| @@ -5,14 +5,13 @@ the built-in half-duplex mode. · 4 unmodified lines | ||
| 5 | 5 | The properties described hereafter shall be given to a half-duplex capable |
| 6 | 6 | UART node. |
| 7 | 7 | |
| 8 | −Required properties: | |
| 8 | +Optional properties: | |
| 9 | 9 | - rs485-rts-delay: prop-encoded-array <a b> where: |
| 10 | 10 | * a is the delay between rts signal and beginning of data sent in milliseconds. |
| 11 | 11 | it corresponds to the delay before sending data. |
| 12 | 12 | * b is the delay between end of data sent and rts signal in milliseconds |
| 13 | 13 | it corresponds to the delay after sending data and actual release of the line. |
| 14 | − | |
| 15 | −Optional properties: | |
| 14 | + If this property is not specified, <0 0> is assumed. | |
| 16 | 15 | - linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485 |
| 17 | 16 | feature at boot time. It can be disabled later with proper ioctl. |
| 18 | 17 | - rs485-rx-during-tx: empty property that enables the receiving of data even |
| @@ -43,7 +43,6 @@ Examples: · 42 unmodified lines | ||
| 43 | 43 | rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; |
| 44 | 44 | cts-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; |
| 45 | 45 | rts-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; |
| 46 | − status = "okay"; | |
| 47 | 46 | }; |
| 48 | 47 | |
| 49 | 48 | scifa4: serial@e6c80000 { |
| @@ -54,5 +53,4 @@ Examples: · 4 unmodified lines | ||
| 54 | 53 | clock-names = "fck"; |
| 55 | 54 | power-domains = <&pd_a3sp>; |
| 56 | 55 | uart-has-rtscts; |
| 57 | − status = "okay"; | |
| 58 | 56 | }; |
| @@ -1,12 +1,19 @@ | ||
| 1 | 1 | * STMicroelectronics STM32 USART |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible: Can be either "st,stm32-usart", "st,stm32-uart", | |
| 5 | −"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether | |
| 6 | −the device supports synchronous mode and is compatible with | |
| 7 | −stm32(f4) or stm32f7. | |
| 4 | +- compatible: can be either: | |
| 5 | + - "st,stm32-usart", | |
| 6 | + - "st,stm32-uart", | |
| 7 | + - "st,stm32f7-usart", | |
| 8 | + - "st,stm32f7-uart", | |
| 9 | + - "st,stm32h7-usart" | |
| 10 | + - "st,stm32h7-uart". | |
| 11 | + depending on whether the device supports synchronous mode | |
| 12 | + and is compatible with stm32(f4), stm32f7 or stm32h7. | |
| 8 | 13 | - reg: The address and length of the peripheral registers space |
| 9 | −- interrupts: The interrupt line of the USART instance | |
| 14 | +- interrupts: | |
| 15 | + - The interrupt line for the USART instance, | |
| 16 | + - An optional wake-up interrupt. | |
| 10 | 17 | - clocks: The input clock of the USART instance |
| 11 | 18 | |
| 12 | 19 | Optional properties: |
| @@ -19,5 +19,4 @@ Example: · 18 unmodified lines | ||
| 19 | 19 | reg = <0x01c2a000 0x400>; |
| 20 | 20 | interrupts = <0 62 4>; |
| 21 | 21 | clocks = <&apb1_gates 6>; |
| 22 | − status = "disabled"; | |
| 23 | 22 | }; |
| @@ -0,0 +1,23 @@ | ||
| 1 | +Device-Tree binding for ps/2 gpio device | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible = "ps2-gpio" | |
| 5 | + - data-gpios: the data pin | |
| 6 | + - clk-gpios: the clock pin | |
| 7 | + - interrupts: Should trigger on the falling edge of the clock line. | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | + - write-enable: Indicates whether write function is provided | |
| 11 | + to serio device. Possibly providing the write fn will not work, because | |
| 12 | + of the tough timing requirements. | |
| 13 | + | |
| 14 | +Example nodes: | |
| 15 | + | |
| 16 | +ps2@0 { | |
| 17 | + compatible = "ps2-gpio"; | |
| 18 | + interrupt-parent = <&gpio>; | |
| 19 | + interrupts = <23 IRQ_TYPE_EDGE_FALLING>; | |
| 20 | + data-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; | |
| 21 | + clk-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>; | |
| 22 | + write-enable; | |
| 23 | +}; | |
| @@ -12,11 +12,13 @@ power/power_domain.txt. It provides the power domains defined in · 11 unmodified lines | ||
| 12 | 12 | - include/dt-bindings/power/mt8173-power.h |
| 13 | 13 | - include/dt-bindings/power/mt6797-power.h |
| 14 | 14 | - include/dt-bindings/power/mt2701-power.h |
| 15 | +- include/dt-bindings/power/mt7622-power.h | |
| 15 | 16 | |
| 16 | 17 | Required properties: |
| 17 | 18 | - compatible: Should be one of: |
| 18 | 19 | - "mediatek,mt2701-scpsys" |
| 19 | 20 | - "mediatek,mt6797-scpsys" |
| 21 | + - "mediatek,mt7622-scpsys" | |
| 20 | 22 | - "mediatek,mt8173-scpsys" |
| 21 | 23 | - #power-domain-cells: Must be 1 |
| 22 | 24 | - reg: Address range of the SCPSYS unit |
| @@ -26,6 +28,7 @@ Required properties: · 3 unmodified lines | ||
| 26 | 28 | enabled before enabling certain power domains. |
| 27 | 29 | Required clocks for MT2701: "mm", "mfg", "ethif" |
| 28 | 30 | Required clocks for MT6797: "mm", "mfg", "vdec" |
| 31 | + Required clocks for MT7622: "hif_sel" | |
| 29 | 32 | Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" |
| 30 | 33 | |
| 31 | 34 | Optional properties: |
| @@ -1,11 +1,12 @@ | ||
| 1 | −Qualcomm RPM GLINK binding | |
| 1 | +Qualcomm GLINK edge binding | |
| 2 | 2 | |
| 3 | −This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for | |
| 4 | −communication with the Resource Power Management system on various Qualcomm | |
| 5 | −platforms. | |
| 3 | +This binding describes a Qualcomm GLINK edge, a fifo based mechanism for | |
| 4 | +communication between subsystem-pairs on various Qualcomm platforms. Two types | |
| 5 | +of edges can be described by the binding; the GLINK RPM edge and a SMEM based | |
| 6 | +edge. | |
| 6 | 7 | |
| 7 | 8 | - compatible: |
| 8 | − Usage: required | |
| 9 | + Usage: required for glink-rpm | |
| 9 | 10 | Value type: <stringlist> |
| 10 | 11 | Definition: must be "qcom,glink-rpm" |
| 11 | 12 | |
| @@ -16,7 +17,7 @@ platforms. · 4 unmodified lines | ||
| 16 | 17 | signal this processor about communication related events |
| 17 | 18 | |
| 18 | 19 | - qcom,rpm-msg-ram: |
| 19 | − Usage: required | |
| 20 | + Usage: required for glink-rpm | |
| 20 | 21 | Value type: <prop-encoded-array> |
| 21 | 22 | Definition: handle to RPM message memory resource |
| 22 | 23 | |
| @@ -78,7 +78,6 @@ Example for APQ8064: · 77 unmodified lines | ||
| 78 | 78 | interrupts = <0 152 0x0>; |
| 79 | 79 | clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; |
| 80 | 80 | clock-names = "core", "iface"; |
| 81 | − status = "ok"; | |
| 82 | 81 | }; |
| 83 | 82 | }; |
| 84 | 83 | |
| @@ -21,6 +21,7 @@ Required Properties: · 20 unmodified lines | ||
| 21 | 21 | - "rockchip,rk3328-grf", "syscon": for rk3328 |
| 22 | 22 | - "rockchip,rk3368-grf", "syscon": for rk3368 |
| 23 | 23 | - "rockchip,rk3399-grf", "syscon": for rk3399 |
| 24 | + - "rockchip,rv1108-grf", "syscon": for rv1108 | |
| 24 | 25 | - compatible: PMUGRF should be one of the following: |
| 25 | 26 | - "rockchip,rk3368-pmugrf", "syscon": for rk3368 |
| 26 | 27 | - "rockchip,rk3399-pmugrf", "syscon": for rk3399 |
| @@ -28,6 +29,8 @@ Required Properties: · 1 unmodified line | ||
| 28 | 29 | - "rockchip,rk3288-sgrf", "syscon": for rk3288 |
| 29 | 30 | - compatible: USB2PHYGRF should be one of the followings |
| 30 | 31 | - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328 |
| 32 | +- compatible: USBGRF should be one of the following | |
| 33 | + - "rockchip,rv1108-usbgrf", "syscon": for rv1108 | |
| 31 | 34 | - reg: physical base address of the controller and length of memory mapped |
| 32 | 35 | region. |
| 33 | 36 | |
| @@ -7,6 +7,7 @@ Required properties for power domain controller: · 6 unmodified lines | ||
| 7 | 7 | - compatible: Should be one of the following. |
| 8 | 8 | "rockchip,rk3288-power-controller" - for RK3288 SoCs. |
| 9 | 9 | "rockchip,rk3328-power-controller" - for RK3328 SoCs. |
| 10 | + "rockchip,rk3366-power-controller" - for RK3366 SoCs. | |
| 10 | 11 | "rockchip,rk3368-power-controller" - for RK3368 SoCs. |
| 11 | 12 | "rockchip,rk3399-power-controller" - for RK3399 SoCs. |
| 12 | 13 | - #power-domain-cells: Number of cells in a power-domain specifier. |
| @@ -18,6 +19,7 @@ Required properties for power domain sub nodes: · 5 unmodified lines | ||
| 18 | 19 | - reg: index of the power domain, should use macros in: |
| 19 | 20 | "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain. |
| 20 | 21 | "include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain. |
| 22 | + "include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain. | |
| 21 | 23 | "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain. |
| 22 | 24 | "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain. |
| 23 | 25 | - clocks (optional): phandles to clocks which need to be enabled while power domain |
| @@ -93,6 +95,7 @@ power domain to use. · 69 unmodified lines | ||
| 93 | 95 | The index should use macros in: |
| 94 | 96 | "include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain. |
| 95 | 97 | "include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain. |
| 98 | + "include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain. | |
| 96 | 99 | "include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain. |
| 97 | 100 | "include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain. |
| 98 | 101 | |
| @@ -46,12 +46,13 @@ Required Properties: · 45 unmodified lines | ||
| 46 | 46 | - power-domains: phandle pointing to the corresponding PM domain node |
| 47 | 47 | and an ID representing the device. |
| 48 | 48 | |
| 49 | −See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g. | |
| 49 | +See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list | |
| 50 | +of valid identifiers for k2g. | |
| 50 | 51 | |
| 51 | 52 | Example (K2G): |
| 52 | 53 | -------------------- |
| 53 | 54 | uart0: serial@02530c00 { |
| 54 | 55 | compatible = "ns16550a"; |
| 55 | 56 | ... |
| 56 | − power-domains = <&k2g_pds K2G_DEV_UART0>; | |
| 57 | + power-domains = <&k2g_pds 0x002c>; | |
| 57 | 58 | }; |
| @@ -23,5 +23,4 @@ Example: · 22 unmodified lines | ||
| 23 | 23 | compatible = "marvell,a370db-audio"; |
| 24 | 24 | marvell,audio-controller = <&audio_controller>; |
| 25 | 25 | marvell,audio-codec = <&audio_codec &spdif_out &spdif_in>; |
| 26 | − status = "okay"; | |
| 27 | 26 | }; |
| @@ -13,13 +13,11 @@ Required properties: · 12 unmodified lines | ||
| 13 | 13 | Must be "tx". |
| 14 | 14 | - clock-names |
| 15 | 15 | Tuple listing input clock names. |
| 16 | − Required elements: "pclk", "gclk" and "aclk". | |
| 16 | + Required elements: "pclk" and "gclk". | |
| 17 | 17 | - clocks |
| 18 | 18 | Please refer to clock-bindings.txt. |
| 19 | 19 | - assigned-clocks |
| 20 | 20 | Should be <&classd_gclk>. |
| 21 | −- assigned-clock-parents | |
| 22 | − Should be <&audio_pll_pmc>. | |
| 23 | 21 | |
| 24 | 22 | Optional properties: |
| 25 | 23 | - pinctrl-names, pinctrl-0 |
| @@ -45,10 +43,9 @@ classd: classd@fc048000 { · 19 unmodified lines | ||
| 45 | 43 | (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
| 46 | 44 | | AT91_XDMAC_DT_PERID(47))>; |
| 47 | 45 | dma-names = "tx"; |
| 48 | − clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>; | |
| 49 | − clock-names = "pclk", "gclk", "aclk"; | |
| 46 | + clocks = <&classd_clk>, <&classd_gclk>; | |
| 47 | + clock-names = "pclk", "gclk"; | |
| 50 | 48 | assigned-clocks = <&classd_gclk>; |
| 51 | − assigned-clock-parents = <&audio_pll_pmc>; | |
| 52 | 49 | |
| 53 | 50 | pinctrl-names = "default"; |
| 54 | 51 | pinctrl-0 = <&pinctrl_classd_default>; |
| @@ -45,7 +45,6 @@ Example: · 44 unmodified lines | ||
| 45 | 45 | &ssc0 { |
| 46 | 46 | #sound-dai-cells = <0>; |
| 47 | 47 | |
| 48 | − status = "okay"; | |
| 49 | 48 | }; |
| 50 | 49 | |
| 51 | 50 | &i2c { |
| @@ -47,21 +47,17 @@ Example: · 46 unmodified lines | ||
| 47 | 47 | |
| 48 | 48 | ssp0: ssp_port@0 { |
| 49 | 49 | reg = <0>; |
| 50 | − status = "okay"; | |
| 51 | 50 | }; |
| 52 | 51 | |
| 53 | 52 | ssp1: ssp_port@1 { |
| 54 | 53 | reg = <1>; |
| 55 | − status = "disabled"; | |
| 56 | 54 | }; |
| 57 | 55 | |
| 58 | 56 | ssp2: ssp_port@2 { |
| 59 | 57 | reg = <2>; |
| 60 | − status = "disabled"; | |
| 61 | 58 | }; |
| 62 | 59 | |
| 63 | 60 | spdif: spdif_port@3 { |
| 64 | 61 | reg = <3>; |
| 65 | − status = "disabled"; | |
| 66 | 62 | }; |
| 67 | 63 | }; |
| @@ -0,0 +1,67 @@ | ||
| 1 | +CS43130 DAC | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible : "cirrus,cs43130", "cirrus,cs4399", "cirrus,cs43131", | |
| 6 | + "cirrus,cs43198" | |
| 7 | + | |
| 8 | + - reg : the I2C address of the device for I2C | |
| 9 | + | |
| 10 | + - VA-supply, VP-supply, VL-supply, VCP-supply, VD-supply: | |
| 11 | + power supplies for the device, as covered in | |
| 12 | + Documentation/devicetree/bindings/regulator/regulator.txt. | |
| 13 | + | |
| 14 | + | |
| 15 | +Optional properties: | |
| 16 | + | |
| 17 | + - reset-gpios : Active low GPIO used to reset the device | |
| 18 | + | |
| 19 | + - cirrus,xtal-ibias: | |
| 20 | + When external MCLK is generated by external crystal | |
| 21 | + oscillator, CS43130 can be used to provide bias current | |
| 22 | + for external crystal. Amount of bias current sent is | |
| 23 | + set as: | |
| 24 | + 1 = 7.5uA | |
| 25 | + 2 = 12.5uA | |
| 26 | + 3 = 15uA | |
| 27 | + | |
| 28 | + - cirrus,dc-measure: | |
| 29 | + Boolean, define to enable headphone DC impedance measurement. | |
| 30 | + | |
| 31 | + - cirrus,ac-measure: | |
| 32 | + Boolean, define to enable headphone AC impedance measurement. | |
| 33 | + DC impedance must also be enabled for AC impedance measurement. | |
| 34 | + | |
| 35 | + - cirrus,dc-threshold: | |
| 36 | + Define 2 DC impedance thresholds in ohms for HP output control. | |
| 37 | + Default values are 50 and 120 Ohms. | |
| 38 | + | |
| 39 | + - cirrus,ac-freq: | |
| 40 | + Define the frequencies at which to measure HP AC impedance. | |
| 41 | + Only used if "cirrus,dc-measure" is defined. | |
| 42 | + Exactly 10 frequencies must be defined. | |
| 43 | + If this properties is undefined, by default, | |
| 44 | + following frequencies are used: | |
| 45 | + <24 43 93 200 431 928 2000 4309 9283 20000> | |
| 46 | + The above frequencies are logarithmically equally spaced. | |
| 47 | + Log base is 10. | |
| 48 | + | |
| 49 | +Example: | |
| 50 | + | |
| 51 | +cs43130: audio-codec@30 { | |
| 52 | + compatible = "cirrus,cs43130"; | |
| 53 | + reg = <0x30>; | |
| 54 | + reset-gpios = <&axi_gpio 54 0>; | |
| 55 | + VA-supply = <&dummy_vreg>; | |
| 56 | + VP-supply = <&dummy_vreg>; | |
| 57 | + VL-supply = <&dummy_vreg>; | |
| 58 | + VCP-supply = <&dummy_vreg>; | |
| 59 | + VD-supply = <&dummy_vreg>; | |
| 60 | + cirrus,xtal-ibias = <2>; | |
| 61 | + interrupt-parent = <&gpio0>; | |
| 62 | + interrupts = <55 8>; | |
| 63 | + cirrus,dc-measure; | |
| 64 | + cirrus,ac-measure; | |
| 65 | + cirrus,dc-threshold = /bits/ 16 <20 100>; | |
| 66 | + cirrus,ac-freq = /bits/ 16 <24 43 93 200 431 928 2000 4309 9283 20000>; | |
| 67 | +}; | |
| @@ -47,5 +47,4 @@ mcbsp0: mcbsp@1d10000 { · 46 unmodified lines | ||
| 47 | 47 | dmas = <&edma0 3 1 |
| 48 | 48 | &edma0 2 1>; |
| 49 | 49 | dma-names = "tx", "rx"; |
| 50 | − status = "okay"; | |
| 51 | 50 | }; |
| @@ -0,0 +1,16 @@ | ||
| 1 | +Device-Tree bindings for Digital microphone (DMIC) codec | |
| 2 | + | |
| 3 | +This device support generic PDM digital microphone. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + - compatible: should be "dmic-codec". | |
| 7 | + | |
| 8 | +Optional properties: | |
| 9 | + - dmicen-gpios: GPIO specifier for dmic to control start and stop | |
| 10 | + | |
| 11 | +Example node: | |
| 12 | + | |
| 13 | + dmic_codec: dmic@0 { | |
| 14 | + compatible = "dmic-codec"; | |
| 15 | + dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>; | |
| 16 | + }; | |
| @@ -61,5 +61,4 @@ asrc: asrc@02034000 { · 60 unmodified lines | ||
| 61 | 61 | "txa", "txb", "txc"; |
| 62 | 62 | fsl,asrc-rate = <48000>; |
| 63 | 63 | fsl,asrc-width = <16>; |
| 64 | − status = "okay"; | |
| 65 | 64 | }; |
| @@ -59,5 +59,4 @@ esai: esai@02024000 { · 58 unmodified lines | ||
| 59 | 59 | fsl,fifo-depth = <128>; |
| 60 | 60 | fsl,esai-synchronous; |
| 61 | 61 | big-endian; |
| 62 | − status = "disabled"; | |
| 63 | 62 | }; |
| @@ -59,5 +59,4 @@ spdif: spdif@02004000 { · 58 unmodified lines | ||
| 59 | 59 | "rxtx7"; |
| 60 | 60 | |
| 61 | 61 | big-endian; |
| 62 | − status = "okay"; | |
| 63 | 62 | }; |
| @@ -13,5 +13,4 @@ Example node: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | hdmi_audio: hdmi_audio@0 { |
| 15 | 15 | compatible = "linux,hdmi-audio"; |
| 16 | − status = "okay"; | |
| 17 | 16 | }; |
| @@ -3,7 +3,8 @@ Mediatek AFE PCM controller for mt2701 · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible = "mediatek,mt2701-audio"; |
| 5 | 5 | - reg: register location and size |
| 6 | −- interrupts: Should contain AFE interrupt | |
| 6 | +- interrupts: should contain AFE and ASYS interrupts | |
| 7 | +- interrupt-names: should be "afe" and "asys" | |
| 7 | 8 | - power-domains: should define the power domain |
| 8 | 9 | - clock-names: should have these clock names: |
| 9 | 10 | "infra_sys_audio_clk", |
| @@ -59,6 +60,7 @@ Example: · 49 unmodified lines | ||
| 59 | 60 | <0 0x112A0000 0 0x20000>; |
| 60 | 61 | interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>, |
| 61 | 62 | <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>; |
| 63 | + interrupt-names = "afe", "asys"; | |
| 62 | 64 | power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>; |
| 63 | 65 | clocks = <&infracfg CLK_INFRA_AUDIO>, |
| 64 | 66 | <&topckgen CLK_TOP_AUD_MUX1_SEL>, |
| @@ -31,8 +31,22 @@ Required properties · 30 unmodified lines | ||
| 31 | 31 | - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node. |
| 32 | 32 | - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node. |
| 33 | 33 | - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node. |
| 34 | − | |
| 35 | 34 | Optional Properties: |
| 35 | + - qcom,mbhc-vthreshold-low: Array of 5 threshold voltages in mV for 5 buttons | |
| 36 | + detection on headset when the mbhc is powered up | |
| 37 | + by internal current source, this is a low power. | |
| 38 | + - qcom,mbhc-vthreshold-high: Array of 5 thresold voltages in mV for 5 buttons | |
| 39 | + detection on headset when mbhc is powered up | |
| 40 | + from micbias. | |
| 41 | +- qcom,micbias-lvl: Voltage (mV) for Mic Bias | |
| 42 | +- qcom,hphl-jack-type-normally-open: boolean, present if hphl pin on jack is a | |
| 43 | + NO (Normally Open). If not specified, then | |
| 44 | + its assumed that hphl pin on jack is NC | |
| 45 | + (Normally Closed). | |
| 46 | +- qcom,gnd-jack-type-normally-open: boolean, present if gnd pin on jack is | |
| 47 | + NO (Normally Open). If not specified, then | |
| 48 | + its assumed that gnd pin on jack is NC | |
| 49 | + (Normally Closed). | |
| 36 | 50 | - qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor |
| 37 | 51 | connected. |
| 38 | 52 | - qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor |
| @@ -48,6 +62,8 @@ spmi_bus { · 9 unmodified lines | ||
| 48 | 62 | reg-names = "pmic-codec-core"; |
| 49 | 63 | clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>; |
| 50 | 64 | clock-names = "mclk"; |
| 65 | + qcom,mbhc-vthreshold-low = <75 150 237 450 500>; | |
| 66 | + qcom,mbhc-vthreshold-high = <75 150 237 450 500>; | |
| 51 | 67 | interrupt-parent = <&spmi_bus>; |
| 52 | 68 | interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>, |
| 53 | 69 | <0x1 0xf0 0x1 IRQ_TYPE_NONE>, |
| @@ -199,10 +199,10 @@ Ex) · 198 unmodified lines | ||
| 199 | 199 | sound { |
| 200 | 200 | compatible = "simple-scu-audio-card"; |
| 201 | 201 | ... |
| 202 | − simple-audio-card,cpu@0 { | |
| 202 | + simple-audio-card,cpu-0 { | |
| 203 | 203 | sound-dai = <&rcar_sound 0>; |
| 204 | 204 | }; |
| 205 | − simple-audio-card,cpu@1 { | |
| 205 | + simple-audio-card,cpu-1 { | |
| 206 | 206 | sound-dai = <&rcar_sound 1>; |
| 207 | 207 | }; |
| 208 | 208 | simple-audio-card,codec { |
| @@ -441,79 +441,79 @@ rcar_sound: sound@ec500000 { · 232 unmodified lines | ||
| 441 | 441 | "clk_a", "clk_b", "clk_c", "clk_i"; |
| 442 | 442 | |
| 443 | 443 | rcar_sound,dvc { |
| 444 | − dvc0: dvc@0 { | |
| 444 | + dvc0: dvc-0 { | |
| 445 | 445 | dmas = <&audma0 0xbc>; |
| 446 | 446 | dma-names = "tx"; |
| 447 | 447 | }; |
| 448 | − dvc1: dvc@1 { | |
| 448 | + dvc1: dvc-1 { | |
| 449 | 449 | dmas = <&audma0 0xbe>; |
| 450 | 450 | dma-names = "tx"; |
| 451 | 451 | }; |
| 452 | 452 | }; |
| 453 | 453 | |
| 454 | 454 | rcar_sound,mix { |
| 455 | − mix0: mix@0 { }; | |
| 456 | − mix1: mix@1 { }; | |
| 455 | + mix0: mix-0 { }; | |
| 456 | + mix1: mix-1 { }; | |
| 457 | 457 | }; |
| 458 | 458 | |
| 459 | 459 | rcar_sound,ctu { |
| 460 | − ctu00: ctu@0 { }; | |
| 461 | − ctu01: ctu@1 { }; | |
| 462 | − ctu02: ctu@2 { }; | |
| 463 | − ctu03: ctu@3 { }; | |
| 464 | − ctu10: ctu@4 { }; | |
| 465 | − ctu11: ctu@5 { }; | |
| 466 | − ctu12: ctu@6 { }; | |
| 467 | − ctu13: ctu@7 { }; | |
| 460 | + ctu00: ctu-0 { }; | |
| 461 | + ctu01: ctu-1 { }; | |
| 462 | + ctu02: ctu-2 { }; | |
| 463 | + ctu03: ctu-3 { }; | |
| 464 | + ctu10: ctu-4 { }; | |
| 465 | + ctu11: ctu-5 { }; | |
| 466 | + ctu12: ctu-6 { }; | |
| 467 | + ctu13: ctu-7 { }; | |
| 468 | 468 | }; |
| 469 | 469 | |
| 470 | 470 | rcar_sound,src { |
| 471 | − src0: src@0 { | |
| 471 | + src0: src-0 { | |
| 472 | 472 | interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>; |
| 473 | 473 | dmas = <&audma0 0x85>, <&audma1 0x9a>; |
| 474 | 474 | dma-names = "rx", "tx"; |
| 475 | 475 | }; |
| 476 | − src1: src@1 { | |
| 476 | + src1: src-1 { | |
| 477 | 477 | interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>; |
| 478 | 478 | dmas = <&audma0 0x87>, <&audma1 0x9c>; |
| 479 | 479 | dma-names = "rx", "tx"; |
| 480 | 480 | }; |
| 481 | − src2: src@2 { | |
| 481 | + src2: src-2 { | |
| 482 | 482 | interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>; |
| 483 | 483 | dmas = <&audma0 0x89>, <&audma1 0x9e>; |
| 484 | 484 | dma-names = "rx", "tx"; |
| 485 | 485 | }; |
| 486 | − src3: src@3 { | |
| 486 | + src3: src-3 { | |
| 487 | 487 | interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>; |
| 488 | 488 | dmas = <&audma0 0x8b>, <&audma1 0xa0>; |
| 489 | 489 | dma-names = "rx", "tx"; |
| 490 | 490 | }; |
| 491 | − src4: src@4 { | |
| 491 | + src4: src-4 { | |
| 492 | 492 | interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>; |
| 493 | 493 | dmas = <&audma0 0x8d>, <&audma1 0xb0>; |
| 494 | 494 | dma-names = "rx", "tx"; |
| 495 | 495 | }; |
| 496 | − src5: src@5 { | |
| 496 | + src5: src-5 { | |
| 497 | 497 | interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>; |
| 498 | 498 | dmas = <&audma0 0x8f>, <&audma1 0xb2>; |
| 499 | 499 | dma-names = "rx", "tx"; |
| 500 | 500 | }; |
| 501 | − src6: src@6 { | |
| 501 | + src6: src-6 { | |
| 502 | 502 | interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>; |
| 503 | 503 | dmas = <&audma0 0x91>, <&audma1 0xb4>; |
| 504 | 504 | dma-names = "rx", "tx"; |
| 505 | 505 | }; |
| 506 | − src7: src@7 { | |
| 506 | + src7: src-7 { | |
| 507 | 507 | interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>; |
| 508 | 508 | dmas = <&audma0 0x93>, <&audma1 0xb6>; |
| 509 | 509 | dma-names = "rx", "tx"; |
| 510 | 510 | }; |
| 511 | − src8: src@8 { | |
| 511 | + src8: src-8 { | |
| 512 | 512 | interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>; |
| 513 | 513 | dmas = <&audma0 0x95>, <&audma1 0xb8>; |
| 514 | 514 | dma-names = "rx", "tx"; |
| 515 | 515 | }; |
| 516 | − src9: src@9 { | |
| 516 | + src9: src-9 { | |
| 517 | 517 | interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>; |
| 518 | 518 | dmas = <&audma0 0x97>, <&audma1 0xba>; |
| 519 | 519 | dma-names = "rx", "tx"; |
| @@ -521,52 +521,52 @@ rcar_sound: sound@ec500000 { · 1 unmodified line | ||
| 521 | 521 | }; |
| 522 | 522 | |
| 523 | 523 | rcar_sound,ssi { |
| 524 | − ssi0: ssi@0 { | |
| 524 | + ssi0: ssi-0 { | |
| 525 | 525 | interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>; |
| 526 | 526 | dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>; |
| 527 | 527 | dma-names = "rx", "tx", "rxu", "txu"; |
| 528 | 528 | }; |
| 529 | − ssi1: ssi@1 { | |
| 529 | + ssi1: ssi-1 { | |
| 530 | 530 | interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>; |
| 531 | 531 | dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>; |
| 532 | 532 | dma-names = "rx", "tx", "rxu", "txu"; |
| 533 | 533 | }; |
| 534 | − ssi2: ssi@2 { | |
| 534 | + ssi2: ssi-2 { | |
| 535 | 535 | interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>; |
| 536 | 536 | dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>; |
| 537 | 537 | dma-names = "rx", "tx", "rxu", "txu"; |
| 538 | 538 | }; |
| 539 | − ssi3: ssi@3 { | |
| 539 | + ssi3: ssi-3 { | |
| 540 | 540 | interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>; |
| 541 | 541 | dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>; |
| 542 | 542 | dma-names = "rx", "tx", "rxu", "txu"; |
| 543 | 543 | }; |
| 544 | − ssi4: ssi@4 { | |
| 544 | + ssi4: ssi-4 { | |
| 545 | 545 | interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>; |
| 546 | 546 | dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>; |
| 547 | 547 | dma-names = "rx", "tx", "rxu", "txu"; |
| 548 | 548 | }; |
| 549 | − ssi5: ssi@5 { | |
| 549 | + ssi5: ssi-5 { | |
| 550 | 550 | interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>; |
| 551 | 551 | dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>; |
| 552 | 552 | dma-names = "rx", "tx", "rxu", "txu"; |
| 553 | 553 | }; |
| 554 | − ssi6: ssi@6 { | |
| 554 | + ssi6: ssi-6 { | |
| 555 | 555 | interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>; |
| 556 | 556 | dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>; |
| 557 | 557 | dma-names = "rx", "tx", "rxu", "txu"; |
| 558 | 558 | }; |
| 559 | − ssi7: ssi@7 { | |
| 559 | + ssi7: ssi-7 { | |
| 560 | 560 | interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>; |
| 561 | 561 | dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>; |
| 562 | 562 | dma-names = "rx", "tx", "rxu", "txu"; |
| 563 | 563 | }; |
| 564 | − ssi8: ssi@8 { | |
| 564 | + ssi8: ssi-8 { | |
| 565 | 565 | interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>; |
| 566 | 566 | dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>; |
| 567 | 567 | dma-names = "rx", "tx", "rxu", "txu"; |
| 568 | 568 | }; |
| 569 | − ssi9: ssi@9 { | |
| 569 | + ssi9: ssi-9 { | |
| 570 | 570 | interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>; |
| 571 | 571 | dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>; |
| 572 | 572 | dma-names = "rx", "tx", "rxu", "txu"; |
| @@ -621,7 +621,6 @@ Example: simple sound card · 48 unmodified lines | ||
| 621 | 621 | /* Single DAI */ |
| 622 | 622 | #sound-dai-cells = <0>; |
| 623 | 623 | |
| 624 | − status = "okay"; | |
| 625 | 624 | |
| 626 | 625 | rcar_sound,dai { |
| 627 | 626 | dai0 { |
| @@ -667,7 +666,6 @@ Example: simple sound card for Multi channel · 39 unmodified lines | ||
| 667 | 666 | /* Single DAI */ |
| 668 | 667 | #sound-dai-cells = <0>; |
| 669 | 668 | |
| 670 | − status = "okay"; | |
| 671 | 669 | |
| 672 | 670 | rcar_sound,dai { |
| 673 | 671 | dai0 { |
| @@ -29,11 +29,13 @@ pdm: pdm@ff040000 { · 28 unmodified lines | ||
| 29 | 29 | dma-names = "rx"; |
| 30 | 30 | pinctrl-names = "default", "sleep"; |
| 31 | 31 | pinctrl-0 = <&pdmm0_clk |
| 32 | − &pdmm0_fsync | |
| 33 | 32 | &pdmm0_sdi0 |
| 34 | 33 | &pdmm0_sdi1 |
| 35 | 34 | &pdmm0_sdi2 |
| 36 | 35 | &pdmm0_sdi3>; |
| 37 | − pinctrl-1 = <&pdmm0_sleep>; | |
| 38 | − status = "disabled"; | |
| 36 | + pinctrl-1 = <&pdmm0_clk_sleep | |
| 37 | + &pdmm0_sdi0_sleep | |
| 38 | + &pdmm0_sdi1_sleep | |
| 39 | + &pdmm0_sdi2_sleep | |
| 40 | + &pdmm0_sdi3_sleep>; | |
| 39 | 41 | }; |
| @@ -4,7 +4,7 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible: "rockchip,rk3399-gru-sound" |
| 5 | 5 | - rockchip,cpu: The phandle of the Rockchip I2S controller that's |
| 6 | 6 | connected to the codecs |
| 7 | −- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs | |
| 7 | +- rockchip,codec: The phandle of the audio codecs | |
| 8 | 8 | |
| 9 | 9 | Optional properties: |
| 10 | 10 | - dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready. |
| @@ -7,8 +7,12 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | |
| 8 | 8 | - compatible: should be one of the following: |
| 9 | 9 | - "rockchip,rk3066-i2s": for rk3066 |
| 10 | + - "rockchip,rk3036-i2s", "rockchip,rk3066-i2s": for rk3036 | |
| 10 | 11 | - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188 |
| 12 | + - "rockchip,rk3228-i2s", "rockchip,rk3066-i2s": for rk3228 | |
| 11 | 13 | - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288 |
| 14 | + - "rockchip,rk3328-i2s", "rockchip,rk3066-i2s": for rk3328 | |
| 15 | + - "rockchip,rk3366-i2s", "rockchip,rk3066-i2s": for rk3366 | |
| 12 | 16 | - "rockchip,rk3368-i2s", "rockchip,rk3066-i2s": for rk3368 |
| 13 | 17 | - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399 |
| 14 | 18 | - reg: physical base address of the controller and length of memory mapped |
| @@ -41,6 +41,5 @@ spdif: spdif@0x1011e000 { · 40 unmodified lines | ||
| 41 | 41 | dma-names = "tx"; |
| 42 | 42 | clock-names = "hclk", "mclk"; |
| 43 | 43 | clocks = <&cru HCLK_SPDIF>, <&cru SCLK_SPDIF>; |
| 44 | − status = "disabled"; | |
| 45 | 44 | #sound-dai-cells = <0>; |
| 46 | 45 | }; |
| @@ -0,0 +1,33 @@ | ||
| 1 | +RT274 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : "realtek,rt274". | |
| 8 | + | |
| 9 | +- reg : The I2C address of the device. | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | + | |
| 13 | +- interrupts : The CODEC's interrupt output. | |
| 14 | + | |
| 15 | + | |
| 16 | +Pins on the device (for linking into audio routes) for RT274: | |
| 17 | + | |
| 18 | + * DMIC1 Pin | |
| 19 | + * DMIC2 Pin | |
| 20 | + * MIC | |
| 21 | + * LINE1 | |
| 22 | + * LINE2 | |
| 23 | + * HPO Pin | |
| 24 | + * SPDIF | |
| 25 | + * LINE3 | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + | |
| 29 | +codec: rt274@1c { | |
| 30 | + compatible = "realtek,rt274"; | |
| 31 | + reg = <0x1c>; | |
| 32 | + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; | |
| 33 | +}; | |
| @@ -12,6 +12,14 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | |
| 13 | 13 | Optional properties: |
| 14 | 14 | |
| 15 | +- "realtek,dc_offset_l_manual" | |
| 16 | +- "realtek,dc_offset_r_manual" | |
| 17 | +- "realtek,dc_offset_l_manual_mic" | |
| 18 | +- "realtek,dc_offset_r_manual_mic" | |
| 19 | + Based on the different PCB layout, add the manual offset value to | |
| 20 | + compensate the DC offset for each L and R channel, and they are different | |
| 21 | + between headphone and headset. | |
| 22 | + | |
| 15 | 23 | Pins on the device (for linking into audio routes) for RT5663: |
| 16 | 24 | |
| 17 | 25 | * IN1P |
| @@ -7,9 +7,6 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - model - the user-visible name of this sound complex |
| 8 | 8 | - clocks - should contain entries matching clock names in the clock-names |
| 9 | 9 | property |
| 10 | − - clock-names - should contain following entries: | |
| 11 | − - "epll" - indicating the EPLL output clock | |
| 12 | − - "i2s_rclk" - indicating the RCLK (root) clock of the I2S0 controller | |
| 13 | 10 | - samsung,audio-widgets - this property specifies off-codec audio elements |
| 14 | 11 | like headphones or speakers, for details see widgets.txt |
| 15 | 12 | - samsung,audio-routing - a list of the connections between audio |
| @@ -46,9 +43,6 @@ sound { · 30 unmodified lines | ||
| 46 | 43 | "IN1", "Mic Jack", |
| 47 | 44 | "Mic Jack", "MICBIAS"; |
| 48 | 45 | |
| 49 | − clocks = <&clock CLK_FOUT_EPLL>, <&i2s0 CLK_I2S_RCLK_SRC>; | |
| 50 | − clock-names = "epll", "sclk_i2s"; | |
| 51 | − | |
| 52 | 46 | cpu { |
| 53 | 47 | sound-dai = <&i2s0 0>; |
| 54 | 48 | }; |
| @@ -86,6 +86,9 @@ Optional CPU/CODEC subnodes properties: · 85 unmodified lines | ||
| 86 | 86 | in dai startup() and disabled with |
| 87 | 87 | clk_disable_unprepare() in dai |
| 88 | 88 | shutdown(). |
| 89 | +- system-clock-direction-out : specifies clock direction as 'out' on | |
| 90 | + initialization. It is useful for some aCPUs with | |
| 91 | + fixed clocks. | |
| 89 | 92 | |
| 90 | 93 | Example 1 - single DAI link: |
| 91 | 94 | |
| @@ -24,6 +24,7 @@ Optional subnode properties: · 23 unmodified lines | ||
| 24 | 24 | - simple-audio-card,convert-rate : platform specified sampling rate convert |
| 25 | 25 | - simple-audio-card,convert-channels : platform specified converted channel size (2 - 8 ch) |
| 26 | 26 | - simple-audio-card,prefix : see routing |
| 27 | +- simple-audio-card,widgets : Please refer to widgets.txt. | |
| 27 | 28 | - simple-audio-card,routing : A list of the connections between audio components. |
| 28 | 29 | Each entry is a pair of strings, the first being the connection's sink, |
| 29 | 30 | the second being the connection's source. Valid names for sources. |
| @@ -53,7 +53,6 @@ Example: · 52 unmodified lines | ||
| 53 | 53 | |
| 54 | 54 | sti_uni_player1: sti-uni-player@0x8D81000 { |
| 55 | 55 | compatible = "st,stih407-uni-player-hdmi"; |
| 56 | − status = "okay"; | |
| 57 | 56 | #sound-dai-cells = <0>; |
| 58 | 57 | st,syscfg = <&syscfg_core>; |
| 59 | 58 | clocks = <&clk_s_d0_flexgen CLK_PCM_1>; |
| @@ -66,7 +65,6 @@ Example: · 6 unmodified lines | ||
| 66 | 65 | |
| 67 | 66 | sti_uni_player2: sti-uni-player@0x8D82000 { |
| 68 | 67 | compatible = "st,stih407-uni-player-pcm-out"; |
| 69 | − status = "okay"; | |
| 70 | 68 | #sound-dai-cells = <0>; |
| 71 | 69 | st,syscfg = <&syscfg_core>; |
| 72 | 70 | clocks = <&clk_s_d0_flexgen CLK_PCM_2>; |
| @@ -78,7 +76,6 @@ Example: · 5 unmodified lines | ||
| 78 | 76 | |
| 79 | 77 | sti_uni_player3: sti-uni-player@0x8D85000 { |
| 80 | 78 | compatible = "st,stih407-uni-player-spdif"; |
| 81 | − status = "okay"; | |
| 82 | 79 | #sound-dai-cells = <0>; |
| 83 | 80 | st,syscfg = <&syscfg_core>; |
| 84 | 81 | clocks = <&clk_s_d0_flexgen CLK_SPDIFF>; |
| @@ -90,7 +87,6 @@ Example: · 5 unmodified lines | ||
| 90 | 87 | |
| 91 | 88 | sti_uni_reader1: sti-uni-reader@0x8D84000 { |
| 92 | 89 | compatible = "st,stih407-uni-reader-hdmi"; |
| 93 | − status = "disabled"; | |
| 94 | 90 | #sound-dai-cells = <0>; |
| 95 | 91 | st,syscfg = <&syscfg_core>; |
| 96 | 92 | reg = <0x8D84000 0x158>; |
| @@ -125,7 +121,6 @@ Example of audio card declaration: · 28 unmodified lines | ||
| 125 | 121 | sound { |
| 126 | 122 | compatible = "simple-audio-card"; |
| 127 | 123 | simple-audio-card,name = "sti audio card"; |
| 128 | − status = "okay"; | |
| 129 | 124 | |
| 130 | 125 | simple-audio-card,dai-link@0 { |
| 131 | 126 | /* DAC */ |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible: should be one of the following: |
| 9 | 9 | - "allwinner,sun4i-a10-i2s" |
| 10 | 10 | - "allwinner,sun6i-a31-i2s" |
| 11 | + - "allwinner,sun8i-h3-i2s" | |
| 11 | 12 | - reg: physical base address of the controller and length of memory mapped |
| 12 | 13 | region. |
| 13 | 14 | - interrupts: should contain the I2S interrupt. |
| @@ -22,6 +23,7 @@ Required properties: · 8 unmodified lines | ||
| 22 | 23 | |
| 23 | 24 | Required properties for the following compatibles: |
| 24 | 25 | - "allwinner,sun6i-a31-i2s" |
| 26 | + - "allwinner,sun8i-h3-i2s" | |
| 25 | 27 | - resets: phandle to the reset line for this codec |
| 26 | 28 | |
| 27 | 29 | Example: |
| @@ -39,5 +39,4 @@ spdif: spdif@01c21000 { · 38 unmodified lines | ||
| 39 | 39 | clock-names = "apb", "spdif"; |
| 40 | 40 | dmas = <&dma 0 2>, <&dma 0 2>; |
| 41 | 41 | dma-names = "rx", "tx"; |
| 42 | − status = "okay"; | |
| 43 | 42 | }; |
| @@ -17,7 +17,6 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | Example: |
| 18 | 18 | |
| 19 | 19 | tas5720: tas5720@6c { |
| 20 | − status = "okay"; | |
| 21 | 20 | compatible = "ti,tas5720"; |
| 22 | 21 | reg = <0x6c>; |
| 23 | 22 | dvdd-supply = <&vdd_3v3_reg>; |
| @@ -3,7 +3,9 @@ Texas Instruments - tlv320aic32x4 Codec module · 2 unmodified lines | ||
| 3 | 3 | The tlv320aic32x4 serial control bus communicates through I2C protocols |
| 4 | 4 | |
| 5 | 5 | Required properties: |
| 6 | − - compatible: Should be "ti,tlv320aic32x4" | |
| 6 | + - compatible - "string" - One of: | |
| 7 | + "ti,tlv320aic32x4" TLV320AIC3204 | |
| 8 | + "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256 | |
| 7 | 9 | - reg: I2C slave address |
| 8 | 10 | - supply-*: Required supply regulators are: |
| 9 | 11 | "iov" - digital IO power supply |
| @@ -18,6 +20,8 @@ Optional properties: · 8 unmodified lines | ||
| 18 | 20 | - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt |
| 19 | 21 | - clocks/clock-names: Clock named 'mclk' for the master clock of the codec. |
| 20 | 22 | See clock/clock-bindings.txt for information about the detailed format. |
| 23 | + - aic32x4-gpio-func - <array of 5 int> | |
| 24 | + - Types are defined in include/sound/tlv320aic32x4.h | |
| 21 | 25 | |
| 22 | 26 | |
| 23 | 27 | Example: |
| @@ -27,4 +31,11 @@ codec: tlv320aic32x4@18 { · 3 unmodified lines | ||
| 27 | 31 | reg = <0x18>; |
| 28 | 32 | clocks = <&clks 201>; |
| 29 | 33 | clock-names = "mclk"; |
| 34 | + aic32x4-gpio-func= < | |
| 35 | + 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ | |
| 36 | + 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ | |
| 37 | + 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */ | |
| 38 | + 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */ | |
| 39 | + 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */ | |
| 40 | + >; | |
| 30 | 41 | }; |
| @@ -26,6 +26,11 @@ Optional properties: · 25 unmodified lines | ||
| 26 | 26 | 3 - MICBIAS output is connected to AVDD, |
| 27 | 27 | If this node is not mentioned or if the value is incorrect, then MicBias |
| 28 | 28 | is powered down. |
| 29 | +- ai3x-ocmv - Output Common-Mode Voltage selection: | |
| 30 | + 0 - 1.35V, | |
| 31 | + 1 - 1.5V, | |
| 32 | + 2 - 1.65V, | |
| 33 | + 3 - 1.8V | |
| 29 | 34 | - AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the |
| 30 | 35 | device as covered in Documentation/devicetree/bindings/regulator/regulator.txt |
| 31 | 36 | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +WM8524 audio CODEC | |
| 2 | + | |
| 3 | +This device does not use I2C or SPI but a simple Hardware Control Interface. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | + - compatible : "wlf,wm8524" | |
| 8 | + | |
| 9 | + - wlf,mute-gpios: a GPIO spec for the MUTE pin. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +codec: wm8524@0 { | |
| 14 | + compatible = "wlf,wm8524"; | |
| 15 | + wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; | |
| 16 | +}; | |
| @@ -27,7 +27,6 @@ Example: · 26 unmodified lines | ||
| 27 | 27 | interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; |
| 28 | 28 | dmas = <&dma 5>, <&dma 6>; |
| 29 | 29 | dma-names = "tx", "rx"; |
| 30 | − status = "okay"; | |
| 31 | 30 | }; |
| 32 | 31 | |
| 33 | 32 | sound { |
| @@ -24,5 +24,4 @@ Example: · 23 unmodified lines | ||
| 24 | 24 | interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; |
| 25 | 25 | dmas = <&dma 4>; |
| 26 | 26 | dma-names = "tx"; |
| 27 | − status = "okay"; | |
| 28 | 27 | }; |
| @@ -28,7 +28,6 @@ spi1: spi@0x4000c400 { /* USART1 */ · 27 unmodified lines | ||
| 28 | 28 | clocks = <&cmu 20>; |
| 29 | 29 | cs-gpios = <&gpio 51 1>; // D3 |
| 30 | 30 | energymicro,location = <1>; |
| 31 | − status = "ok"; | |
| 32 | 31 | |
| 33 | 32 | ks8851@0 { |
| 34 | 33 | compatible = "ks8851"; |
| @@ -36,6 +35,5 @@ spi1: spi@0x4000c400 { /* USART1 */ · 1 unmodified line | ||
| 36 | 35 | reg = <0>; |
| 37 | 36 | interrupt-parent = <&boardfpga>; |
| 38 | 37 | interrupts = <4>; |
| 39 | − status = "ok"; | |
| 40 | 38 | }; |
| 41 | 39 | }; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31 |
| 10 | 10 | - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 |
| 11 | 11 | - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51 |
| 12 | + - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and later Soc | |
| 12 | 13 | - reg : Offset and length of the register set for the device |
| 13 | 14 | - interrupts : Should contain CSPI/eCSPI interrupt |
| 14 | 15 | - cs-gpios : Specifies the gpio pins to be used for chipselects. |
| @@ -38,5 +38,4 @@ spi@7000d600 { · 37 unmodified lines | ||
| 38 | 38 | reset-names = "spi"; |
| 39 | 39 | dmas = <&apbdma 16>, <&apbdma 16>; |
| 40 | 40 | dma-names = "rx", "tx"; |
| 41 | − status = "disabled"; | |
| 42 | 41 | }; |
| @@ -34,5 +34,4 @@ spi@7000c380 { · 33 unmodified lines | ||
| 34 | 34 | reset-names = "spi"; |
| 35 | 35 | dmas = <&apbdma 11>, <&apbdma 11>; |
| 36 | 36 | dma-names = "rx", "tx"; |
| 37 | − status = "disabled"; | |
| 38 | 37 | }; |
| @@ -34,5 +34,4 @@ spi@7000d600 { · 33 unmodified lines | ||
| 34 | 34 | reset-names = "spi"; |
| 35 | 35 | dmas = <&apbdma 16>, <&apbdma 16>; |
| 36 | 36 | dma-names = "rx", "tx"; |
| 37 | − status = "disabled"; | |
| 38 | 37 | }; |
| @@ -24,6 +24,5 @@ Example: · 23 unmodified lines | ||
| 24 | 24 | interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>; |
| 25 | 25 | #address-cells = <1>; |
| 26 | 26 | #size-cells = <0>; |
| 27 | − status = "disabled"; | |
| 28 | 27 | }; |
| 29 | 28 | |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | "renesas,msiof-r8a7792" (R-Car V2H) |
| 7 | 7 | "renesas,msiof-r8a7793" (R-Car M2-N) |
| 8 | 8 | "renesas,msiof-r8a7794" (R-Car E2) |
| 9 | + "renesas,msiof-r8a7795" (R-Car H3) | |
| 9 | 10 | "renesas,msiof-r8a7796" (R-Car M3-W) |
| 10 | 11 | "renesas,msiof-sh73a0" (SH-Mobile AG5) |
| 11 | 12 | "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) |
| @@ -78,5 +79,4 @@ Example: · 66 unmodified lines | ||
| 78 | 79 | dma-names = "tx", "rx"; |
| 79 | 80 | #address-cells = <1>; |
| 80 | 81 | #size-cells = <0>; |
| 81 | − status = "disabled"; | |
| 82 | 82 | }; |
| @@ -23,7 +23,6 @@ spi@80000500 { · 22 unmodified lines | ||
| 23 | 23 | reg = <0x80000500 0x4>; |
| 24 | 24 | interrupts = <15>; |
| 25 | 25 | clocks = <&clks CLPS711X_CLK_SPI>; |
| 26 | − status = "disabled"; | |
| 27 | 26 | }; |
| 28 | 27 | |
| 29 | 28 | syscon3: syscon@80002200 { |
| @@ -39,7 +39,6 @@ dspi0@4002c000 { · 38 unmodified lines | ||
| 39 | 39 | pinctrl-names = "default"; |
| 40 | 40 | pinctrl-0 = <&pinctrl_dspi0_1>; |
| 41 | 41 | big-endian; |
| 42 | − status = "okay"; | |
| 43 | 42 | |
| 44 | 43 | sflash: at26df081a@0 { |
| 45 | 44 | #address-cells = <1>; |
| @@ -57,5 +57,4 @@ spi: spi@1100a000 { · 56 unmodified lines | ||
| 57 | 57 | clock-names = "parent-clk", "sel-clk", "spi-clk"; |
| 58 | 58 | cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; |
| 59 | 59 | mediatek,pad-select = <1>, <0>; |
| 60 | − status = "disabled"; | |
| 61 | 60 | }; |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | ||
| 29 | 29 | cell-index = <0>; |
| 30 | 30 | reg = <0x10600 0x28>; |
| 31 | 31 | interrupts = <23>; |
| 32 | − status = "disabled"; | |
| 33 | 32 | }; |
| 34 | 33 | |
| 35 | 34 | Example with SPI direct mode support (optionally): |
| @@ -48,7 +47,6 @@ Example with SPI direct mode support (optionally): · 12 unmodified lines | ||
| 48 | 47 | <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */ |
| 49 | 48 | <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */ |
| 50 | 49 | interrupts = <23>; |
| 51 | − status = "disabled"; | |
| 52 | 50 | }; |
| 53 | 51 | |
| 54 | 52 | To enable the direct mode, the board specific 'ranges' property in the |
| @@ -6,6 +6,7 @@ and display controllers using the SPI communication interface. · 5 unmodified lines | ||
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | 8 | - compatible: should be one of the following. |
| 9 | + "rockchip,rv1108-spi" for rv1108 SoCs. | |
| 9 | 10 | "rockchip,rk3036-spi" for rk3036 SoCS. |
| 10 | 11 | "rockchip,rk3066-spi" for rk3066 SoCs. |
| 11 | 12 | "rockchip,rk3188-spi" for rk3188 SoCs. |
| @@ -18,7 +18,6 @@ spi1: spi@01c06000 { · 17 unmodified lines | ||
| 18 | 18 | interrupts = <11>; |
| 19 | 19 | clocks = <&ahb_gates 21>, <&spi1_clk>; |
| 20 | 20 | clock-names = "ahb", "mod"; |
| 21 | − status = "disabled"; | |
| 22 | 21 | #address-cells = <1>; |
| 23 | 22 | #size-cells = <0>; |
| 24 | 23 | }; |
| @@ -39,7 +39,6 @@ spi0: spi@01c68000 { · 38 unmodified lines | ||
| 39 | 39 | pinctrl-names = "default"; |
| 40 | 40 | pinctrl-0 = <&spi0_pins>; |
| 41 | 41 | resets = <&ccu RST_BUS_SPI0>; |
| 42 | − status = "disabled"; | |
| 43 | 42 | #address-cells = <1>; |
| 44 | 43 | #size-cells = <0>; |
| 45 | 44 | }; |
| @@ -26,7 +26,6 @@ spi1: spi@fffcc000 { · 25 unmodified lines | ||
| 26 | 26 | clock-names = "spi_clk"; |
| 27 | 27 | cs-gpios = <&pioB 3 0>; |
| 28 | 28 | atmel,fifo-size = <32>; |
| 29 | − status = "okay"; | |
| 30 | 29 | |
| 31 | 30 | mmc-slot@0 { |
| 32 | 31 | compatible = "mmc-spi-slot"; |
| @@ -0,0 +1,27 @@ | ||
| 1 | +* Renesas SMP SRAM | |
| 2 | + | |
| 3 | +Renesas R-Car Gen2 and RZ/G1 SoCs need a small piece of SRAM for the jump stub | |
| 4 | +for secondary CPU bringup and CPU hotplug. | |
| 5 | +This memory is reserved by adding a child node to a "mmio-sram" node, cfr. | |
| 6 | +Documentation/devicetree/bindings/sram/sram.txt. | |
| 7 | + | |
| 8 | +Required child node properties: | |
| 9 | + - compatible: Must be "renesas,smp-sram", | |
| 10 | + - reg: Address and length of the reserved SRAM. | |
| 11 | + The full physical (bus) address must be aligned to a 256 KiB boundary. | |
| 12 | + | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | + icram1: sram@e63c0000 { | |
| 17 | + compatible = "mmio-sram"; | |
| 18 | + reg = <0 0xe63c0000 0 0x1000>; | |
| 19 | + #address-cells = <1>; | |
| 20 | + #size-cells = <1>; | |
| 21 | + ranges = <0 0 0xe63c0000 0x1000>; | |
| 22 | + | |
| 23 | + smp-sram@0 { | |
| 24 | + compatible = "renesas,smp-sram"; | |
| 25 | + reg = <0 0x10>; | |
| 26 | + }; | |
| 27 | + }; | |
| @@ -9,7 +9,9 @@ Controller Node · 8 unmodified lines | ||
| 9 | 9 | --------------- |
| 10 | 10 | |
| 11 | 11 | Required properties: |
| 12 | −- compatible : "allwinner,sun4i-a10-sram-controller" | |
| 12 | +- compatible : should be: | |
| 13 | + - "allwinner,sun4i-a10-sram-controller" | |
| 14 | + - "allwinner,sun50i-a64-sram-controller" | |
| 13 | 15 | - reg : sram controller register offset + length |
| 14 | 16 | |
| 15 | 17 | SRAM nodes |
| @@ -22,10 +24,13 @@ Each SRAM will have SRAM sections that are going to be handled by the · 6 unmodified lines | ||
| 22 | 24 | SRAM controller as subnodes. These sections are represented following |
| 23 | 25 | once again the representation described in the mmio-sram binding. |
| 24 | 26 | |
| 25 | −The valid sections compatible are: | |
| 27 | +The valid sections compatible for A10 are: | |
| 26 | 28 | - allwinner,sun4i-a10-sram-a3-a4 |
| 27 | 29 | - allwinner,sun4i-a10-sram-d |
| 28 | 30 | |
| 31 | +The valid sections compatible for A64 are: | |
| 32 | + - allwinner,sun50i-a64-sram-c | |
| 33 | + | |
| 29 | 34 | Devices using SRAM sections |
| 30 | 35 | --------------------------- |
| 31 | 36 | |
| @@ -59,7 +64,6 @@ sram-controller@01c00000 { · 27 unmodified lines | ||
| 59 | 64 | emac_sram: sram-section@8000 { |
| 60 | 65 | compatible = "allwinner,sun4i-a10-sram-a3-a4"; |
| 61 | 66 | reg = <0x8000 0x4000>; |
| 62 | − status = "disabled"; | |
| 63 | 67 | }; |
| 64 | 68 | }; |
| 65 | 69 | }; |
| @@ -20,5 +20,4 @@ Example: · 19 unmodified lines | ||
| 20 | 20 | compatible = "marvell,armada370-thermal"; |
| 21 | 21 | reg = <0xd0018300 0x4 |
| 22 | 22 | 0xd0018304 0x4>; |
| 23 | − status = "okay"; | |
| 24 | 23 | }; |
| @@ -77,7 +77,6 @@ Example 1): · 76 unmodified lines | ||
| 77 | 77 | interrupts = <2 4>; |
| 78 | 78 | clocks = <&clock 383>; |
| 79 | 79 | clock-names = "tmu_apbif"; |
| 80 | − status = "disabled"; | |
| 81 | 80 | vtmu-supply = <&tmu_regulator_node>; |
| 82 | 81 | #include "exynos4412-tmu-sensor-conf.dtsi" |
| 83 | 82 | }; |
| @@ -11,6 +11,7 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | - compatible: |
| 12 | 12 | - "mediatek,mt8173-thermal" : For MT8173 family of SoCs |
| 13 | 13 | - "mediatek,mt2701-thermal" : For MT2701 family of SoCs |
| 14 | + - "mediatek,mt2712-thermal" : For MT2712 family of SoCs | |
| 14 | 15 | - reg: Address range of the thermal controller |
| 15 | 16 | - interrupts: IRQ for the thermal controller |
| 16 | 17 | - clocks, clock-names: Clocks needed for the thermal controller. required |
| @@ -36,7 +36,6 @@ Example: · 35 unmodified lines | ||
| 36 | 36 | clocks = <&cpg CPG_MOD 522>; |
| 37 | 37 | power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; |
| 38 | 38 | #thermal-sensor-cells = <1>; |
| 39 | − status = "okay"; | |
| 40 | 39 | }; |
| 41 | 40 | |
| 42 | 41 | thermal-zones { |
| @@ -4,6 +4,7 @@ Required properties: · 3 unmodified lines | ||
| 4 | 4 | - compatible : should be "rockchip,<name>-tsadc" |
| 5 | 5 | "rockchip,rk3228-tsadc": found on RK3228 SoCs |
| 6 | 6 | "rockchip,rk3288-tsadc": found on RK3288 SoCs |
| 7 | + "rockchip,rk3328-tsadc": found on RK3328 SoCs | |
| 7 | 8 | "rockchip,rk3368-tsadc": found on RK3368 SoCs |
| 8 | 9 | "rockchip,rk3399-tsadc": found on RK3399 SoCs |
| 9 | 10 | - reg : physical base address of the controller and length of memory mapped |
| @@ -0,0 +1,64 @@ | ||
| 1 | +* UniPhier Thermal bindings | |
| 2 | + | |
| 3 | +This describes the devicetree bindings for thermal monitor supported by | |
| 4 | +PVT(Process, Voltage and Temperature) monitoring unit implemented on Socionext | |
| 5 | +UniPhier SoCs. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : | |
| 9 | + - "socionext,uniphier-pxs2-thermal" : For UniPhier PXs2 SoC | |
| 10 | + - "socionext,uniphier-ld20-thermal" : For UniPhier LD20 SoC | |
| 11 | +- interrupts : IRQ for the temperature alarm | |
| 12 | +- #thermal-sensor-cells : Should be 0. See ./thermal.txt for details. | |
| 13 | + | |
| 14 | +Optional properties: | |
| 15 | +- socionext,tmod-calibration: A pair of calibrated values referred from PVT, | |
| 16 | + in case that the values aren't set on SoC, | |
| 17 | + like a reference board. | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | + sysctrl@61840000 { | |
| 22 | + compatible = "socionext,uniphier-ld20-sysctrl", | |
| 23 | + "simple-mfd", "syscon"; | |
| 24 | + reg = <0x61840000 0x10000>; | |
| 25 | + ... | |
| 26 | + pvtctl: pvtctl { | |
| 27 | + compatible = "socionext,uniphier-ld20-thermal"; | |
| 28 | + interrupts = <0 3 1>; | |
| 29 | + #thermal-sensor-cells = <0>; | |
| 30 | + }; | |
| 31 | + ... | |
| 32 | + }; | |
| 33 | + | |
| 34 | + thermal-zones { | |
| 35 | + cpu_thermal { | |
| 36 | + polling-delay-passive = <250>; /* 250ms */ | |
| 37 | + polling-delay = <1000>; /* 1000ms */ | |
| 38 | + thermal-sensors = <&pvtctl>; | |
| 39 | + | |
| 40 | + trips { | |
| 41 | + cpu_crit: cpu_crit { | |
| 42 | + temperature = <110000>; /* 110C */ | |
| 43 | + hysteresis = <2000>; | |
| 44 | + type = "critical"; | |
| 45 | + }; | |
| 46 | + cpu_alert: cpu_alert { | |
| 47 | + temperature = <100000>; /* 100C */ | |
| 48 | + hysteresis = <2000>; | |
| 49 | + type = "passive"; | |
| 50 | + }; | |
| 51 | + }; | |
| 52 | + | |
| 53 | + cooling-maps { | |
| 54 | + map0 { | |
| 55 | + trip = <&cpu_alert>; | |
| 56 | + cooling-device = <&cpu0 (-1) (-1)>; | |
| 57 | + }; | |
| 58 | + map1 { | |
| 59 | + trip = <&cpu_alert>; | |
| 60 | + cooling-device = <&cpu2 (-1) (-1)>; | |
| 61 | + }; | |
| 62 | + }; | |
| 63 | + }; | |
| 64 | + }; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +NXP Low Power Timer/Pulse Width Modulation Module (TPM) | |
| 2 | + | |
| 3 | +The Timer/PWM Module (TPM) supports input capture, output compare, | |
| 4 | +and the generation of PWM signals to control electric motor and power | |
| 5 | +management applications. The counter, compare and capture registers | |
| 6 | +are clocked by an asynchronous clock that can remain enabled in low | |
| 7 | +power modes. TPM can support global counter bus where one TPM drives | |
| 8 | +the counter bus for the others, provided bit width is the same. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | + | |
| 12 | +- compatible : should be "fsl,imx7ulp-tpm" | |
| 13 | +- reg : Specifies base physical address and size of the register sets | |
| 14 | + for the clock event device and clock source device. | |
| 15 | +- interrupts : Should be the clock event device interrupt. | |
| 16 | +- clocks : The clocks provided by the SoC to drive the timer, must contain | |
| 17 | + an entry for each entry in clock-names. | |
| 18 | +- clock-names : Must include the following entries: "igp" and "per". | |
| 19 | + | |
| 20 | +Example: | |
| 21 | +tpm5: tpm@40260000 { | |
| 22 | + compatible = "fsl,imx7ulp-tpm"; | |
| 23 | + reg = <0x40260000 0x1000>; | |
| 24 | + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; | |
| 25 | + clocks = <&clks IMX7ULP_CLK_NIC1_BUS_DIV>, | |
| 26 | + <&clks IMX7ULP_CLK_LPTPM5>; | |
| 27 | + clock-names = "ipg", "per"; | |
| 28 | +}; | |
| @@ -12,46 +12,29 @@ datasheets. · 11 unmodified lines | ||
| 12 | 12 | Required Properties: |
| 13 | 13 | |
| 14 | 14 | - compatible: must contain one or more of the following: |
| 15 | − - "renesas,cmt-32-r8a7740" for the r8a7740 32-bit CMT | |
| 16 | − (CMT0) | |
| 17 | − - "renesas,cmt-32-sh7372" for the sh7372 32-bit CMT | |
| 18 | − (CMT0) | |
| 19 | − - "renesas,cmt-32-sh73a0" for the sh73a0 32-bit CMT | |
| 20 | − (CMT0) | |
| 21 | − - "renesas,cmt-32" for all 32-bit CMT without fast clock support | |
| 22 | − (CMT0 on sh7372, sh73a0 and r8a7740) | |
| 23 | − This is a fallback for the above renesas,cmt-32-* entries. | |
| 24 | − | |
| 25 | − - "renesas,cmt-32-fast-r8a7740" for the r8a7740 32-bit CMT with fast | |
| 26 | − clock support (CMT[234]) | |
| 27 | − - "renesas,cmt-32-fast-sh7372" for the sh7372 32-bit CMT with fast | |
| 28 | − clock support (CMT[234]) | |
| 29 | − - "renesas,cmt-32-fast-sh73a0" for the sh73A0 32-bit CMT with fast | |
| 30 | − clock support (CMT[234]) | |
| 31 | − - "renesas,cmt-32-fast" for all 32-bit CMT with fast clock support | |
| 32 | − (CMT[234] on sh7372, sh73a0 and r8a7740) | |
| 33 | − This is a fallback for the above renesas,cmt-32-fast-* entries. | |
| 34 | − | |
| 35 | − - "renesas,cmt-48-sh7372" for the sh7372 48-bit CMT | |
| 36 | − (CMT1) | |
| 37 | 15 | - "renesas,cmt-48-sh73a0" for the sh73A0 48-bit CMT |
| 38 | 16 | (CMT1) |
| 39 | 17 | - "renesas,cmt-48-r8a7740" for the r8a7740 48-bit CMT |
| 40 | 18 | (CMT1) |
| 41 | 19 | - "renesas,cmt-48" for all non-second generation 48-bit CMT |
| 42 | − (CMT1 on sh7372, sh73a0 and r8a7740) | |
| 20 | + (CMT1 on sh73a0 and r8a7740) | |
| 43 | 21 | This is a fallback for the above renesas,cmt-48-* entries. |
| 44 | 22 | |
| 45 | − - "renesas,cmt-48-r8a73a4" for the r8a73a4 48-bit CMT | |
| 46 | − (CMT[01]) | |
| 47 | − - "renesas,cmt-48-r8a7790" for the r8a7790 48-bit CMT | |
| 48 | − (CMT[01]) | |
| 49 | − - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT | |
| 50 | − (CMT[01]) | |
| 51 | − - "renesas,cmt-48-gen2" for all second generation 48-bit CMT | |
| 52 | − (CMT[01] on r8a73a4, r8a7790 and r8a7791) | |
| 53 | − This is a fallback for the renesas,cmt-48-r8a73a4, | |
| 54 | − renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries. | |
| 23 | + - "renesas,cmt0-r8a73a4" for the 32-bit CMT0 device included in r8a73a4. | |
| 24 | + - "renesas,cmt1-r8a73a4" for the 48-bit CMT1 device included in r8a73a4. | |
| 25 | + - "renesas,cmt0-r8a7790" for the 32-bit CMT0 device included in r8a7790. | |
| 26 | + - "renesas,cmt1-r8a7790" for the 48-bit CMT1 device included in r8a7790. | |
| 27 | + - "renesas,cmt0-r8a7791" for the 32-bit CMT0 device included in r8a7791. | |
| 28 | + - "renesas,cmt1-r8a7791" for the 48-bit CMT1 device included in r8a7791. | |
| 29 | + - "renesas,cmt0-r8a7793" for the 32-bit CMT0 device included in r8a7793. | |
| 30 | + - "renesas,cmt1-r8a7793" for the 48-bit CMT1 device included in r8a7793. | |
| 31 | + - "renesas,cmt0-r8a7794" for the 32-bit CMT0 device included in r8a7794. | |
| 32 | + - "renesas,cmt1-r8a7794" for the 48-bit CMT1 device included in r8a7794. | |
| 33 | + | |
| 34 | + - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2. | |
| 35 | + - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2. | |
| 36 | + These are fallbacks for r8a73a4 and all the R-Car Gen2 | |
| 37 | + entries listed above. | |
| 55 | 38 | |
| 56 | 39 | - reg: base address and length of the registers block for the timer module. |
| 57 | 40 | - interrupts: interrupt-specifier for the timer, one per channel. |
| @@ -59,21 +42,29 @@ Required Properties: · 1 unmodified line | ||
| 59 | 42 | in clock-names. |
| 60 | 43 | - clock-names: must contain "fck" for the functional clock. |
| 61 | 44 | |
| 62 | − - renesas,channels-mask: bitmask of the available channels. | |
| 63 | 45 | |
| 64 | − | |
| 65 | −Example: R8A7790 (R-Car H2) CMT0 node | |
| 66 | − | |
| 67 | − CMT0 on R8A7790 implements hardware channels 5 and 6 only and names | |
| 68 | − them channels 0 and 1 in the documentation. | |
| 46 | +Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes | |
| 69 | 47 | |
| 70 | 48 | cmt0: timer@ffca0000 { |
| 71 | − compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2"; | |
| 49 | + compatible = "renesas,cmt0-r8a7790", "renesas,rcar-gen2-cmt0"; | |
| 72 | 50 | reg = <0 0xffca0000 0 0x1004>; |
| 73 | 51 | interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>, |
| 74 | 52 | <0 142 IRQ_TYPE_LEVEL_HIGH>; |
| 75 | 53 | clocks = <&mstp1_clks R8A7790_CLK_CMT0>; |
| 76 | 54 | clock-names = "fck"; |
| 55 | + }; | |
| 77 | 56 | |
| 78 | − renesas,channels-mask = <0x60>; | |
| 57 | + cmt1: timer@e6130000 { | |
| 58 | + compatible = "renesas,cmt1-r8a7790", "renesas,rcar-gen2-cmt1"; | |
| 59 | + reg = <0 0xe6130000 0 0x1004>; | |
| 60 | + interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>, | |
| 61 | + <0 121 IRQ_TYPE_LEVEL_HIGH>, | |
| 62 | + <0 122 IRQ_TYPE_LEVEL_HIGH>, | |
| 63 | + <0 123 IRQ_TYPE_LEVEL_HIGH>, | |
| 64 | + <0 124 IRQ_TYPE_LEVEL_HIGH>, | |
| 65 | + <0 125 IRQ_TYPE_LEVEL_HIGH>, | |
| 66 | + <0 126 IRQ_TYPE_LEVEL_HIGH>, | |
| 67 | + <0 127 IRQ_TYPE_LEVEL_HIGH>; | |
| 68 | + clocks = <&mstp3_clks R8A7790_CLK_CMT1>; | |
| 69 | + clock-names = "fck"; | |
| 79 | 70 | }; |
| @@ -21,6 +21,16 @@ adi,adt7490 +/-1C TDM Extended Temp Range I.C · 20 unmodified lines | ||
| 21 | 21 | adi,adxl345 Three-Axis Digital Accelerometer |
| 22 | 22 | adi,adxl346 Three-Axis Digital Accelerometer (backward-compatibility value "adi,adxl345" must be listed too) |
| 23 | 23 | ams,iaq-core AMS iAQ-Core VOC Sensor |
| 24 | +amstaos,tsl2571 AMS/TAOS ALS and proximity sensor | |
| 25 | +amstaos,tsl2671 AMS/TAOS ALS and proximity sensor | |
| 26 | +amstaos,tmd2671 AMS/TAOS ALS and proximity sensor | |
| 27 | +amstaos,tsl2771 AMS/TAOS ALS and proximity sensor | |
| 28 | +amstaos,tmd2771 AMS/TAOS ALS and proximity sensor | |
| 29 | +amstaos,tsl2572 AMS/TAOS ALS and proximity sensor | |
| 30 | +amstaos,tsl2672 AMS/TAOS ALS and proximity sensor | |
| 31 | +amstaos,tmd2672 AMS/TAOS ALS and proximity sensor | |
| 32 | +amstaos,tsl2772 AMS/TAOS ALS and proximity sensor | |
| 33 | +amstaos,tmd2772 AMS/TAOS ALS and proximity sensor | |
| 24 | 34 | at,24c08 i2c serial eeprom (24cxx) |
| 25 | 35 | atmel,at97sc3204t i2c trusted platform module (TPM) |
| 26 | 36 | capella,cm32181 CM32181: Ambient Light Sensor |
| @@ -36,7 +46,9 @@ dallas,ds1775 Tiny Digital Thermometer and Thermostat · 9 unmodified lines | ||
| 36 | 46 | dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM |
| 37 | 47 | dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O |
| 38 | 48 | dallas,ds75 Digital Thermometer and Thermostat |
| 49 | +devantech,srf02 Devantech SRF02 ultrasonic ranger in I2C mode | |
| 39 | 50 | devantech,srf08 Devantech SRF08 ultrasonic ranger |
| 51 | +devantech,srf10 Devantech SRF10 ultrasonic ranger | |
| 40 | 52 | dlg,da9053 DA9053: flexible system level PMIC with multicore support |
| 41 | 53 | dlg,da9063 DA9063: system PMIC for quad-core application processors |
| 42 | 54 | domintech,dmard09 DMARD09: 3-axis Accelerometer |
| @@ -54,6 +66,7 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec · 11 unmodified lines | ||
| 54 | 66 | gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface |
| 55 | 67 | infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) |
| 56 | 68 | infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) |
| 69 | +isil,isl1208 Intersil ISL1208 Low Power RTC with Battery Backed SRAM | |
| 57 | 70 | isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor |
| 58 | 71 | isil,isl29030 Intersil ISL29030 Ambient Light and Proximity Sensor |
| 59 | 72 | maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator |
| @@ -168,6 +181,7 @@ st,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS · 108 unmodified lines | ||
| 168 | 181 | taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface |
| 169 | 182 | ti,ads7828 8-Channels, 12-bit ADC |
| 170 | 183 | ti,ads7830 8-Channels, 8-bit ADC |
| 184 | +ti,amc6821 Temperature Monitoring and Fan Control | |
| 171 | 185 | ti,tsc2003 I2C Touch-Screen Controller |
| 172 | 186 | ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface |
| 173 | 187 | ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface |
| @@ -10,7 +10,6 @@ All other properties are optional. · 9 unmodified lines | ||
| 10 | 10 | Example: |
| 11 | 11 | unittest { |
| 12 | 12 | compatible = "unittest"; |
| 13 | − status = "okay"; | |
| 14 | 13 | }; |
| 15 | 14 | |
| 16 | 15 | 2) OF unittest i2c adapter platform device |
| @@ -25,7 +24,6 @@ Children nodes contain unittest i2c devices. · 8 unmodified lines | ||
| 25 | 24 | Example: |
| 26 | 25 | unittest-i2c-bus { |
| 27 | 26 | compatible = "unittest-i2c-bus"; |
| 28 | − status = "okay"; | |
| 29 | 27 | }; |
| 30 | 28 | |
| 31 | 29 | 3) OF unittest i2c device |
| @@ -40,7 +38,6 @@ All other properties are optional · 8 unmodified lines | ||
| 40 | 38 | Example: |
| 41 | 39 | unittest-i2c-dev { |
| 42 | 40 | compatible = "unittest-i2c-dev"; |
| 43 | − status = "okay"; | |
| 44 | 41 | }; |
| 45 | 42 | |
| 46 | 43 | 4) OF unittest i2c mux device |
| @@ -55,7 +52,6 @@ Children nodes contain unittest i2c bus nodes per channel. · 8 unmodified lines | ||
| 55 | 52 | Example: |
| 56 | 53 | unittest-i2c-mux { |
| 57 | 54 | compatible = "unittest-i2c-mux"; |
| 58 | − status = "okay"; | |
| 59 | 55 | #address-cells = <1>; |
| 60 | 56 | #size-cells = <0>; |
| 61 | 57 | channel-0 { |
| @@ -65,7 +61,6 @@ Example: · 3 unmodified lines | ||
| 65 | 61 | i2c-dev { |
| 66 | 62 | reg = <8>; |
| 67 | 63 | compatible = "unittest-i2c-dev"; |
| 68 | − status = "okay"; | |
| 69 | 64 | }; |
| 70 | 65 | }; |
| 71 | 66 | }; |
| @@ -25,5 +25,4 @@ Example: · 24 unmodified lines | ||
| 25 | 25 | phys = <&usbphy 0>; |
| 26 | 26 | phy-names = "usb"; |
| 27 | 27 | extcon = <&usbphy 0>; |
| 28 | − status = "disabled"; | |
| 29 | 28 | }; |
| @@ -4,9 +4,9 @@ · 3 unmodified lines | ||
| 4 | 4 | - reg: offset and length of the usbss register sets |
| 5 | 5 | - ti,hwmods : must be "usb_otg_hs" |
| 6 | 6 | |
| 7 | −The glue layer contains multiple child nodes. It is required the have | |
| 7 | +The glue layer contains multiple child nodes. It is required to have | |
| 8 | 8 | at least a control module node, USB node and a PHY node. The second USB |
| 9 | −node and its PHY node is optional. The DMA node is also optional. | |
| 9 | +node and its PHY node are optional. The DMA node is also optional. | |
| 10 | 10 | |
| 11 | 11 | Reset module |
| 12 | 12 | ~~~~~~~~~~~~ |
| @@ -0,0 +1,29 @@ | ||
| 1 | +Broadcom USB Device Controller (BDC) | |
| 2 | +==================================== | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + | |
| 6 | +- compatible: must be one of: | |
| 7 | + "brcm,bdc-v0.16" | |
| 8 | + "brcm,bdc" | |
| 9 | +- reg: the base register address and length | |
| 10 | +- interrupts: the interrupt line for this controller | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | + | |
| 14 | +On Broadcom STB platforms, these properties are required: | |
| 15 | + | |
| 16 | +- phys: phandle to one or two USB PHY blocks | |
| 17 | + NOTE: Some SoC's have a single phy and some have | |
| 18 | + USB 2.0 and USB 3.0 phys | |
| 19 | +- clocks: phandle to the functional clock of this block | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + | |
| 23 | + bdc@f0b02000 { | |
| 24 | + compatible = "brcm,bdc-v0.16"; | |
| 25 | + reg = <0xf0b02000 0xfc4>; | |
| 26 | + interrupts = <0x0 0x60 0x0>; | |
| 27 | + phys = <&usbphy_0 0x0>; | |
| 28 | + clocks = <&sw_usbd>; | |
| 29 | + }; | |
| @@ -42,7 +42,6 @@ Example: · 41 unmodified lines | ||
| 42 | 42 | usb_phy: usb-phy { |
| 43 | 43 | compatible = "ti,da830-usb-phy"; |
| 44 | 44 | #phy-cells = <0>; |
| 45 | − status = "okay"; | |
| 46 | 45 | }; |
| 47 | 46 | usb0: usb@200000 { |
| 48 | 47 | compatible = "ti,da830-musb"; |
| @@ -66,7 +65,6 @@ Example: · 17 unmodified lines | ||
| 66 | 65 | "rx1", "rx2", "rx3", "rx4", |
| 67 | 66 | "tx1", "tx2", "tx3", "tx4"; |
| 68 | 67 | |
| 69 | − status = "okay"; | |
| 70 | 68 | |
| 71 | 69 | cppi41dma: dma-controller@201000 { |
| 72 | 70 | compatible = "ti,da830-cppi41"; |
| @@ -42,7 +42,6 @@ or "device". · 41 unmodified lines | ||
| 42 | 42 | Example: |
| 43 | 43 | |
| 44 | 44 | st_dwc3: dwc3@8f94000 { |
| 45 | − status = "disabled"; | |
| 46 | 45 | compatible = "st,stih407-dwc3"; |
| 47 | 46 | reg = <0x08f94000 0x1000>, <0x110 0x4>; |
| 48 | 47 | reg-names = "reg-glue", "syscfg-reg"; |
| @@ -18,7 +18,6 @@ Example device node: · 17 unmodified lines | ||
| 18 | 18 | usb@0 { |
| 19 | 19 | #address-cells = <0x2>; |
| 20 | 20 | #size-cells = <0x1>; |
| 21 | − status = "okay"; | |
| 22 | 21 | compatible = "xlnx,zynqmp-dwc3"; |
| 23 | 22 | clock-names = "bus_clk" "ref_clk"; |
| 24 | 23 | clocks = <&clk125>, <&clk125>; |
| @@ -31,7 +31,6 @@ Example: · 30 unmodified lines | ||
| 31 | 31 | clocks = <&clk_s_a1_ls 0>; |
| 32 | 32 | phys = <&usb2_phy>; |
| 33 | 33 | phy-names = "usb"; |
| 34 | − status = "okay"; | |
| 35 | 34 | |
| 36 | 35 | resets = <&powerdown STIH416_USB1_POWERDOWN>, |
| 37 | 36 | <&softreset STIH416_USB1_SOFTRESET>; |
| @@ -40,7 +40,6 @@ Example: · 39 unmodified lines | ||
| 40 | 40 | port@0 { |
| 41 | 41 | reg = <0>; |
| 42 | 42 | phys = <&usb2phy 1>; |
| 43 | − status = "disabled"; | |
| 44 | 43 | }; |
| 45 | 44 | }; |
| 46 | 45 | |
| @@ -75,7 +74,6 @@ Example: · 28 unmodified lines | ||
| 75 | 74 | port@0 { |
| 76 | 75 | reg = <0>; |
| 77 | 76 | phys = <&usb2phy 1>; |
| 78 | − status = "disabled"; | |
| 79 | 77 | }; |
| 80 | 78 | |
| 81 | 79 | }; |
| @@ -0,0 +1,29 @@ | ||
| 1 | +Fairchild FUSB302 Type-C Port controllers | |
| 2 | + | |
| 3 | +Required properties : | |
| 4 | +- compatible : "fcs,fusb302" | |
| 5 | +- reg : I2C slave address | |
| 6 | +- interrupts : Interrupt specifier | |
| 7 | + | |
| 8 | +Optional properties : | |
| 9 | +- fcs,max-sink-microvolt : Maximum voltage to negotiate when configured as sink | |
| 10 | +- fcs,max-sink-microamp : Maximum current to negotiate when configured as sink | |
| 11 | +- fcs,max-sink-microwatt : Maximum power to negotiate when configured as sink | |
| 12 | + If this is less then max-sink-microvolt * | |
| 13 | + max-sink-microamp then the configured current will | |
| 14 | + be clamped. | |
| 15 | +- fcs,operating-sink-microwatt : | |
| 16 | + Minimum amount of power accepted from a sink | |
| 17 | + when negotiating | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | +fusb302: typec-portc@54 { | |
| 22 | + compatible = "fcs,fusb302"; | |
| 23 | + reg = <0x54>; | |
| 24 | + interrupt-parent = <&nmi_intc>; | |
| 25 | + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; | |
| 26 | + fcs,max-sink-microvolt = <12000000>; | |
| 27 | + fcs,max-sink-microamp = <3000000>; | |
| 28 | + fcs,max-sink-microwatt = <36000000>; | |
| 29 | +}; | |
| @@ -21,5 +21,4 @@ Example: · 20 unmodified lines | ||
| 21 | 21 | interrupt-parent = <&mic>; |
| 22 | 22 | interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; |
| 23 | 23 | transceiver = <&isp1301>; |
| 24 | − status = "okay"; | |
| 25 | 24 | }; |
| @@ -12,8 +12,21 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | MPU. |
| 13 | 13 | - ranges: allows valid 1:1 translation between child's address space and |
| 14 | 14 | parent's address space. |
| 15 | − - clocks: Clock IDs array as required by the controller. | |
| 16 | − - clock-names: names of clocks correseponding to IDs in the clock property. | |
| 15 | + | |
| 16 | +SoC-specific Required Properties: | |
| 17 | +The following are mandatory properties for Keystone 2 66AK2HK, 66AK2L and 66AK2E | |
| 18 | +SoCs only: | |
| 19 | + | |
| 20 | +- clocks: Clock ID for USB functional clock. | |
| 21 | +- clock-names: Must be "usb". | |
| 22 | + | |
| 23 | + | |
| 24 | +The following are mandatory properties for Keystone 2 66AK2G SoCs only: | |
| 25 | + | |
| 26 | +- power-domains: Should contain a phandle to a PM domain provider node | |
| 27 | + and an args specifier containing the USB device id | |
| 28 | + value. This property is as per the binding, | |
| 29 | + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt | |
| 17 | 30 | |
| 18 | 31 | Sub-nodes: |
| 19 | 32 | The dwc3 core should be added as subnode to Keystone DWC3 glue. |
| @@ -31,7 +44,6 @@ Example: · 11 unmodified lines | ||
| 31 | 44 | clock-names = "usb"; |
| 32 | 45 | interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; |
| 33 | 46 | ranges; |
| 34 | − status = "disabled"; | |
| 35 | 47 | |
| 36 | 48 | dwc3@2690000 { |
| 37 | 49 | compatible = "synopsys,dwc3"; |
| @@ -11,7 +11,11 @@ into two parts. · 10 unmodified lines | ||
| 11 | 11 | ------------------------------------------------------------------------ |
| 12 | 12 | |
| 13 | 13 | Required properties: |
| 14 | − - compatible : should contain "mediatek,mt8173-xhci" | |
| 14 | + - compatible : should be "mediatek,<soc-model>-xhci", "mediatek,mtk-xhci", | |
| 15 | + soc-model is the name of SoC, such as mt8173, mt2712 etc, when using | |
| 16 | + "mediatek,mtk-xhci" compatible string, you need SoC specific ones in | |
| 17 | + addition, one of: | |
| 18 | + - "mediatek,mt8173-xhci" | |
| 15 | 19 | - reg : specifies physical base address and size of the registers |
| 16 | 20 | - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control |
| 17 | 21 | - interrupts : interrupt used by the controller |
| @@ -68,10 +72,14 @@ usb30: usb@11270000 { · 50 unmodified lines | ||
| 68 | 72 | |
| 69 | 73 | In the case, xhci is added as subnode to mtu3. An example and the DT binding |
| 70 | 74 | details of mtu3 can be found in: |
| 71 | −Documentation/devicetree/bindings/usb/mt8173-mtu3.txt | |
| 75 | +Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | |
| 72 | 76 | |
| 73 | 77 | Required properties: |
| 74 | − - compatible : should contain "mediatek,mt8173-xhci" | |
| 78 | + - compatible : should be "mediatek,<soc-model>-xhci", "mediatek,mtk-xhci", | |
| 79 | + soc-model is the name of SoC, such as mt8173, mt2712 etc, when using | |
| 80 | + "mediatek,mtk-xhci" compatible string, you need SoC specific ones in | |
| 81 | + addition, one of: | |
| 82 | + - "mediatek,mt8173-xhci" | |
| 75 | 83 | - reg : specifies physical base address and size of the registers |
| 76 | 84 | - reg-names: should be "mac" for xHCI MAC |
| 77 | 85 | - interrupts : interrupt used by the host controller |
| @@ -1,7 +1,11 @@ | ||
| 1 | 1 | The device node for Mediatek USB3.0 DRD controller |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | − - compatible : should be "mediatek,mt8173-mtu3" | |
| 4 | + - compatible : should be "mediatek,<soc-model>-mtu3", "mediatek,mtu3", | |
| 5 | + soc-model is the name of SoC, such as mt8173, mt2712 etc, | |
| 6 | + when using "mediatek,mtu3" compatible string, you need SoC specific | |
| 7 | + ones in addition, one of: | |
| 8 | + - "mediatek,mt8173-mtu3" | |
| 5 | 9 | - reg : specifies physical base address and size of the registers |
| 6 | 10 | - reg-names: should be "mac" for device IP and "ippc" for IP port control |
| 7 | 11 | - interrupts : interrupt used by the device IP |
| @@ -44,7 +48,7 @@ Optional properties: · 36 unmodified lines | ||
| 44 | 48 | Sub-nodes: |
| 45 | 49 | The xhci should be added as subnode to mtu3 as shown in the following example |
| 46 | 50 | if host mode is enabled. The DT binding details of xhci can be found in: |
| 47 | −Documentation/devicetree/bindings/usb/mt8173-xhci.txt | |
| 51 | +Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | |
| 48 | 52 | |
| 49 | 53 | Example: |
| 50 | 54 | ssusb: usb@11271000 { |
| @@ -71,7 +75,6 @@ ssusb: usb@11271000 { · 20 unmodified lines | ||
| 71 | 75 | #address-cells = <2>; |
| 72 | 76 | #size-cells = <2>; |
| 73 | 77 | ranges; |
| 74 | − status = "disabled"; | |
| 75 | 78 | |
| 76 | 79 | usb_host: xhci@11270000 { |
| 77 | 80 | compatible = "mediatek,mt8173-xhci"; |
| @@ -82,6 +85,5 @@ ssusb: usb@11271000 { · 4 unmodified lines | ||
| 82 | 85 | clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>; |
| 83 | 86 | clock-names = "sys_ck", "ref_ck"; |
| 84 | 87 | vusb33-supply = <&mt6397_vusb_reg>; |
| 85 | − status = "disabled"; | |
| 86 | 88 | }; |
| 87 | 89 | }; |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | ||
| 29 | 29 | clock-names = "ic", "clk48"; |
| 30 | 30 | phys = <&usb2_phy>; |
| 31 | 31 | phy-names = "usb"; |
| 32 | − status = "okay"; | |
| 33 | 32 | |
| 34 | 33 | resets = <&powerdown STIH416_USB0_POWERDOWN>, |
| 35 | 34 | <&softreset STIH416_USB0_SOFTRESET>; |
| @@ -29,7 +29,6 @@ Example device nodes: · 28 unmodified lines | ||
| 29 | 29 | clock-names = "ref"; |
| 30 | 30 | #phy-cells = <0>; |
| 31 | 31 | |
| 32 | − status = "ok"; | |
| 33 | 32 | }; |
| 34 | 33 | |
| 35 | 34 | ss_phy: phy@100f8830 { |
| @@ -39,7 +38,6 @@ Example device nodes: · 3 unmodified lines | ||
| 39 | 38 | clock-names = "ref"; |
| 40 | 39 | #phy-cells = <0>; |
| 41 | 40 | |
| 42 | − status = "ok"; | |
| 43 | 41 | }; |
| 44 | 42 | |
| 45 | 43 | usb3_0: usb30@0 { |
| @@ -51,7 +49,6 @@ Example device nodes: · 5 unmodified lines | ||
| 51 | 49 | |
| 52 | 50 | ranges; |
| 53 | 51 | |
| 54 | − status = "ok"; | |
| 55 | 52 | |
| 56 | 53 | dwc3@10000000 { |
| 57 | 54 | compatible = "snps,dwc3"; |
| @@ -3,20 +3,30 @@ Renesas Electronics USB3.0 Peripheral driver · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: Must contain one of the following: |
| 5 | 5 | - "renesas,r8a7795-usb3-peri" |
| 6 | + - "renesas,r8a7796-usb3-peri" | |
| 7 | + - "renesas,rcar-gen3-usb3-peri" for a generic R-Car Gen3 compatible | |
| 8 | + device | |
| 9 | + | |
| 10 | + When compatible with the generic version, nodes must list the | |
| 11 | + SoC-specific version corresponding to the platform first | |
| 12 | + followed by the generic version. | |
| 13 | + | |
| 6 | 14 | - reg: Base address and length of the register for the USB3.0 Peripheral |
| 7 | 15 | - interrupts: Interrupt specifier for the USB3.0 Peripheral |
| 8 | 16 | - clocks: clock phandle and specifier pair |
| 9 | 17 | |
| 10 | −Example: | |
| 18 | +Example of R-Car H3 ES1.x: | |
| 11 | 19 | usb3_peri0: usb@ee020000 { |
| 12 | − compatible = "renesas,r8a7795-usb3-peri"; | |
| 20 | + compatible = "renesas,r8a7795-usb3-peri", | |
| 21 | + "renesas,rcar-gen3-usb3-peri"; | |
| 13 | 22 | reg = <0 0xee020000 0 0x400>; |
| 14 | 23 | interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; |
| 15 | 24 | clocks = <&cpg CPG_MOD 328>; |
| 16 | 25 | }; |
| 17 | 26 | |
| 18 | 27 | usb3_peri1: usb@ee060000 { |
| 19 | − compatible = "renesas,r8a7795-usb3-peri"; | |
| 28 | + compatible = "renesas,r8a7795-usb3-peri", | |
| 29 | + "renesas,rcar-gen3-usb3-peri"; | |
| 20 | 30 | reg = <0 0xee060000 0 0x400>; |
| 21 | 31 | interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; |
| 22 | 32 | clocks = <&cpg CPG_MOD 327>; |
| @@ -29,13 +29,11 @@ Example device nodes: · 28 unmodified lines | ||
| 29 | 29 | #address-cells = <2>; |
| 30 | 30 | #size-cells = <2>; |
| 31 | 31 | ranges; |
| 32 | − status = "disabled"; | |
| 33 | 32 | usbdrd_dwc3_0: dwc3@fe800000 { |
| 34 | 33 | compatible = "snps,dwc3"; |
| 35 | 34 | reg = <0x0 0xfe800000 0x0 0x100000>; |
| 36 | 35 | interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; |
| 37 | 36 | dr_mode = "otg"; |
| 38 | − status = "disabled"; | |
| 39 | 37 | }; |
| 40 | 38 | }; |
| 41 | 39 | |
| @@ -48,12 +46,10 @@ Example device nodes: · 6 unmodified lines | ||
| 48 | 46 | #address-cells = <2>; |
| 49 | 47 | #size-cells = <2>; |
| 50 | 48 | ranges; |
| 51 | − status = "disabled"; | |
| 52 | 49 | usbdrd_dwc3_1: dwc3@fe900000 { |
| 53 | 50 | compatible = "snps,dwc3"; |
| 54 | 51 | reg = <0x0 0xfe900000 0x0 0x100000>; |
| 55 | 52 | interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; |
| 56 | 53 | dr_mode = "otg"; |
| 57 | − status = "disabled"; | |
| 58 | 54 | }; |
| 59 | 55 | }; |
| @@ -2,7 +2,7 @@ Generic USB Device Properties · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Usually, we only use device tree for hard wired USB device. |
| 4 | 4 | The reference binding doc is from: |
| 5 | −http://www.firmware.org/1275/bindings/usb/usb-1_0.ps | |
| 5 | +http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps | |
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: usbVID,PID. The textual representation of VID, PID shall |
| @@ -16,7 +16,6 @@ Required properties: · 7 unmodified lines | ||
| 16 | 16 | Example: |
| 17 | 17 | |
| 18 | 18 | &usb1 { |
| 19 | − status = "okay"; | |
| 20 | 19 | |
| 21 | 20 | #address-cells = <1>; |
| 22 | 21 | #size-cells = <0>; |
| @@ -3,12 +3,13 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. · 2 unmodified lines | ||
| 3 | 3 | This isn't an exhaustive list, but you should add new prefixes to it before |
| 4 | 4 | using them to avoid name-space collisions. |
| 5 | 5 | |
| 6 | −abcn Abracon Corporation | |
| 7 | 6 | abilis Abilis Systems |
| 7 | +abracon Abracon Corporation | |
| 8 | 8 | actions Actions Semiconductor Co., Ltd. |
| 9 | 9 | active-semi Active-Semi International Inc |
| 10 | 10 | ad Avionic Design GmbH |
| 11 | 11 | adapteva Adapteva, Inc. |
| 12 | +adaptrum Adaptrum, Inc. | |
| 12 | 13 | adh AD Holdings Plc. |
| 13 | 14 | adi Analog Devices, Inc. |
| 14 | 15 | advantech Advantech Corporation |
| @@ -47,6 +48,7 @@ avic Shanghai AVIC Optoelectronics Co., Ltd. · 32 unmodified lines | ||
| 47 | 48 | axentia Axentia Technologies AB |
| 48 | 49 | axis Axis Communications AB |
| 49 | 50 | bananapi BIPAI KEJI LIMITED |
| 51 | +bhf Beckhoff Automation GmbH & Co. KG | |
| 50 | 52 | boe BOE Technology Group Co., Ltd. |
| 51 | 53 | bosch Bosch Sensortec GmbH |
| 52 | 54 | boundary Boundary Devices Inc. |
| @@ -176,6 +178,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd. · 123 unmodified lines | ||
| 176 | 178 | kyo Kyocera Corporation |
| 177 | 179 | lacie LaCie |
| 178 | 180 | lantiq Lantiq Semiconductor |
| 181 | +lattice Lattice Semiconductor | |
| 179 | 182 | lego LEGO Systems A/S |
| 180 | 183 | lenovo Lenovo Group Ltd. |
| 181 | 184 | lg LG Corporation |
| @@ -196,6 +199,7 @@ mediatek MediaTek Inc. · 14 unmodified lines | ||
| 196 | 199 | megachips MegaChips |
| 197 | 200 | melexis Melexis N.V. |
| 198 | 201 | melfas MELFAS Inc. |
| 202 | +mellanox Mellanox Technologies | |
| 199 | 203 | memsic MEMSIC Inc. |
| 200 | 204 | merrii Merrii Technology Co., Ltd. |
| 201 | 205 | micrel Micrel Inc. |
| @@ -207,7 +211,7 @@ miramems MiraMEMS Sensing Technology Co., Ltd. · 5 unmodified lines | ||
| 207 | 211 | mitsubishi Mitsubishi Electric Corporation |
| 208 | 212 | mosaixtech Mosaix Technologies, Inc. |
| 209 | 213 | motorola Motorola, Inc. |
| 210 | −moxa Moxa | |
| 214 | +moxa Moxa Inc. | |
| 211 | 215 | mpl MPL AG |
| 212 | 216 | mqmaker mqmaker Inc. |
| 213 | 217 | msi Micro-Star International Co. Ltd. |
| @@ -250,6 +254,7 @@ oxsemi Oxford Semiconductor, Ltd. · 36 unmodified lines | ||
| 250 | 254 | panasonic Panasonic Corporation |
| 251 | 255 | parade Parade Technologies Inc. |
| 252 | 256 | pericom Pericom Technology Inc. |
| 257 | +pervasive Pervasive Displays, Inc. | |
| 253 | 258 | phytec PHYTEC Messtechnik GmbH |
| 254 | 259 | picochip Picochip Ltd |
| 255 | 260 | pine64 Pine64 |
| @@ -288,6 +293,7 @@ schindler Schindler · 32 unmodified lines | ||
| 288 | 293 | seagate Seagate Technology PLC |
| 289 | 294 | semtech Semtech Corporation |
| 290 | 295 | sensirion Sensirion AG |
| 296 | +sff Small Form Factor Committee | |
| 291 | 297 | sgx SGX Sensortech |
| 292 | 298 | sharp Sharp Corporation |
| 293 | 299 | si-en Si-En Technology Ltd. |
| @@ -342,6 +348,7 @@ tpo TPO · 48 unmodified lines | ||
| 342 | 348 | tronfy Tronfy |
| 343 | 349 | tronsmart Tronsmart |
| 344 | 350 | truly Truly Semiconductors Limited |
| 351 | +tsd Theobroma Systems Design und Consulting GmbH | |
| 345 | 352 | tyan Tyan Computer Corporation |
| 346 | 353 | ucrobotics uCRobotics |
| 347 | 354 | udoo Udoo |
| @@ -354,6 +361,7 @@ variscite Variscite Ltd. · 6 unmodified lines | ||
| 354 | 361 | via VIA Technologies, Inc. |
| 355 | 362 | virtio Virtual I/O Device Specification, developed by the OASIS consortium |
| 356 | 363 | vivante Vivante Corporation |
| 364 | +vocore VoCore Studio | |
| 357 | 365 | voipac Voipac Technologies s.r.o. |
| 358 | 366 | wd Western Digital Corp. |
| 359 | 367 | wetek WeTek Electronics, limited. |
| @@ -15,5 +15,4 @@ owire: owire@63fa4000 { · 14 unmodified lines | ||
| 15 | 15 | compatible = "fsl,imx53-owire", "fsl,imx21-owire"; |
| 16 | 16 | reg = <0x63fa4000 0x4000>; |
| 17 | 17 | clocks = <&clks 159>; |
| 18 | − status = "disabled"; | |
| 19 | 18 | }; |
| @@ -8,9 +8,49 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - reg: physical base address of the controller and length of memory mapped |
| 9 | 9 | region |
| 10 | 10 | |
| 11 | +Optional properties: | |
| 12 | + | |
| 13 | + - aspeed,reset-type = "cpu|soc|system|none" | |
| 14 | + | |
| 15 | + Reset behavior - Whenever a timeout occurs the watchdog can be programmed | |
| 16 | + to generate one of three different, mutually exclusive, types of resets. | |
| 17 | + | |
| 18 | + Type "none" can be specified to indicate that no resets are to be done. | |
| 19 | + This is useful in situations where another watchdog engine on chip is | |
| 20 | + to perform the reset. | |
| 21 | + | |
| 22 | + If 'aspeed,reset-type=' is not specfied the default is to enable system | |
| 23 | + reset. | |
| 24 | + | |
| 25 | + Reset types: | |
| 26 | + | |
| 27 | + - cpu: Reset CPU on watchdog timeout | |
| 28 | + | |
| 29 | + - soc: Reset 'System on Chip' on watchdog timeout | |
| 30 | + | |
| 31 | + - system: Reset system on watchdog timeout | |
| 32 | + | |
| 33 | + - none: No reset is performed on timeout. Assumes another watchdog | |
| 34 | + engine is responsible for this. | |
| 35 | + | |
| 36 | + - aspeed,alt-boot: If property is present then boot from alternate block. | |
| 37 | + - aspeed,external-signal: If property is present then signal is sent to | |
| 38 | + external reset counter (only WDT1 and WDT2). If not | |
| 39 | + specified no external signal is sent. | |
| 40 | + - aspeed,ext-pulse-duration: External signal pulse duration in microseconds | |
| 41 | + | |
| 42 | +Optional properties for AST2500-compatible watchdogs: | |
| 43 | + - aspeed,ext-push-pull: If aspeed,external-signal is present, set the pin's | |
| 44 | + drive type to push-pull. The default is open-drain. | |
| 45 | + - aspeed,ext-active-high: If aspeed,external-signal is present and and the pin | |
| 46 | + is configured as push-pull, then set the pulse | |
| 47 | + polarity to active-high. The default is active-low. | |
| 48 | + | |
| 11 | 49 | Example: |
| 12 | 50 | |
| 13 | 51 | wdt1: watchdog@1e785000 { |
| 14 | 52 | compatible = "aspeed,ast2400-wdt"; |
| 15 | 53 | reg = <0x1e785000 0x1c>; |
| 54 | + aspeed,reset-type = "system"; | |
| 55 | + aspeed,external-signal; | |
| 16 | 56 | }; |
| @@ -31,5 +31,4 @@ Example: · 30 unmodified lines | ||
| 31 | 31 | atmel,watchdog-type = "hardware"; |
| 32 | 32 | atmel,dbg-halt; |
| 33 | 33 | atmel,idle-halt; |
| 34 | − status = "okay"; | |
| 35 | 34 | }; |
| @@ -48,5 +48,4 @@ Example: · 47 unmodified lines | ||
| 48 | 48 | atmel,idle-halt; |
| 49 | 49 | atmel,max-heartbeat-sec = <16>; |
| 50 | 50 | atmel,min-heartbeat-sec = <0>; |
| 51 | − status = "okay"; | |
| 52 | 51 | }; |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Lantiq WTD watchdog binding | |
| 2 | +============================ | |
| 3 | + | |
| 4 | +This describes the binding of the Lantiq watchdog driver. | |
| 5 | + | |
| 6 | +------------------------------------------------------------------------------- | |
| 7 | +Required properties: | |
| 8 | +- compatible : Should be one of | |
| 9 | + "lantiq,wdt" | |
| 10 | + "lantiq,xrx100-wdt" | |
| 11 | + "lantiq,xrx200-wdt", "lantiq,xrx100-wdt" | |
| 12 | + "lantiq,falcon-wdt" | |
| 13 | +- reg : Address of the watchdog block | |
| 14 | +- lantiq,rcu : A phandle to the RCU syscon (required for | |
| 15 | + "lantiq,falcon-wdt" and "lantiq,xrx100-wdt") | |
| 16 | + | |
| 17 | +------------------------------------------------------------------------------- | |
| 18 | +Example for the watchdog on the xRX200 SoCs: | |
| 19 | + watchdog@803f0 { | |
| 20 | + compatible = "lantiq,xrx200-wdt", "lantiq,xrx100-wdt"; | |
| 21 | + reg = <0x803f0 0x10>; | |
| 22 | + | |
| 23 | + lantiq,rcu = <&rcu0>; | |
| 24 | + }; | |
| @@ -41,6 +41,5 @@ Example: · 40 unmodified lines | ||
| 41 | 41 | reg = <0x20300 0x28>, <0x20108 0x4>; |
| 42 | 42 | interrupts = <3>; |
| 43 | 43 | timeout-sec = <10>; |
| 44 | − status = "okay"; | |
| 45 | 44 | clocks = <&gate_clk 7>; |
| 46 | 45 | }; |
| @@ -2,7 +2,11 @@ Meson SoCs Watchdog timer · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | −- compatible : should be "amlogic,meson6-wdt" or "amlogic,meson8b-wdt" | |
| 5 | +- compatible : depending on the SoC this should be one of: | |
| 6 | + "amlogic,meson6-wdt" on Meson6 SoCs | |
| 7 | + "amlogic,meson8-wdt" and "amlogic,meson6-wdt" on Meson8 SoCs | |
| 8 | + "amlogic,meson8b-wdt" on Meson8b SoCs | |
| 9 | + "amlogic,meson8m2-wdt" and "amlogic,meson8b-wdt" on Meson8m2 SoCs | |
| 6 | 10 | - reg : Specifies base physical address and size of the registers. |
| 7 | 11 | |
| 8 | 12 | Example: |
| @@ -3,9 +3,11 @@ Mediatek SoCs Watchdog timer · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | 5 | - compatible should contain: |
| 6 | − * "mediatek,mt2701-wdt" for MT2701 compatible watchdog timers | |
| 7 | − * "mediatek,mt6589-wdt" for all compatible watchdog timers (MT2701, | |
| 8 | − MT6589) | |
| 6 | + "mediatek,mt2701-wdt", "mediatek,mt6589-wdt": for MT2701 | |
| 7 | + "mediatek,mt6589-wdt": for MT6589 | |
| 8 | + "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 | |
| 9 | + "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 | |
| 10 | + "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 | |
| 9 | 11 | |
| 10 | 12 | - reg : Specifies base physical address and size of the registers. |
| 11 | 13 | |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | Examples with soctypes are: |
| 7 | 7 | - "renesas,r8a7795-wdt" (R-Car H3) |
| 8 | 8 | - "renesas,r8a7796-wdt" (R-Car M3-W) |
| 9 | + - "renesas,r8a77995-wdt" (R-Car D3) | |
| 9 | 10 | - "renesas,r7s72100-wdt" (RZ/A1) |
| 10 | 11 | |
| 11 | 12 | When compatible with the generic version, nodes must list the SoC-specific |
| @@ -281,6 +281,8 @@ · 280 unmodified lines | ||
| 281 | 281 | capabilities of the underlying ICAP hardware |
| 282 | 282 | differ between different families. May be |
| 283 | 283 | 'virtex2p', 'virtex4', or 'virtex5'. |
| 284 | + - compatible : should contain "xlnx,xps-hwicap-1.00.a" or | |
| 285 | + "xlnx,opb-hwicap-1.00.b". | |
| 284 | 286 | |
| 285 | 287 | vi) Xilinx Uart 16550 |
| 286 | 288 | |
| @@ -1282,7 +1282,7 @@ hierarchy and routing of interrupts in the hardware. · 1281 unmodified lines | ||
| 1282 | 1282 | The interrupt tree model is fully described in the |
| 1283 | 1283 | document "Open Firmware Recommended Practice: Interrupt |
| 1284 | 1284 | Mapping Version 0.9". The document is available at: |
| 1285 | −<http://www.openfirmware.org/ofwg/practice/> | |
| 1285 | +<http://www.devicetree.org/open-firmware/practice/> | |
| 1286 | 1286 | |
| 1287 | 1287 | 1) interrupts property |
| 1288 | 1288 | ---------------------- |
| @@ -181,13 +181,6 @@ Currently, the types available are: · 180 unmodified lines | ||
| 181 | 181 | - Used by the client drivers to register a callback that will be |
| 182 | 182 | called on a regular basis through the DMA controller interrupt |
| 183 | 183 | |
| 184 | − * DMA_SG | |
| 185 | − - The device supports memory to memory scatter-gather | |
| 186 | − transfers. | |
| 187 | − - Even though a plain memcpy can look like a particular case of a | |
| 188 | − scatter-gather transfer, with a single chunk to transfer, it's a | |
| 189 | − distinct transaction type in the mem2mem transfers case | |
| 190 | − | |
| 191 | 184 | * DMA_PRIVATE |
| 192 | 185 | - The devices only supports slave transfers, and as such isn't |
| 193 | 186 | available for async transfers. |
| @@ -395,6 +388,13 @@ where to put them) · 201 unmodified lines | ||
| 395 | 388 | when DMA_CTRL_REUSE is already set |
| 396 | 389 | - Terminating the channel |
| 397 | 390 | |
| 391 | + * DMA_PREP_CMD | |
| 392 | + - If set, the client driver tells DMA controller that passed data in DMA | |
| 393 | + API is command data. | |
| 394 | + - Interpretation of command data is DMA controller specific. It can be | |
| 395 | + used for issuing commands to other peripherals/register reads/register | |
| 396 | + writes for which the descriptor should be in different format from | |
| 397 | + normal data descriptors. | |
| 398 | 398 | |
| 399 | 399 | General Design Notes |
| 400 | 400 | -------------------- |
| @@ -19,6 +19,110 @@ Finally, there are thousands of plain text documentation files scattered around · 18 unmodified lines | ||
| 19 | 19 | ``Documentation``. Some of these will likely be converted to reStructuredText |
| 20 | 20 | over time, but the bulk of them will remain in plain text. |
| 21 | 21 | |
| 22 | +.. _sphinx_install: | |
| 23 | + | |
| 24 | +Sphinx Install | |
| 25 | +============== | |
| 26 | + | |
| 27 | +The ReST markups currently used by the Documentation/ files are meant to be | |
| 28 | +built with ``Sphinx`` version 1.3 or upper. If you're desiring to build | |
| 29 | +PDF outputs, it is recommended to use version 1.4.6 or upper. | |
| 30 | + | |
| 31 | +There's a script that checks for the Spinx requirements. Please see | |
| 32 | +:ref:`sphinx-pre-install` for further details. | |
| 33 | + | |
| 34 | +Most distributions are shipped with Sphinx, but its toolchain is fragile, | |
| 35 | +and it is not uncommon that upgrading it or some other Python packages | |
| 36 | +on your machine would cause the documentation build to break. | |
| 37 | + | |
| 38 | +A way to get rid of that is to use a different version than the one shipped | |
| 39 | +on your distributions. In order to do that, it is recommended to install | |
| 40 | +Sphinx inside a virtual environment, using ``virtualenv-3`` | |
| 41 | +or ``virtualenv``, depending on how your distribution packaged Python 3. | |
| 42 | + | |
| 43 | +.. note:: | |
| 44 | + | |
| 45 | + #) Sphinx versions below 1.5 don't work properly with Python's | |
| 46 | + docutils version 0.13.1 or upper. So, if you're willing to use | |
| 47 | + those versions, you should run ``pip install 'docutils==0.12'``. | |
| 48 | + | |
| 49 | + #) It is recommended to use the RTD theme for html output. Depending | |
| 50 | + on the Sphinx version, it should be installed in separate, | |
| 51 | + with ``pip install sphinx_rtd_theme``. | |
| 52 | + | |
| 53 | + #) Some ReST pages contain math expressions. Due to the way Sphinx work, | |
| 54 | + those expressions are written using LaTeX notation. It needs texlive | |
| 55 | + installed with amdfonts and amsmath in order to evaluate them. | |
| 56 | + | |
| 57 | +In summary, if you want to install Sphinx version 1.4.9, you should do:: | |
| 58 | + | |
| 59 | + $ virtualenv sphinx_1.4 | |
| 60 | + $ . sphinx_1.4/bin/activate | |
| 61 | + (sphinx_1.4) $ pip install -r Documentation/sphinx/requirements.txt | |
| 62 | + | |
| 63 | +After running ``. sphinx_1.4/bin/activate``, the prompt will change, | |
| 64 | +in order to indicate that you're using the new environment. If you | |
| 65 | +open a new shell, you need to rerun this command to enter again at | |
| 66 | +the virtual environment before building the documentation. | |
| 67 | + | |
| 68 | +Image output | |
| 69 | +------------ | |
| 70 | + | |
| 71 | +The kernel documentation build system contains an extension that | |
| 72 | +handles images on both GraphViz and SVG formats (see | |
| 73 | +:ref:`sphinx_kfigure`). | |
| 74 | + | |
| 75 | +For it to work, you need to install both GraphViz and ImageMagick | |
| 76 | +packages. If those packages are not installed, the build system will | |
| 77 | +still build the documentation, but won't include any images at the | |
| 78 | +output. | |
| 79 | + | |
| 80 | +PDF and LaTeX builds | |
| 81 | +-------------------- | |
| 82 | + | |
| 83 | +Such builds are currently supported only with Sphinx versions 1.4 and upper. | |
| 84 | + | |
| 85 | +For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265. | |
| 86 | + | |
| 87 | +Depending on the distribution, you may also need to install a series of | |
| 88 | +``texlive`` packages that provide the minimal set of functionalities | |
| 89 | +required for ``XeLaTeX`` to work. | |
| 90 | + | |
| 91 | +.. _sphinx-pre-install: | |
| 92 | + | |
| 93 | +Checking for Sphinx dependencies | |
| 94 | +-------------------------------- | |
| 95 | + | |
| 96 | +There's a script that automatically check for Sphinx dependencies. If it can | |
| 97 | +recognize your distribution, it will also give a hint about the install | |
| 98 | +command line options for your distro:: | |
| 99 | + | |
| 100 | + $ ./scripts/sphinx-pre-install | |
| 101 | + Checking if the needed tools for Fedora release 26 (Twenty Six) are available | |
| 102 | + Warning: better to also install "texlive-luatex85". | |
| 103 | + You should run: | |
| 104 | + | |
| 105 | + sudo dnf install -y texlive-luatex85 | |
| 106 | + /usr/bin/virtualenv sphinx_1.4 | |
| 107 | + . sphinx_1.4/bin/activate | |
| 108 | + pip install -r Documentation/sphinx/requirements.txt | |
| 109 | + | |
| 110 | + Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468. | |
| 111 | + | |
| 112 | +By default, it checks all the requirements for both html and PDF, including | |
| 113 | +the requirements for images, math expressions and LaTeX build, and assumes | |
| 114 | +that a virtual Python environment will be used. The ones needed for html | |
| 115 | +builds are assumed to be mandatory; the others to be optional. | |
| 116 | + | |
| 117 | +It supports two optional parameters: | |
| 118 | + | |
| 119 | +``--no-pdf`` | |
| 120 | + Disable checks for PDF; | |
| 121 | + | |
| 122 | +``--no-virtualenv`` | |
| 123 | + Use OS packaging for Sphinx instead of Python virtual environment. | |
| 124 | + | |
| 125 | + | |
| 22 | 126 | Sphinx Build |
| 23 | 127 | ============ |
| 24 | 128 | |
| @@ -118,7 +222,7 @@ Here are some specific guidelines for the kernel documentation: · 93 unmodified lines | ||
| 118 | 222 | the C domain |
| 119 | 223 | ------------ |
| 120 | 224 | |
| 121 | −The `Sphinx C Domain`_ (name c) is suited for documentation of C API. E.g. a | |
| 225 | +The **Sphinx C Domain** (name c) is suited for documentation of C API. E.g. a | |
| 122 | 226 | function prototype: |
| 123 | 227 | |
| 124 | 228 | .. code-block:: rst |
| @@ -229,6 +333,7 @@ Rendered as: · 104 unmodified lines | ||
| 229 | 333 | |
| 230 | 334 | - column 3 |
| 231 | 335 | |
| 336 | +.. _sphinx_kfigure: | |
| 232 | 337 | |
| 233 | 338 | Figures & Images |
| 234 | 339 | ================ |
| @@ -259,5 +259,4 @@ wakeup.bin · 258 unmodified lines | ||
| 259 | 259 | wakeup.elf |
| 260 | 260 | wakeup.lds |
| 261 | 261 | zImage* |
| 262 | −zconf.hash.c | |
| 263 | 262 | zoffset.h |
| @@ -4,7 +4,7 @@ Driver Basics · 3 unmodified lines | ||
| 4 | 4 | Driver Entry and Exit points |
| 5 | 5 | ---------------------------- |
| 6 | 6 | |
| 7 | −.. kernel-doc:: include/linux/init.h | |
| 7 | +.. kernel-doc:: include/linux/module.h | |
| 8 | 8 | :internal: |
| 9 | 9 | |
| 10 | 10 | Driver device table |
| @@ -103,9 +103,6 @@ Kernel utility functions · 92 unmodified lines | ||
| 103 | 103 | .. kernel-doc:: kernel/panic.c |
| 104 | 104 | :export: |
| 105 | 105 | |
| 106 | −.. kernel-doc:: kernel/sys.c | |
| 107 | − :export: | |
| 108 | − | |
| 109 | 106 | .. kernel-doc:: kernel/rcu/tree.c |
| 110 | 107 | :export: |
| 111 | 108 | |
| @@ -139,9 +139,6 @@ DMA Fences · 138 unmodified lines | ||
| 139 | 139 | Seqno Hardware Fences |
| 140 | 140 | ~~~~~~~~~~~~~~~~~~~~~ |
| 141 | 141 | |
| 142 | −.. kernel-doc:: drivers/dma-buf/seqno-fence.c | |
| 143 | − :export: | |
| 144 | − | |
| 145 | 142 | .. kernel-doc:: include/linux/seqno-fence.h |
| 146 | 143 | :internal: |
| 147 | 144 | |
| @@ -44,17 +44,6 @@ request_firmware_nowait · 43 unmodified lines | ||
| 44 | 44 | .. kernel-doc:: drivers/base/firmware_class.c |
| 45 | 45 | :functions: request_firmware_nowait |
| 46 | 46 | |
| 47 | −Considerations for suspend and resume | |
| 48 | −===================================== | |
| 49 | − | |
| 50 | −During suspend and resume only the built-in firmware and the firmware cache | |
| 51 | −elements of the firmware API can be used. This is managed by fw_pm_notify(). | |
| 52 | − | |
| 53 | −fw_pm_notify | |
| 54 | −------------ | |
| 55 | −.. kernel-doc:: drivers/base/firmware_class.c | |
| 56 | − :functions: fw_pm_notify | |
| 57 | − | |
| 58 | 47 | request firmware API expected driver use |
| 59 | 48 | ======================================== |
| 60 | 49 | |
| @@ -0,0 +1,45 @@ | ||
| 1 | +=================================== | |
| 2 | +General Purpose Input/Output (GPIO) | |
| 3 | +=================================== | |
| 4 | + | |
| 5 | +Core | |
| 6 | +==== | |
| 7 | + | |
| 8 | +.. kernel-doc:: include/linux/gpio/driver.h | |
| 9 | + :internal: | |
| 10 | + | |
| 11 | +.. kernel-doc:: drivers/gpio/gpiolib.c | |
| 12 | + :export: | |
| 13 | + | |
| 14 | +Legacy API | |
| 15 | +========== | |
| 16 | + | |
| 17 | +The functions listed in this section are deprecated. The GPIO descriptor based | |
| 18 | +API described above should be used in new code. | |
| 19 | + | |
| 20 | +.. kernel-doc:: drivers/gpio/gpiolib-legacy.c | |
| 21 | + :export: | |
| 22 | + | |
| 23 | +ACPI support | |
| 24 | +============ | |
| 25 | + | |
| 26 | +.. kernel-doc:: drivers/gpio/gpiolib-acpi.c | |
| 27 | + :export: | |
| 28 | + | |
| 29 | +Device tree support | |
| 30 | +=================== | |
| 31 | + | |
| 32 | +.. kernel-doc:: drivers/gpio/gpiolib-of.c | |
| 33 | + :export: | |
| 34 | + | |
| 35 | +Device-managed API | |
| 36 | +================== | |
| 37 | + | |
| 38 | +.. kernel-doc:: drivers/gpio/devres.c | |
| 39 | + :export: | |
| 40 | + | |
| 41 | +sysfs helpers | |
| 42 | +============= | |
| 43 | + | |
| 44 | +.. kernel-doc:: drivers/gpio/gpiolib-sysfs.c | |
| 45 | + :export: | |
| @@ -44,6 +44,7 @@ available subsections can be seen below. · 43 unmodified lines | ||
| 44 | 44 | uio-howto |
| 45 | 45 | firmware/index |
| 46 | 46 | pinctl |
| 47 | + gpio | |
| 47 | 48 | misc_devices |
| 48 | 49 | |
| 49 | 50 | .. only:: subproject and html |
| @@ -47,4 +47,3 @@ used by one consumer at a time. · 46 unmodified lines | ||
| 47 | 47 | |
| 48 | 48 | .. kernel-doc:: drivers/pwm/core.c |
| 49 | 49 | :export: |
| 50 | − | |
| @@ -516,7 +516,7 @@ mirrored table is performed. · 515 unmodified lines | ||
| 516 | 516 | |
| 517 | 517 | The most important field in the nand_bbt_descr structure is the |
| 518 | 518 | options field. The options define most of the table properties. Use the |
| 519 | −predefined constants from nand.h to define the options. | |
| 519 | +predefined constants from rawnand.h to define the options. | |
| 520 | 520 | |
| 521 | 521 | - Number of bits per block |
| 522 | 522 | |
| @@ -843,7 +843,7 @@ Chip option constants · 320 unmodified lines | ||
| 843 | 843 | Constants for chip id table |
| 844 | 844 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 845 | 845 | |
| 846 | −These constants are defined in nand.h. They are OR-ed together to | |
| 846 | +These constants are defined in rawnand.h. They are OR-ed together to | |
| 847 | 847 | describe the chip functionality:: |
| 848 | 848 | |
| 849 | 849 | /* Buswitdh is 16 bit */ |
| @@ -865,7 +865,7 @@ describe the chip functionality:: · 15 unmodified lines | ||
| 865 | 865 | Constants for runtime options |
| 866 | 866 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 867 | 867 | |
| 868 | −These constants are defined in nand.h. They are OR-ed together to | |
| 868 | +These constants are defined in rawnand.h. They are OR-ed together to | |
| 869 | 869 | describe the functionality:: |
| 870 | 870 | |
| 871 | 871 | /* The hw ecc generator provides a syndrome instead a ecc value on read |
| @@ -956,7 +956,7 @@ developer. Each struct member has a short description which is marked · 84 unmodified lines | ||
| 956 | 956 | with an [XXX] identifier. See the chapter "Documentation hints" for an |
| 957 | 957 | explanation. |
| 958 | 958 | |
| 959 | −.. kernel-doc:: include/linux/mtd/nand.h | |
| 959 | +.. kernel-doc:: include/linux/mtd/rawnand.h | |
| 960 | 960 | :internal: |
| 961 | 961 | |
| 962 | 962 | Public Functions Provided |
| @@ -675,7 +675,7 @@ sub-domain of the parent domain. · 674 unmodified lines | ||
| 675 | 675 | |
| 676 | 676 | Support for power domains is provided through the :c:member:`pm_domain` field of |
| 677 | 677 | |struct device|. This field is a pointer to an object of type |
| 678 | −|struct dev_pm_domain|, defined in :file:`include/linux/pm.h``, providing a set | |
| 678 | +|struct dev_pm_domain|, defined in :file:`include/linux/pm.h`, providing a set | |
| 679 | 679 | of power management callbacks analogous to the subsystem-level and device driver |
| 680 | 680 | callbacks that are executed for the given device during all power transitions, |
| 681 | 681 | instead of the respective subsystem-level callbacks. Specifically, if a |
| @@ -75,7 +75,7 @@ The channel-measurement facility provides a means to collect measurement · 74 unmodified lines | ||
| 75 | 75 | data which is made available by the channel subsystem for each channel |
| 76 | 76 | attached device. |
| 77 | 77 | |
| 78 | −.. kernel-doc:: arch/s390/include/asm/cmb.h | |
| 78 | +.. kernel-doc:: arch/s390/include/uapi/asm/cmb.h | |
| 79 | 79 | :internal: |
| 80 | 80 | |
| 81 | 81 | .. kernel-doc:: drivers/s390/cio/cmf.c |
| @@ -224,14 +224,6 @@ mid to lowlevel SCSI driver interface · 223 unmodified lines | ||
| 224 | 224 | .. kernel-doc:: drivers/scsi/hosts.c |
| 225 | 225 | :export: |
| 226 | 226 | |
| 227 | −drivers/scsi/constants.c | |
| 228 | −~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 229 | − | |
| 230 | −mid to lowlevel SCSI driver interface | |
| 231 | − | |
| 232 | −.. kernel-doc:: drivers/scsi/constants.c | |
| 233 | − :export: | |
| 234 | − | |
| 235 | 227 | Transport classes |
| 236 | 228 | ----------------- |
| 237 | 229 | |
| @@ -312,6 +312,7 @@ IRQ · 311 unmodified lines | ||
| 312 | 312 | devm_irq_alloc_descs_from() |
| 313 | 313 | devm_irq_alloc_generic_chip() |
| 314 | 314 | devm_irq_setup_generic_chip() |
| 315 | + devm_irq_sim_init() | |
| 315 | 316 | |
| 316 | 317 | LED |
| 317 | 318 | devm_led_classdev_register() |
| @@ -0,0 +1,149 @@ | ||
| 1 | +The errseq_t datatype | |
| 2 | +===================== | |
| 3 | +An errseq_t is a way of recording errors in one place, and allowing any | |
| 4 | +number of "subscribers" to tell whether it has changed since a previous | |
| 5 | +point where it was sampled. | |
| 6 | + | |
| 7 | +The initial use case for this is tracking errors for file | |
| 8 | +synchronization syscalls (fsync, fdatasync, msync and sync_file_range), | |
| 9 | +but it may be usable in other situations. | |
| 10 | + | |
| 11 | +It's implemented as an unsigned 32-bit value. The low order bits are | |
| 12 | +designated to hold an error code (between 1 and MAX_ERRNO). The upper bits | |
| 13 | +are used as a counter. This is done with atomics instead of locking so that | |
| 14 | +these functions can be called from any context. | |
| 15 | + | |
| 16 | +Note that there is a risk of collisions if new errors are being recorded | |
| 17 | +frequently, since we have so few bits to use as a counter. | |
| 18 | + | |
| 19 | +To mitigate this, the bit between the error value and counter is used as | |
| 20 | +a flag to tell whether the value has been sampled since a new value was | |
| 21 | +recorded. That allows us to avoid bumping the counter if no one has | |
| 22 | +sampled it since the last time an error was recorded. | |
| 23 | + | |
| 24 | +Thus we end up with a value that looks something like this:: | |
| 25 | + | |
| 26 | + bit: 31..13 12 11..0 | |
| 27 | + +-----------------+----+----------------+ | |
| 28 | + | counter | SF | errno | | |
| 29 | + +-----------------+----+----------------+ | |
| 30 | + | |
| 31 | +The general idea is for "watchers" to sample an errseq_t value and keep | |
| 32 | +it as a running cursor. That value can later be used to tell whether | |
| 33 | +any new errors have occurred since that sampling was done, and atomically | |
| 34 | +record the state at the time that it was checked. This allows us to | |
| 35 | +record errors in one place, and then have a number of "watchers" that | |
| 36 | +can tell whether the value has changed since they last checked it. | |
| 37 | + | |
| 38 | +A new errseq_t should always be zeroed out. An errseq_t value of all zeroes | |
| 39 | +is the special (but common) case where there has never been an error. An all | |
| 40 | +zero value thus serves as the "epoch" if one wishes to know whether there | |
| 41 | +has ever been an error set since it was first initialized. | |
| 42 | + | |
| 43 | +API usage | |
| 44 | +========= | |
| 45 | +Let me tell you a story about a worker drone. Now, he's a good worker | |
| 46 | +overall, but the company is a little...management heavy. He has to | |
| 47 | +report to 77 supervisors today, and tomorrow the "big boss" is coming in | |
| 48 | +from out of town and he's sure to test the poor fellow too. | |
| 49 | + | |
| 50 | +They're all handing him work to do -- so much he can't keep track of who | |
| 51 | +handed him what, but that's not really a big problem. The supervisors | |
| 52 | +just want to know when he's finished all of the work they've handed him so | |
| 53 | +far and whether he made any mistakes since they last asked. | |
| 54 | + | |
| 55 | +He might have made the mistake on work they didn't actually hand him, | |
| 56 | +but he can't keep track of things at that level of detail, all he can | |
| 57 | +remember is the most recent mistake that he made. | |
| 58 | + | |
| 59 | +Here's our worker_drone representation:: | |
| 60 | + | |
| 61 | + struct worker_drone { | |
| 62 | + errseq_t wd_err; /* for recording errors */ | |
| 63 | + }; | |
| 64 | + | |
| 65 | +Every day, the worker_drone starts out with a blank slate:: | |
| 66 | + | |
| 67 | + struct worker_drone wd; | |
| 68 | + | |
| 69 | + wd.wd_err = (errseq_t)0; | |
| 70 | + | |
| 71 | +The supervisors come in and get an initial read for the day. They | |
| 72 | +don't care about anything that happened before their watch begins:: | |
| 73 | + | |
| 74 | + struct supervisor { | |
| 75 | + errseq_t s_wd_err; /* private "cursor" for wd_err */ | |
| 76 | + spinlock_t s_wd_err_lock; /* protects s_wd_err */ | |
| 77 | + } | |
| 78 | + | |
| 79 | + struct supervisor su; | |
| 80 | + | |
| 81 | + su.s_wd_err = errseq_sample(&wd.wd_err); | |
| 82 | + spin_lock_init(&su.s_wd_err_lock); | |
| 83 | + | |
| 84 | +Now they start handing him tasks to do. Every few minutes they ask him to | |
| 85 | +finish up all of the work they've handed him so far. Then they ask him | |
| 86 | +whether he made any mistakes on any of it:: | |
| 87 | + | |
| 88 | + spin_lock(&su.su_wd_err_lock); | |
| 89 | + err = errseq_check_and_advance(&wd.wd_err, &su.s_wd_err); | |
| 90 | + spin_unlock(&su.su_wd_err_lock); | |
| 91 | + | |
| 92 | +Up to this point, that just keeps returning 0. | |
| 93 | + | |
| 94 | +Now, the owners of this company are quite miserly and have given him | |
| 95 | +substandard equipment with which to do his job. Occasionally it | |
| 96 | +glitches and he makes a mistake. He sighs a heavy sigh, and marks it | |
| 97 | +down:: | |
| 98 | + | |
| 99 | + errseq_set(&wd.wd_err, -EIO); | |
| 100 | + | |
| 101 | +...and then gets back to work. The supervisors eventually poll again | |
| 102 | +and they each get the error when they next check. Subsequent calls will | |
| 103 | +return 0, until another error is recorded, at which point it's reported | |
| 104 | +to each of them once. | |
| 105 | + | |
| 106 | +Note that the supervisors can't tell how many mistakes he made, only | |
| 107 | +whether one was made since they last checked, and the latest value | |
| 108 | +recorded. | |
| 109 | + | |
| 110 | +Occasionally the big boss comes in for a spot check and asks the worker | |
| 111 | +to do a one-off job for him. He's not really watching the worker | |
| 112 | +full-time like the supervisors, but he does need to know whether a | |
| 113 | +mistake occurred while his job was processing. | |
| 114 | + | |
| 115 | +He can just sample the current errseq_t in the worker, and then use that | |
| 116 | +to tell whether an error has occurred later:: | |
| 117 | + | |
| 118 | + errseq_t since = errseq_sample(&wd.wd_err); | |
| 119 | + /* submit some work and wait for it to complete */ | |
| 120 | + err = errseq_check(&wd.wd_err, since); | |
| 121 | + | |
| 122 | +Since he's just going to discard "since" after that point, he doesn't | |
| 123 | +need to advance it here. He also doesn't need any locking since it's | |
| 124 | +not usable by anyone else. | |
| 125 | + | |
| 126 | +Serializing errseq_t cursor updates | |
| 127 | +=================================== | |
| 128 | +Note that the errseq_t API does not protect the errseq_t cursor during a | |
| 129 | +check_and_advance_operation. Only the canonical error code is handled | |
| 130 | +atomically. In a situation where more than one task might be using the | |
| 131 | +same errseq_t cursor at the same time, it's important to serialize | |
| 132 | +updates to that cursor. | |
| 133 | + | |
| 134 | +If that's not done, then it's possible for the cursor to go backward | |
| 135 | +in which case the same error could be reported more than once. | |
| 136 | + | |
| 137 | +Because of this, it's often advantageous to first do an errseq_check to | |
| 138 | +see if anything has changed, and only later do an | |
| 139 | +errseq_check_and_advance after taking the lock. e.g.:: | |
| 140 | + | |
| 141 | + if (errseq_check(&wd.wd_err, READ_ONCE(su.s_wd_err)) { | |
| 142 | + /* su.s_wd_err is protected by s_wd_err_lock */ | |
| 143 | + spin_lock(&su.s_wd_err_lock); | |
| 144 | + err = errseq_check_and_advance(&wd.wd_err, &su.s_wd_err); | |
| 145 | + spin_unlock(&su.s_wd_err_lock); | |
| 146 | + } | |
| 147 | + | |
| 148 | +That avoids the spinlock in the common case where nothing has changed | |
| 149 | +since the last time it was checked. | |
| @@ -27,5 +27,11 @@ You have to add the following kernel parameters in your elilo.conf: · 26 unmodified lines | ||
| 27 | 27 | Macbook Pro 17", iMac 20" : |
| 28 | 28 | video=efifb:i20 |
| 29 | 29 | |
| 30 | +Accepted options: | |
| 31 | + | |
| 32 | +nowc Don't map the framebuffer write combined. This can be used | |
| 33 | + to workaround side-effects and slowdowns on other CPU cores | |
| 34 | + when large amounts of console data are written. | |
| 35 | + | |
| 30 | 36 | -- |
| 31 | 37 | Edgar Hucek <gimli@dark-green.com> |
| @@ -148,6 +148,13 @@ C. Boot options · 147 unmodified lines | ||
| 148 | 148 | Actually, the underlying fb driver is totally ignorant of console |
| 149 | 149 | rotation. |
| 150 | 150 | |
| 151 | +5. fbcon=margin:<color> | |
| 152 | + | |
| 153 | + This option specifies the color of the margins. The margins are the | |
| 154 | + leftover area at the right and the bottom of the screen that are not | |
| 155 | + used by text. By default, this area will be black. The 'color' value | |
| 156 | + is an integer number that depends on the framebuffer driver being used. | |
| 157 | + | |
| 151 | 158 | C. Attaching, Detaching and Unloading |
| 152 | 159 | |
| 153 | 160 | Before going on how to attach, detach and unload the framebuffer console, an |
| @@ -25,7 +25,7 @@ · 24 unmodified lines | ||
| 25 | 25 | | mn10300: | ok | |
| 26 | 26 | | nios2: | ok | |
| 27 | 27 | | openrisc: | ok | |
| 28 | − | parisc: | TODO | | |
| 28 | + | parisc: | ok | | |
| 29 | 29 | | powerpc: | ok | |
| 30 | 30 | | s390: | ok | |
| 31 | 31 | | score: | TODO | |
| @@ -22,7 +22,7 @@ prototypes: · 21 unmodified lines | ||
| 22 | 22 | struct vfsmount *(*d_automount)(struct path *path); |
| 23 | 23 | int (*d_manage)(const struct path *, bool); |
| 24 | 24 | struct dentry *(*d_real)(struct dentry *, const struct inode *, |
| 25 | − unsigned int); | |
| 25 | + unsigned int, unsigned int); | |
| 26 | 26 | |
| 27 | 27 | locking rules: |
| 28 | 28 | rename_lock ->d_lock may block rcu-walk |
| @@ -151,8 +151,6 @@ To define an object, a structure of the following type should be filled out: · 150 unmodified lines | ||
| 151 | 151 | void (*mark_pages_cached)(void *cookie_netfs_data, |
| 152 | 152 | struct address_space *mapping, |
| 153 | 153 | struct pagevec *cached_pvec); |
| 154 | − | |
| 155 | − void (*now_uncached)(void *cookie_netfs_data); | |
| 156 | 154 | }; |
| 157 | 155 | |
| 158 | 156 | This has the following fields: |
| @@ -41,6 +41,11 @@ Igor Mammedov (DFS support) · 40 unmodified lines | ||
| 41 | 41 | Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code) |
| 42 | 42 | Scott Lovenberg |
| 43 | 43 | Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features) |
| 44 | +Aurelien Aptel (for DFS SMB3 work and some key bug fixes) | |
| 45 | +Ronnie Sahlberg (for SMB3 xattr work and bug fixes) | |
| 46 | +Shirish Pargaonkar (for many ACL patches over the years) | |
| 47 | +Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security) | |
| 48 | + | |
| 44 | 49 | |
| 45 | 50 | Test case and Bug Report contributors |
| 46 | 51 | ------------------------------------- |
| @@ -1,10 +1,14 @@ | ||
| 1 | −The CIFS VFS support for Linux supports many advanced network filesystem | |
| 2 | −features such as hierarchical dfs like namespace, hardlinks, locking and more. | |
| 1 | +This module supports the SMB3 family of advanced network protocols (as well | |
| 2 | +as older dialects, originally called "CIFS" or SMB1). | |
| 3 | + | |
| 4 | +The CIFS VFS module for Linux supports many advanced network filesystem | |
| 5 | +features such as hierarchical DFS like namespace, hardlinks, locking and more. | |
| 3 | 6 | It was designed to comply with the SNIA CIFS Technical Reference (which |
| 4 | 7 | supersedes the 1992 X/Open SMB Standard) as well as to perform best practice |
| 5 | 8 | practical interoperability with Windows 2000, Windows XP, Samba and equivalent |
| 6 | 9 | servers. This code was developed in participation with the Protocol Freedom |
| 7 | −Information Foundation. | |
| 10 | +Information Foundation. CIFS and now SMB3 has now become a defacto | |
| 11 | +standard for interoperating between Macs and Windows and major NAS appliances. | |
| 8 | 12 | |
| 9 | 13 | Please see |
| 10 | 14 | http://protocolfreedom.org/ and |
| @@ -15,30 +19,11 @@ for more details. · 4 unmodified lines | ||
| 15 | 19 | For questions or bug reports please contact: |
| 16 | 20 | sfrench@samba.org (sfrench@us.ibm.com) |
| 17 | 21 | |
| 22 | +See the project page at: https://wiki.samba.org/index.php/LinuxCIFS_utils | |
| 23 | + | |
| 18 | 24 | Build instructions: |
| 19 | 25 | ================== |
| 20 | −For Linux 2.4: | |
| 21 | −1) Get the kernel source (e.g.from http://www.kernel.org) | |
| 22 | −and download the cifs vfs source (see the project page | |
| 23 | −at http://us1.samba.org/samba/Linux_CIFS_client.html) | |
| 24 | −and change directory into the top of the kernel directory | |
| 25 | −then patch the kernel (e.g. "patch -p1 < cifs_24.patch") | |
| 26 | −to add the cifs vfs to your kernel configure options if | |
| 27 | −it has not already been added (e.g. current SuSE and UL | |
| 28 | −users do not need to apply the cifs_24.patch since the cifs vfs is | |
| 29 | −already in the kernel configure menu) and then | |
| 30 | −mkdir linux/fs/cifs and then copy the current cifs vfs files from | |
| 31 | −the cifs download to your kernel build directory e.g. | |
| 32 | − | |
| 33 | − cp <cifs_download_dir>/fs/cifs/* to <kernel_download_dir>/fs/cifs | |
| 34 | − | |
| 35 | −2) make menuconfig (or make xconfig) | |
| 36 | −3) select cifs from within the network filesystem choices | |
| 37 | −4) save and exit | |
| 38 | −5) make dep | |
| 39 | −6) make modules (or "make" if CIFS VFS not to be built as a module) | |
| 40 | − | |
| 41 | −For Linux 2.6: | |
| 26 | +For Linux: | |
| 42 | 27 | 1) Download the kernel (e.g. from http://www.kernel.org) |
| 43 | 28 | and change directory into the top of the kernel directory tree |
| 44 | 29 | (e.g. /usr/src/linux-2.5.73) |
| @@ -61,16 +46,13 @@ would simply type "make install"). · 16 unmodified lines | ||
| 61 | 46 | If you do not have the utility mount.cifs (in the Samba 3.0 source tree and on |
| 62 | 47 | the CIFS VFS web site) copy it to the same directory in which mount.smbfs and |
| 63 | 48 | similar files reside (usually /sbin). Although the helper software is not |
| 64 | −required, mount.cifs is recommended. Eventually the Samba 3.0 utility program | |
| 65 | −"net" may also be helpful since it may someday provide easier mount syntax for | |
| 66 | −users who are used to Windows e.g. | |
| 67 | − net use <mount point> <UNC name or cifs URL> | |
| 49 | +required, mount.cifs is recommended. Most distros include a "cifs-utils" | |
| 50 | +package that includes this utility so it is recommended to install this. | |
| 51 | + | |
| 68 | 52 | Note that running the Winbind pam/nss module (logon service) on all of your |
| 69 | 53 | Linux clients is useful in mapping Uids and Gids consistently across the |
| 70 | 54 | domain to the proper network user. The mount.cifs mount helper can be |
| 71 | −trivially built from Samba 3.0 or later source e.g. by executing: | |
| 72 | − | |
| 73 | − gcc samba/source/client/mount.cifs.c -o mount.cifs | |
| 55 | +found at cifs-utils.git on git.samba.org | |
| 74 | 56 | |
| 75 | 57 | If cifs is built as a module, then the size and number of network buffers |
| 76 | 58 | and maximum number of simultaneous requests to one server can be configured. |
| @@ -79,6 +61,18 @@ Changing these from their defaults is not recommended. By executing modinfo · 2 unmodified lines | ||
| 79 | 61 | on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made |
| 80 | 62 | at module initialization time (by running insmod cifs.ko) can be seen. |
| 81 | 63 | |
| 64 | +Recommendations | |
| 65 | +=============== | |
| 66 | +To improve security the SMB2.1 dialect or later (usually will get SMB3) is now | |
| 67 | +the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0" | |
| 68 | +on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is | |
| 69 | +much older and less secure than the default dialect SMB3 which includes | |
| 70 | +many advanced security features such as downgrade attack detection | |
| 71 | +and encrypted shares and stronger signing and authentication algorithms. | |
| 72 | +There are additional mount options that may be helpful for SMB3 to get | |
| 73 | +improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1): | |
| 74 | + "mfsymlinks" and "cifsacl" and "idsfromsid" | |
| 75 | + | |
| 82 | 76 | Allowing User Mounts |
| 83 | 77 | ==================== |
| 84 | 78 | To permit users to mount and unmount over directories they own is possible |
| @@ -98,9 +92,7 @@ and execution of suid programs on the remote target would be enabled · 13 unmodified lines | ||
| 98 | 92 | by default. This can be changed, as with nfs and other filesystems, |
| 99 | 93 | by simply specifying "nosuid" among the mount options. For user mounts |
| 100 | 94 | though to be able to pass the suid flag to mount requires rebuilding |
| 101 | −mount.cifs with the following flag: | |
| 102 | − | |
| 103 | − gcc samba/source/client/mount.cifs.c -DCIFS_ALLOW_USR_SUID -o mount.cifs | |
| 95 | +mount.cifs with the following flag: CIFS_ALLOW_USR_SUID | |
| 104 | 96 | |
| 105 | 97 | There is a corresponding manual page for cifs mounting in the Samba 3.0 and |
| 106 | 98 | later source tree in docs/manpages/mount.cifs.8 |
| @@ -189,18 +181,18 @@ applications running on the same server as Samba. · 82 unmodified lines | ||
| 189 | 181 | Use instructions: |
| 190 | 182 | ================ |
| 191 | 183 | Once the CIFS VFS support is built into the kernel or installed as a module |
| 192 | −(cifs.o), you can use mount syntax like the following to access Samba or Windows | |
| 193 | −servers: | |
| 184 | +(cifs.ko), you can use mount syntax like the following to access Samba or | |
| 185 | +Mac or Windows servers: | |
| 194 | 186 | |
| 195 | − mount -t cifs //9.53.216.11/e$ /mnt -o user=myname,pass=mypassword | |
| 187 | + mount -t cifs //9.53.216.11/e$ /mnt -o username=myname,password=mypassword | |
| 196 | 188 | |
| 197 | 189 | Before -o the option -v may be specified to make the mount.cifs |
| 198 | 190 | mount helper display the mount steps more verbosely. |
| 199 | 191 | After -o the following commonly used cifs vfs specific options |
| 200 | 192 | are supported: |
| 201 | 193 | |
| 202 | − user=<username> | |
| 203 | − pass=<password> | |
| 194 | + username=<username> | |
| 195 | + password=<password> | |
| 204 | 196 | domain=<domain name> |
| 205 | 197 | |
| 206 | 198 | Other cifs mount options are described below. Use of TCP names (in addition to |
| @@ -246,13 +238,16 @@ the Server's registry. Samba starting with version 3.10 will allow such · 39 unmodified lines | ||
| 246 | 238 | filenames (ie those which contain valid Linux characters, which normally |
| 247 | 239 | would be forbidden for Windows/CIFS semantics) as long as the server is |
| 248 | 240 | configured for Unix Extensions (and the client has not disabled |
| 249 | −/proc/fs/cifs/LinuxExtensionsEnabled). | |
| 250 | − | |
| 241 | +/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option | |
| 242 | +"mapposix" can be used on CIFS (vers=1.0) to force the mapping of | |
| 243 | +illegal Windows/NTFS/SMB characters to a remap range (this mount parm | |
| 244 | +is the default for SMB3). This remap ("mapposix") range is also | |
| 245 | +compatible with Mac (and "Services for Mac" on some older Windows). | |
| 251 | 246 | |
| 252 | 247 | CIFS VFS Mount Options |
| 253 | 248 | ====================== |
| 254 | 249 | A partial list of the supported mount options follows: |
| 255 | − user The user name to use when trying to establish | |
| 250 | + username The user name to use when trying to establish | |
| 256 | 251 | the CIFS session. |
| 257 | 252 | password The user password. If the mount helper is |
| 258 | 253 | installed, the user will be prompted for password |
| @@ -1,4 +1,4 @@ | ||
| 1 | −Version 2.03 August 1, 2014 | |
| 1 | +Version 2.04 September 13, 2017 | |
| 2 | 2 | |
| 3 | 3 | A Partial List of Missing Features |
| 4 | 4 | ================================== |
| @@ -8,73 +8,69 @@ for visible, important contributions to this module. Here · 3 unmodified lines | ||
| 8 | 8 | is a partial list of the known problems and missing features: |
| 9 | 9 | |
| 10 | 10 | a) SMB3 (and SMB3.02) missing optional features: |
| 11 | − - RDMA | |
| 11 | + - RDMA (started) | |
| 12 | 12 | - multichannel (started) |
| 13 | 13 | - directory leases (improved metadata caching) |
| 14 | 14 | - T10 copy offload (copy chunk is only mechanism supported) |
| 15 | − - encrypted shares | |
| 16 | 15 | |
| 17 | 16 | b) improved sparse file support |
| 18 | 17 | |
| 19 | 18 | c) Directory entry caching relies on a 1 second timer, rather than |
| 20 | −using FindNotify or equivalent. - (started) | |
| 19 | +using Directory Leases | |
| 21 | 20 | |
| 22 | 21 | d) quota support (needs minor kernel change since quota calls |
| 23 | 22 | to make it to network filesystems or deviceless filesystems) |
| 24 | 23 | |
| 25 | −e) improve support for very old servers (OS/2 and Win9x for example) | |
| 26 | −Including support for changing the time remotely (utimes command). | |
| 24 | +e) Better optimize open to reduce redundant opens (using reference | |
| 25 | +counts more) and to improve use of compounding in SMB3 to reduce | |
| 26 | +number of roundtrips. | |
| 27 | 27 | |
| 28 | −f) hook lower into the sockets api (as NFS/SunRPC does) to avoid the | |
| 29 | −extra copy in/out of the socket buffers in some cases. | |
| 30 | − | |
| 31 | −g) Better optimize open (and pathbased setfilesize) to reduce the | |
| 32 | −oplock breaks coming from windows srv. Piggyback identical file | |
| 33 | −opens on top of each other by incrementing reference count rather | |
| 34 | −than resending (helps reduce server resource utilization and avoid | |
| 35 | −spurious oplock breaks). | |
| 36 | − | |
| 37 | −h) Add support for storing symlink info to Windows servers | |
| 38 | −in the Extended Attribute format their SFU clients would recognize. | |
| 39 | − | |
| 40 | −i) Finish inotify support so kde and gnome file list windows | |
| 28 | +f) Finish inotify support so kde and gnome file list windows | |
| 41 | 29 | will autorefresh (partially complete by Asser). Needs minor kernel |
| 42 | 30 | vfs change to support removing D_NOTIFY on a file. |
| 43 | 31 | |
| 44 | −j) Add GUI tool to configure /proc/fs/cifs settings and for display of | |
| 32 | +g) Add GUI tool to configure /proc/fs/cifs settings and for display of | |
| 45 | 33 | the CIFS statistics (started) |
| 46 | 34 | |
| 47 | −k) implement support for security and trusted categories of xattrs | |
| 35 | +h) implement support for security and trusted categories of xattrs | |
| 48 | 36 | (requires minor protocol extension) to enable better support for SELINUX |
| 49 | 37 | |
| 50 | −l) Implement O_DIRECT flag on open (already supported on mount) | |
| 38 | +i) Implement O_DIRECT flag on open (already supported on mount) | |
| 51 | 39 | |
| 52 | −m) Create UID mapping facility so server UIDs can be mapped on a per | |
| 40 | +j) Create UID mapping facility so server UIDs can be mapped on a per | |
| 53 | 41 | mount or a per server basis to client UIDs or nobody if no mapping |
| 54 | −exists. This is helpful when Unix extensions are negotiated to | |
| 55 | −allow better permission checking when UIDs differ on the server | |
| 56 | −and client. Add new protocol request to the CIFS protocol | |
| 57 | −standard for asking the server for the corresponding name of a | |
| 58 | −particular uid. | |
| 42 | +exists. Also better integration with winbind for resolving SID owners | |
| 43 | + | |
| 44 | +k) Add tools to take advantage of more smb3 specific ioctls and features | |
| 45 | + | |
| 46 | +l) encrypted file support | |
| 47 | + | |
| 48 | +m) improved stats gathering, tools (perhaps integration with nfsometer?) | |
| 59 | 49 | |
| 60 | −n) DOS attrs - returned as pseudo-xattr in Samba format (check VFAT and NTFS for this too) | |
| 50 | +n) allow setting more NTFS/SMB3 file attributes remotely (currently limited to compressed | |
| 51 | +file attribute via chflags) and improve user space tools for managing and | |
| 52 | +viewing them. | |
| 61 | 53 | |
| 62 | −o) mount check for unmatched uids | |
| 54 | +o) mount helper GUI (to simplify the various configuration options on mount) | |
| 63 | 55 | |
| 64 | −p) Add support for new vfs entry point for fallocate | |
| 56 | +p) autonegotiation of dialects (offering more than one dialect ie SMB3.02, | |
| 57 | +SMB3, SMB2.1 not just SMB3). | |
| 65 | 58 | |
| 66 | −q) Add tools to take advantage of cifs/smb3 specific ioctls and features | |
| 67 | −such as "CopyChunk" (fast server side file copy) | |
| 59 | +q) Allow mount.cifs to be more verbose in reporting errors with dialect | |
| 60 | +or unsupported feature errors. | |
| 68 | 61 | |
| 69 | −r) encrypted file support | |
| 62 | +r) updating cifs documentation, and user guid. | |
| 70 | 63 | |
| 71 | −s) improved stats gathering, tools (perhaps integration with nfsometer?) | |
| 64 | +s) Addressing bugs found by running a broader set of xfstests in standard | |
| 65 | +file system xfstest suite. | |
| 72 | 66 | |
| 73 | −t) allow setting more NTFS/SMB3 file attributes remotely (currently limited to compressed | |
| 74 | −file attribute via chflags) | |
| 67 | +t) split cifs and smb3 support into separate modules so legacy (and less | |
| 68 | +secure) CIFS dialect can be disabled in environments that don't need it | |
| 69 | +and simplify the code. | |
| 75 | 70 | |
| 76 | −u) mount helper GUI (to simplify the various configuration options on mount) | |
| 71 | +u) Finish up SMB3.1.1 dialect support | |
| 77 | 72 | |
| 73 | +v) POSIX Extensions for SMB3.1.1 | |
| 78 | 74 | |
| 79 | 75 | KNOWN BUGS |
| 80 | 76 | ==================================== |
| @@ -1,24 +1,28 @@ | ||
| 1 | − This is the client VFS module for the Common Internet File System | |
| 2 | − (CIFS) protocol which is the successor to the Server Message Block | |
| 1 | + This is the client VFS module for the SMB3 NAS protocol as well | |
| 2 | + older dialects such as the Common Internet File System (CIFS) | |
| 3 | + protocol which was the successor to the Server Message Block | |
| 3 | 4 | (SMB) protocol, the native file sharing mechanism for most early |
| 4 | 5 | PC operating systems. New and improved versions of CIFS are now |
| 5 | 6 | called SMB2 and SMB3. These dialects are also supported by the |
| 6 | 7 | CIFS VFS module. CIFS is fully supported by network |
| 7 | − file servers such as Windows 2000, 2003, 2008 and 2012 | |
| 8 | + file servers such as Windows 2000, 2003, 2008, 2012 and 2016 | |
| 8 | 9 | as well by Samba (which provides excellent CIFS |
| 9 | − server support for Linux and many other operating systems), so | |
| 10 | + server support for Linux and many other operating systems), Apple | |
| 11 | + systems, as well as most Network Attached Storage vendors, so | |
| 10 | 12 | this network filesystem client can mount to a wide variety of |
| 11 | 13 | servers. |
| 12 | 14 | |
| 13 | 15 | The intent of this module is to provide the most advanced network |
| 14 | − file system function for CIFS compliant servers, including better | |
| 15 | − POSIX compliance, secure per-user session establishment, high | |
| 16 | − performance safe distributed caching (oplock), optional packet | |
| 16 | + file system function for SMB3 compliant servers, including advanced | |
| 17 | + security features, excellent parallelized high performance i/o, better | |
| 18 | + POSIX compliance, secure per-user session establishment, encryption, | |
| 19 | + high performance safe distributed caching (leases/oplocks), optional packet | |
| 17 | 20 | signing, large files, Unicode support and other internationalization |
| 18 | 21 | improvements. Since both Samba server and this filesystem client support |
| 19 | − the CIFS Unix extensions, the combination can provide a reasonable | |
| 20 | − alternative to NFSv4 for fileserving in some Linux to Linux environments, | |
| 21 | − not just in Linux to Windows environments. | |
| 22 | + the CIFS Unix extensions (and in the future SMB3 POSIX extensions), | |
| 23 | + the combination can provide a reasonable alternative to other network and | |
| 24 | + cluster file systems for fileserving in some Linux to Linux environments, | |
| 25 | + not just in Linux to Windows (or Linux to Mac) environments. | |
| 22 | 26 | |
| 23 | 27 | This filesystem has an mount utility (mount.cifs) that can be obtained from |
| 24 | 28 | |
| @@ -63,9 +63,8 @@ Filesystem support consists of · 62 unmodified lines | ||
| 63 | 63 | - implementing an mmap file operation for DAX files which sets the |
| 64 | 64 | VM_MIXEDMAP and VM_HUGEPAGE flags on the VMA, and setting the vm_ops to |
| 65 | 65 | include handlers for fault, pmd_fault, page_mkwrite, pfn_mkwrite. These |
| 66 | − handlers should probably call dax_iomap_fault() (for fault and page_mkwrite | |
| 67 | − handlers), dax_iomap_pmd_fault(), dax_pfn_mkwrite() passing the appropriate | |
| 68 | − iomap operations. | |
| 66 | + handlers should probably call dax_iomap_fault() passing the appropriate | |
| 67 | + fault size and iomap operations. | |
| 69 | 68 | - calling iomap_zero_range() passing appropriate iomap operations instead of |
| 70 | 69 | block_truncate_page() for DAX files |
| 71 | 70 | - ensuring that there is sufficient locking between reads, writes, |
| @@ -164,6 +164,16 @@ io_bits=%u Set the bit size of write IO requests. It should be set · 163 unmodified lines | ||
| 164 | 164 | with "mode=lfs". |
| 165 | 165 | usrquota Enable plain user disk quota accounting. |
| 166 | 166 | grpquota Enable plain group disk quota accounting. |
| 167 | +prjquota Enable plain project quota accounting. | |
| 168 | +usrjquota=<file> Appoint specified file and type during mount, so that quota | |
| 169 | +grpjquota=<file> information can be properly updated during recovery flow, | |
| 170 | +prjjquota=<file> <quota file>: must be in root directory; | |
| 171 | +jqfmt=<quota type> <quota type>: [vfsold,vfsv0,vfsv1]. | |
| 172 | +offusrjquota Turn off user journelled quota. | |
| 173 | +offgrpjquota Turn off group journelled quota. | |
| 174 | +offprjjquota Turn off project journelled quota. | |
| 175 | +quota Enable plain user disk quota accounting. | |
| 176 | +noquota Disable all plain disk quota option. | |
| 167 | 177 | |
| 168 | 178 | ================================================================================ |
| 169 | 179 | DEBUGFS ENTRIES |
| @@ -209,6 +219,15 @@ Files in /sys/fs/f2fs/<devname> · 39 unmodified lines | ||
| 209 | 219 | gc_idle = 1 will select the Cost Benefit approach |
| 210 | 220 | & setting gc_idle = 2 will select the greedy approach. |
| 211 | 221 | |
| 222 | + gc_urgent This parameter controls triggering background GCs | |
| 223 | + urgently or not. Setting gc_urgent = 0 [default] | |
| 224 | + makes back to default behavior, while if it is set | |
| 225 | + to 1, background thread starts to do GC by given | |
| 226 | + gc_urgent_sleep_time interval. | |
| 227 | + | |
| 228 | + gc_urgent_sleep_time This parameter controls sleep time for gc_urgent. | |
| 229 | + 500 ms is set by default. See above gc_urgent. | |
| 230 | + | |
| 212 | 231 | reclaim_segments This parameter controls the number of prefree |
| 213 | 232 | segments to be reclaimed. If the number of prefree |
| 214 | 233 | segments is larger than the number of segments |
| @@ -45,14 +45,11 @@ upstream version of the kernel client. · 44 unmodified lines | ||
| 45 | 45 | BUILDING THE USERSPACE FILESYSTEM ON A SINGLE SERVER |
| 46 | 46 | ==================================================== |
| 47 | 47 | |
| 48 | −When Orangefs is upstream, "--with-kernel" shouldn't be needed, but | |
| 49 | −until then the path to where the kernel with the Orangefs kernel client | |
| 50 | −patch was built is needed to ensure that pvfs2-client-core (the bridge | |
| 51 | −between kernel space and user space) will build properly. You can omit | |
| 52 | −--prefix if you don't care that things are sprinkled around in | |
| 53 | −/usr/local. | |
| 48 | +You can omit --prefix if you don't care that things are sprinkled around in | |
| 49 | +/usr/local. As of version 2.9.6, Orangefs uses Berkeley DB by default, we | |
| 50 | +will probably be changing the default to lmdb soon. | |
| 54 | 51 | |
| 55 | −./configure --prefix=/opt/ofs --with-kernel=/path/to/orangefs/kernel | |
| 52 | +./configure --prefix=/opt/ofs --with-db-backend=lmdb | |
| 56 | 53 | |
| 57 | 54 | make |
| 58 | 55 | |
| @@ -82,9 +79,6 @@ prove things are working with: · 23 unmodified lines | ||
| 82 | 79 | |
| 83 | 80 | /opt/osf/bin/pvfs2-ls /mymountpoint |
| 84 | 81 | |
| 85 | −You might not want to enforce selinux, it doesn't seem to matter by | |
| 86 | −linux 3.11... | |
| 87 | − | |
| 88 | 82 | If stuff seems to be working, turn on the client core: |
| 89 | 83 | /opt/osf/sbin/pvfs2-client -p /opt/osf/sbin/pvfs2-client-core |
| 90 | 84 | |
| @@ -228,7 +228,7 @@ anything from oops to silent memory corruption. · 227 unmodified lines | ||
| 228 | 228 | --- |
| 229 | 229 | [mandatory] |
| 230 | 230 | |
| 231 | − FS_NOMOUNT is gone. If you use it - just set MS_NOUSER in flags | |
| 231 | + FS_NOMOUNT is gone. If you use it - just set SB_NOUSER in flags | |
| 232 | 232 | (see rootfs for one kind of solution and bdev/socket/pipe for another). |
| 233 | 233 | |
| 234 | 234 | --- |
| @@ -829,9 +829,7 @@ struct address_space_operations { · 828 unmodified lines | ||
| 829 | 829 | swap_activate: Called when swapon is used on a file to allocate |
| 830 | 830 | space if necessary and pin the block lookup information in |
| 831 | 831 | memory. A return value of zero indicates success, |
| 832 | − in which case this file can be used to back swapspace. The | |
| 833 | − swapspace operations will be proxied to this address space's | |
| 834 | − ->swap_{out,in} methods. | |
| 832 | + in which case this file can be used to back swapspace. | |
| 835 | 833 | |
| 836 | 834 | swap_deactivate: Called during swapoff on files where swap_activate |
| 837 | 835 | was successful. |
| @@ -990,7 +988,7 @@ struct dentry_operations { · 152 unmodified lines | ||
| 990 | 988 | struct vfsmount *(*d_automount)(struct path *); |
| 991 | 989 | int (*d_manage)(const struct path *, bool); |
| 992 | 990 | struct dentry *(*d_real)(struct dentry *, const struct inode *, |
| 993 | − unsigned int); | |
| 991 | + unsigned int, unsigned int); | |
| 994 | 992 | }; |
| 995 | 993 | |
| 996 | 994 | d_revalidate: called when the VFS needs to revalidate a dentry. This |
| @@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI: · 83 unmodified lines | ||
| 84 | 84 | NAND flash MTD subsystem and provides chip access and partition parsing like |
| 85 | 85 | any other NAND driving hardware. |
| 86 | 86 | |
| 87 | +- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive a PS/2 (IBM) serio | |
| 88 | + bus, data and clock line, by bit banging two GPIO lines. It will appear as | |
| 89 | + any other serio bus to the system and makes it possible to connect drivers | |
| 90 | + for e.g. keyboards and other PS/2 protocol based devices. | |
| 91 | + | |
| 87 | 92 | Apart from this there are special GPIO drivers in subsystems like MMC/SD to |
| 88 | 93 | read card detect and write protect GPIO lines, and in the TTY serial subsystem |
| 89 | 94 | to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The |
| @@ -459,7 +459,7 @@ pin controller? · 458 unmodified lines | ||
| 459 | 459 | |
| 460 | 460 | This is done by registering "ranges" of pins, which are essentially |
| 461 | 461 | cross-reference tables. These are described in |
| 462 | −Documentation/pinctrl.txt | |
| 462 | +Documentation/driver-api/pinctl.rst | |
| 463 | 463 | |
| 464 | 464 | While the pin allocation is totally managed by the pinctrl subsystem, |
| 465 | 465 | gpio (under gpiolib) is still maintained by gpio drivers. It may happen |
| @@ -201,6 +201,8 @@ drivers. · 200 unmodified lines | ||
| 201 | 201 | Open/Close, File Operations and IOCTLs |
| 202 | 202 | ====================================== |
| 203 | 203 | |
| 204 | +.. _drm_driver_fops: | |
| 205 | + | |
| 204 | 206 | File Operations |
| 205 | 207 | --------------- |
| 206 | 208 | |
| @@ -296,3 +296,12 @@ Auxiliary Modeset Helpers · 295 unmodified lines | ||
| 296 | 296 | |
| 297 | 297 | .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c |
| 298 | 298 | :export: |
| 299 | + | |
| 300 | +Framebuffer GEM Helper Reference | |
| 301 | +================================ | |
| 302 | + | |
| 303 | +.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c | |
| 304 | + :doc: overview | |
| 305 | + | |
| 306 | +.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c | |
| 307 | + :export: | |
| @@ -523,9 +523,6 @@ Color Management Properties · 522 unmodified lines | ||
| 523 | 523 | .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c |
| 524 | 524 | :doc: overview |
| 525 | 525 | |
| 526 | −.. kernel-doc:: include/drm/drm_color_mgmt.h | |
| 527 | − :internal: | |
| 528 | − | |
| 529 | 526 | .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c |
| 530 | 527 | :export: |
| 531 | 528 | |
| @@ -554,60 +551,8 @@ various modules/drivers. · 22 unmodified lines | ||
| 554 | 551 | Vertical Blanking |
| 555 | 552 | ================= |
| 556 | 553 | |
| 557 | −Vertical blanking plays a major role in graphics rendering. To achieve | |
| 558 | −tear-free display, users must synchronize page flips and/or rendering to | |
| 559 | −vertical blanking. The DRM API offers ioctls to perform page flips | |
| 560 | −synchronized to vertical blanking and wait for vertical blanking. | |
| 561 | − | |
| 562 | −The DRM core handles most of the vertical blanking management logic, | |
| 563 | −which involves filtering out spurious interrupts, keeping race-free | |
| 564 | −blanking counters, coping with counter wrap-around and resets and | |
| 565 | −keeping use counts. It relies on the driver to generate vertical | |
| 566 | −blanking interrupts and optionally provide a hardware vertical blanking | |
| 567 | −counter. Drivers must implement the following operations. | |
| 568 | − | |
| 569 | −- int (\*enable_vblank) (struct drm_device \*dev, int crtc); void | |
| 570 | − (\*disable_vblank) (struct drm_device \*dev, int crtc); | |
| 571 | − Enable or disable vertical blanking interrupts for the given CRTC. | |
| 572 | − | |
| 573 | −- u32 (\*get_vblank_counter) (struct drm_device \*dev, int crtc); | |
| 574 | − Retrieve the value of the vertical blanking counter for the given | |
| 575 | − CRTC. If the hardware maintains a vertical blanking counter its value | |
| 576 | − should be returned. Otherwise drivers can use the | |
| 577 | − :c:func:`drm_vblank_count()` helper function to handle this | |
| 578 | − operation. | |
| 579 | − | |
| 580 | −Drivers must initialize the vertical blanking handling core with a call | |
| 581 | −to :c:func:`drm_vblank_init()` in their load operation. | |
| 582 | − | |
| 583 | −Vertical blanking interrupts can be enabled by the DRM core or by | |
| 584 | −drivers themselves (for instance to handle page flipping operations). | |
| 585 | −The DRM core maintains a vertical blanking use count to ensure that the | |
| 586 | −interrupts are not disabled while a user still needs them. To increment | |
| 587 | −the use count, drivers call :c:func:`drm_vblank_get()`. Upon | |
| 588 | −return vertical blanking interrupts are guaranteed to be enabled. | |
| 589 | − | |
| 590 | −To decrement the use count drivers call | |
| 591 | −:c:func:`drm_vblank_put()`. Only when the use count drops to zero | |
| 592 | −will the DRM core disable the vertical blanking interrupts after a delay | |
| 593 | −by scheduling a timer. The delay is accessible through the | |
| 594 | −vblankoffdelay module parameter or the ``drm_vblank_offdelay`` global | |
| 595 | −variable and expressed in milliseconds. Its default value is 5000 ms. | |
| 596 | −Zero means never disable, and a negative value means disable | |
| 597 | −immediately. Drivers may override the behaviour by setting the | |
| 598 | −:c:type:`struct drm_device <drm_device>` | |
| 599 | −vblank_disable_immediate flag, which when set causes vblank interrupts | |
| 600 | −to be disabled immediately regardless of the drm_vblank_offdelay | |
| 601 | −value. The flag should only be set if there's a properly working | |
| 602 | −hardware vblank counter present. | |
| 603 | − | |
| 604 | −When a vertical blanking interrupt occurs drivers only need to call the | |
| 605 | −:c:func:`drm_handle_vblank()` function to account for the | |
| 606 | −interrupt. | |
| 607 | − | |
| 608 | −Resources allocated by :c:func:`drm_vblank_init()` must be freed | |
| 609 | −with a call to :c:func:`drm_vblank_cleanup()` in the driver unload | |
| 610 | −operation handler. | |
| 554 | +.. kernel-doc:: drivers/gpu/drm/drm_vblank.c | |
| 555 | + :doc: vblank handling | |
| 611 | 556 | |
| 612 | 557 | Vertical Blanking and Interrupt Handling Functions Reference |
| 613 | 558 | ------------------------------------------------------------ |
| @@ -191,7 +191,7 @@ acquired and release by :c:func:`calling drm_gem_object_get()` and · 190 unmodified lines | ||
| 191 | 191 | holding the lock. |
| 192 | 192 | |
| 193 | 193 | When the last reference to a GEM object is released the GEM core calls |
| 194 | −the :c:type:`struct drm_driver <drm_driver>` gem_free_object | |
| 194 | +the :c:type:`struct drm_driver <drm_driver>` gem_free_object_unlocked | |
| 195 | 195 | operation. That operation is mandatory for GEM-enabled drivers and must |
| 196 | 196 | free the GEM object and all associated resources. |
| 197 | 197 | |
| @@ -492,7 +492,7 @@ DRM Sync Objects · 294 unmodified lines | ||
| 492 | 492 | :doc: Overview |
| 493 | 493 | |
| 494 | 494 | .. kernel-doc:: include/drm/drm_syncobj.h |
| 495 | − :export: | |
| 495 | + :internal: | |
| 496 | 496 | |
| 497 | 497 | .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c |
| 498 | 498 | :export: |
| @@ -160,6 +160,8 @@ other hand, a driver requires shared state between clients which is · 159 unmodified lines | ||
| 160 | 160 | visible to user-space and accessible beyond open-file boundaries, they |
| 161 | 161 | cannot support render nodes. |
| 162 | 162 | |
| 163 | +.. _drm_driver_ioctl: | |
| 164 | + | |
| 163 | 165 | IOCTL Support on Device Nodes |
| 164 | 166 | ============================= |
| 165 | 167 | |
| @@ -417,6 +417,10 @@ integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl. · 416 unmodified lines | ||
| 417 | 417 | :functions: i915_perf_open_ioctl |
| 418 | 418 | .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c |
| 419 | 419 | :functions: i915_perf_release |
| 420 | +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c | |
| 421 | + :functions: i915_perf_add_config_ioctl | |
| 422 | +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c | |
| 423 | + :functions: i915_perf_remove_config_ioctl | |
| 420 | 424 | |
| 421 | 425 | i915 Perf Stream |
| 422 | 426 | ---------------- |
| @@ -477,4 +481,16 @@ specific details than found in the more high-level sections. · 54 unmodified lines | ||
| 477 | 481 | .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c |
| 478 | 482 | :internal: |
| 479 | 483 | |
| 480 | −.. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/drm/i915/i915_irq.c | |
| 484 | +Style | |
| 485 | +===== | |
| 486 | + | |
| 487 | +The drm/i915 driver codebase has some style rules in addition to (and, in some | |
| 488 | +cases, deviating from) the kernel coding style. | |
| 489 | + | |
| 490 | +Register macro definition style | |
| 491 | +------------------------------- | |
| 492 | + | |
| 493 | +The style guide for ``i915_reg.h``. | |
| 494 | + | |
| 495 | +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h | |
| 496 | + :doc: The i915 register macro definition style guide | |
| @@ -108,8 +108,8 @@ This would be especially useful for tinydrm: · 107 unmodified lines | ||
| 108 | 108 | crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in |
| 109 | 109 | __drm_atomic_helper_crtc_duplicate_state(). |
| 110 | 110 | |
| 111 | −- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_ | |
| 112 | − prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this | |
| 111 | +- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_ | |
| 112 | + prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this | |
| 113 | 113 | is a function useful to implement the fb->dirty function. |
| 114 | 114 | |
| 115 | 115 | - Create a new drm_fb_dirty function which does essentially what e.g. |
| @@ -18,6 +18,10 @@ enhancements. It can monitor up to 4 voltages, 16 temperatures and · 17 unmodified lines | ||
| 18 | 18 | 8 fans. It also contains an integrated watchdog which is currently |
| 19 | 19 | implemented in this driver. |
| 20 | 20 | |
| 21 | +To clear a temperature or fan alarm, execute the following command with the | |
| 22 | +correct path to the alarm file: | |
| 23 | + echo 0 >XXXX_alarm | |
| 24 | + | |
| 21 | 25 | Specification of the chip can be found here: |
| 22 | 26 | ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf |
| 23 | 27 | ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf |
| @@ -0,0 +1,54 @@ | ||
| 1 | +Kernel driver ibm-cffps | |
| 2 | +======================= | |
| 3 | + | |
| 4 | +Supported chips: | |
| 5 | + * IBM Common Form Factor power supply | |
| 6 | + | |
| 7 | +Author: Eddie James <eajames@us.ibm.com> | |
| 8 | + | |
| 9 | +Description | |
| 10 | +----------- | |
| 11 | + | |
| 12 | +This driver supports IBM Common Form Factor (CFF) power supplies. This driver | |
| 13 | +is a client to the core PMBus driver. | |
| 14 | + | |
| 15 | +Usage Notes | |
| 16 | +----------- | |
| 17 | + | |
| 18 | +This driver does not auto-detect devices. You will have to instantiate the | |
| 19 | +devices explicitly. Please see Documentation/i2c/instantiating-devices for | |
| 20 | +details. | |
| 21 | + | |
| 22 | +Sysfs entries | |
| 23 | +------------- | |
| 24 | + | |
| 25 | +The following attributes are supported: | |
| 26 | + | |
| 27 | +curr1_alarm Output current over-current alarm. | |
| 28 | +curr1_input Measured output current in mA. | |
| 29 | +curr1_label "iout1" | |
| 30 | + | |
| 31 | +fan1_alarm Fan 1 warning. | |
| 32 | +fan1_fault Fan 1 fault. | |
| 33 | +fan1_input Fan 1 speed in RPM. | |
| 34 | +fan2_alarm Fan 2 warning. | |
| 35 | +fan2_fault Fan 2 fault. | |
| 36 | +fan2_input Fan 2 speed in RPM. | |
| 37 | + | |
| 38 | +in1_alarm Input voltage under-voltage alarm. | |
| 39 | +in1_input Measured input voltage in mV. | |
| 40 | +in1_label "vin" | |
| 41 | +in2_alarm Output voltage over-voltage alarm. | |
| 42 | +in2_input Measured output voltage in mV. | |
| 43 | +in2_label "vout1" | |
| 44 | + | |
| 45 | +power1_alarm Input fault or alarm. | |
| 46 | +power1_input Measured input power in uW. | |
| 47 | +power1_label "pin" | |
| 48 | + | |
| 49 | +temp1_alarm PSU inlet ambient temperature over-temperature alarm. | |
| 50 | +temp1_input Measured PSU inlet ambient temp in millidegrees C. | |
| 51 | +temp2_alarm Secondary rectifier temp over-temperature alarm. | |
| 52 | +temp2_input Measured secondary rectifier temp in millidegrees C. | |
| 53 | +temp3_alarm ORing FET temperature over-temperature alarm. | |
| 54 | +temp3_input Measured ORing FET temperature in millidegrees C. | |
| @@ -29,6 +29,11 @@ Supported chips: · 28 unmodified lines | ||
| 29 | 29 | Addresses scanned: - |
| 30 | 30 | Datasheet: |
| 31 | 31 | http://www.national.com/pf/LM/LM5066.html |
| 32 | + * Texas Instruments LM5066I | |
| 33 | + Prefix: 'lm5066i' | |
| 34 | + Addresses scanned: - | |
| 35 | + Datasheet: | |
| 36 | + http://www.ti.com/product/LM5066I | |
| 32 | 37 | |
| 33 | 38 | Author: Guenter Roeck <linux@roeck-us.net> |
| 34 | 39 | |
| @@ -37,8 +42,8 @@ Description · 2 unmodified lines | ||
| 37 | 42 | ----------- |
| 38 | 43 | |
| 39 | 44 | This driver supports hardware monitoring for National Semiconductor / TI LM25056, |
| 40 | −LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and | |
| 41 | −Protection ICs. | |
| 45 | +LM25063, LM25066, LM5064, and LM5066/LM5066I Power Management, Monitoring, | |
| 46 | +Control, and Protection ICs. | |
| 42 | 47 | |
| 43 | 48 | The driver is a client driver to the core PMBus driver. Please see |
| 44 | 49 | Documentation/hwmon/pmbus for details on PMBus client drivers. |
| @@ -42,6 +42,10 @@ i2c-arb-gpio-challenge Parent-locked · 41 unmodified lines | ||
| 42 | 42 | i2c-mux-gpio Normally parent-locked, mux-locked iff |
| 43 | 43 | all involved gpio pins are controlled by the |
| 44 | 44 | same i2c root adapter that they mux. |
| 45 | +i2c-mux-gpmux Normally parent-locked, mux-locked iff | |
| 46 | + specified in device-tree. | |
| 47 | +i2c-mux-ltc4306 Mux-locked | |
| 48 | +i2c-mux-mlxcpld Parent-locked | |
| 45 | 49 | i2c-mux-pca9541 Parent-locked |
| 46 | 50 | i2c-mux-pca954x Parent-locked |
| 47 | 51 | i2c-mux-pinctrl Normally parent-locked, mux-locked iff |
| @@ -50,9 +54,11 @@ i2c-mux-pinctrl Normally parent-locked, mux-locked iff · 2 unmodified lines | ||
| 50 | 54 | i2c-mux-reg Parent-locked |
| 51 | 55 | |
| 52 | 56 | In drivers/iio/ |
| 57 | +gyro/mpu3050 Mux-locked | |
| 53 | 58 | imu/inv_mpu6050/ Mux-locked |
| 54 | 59 | |
| 55 | 60 | In drivers/media/ |
| 61 | +dvb-frontends/lgdt3306a Mux-locked | |
| 56 | 62 | dvb-frontends/m88ds3103 Parent-locked |
| 57 | 63 | dvb-frontends/rtl2830 Parent-locked |
| 58 | 64 | dvb-frontends/rtl2832 Mux-locked |
| @@ -0,0 +1,29 @@ | ||
| 1 | +Cirrus Logic EP93xx ADC driver. | |
| 2 | + | |
| 3 | +1. Overview | |
| 4 | + | |
| 5 | +The driver is intended to work on both low-end (EP9301, EP9302) devices with | |
| 6 | +5-channel ADC and high-end (EP9307, EP9312, EP9315) devices with 10-channel | |
| 7 | +touchscreen/ADC module. | |
| 8 | + | |
| 9 | +2. Channel numbering | |
| 10 | + | |
| 11 | +Numbering scheme for channels 0..4 is defined in EP9301 and EP9302 datasheets. | |
| 12 | +EP9307, EP9312 and EP9312 have 3 channels more (total 8), but the numbering is | |
| 13 | +not defined. So the last three are numbered randomly, let's say. | |
| 14 | + | |
| 15 | +Assuming ep93xx_adc is IIO device0, you'd find the following entries under | |
| 16 | +/sys/bus/iio/devices/iio:device0/: | |
| 17 | + | |
| 18 | + +-----------------+---------------+ | |
| 19 | + | sysfs entry | ball/pin name | | |
| 20 | + +-----------------+---------------+ | |
| 21 | + | in_voltage0_raw | YM | | |
| 22 | + | in_voltage1_raw | SXP | | |
| 23 | + | in_voltage2_raw | SXM | | |
| 24 | + | in_voltage3_raw | SYP | | |
| 25 | + | in_voltage4_raw | SYM | | |
| 26 | + | in_voltage5_raw | XP | | |
| 27 | + | in_voltage6_raw | XM | | |
| 28 | + | in_voltage7_raw | YP | | |
| 29 | + +-----------------+---------------+ | |
| @@ -0,0 +1,64 @@ | ||
| 1 | +Tag matching logic | |
| 2 | + | |
| 3 | +The MPI standard defines a set of rules, known as tag-matching, for matching | |
| 4 | +source send operations to destination receives. The following parameters must | |
| 5 | +match the following source and destination parameters: | |
| 6 | +* Communicator | |
| 7 | +* User tag - wild card may be specified by the receiver | |
| 8 | +* Source rank – wild car may be specified by the receiver | |
| 9 | +* Destination rank – wild | |
| 10 | +The ordering rules require that when more than one pair of send and receive | |
| 11 | +message envelopes may match, the pair that includes the earliest posted-send | |
| 12 | +and the earliest posted-receive is the pair that must be used to satisfy the | |
| 13 | +matching operation. However, this doesn’t imply that tags are consumed in | |
| 14 | +the order they are created, e.g., a later generated tag may be consumed, if | |
| 15 | +earlier tags can’t be used to satisfy the matching rules. | |
| 16 | + | |
| 17 | +When a message is sent from the sender to the receiver, the communication | |
| 18 | +library may attempt to process the operation either after or before the | |
| 19 | +corresponding matching receive is posted. If a matching receive is posted, | |
| 20 | +this is an expected message, otherwise it is called an unexpected message. | |
| 21 | +Implementations frequently use different matching schemes for these two | |
| 22 | +different matching instances. | |
| 23 | + | |
| 24 | +To keep MPI library memory footprint down, MPI implementations typically use | |
| 25 | +two different protocols for this purpose: | |
| 26 | + | |
| 27 | +1. The Eager protocol- the complete message is sent when the send is | |
| 28 | +processed by the sender. A completion send is received in the send_cq | |
| 29 | +notifying that the buffer can be reused. | |
| 30 | + | |
| 31 | +2. The Rendezvous Protocol - the sender sends the tag-matching header, | |
| 32 | +and perhaps a portion of data when first notifying the receiver. When the | |
| 33 | +corresponding buffer is posted, the responder will use the information from | |
| 34 | +the header to initiate an RDMA READ operation directly to the matching buffer. | |
| 35 | +A fin message needs to be received in order for the buffer to be reused. | |
| 36 | + | |
| 37 | +Tag matching implementation | |
| 38 | + | |
| 39 | +There are two types of matching objects used, the posted receive list and the | |
| 40 | +unexpected message list. The application posts receive buffers through calls | |
| 41 | +to the MPI receive routines in the posted receive list and posts send messages | |
| 42 | +using the MPI send routines. The head of the posted receive list may be | |
| 43 | +maintained by the hardware, with the software expected to shadow this list. | |
| 44 | + | |
| 45 | +When send is initiated and arrives at the receive side, if there is no | |
| 46 | +pre-posted receive for this arriving message, it is passed to the software and | |
| 47 | +placed in the unexpected message list. Otherwise the match is processed, | |
| 48 | +including rendezvous processing, if appropriate, delivering the data to the | |
| 49 | +specified receive buffer. This allows overlapping receive-side MPI tag | |
| 50 | +matching with computation. | |
| 51 | + | |
| 52 | +When a receive-message is posted, the communication library will first check | |
| 53 | +the software unexpected message list for a matching receive. If a match is | |
| 54 | +found, data is delivered to the user buffer, using a software controlled | |
| 55 | +protocol. The UCX implementation uses either an eager or rendezvous protocol, | |
| 56 | +depending on data size. If no match is found, the entire pre-posted receive | |
| 57 | +list is maintained by the hardware, and there is space to add one more | |
| 58 | +pre-posted receive to this list, this receive is passed to the hardware. | |
| 59 | +Software is expected to shadow this list, to help with processing MPI cancel | |
| 60 | +operations. In addition, because hardware and software are not expected to be | |
| 61 | +tightly synchronized with respect to the tag-matching operation, this shadow | |
| 62 | +list is used to detect the case that a pre-posted receive is passed to the | |
| 63 | +hardware, as the matching unexpected message is being passed from the hardware | |
| 64 | +to the software. | |
| @@ -109,7 +109,7 @@ evdev nodes are created with minors starting with 256. · 108 unmodified lines | ||
| 109 | 109 | keyboard |
| 110 | 110 | ~~~~~~~~ |
| 111 | 111 | |
| 112 | −``keyboard`` is in-kernel input handler ad is a part of VT code. It | |
| 112 | +``keyboard`` is in-kernel input handler and is a part of VT code. It | |
| 113 | 113 | consumes keyboard keystrokes and handles user input for VT consoles. |
| 114 | 114 | |
| 115 | 115 | mousedev |
| @@ -12,7 +12,6 @@ Linux Joystick support · 11 unmodified lines | ||
| 12 | 12 | |
| 13 | 13 | .. toctree:: |
| 14 | 14 | :maxdepth: 3 |
| 15 | − :numbered: | |
| 16 | 15 | |
| 17 | 16 | joystick |
| 18 | 17 | joystick-api |
| @@ -297,9 +297,9 @@ more details, with real examples. · 296 unmodified lines | ||
| 297 | 297 | ccflags-y specifies options for compiling with $(CC). |
| 298 | 298 | |
| 299 | 299 | Example: |
| 300 | − # drivers/acpi/Makefile | |
| 301 | − ccflags-y := -Os | |
| 302 | − ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT | |
| 300 | + # drivers/acpi/acpica/Makefile | |
| 301 | + ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA | |
| 302 | + ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT | |
| 303 | 303 | |
| 304 | 304 | This variable is necessary because the top Makefile owns the |
| 305 | 305 | variable $(KBUILD_CFLAGS) and uses it for compilation flags for the |
| @@ -121,8 +121,9 @@ space, for 2.6.23+ this is /sys/devices/platform/thinkpad_acpi/. · 120 unmodified lines | ||
| 121 | 121 | Sysfs device attributes for the sensors and fan are on the |
| 122 | 122 | thinkpad_hwmon device's sysfs attribute space, but you should locate it |
| 123 | 123 | looking for a hwmon device with the name attribute of "thinkpad", or |
| 124 | −better yet, through libsensors. | |
| 125 | − | |
| 124 | +better yet, through libsensors. For 4.14+ sysfs attributes were moved to the | |
| 125 | +hwmon device (/sys/bus/platform/devices/thinkpad_hwmon/hwmon/hwmon? or | |
| 126 | +/sys/class/hwmon/hwmon?). | |
| 126 | 127 | |
| 127 | 128 | Driver version |
| 128 | 129 | -------------- |
| @@ -1478,3 +1479,7 @@ Sysfs interface changelog: · 1349 unmodified lines | ||
| 1478 | 1479 | 0x020700: Support for mute-only mixers. |
| 1479 | 1480 | Volume control in read-only mode by default. |
| 1480 | 1481 | Marker for ALSA mixer support. |
| 1482 | + | |
| 1483 | +0x030000: Thermal and fan sysfs attributes were moved to the hwmon | |
| 1484 | + device instead of being attached to the backing platform | |
| 1485 | + device. | |
| @@ -0,0 +1,874 @@ | ||
| 1 | +Crossrelease | |
| 2 | +============ | |
| 3 | + | |
| 4 | +Started by Byungchul Park <byungchul.park@lge.com> | |
| 5 | + | |
| 6 | +Contents: | |
| 7 | + | |
| 8 | + (*) Background | |
| 9 | + | |
| 10 | + - What causes deadlock | |
| 11 | + - How lockdep works | |
| 12 | + | |
| 13 | + (*) Limitation | |
| 14 | + | |
| 15 | + - Limit lockdep | |
| 16 | + - Pros from the limitation | |
| 17 | + - Cons from the limitation | |
| 18 | + - Relax the limitation | |
| 19 | + | |
| 20 | + (*) Crossrelease | |
| 21 | + | |
| 22 | + - Introduce crossrelease | |
| 23 | + - Introduce commit | |
| 24 | + | |
| 25 | + (*) Implementation | |
| 26 | + | |
| 27 | + - Data structures | |
| 28 | + - How crossrelease works | |
| 29 | + | |
| 30 | + (*) Optimizations | |
| 31 | + | |
| 32 | + - Avoid duplication | |
| 33 | + - Lockless for hot paths | |
| 34 | + | |
| 35 | + (*) APPENDIX A: What lockdep does to work aggresively | |
| 36 | + | |
| 37 | + (*) APPENDIX B: How to avoid adding false dependencies | |
| 38 | + | |
| 39 | + | |
| 40 | +========== | |
| 41 | +Background | |
| 42 | +========== | |
| 43 | + | |
| 44 | +What causes deadlock | |
| 45 | +-------------------- | |
| 46 | + | |
| 47 | +A deadlock occurs when a context is waiting for an event to happen, | |
| 48 | +which is impossible because another (or the) context who can trigger the | |
| 49 | +event is also waiting for another (or the) event to happen, which is | |
| 50 | +also impossible due to the same reason. | |
| 51 | + | |
| 52 | +For example: | |
| 53 | + | |
| 54 | + A context going to trigger event C is waiting for event A to happen. | |
| 55 | + A context going to trigger event A is waiting for event B to happen. | |
| 56 | + A context going to trigger event B is waiting for event C to happen. | |
| 57 | + | |
| 58 | +A deadlock occurs when these three wait operations run at the same time, | |
| 59 | +because event C cannot be triggered if event A does not happen, which in | |
| 60 | +turn cannot be triggered if event B does not happen, which in turn | |
| 61 | +cannot be triggered if event C does not happen. After all, no event can | |
| 62 | +be triggered since any of them never meets its condition to wake up. | |
| 63 | + | |
| 64 | +A dependency might exist between two waiters and a deadlock might happen | |
| 65 | +due to an incorrect releationship between dependencies. Thus, we must | |
| 66 | +define what a dependency is first. A dependency exists between them if: | |
| 67 | + | |
| 68 | + 1. There are two waiters waiting for each event at a given time. | |
| 69 | + 2. The only way to wake up each waiter is to trigger its event. | |
| 70 | + 3. Whether one can be woken up depends on whether the other can. | |
| 71 | + | |
| 72 | +Each wait in the example creates its dependency like: | |
| 73 | + | |
| 74 | + Event C depends on event A. | |
| 75 | + Event A depends on event B. | |
| 76 | + Event B depends on event C. | |
| 77 | + | |
| 78 | + NOTE: Precisely speaking, a dependency is one between whether a | |
| 79 | + waiter for an event can be woken up and whether another waiter for | |
| 80 | + another event can be woken up. However from now on, we will describe | |
| 81 | + a dependency as if it's one between an event and another event for | |
| 82 | + simplicity. | |
| 83 | + | |
| 84 | +And they form circular dependencies like: | |
| 85 | + | |
| 86 | + -> C -> A -> B - | |
| 87 | + / \ | |
| 88 | + \ / | |
| 89 | + ---------------- | |
| 90 | + | |
| 91 | + where 'A -> B' means that event A depends on event B. | |
| 92 | + | |
| 93 | +Such circular dependencies lead to a deadlock since no waiter can meet | |
| 94 | +its condition to wake up as described. | |
| 95 | + | |
| 96 | +CONCLUSION | |
| 97 | + | |
| 98 | +Circular dependencies cause a deadlock. | |
| 99 | + | |
| 100 | + | |
| 101 | +How lockdep works | |
| 102 | +----------------- | |
| 103 | + | |
| 104 | +Lockdep tries to detect a deadlock by checking dependencies created by | |
| 105 | +lock operations, acquire and release. Waiting for a lock corresponds to | |
| 106 | +waiting for an event, and releasing a lock corresponds to triggering an | |
| 107 | +event in the previous section. | |
| 108 | + | |
| 109 | +In short, lockdep does: | |
| 110 | + | |
| 111 | + 1. Detect a new dependency. | |
| 112 | + 2. Add the dependency into a global graph. | |
| 113 | + 3. Check if that makes dependencies circular. | |
| 114 | + 4. Report a deadlock or its possibility if so. | |
| 115 | + | |
| 116 | +For example, consider a graph built by lockdep that looks like: | |
| 117 | + | |
| 118 | + A -> B - | |
| 119 | + \ | |
| 120 | + -> E | |
| 121 | + / | |
| 122 | + C -> D - | |
| 123 | + | |
| 124 | + where A, B,..., E are different lock classes. | |
| 125 | + | |
| 126 | +Lockdep will add a dependency into the graph on detection of a new | |
| 127 | +dependency. For example, it will add a dependency 'E -> C' when a new | |
| 128 | +dependency between lock E and lock C is detected. Then the graph will be: | |
| 129 | + | |
| 130 | + A -> B - | |
| 131 | + \ | |
| 132 | + -> E - | |
| 133 | + / \ | |
| 134 | + -> C -> D - \ | |
| 135 | + / / | |
| 136 | + \ / | |
| 137 | + ------------------ | |
| 138 | + | |
| 139 | + where A, B,..., E are different lock classes. | |
| 140 | + | |
| 141 | +This graph contains a subgraph which demonstrates circular dependencies: | |
| 142 | + | |
| 143 | + -> E - | |
| 144 | + / \ | |
| 145 | + -> C -> D - \ | |
| 146 | + / / | |
| 147 | + \ / | |
| 148 | + ------------------ | |
| 149 | + | |
| 150 | + where C, D and E are different lock classes. | |
| 151 | + | |
| 152 | +This is the condition under which a deadlock might occur. Lockdep | |
| 153 | +reports it on detection after adding a new dependency. This is the way | |
| 154 | +how lockdep works. | |
| 155 | + | |
| 156 | +CONCLUSION | |
| 157 | + | |
| 158 | +Lockdep detects a deadlock or its possibility by checking if circular | |
| 159 | +dependencies were created after adding each new dependency. | |
| 160 | + | |
| 161 | + | |
| 162 | +========== | |
| 163 | +Limitation | |
| 164 | +========== | |
| 165 | + | |
| 166 | +Limit lockdep | |
| 167 | +------------- | |
| 168 | + | |
| 169 | +Limiting lockdep to work on only typical locks e.g. spin locks and | |
| 170 | +mutexes, which are released within the acquire context, the | |
| 171 | +implementation becomes simple but its capacity for detection becomes | |
| 172 | +limited. Let's check pros and cons in next section. | |
| 173 | + | |
| 174 | + | |
| 175 | +Pros from the limitation | |
| 176 | +------------------------ | |
| 177 | + | |
| 178 | +Given the limitation, when acquiring a lock, locks in a held_locks | |
| 179 | +cannot be released if the context cannot acquire it so has to wait to | |
| 180 | +acquire it, which means all waiters for the locks in the held_locks are | |
| 181 | +stuck. It's an exact case to create dependencies between each lock in | |
| 182 | +the held_locks and the lock to acquire. | |
| 183 | + | |
| 184 | +For example: | |
| 185 | + | |
| 186 | + CONTEXT X | |
| 187 | + --------- | |
| 188 | + acquire A | |
| 189 | + acquire B /* Add a dependency 'A -> B' */ | |
| 190 | + release B | |
| 191 | + release A | |
| 192 | + | |
| 193 | + where A and B are different lock classes. | |
| 194 | + | |
| 195 | +When acquiring lock A, the held_locks of CONTEXT X is empty thus no | |
| 196 | +dependency is added. But when acquiring lock B, lockdep detects and adds | |
| 197 | +a new dependency 'A -> B' between lock A in the held_locks and lock B. | |
| 198 | +They can be simply added whenever acquiring each lock. | |
| 199 | + | |
| 200 | +And data required by lockdep exists in a local structure, held_locks | |
| 201 | +embedded in task_struct. Forcing to access the data within the context, | |
| 202 | +lockdep can avoid racy problems without explicit locks while handling | |
| 203 | +the local data. | |
| 204 | + | |
| 205 | +Lastly, lockdep only needs to keep locks currently being held, to build | |
| 206 | +a dependency graph. However, relaxing the limitation, it needs to keep | |
| 207 | +even locks already released, because a decision whether they created | |
| 208 | +dependencies might be long-deferred. | |
| 209 | + | |
| 210 | +To sum up, we can expect several advantages from the limitation: | |
| 211 | + | |
| 212 | + 1. Lockdep can easily identify a dependency when acquiring a lock. | |
| 213 | + 2. Races are avoidable while accessing local locks in a held_locks. | |
| 214 | + 3. Lockdep only needs to keep locks currently being held. | |
| 215 | + | |
| 216 | +CONCLUSION | |
| 217 | + | |
| 218 | +Given the limitation, the implementation becomes simple and efficient. | |
| 219 | + | |
| 220 | + | |
| 221 | +Cons from the limitation | |
| 222 | +------------------------ | |
| 223 | + | |
| 224 | +Given the limitation, lockdep is applicable only to typical locks. For | |
| 225 | +example, page locks for page access or completions for synchronization | |
| 226 | +cannot work with lockdep. | |
| 227 | + | |
| 228 | +Can we detect deadlocks below, under the limitation? | |
| 229 | + | |
| 230 | +Example 1: | |
| 231 | + | |
| 232 | + CONTEXT X CONTEXT Y CONTEXT Z | |
| 233 | + --------- --------- ---------- | |
| 234 | + mutex_lock A | |
| 235 | + lock_page B | |
| 236 | + lock_page B | |
| 237 | + mutex_lock A /* DEADLOCK */ | |
| 238 | + unlock_page B held by X | |
| 239 | + unlock_page B | |
| 240 | + mutex_unlock A | |
| 241 | + mutex_unlock A | |
| 242 | + | |
| 243 | + where A and B are different lock classes. | |
| 244 | + | |
| 245 | +No, we cannot. | |
| 246 | + | |
| 247 | +Example 2: | |
| 248 | + | |
| 249 | + CONTEXT X CONTEXT Y | |
| 250 | + --------- --------- | |
| 251 | + mutex_lock A | |
| 252 | + mutex_lock A | |
| 253 | + wait_for_complete B /* DEADLOCK */ | |
| 254 | + complete B | |
| 255 | + mutex_unlock A | |
| 256 | + mutex_unlock A | |
| 257 | + | |
| 258 | + where A is a lock class and B is a completion variable. | |
| 259 | + | |
| 260 | +No, we cannot. | |
| 261 | + | |
| 262 | +CONCLUSION | |
| 263 | + | |
| 264 | +Given the limitation, lockdep cannot detect a deadlock or its | |
| 265 | +possibility caused by page locks or completions. | |
| 266 | + | |
| 267 | + | |
| 268 | +Relax the limitation | |
| 269 | +-------------------- | |
| 270 | + | |
| 271 | +Under the limitation, things to create dependencies are limited to | |
| 272 | +typical locks. However, synchronization primitives like page locks and | |
| 273 | +completions, which are allowed to be released in any context, also | |
| 274 | +create dependencies and can cause a deadlock. So lockdep should track | |
| 275 | +these locks to do a better job. We have to relax the limitation for | |
| 276 | +these locks to work with lockdep. | |
| 277 | + | |
| 278 | +Detecting dependencies is very important for lockdep to work because | |
| 279 | +adding a dependency means adding an opportunity to check whether it | |
| 280 | +causes a deadlock. The more lockdep adds dependencies, the more it | |
| 281 | +thoroughly works. Thus Lockdep has to do its best to detect and add as | |
| 282 | +many true dependencies into a graph as possible. | |
| 283 | + | |
| 284 | +For example, considering only typical locks, lockdep builds a graph like: | |
| 285 | + | |
| 286 | + A -> B - | |
| 287 | + \ | |
| 288 | + -> E | |
| 289 | + / | |
| 290 | + C -> D - | |
| 291 | + | |
| 292 | + where A, B,..., E are different lock classes. | |
| 293 | + | |
| 294 | +On the other hand, under the relaxation, additional dependencies might | |
| 295 | +be created and added. Assuming additional 'FX -> C' and 'E -> GX' are | |
| 296 | +added thanks to the relaxation, the graph will be: | |
| 297 | + | |
| 298 | + A -> B - | |
| 299 | + \ | |
| 300 | + -> E -> GX | |
| 301 | + / | |
| 302 | + FX -> C -> D - | |
| 303 | + | |
| 304 | + where A, B,..., E, FX and GX are different lock classes, and a suffix | |
| 305 | + 'X' is added on non-typical locks. | |
| 306 | + | |
| 307 | +The latter graph gives us more chances to check circular dependencies | |
| 308 | +than the former. However, it might suffer performance degradation since | |
| 309 | +relaxing the limitation, with which design and implementation of lockdep | |
| 310 | +can be efficient, might introduce inefficiency inevitably. So lockdep | |
| 311 | +should provide two options, strong detection and efficient detection. | |
| 312 | + | |
| 313 | +Choosing efficient detection: | |
| 314 | + | |
| 315 | + Lockdep works with only locks restricted to be released within the | |
| 316 | + acquire context. However, lockdep works efficiently. | |
| 317 | + | |
| 318 | +Choosing strong detection: | |
| 319 | + | |
| 320 | + Lockdep works with all synchronization primitives. However, lockdep | |
| 321 | + suffers performance degradation. | |
| 322 | + | |
| 323 | +CONCLUSION | |
| 324 | + | |
| 325 | +Relaxing the limitation, lockdep can add additional dependencies giving | |
| 326 | +additional opportunities to check circular dependencies. | |
| 327 | + | |
| 328 | + | |
| 329 | +============ | |
| 330 | +Crossrelease | |
| 331 | +============ | |
| 332 | + | |
| 333 | +Introduce crossrelease | |
| 334 | +---------------------- | |
| 335 | + | |
| 336 | +In order to allow lockdep to handle additional dependencies by what | |
| 337 | +might be released in any context, namely 'crosslock', we have to be able | |
| 338 | +to identify those created by crosslocks. The proposed 'crossrelease' | |
| 339 | +feature provoides a way to do that. | |
| 340 | + | |
| 341 | +Crossrelease feature has to do: | |
| 342 | + | |
| 343 | + 1. Identify dependencies created by crosslocks. | |
| 344 | + 2. Add the dependencies into a dependency graph. | |
| 345 | + | |
| 346 | +That's all. Once a meaningful dependency is added into graph, then | |
| 347 | +lockdep would work with the graph as it did. The most important thing | |
| 348 | +crossrelease feature has to do is to correctly identify and add true | |
| 349 | +dependencies into the global graph. | |
| 350 | + | |
| 351 | +A dependency e.g. 'A -> B' can be identified only in the A's release | |
| 352 | +context because a decision required to identify the dependency can be | |
| 353 | +made only in the release context. That is to decide whether A can be | |
| 354 | +released so that a waiter for A can be woken up. It cannot be made in | |
| 355 | +other than the A's release context. | |
| 356 | + | |
| 357 | +It's no matter for typical locks because each acquire context is same as | |
| 358 | +its release context, thus lockdep can decide whether a lock can be | |
| 359 | +released in the acquire context. However for crosslocks, lockdep cannot | |
| 360 | +make the decision in the acquire context but has to wait until the | |
| 361 | +release context is identified. | |
| 362 | + | |
| 363 | +Therefore, deadlocks by crosslocks cannot be detected just when it | |
| 364 | +happens, because those cannot be identified until the crosslocks are | |
| 365 | +released. However, deadlock possibilities can be detected and it's very | |
| 366 | +worth. See 'APPENDIX A' section to check why. | |
| 367 | + | |
| 368 | +CONCLUSION | |
| 369 | + | |
| 370 | +Using crossrelease feature, lockdep can work with what might be released | |
| 371 | +in any context, namely crosslock. | |
| 372 | + | |
| 373 | + | |
| 374 | +Introduce commit | |
| 375 | +---------------- | |
| 376 | + | |
| 377 | +Since crossrelease defers the work adding true dependencies of | |
| 378 | +crosslocks until they are actually released, crossrelease has to queue | |
| 379 | +all acquisitions which might create dependencies with the crosslocks. | |
| 380 | +Then it identifies dependencies using the queued data in batches at a | |
| 381 | +proper time. We call it 'commit'. | |
| 382 | + | |
| 383 | +There are four types of dependencies: | |
| 384 | + | |
| 385 | +1. TT type: 'typical lock A -> typical lock B' | |
| 386 | + | |
| 387 | + Just when acquiring B, lockdep can see it's in the A's release | |
| 388 | + context. So the dependency between A and B can be identified | |
| 389 | + immediately. Commit is unnecessary. | |
| 390 | + | |
| 391 | +2. TC type: 'typical lock A -> crosslock BX' | |
| 392 | + | |
| 393 | + Just when acquiring BX, lockdep can see it's in the A's release | |
| 394 | + context. So the dependency between A and BX can be identified | |
| 395 | + immediately. Commit is unnecessary, too. | |
| 396 | + | |
| 397 | +3. CT type: 'crosslock AX -> typical lock B' | |
| 398 | + | |
| 399 | + When acquiring B, lockdep cannot identify the dependency because | |
| 400 | + there's no way to know if it's in the AX's release context. It has | |
| 401 | + to wait until the decision can be made. Commit is necessary. | |
| 402 | + | |
| 403 | +4. CC type: 'crosslock AX -> crosslock BX' | |
| 404 | + | |
| 405 | + When acquiring BX, lockdep cannot identify the dependency because | |
| 406 | + there's no way to know if it's in the AX's release context. It has | |
| 407 | + to wait until the decision can be made. Commit is necessary. | |
| 408 | + But, handling CC type is not implemented yet. It's a future work. | |
| 409 | + | |
| 410 | +Lockdep can work without commit for typical locks, but commit step is | |
| 411 | +necessary once crosslocks are involved. Introducing commit, lockdep | |
| 412 | +performs three steps. What lockdep does in each step is: | |
| 413 | + | |
| 414 | +1. Acquisition: For typical locks, lockdep does what it originally did | |
| 415 | + and queues the lock so that CT type dependencies can be checked using | |
| 416 | + it at the commit step. For crosslocks, it saves data which will be | |
| 417 | + used at the commit step and increases a reference count for it. | |
| 418 | + | |
| 419 | +2. Commit: No action is reauired for typical locks. For crosslocks, | |
| 420 | + lockdep adds CT type dependencies using the data saved at the | |
| 421 | + acquisition step. | |
| 422 | + | |
| 423 | +3. Release: No changes are required for typical locks. When a crosslock | |
| 424 | + is released, it decreases a reference count for it. | |
| 425 | + | |
| 426 | +CONCLUSION | |
| 427 | + | |
| 428 | +Crossrelease introduces commit step to handle dependencies of crosslocks | |
| 429 | +in batches at a proper time. | |
| 430 | + | |
| 431 | + | |
| 432 | +============== | |
| 433 | +Implementation | |
| 434 | +============== | |
| 435 | + | |
| 436 | +Data structures | |
| 437 | +--------------- | |
| 438 | + | |
| 439 | +Crossrelease introduces two main data structures. | |
| 440 | + | |
| 441 | +1. hist_lock | |
| 442 | + | |
| 443 | + This is an array embedded in task_struct, for keeping lock history so | |
| 444 | + that dependencies can be added using them at the commit step. Since | |
| 445 | + it's local data, it can be accessed locklessly in the owner context. | |
| 446 | + The array is filled at the acquisition step and consumed at the | |
| 447 | + commit step. And it's managed in circular manner. | |
| 448 | + | |
| 449 | +2. cross_lock | |
| 450 | + | |
| 451 | + One per lockdep_map exists. This is for keeping data of crosslocks | |
| 452 | + and used at the commit step. | |
| 453 | + | |
| 454 | + | |
| 455 | +How crossrelease works | |
| 456 | +---------------------- | |
| 457 | + | |
| 458 | +It's the key of how crossrelease works, to defer necessary works to an | |
| 459 | +appropriate point in time and perform in at once at the commit step. | |
| 460 | +Let's take a look with examples step by step, starting from how lockdep | |
| 461 | +works without crossrelease for typical locks. | |
| 462 | + | |
| 463 | + acquire A /* Push A onto held_locks */ | |
| 464 | + acquire B /* Push B onto held_locks and add 'A -> B' */ | |
| 465 | + acquire C /* Push C onto held_locks and add 'B -> C' */ | |
| 466 | + release C /* Pop C from held_locks */ | |
| 467 | + release B /* Pop B from held_locks */ | |
| 468 | + release A /* Pop A from held_locks */ | |
| 469 | + | |
| 470 | + where A, B and C are different lock classes. | |
| 471 | + | |
| 472 | + NOTE: This document assumes that readers already understand how | |
| 473 | + lockdep works without crossrelease thus omits details. But there's | |
| 474 | + one thing to note. Lockdep pretends to pop a lock from held_locks | |
| 475 | + when releasing it. But it's subtly different from the original pop | |
| 476 | + operation because lockdep allows other than the top to be poped. | |
| 477 | + | |
| 478 | +In this case, lockdep adds 'the top of held_locks -> the lock to acquire' | |
| 479 | +dependency every time acquiring a lock. | |
| 480 | + | |
| 481 | +After adding 'A -> B', a dependency graph will be: | |
| 482 | + | |
| 483 | + A -> B | |
| 484 | + | |
| 485 | + where A and B are different lock classes. | |
| 486 | + | |
| 487 | +And after adding 'B -> C', the graph will be: | |
| 488 | + | |
| 489 | + A -> B -> C | |
| 490 | + | |
| 491 | + where A, B and C are different lock classes. | |
| 492 | + | |
| 493 | +Let's performs commit step even for typical locks to add dependencies. | |
| 494 | +Of course, commit step is not necessary for them, however, it would work | |
| 495 | +well because this is a more general way. | |
| 496 | + | |
| 497 | + acquire A | |
| 498 | + /* | |
| 499 | + * Queue A into hist_locks | |
| 500 | + * | |
| 501 | + * In hist_locks: A | |
| 502 | + * In graph: Empty | |
| 503 | + */ | |
| 504 | + | |
| 505 | + acquire B | |
| 506 | + /* | |
| 507 | + * Queue B into hist_locks | |
| 508 | + * | |
| 509 | + * In hist_locks: A, B | |
| 510 | + * In graph: Empty | |
| 511 | + */ | |
| 512 | + | |
| 513 | + acquire C | |
| 514 | + /* | |
| 515 | + * Queue C into hist_locks | |
| 516 | + * | |
| 517 | + * In hist_locks: A, B, C | |
| 518 | + * In graph: Empty | |
| 519 | + */ | |
| 520 | + | |
| 521 | + commit C | |
| 522 | + /* | |
| 523 | + * Add 'C -> ?' | |
| 524 | + * Answer the following to decide '?' | |
| 525 | + * What has been queued since acquire C: Nothing | |
| 526 | + * | |
| 527 | + * In hist_locks: A, B, C | |
| 528 | + * In graph: Empty | |
| 529 | + */ | |
| 530 | + | |
| 531 | + release C | |
| 532 | + | |
| 533 | + commit B | |
| 534 | + /* | |
| 535 | + * Add 'B -> ?' | |
| 536 | + * Answer the following to decide '?' | |
| 537 | + * What has been queued since acquire B: C | |
| 538 | + * | |
| 539 | + * In hist_locks: A, B, C | |
| 540 | + * In graph: 'B -> C' | |
| 541 | + */ | |
| 542 | + | |
| 543 | + release B | |
| 544 | + | |
| 545 | + commit A | |
| 546 | + /* | |
| 547 | + * Add 'A -> ?' | |
| 548 | + * Answer the following to decide '?' | |
| 549 | + * What has been queued since acquire A: B, C | |
| 550 | + * | |
| 551 | + * In hist_locks: A, B, C | |
| 552 | + * In graph: 'B -> C', 'A -> B', 'A -> C' | |
| 553 | + */ | |
| 554 | + | |
| 555 | + release A | |
| 556 | + | |
| 557 | + where A, B and C are different lock classes. | |
| 558 | + | |
| 559 | +In this case, dependencies are added at the commit step as described. | |
| 560 | + | |
| 561 | +After commits for A, B and C, the graph will be: | |
| 562 | + | |
| 563 | + A -> B -> C | |
| 564 | + | |
| 565 | + where A, B and C are different lock classes. | |
| 566 | + | |
| 567 | + NOTE: A dependency 'A -> C' is optimized out. | |
| 568 | + | |
| 569 | +We can see the former graph built without commit step is same as the | |
| 570 | +latter graph built using commit steps. Of course the former way leads to | |
| 571 | +earlier finish for building the graph, which means we can detect a | |
| 572 | +deadlock or its possibility sooner. So the former way would be prefered | |
| 573 | +when possible. But we cannot avoid using the latter way for crosslocks. | |
| 574 | + | |
| 575 | +Let's look at how commit steps work for crosslocks. In this case, the | |
| 576 | +commit step is performed only on crosslock AX as real. And it assumes | |
| 577 | +that the AX release context is different from the AX acquire context. | |
| 578 | + | |
| 579 | + BX RELEASE CONTEXT BX ACQUIRE CONTEXT | |
| 580 | + ------------------ ------------------ | |
| 581 | + acquire A | |
| 582 | + /* | |
| 583 | + * Push A onto held_locks | |
| 584 | + * Queue A into hist_locks | |
| 585 | + * | |
| 586 | + * In held_locks: A | |
| 587 | + * In hist_locks: A | |
| 588 | + * In graph: Empty | |
| 589 | + */ | |
| 590 | + | |
| 591 | + acquire BX | |
| 592 | + /* | |
| 593 | + * Add 'the top of held_locks -> BX' | |
| 594 | + * | |
| 595 | + * In held_locks: A | |
| 596 | + * In hist_locks: A | |
| 597 | + * In graph: 'A -> BX' | |
| 598 | + */ | |
| 599 | + | |
| 600 | + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 601 | + It must be guaranteed that the following operations are seen after | |
| 602 | + acquiring BX globally. It can be done by things like barrier. | |
| 603 | + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 604 | + | |
| 605 | + acquire C | |
| 606 | + /* | |
| 607 | + * Push C onto held_locks | |
| 608 | + * Queue C into hist_locks | |
| 609 | + * | |
| 610 | + * In held_locks: C | |
| 611 | + * In hist_locks: C | |
| 612 | + * In graph: 'A -> BX' | |
| 613 | + */ | |
| 614 | + | |
| 615 | + release C | |
| 616 | + /* | |
| 617 | + * Pop C from held_locks | |
| 618 | + * | |
| 619 | + * In held_locks: Empty | |
| 620 | + * In hist_locks: C | |
| 621 | + * In graph: 'A -> BX' | |
| 622 | + */ | |
| 623 | + acquire D | |
| 624 | + /* | |
| 625 | + * Push D onto held_locks | |
| 626 | + * Queue D into hist_locks | |
| 627 | + * Add 'the top of held_locks -> D' | |
| 628 | + * | |
| 629 | + * In held_locks: A, D | |
| 630 | + * In hist_locks: A, D | |
| 631 | + * In graph: 'A -> BX', 'A -> D' | |
| 632 | + */ | |
| 633 | + acquire E | |
| 634 | + /* | |
| 635 | + * Push E onto held_locks | |
| 636 | + * Queue E into hist_locks | |
| 637 | + * | |
| 638 | + * In held_locks: E | |
| 639 | + * In hist_locks: C, E | |
| 640 | + * In graph: 'A -> BX', 'A -> D' | |
| 641 | + */ | |
| 642 | + | |
| 643 | + release E | |
| 644 | + /* | |
| 645 | + * Pop E from held_locks | |
| 646 | + * | |
| 647 | + * In held_locks: Empty | |
| 648 | + * In hist_locks: D, E | |
| 649 | + * In graph: 'A -> BX', 'A -> D' | |
| 650 | + */ | |
| 651 | + release D | |
| 652 | + /* | |
| 653 | + * Pop D from held_locks | |
| 654 | + * | |
| 655 | + * In held_locks: A | |
| 656 | + * In hist_locks: A, D | |
| 657 | + * In graph: 'A -> BX', 'A -> D' | |
| 658 | + */ | |
| 659 | + commit BX | |
| 660 | + /* | |
| 661 | + * Add 'BX -> ?' | |
| 662 | + * What has been queued since acquire BX: C, E | |
| 663 | + * | |
| 664 | + * In held_locks: Empty | |
| 665 | + * In hist_locks: D, E | |
| 666 | + * In graph: 'A -> BX', 'A -> D', | |
| 667 | + * 'BX -> C', 'BX -> E' | |
| 668 | + */ | |
| 669 | + | |
| 670 | + release BX | |
| 671 | + /* | |
| 672 | + * In held_locks: Empty | |
| 673 | + * In hist_locks: D, E | |
| 674 | + * In graph: 'A -> BX', 'A -> D', | |
| 675 | + * 'BX -> C', 'BX -> E' | |
| 676 | + */ | |
| 677 | + release A | |
| 678 | + /* | |
| 679 | + * Pop A from held_locks | |
| 680 | + * | |
| 681 | + * In held_locks: Empty | |
| 682 | + * In hist_locks: A, D | |
| 683 | + * In graph: 'A -> BX', 'A -> D', | |
| 684 | + * 'BX -> C', 'BX -> E' | |
| 685 | + */ | |
| 686 | + | |
| 687 | + where A, BX, C,..., E are different lock classes, and a suffix 'X' is | |
| 688 | + added on crosslocks. | |
| 689 | + | |
| 690 | +Crossrelease considers all acquisitions after acqiuring BX are | |
| 691 | +candidates which might create dependencies with BX. True dependencies | |
| 692 | +will be determined when identifying the release context of BX. Meanwhile, | |
| 693 | +all typical locks are queued so that they can be used at the commit step. | |
| 694 | +And then two dependencies 'BX -> C' and 'BX -> E' are added at the | |
| 695 | +commit step when identifying the release context. | |
| 696 | + | |
| 697 | +The final graph will be, with crossrelease: | |
| 698 | + | |
| 699 | + -> C | |
| 700 | + / | |
| 701 | + -> BX - | |
| 702 | + / \ | |
| 703 | + A - -> E | |
| 704 | + \ | |
| 705 | + -> D | |
| 706 | + | |
| 707 | + where A, BX, C,..., E are different lock classes, and a suffix 'X' is | |
| 708 | + added on crosslocks. | |
| 709 | + | |
| 710 | +However, the final graph will be, without crossrelease: | |
| 711 | + | |
| 712 | + A -> D | |
| 713 | + | |
| 714 | + where A and D are different lock classes. | |
| 715 | + | |
| 716 | +The former graph has three more dependencies, 'A -> BX', 'BX -> C' and | |
| 717 | +'BX -> E' giving additional opportunities to check if they cause | |
| 718 | +deadlocks. This way lockdep can detect a deadlock or its possibility | |
| 719 | +caused by crosslocks. | |
| 720 | + | |
| 721 | +CONCLUSION | |
| 722 | + | |
| 723 | +We checked how crossrelease works with several examples. | |
| 724 | + | |
| 725 | + | |
| 726 | +============= | |
| 727 | +Optimizations | |
| 728 | +============= | |
| 729 | + | |
| 730 | +Avoid duplication | |
| 731 | +----------------- | |
| 732 | + | |
| 733 | +Crossrelease feature uses a cache like what lockdep already uses for | |
| 734 | +dependency chains, but this time it's for caching CT type dependencies. | |
| 735 | +Once that dependency is cached, the same will never be added again. | |
| 736 | + | |
| 737 | + | |
| 738 | +Lockless for hot paths | |
| 739 | +---------------------- | |
| 740 | + | |
| 741 | +To keep all locks for later use at the commit step, crossrelease adopts | |
| 742 | +a local array embedded in task_struct, which makes access to the data | |
| 743 | +lockless by forcing it to happen only within the owner context. It's | |
| 744 | +like how lockdep handles held_locks. Lockless implmentation is important | |
| 745 | +since typical locks are very frequently acquired and released. | |
| 746 | + | |
| 747 | + | |
| 748 | +================================================= | |
| 749 | +APPENDIX A: What lockdep does to work aggresively | |
| 750 | +================================================= | |
| 751 | + | |
| 752 | +A deadlock actually occurs when all wait operations creating circular | |
| 753 | +dependencies run at the same time. Even though they don't, a potential | |
| 754 | +deadlock exists if the problematic dependencies exist. Thus it's | |
| 755 | +meaningful to detect not only an actual deadlock but also its potential | |
| 756 | +possibility. The latter is rather valuable. When a deadlock occurs | |
| 757 | +actually, we can identify what happens in the system by some means or | |
| 758 | +other even without lockdep. However, there's no way to detect possiblity | |
| 759 | +without lockdep unless the whole code is parsed in head. It's terrible. | |
| 760 | +Lockdep does the both, and crossrelease only focuses on the latter. | |
| 761 | + | |
| 762 | +Whether or not a deadlock actually occurs depends on several factors. | |
| 763 | +For example, what order contexts are switched in is a factor. Assuming | |
| 764 | +circular dependencies exist, a deadlock would occur when contexts are | |
| 765 | +switched so that all wait operations creating the dependencies run | |
| 766 | +simultaneously. Thus to detect a deadlock possibility even in the case | |
| 767 | +that it has not occured yet, lockdep should consider all possible | |
| 768 | +combinations of dependencies, trying to: | |
| 769 | + | |
| 770 | +1. Use a global dependency graph. | |
| 771 | + | |
| 772 | + Lockdep combines all dependencies into one global graph and uses them, | |
| 773 | + regardless of which context generates them or what order contexts are | |
| 774 | + switched in. Aggregated dependencies are only considered so they are | |
| 775 | + prone to be circular if a problem exists. | |
| 776 | + | |
| 777 | +2. Check dependencies between classes instead of instances. | |
| 778 | + | |
| 779 | + What actually causes a deadlock are instances of lock. However, | |
| 780 | + lockdep checks dependencies between classes instead of instances. | |
| 781 | + This way lockdep can detect a deadlock which has not happened but | |
| 782 | + might happen in future by others but the same class. | |
| 783 | + | |
| 784 | +3. Assume all acquisitions lead to waiting. | |
| 785 | + | |
| 786 | + Although locks might be acquired without waiting which is essential | |
| 787 | + to create dependencies, lockdep assumes all acquisitions lead to | |
| 788 | + waiting since it might be true some time or another. | |
| 789 | + | |
| 790 | +CONCLUSION | |
| 791 | + | |
| 792 | +Lockdep detects not only an actual deadlock but also its possibility, | |
| 793 | +and the latter is more valuable. | |
| 794 | + | |
| 795 | + | |
| 796 | +================================================== | |
| 797 | +APPENDIX B: How to avoid adding false dependencies | |
| 798 | +================================================== | |
| 799 | + | |
| 800 | +Remind what a dependency is. A dependency exists if: | |
| 801 | + | |
| 802 | + 1. There are two waiters waiting for each event at a given time. | |
| 803 | + 2. The only way to wake up each waiter is to trigger its event. | |
| 804 | + 3. Whether one can be woken up depends on whether the other can. | |
| 805 | + | |
| 806 | +For example: | |
| 807 | + | |
| 808 | + acquire A | |
| 809 | + acquire B /* A dependency 'A -> B' exists */ | |
| 810 | + release B | |
| 811 | + release A | |
| 812 | + | |
| 813 | + where A and B are different lock classes. | |
| 814 | + | |
| 815 | +A depedency 'A -> B' exists since: | |
| 816 | + | |
| 817 | + 1. A waiter for A and a waiter for B might exist when acquiring B. | |
| 818 | + 2. Only way to wake up each is to release what it waits for. | |
| 819 | + 3. Whether the waiter for A can be woken up depends on whether the | |
| 820 | + other can. IOW, TASK X cannot release A if it fails to acquire B. | |
| 821 | + | |
| 822 | +For another example: | |
| 823 | + | |
| 824 | + TASK X TASK Y | |
| 825 | + ------ ------ | |
| 826 | + acquire AX | |
| 827 | + acquire B /* A dependency 'AX -> B' exists */ | |
| 828 | + release B | |
| 829 | + release AX held by Y | |
| 830 | + | |
| 831 | + where AX and B are different lock classes, and a suffix 'X' is added | |
| 832 | + on crosslocks. | |
| 833 | + | |
| 834 | +Even in this case involving crosslocks, the same rule can be applied. A | |
| 835 | +depedency 'AX -> B' exists since: | |
| 836 | + | |
| 837 | + 1. A waiter for AX and a waiter for B might exist when acquiring B. | |
| 838 | + 2. Only way to wake up each is to release what it waits for. | |
| 839 | + 3. Whether the waiter for AX can be woken up depends on whether the | |
| 840 | + other can. IOW, TASK X cannot release AX if it fails to acquire B. | |
| 841 | + | |
| 842 | +Let's take a look at more complicated example: | |
| 843 | + | |
| 844 | + TASK X TASK Y | |
| 845 | + ------ ------ | |
| 846 | + acquire B | |
| 847 | + release B | |
| 848 | + fork Y | |
| 849 | + acquire AX | |
| 850 | + acquire C /* A dependency 'AX -> C' exists */ | |
| 851 | + release C | |
| 852 | + release AX held by Y | |
| 853 | + | |
| 854 | + where AX, B and C are different lock classes, and a suffix 'X' is | |
| 855 | + added on crosslocks. | |
| 856 | + | |
| 857 | +Does a dependency 'AX -> B' exist? Nope. | |
| 858 | + | |
| 859 | +Two waiters are essential to create a dependency. However, waiters for | |
| 860 | +AX and B to create 'AX -> B' cannot exist at the same time in this | |
| 861 | +example. Thus the dependency 'AX -> B' cannot be created. | |
| 862 | + | |
| 863 | +It would be ideal if the full set of true ones can be considered. But | |
| 864 | +we can ensure nothing but what actually happened. Relying on what | |
| 865 | +actually happens at runtime, we can anyway add only true ones, though | |
| 866 | +they might be a subset of true ones. It's similar to how lockdep works | |
| 867 | +for typical locks. There might be more true dependencies than what | |
| 868 | +lockdep has detected in runtime. Lockdep has no choice but to rely on | |
| 869 | +what actually happens. Crossrelease also relies on it. | |
| 870 | + | |
| 871 | +CONCLUSION | |
| 872 | + | |
| 873 | +Relying on what actually happens, lockdep can avoid adding false | |
| 874 | +dependencies. | |
| @@ -97,9 +97,9 @@ waiter - A waiter is a struct that is stored on the stack of a blocked · 96 unmodified lines | ||
| 97 | 97 | a process being blocked on the mutex, it is fine to allocate |
| 98 | 98 | the waiter on the process's stack (local variable). This |
| 99 | 99 | structure holds a pointer to the task, as well as the mutex that |
| 100 | − the task is blocked on. It also has the plist node structures to | |
| 101 | − place the task in the waiter_list of a mutex as well as the | |
| 102 | − pi_list of a mutex owner task (described below). | |
| 100 | + the task is blocked on. It also has rbtree node structures to | |
| 101 | + place the task in the waiters rbtree of a mutex as well as the | |
| 102 | + pi_waiters rbtree of a mutex owner task (described below). | |
| 103 | 103 | |
| 104 | 104 | waiter is sometimes used in reference to the task that is waiting |
| 105 | 105 | on a mutex. This is the same as waiter->task. |
| @@ -179,53 +179,34 @@ again. · 73 unmodified lines | ||
| 179 | 179 | | |
| 180 | 180 | F->L5-+ |
| 181 | 181 | |
| 182 | +If process G has the highest priority in the chain, then all the tasks up | |
| 183 | +the chain (A and B in this example), must have their priorities increased | |
| 184 | +to that of G. | |
| 182 | 185 | |
| 183 | −Plist | |
| 184 | −----- | |
| 185 | − | |
| 186 | −Before I go further and talk about how the PI chain is stored through lists | |
| 187 | −on both mutexes and processes, I'll explain the plist. This is similar to | |
| 188 | −the struct list_head functionality that is already in the kernel. | |
| 189 | −The implementation of plist is out of scope for this document, but it is | |
| 190 | −very important to understand what it does. | |
| 191 | − | |
| 192 | −There are a few differences between plist and list, the most important one | |
| 193 | −being that plist is a priority sorted linked list. This means that the | |
| 194 | −priorities of the plist are sorted, such that it takes O(1) to retrieve the | |
| 195 | −highest priority item in the list. Obviously this is useful to store processes | |
| 196 | −based on their priorities. | |
| 197 | − | |
| 198 | −Another difference, which is important for implementation, is that, unlike | |
| 199 | −list, the head of the list is a different element than the nodes of a list. | |
| 200 | −So the head of the list is declared as struct plist_head and nodes that will | |
| 201 | −be added to the list are declared as struct plist_node. | |
| 202 | − | |
| 203 | − | |
| 204 | −Mutex Waiter List | |
| 186 | +Mutex Waiters Tree | |
| 205 | 187 | ----------------- |
| 206 | 188 | |
| 207 | −Every mutex keeps track of all the waiters that are blocked on itself. The mutex | |
| 208 | −has a plist to store these waiters by priority. This list is protected by | |
| 209 | −a spin lock that is located in the struct of the mutex. This lock is called | |
| 210 | −wait_lock. Since the modification of the waiter list is never done in | |
| 211 | −interrupt context, the wait_lock can be taken without disabling interrupts. | |
| 189 | +Every mutex keeps track of all the waiters that are blocked on itself. The | |
| 190 | +mutex has a rbtree to store these waiters by priority. This tree is protected | |
| 191 | +by a spin lock that is located in the struct of the mutex. This lock is called | |
| 192 | +wait_lock. | |
| 212 | 193 | |
| 213 | 194 | |
| 214 | −Task PI List | |
| 195 | +Task PI Tree | |
| 215 | 196 | ------------ |
| 216 | 197 | |
| 217 | −To keep track of the PI chains, each process has its own PI list. This is | |
| 218 | −a list of all top waiters of the mutexes that are owned by the process. | |
| 219 | −Note that this list only holds the top waiters and not all waiters that are | |
| 198 | +To keep track of the PI chains, each process has its own PI rbtree. This is | |
| 199 | +a tree of all top waiters of the mutexes that are owned by the process. | |
| 200 | +Note that this tree only holds the top waiters and not all waiters that are | |
| 220 | 201 | blocked on mutexes owned by the process. |
| 221 | 202 | |
| 222 | −The top of the task's PI list is always the highest priority task that | |
| 203 | +The top of the task's PI tree is always the highest priority task that | |
| 223 | 204 | is waiting on a mutex that is owned by the task. So if the task has |
| 224 | 205 | inherited a priority, it will always be the priority of the task that is |
| 225 | −at the top of this list. | |
| 206 | +at the top of this tree. | |
| 226 | 207 | |
| 227 | −This list is stored in the task structure of a process as a plist called | |
| 228 | −pi_list. This list is protected by a spin lock also in the task structure, | |
| 208 | +This tree is stored in the task structure of a process as a rbtree called | |
| 209 | +pi_waiters. It is protected by a spin lock also in the task structure, | |
| 229 | 210 | called pi_lock. This lock may also be taken in interrupt context, so when |
| 230 | 211 | locking the pi_lock, interrupts must be disabled. |
| 231 | 212 | |
| @@ -312,15 +293,12 @@ Mutex owner and flags · 80 unmodified lines | ||
| 312 | 293 | |
| 313 | 294 | The mutex structure contains a pointer to the owner of the mutex. If the |
| 314 | 295 | mutex is not owned, this owner is set to NULL. Since all architectures |
| 315 | −have the task structure on at least a four byte alignment (and if this is | |
| 316 | −not true, the rtmutex.c code will be broken!), this allows for the two | |
| 317 | −least significant bits to be used as flags. This part is also described | |
| 318 | −in Documentation/rt-mutex.txt, but will also be briefly described here. | |
| 319 | − | |
| 320 | −Bit 0 is used as the "Pending Owner" flag. This is described later. | |
| 321 | −Bit 1 is used as the "Has Waiters" flags. This is also described later | |
| 322 | − in more detail, but is set whenever there are waiters on a mutex. | |
| 296 | +have the task structure on at least a two byte alignment (and if this is | |
| 297 | +not true, the rtmutex.c code will be broken!), this allows for the least | |
| 298 | +significant bit to be used as a flag. Bit 0 is used as the "Has Waiters" | |
| 299 | +flag. It's set whenever there are waiters on a mutex. | |
| 323 | 300 | |
| 301 | +See Documentation/locking/rt-mutex.txt for further details. | |
| 324 | 302 | |
| 325 | 303 | cmpxchg Tricks |
| 326 | 304 | -------------- |
| @@ -359,40 +337,31 @@ Priority adjustments · 32 unmodified lines | ||
| 359 | 337 | -------------------- |
| 360 | 338 | |
| 361 | 339 | The implementation of the PI code in rtmutex.c has several places that a |
| 362 | −process must adjust its priority. With the help of the pi_list of a | |
| 340 | +process must adjust its priority. With the help of the pi_waiters of a | |
| 363 | 341 | process this is rather easy to know what needs to be adjusted. |
| 364 | 342 | |
| 365 | −The functions implementing the task adjustments are rt_mutex_adjust_prio, | |
| 366 | −__rt_mutex_adjust_prio (same as the former, but expects the task pi_lock | |
| 367 | −to already be taken), rt_mutex_getprio, and rt_mutex_setprio. | |
| 343 | +The functions implementing the task adjustments are rt_mutex_adjust_prio | |
| 344 | +and rt_mutex_setprio. rt_mutex_setprio is only used in rt_mutex_adjust_prio. | |
| 368 | 345 | |
| 369 | −rt_mutex_getprio and rt_mutex_setprio are only used in __rt_mutex_adjust_prio. | |
| 346 | +rt_mutex_adjust_prio examines the priority of the task, and the highest | |
| 347 | +priority process that is waiting any of mutexes owned by the task. Since | |
| 348 | +the pi_waiters of a task holds an order by priority of all the top waiters | |
| 349 | +of all the mutexes that the task owns, we simply need to compare the top | |
| 350 | +pi waiter to its own normal/deadline priority and take the higher one. | |
| 351 | +Then rt_mutex_setprio is called to adjust the priority of the task to the | |
| 352 | +new priority. Note that rt_mutex_setprio is defined in kernel/sched/core.c | |
| 353 | +to implement the actual change in priority. | |
| 370 | 354 | |
| 371 | −rt_mutex_getprio returns the priority that the task should have. Either the | |
| 372 | −task's own normal priority, or if a process of a higher priority is waiting on | |
| 373 | −a mutex owned by the task, then that higher priority should be returned. | |
| 374 | −Since the pi_list of a task holds an order by priority list of all the top | |
| 375 | −waiters of all the mutexes that the task owns, rt_mutex_getprio simply needs | |
| 376 | −to compare the top pi waiter to its own normal priority, and return the higher | |
| 377 | −priority back. | |
| 355 | +(Note: For the "prio" field in task_struct, the lower the number, the | |
| 356 | + higher the priority. A "prio" of 5 is of higher priority than a | |
| 357 | + "prio" of 10.) | |
| 378 | 358 | |
| 379 | −(Note: if looking at the code, you will notice that the lower number of | |
| 380 | − prio is returned. This is because the prio field in the task structure | |
| 381 | − is an inverse order of the actual priority. So a "prio" of 5 is | |
| 382 | − of higher priority than a "prio" of 10.) | |
| 383 | − | |
| 384 | −__rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the | |
| 385 | −result does not equal the task's current priority, then rt_mutex_setprio | |
| 386 | −is called to adjust the priority of the task to the new priority. | |
| 387 | −Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the | |
| 388 | −actual change in priority. | |
| 389 | − | |
| 390 | −It is interesting to note that __rt_mutex_adjust_prio can either increase | |
| 359 | +It is interesting to note that rt_mutex_adjust_prio can either increase | |
| 391 | 360 | or decrease the priority of the task. In the case that a higher priority |
| 392 | −process has just blocked on a mutex owned by the task, __rt_mutex_adjust_prio | |
| 361 | +process has just blocked on a mutex owned by the task, rt_mutex_adjust_prio | |
| 393 | 362 | would increase/boost the task's priority. But if a higher priority task |
| 394 | 363 | were for some reason to leave the mutex (timeout or signal), this same function |
| 395 | −would decrease/unboost the priority of the task. That is because the pi_list | |
| 364 | +would decrease/unboost the priority of the task. That is because the pi_waiters | |
| 396 | 365 | always contains the highest priority task that is waiting on a mutex owned |
| 397 | 366 | by the task, so we only need to compare the priority of that top pi waiter |
| 398 | 367 | to the normal priority of the given task. |
| @@ -412,9 +381,10 @@ priorities. · 13 unmodified lines | ||
| 412 | 381 | |
| 413 | 382 | rt_mutex_adjust_prio_chain is called with a task to be checked for PI |
| 414 | 383 | (de)boosting (the owner of a mutex that a process is blocking on), a flag to |
| 415 | −check for deadlocking, the mutex that the task owns, and a pointer to a waiter | |
| 384 | +check for deadlocking, the mutex that the task owns, a pointer to a waiter | |
| 416 | 385 | that is the process's waiter struct that is blocked on the mutex (although this |
| 417 | −parameter may be NULL for deboosting). | |
| 386 | +parameter may be NULL for deboosting), a pointer to the mutex on which the task | |
| 387 | +is blocked, and a top_task as the top waiter of the mutex. | |
| 418 | 388 | |
| 419 | 389 | For this explanation, I will not mention deadlock detection. This explanation |
| 420 | 390 | will try to stay at a high level. |
| @@ -424,133 +394,14 @@ that the state of the owner and lock can change when entered into this function. · 3 unmodified lines | ||
| 424 | 394 | |
| 425 | 395 | Before this function is called, the task has already had rt_mutex_adjust_prio |
| 426 | 396 | performed on it. This means that the task is set to the priority that it |
| 427 | −should be at, but the plist nodes of the task's waiter have not been updated | |
| 428 | −with the new priorities, and that this task may not be in the proper locations | |
| 429 | −in the pi_lists and wait_lists that the task is blocked on. This function | |
| 397 | +should be at, but the rbtree nodes of the task's waiter have not been updated | |
| 398 | +with the new priorities, and this task may not be in the proper locations | |
| 399 | +in the pi_waiters and waiters trees that the task is blocked on. This function | |
| 430 | 400 | solves all that. |
| 431 | 401 | |
| 432 | −A loop is entered, where task is the owner to be checked for PI changes that | |
| 433 | −was passed by parameter (for the first iteration). The pi_lock of this task is | |
| 434 | −taken to prevent any more changes to the pi_list of the task. This also | |
| 435 | −prevents new tasks from completing the blocking on a mutex that is owned by this | |
| 436 | −task. | |
| 437 | − | |
| 438 | −If the task is not blocked on a mutex then the loop is exited. We are at | |
| 439 | −the top of the PI chain. | |
| 440 | − | |
| 441 | −A check is now done to see if the original waiter (the process that is blocked | |
| 442 | −on the current mutex) is the top pi waiter of the task. That is, is this | |
| 443 | −waiter on the top of the task's pi_list. If it is not, it either means that | |
| 444 | −there is another process higher in priority that is blocked on one of the | |
| 445 | −mutexes that the task owns, or that the waiter has just woken up via a signal | |
| 446 | −or timeout and has left the PI chain. In either case, the loop is exited, since | |
| 447 | −we don't need to do any more changes to the priority of the current task, or any | |
| 448 | −task that owns a mutex that this current task is waiting on. A priority chain | |
| 449 | −walk is only needed when a new top pi waiter is made to a task. | |
| 450 | − | |
| 451 | −The next check sees if the task's waiter plist node has the priority equal to | |
| 452 | −the priority the task is set at. If they are equal, then we are done with | |
| 453 | −the loop. Remember that the function started with the priority of the | |
| 454 | −task adjusted, but the plist nodes that hold the task in other processes | |
| 455 | −pi_lists have not been adjusted. | |
| 456 | − | |
| 457 | −Next, we look at the mutex that the task is blocked on. The mutex's wait_lock | |
| 458 | −is taken. This is done by a spin_trylock, because the locking order of the | |
| 459 | −pi_lock and wait_lock goes in the opposite direction. If we fail to grab the | |
| 460 | −lock, the pi_lock is released, and we restart the loop. | |
| 461 | − | |
| 462 | −Now that we have both the pi_lock of the task as well as the wait_lock of | |
| 463 | −the mutex the task is blocked on, we update the task's waiter's plist node | |
| 464 | −that is located on the mutex's wait_list. | |
| 465 | − | |
| 466 | −Now we release the pi_lock of the task. | |
| 467 | − | |
| 468 | −Next the owner of the mutex has its pi_lock taken, so we can update the | |
| 469 | −task's entry in the owner's pi_list. If the task is the highest priority | |
| 470 | −process on the mutex's wait_list, then we remove the previous top waiter | |
| 471 | −from the owner's pi_list, and replace it with the task. | |
| 472 | − | |
| 473 | −Note: It is possible that the task was the current top waiter on the mutex, | |
| 474 | − in which case the task is not yet on the pi_list of the waiter. This | |
| 475 | − is OK, since plist_del does nothing if the plist node is not on any | |
| 476 | − list. | |
| 477 | − | |
| 478 | −If the task was not the top waiter of the mutex, but it was before we | |
| 479 | −did the priority updates, that means we are deboosting/lowering the | |
| 480 | −task. In this case, the task is removed from the pi_list of the owner, | |
| 481 | −and the new top waiter is added. | |
| 482 | − | |
| 483 | −Lastly, we unlock both the pi_lock of the task, as well as the mutex's | |
| 484 | −wait_lock, and continue the loop again. On the next iteration of the | |
| 485 | −loop, the previous owner of the mutex will be the task that will be | |
| 486 | −processed. | |
| 487 | − | |
| 488 | −Note: One might think that the owner of this mutex might have changed | |
| 489 | − since we just grab the mutex's wait_lock. And one could be right. | |
| 490 | − The important thing to remember is that the owner could not have | |
| 491 | − become the task that is being processed in the PI chain, since | |
| 492 | − we have taken that task's pi_lock at the beginning of the loop. | |
| 493 | − So as long as there is an owner of this mutex that is not the same | |
| 494 | − process as the tasked being worked on, we are OK. | |
| 495 | − | |
| 496 | − Looking closely at the code, one might be confused. The check for the | |
| 497 | − end of the PI chain is when the task isn't blocked on anything or the | |
| 498 | − task's waiter structure "task" element is NULL. This check is | |
| 499 | − protected only by the task's pi_lock. But the code to unlock the mutex | |
| 500 | − sets the task's waiter structure "task" element to NULL with only | |
| 501 | − the protection of the mutex's wait_lock, which was not taken yet. | |
| 502 | − Isn't this a race condition if the task becomes the new owner? | |
| 503 | − | |
| 504 | − The answer is No! The trick is the spin_trylock of the mutex's | |
| 505 | − wait_lock. If we fail that lock, we release the pi_lock of the | |
| 506 | − task and continue the loop, doing the end of PI chain check again. | |
| 507 | − | |
| 508 | − In the code to release the lock, the wait_lock of the mutex is held | |
| 509 | − the entire time, and it is not let go when we grab the pi_lock of the | |
| 510 | − new owner of the mutex. So if the switch of a new owner were to happen | |
| 511 | − after the check for end of the PI chain and the grabbing of the | |
| 512 | − wait_lock, the unlocking code would spin on the new owner's pi_lock | |
| 513 | − but never give up the wait_lock. So the PI chain loop is guaranteed to | |
| 514 | − fail the spin_trylock on the wait_lock, release the pi_lock, and | |
| 515 | − try again. | |
| 516 | − | |
| 517 | − If you don't quite understand the above, that's OK. You don't have to, | |
| 518 | − unless you really want to make a proof out of it ;) | |
| 519 | − | |
| 520 | − | |
| 521 | −Pending Owners and Lock stealing | |
| 522 | −-------------------------------- | |
| 523 | − | |
| 524 | −One of the flags in the owner field of the mutex structure is "Pending Owner". | |
| 525 | −What this means is that an owner was chosen by the process releasing the | |
| 526 | −mutex, but that owner has yet to wake up and actually take the mutex. | |
| 527 | − | |
| 528 | −Why is this important? Why can't we just give the mutex to another process | |
| 529 | −and be done with it? | |
| 530 | − | |
| 531 | −The PI code is to help with real-time processes, and to let the highest | |
| 532 | −priority process run as long as possible with little latencies and delays. | |
| 533 | −If a high priority process owns a mutex that a lower priority process is | |
| 534 | −blocked on, when the mutex is released it would be given to the lower priority | |
| 535 | −process. What if the higher priority process wants to take that mutex again. | |
| 536 | −The high priority process would fail to take that mutex that it just gave up | |
| 537 | −and it would need to boost the lower priority process to run with full | |
| 538 | −latency of that critical section (since the low priority process just entered | |
| 539 | −it). | |
| 540 | − | |
| 541 | −There's no reason a high priority process that gives up a mutex should be | |
| 542 | −penalized if it tries to take that mutex again. If the new owner of the | |
| 543 | −mutex has not woken up yet, there's no reason that the higher priority process | |
| 544 | −could not take that mutex away. | |
| 545 | − | |
| 546 | −To solve this, we introduced Pending Ownership and Lock Stealing. When a | |
| 547 | −new process is given a mutex that it was blocked on, it is only given | |
| 548 | −pending ownership. This means that it's the new owner, unless a higher | |
| 549 | −priority process comes in and tries to grab that mutex. If a higher priority | |
| 550 | −process does come along and wants that mutex, we let the higher priority | |
| 551 | −process "steal" the mutex from the pending owner (only if it is still pending) | |
| 552 | −and continue with the mutex. | |
| 553 | − | |
| 402 | +The main operation of this function is summarized by Thomas Gleixner in | |
| 403 | +rtmutex.c. See the 'Chain walk basics and protection scope' comment for further | |
| 404 | +details. | |
| 554 | 405 | |
| 555 | 406 | Taking of a mutex (The walk through) |
| 556 | 407 | ------------------------------------ |
| @@ -563,14 +414,14 @@ done when we have CMPXCHG enabled (otherwise the fast taking automatically · 6 unmodified lines | ||
| 563 | 414 | fails). Only when the owner field of the mutex is NULL can the lock be |
| 564 | 415 | taken with the CMPXCHG and nothing else needs to be done. |
| 565 | 416 | |
| 566 | −If there is contention on the lock, whether it is owned or pending owner | |
| 567 | −we go about the slow path (rt_mutex_slowlock). | |
| 417 | +If there is contention on the lock, we go about the slow path | |
| 418 | +(rt_mutex_slowlock). | |
| 568 | 419 | |
| 569 | 420 | The slow path function is where the task's waiter structure is created on |
| 570 | 421 | the stack. This is because the waiter structure is only needed for the |
| 571 | 422 | scope of this function. The waiter structure holds the nodes to store |
| 572 | −the task on the wait_list of the mutex, and if need be, the pi_list of | |
| 573 | −the owner. | |
| 423 | +the task on the waiters tree of the mutex, and if need be, the pi_waiters | |
| 424 | +tree of the owner. | |
| 574 | 425 | |
| 575 | 426 | The wait_lock of the mutex is taken since the slow path of unlocking the |
| 576 | 427 | mutex also takes this lock. |
| @@ -581,102 +432,45 @@ contention). · 4 unmodified lines | ||
| 581 | 432 | |
| 582 | 433 | try_to_take_rt_mutex is used every time the task tries to grab a mutex in the |
| 583 | 434 | slow path. The first thing that is done here is an atomic setting of |
| 584 | −the "Has Waiters" flag of the mutex's owner field. Yes, this could really | |
| 585 | −be false, because if the mutex has no owner, there are no waiters and | |
| 586 | −the current task also won't have any waiters. But we don't have the lock | |
| 587 | −yet, so we assume we are going to be a waiter. The reason for this is to | |
| 588 | −play nice for those architectures that do have CMPXCHG. By setting this flag | |
| 589 | −now, the owner of the mutex can't release the mutex without going into the | |
| 590 | −slow unlock path, and it would then need to grab the wait_lock, which this | |
| 591 | −code currently holds. So setting the "Has Waiters" flag forces the owner | |
| 592 | −to synchronize with this code. | |
| 593 | − | |
| 594 | −Now that we know that we can't have any races with the owner releasing the | |
| 595 | −mutex, we check to see if we can take the ownership. This is done if the | |
| 596 | −mutex doesn't have a owner, or if we can steal the mutex from a pending | |
| 597 | −owner. Let's look at the situations we have here. | |
| 598 | − | |
| 599 | − 1) Has owner that is pending | |
| 600 | − ---------------------------- | |
| 601 | − | |
| 602 | − The mutex has a owner, but it hasn't woken up and the mutex flag | |
| 603 | − "Pending Owner" is set. The first check is to see if the owner isn't the | |
| 604 | − current task. This is because this function is also used for the pending | |
| 605 | − owner to grab the mutex. When a pending owner wakes up, it checks to see | |
| 606 | − if it can take the mutex, and this is done if the owner is already set to | |
| 607 | − itself. If so, we succeed and leave the function, clearing the "Pending | |
| 608 | − Owner" bit. | |
| 609 | − | |
| 610 | − If the pending owner is not current, we check to see if the current priority is | |
| 611 | − higher than the pending owner. If not, we fail the function and return. | |
| 612 | − | |
| 613 | − There's also something special about a pending owner. That is a pending owner | |
| 614 | − is never blocked on a mutex. So there is no PI chain to worry about. It also | |
| 615 | − means that if the mutex doesn't have any waiters, there's no accounting needed | |
| 616 | − to update the pending owner's pi_list, since we only worry about processes | |
| 617 | − blocked on the current mutex. | |
| 618 | − | |
| 619 | − If there are waiters on this mutex, and we just stole the ownership, we need | |
| 620 | − to take the top waiter, remove it from the pi_list of the pending owner, and | |
| 621 | − add it to the current pi_list. Note that at this moment, the pending owner | |
| 622 | − is no longer on the list of waiters. This is fine, since the pending owner | |
| 623 | − would add itself back when it realizes that it had the ownership stolen | |
| 624 | − from itself. When the pending owner tries to grab the mutex, it will fail | |
| 625 | − in try_to_take_rt_mutex if the owner field points to another process. | |
| 626 | − | |
| 627 | − 2) No owner | |
| 628 | − ----------- | |
| 629 | − | |
| 630 | − If there is no owner (or we successfully stole the lock), we set the owner | |
| 631 | − of the mutex to current, and set the flag of "Has Waiters" if the current | |
| 632 | − mutex actually has waiters, or we clear the flag if it doesn't. See, it was | |
| 633 | − OK that we set that flag early, since now it is cleared. | |
| 634 | − | |
| 635 | − 3) Failed to grab ownership | |
| 636 | − --------------------------- | |
| 637 | − | |
| 638 | − The most interesting case is when we fail to take ownership. This means that | |
| 639 | − there exists an owner, or there's a pending owner with equal or higher | |
| 640 | − priority than the current task. | |
| 641 | − | |
| 642 | −We'll continue on the failed case. | |
| 643 | − | |
| 644 | −If the mutex has a timeout, we set up a timer to go off to break us out | |
| 645 | −of this mutex if we failed to get it after a specified amount of time. | |
| 646 | − | |
| 647 | −Now we enter a loop that will continue to try to take ownership of the mutex, or | |
| 648 | −fail from a timeout or signal. | |
| 649 | − | |
| 650 | −Once again we try to take the mutex. This will usually fail the first time | |
| 651 | −in the loop, since it had just failed to get the mutex. But the second time | |
| 652 | −in the loop, this would likely succeed, since the task would likely be | |
| 653 | −the pending owner. | |
| 654 | − | |
| 655 | −If the mutex is TASK_INTERRUPTIBLE a check for signals and timeout is done | |
| 656 | −here. | |
| 657 | − | |
| 658 | −The waiter structure has a "task" field that points to the task that is blocked | |
| 659 | −on the mutex. This field can be NULL the first time it goes through the loop | |
| 660 | −or if the task is a pending owner and had its mutex stolen. If the "task" | |
| 661 | −field is NULL then we need to set up the accounting for it. | |
| 435 | +the "Has Waiters" flag of the mutex's owner field. By setting this flag | |
| 436 | +now, the current owner of the mutex being contended for can't release the mutex | |
| 437 | +without going into the slow unlock path, and it would then need to grab the | |
| 438 | +wait_lock, which this code currently holds. So setting the "Has Waiters" flag | |
| 439 | +forces the current owner to synchronize with this code. | |
| 440 | + | |
| 441 | +The lock is taken if the following are true: | |
| 442 | + 1) The lock has no owner | |
| 443 | + 2) The current task is the highest priority against all other | |
| 444 | + waiters of the lock | |
| 445 | + | |
| 446 | +If the task succeeds to acquire the lock, then the task is set as the | |
| 447 | +owner of the lock, and if the lock still has waiters, the top_waiter | |
| 448 | +(highest priority task waiting on the lock) is added to this task's | |
| 449 | +pi_waiters tree. | |
| 450 | + | |
| 451 | +If the lock is not taken by try_to_take_rt_mutex(), then the | |
| 452 | +task_blocks_on_rt_mutex() function is called. This will add the task to | |
| 453 | +the lock's waiter tree and propagate the pi chain of the lock as well | |
| 454 | +as the lock's owner's pi_waiters tree. This is described in the next | |
| 455 | +section. | |
| 662 | 456 | |
| 663 | 457 | Task blocks on mutex |
| 664 | 458 | -------------------- |
| 665 | 459 | |
| 666 | 460 | The accounting of a mutex and process is done with the waiter structure of |
| 667 | 461 | the process. The "task" field is set to the process, and the "lock" field |
| 668 | −to the mutex. The plist nodes are initialized to the processes current | |
| 669 | −priority. | |
| 462 | +to the mutex. The rbtree node of waiter are initialized to the processes | |
| 463 | +current priority. | |
| 670 | 464 | |
| 671 | 465 | Since the wait_lock was taken at the entry of the slow lock, we can safely |
| 672 | −add the waiter to the wait_list. If the current process is the highest | |
| 673 | −priority process currently waiting on this mutex, then we remove the | |
| 674 | −previous top waiter process (if it exists) from the pi_list of the owner, | |
| 675 | −and add the current process to that list. Since the pi_list of the owner | |
| 466 | +add the waiter to the task waiter tree. If the current process is the | |
| 467 | +highest priority process currently waiting on this mutex, then we remove the | |
| 468 | +previous top waiter process (if it exists) from the pi_waiters of the owner, | |
| 469 | +and add the current process to that tree. Since the pi_waiter of the owner | |
| 676 | 470 | has changed, we call rt_mutex_adjust_prio on the owner to see if the owner |
| 677 | 471 | should adjust its priority accordingly. |
| 678 | 472 | |
| 679 | −If the owner is also blocked on a lock, and had its pi_list changed | |
| 473 | +If the owner is also blocked on a lock, and had its pi_waiters changed | |
| 680 | 474 | (or deadlock checking is on), we unlock the wait_lock of the mutex and go ahead |
| 681 | 475 | and run rt_mutex_adjust_prio_chain on the owner, as described earlier. |
| 682 | 476 | |
| @@ -686,30 +480,23 @@ mutex (waiter "task" field is not NULL), then we go to sleep (call schedule). · 3 unmodified lines | ||
| 686 | 480 | Waking up in the loop |
| 687 | 481 | --------------------- |
| 688 | 482 | |
| 689 | −The schedule can then wake up for a few reasons. | |
| 690 | − 1) we were given pending ownership of the mutex. | |
| 691 | − 2) we received a signal and was TASK_INTERRUPTIBLE | |
| 692 | − 3) we had a timeout and was TASK_INTERRUPTIBLE | |
| 483 | +The task can then wake up for a couple of reasons: | |
| 484 | + 1) The previous lock owner released the lock, and the task now is top_waiter | |
| 485 | + 2) we received a signal or timeout | |
| 693 | 486 | |
| 694 | −In any of these cases, we continue the loop and once again try to grab the | |
| 695 | −ownership of the mutex. If we succeed, we exit the loop, otherwise we continue | |
| 696 | −and on signal and timeout, will exit the loop, or if we had the mutex stolen | |
| 697 | −we just simply add ourselves back on the lists and go back to sleep. | |
| 487 | +In both cases, the task will try again to acquire the lock. If it | |
| 488 | +does, then it will take itself off the waiters tree and set itself back | |
| 489 | +to the TASK_RUNNING state. | |
| 698 | 490 | |
| 699 | −Note: For various reasons, because of timeout and signals, the steal mutex | |
| 700 | − algorithm needs to be careful. This is because the current process is | |
| 701 | − still on the wait_list. And because of dynamic changing of priorities, | |
| 702 | − especially on SCHED_OTHER tasks, the current process can be the | |
| 703 | − highest priority task on the wait_list. | |
| 704 | − | |
| 705 | −Failed to get mutex on Timeout or Signal | |
| 706 | −---------------------------------------- | |
| 491 | +In first case, if the lock was acquired by another task before this task | |
| 492 | +could get the lock, then it will go back to sleep and wait to be woken again. | |
| 707 | 493 | |
| 708 | −If a timeout or signal occurred, the waiter's "task" field would not be | |
| 709 | −NULL and the task needs to be taken off the wait_list of the mutex and perhaps | |
| 710 | −pi_list of the owner. If this process was a high priority process, then | |
| 711 | −the rt_mutex_adjust_prio_chain needs to be executed again on the owner, | |
| 712 | −but this time it will be lowering the priorities. | |
| 494 | +The second case is only applicable for tasks that are grabbing a mutex | |
| 495 | +that can wake up before getting the lock, either due to a signal or | |
| 496 | +a timeout (i.e. rt_mutex_timed_futex_lock()). When woken, it will try to | |
| 497 | +take the lock again, if it succeeds, then the task will return with the | |
| 498 | +lock held, otherwise it will return with -EINTR if the task was woken | |
| 499 | +by a signal, or -ETIMEDOUT if it timed out. | |
| 713 | 500 | |
| 714 | 501 | |
| 715 | 502 | Unlocking the Mutex |
| @@ -739,25 +526,12 @@ owner still needs to make this check. If there are no waiters then the mutex · 23 unmodified lines | ||
| 739 | 526 | owner field is set to NULL, the wait_lock is released and nothing more is |
| 740 | 527 | needed. |
| 741 | 528 | |
| 742 | −If there are waiters, then we need to wake one up and give that waiter | |
| 743 | −pending ownership. | |
| 529 | +If there are waiters, then we need to wake one up. | |
| 744 | 530 | |
| 745 | 531 | On the wake up code, the pi_lock of the current owner is taken. The top |
| 746 | −waiter of the lock is found and removed from the wait_list of the mutex | |
| 747 | −as well as the pi_list of the current owner. The task field of the new | |
| 748 | −pending owner's waiter structure is set to NULL, and the owner field of the | |
| 749 | −mutex is set to the new owner with the "Pending Owner" bit set, as well | |
| 750 | −as the "Has Waiters" bit if there still are other processes blocked on the | |
| 751 | −mutex. | |
| 752 | − | |
| 753 | −The pi_lock of the previous owner is released, and the new pending owner's | |
| 754 | −pi_lock is taken. Remember that this is the trick to prevent the race | |
| 755 | −condition in rt_mutex_adjust_prio_chain from adding itself as a waiter | |
| 756 | −on the mutex. | |
| 757 | − | |
| 758 | −We now clear the "pi_blocked_on" field of the new pending owner, and if | |
| 759 | −the mutex still has waiters pending, we add the new top waiter to the pi_list | |
| 760 | −of the pending owner. | |
| 532 | +waiter of the lock is found and removed from the waiters tree of the mutex | |
| 533 | +as well as the pi_waiters tree of the current owner. The "Has Waiters" bit is | |
| 534 | +marked to prevent lower priority tasks from stealing the lock. | |
| 761 | 535 | |
| 762 | 536 | Finally we unlock the pi_lock of the pending owner and wake it up. |
| 763 | 537 | |
| @@ -772,10 +546,14 @@ Credits · 8 unmodified lines | ||
| 772 | 546 | ------- |
| 773 | 547 | |
| 774 | 548 | Author: Steven Rostedt <rostedt@goodmis.org> |
| 549 | +Updated: Alex Shi <alex.shi@linaro.org> - 7/6/2017 | |
| 775 | 550 | |
| 776 | −Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap | |
| 551 | +Original Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and | |
| 552 | + Randy Dunlap | |
| 553 | +Update (7/6/2017) Reviewers: Steven Rostedt and Sebastian Siewior | |
| 777 | 554 | |
| 778 | 555 | Updates |
| 779 | 556 | ------- |
| 780 | 557 | |
| 781 | 558 | This document was originally written for 2.6.17-rc3-mm1 |
| 559 | +was updated on 4.12 | |
| @@ -28,14 +28,13 @@ magic bullet for poorly designed applications, but it allows · 27 unmodified lines | ||
| 28 | 28 | well-designed applications to use userspace locks in critical parts of |
| 29 | 29 | an high priority thread, without losing determinism. |
| 30 | 30 | |
| 31 | −The enqueueing of the waiters into the rtmutex waiter list is done in | |
| 31 | +The enqueueing of the waiters into the rtmutex waiter tree is done in | |
| 32 | 32 | priority order. For same priorities FIFO order is chosen. For each |
| 33 | 33 | rtmutex, only the top priority waiter is enqueued into the owner's |
| 34 | −priority waiters list. This list too queues in priority order. Whenever | |
| 34 | +priority waiters tree. This tree too queues in priority order. Whenever | |
| 35 | 35 | the top priority waiter of a task changes (for example it timed out or |
| 36 | −got a signal), the priority of the owner task is readjusted. [The | |
| 37 | −priority enqueueing is handled by "plists", see include/linux/plist.h | |
| 38 | −for more details.] | |
| 36 | +got a signal), the priority of the owner task is readjusted. The | |
| 37 | +priority enqueueing is handled by "pi_waiters". | |
| 39 | 38 | |
| 40 | 39 | RT-mutexes are optimized for fastpath operations and have no internal |
| 41 | 40 | locking overhead when locking an uncontended mutex or unlocking a mutex |
| @@ -46,34 +45,29 @@ is used] · 4 unmodified lines | ||
| 46 | 45 | The state of the rt-mutex is tracked via the owner field of the rt-mutex |
| 47 | 46 | structure: |
| 48 | 47 | |
| 49 | −rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1 | |
| 50 | −are used to keep track of the "owner is pending" and "rtmutex has | |
| 51 | −waiters" state. | |
| 48 | +lock->owner holds the task_struct pointer of the owner. Bit 0 is used to | |
| 49 | +keep track of the "lock has waiters" state. | |
| 52 | 50 | |
| 53 | − owner bit1 bit0 | |
| 54 | − NULL 0 0 mutex is free (fast acquire possible) | |
| 55 | − NULL 0 1 invalid state | |
| 56 | − NULL 1 0 Transitional state* | |
| 57 | − NULL 1 1 invalid state | |
| 58 | − taskpointer 0 0 mutex is held (fast release possible) | |
| 59 | − taskpointer 0 1 task is pending owner | |
| 60 | − taskpointer 1 0 mutex is held and has waiters | |
| 61 | − taskpointer 1 1 task is pending owner and mutex has waiters | |
| 51 | + owner bit0 | |
| 52 | + NULL 0 lock is free (fast acquire possible) | |
| 53 | + NULL 1 lock is free and has waiters and the top waiter | |
| 54 | + is going to take the lock* | |
| 55 | + taskpointer 0 lock is held (fast release possible) | |
| 56 | + taskpointer 1 lock is held and has waiters** | |
| 62 | 57 | |
| 63 | −Pending-ownership handling is a performance optimization: | |
| 64 | −pending-ownership is assigned to the first (highest priority) waiter of | |
| 65 | −the mutex, when the mutex is released. The thread is woken up and once | |
| 66 | −it starts executing it can acquire the mutex. Until the mutex is taken | |
| 67 | −by it (bit 0 is cleared) a competing higher priority thread can "steal" | |
| 68 | −the mutex which puts the woken up thread back on the waiters list. | |
| 58 | +The fast atomic compare exchange based acquire and release is only | |
| 59 | +possible when bit 0 of lock->owner is 0. | |
| 69 | 60 | |
| 70 | −The pending-ownership optimization is especially important for the | |
| 71 | −uninterrupted workflow of high-prio tasks which repeatedly | |
| 72 | −takes/releases locks that have lower-prio waiters. Without this | |
| 73 | −optimization the higher-prio thread would ping-pong to the lower-prio | |
| 74 | −task [because at unlock time we always assign a new owner]. | |
| 61 | +(*) It also can be a transitional state when grabbing the lock | |
| 62 | +with ->wait_lock is held. To prevent any fast path cmpxchg to the lock, | |
| 63 | +we need to set the bit0 before looking at the lock, and the owner may be | |
| 64 | +NULL in this small time, hence this can be a transitional state. | |
| 75 | 65 | |
| 76 | −(*) The "mutex has waiters" bit gets set to take the lock. If the lock | |
| 77 | −doesn't already have an owner, this bit is quickly cleared if there are | |
| 78 | −no waiters. So this is a transitional state to synchronize with looking | |
| 79 | −at the owner field of the mutex and the mutex owner releasing the lock. | |
| 66 | +(**) There is a small time when bit 0 is set but there are no | |
| 67 | +waiters. This can happen when grabbing the lock in the slow path. | |
| 68 | +To prevent a cmpxchg of the owner releasing the lock, we need to | |
| 69 | +set this bit before looking at the lock. | |
| 70 | + | |
| 71 | +BTW, there is still technically a "Pending Owner", it's just not called | |
| 72 | +that anymore. The pending owner happens to be the top_waiter of a lock | |
| 73 | +that has no owner and has been woken up to grab the lock. | |
| @@ -498,11 +498,11 @@ And a couple of implicit varieties: · 497 unmodified lines | ||
| 498 | 498 | This means that ACQUIRE acts as a minimal "acquire" operation and |
| 499 | 499 | RELEASE acts as a minimal "release" operation. |
| 500 | 500 | |
| 501 | −A subset of the atomic operations described in core-api/atomic_ops.rst have | |
| 502 | −ACQUIRE and RELEASE variants in addition to fully-ordered and relaxed (no | |
| 503 | −barrier semantics) definitions. For compound atomics performing both a load | |
| 504 | −and a store, ACQUIRE semantics apply only to the load and RELEASE semantics | |
| 505 | −apply only to the store portion of the operation. | |
| 501 | +A subset of the atomic operations described in atomic_t.txt have ACQUIRE and | |
| 502 | +RELEASE variants in addition to fully-ordered and relaxed (no barrier | |
| 503 | +semantics) definitions. For compound atomics performing both a load and a | |
| 504 | +store, ACQUIRE semantics apply only to the load and RELEASE semantics apply | |
| 505 | +only to the store portion of the operation. | |
| 506 | 506 | |
| 507 | 507 | Memory barriers are only required where there's a possibility of interaction |
| 508 | 508 | between two CPUs or between a CPU and a device. If it can be guaranteed that |
| @@ -594,7 +594,24 @@ between the address load and the data load: · 85 unmodified lines | ||
| 594 | 594 | This enforces the occurrence of one of the two implications, and prevents the |
| 595 | 595 | third possibility from arising. |
| 596 | 596 | |
| 597 | −A data-dependency barrier must also order against dependent writes: | |
| 597 | + | |
| 598 | +[!] Note that this extremely counterintuitive situation arises most easily on | |
| 599 | +machines with split caches, so that, for example, one cache bank processes | |
| 600 | +even-numbered cache lines and the other bank processes odd-numbered cache | |
| 601 | +lines. The pointer P might be stored in an odd-numbered cache line, and the | |
| 602 | +variable B might be stored in an even-numbered cache line. Then, if the | |
| 603 | +even-numbered bank of the reading CPU's cache is extremely busy while the | |
| 604 | +odd-numbered bank is idle, one can see the new value of the pointer P (&B), | |
| 605 | +but the old value of the variable B (2). | |
| 606 | + | |
| 607 | + | |
| 608 | +A data-dependency barrier is not required to order dependent writes | |
| 609 | +because the CPUs that the Linux kernel supports don't do writes | |
| 610 | +until they are certain (1) that the write will actually happen, (2) | |
| 611 | +of the location of the write, and (3) of the value to be written. | |
| 612 | +But please carefully read the "CONTROL DEPENDENCIES" section and the | |
| 613 | +Documentation/RCU/rcu_dereference.txt file: The compiler can and does | |
| 614 | +break dependencies in a great many highly creative ways. | |
| 598 | 615 | |
| 599 | 616 | CPU 1 CPU 2 |
| 600 | 617 | =============== =============== |
| @@ -603,29 +620,19 @@ A data-dependency barrier must also order against dependent writes: · 2 unmodified lines | ||
| 603 | 620 | <write barrier> |
| 604 | 621 | WRITE_ONCE(P, &B); |
| 605 | 622 | Q = READ_ONCE(P); |
| 606 | − <data dependency barrier> | |
| 607 | − *Q = 5; | |
| 623 | + WRITE_ONCE(*Q, 5); | |
| 608 | 624 | |
| 609 | −The data-dependency barrier must order the read into Q with the store | |
| 610 | −into *Q. This prohibits this outcome: | |
| 625 | +Therefore, no data-dependency barrier is required to order the read into | |
| 626 | +Q with the store into *Q. In other words, this outcome is prohibited, | |
| 627 | +even without a data-dependency barrier: | |
| 611 | 628 | |
| 612 | 629 | (Q == &B) && (B == 4) |
| 613 | 630 | |
| 614 | 631 | Please note that this pattern should be rare. After all, the whole point |
| 615 | 632 | of dependency ordering is to -prevent- writes to the data structure, along |
| 616 | 633 | with the expensive cache misses associated with those writes. This pattern |
| 617 | −can be used to record rare error conditions and the like, and the ordering | |
| 618 | −prevents such records from being lost. | |
| 619 | − | |
| 620 | − | |
| 621 | −[!] Note that this extremely counterintuitive situation arises most easily on | |
| 622 | −machines with split caches, so that, for example, one cache bank processes | |
| 623 | −even-numbered cache lines and the other bank processes odd-numbered cache | |
| 624 | −lines. The pointer P might be stored in an odd-numbered cache line, and the | |
| 625 | −variable B might be stored in an even-numbered cache line. Then, if the | |
| 626 | −even-numbered bank of the reading CPU's cache is extremely busy while the | |
| 627 | −odd-numbered bank is idle, one can see the new value of the pointer P (&B), | |
| 628 | −but the old value of the variable B (2). | |
| 634 | +can be used to record rare error conditions and the like, and the CPUs' | |
| 635 | +naturally occurring ordering prevents such records from being lost. | |
| 629 | 636 | |
| 630 | 637 | |
| 631 | 638 | The data dependency barrier is very important to the RCU system, |
| @@ -1876,8 +1883,7 @@ There are some more advanced barrier functions: · 1244 unmodified lines | ||
| 1876 | 1883 | This makes sure that the death mark on the object is perceived to be set |
| 1877 | 1884 | *before* the reference counter is decremented. |
| 1878 | 1885 | |
| 1879 | − See Documentation/core-api/atomic_ops.rst for more information. See the | |
| 1880 | − "Atomic operations" subsection for information on where to use these. | |
| 1886 | + See Documentation/atomic_{t,bitops}.txt for more information. | |
| 1881 | 1887 | |
| 1882 | 1888 | |
| 1883 | 1889 | (*) lockless_dereference(); |
| @@ -1982,10 +1988,7 @@ for each construct. These operations all imply certain barriers: · 98 unmodified lines | ||
| 1982 | 1988 | ACQUIRE operation has completed. |
| 1983 | 1989 | |
| 1984 | 1990 | Memory operations issued before the ACQUIRE may be completed after |
| 1985 | − the ACQUIRE operation has completed. An smp_mb__before_spinlock(), | |
| 1986 | − combined with a following ACQUIRE, orders prior stores against | |
| 1987 | − subsequent loads and stores. Note that this is weaker than smp_mb()! | |
| 1988 | − The smp_mb__before_spinlock() primitive is free on many architectures. | |
| 1991 | + the ACQUIRE operation has completed. | |
| 1989 | 1992 | |
| 1990 | 1993 | (2) RELEASE operation implication: |
| 1991 | 1994 | |
| @@ -2503,88 +2506,7 @@ operations are noted specially as some of them imply full memory barriers and · 511 unmodified lines | ||
| 2503 | 2506 | some don't, but they're very heavily relied on as a group throughout the |
| 2504 | 2507 | kernel. |
| 2505 | 2508 | |
| 2506 | −Any atomic operation that modifies some state in memory and returns information | |
| 2507 | −about the state (old or new) implies an SMP-conditional general memory barrier | |
| 2508 | −(smp_mb()) on each side of the actual operation (with the exception of | |
| 2509 | −explicit lock operations, described later). These include: | |
| 2510 | − | |
| 2511 | − xchg(); | |
| 2512 | − atomic_xchg(); atomic_long_xchg(); | |
| 2513 | − atomic_inc_return(); atomic_long_inc_return(); | |
| 2514 | − atomic_dec_return(); atomic_long_dec_return(); | |
| 2515 | − atomic_add_return(); atomic_long_add_return(); | |
| 2516 | − atomic_sub_return(); atomic_long_sub_return(); | |
| 2517 | − atomic_inc_and_test(); atomic_long_inc_and_test(); | |
| 2518 | − atomic_dec_and_test(); atomic_long_dec_and_test(); | |
| 2519 | − atomic_sub_and_test(); atomic_long_sub_and_test(); | |
| 2520 | − atomic_add_negative(); atomic_long_add_negative(); | |
| 2521 | − test_and_set_bit(); | |
| 2522 | − test_and_clear_bit(); | |
| 2523 | − test_and_change_bit(); | |
| 2524 | − | |
| 2525 | − /* when succeeds */ | |
| 2526 | − cmpxchg(); | |
| 2527 | − atomic_cmpxchg(); atomic_long_cmpxchg(); | |
| 2528 | − atomic_add_unless(); atomic_long_add_unless(); | |
| 2529 | − | |
| 2530 | −These are used for such things as implementing ACQUIRE-class and RELEASE-class | |
| 2531 | −operations and adjusting reference counters towards object destruction, and as | |
| 2532 | −such the implicit memory barrier effects are necessary. | |
| 2533 | − | |
| 2534 | − | |
| 2535 | −The following operations are potential problems as they do _not_ imply memory | |
| 2536 | −barriers, but might be used for implementing such things as RELEASE-class | |
| 2537 | −operations: | |
| 2538 | − | |
| 2539 | − atomic_set(); | |
| 2540 | − set_bit(); | |
| 2541 | − clear_bit(); | |
| 2542 | − change_bit(); | |
| 2543 | − | |
| 2544 | −With these the appropriate explicit memory barrier should be used if necessary | |
| 2545 | −(smp_mb__before_atomic() for instance). | |
| 2546 | − | |
| 2547 | − | |
| 2548 | −The following also do _not_ imply memory barriers, and so may require explicit | |
| 2549 | −memory barriers under some circumstances (smp_mb__before_atomic() for | |
| 2550 | −instance): | |
| 2551 | − | |
| 2552 | − atomic_add(); | |
| 2553 | − atomic_sub(); | |
| 2554 | − atomic_inc(); | |
| 2555 | − atomic_dec(); | |
| 2556 | − | |
| 2557 | −If they're used for statistics generation, then they probably don't need memory | |
| 2558 | −barriers, unless there's a coupling between statistical data. | |
| 2559 | − | |
| 2560 | −If they're used for reference counting on an object to control its lifetime, | |
| 2561 | −they probably don't need memory barriers because either the reference count | |
| 2562 | −will be adjusted inside a locked section, or the caller will already hold | |
| 2563 | −sufficient references to make the lock, and thus a memory barrier unnecessary. | |
| 2564 | − | |
| 2565 | −If they're used for constructing a lock of some description, then they probably | |
| 2566 | −do need memory barriers as a lock primitive generally has to do things in a | |
| 2567 | −specific order. | |
| 2568 | − | |
| 2569 | −Basically, each usage case has to be carefully considered as to whether memory | |
| 2570 | −barriers are needed or not. | |
| 2571 | − | |
| 2572 | −The following operations are special locking primitives: | |
| 2573 | − | |
| 2574 | − test_and_set_bit_lock(); | |
| 2575 | − clear_bit_unlock(); | |
| 2576 | − __clear_bit_unlock(); | |
| 2577 | − | |
| 2578 | −These implement ACQUIRE-class and RELEASE-class operations. These should be | |
| 2579 | −used in preference to other operations when implementing locking primitives, | |
| 2580 | −because their implementations can be optimised on many architectures. | |
| 2581 | − | |
| 2582 | −[!] Note that special memory barrier primitives are available for these | |
| 2583 | −situations because on some CPUs the atomic instructions used imply full memory | |
| 2584 | −barriers, and so barrier instructions are superfluous in conjunction with them, | |
| 2585 | −and in such cases the special barrier primitives will be no-ops. | |
| 2586 | − | |
| 2587 | −See Documentation/core-api/atomic_ops.rst for more information. | |
| 2509 | +See Documentation/atomic_t.txt for more information. | |
| 2588 | 2510 | |
| 2589 | 2511 | |
| 2590 | 2512 | ACCESSING DEVICES |
| @@ -30,8 +30,6 @@ atm.txt · 29 unmodified lines | ||
| 30 | 30 | - info on where to get ATM programs and support for Linux. |
| 31 | 31 | ax25.txt |
| 32 | 32 | - info on using AX.25 and NET/ROM code for Linux |
| 33 | −batman-adv.txt | |
| 34 | − - B.A.T.M.A.N routing protocol on top of layer 2 Ethernet Frames. | |
| 35 | 33 | baycom.txt |
| 36 | 34 | - info on the driver for Baycom style amateur radio modems |
| 37 | 35 | bonding.txt |
| @@ -0,0 +1,220 @@ | ||
| 1 | +========== | |
| 2 | +batman-adv | |
| 3 | +========== | |
| 4 | + | |
| 5 | +Batman advanced is a new approach to wireless networking which does no longer | |
| 6 | +operate on the IP basis. Unlike the batman daemon, which exchanges information | |
| 7 | +using UDP packets and sets routing tables, batman-advanced operates on ISO/OSI | |
| 8 | +Layer 2 only and uses and routes (or better: bridges) Ethernet Frames. It | |
| 9 | +emulates a virtual network switch of all nodes participating. Therefore all | |
| 10 | +nodes appear to be link local, thus all higher operating protocols won't be | |
| 11 | +affected by any changes within the network. You can run almost any protocol | |
| 12 | +above batman advanced, prominent examples are: IPv4, IPv6, DHCP, IPX. | |
| 13 | + | |
| 14 | +Batman advanced was implemented as a Linux kernel driver to reduce the overhead | |
| 15 | +to a minimum. It does not depend on any (other) network driver, and can be used | |
| 16 | +on wifi as well as ethernet lan, vpn, etc ... (anything with ethernet-style | |
| 17 | +layer 2). | |
| 18 | + | |
| 19 | + | |
| 20 | +Configuration | |
| 21 | +============= | |
| 22 | + | |
| 23 | +Load the batman-adv module into your kernel:: | |
| 24 | + | |
| 25 | + $ insmod batman-adv.ko | |
| 26 | + | |
| 27 | +The module is now waiting for activation. You must add some interfaces on which | |
| 28 | +batman can operate. After loading the module batman advanced will scan your | |
| 29 | +systems interfaces to search for compatible interfaces. Once found, it will | |
| 30 | +create subfolders in the ``/sys`` directories of each supported interface, | |
| 31 | +e.g.:: | |
| 32 | + | |
| 33 | + $ ls /sys/class/net/eth0/batman_adv/ | |
| 34 | + elp_interval iface_status mesh_iface throughput_override | |
| 35 | + | |
| 36 | +If an interface does not have the ``batman_adv`` subfolder, it probably is not | |
| 37 | +supported. Not supported interfaces are: loopback, non-ethernet and batman's | |
| 38 | +own interfaces. | |
| 39 | + | |
| 40 | +Note: After the module was loaded it will continuously watch for new | |
| 41 | +interfaces to verify the compatibility. There is no need to reload the module | |
| 42 | +if you plug your USB wifi adapter into your machine after batman advanced was | |
| 43 | +initially loaded. | |
| 44 | + | |
| 45 | +The batman-adv soft-interface can be created using the iproute2 tool ``ip``:: | |
| 46 | + | |
| 47 | + $ ip link add name bat0 type batadv | |
| 48 | + | |
| 49 | +To activate a given interface simply attach it to the ``bat0`` interface:: | |
| 50 | + | |
| 51 | + $ ip link set dev eth0 master bat0 | |
| 52 | + | |
| 53 | +Repeat this step for all interfaces you wish to add. Now batman starts | |
| 54 | +using/broadcasting on this/these interface(s). | |
| 55 | + | |
| 56 | +By reading the "iface_status" file you can check its status:: | |
| 57 | + | |
| 58 | + $ cat /sys/class/net/eth0/batman_adv/iface_status | |
| 59 | + active | |
| 60 | + | |
| 61 | +To deactivate an interface you have to detach it from the "bat0" interface:: | |
| 62 | + | |
| 63 | + $ ip link set dev eth0 nomaster | |
| 64 | + | |
| 65 | + | |
| 66 | +All mesh wide settings can be found in batman's own interface folder:: | |
| 67 | + | |
| 68 | + $ ls /sys/class/net/bat0/mesh/ | |
| 69 | + aggregated_ogms fragmentation isolation_mark routing_algo | |
| 70 | + ap_isolation gw_bandwidth log_level vlan0 | |
| 71 | + bonding gw_mode multicast_mode | |
| 72 | + bridge_loop_avoidance gw_sel_class network_coding | |
| 73 | + distributed_arp_table hop_penalty orig_interval | |
| 74 | + | |
| 75 | +There is a special folder for debugging information:: | |
| 76 | + | |
| 77 | + $ ls /sys/kernel/debug/batman_adv/bat0/ | |
| 78 | + bla_backbone_table log neighbors transtable_local | |
| 79 | + bla_claim_table mcast_flags originators | |
| 80 | + dat_cache nc socket | |
| 81 | + gateways nc_nodes transtable_global | |
| 82 | + | |
| 83 | +Some of the files contain all sort of status information regarding the mesh | |
| 84 | +network. For example, you can view the table of originators (mesh | |
| 85 | +participants) with:: | |
| 86 | + | |
| 87 | + $ cat /sys/kernel/debug/batman_adv/bat0/originators | |
| 88 | + | |
| 89 | +Other files allow to change batman's behaviour to better fit your requirements. | |
| 90 | +For instance, you can check the current originator interval (value in | |
| 91 | +milliseconds which determines how often batman sends its broadcast packets):: | |
| 92 | + | |
| 93 | + $ cat /sys/class/net/bat0/mesh/orig_interval | |
| 94 | + 1000 | |
| 95 | + | |
| 96 | +and also change its value:: | |
| 97 | + | |
| 98 | + $ echo 3000 > /sys/class/net/bat0/mesh/orig_interval | |
| 99 | + | |
| 100 | +In very mobile scenarios, you might want to adjust the originator interval to a | |
| 101 | +lower value. This will make the mesh more responsive to topology changes, but | |
| 102 | +will also increase the overhead. | |
| 103 | + | |
| 104 | + | |
| 105 | +Usage | |
| 106 | +===== | |
| 107 | + | |
| 108 | +To make use of your newly created mesh, batman advanced provides a new | |
| 109 | +interface "bat0" which you should use from this point on. All interfaces added | |
| 110 | +to batman advanced are not relevant any longer because batman handles them for | |
| 111 | +you. Basically, one "hands over" the data by using the batman interface and | |
| 112 | +batman will make sure it reaches its destination. | |
| 113 | + | |
| 114 | +The "bat0" interface can be used like any other regular interface. It needs an | |
| 115 | +IP address which can be either statically configured or dynamically (by using | |
| 116 | +DHCP or similar services):: | |
| 117 | + | |
| 118 | + NodeA: ip link set up dev bat0 | |
| 119 | + NodeA: ip addr add 192.168.0.1/24 dev bat0 | |
| 120 | + | |
| 121 | + NodeB: ip link set up dev bat0 | |
| 122 | + NodeB: ip addr add 192.168.0.2/24 dev bat0 | |
| 123 | + NodeB: ping 192.168.0.1 | |
| 124 | + | |
| 125 | +Note: In order to avoid problems remove all IP addresses previously assigned to | |
| 126 | +interfaces now used by batman advanced, e.g.:: | |
| 127 | + | |
| 128 | + $ ip addr flush dev eth0 | |
| 129 | + | |
| 130 | + | |
| 131 | +Logging/Debugging | |
| 132 | +================= | |
| 133 | + | |
| 134 | +All error messages, warnings and information messages are sent to the kernel | |
| 135 | +log. Depending on your operating system distribution this can be read in one of | |
| 136 | +a number of ways. Try using the commands: ``dmesg``, ``logread``, or looking in | |
| 137 | +the files ``/var/log/kern.log`` or ``/var/log/syslog``. All batman-adv messages | |
| 138 | +are prefixed with "batman-adv:" So to see just these messages try:: | |
| 139 | + | |
| 140 | + $ dmesg | grep batman-adv | |
| 141 | + | |
| 142 | +When investigating problems with your mesh network, it is sometimes necessary to | |
| 143 | +see more detail debug messages. This must be enabled when compiling the | |
| 144 | +batman-adv module. When building batman-adv as part of kernel, use "make | |
| 145 | +menuconfig" and enable the option ``B.A.T.M.A.N. debugging`` | |
| 146 | +(``CONFIG_BATMAN_ADV_DEBUG=y``). | |
| 147 | + | |
| 148 | +Those additional debug messages can be accessed using a special file in | |
| 149 | +debugfs:: | |
| 150 | + | |
| 151 | + $ cat /sys/kernel/debug/batman_adv/bat0/log | |
| 152 | + | |
| 153 | +The additional debug output is by default disabled. It can be enabled during | |
| 154 | +run time. Following log_levels are defined: | |
| 155 | + | |
| 156 | +.. flat-table:: | |
| 157 | + | |
| 158 | + * - 0 | |
| 159 | + - All debug output disabled | |
| 160 | + * - 1 | |
| 161 | + - Enable messages related to routing / flooding / broadcasting | |
| 162 | + * - 2 | |
| 163 | + - Enable messages related to route added / changed / deleted | |
| 164 | + * - 4 | |
| 165 | + - Enable messages related to translation table operations | |
| 166 | + * - 8 | |
| 167 | + - Enable messages related to bridge loop avoidance | |
| 168 | + * - 16 | |
| 169 | + - Enable messages related to DAT, ARP snooping and parsing | |
| 170 | + * - 32 | |
| 171 | + - Enable messages related to network coding | |
| 172 | + * - 64 | |
| 173 | + - Enable messages related to multicast | |
| 174 | + * - 128 | |
| 175 | + - Enable messages related to throughput meter | |
| 176 | + * - 255 | |
| 177 | + - Enable all messages | |
| 178 | + | |
| 179 | +The debug output can be changed at runtime using the file | |
| 180 | +``/sys/class/net/bat0/mesh/log_level``. e.g.:: | |
| 181 | + | |
| 182 | + $ echo 6 > /sys/class/net/bat0/mesh/log_level | |
| 183 | + | |
| 184 | +will enable debug messages for when routes change. | |
| 185 | + | |
| 186 | +Counters for different types of packets entering and leaving the batman-adv | |
| 187 | +module are available through ethtool:: | |
| 188 | + | |
| 189 | + $ ethtool --statistics bat0 | |
| 190 | + | |
| 191 | + | |
| 192 | +batctl | |
| 193 | +====== | |
| 194 | + | |
| 195 | +As batman advanced operates on layer 2, all hosts participating in the virtual | |
| 196 | +switch are completely transparent for all protocols above layer 2. Therefore | |
| 197 | +the common diagnosis tools do not work as expected. To overcome these problems, | |
| 198 | +batctl was created. At the moment the batctl contains ping, traceroute, tcpdump | |
| 199 | +and interfaces to the kernel module settings. | |
| 200 | + | |
| 201 | +For more information, please see the manpage (``man batctl``). | |
| 202 | + | |
| 203 | +batctl is available on https://www.open-mesh.org/ | |
| 204 | + | |
| 205 | + | |
| 206 | +Contact | |
| 207 | +======= | |
| 208 | + | |
| 209 | +Please send us comments, experiences, questions, anything :) | |
| 210 | + | |
| 211 | +IRC: | |
| 212 | + #batman on irc.freenode.org | |
| 213 | +Mailing-list: | |
| 214 | + b.a.t.m.a.n@open-mesh.org (optional subscription at | |
| 215 | + https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) | |
| 216 | + | |
| 217 | +You can also contact the Authors: | |
| 218 | + | |
| 219 | +* Marek Lindner <mareklindner@neomailbox.ch> | |
| 220 | +* Simon Wunderlich <sw@simonwunderlich.de> | |
| @@ -1,215 +0,0 @@ | ||
| 1 | −BATMAN-ADV | |
| 2 | −---------- | |
| 3 | − | |
| 4 | −Batman advanced is a new approach to wireless networking which | |
| 5 | −does no longer operate on the IP basis. Unlike the batman daemon, | |
| 6 | −which exchanges information using UDP packets and sets routing | |
| 7 | −tables, batman-advanced operates on ISO/OSI Layer 2 only and uses | |
| 8 | −and routes (or better: bridges) Ethernet Frames. It emulates a | |
| 9 | −virtual network switch of all nodes participating. Therefore all | |
| 10 | −nodes appear to be link local, thus all higher operating proto- | |
| 11 | −cols won't be affected by any changes within the network. You can | |
| 12 | −run almost any protocol above batman advanced, prominent examples | |
| 13 | −are: IPv4, IPv6, DHCP, IPX. | |
| 14 | − | |
| 15 | −Batman advanced was implemented as a Linux kernel driver to re- | |
| 16 | −duce the overhead to a minimum. It does not depend on any (other) | |
| 17 | −network driver, and can be used on wifi as well as ethernet lan, | |
| 18 | −vpn, etc ... (anything with ethernet-style layer 2). | |
| 19 | − | |
| 20 | − | |
| 21 | −CONFIGURATION | |
| 22 | −------------- | |
| 23 | − | |
| 24 | −Load the batman-adv module into your kernel: | |
| 25 | − | |
| 26 | −# insmod batman-adv.ko | |
| 27 | − | |
| 28 | −The module is now waiting for activation. You must add some in- | |
| 29 | −terfaces on which batman can operate. After loading the module | |
| 30 | −batman advanced will scan your systems interfaces to search for | |
| 31 | −compatible interfaces. Once found, it will create subfolders in | |
| 32 | −the /sys directories of each supported interface, e.g. | |
| 33 | − | |
| 34 | −# ls /sys/class/net/eth0/batman_adv/ | |
| 35 | −# elp_interval iface_status mesh_iface throughput_override | |
| 36 | − | |
| 37 | −If an interface does not have the "batman_adv" subfolder it prob- | |
| 38 | −ably is not supported. Not supported interfaces are: loopback, | |
| 39 | −non-ethernet and batman's own interfaces. | |
| 40 | − | |
| 41 | −Note: After the module was loaded it will continuously watch for | |
| 42 | −new interfaces to verify the compatibility. There is no need to | |
| 43 | −reload the module if you plug your USB wifi adapter into your ma- | |
| 44 | −chine after batman advanced was initially loaded. | |
| 45 | − | |
| 46 | −The batman-adv soft-interface can be created using the iproute2 | |
| 47 | −tool "ip" | |
| 48 | − | |
| 49 | −# ip link add name bat0 type batadv | |
| 50 | − | |
| 51 | −To activate a given interface simply attach it to the "bat0" | |
| 52 | −interface | |
| 53 | − | |
| 54 | −# ip link set dev eth0 master bat0 | |
| 55 | − | |
| 56 | −Repeat this step for all interfaces you wish to add. Now batman | |
| 57 | −starts using/broadcasting on this/these interface(s). | |
| 58 | − | |
| 59 | −By reading the "iface_status" file you can check its status: | |
| 60 | − | |
| 61 | −# cat /sys/class/net/eth0/batman_adv/iface_status | |
| 62 | −# active | |
| 63 | − | |
| 64 | −To deactivate an interface you have to detach it from the | |
| 65 | −"bat0" interface: | |
| 66 | − | |
| 67 | −# ip link set dev eth0 nomaster | |
| 68 | − | |
| 69 | − | |
| 70 | −All mesh wide settings can be found in batman's own interface | |
| 71 | −folder: | |
| 72 | − | |
| 73 | −# ls /sys/class/net/bat0/mesh/ | |
| 74 | −# aggregated_ogms fragmentation isolation_mark routing_algo | |
| 75 | −# ap_isolation gw_bandwidth log_level vlan0 | |
| 76 | −# bonding gw_mode multicast_mode | |
| 77 | −# bridge_loop_avoidance gw_sel_class network_coding | |
| 78 | −# distributed_arp_table hop_penalty orig_interval | |
| 79 | − | |
| 80 | −There is a special folder for debugging information: | |
| 81 | − | |
| 82 | −# ls /sys/kernel/debug/batman_adv/bat0/ | |
| 83 | −# bla_backbone_table log neighbors transtable_local | |
| 84 | −# bla_claim_table mcast_flags originators | |
| 85 | −# dat_cache nc socket | |
| 86 | −# gateways nc_nodes transtable_global | |
| 87 | − | |
| 88 | −Some of the files contain all sort of status information regard- | |
| 89 | −ing the mesh network. For example, you can view the table of | |
| 90 | −originators (mesh participants) with: | |
| 91 | − | |
| 92 | −# cat /sys/kernel/debug/batman_adv/bat0/originators | |
| 93 | − | |
| 94 | −Other files allow to change batman's behaviour to better fit your | |
| 95 | −requirements. For instance, you can check the current originator | |
| 96 | −interval (value in milliseconds which determines how often batman | |
| 97 | −sends its broadcast packets): | |
| 98 | − | |
| 99 | −# cat /sys/class/net/bat0/mesh/orig_interval | |
| 100 | −# 1000 | |
| 101 | − | |
| 102 | −and also change its value: | |
| 103 | − | |
| 104 | −# echo 3000 > /sys/class/net/bat0/mesh/orig_interval | |
| 105 | − | |
| 106 | −In very mobile scenarios, you might want to adjust the originator | |
| 107 | −interval to a lower value. This will make the mesh more respon- | |
| 108 | −sive to topology changes, but will also increase the overhead. | |
| 109 | − | |
| 110 | − | |
| 111 | −USAGE | |
| 112 | −----- | |
| 113 | − | |
| 114 | −To make use of your newly created mesh, batman advanced provides | |
| 115 | −a new interface "bat0" which you should use from this point on. | |
| 116 | −All interfaces added to batman advanced are not relevant any | |
| 117 | −longer because batman handles them for you. Basically, one "hands | |
| 118 | −over" the data by using the batman interface and batman will make | |
| 119 | −sure it reaches its destination. | |
| 120 | − | |
| 121 | −The "bat0" interface can be used like any other regular inter- | |
| 122 | −face. It needs an IP address which can be either statically con- | |
| 123 | −figured or dynamically (by using DHCP or similar services): | |
| 124 | − | |
| 125 | −# NodeA: ip link set up dev bat0 | |
| 126 | −# NodeA: ip addr add 192.168.0.1/24 dev bat0 | |
| 127 | − | |
| 128 | −# NodeB: ip link set up dev bat0 | |
| 129 | −# NodeB: ip addr add 192.168.0.2/24 dev bat0 | |
| 130 | −# NodeB: ping 192.168.0.1 | |
| 131 | − | |
| 132 | −Note: In order to avoid problems remove all IP addresses previ- | |
| 133 | −ously assigned to interfaces now used by batman advanced, e.g. | |
| 134 | − | |
| 135 | −# ip addr flush dev eth0 | |
| 136 | − | |
| 137 | − | |
| 138 | −LOGGING/DEBUGGING | |
| 139 | −----------------- | |
| 140 | − | |
| 141 | −All error messages, warnings and information messages are sent to | |
| 142 | −the kernel log. Depending on your operating system distribution | |
| 143 | −this can be read in one of a number of ways. Try using the com- | |
| 144 | −mands: dmesg, logread, or looking in the files /var/log/kern.log | |
| 145 | −or /var/log/syslog. All batman-adv messages are prefixed with | |
| 146 | −"batman-adv:" So to see just these messages try | |
| 147 | − | |
| 148 | −# dmesg | grep batman-adv | |
| 149 | − | |
| 150 | −When investigating problems with your mesh network it is some- | |
| 151 | −times necessary to see more detail debug messages. This must be | |
| 152 | −enabled when compiling the batman-adv module. When building bat- | |
| 153 | −man-adv as part of kernel, use "make menuconfig" and enable the | |
| 154 | −option "B.A.T.M.A.N. debugging". | |
| 155 | − | |
| 156 | −Those additional debug messages can be accessed using a special | |
| 157 | −file in debugfs | |
| 158 | − | |
| 159 | −# cat /sys/kernel/debug/batman_adv/bat0/log | |
| 160 | − | |
| 161 | −The additional debug output is by default disabled. It can be en- | |
| 162 | −abled during run time. Following log_levels are defined: | |
| 163 | − | |
| 164 | − 0 - All debug output disabled | |
| 165 | − 1 - Enable messages related to routing / flooding / broadcasting | |
| 166 | − 2 - Enable messages related to route added / changed / deleted | |
| 167 | − 4 - Enable messages related to translation table operations | |
| 168 | − 8 - Enable messages related to bridge loop avoidance | |
| 169 | − 16 - Enable messages related to DAT, ARP snooping and parsing | |
| 170 | − 32 - Enable messages related to network coding | |
| 171 | − 64 - Enable messages related to multicast | |
| 172 | −128 - Enable messages related to throughput meter | |
| 173 | −255 - Enable all messages | |
| 174 | − | |
| 175 | −The debug output can be changed at runtime using the file | |
| 176 | −/sys/class/net/bat0/mesh/log_level. e.g. | |
| 177 | − | |
| 178 | −# echo 6 > /sys/class/net/bat0/mesh/log_level | |
| 179 | − | |
| 180 | −will enable debug messages for when routes change. | |
| 181 | − | |
| 182 | −Counters for different types of packets entering and leaving the | |
| 183 | −batman-adv module are available through ethtool: | |
| 184 | − | |
| 185 | −# ethtool --statistics bat0 | |
| 186 | − | |
| 187 | − | |
| 188 | −BATCTL | |
| 189 | −------ | |
| 190 | − | |
| 191 | −As batman advanced operates on layer 2 all hosts participating in | |
| 192 | −the virtual switch are completely transparent for all protocols | |
| 193 | −above layer 2. Therefore the common diagnosis tools do not work | |
| 194 | −as expected. To overcome these problems batctl was created. At | |
| 195 | −the moment the batctl contains ping, traceroute, tcpdump and | |
| 196 | −interfaces to the kernel module settings. | |
| 197 | − | |
| 198 | −For more information, please see the manpage (man batctl). | |
| 199 | − | |
| 200 | −batctl is available on https://www.open-mesh.org/ | |
| 201 | − | |
| 202 | − | |
| 203 | −CONTACT | |
| 204 | −------- | |
| 205 | − | |
| 206 | −Please send us comments, experiences, questions, anything :) | |
| 207 | − | |
| 208 | −IRC: #batman on irc.freenode.org | |
| 209 | −Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription | |
| 210 | − at https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) | |
| 211 | − | |
| 212 | −You can also contact the Authors: | |
| 213 | − | |
| 214 | −Marek Lindner <mareklindner@neomailbox.ch> | |
| 215 | −Simon Wunderlich <sw@simonwunderlich.de> | |
| @@ -13,6 +13,7 @@ Contents · 12 unmodified lines | ||
| 13 | 13 | - Configuring DPAA Ethernet in your kernel |
| 14 | 14 | - DPAA Ethernet Frame Processing |
| 15 | 15 | - DPAA Ethernet Features |
| 16 | + - DPAA IRQ Affinity and Receive Side Scaling | |
| 16 | 17 | - Debugging |
| 17 | 18 | |
| 18 | 19 | DPAA Ethernet Overview |
| @@ -147,7 +148,10 @@ gradually. · 128 unmodified lines | ||
| 147 | 148 | |
| 148 | 149 | The driver has Rx and Tx checksum offloading for UDP and TCP. Currently the Rx |
| 149 | 150 | checksum offload feature is enabled by default and cannot be controlled through |
| 150 | −ethtool. | |
| 151 | +ethtool. Also, rx-flow-hash and rx-hashing was added. The addition of RSS | |
| 152 | +provides a big performance boost for the forwarding scenarios, allowing | |
| 153 | +different traffic flows received by one interface to be processed by different | |
| 154 | +CPUs in parallel. | |
| 151 | 155 | |
| 152 | 156 | The driver has support for multiple prioritized Tx traffic classes. Priorities |
| 153 | 157 | range from 0 (lowest) to 3 (highest). These are mapped to HW workqueues with |
| @@ -166,6 +170,68 @@ classes as follows: · 12 unmodified lines | ||
| 166 | 170 | tc qdisc add dev <int> root handle 1: \ |
| 167 | 171 | mqprio num_tc 4 map 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 hw 1 |
| 168 | 172 | |
| 173 | +DPAA IRQ Affinity and Receive Side Scaling | |
| 174 | +========================================== | |
| 175 | + | |
| 176 | +Traffic coming on the DPAA Rx queues or on the DPAA Tx confirmation | |
| 177 | +queues is seen by the CPU as ingress traffic on a certain portal. | |
| 178 | +The DPAA QMan portal interrupts are affined each to a certain CPU. | |
| 179 | +The same portal interrupt services all the QMan portal consumers. | |
| 180 | + | |
| 181 | +By default the DPAA Ethernet driver enables RSS, making use of the | |
| 182 | +DPAA FMan Parser and Keygen blocks to distribute traffic on 128 | |
| 183 | +hardware frame queues using a hash on IP v4/v6 source and destination | |
| 184 | +and L4 source and destination ports, in present in the received frame. | |
| 185 | +When RSS is disabled, all traffic received by a certain interface is | |
| 186 | +received on the default Rx frame queue. The default DPAA Rx frame | |
| 187 | +queues are configured to put the received traffic into a pool channel | |
| 188 | +that allows any available CPU portal to dequeue the ingress traffic. | |
| 189 | +The default frame queues have the HOLDACTIVE option set, ensuring that | |
| 190 | +traffic bursts from a certain queue are serviced by the same CPU. | |
| 191 | +This ensures a very low rate of frame reordering. A drawback of this | |
| 192 | +is that only one CPU at a time can service the traffic received by a | |
| 193 | +certain interface when RSS is not enabled. | |
| 194 | + | |
| 195 | +To implement RSS, the DPAA Ethernet driver allocates an extra set of | |
| 196 | +128 Rx frame queues that are configured to dedicated channels, in a | |
| 197 | +round-robin manner. The mapping of the frame queues to CPUs is now | |
| 198 | +hardcoded, there is no indirection table to move traffic for a certain | |
| 199 | +FQ (hash result) to another CPU. The ingress traffic arriving on one | |
| 200 | +of these frame queues will arrive at the same portal and will always | |
| 201 | +be processed by the same CPU. This ensures intra-flow order preservation | |
| 202 | +and workload distribution for multiple traffic flows. | |
| 203 | + | |
| 204 | +RSS can be turned off for a certain interface using ethtool, i.e. | |
| 205 | + | |
| 206 | + # ethtool -N fm1-mac9 rx-flow-hash tcp4 "" | |
| 207 | + | |
| 208 | +To turn it back on, one needs to set rx-flow-hash for tcp4/6 or udp4/6: | |
| 209 | + | |
| 210 | + # ethtool -N fm1-mac9 rx-flow-hash udp4 sfdn | |
| 211 | + | |
| 212 | +There is no independent control for individual protocols, any command | |
| 213 | +run for one of tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 is | |
| 214 | +going to control the rx-flow-hashing for all protocols on that interface. | |
| 215 | + | |
| 216 | +Besides using the FMan Keygen computed hash for spreading traffic on the | |
| 217 | +128 Rx FQs, the DPAA Ethernet driver also sets the skb hash value when | |
| 218 | +the NETIF_F_RXHASH feature is on (active by default). This can be turned | |
| 219 | +on or off through ethtool, i.e.: | |
| 220 | + | |
| 221 | + # ethtool -K fm1-mac9 rx-hashing off | |
| 222 | + # ethtool -k fm1-mac9 | grep hash | |
| 223 | + receive-hashing: off | |
| 224 | + # ethtool -K fm1-mac9 rx-hashing on | |
| 225 | + Actual changes: | |
| 226 | + receive-hashing: on | |
| 227 | + # ethtool -k fm1-mac9 | grep hash | |
| 228 | + receive-hashing: on | |
| 229 | + | |
| 230 | +Please note that Rx hashing depends upon the rx-flow-hashing being on | |
| 231 | +for that interface - turning off rx-flow-hashing will also disable the | |
| 232 | +rx-hashing (without ethtool reporting it as off as that depends on the | |
| 233 | +NETIF_F_RXHASH feature flag). | |
| 234 | + | |
| 169 | 235 | Debugging |
| 170 | 236 | ========= |
| 171 | 237 | |
| @@ -45,7 +45,7 @@ in many more places. There's xt_bpf for netfilter, cls_bpf in the kernel · 44 unmodified lines | ||
| 45 | 45 | qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places |
| 46 | 46 | such as team driver, PTP code, etc where BPF is being used. |
| 47 | 47 | |
| 48 | − [1] Documentation/prctl/seccomp_filter.txt | |
| 48 | + [1] Documentation/userspace-api/seccomp_filter.rst | |
| 49 | 49 | |
| 50 | 50 | Original BPF paper: |
| 51 | 51 | |
| @@ -337,7 +337,7 @@ Examples for low-level BPF: · 285 unmodified lines | ||
| 337 | 337 | jeq #14, good /* __NR_rt_sigprocmask */ |
| 338 | 338 | jeq #13, good /* __NR_rt_sigaction */ |
| 339 | 339 | jeq #35, good /* __NR_nanosleep */ |
| 340 | − bad: ret #0 /* SECCOMP_RET_KILL */ | |
| 340 | + bad: ret #0 /* SECCOMP_RET_KILL_THREAD */ | |
| 341 | 341 | good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ |
| 342 | 342 | |
| 343 | 343 | The above example code can be placed into a file (here called "foo"), and |
| @@ -596,8 +596,8 @@ skb pointer). All constraints and restrictions from bpf_check_classic() apply · 252 unmodified lines | ||
| 596 | 596 | before a conversion to the new layout is being done behind the scenes! |
| 597 | 597 | |
| 598 | 598 | Currently, the classic BPF format is being used for JITing on most 32-bit |
| 599 | −architectures, whereas x86-64, aarch64, s390x, powerpc64, sparc64 perform JIT | |
| 600 | −compilation from eBPF instruction set. | |
| 599 | +architectures, whereas x86-64, aarch64, s390x, powerpc64, sparc64, arm32 perform | |
| 600 | +JIT compilation from eBPF instruction set. | |
| 601 | 601 | |
| 602 | 602 | Some core changes of the new internal format: |
| 603 | 603 | |
| @@ -793,7 +793,7 @@ Some core changes of the new internal format: · 189 unmodified lines | ||
| 793 | 793 | bpf_exit |
| 794 | 794 | |
| 795 | 795 | After the call the registers R1-R5 contain junk values and cannot be read. |
| 796 | − In the future an eBPF verifier can be used to validate internal BPF programs. | |
| 796 | + An in-kernel eBPF verifier is used to validate internal BPF programs. | |
| 797 | 797 | |
| 798 | 798 | Also in the new design, eBPF is limited to 4096 insns, which means that any |
| 799 | 799 | program will terminate quickly and will only call a fixed number of kernel |
| @@ -906,6 +906,10 @@ If BPF_CLASS(code) == BPF_JMP, BPF_OP(code) is one of: · 106 unmodified lines | ||
| 906 | 906 | BPF_JSGE 0x70 /* eBPF only: signed '>=' */ |
| 907 | 907 | BPF_CALL 0x80 /* eBPF only: function call */ |
| 908 | 908 | BPF_EXIT 0x90 /* eBPF only: function return */ |
| 909 | + BPF_JLT 0xa0 /* eBPF only: unsigned '<' */ | |
| 910 | + BPF_JLE 0xb0 /* eBPF only: unsigned '<=' */ | |
| 911 | + BPF_JSLT 0xc0 /* eBPF only: signed '<' */ | |
| 912 | + BPF_JSLE 0xd0 /* eBPF only: signed '<=' */ | |
| 909 | 913 | |
| 910 | 914 | So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF |
| 911 | 915 | and eBPF. There are only two registers in classic BPF, so it means A += X. |
| @@ -1017,7 +1021,7 @@ At the start of the program the register R1 contains a pointer to context · 105 unmodified lines | ||
| 1017 | 1021 | and has type PTR_TO_CTX. |
| 1018 | 1022 | If verifier sees an insn that does R2=R1, then R2 has now type |
| 1019 | 1023 | PTR_TO_CTX as well and can be used on the right hand side of expression. |
| 1020 | −If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=UNKNOWN_VALUE, | |
| 1024 | +If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=SCALAR_VALUE, | |
| 1021 | 1025 | since addition of two valid pointers makes invalid pointer. |
| 1022 | 1026 | (In 'secure' mode verifier will reject any type of pointer arithmetic to make |
| 1023 | 1027 | sure that kernel addresses don't leak to unprivileged users) |
| @@ -1039,7 +1043,7 @@ is a correct program. If there was R1 instead of R6, it would have · 15 unmodified lines | ||
| 1039 | 1043 | been rejected. |
| 1040 | 1044 | |
| 1041 | 1045 | load/store instructions are allowed only with registers of valid types, which |
| 1042 | −are PTR_TO_CTX, PTR_TO_MAP, FRAME_PTR. They are bounds and alignment checked. | |
| 1046 | +are PTR_TO_CTX, PTR_TO_MAP, PTR_TO_STACK. They are bounds and alignment checked. | |
| 1043 | 1047 | For example: |
| 1044 | 1048 | bpf_mov R1 = 1 |
| 1045 | 1049 | bpf_mov R2 = 2 |
| @@ -1058,7 +1062,7 @@ intends to load a word from address R6 + 8 and store it into R0 · 12 unmodified lines | ||
| 1058 | 1062 | If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know |
| 1059 | 1063 | that offset 8 of size 4 bytes can be accessed for reading, otherwise |
| 1060 | 1064 | the verifier will reject the program. |
| 1061 | −If R6=FRAME_PTR, then access should be aligned and be within | |
| 1065 | +If R6=PTR_TO_STACK, then access should be aligned and be within | |
| 1062 | 1066 | stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8, |
| 1063 | 1067 | so it will fail verification, since it's out of bounds. |
| 1064 | 1068 | |
| @@ -1069,7 +1073,7 @@ For example: · 4 unmodified lines | ||
| 1069 | 1073 | bpf_ld R0 = *(u32 *)(R10 - 4) |
| 1070 | 1074 | bpf_exit |
| 1071 | 1075 | is invalid program. |
| 1072 | −Though R10 is correct read-only register and has type FRAME_PTR | |
| 1076 | +Though R10 is correct read-only register and has type PTR_TO_STACK | |
| 1073 | 1077 | and R10 - 4 is within stack bounds, there were no stores into that location. |
| 1074 | 1078 | |
| 1075 | 1079 | Pointer register spill/fill is tracked as well, since four (R6-R9) |
| @@ -1094,6 +1098,71 @@ all use cases. · 18 unmodified lines | ||
| 1094 | 1098 | |
| 1095 | 1099 | See details of eBPF verifier in kernel/bpf/verifier.c |
| 1096 | 1100 | |
| 1101 | +Register value tracking | |
| 1102 | +----------------------- | |
| 1103 | +In order to determine the safety of an eBPF program, the verifier must track | |
| 1104 | +the range of possible values in each register and also in each stack slot. | |
| 1105 | +This is done with 'struct bpf_reg_state', defined in include/linux/ | |
| 1106 | +bpf_verifier.h, which unifies tracking of scalar and pointer values. Each | |
| 1107 | +register state has a type, which is either NOT_INIT (the register has not been | |
| 1108 | +written to), SCALAR_VALUE (some value which is not usable as a pointer), or a | |
| 1109 | +pointer type. The types of pointers describe their base, as follows: | |
| 1110 | + PTR_TO_CTX Pointer to bpf_context. | |
| 1111 | + CONST_PTR_TO_MAP Pointer to struct bpf_map. "Const" because arithmetic | |
| 1112 | + on these pointers is forbidden. | |
| 1113 | + PTR_TO_MAP_VALUE Pointer to the value stored in a map element. | |
| 1114 | + PTR_TO_MAP_VALUE_OR_NULL | |
| 1115 | + Either a pointer to a map value, or NULL; map accesses | |
| 1116 | + (see section 'eBPF maps', below) return this type, | |
| 1117 | + which becomes a PTR_TO_MAP_VALUE when checked != NULL. | |
| 1118 | + Arithmetic on these pointers is forbidden. | |
| 1119 | + PTR_TO_STACK Frame pointer. | |
| 1120 | + PTR_TO_PACKET skb->data. | |
| 1121 | + PTR_TO_PACKET_END skb->data + headlen; arithmetic forbidden. | |
| 1122 | +However, a pointer may be offset from this base (as a result of pointer | |
| 1123 | +arithmetic), and this is tracked in two parts: the 'fixed offset' and 'variable | |
| 1124 | +offset'. The former is used when an exactly-known value (e.g. an immediate | |
| 1125 | +operand) is added to a pointer, while the latter is used for values which are | |
| 1126 | +not exactly known. The variable offset is also used in SCALAR_VALUEs, to track | |
| 1127 | +the range of possible values in the register. | |
| 1128 | +The verifier's knowledge about the variable offset consists of: | |
| 1129 | +* minimum and maximum values as unsigned | |
| 1130 | +* minimum and maximum values as signed | |
| 1131 | +* knowledge of the values of individual bits, in the form of a 'tnum': a u64 | |
| 1132 | +'mask' and a u64 'value'. 1s in the mask represent bits whose value is unknown; | |
| 1133 | +1s in the value represent bits known to be 1. Bits known to be 0 have 0 in both | |
| 1134 | +mask and value; no bit should ever be 1 in both. For example, if a byte is read | |
| 1135 | +into a register from memory, the register's top 56 bits are known zero, while | |
| 1136 | +the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we | |
| 1137 | +then OR this with 0x40, we get (0x40; 0xcf), then if we add 1 we get (0x0; | |
| 1138 | +0x1ff), because of potential carries. | |
| 1139 | +Besides arithmetic, the register state can also be updated by conditional | |
| 1140 | +branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch | |
| 1141 | +it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false' | |
| 1142 | +branch it will have a umax_value of 8. A signed compare (with BPF_JSGT or | |
| 1143 | +BPF_JSGE) would instead update the signed minimum/maximum values. Information | |
| 1144 | +from the signed and unsigned bounds can be combined; for instance if a value is | |
| 1145 | +first tested < 8 and then tested s> 4, the verifier will conclude that the value | |
| 1146 | +is also > 4 and s< 8, since the bounds prevent crossing the sign boundary. | |
| 1147 | +PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all | |
| 1148 | +pointers sharing that same variable offset. This is important for packet range | |
| 1149 | +checks: after adding some variable to a packet pointer, if you then copy it to | |
| 1150 | +another register and (say) add a constant 4, both registers will share the same | |
| 1151 | +'id' but one will have a fixed offset of +4. Then if it is bounds-checked and | |
| 1152 | +found to be less than a PTR_TO_PACKET_END, the other register is now known to | |
| 1153 | +have a safe range of at least 4 bytes. See 'Direct packet access', below, for | |
| 1154 | +more on PTR_TO_PACKET ranges. | |
| 1155 | +The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of | |
| 1156 | +the pointer returned from a map lookup. This means that when one copy is | |
| 1157 | +checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs. | |
| 1158 | +As well as range-checking, the tracked information is also used for enforcing | |
| 1159 | +alignment of pointer accesses. For instance, on most systems the packet pointer | |
| 1160 | +is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump | |
| 1161 | +over the Ethernet header, then reads IHL and addes (IHL * 4), the resulting | |
| 1162 | +pointer will have a variable offset known to be 4n+2 for some n, so adding the 2 | |
| 1163 | +bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through | |
| 1164 | +that pointer are safe. | |
| 1165 | + | |
| 1097 | 1166 | Direct packet access |
| 1098 | 1167 | -------------------- |
| 1099 | 1168 | In cls_bpf and act_bpf programs the verifier allows direct access to the packet |
| @@ -1121,7 +1190,7 @@ it now points to 'skb->data + 14' and accessible range is [R5, R5 + 14 - 14) · 21 unmodified lines | ||
| 1121 | 1190 | which is zero bytes. |
| 1122 | 1191 | |
| 1123 | 1192 | More complex packet access may look like: |
| 1124 | − R0=imm1 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp | |
| 1193 | + R0=inv1 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp | |
| 1125 | 1194 | 6: r0 = *(u8 *)(r3 +7) /* load 7th byte from the packet */ |
| 1126 | 1195 | 7: r4 = *(u8 *)(r3 +12) |
| 1127 | 1196 | 8: r4 *= 14 |
| @@ -1135,26 +1204,31 @@ More complex packet access may look like: · 7 unmodified lines | ||
| 1135 | 1204 | 16: r2 += 8 |
| 1136 | 1205 | 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */ |
| 1137 | 1206 | 18: if r2 > r1 goto pc+2 |
| 1138 | − R0=inv56 R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv52 R5=pkt(id=0,off=14,r=14) R10=fp | |
| 1207 | + R0=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)) R5=pkt(id=0,off=14,r=14) R10=fp | |
| 1139 | 1208 | 19: r1 = *(u8 *)(r3 +4) |
| 1140 | 1209 | The state of the register R3 is R3=pkt(id=2,off=0,r=8) |
| 1141 | 1210 | id=2 means that two 'r3 += rX' instructions were seen, so r3 points to some |
| 1142 | 1211 | offset within a packet and since the program author did |
| 1143 | 1212 | 'if (r3 + 8 > r1) goto err' at insn #18, the safe range is [R3, R3 + 8). |
| 1144 | −The verifier only allows 'add' operation on packet registers. Any other | |
| 1145 | −operation will set the register state to 'unknown_value' and it won't be | |
| 1213 | +The verifier only allows 'add'/'sub' operations on packet registers. Any other | |
| 1214 | +operation will set the register state to 'SCALAR_VALUE' and it won't be | |
| 1146 | 1215 | available for direct packet access. |
| 1147 | 1216 | Operation 'r3 += rX' may overflow and become less than original skb->data, |
| 1148 | −therefore the verifier has to prevent that. So it tracks the number of | |
| 1149 | −upper zero bits in all 'uknown_value' registers, so when it sees | |
| 1150 | −'r3 += rX' instruction and rX is more than 16-bit value, it will error as: | |
| 1151 | −"cannot add integer value with N upper zero bits to ptr_to_packet" | |
| 1217 | +therefore the verifier has to prevent that. So when it sees 'r3 += rX' | |
| 1218 | +instruction and rX is more than 16-bit value, any subsequent bounds-check of r3 | |
| 1219 | +against skb->data_end will not give us 'range' information, so attempts to read | |
| 1220 | +through the pointer will give "invalid access to packet" error. | |
| 1152 | 1221 | Ex. after insn 'r4 = *(u8 *)(r3 +12)' (insn #7 above) the state of r4 is |
| 1153 | −R4=inv56 which means that upper 56 bits on the register are guaranteed | |
| 1154 | −to be zero. After insn 'r4 *= 14' the state becomes R4=inv52, since | |
| 1155 | −multiplying 8-bit value by constant 14 will keep upper 52 bits as zero. | |
| 1156 | −Similarly 'r2 >>= 48' will make R2=inv48, since the shift is not sign | |
| 1157 | −extending. This logic is implemented in evaluate_reg_alu() function. | |
| 1222 | +R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) which means that upper 56 bits | |
| 1223 | +of the register are guaranteed to be zero, and nothing is known about the lower | |
| 1224 | +8 bits. After insn 'r4 *= 14' the state becomes | |
| 1225 | +R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), since multiplying an 8-bit | |
| 1226 | +value by constant 14 will keep upper 52 bits as zero, also the least significant | |
| 1227 | +bit will be zero as 14 is even. Similarly 'r2 >>= 48' will make | |
| 1228 | +R2=inv(id=0,umax_value=65535,var_off=(0x0; 0xffff)), since the shift is not sign | |
| 1229 | +extending. This logic is implemented in adjust_reg_min_max_vals() function, | |
| 1230 | +which calls adjust_ptr_min_max_vals() for adding pointer to scalar (or vice | |
| 1231 | +versa) and adjust_scalar_min_max_vals() for operations on two scalars. | |
| 1158 | 1232 | |
| 1159 | 1233 | The end result is that bpf program author can access packet directly |
| 1160 | 1234 | using normal C code as: |
| @@ -1214,6 +1288,22 @@ The map is defined by: · 53 unmodified lines | ||
| 1214 | 1288 | . key size in bytes |
| 1215 | 1289 | . value size in bytes |
| 1216 | 1290 | |
| 1291 | +Pruning | |
| 1292 | +------- | |
| 1293 | +The verifier does not actually walk all possible paths through the program. For | |
| 1294 | +each new branch to analyse, the verifier looks at all the states it's previously | |
| 1295 | +been in when at this instruction. If any of them contain the current state as a | |
| 1296 | +subset, the branch is 'pruned' - that is, the fact that the previous state was | |
| 1297 | +accepted implies the current state would be as well. For instance, if in the | |
| 1298 | +previous state, r1 held a packet-pointer, and in the current state, r1 holds a | |
| 1299 | +packet-pointer with a range as long or longer and at least as strict an | |
| 1300 | +alignment, then r1 is safe. Similarly, if r2 was NOT_INIT before then it can't | |
| 1301 | +have been used by any path from that point, so any value in r2 (including | |
| 1302 | +another NOT_INIT) is safe. The implementation is in the function regsafe(). | |
| 1303 | +Pruning considers not only the registers but also the stack (and any spilled | |
| 1304 | +registers it may hold). They must all be safe for the branch to be pruned. | |
| 1305 | +This is implemented in states_equal(). | |
| 1306 | + | |
| 1217 | 1307 | Understanding eBPF verifier messages |
| 1218 | 1308 | ------------------------------------ |
| 1219 | 1309 | |
| @@ -0,0 +1,125 @@ | ||
| 1 | +Linux Kernel Driver for Huawei Intelligent NIC(HiNIC) family | |
| 2 | +============================================================ | |
| 3 | + | |
| 4 | +Overview: | |
| 5 | +========= | |
| 6 | +HiNIC is a network interface card for the Data Center Area. | |
| 7 | + | |
| 8 | +The driver supports a range of link-speed devices (10GbE, 25GbE, 40GbE, etc.). | |
| 9 | +The driver supports also a negotiated and extendable feature set. | |
| 10 | + | |
| 11 | +Some HiNIC devices support SR-IOV. This driver is used for Physical Function | |
| 12 | +(PF). | |
| 13 | + | |
| 14 | +HiNIC devices support MSI-X interrupt vector for each Tx/Rx queue and | |
| 15 | +adaptive interrupt moderation. | |
| 16 | + | |
| 17 | +HiNIC devices support also various offload features such as checksum offload, | |
| 18 | +TCP Transmit Segmentation Offload(TSO), Receive-Side Scaling(RSS) and | |
| 19 | +LRO(Large Receive Offload). | |
| 20 | + | |
| 21 | + | |
| 22 | +Supported PCI vendor ID/device IDs: | |
| 23 | +=================================== | |
| 24 | + | |
| 25 | +19e5:1822 - HiNIC PF | |
| 26 | + | |
| 27 | + | |
| 28 | +Driver Architecture and Source Code: | |
| 29 | +==================================== | |
| 30 | + | |
| 31 | +hinic_dev - Implement a Logical Network device that is independent from | |
| 32 | +specific HW details about HW data structure formats. | |
| 33 | + | |
| 34 | +hinic_hwdev - Implement the HW details of the device and include the components | |
| 35 | +for accessing the PCI NIC. | |
| 36 | + | |
| 37 | +hinic_hwdev contains the following components: | |
| 38 | +=============================================== | |
| 39 | + | |
| 40 | +HW Interface: | |
| 41 | +============= | |
| 42 | + | |
| 43 | +The interface for accessing the pci device (DMA memory and PCI BARs). | |
| 44 | +(hinic_hw_if.c, hinic_hw_if.h) | |
| 45 | + | |
| 46 | +Configuration Status Registers Area that describes the HW Registers on the | |
| 47 | +configuration and status BAR0. (hinic_hw_csr.h) | |
| 48 | + | |
| 49 | +MGMT components: | |
| 50 | +================ | |
| 51 | + | |
| 52 | +Asynchronous Event Queues(AEQs) - The event queues for receiving messages from | |
| 53 | +the MGMT modules on the cards. (hinic_hw_eqs.c, hinic_hw_eqs.h) | |
| 54 | + | |
| 55 | +Application Programmable Interface commands(API CMD) - Interface for sending | |
| 56 | +MGMT commands to the card. (hinic_hw_api_cmd.c, hinic_hw_api_cmd.h) | |
| 57 | + | |
| 58 | +Management (MGMT) - the PF to MGMT channel that uses API CMD for sending MGMT | |
| 59 | +commands to the card and receives notifications from the MGMT modules on the | |
| 60 | +card by AEQs. Also set the addresses of the IO CMDQs in HW. | |
| 61 | +(hinic_hw_mgmt.c, hinic_hw_mgmt.h) | |
| 62 | + | |
| 63 | +IO components: | |
| 64 | +============== | |
| 65 | + | |
| 66 | +Completion Event Queues(CEQs) - The completion Event Queues that describe IO | |
| 67 | +tasks that are finished. (hinic_hw_eqs.c, hinic_hw_eqs.h) | |
| 68 | + | |
| 69 | +Work Queues(WQ) - Contain the memory and operations for use by CMD queues and | |
| 70 | +the Queue Pairs. The WQ is a Memory Block in a Page. The Block contains | |
| 71 | +pointers to Memory Areas that are the Memory for the Work Queue Elements(WQEs). | |
| 72 | +(hinic_hw_wq.c, hinic_hw_wq.h) | |
| 73 | + | |
| 74 | +Command Queues(CMDQ) - The queues for sending commands for IO management and is | |
| 75 | +used to set the QPs addresses in HW. The commands completion events are | |
| 76 | +accumulated on the CEQ that is configured to receive the CMDQ completion events. | |
| 77 | +(hinic_hw_cmdq.c, hinic_hw_cmdq.h) | |
| 78 | + | |
| 79 | +Queue Pairs(QPs) - The HW Receive and Send queues for Receiving and Transmitting | |
| 80 | +Data. (hinic_hw_qp.c, hinic_hw_qp.h, hinic_hw_qp_ctxt.h) | |
| 81 | + | |
| 82 | +IO - de/constructs all the IO components. (hinic_hw_io.c, hinic_hw_io.h) | |
| 83 | + | |
| 84 | +HW device: | |
| 85 | +========== | |
| 86 | + | |
| 87 | +HW device - de/constructs the HW Interface, the MGMT components on the | |
| 88 | +initialization of the driver and the IO components on the case of Interface | |
| 89 | +UP/DOWN Events. (hinic_hw_dev.c, hinic_hw_dev.h) | |
| 90 | + | |
| 91 | + | |
| 92 | +hinic_dev contains the following components: | |
| 93 | +=============================================== | |
| 94 | + | |
| 95 | +PCI ID table - Contains the supported PCI Vendor/Device IDs. | |
| 96 | +(hinic_pci_tbl.h) | |
| 97 | + | |
| 98 | +Port Commands - Send commands to the HW device for port management | |
| 99 | +(MAC, Vlan, MTU, ...). (hinic_port.c, hinic_port.h) | |
| 100 | + | |
| 101 | +Tx Queues - Logical Tx Queues that use the HW Send Queues for transmit. | |
| 102 | +The Logical Tx queue is not dependent on the format of the HW Send Queue. | |
| 103 | +(hinic_tx.c, hinic_tx.h) | |
| 104 | + | |
| 105 | +Rx Queues - Logical Rx Queues that use the HW Receive Queues for receive. | |
| 106 | +The Logical Rx queue is not dependent on the format of the HW Receive Queue. | |
| 107 | +(hinic_rx.c, hinic_rx.h) | |
| 108 | + | |
| 109 | +hinic_dev - de/constructs the Logical Tx and Rx Queues. | |
| 110 | +(hinic_main.c, hinic_dev.h) | |
| 111 | + | |
| 112 | + | |
| 113 | +Miscellaneous: | |
| 114 | +============= | |
| 115 | + | |
| 116 | +Common functions that are used by HW and Logical Device. | |
| 117 | +(hinic_common.c, hinic_common.h) | |
| 118 | + | |
| 119 | + | |
| 120 | +Support | |
| 121 | +======= | |
| 122 | + | |
| 123 | +If an issue is identified with the released source code on the supported kernel | |
| 124 | +with a supported adapter, email the specific information related to the issue to | |
| 125 | +aviad.krawczyk@huawei.com. | |
| @@ -84,17 +84,17 @@ Device drivers API · 83 unmodified lines | ||
| 84 | 84 | ================== |
| 85 | 85 | |
| 86 | 86 | The include/net/mac802154.h defines following functions: |
| 87 | − - struct ieee802154_dev *ieee802154_alloc_device | |
| 88 | − (size_t priv_size, struct ieee802154_ops *ops): | |
| 89 | − allocation of IEEE 802.15.4 compatible device | |
| 87 | + - struct ieee802154_hw * | |
| 88 | + ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops): | |
| 89 | + allocation of IEEE 802.15.4 compatible hardware device | |
| 90 | 90 | |
| 91 | − - void ieee802154_free_device(struct ieee802154_dev *dev): | |
| 92 | − freeing allocated device | |
| 91 | + - void ieee802154_free_hw(struct ieee802154_hw *hw): | |
| 92 | + freeing allocated hardware device | |
| 93 | 93 | |
| 94 | − - int ieee802154_register_device(struct ieee802154_dev *dev): | |
| 95 | − register PHY in the system | |
| 94 | + - int ieee802154_register_hw(struct ieee802154_hw *hw): | |
| 95 | + register PHY which is the allocated hardware device, in the system | |
| 96 | 96 | |
| 97 | − - void ieee802154_unregister_device(struct ieee802154_dev *dev): | |
| 97 | + - void ieee802154_unregister_hw(struct ieee802154_hw *hw): | |
| 98 | 98 | freeing registered PHY |
| 99 | 99 | |
| 100 | 100 | Moreover IEEE 802.15.4 device operations structure should be filled. |
| @@ -6,6 +6,7 @@ Contents: · 5 unmodified lines | ||
| 6 | 6 | .. toctree:: |
| 7 | 7 | :maxdepth: 2 |
| 8 | 8 | |
| 9 | + batman-adv | |
| 9 | 10 | kapi |
| 10 | 11 | z8530book |
| 11 | 12 | |
| @@ -109,7 +109,10 @@ neigh/default/unres_qlen_bytes - INTEGER · 108 unmodified lines | ||
| 109 | 109 | queued for each unresolved address by other network layers. |
| 110 | 110 | (added in linux 3.3) |
| 111 | 111 | Setting negative value is meaningless and will return error. |
| 112 | − Default: 65536 Bytes(64KB) | |
| 112 | + Default: SK_WMEM_MAX, (same as net.core.wmem_default). | |
| 113 | + Exact value depends on architecture and kernel options, | |
| 114 | + but should be enough to allow queuing 256 packets | |
| 115 | + of medium size. | |
| 113 | 116 | |
| 114 | 117 | neigh/default/unres_qlen - INTEGER |
| 115 | 118 | The maximum number of packets which may be queued for each |
| @@ -119,7 +122,7 @@ neigh/default/unres_qlen - INTEGER · 3 unmodified lines | ||
| 119 | 122 | unexpected packet loss. The current default value is calculated |
| 120 | 123 | according to default value of unres_qlen_bytes and true size of |
| 121 | 124 | packet. |
| 122 | − Default: 31 | |
| 125 | + Default: 101 | |
| 123 | 126 | |
| 124 | 127 | mtu_expires - INTEGER |
| 125 | 128 | Time, in seconds, that cached PMTU information is kept. |
| @@ -353,12 +356,7 @@ tcp_l3mdev_accept - BOOLEAN · 227 unmodified lines | ||
| 353 | 356 | compiled with CONFIG_NET_L3_MASTER_DEV. |
| 354 | 357 | |
| 355 | 358 | tcp_low_latency - BOOLEAN |
| 356 | − If set, the TCP stack makes decisions that prefer lower | |
| 357 | − latency as opposed to higher throughput. By default, this | |
| 358 | − option is not set meaning that higher throughput is preferred. | |
| 359 | − An example of an application where this default should be | |
| 360 | − changed would be a Beowulf compute cluster. | |
| 361 | − Default: 0 | |
| 359 | + This is a legacy option, it has no effect anymore. | |
| 362 | 360 | |
| 363 | 361 | tcp_max_orphans - INTEGER |
| 364 | 362 | Maximal number of TCP sockets not attached to any user file handle, |
| @@ -1291,8 +1289,7 @@ tag - INTEGER · 926 unmodified lines | ||
| 1291 | 1289 | xfrm4_gc_thresh - INTEGER |
| 1292 | 1290 | The threshold at which we will start garbage collecting for IPv4 |
| 1293 | 1291 | destination cache entries. At twice this value the system will |
| 1294 | − refuse new allocations. The value must be set below the flowcache | |
| 1295 | − limit (4096 * number of online cpus) to take effect. | |
| 1292 | + refuse new allocations. | |
| 1296 | 1293 | |
| 1297 | 1294 | igmp_link_local_mcast_reports - BOOLEAN |
| 1298 | 1295 | Enable IGMP reports for link local multicast groups in the |
| @@ -1356,6 +1353,15 @@ flowlabel_state_ranges - BOOLEAN · 57 unmodified lines | ||
| 1356 | 1353 | FALSE: disabled |
| 1357 | 1354 | Default: true |
| 1358 | 1355 | |
| 1356 | +flowlabel_reflect - BOOLEAN | |
| 1357 | + Automatically reflect the flow label. Needed for Path MTU | |
| 1358 | + Discovery to work with Equal Cost Multipath Routing in anycast | |
| 1359 | + environments. See RFC 7690 and: | |
| 1360 | + https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01 | |
| 1361 | + TRUE: enabled | |
| 1362 | + FALSE: disabled | |
| 1363 | + Default: FALSE | |
| 1364 | + | |
| 1359 | 1365 | anycast_src_echo_reply - BOOLEAN |
| 1360 | 1366 | Controls the use of anycast addresses as source addresses for ICMPv6 |
| 1361 | 1367 | echo reply |
| @@ -1674,6 +1680,9 @@ accept_dad - INTEGER · 312 unmodified lines | ||
| 1674 | 1680 | 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate |
| 1675 | 1681 | link-local address has been found. |
| 1676 | 1682 | |
| 1683 | + DAD operation and mode on a given interface will be selected according | |
| 1684 | + to the maximum value of conf/{all,interface}/accept_dad. | |
| 1685 | + | |
| 1677 | 1686 | force_tllao - BOOLEAN |
| 1678 | 1687 | Enable sending the target link-layer address option even when |
| 1679 | 1688 | responding to a unicast neighbor solicitation. |
| @@ -1721,16 +1730,23 @@ suppress_frag_ndisc - INTEGER · 41 unmodified lines | ||
| 1721 | 1730 | |
| 1722 | 1731 | optimistic_dad - BOOLEAN |
| 1723 | 1732 | Whether to perform Optimistic Duplicate Address Detection (RFC 4429). |
| 1724 | − 0: disabled (default) | |
| 1725 | − 1: enabled | |
| 1733 | + 0: disabled (default) | |
| 1734 | + 1: enabled | |
| 1735 | + | |
| 1736 | + Optimistic Duplicate Address Detection for the interface will be enabled | |
| 1737 | + if at least one of conf/{all,interface}/optimistic_dad is set to 1, | |
| 1738 | + it will be disabled otherwise. | |
| 1726 | 1739 | |
| 1727 | 1740 | use_optimistic - BOOLEAN |
| 1728 | 1741 | If enabled, do not classify optimistic addresses as deprecated during |
| 1729 | 1742 | source address selection. Preferred addresses will still be chosen |
| 1730 | 1743 | before optimistic addresses, subject to other ranking in the source |
| 1731 | 1744 | address selection algorithm. |
| 1732 | − 0: disabled (default) | |
| 1733 | − 1: enabled | |
| 1745 | + 0: disabled (default) | |
| 1746 | + 1: enabled | |
| 1747 | + | |
| 1748 | + This will be enabled if at least one of | |
| 1749 | + conf/{all,interface}/use_optimistic is set to 1, disabled otherwise. | |
| 1734 | 1750 | |
| 1735 | 1751 | stable_secret - IPv6 address |
| 1736 | 1752 | This IPv6 address will be used as a secret to generate IPv6 |
| @@ -1778,8 +1794,7 @@ ratelimit - INTEGER · 41 unmodified lines | ||
| 1778 | 1794 | xfrm6_gc_thresh - INTEGER |
| 1779 | 1795 | The threshold at which we will start garbage collecting for IPv6 |
| 1780 | 1796 | destination cache entries. At twice this value the system will |
| 1781 | − refuse new allocations. The value must be set below the flowcache | |
| 1782 | − limit (4096 * number of online cpus) to take effect. | |
| 1797 | + refuse new allocations. | |
| 1783 | 1798 | |
| 1784 | 1799 | |
| 1785 | 1800 | IPv6 Update by: |
| @@ -0,0 +1,257 @@ | ||
| 1 | + | |
| 2 | +============ | |
| 3 | +MSG_ZEROCOPY | |
| 4 | +============ | |
| 5 | + | |
| 6 | +Intro | |
| 7 | +===== | |
| 8 | + | |
| 9 | +The MSG_ZEROCOPY flag enables copy avoidance for socket send calls. | |
| 10 | +The feature is currently implemented for TCP sockets. | |
| 11 | + | |
| 12 | + | |
| 13 | +Opportunity and Caveats | |
| 14 | +----------------------- | |
| 15 | + | |
| 16 | +Copying large buffers between user process and kernel can be | |
| 17 | +expensive. Linux supports various interfaces that eschew copying, | |
| 18 | +such as sendpage and splice. The MSG_ZEROCOPY flag extends the | |
| 19 | +underlying copy avoidance mechanism to common socket send calls. | |
| 20 | + | |
| 21 | +Copy avoidance is not a free lunch. As implemented, with page pinning, | |
| 22 | +it replaces per byte copy cost with page accounting and completion | |
| 23 | +notification overhead. As a result, MSG_ZEROCOPY is generally only | |
| 24 | +effective at writes over around 10 KB. | |
| 25 | + | |
| 26 | +Page pinning also changes system call semantics. It temporarily shares | |
| 27 | +the buffer between process and network stack. Unlike with copying, the | |
| 28 | +process cannot immediately overwrite the buffer after system call | |
| 29 | +return without possibly modifying the data in flight. Kernel integrity | |
| 30 | +is not affected, but a buggy program can possibly corrupt its own data | |
| 31 | +stream. | |
| 32 | + | |
| 33 | +The kernel returns a notification when it is safe to modify data. | |
| 34 | +Converting an existing application to MSG_ZEROCOPY is not always as | |
| 35 | +trivial as just passing the flag, then. | |
| 36 | + | |
| 37 | + | |
| 38 | +More Info | |
| 39 | +--------- | |
| 40 | + | |
| 41 | +Much of this document was derived from a longer paper presented at | |
| 42 | +netdev 2.1. For more in-depth information see that paper and talk, | |
| 43 | +the excellent reporting over at LWN.net or read the original code. | |
| 44 | + | |
| 45 | + paper, slides, video | |
| 46 | + https://netdevconf.org/2.1/session.html?debruijn | |
| 47 | + | |
| 48 | + LWN article | |
| 49 | + https://lwn.net/Articles/726917/ | |
| 50 | + | |
| 51 | + patchset | |
| 52 | + [PATCH net-next v4 0/9] socket sendmsg MSG_ZEROCOPY | |
| 53 | + http://lkml.kernel.org/r/20170803202945.70750-1-willemdebruijn.kernel@gmail.com | |
| 54 | + | |
| 55 | + | |
| 56 | +Interface | |
| 57 | +========= | |
| 58 | + | |
| 59 | +Passing the MSG_ZEROCOPY flag is the most obvious step to enable copy | |
| 60 | +avoidance, but not the only one. | |
| 61 | + | |
| 62 | +Socket Setup | |
| 63 | +------------ | |
| 64 | + | |
| 65 | +The kernel is permissive when applications pass undefined flags to the | |
| 66 | +send system call. By default it simply ignores these. To avoid enabling | |
| 67 | +copy avoidance mode for legacy processes that accidentally already pass | |
| 68 | +this flag, a process must first signal intent by setting a socket option: | |
| 69 | + | |
| 70 | +:: | |
| 71 | + | |
| 72 | + if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one))) | |
| 73 | + error(1, errno, "setsockopt zerocopy"); | |
| 74 | + | |
| 75 | + | |
| 76 | +Transmission | |
| 77 | +------------ | |
| 78 | + | |
| 79 | +The change to send (or sendto, sendmsg, sendmmsg) itself is trivial. | |
| 80 | +Pass the new flag. | |
| 81 | + | |
| 82 | +:: | |
| 83 | + | |
| 84 | + ret = send(fd, buf, sizeof(buf), MSG_ZEROCOPY); | |
| 85 | + | |
| 86 | +A zerocopy failure will return -1 with errno ENOBUFS. This happens if | |
| 87 | +the socket option was not set, the socket exceeds its optmem limit or | |
| 88 | +the user exceeds its ulimit on locked pages. | |
| 89 | + | |
| 90 | + | |
| 91 | +Mixing copy avoidance and copying | |
| 92 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 93 | + | |
| 94 | +Many workloads have a mixture of large and small buffers. Because copy | |
| 95 | +avoidance is more expensive than copying for small packets, the | |
| 96 | +feature is implemented as a flag. It is safe to mix calls with the flag | |
| 97 | +with those without. | |
| 98 | + | |
| 99 | + | |
| 100 | +Notifications | |
| 101 | +------------- | |
| 102 | + | |
| 103 | +The kernel has to notify the process when it is safe to reuse a | |
| 104 | +previously passed buffer. It queues completion notifications on the | |
| 105 | +socket error queue, akin to the transmit timestamping interface. | |
| 106 | + | |
| 107 | +The notification itself is a simple scalar value. Each socket | |
| 108 | +maintains an internal unsigned 32-bit counter. Each send call with | |
| 109 | +MSG_ZEROCOPY that successfully sends data increments the counter. The | |
| 110 | +counter is not incremented on failure or if called with length zero. | |
| 111 | +The counter counts system call invocations, not bytes. It wraps after | |
| 112 | +UINT_MAX calls. | |
| 113 | + | |
| 114 | + | |
| 115 | +Notification Reception | |
| 116 | +~~~~~~~~~~~~~~~~~~~~~~ | |
| 117 | + | |
| 118 | +The below snippet demonstrates the API. In the simplest case, each | |
| 119 | +send syscall is followed by a poll and recvmsg on the error queue. | |
| 120 | + | |
| 121 | +Reading from the error queue is always a non-blocking operation. The | |
| 122 | +poll call is there to block until an error is outstanding. It will set | |
| 123 | +POLLERR in its output flags. That flag does not have to be set in the | |
| 124 | +events field. Errors are signaled unconditionally. | |
| 125 | + | |
| 126 | +:: | |
| 127 | + | |
| 128 | + pfd.fd = fd; | |
| 129 | + pfd.events = 0; | |
| 130 | + if (poll(&pfd, 1, -1) != 1 || pfd.revents & POLLERR == 0) | |
| 131 | + error(1, errno, "poll"); | |
| 132 | + | |
| 133 | + ret = recvmsg(fd, &msg, MSG_ERRQUEUE); | |
| 134 | + if (ret == -1) | |
| 135 | + error(1, errno, "recvmsg"); | |
| 136 | + | |
| 137 | + read_notification(msg); | |
| 138 | + | |
| 139 | +The example is for demonstration purpose only. In practice, it is more | |
| 140 | +efficient to not wait for notifications, but read without blocking | |
| 141 | +every couple of send calls. | |
| 142 | + | |
| 143 | +Notifications can be processed out of order with other operations on | |
| 144 | +the socket. A socket that has an error queued would normally block | |
| 145 | +other operations until the error is read. Zerocopy notifications have | |
| 146 | +a zero error code, however, to not block send and recv calls. | |
| 147 | + | |
| 148 | + | |
| 149 | +Notification Batching | |
| 150 | +~~~~~~~~~~~~~~~~~~~~~ | |
| 151 | + | |
| 152 | +Multiple outstanding packets can be read at once using the recvmmsg | |
| 153 | +call. This is often not needed. In each message the kernel returns not | |
| 154 | +a single value, but a range. It coalesces consecutive notifications | |
| 155 | +while one is outstanding for reception on the error queue. | |
| 156 | + | |
| 157 | +When a new notification is about to be queued, it checks whether the | |
| 158 | +new value extends the range of the notification at the tail of the | |
| 159 | +queue. If so, it drops the new notification packet and instead increases | |
| 160 | +the range upper value of the outstanding notification. | |
| 161 | + | |
| 162 | +For protocols that acknowledge data in-order, like TCP, each | |
| 163 | +notification can be squashed into the previous one, so that no more | |
| 164 | +than one notification is outstanding at any one point. | |
| 165 | + | |
| 166 | +Ordered delivery is the common case, but not guaranteed. Notifications | |
| 167 | +may arrive out of order on retransmission and socket teardown. | |
| 168 | + | |
| 169 | + | |
| 170 | +Notification Parsing | |
| 171 | +~~~~~~~~~~~~~~~~~~~~ | |
| 172 | + | |
| 173 | +The below snippet demonstrates how to parse the control message: the | |
| 174 | +read_notification() call in the previous snippet. A notification | |
| 175 | +is encoded in the standard error format, sock_extended_err. | |
| 176 | + | |
| 177 | +The level and type fields in the control data are protocol family | |
| 178 | +specific, IP_RECVERR or IPV6_RECVERR. | |
| 179 | + | |
| 180 | +Error origin is the new type SO_EE_ORIGIN_ZEROCOPY. ee_errno is zero, | |
| 181 | +as explained before, to avoid blocking read and write system calls on | |
| 182 | +the socket. | |
| 183 | + | |
| 184 | +The 32-bit notification range is encoded as [ee_info, ee_data]. This | |
| 185 | +range is inclusive. Other fields in the struct must be treated as | |
| 186 | +undefined, bar for ee_code, as discussed below. | |
| 187 | + | |
| 188 | +:: | |
| 189 | + | |
| 190 | + struct sock_extended_err *serr; | |
| 191 | + struct cmsghdr *cm; | |
| 192 | + | |
| 193 | + cm = CMSG_FIRSTHDR(msg); | |
| 194 | + if (cm->cmsg_level != SOL_IP && | |
| 195 | + cm->cmsg_type != IP_RECVERR) | |
| 196 | + error(1, 0, "cmsg"); | |
| 197 | + | |
| 198 | + serr = (void *) CMSG_DATA(cm); | |
| 199 | + if (serr->ee_errno != 0 || | |
| 200 | + serr->ee_origin != SO_EE_ORIGIN_ZEROCOPY) | |
| 201 | + error(1, 0, "serr"); | |
| 202 | + | |
| 203 | + printf("completed: %u..%u\n", serr->ee_info, serr->ee_data); | |
| 204 | + | |
| 205 | + | |
| 206 | +Deferred copies | |
| 207 | +~~~~~~~~~~~~~~~ | |
| 208 | + | |
| 209 | +Passing flag MSG_ZEROCOPY is a hint to the kernel to apply copy | |
| 210 | +avoidance, and a contract that the kernel will queue a completion | |
| 211 | +notification. It is not a guarantee that the copy is elided. | |
| 212 | + | |
| 213 | +Copy avoidance is not always feasible. Devices that do not support | |
| 214 | +scatter-gather I/O cannot send packets made up of kernel generated | |
| 215 | +protocol headers plus zerocopy user data. A packet may need to be | |
| 216 | +converted to a private copy of data deep in the stack, say to compute | |
| 217 | +a checksum. | |
| 218 | + | |
| 219 | +In all these cases, the kernel returns a completion notification when | |
| 220 | +it releases its hold on the shared pages. That notification may arrive | |
| 221 | +before the (copied) data is fully transmitted. A zerocopy completion | |
| 222 | +notification is not a transmit completion notification, therefore. | |
| 223 | + | |
| 224 | +Deferred copies can be more expensive than a copy immediately in the | |
| 225 | +system call, if the data is no longer warm in the cache. The process | |
| 226 | +also incurs notification processing cost for no benefit. For this | |
| 227 | +reason, the kernel signals if data was completed with a copy, by | |
| 228 | +setting flag SO_EE_CODE_ZEROCOPY_COPIED in field ee_code on return. | |
| 229 | +A process may use this signal to stop passing flag MSG_ZEROCOPY on | |
| 230 | +subsequent requests on the same socket. | |
| 231 | + | |
| 232 | + | |
| 233 | +Implementation | |
| 234 | +============== | |
| 235 | + | |
| 236 | +Loopback | |
| 237 | +-------- | |
| 238 | + | |
| 239 | +Data sent to local sockets can be queued indefinitely if the receive | |
| 240 | +process does not read its socket. Unbound notification latency is not | |
| 241 | +acceptable. For this reason all packets generated with MSG_ZEROCOPY | |
| 242 | +that are looped to a local socket will incur a deferred copy. This | |
| 243 | +includes looping onto packet sockets (e.g., tcpdump) and tun devices. | |
| 244 | + | |
| 245 | + | |
| 246 | +Testing | |
| 247 | +======= | |
| 248 | + | |
| 249 | +More realistic example code can be found in the kernel source under | |
| 250 | +tools/testing/selftests/net/msg_zerocopy.c. | |
| 251 | + | |
| 252 | +Be cognizant of the loopback constraint. The test can be run between | |
| 253 | +a pair of hosts. But if run between a local pair of processes, for | |
| 254 | +instance when run with msg_zerocopy.sh between a veth pair across | |
| 255 | +namespaces, the test will not show any improvement. For testing, the | |
| 256 | +loopback restriction can be temporarily relaxed by making | |
| 257 | +skb_orphan_frags_rx identical to skb_orphan_frags. | |
| @@ -111,6 +111,14 @@ A: Generally speaking, the patches get triaged quickly (in less than 48h). · 110 unmodified lines | ||
| 111 | 111 | patch is a good way to ensure your patch is ignored or pushed to |
| 112 | 112 | the bottom of the priority list. |
| 113 | 113 | |
| 114 | +Q: I submitted multiple versions of the patch series, should I directly update | |
| 115 | + patchwork for the previous versions of these patch series? | |
| 116 | + | |
| 117 | +A: No, please don't interfere with the patch status on patchwork, leave it to | |
| 118 | + the maintainer to figure out what is the most recent and current version that | |
| 119 | + should be applied. If there is any doubt, the maintainer will reply and ask | |
| 120 | + what should be done. | |
| 121 | + | |
| 114 | 122 | Q: How can I tell what patches are queued up for backporting to the |
| 115 | 123 | various stable releases? |
| 116 | 124 | |
| @@ -0,0 +1,75 @@ | ||
| 1 | +Hyper-V network driver | |
| 2 | +====================== | |
| 3 | + | |
| 4 | +Compatibility | |
| 5 | +============= | |
| 6 | + | |
| 7 | +This driver is compatible with Windows Server 2012 R2, 2016 and | |
| 8 | +Windows 10. | |
| 9 | + | |
| 10 | +Features | |
| 11 | +======== | |
| 12 | + | |
| 13 | + Checksum offload | |
| 14 | + ---------------- | |
| 15 | + The netvsc driver supports checksum offload as long as the | |
| 16 | + Hyper-V host version does. Windows Server 2016 and Azure | |
| 17 | + support checksum offload for TCP and UDP for both IPv4 and | |
| 18 | + IPv6. Windows Server 2012 only supports checksum offload for TCP. | |
| 19 | + | |
| 20 | + Receive Side Scaling | |
| 21 | + -------------------- | |
| 22 | + Hyper-V supports receive side scaling. For TCP, packets are | |
| 23 | + distributed among available queues based on IP address and port | |
| 24 | + number. | |
| 25 | + | |
| 26 | + For UDP, we can switch UDP hash level between L3 and L4 by ethtool | |
| 27 | + command. UDP over IPv4 and v6 can be set differently. The default | |
| 28 | + hash level is L4. We currently only allow switching TX hash level | |
| 29 | + from within the guests. | |
| 30 | + | |
| 31 | + On Azure, fragmented UDP packets have high loss rate with L4 | |
| 32 | + hashing. Using L3 hashing is recommended in this case. | |
| 33 | + | |
| 34 | + For example, for UDP over IPv4 on eth0: | |
| 35 | + To include UDP port numbers in hashing: | |
| 36 | + ethtool -N eth0 rx-flow-hash udp4 sdfn | |
| 37 | + To exclude UDP port numbers in hashing: | |
| 38 | + ethtool -N eth0 rx-flow-hash udp4 sd | |
| 39 | + To show UDP hash level: | |
| 40 | + ethtool -n eth0 rx-flow-hash udp4 | |
| 41 | + | |
| 42 | + Generic Receive Offload, aka GRO | |
| 43 | + -------------------------------- | |
| 44 | + The driver supports GRO and it is enabled by default. GRO coalesces | |
| 45 | + like packets and significantly reduces CPU usage under heavy Rx | |
| 46 | + load. | |
| 47 | + | |
| 48 | + SR-IOV support | |
| 49 | + -------------- | |
| 50 | + Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV | |
| 51 | + is enabled in both the vSwitch and the guest configuration, then the | |
| 52 | + Virtual Function (VF) device is passed to the guest as a PCI | |
| 53 | + device. In this case, both a synthetic (netvsc) and VF device are | |
| 54 | + visible in the guest OS and both NIC's have the same MAC address. | |
| 55 | + | |
| 56 | + The VF is enslaved by netvsc device. The netvsc driver will transparently | |
| 57 | + switch the data path to the VF when it is available and up. | |
| 58 | + Network state (addresses, firewall, etc) should be applied only to the | |
| 59 | + netvsc device; the slave device should not be accessed directly in | |
| 60 | + most cases. The exceptions are if some special queue discipline or | |
| 61 | + flow direction is desired, these should be applied directly to the | |
| 62 | + VF slave device. | |
| 63 | + | |
| 64 | + Receive Buffer | |
| 65 | + -------------- | |
| 66 | + Packets are received into a receive area which is created when device | |
| 67 | + is probed. The receive area is broken into MTU sized chunks and each may | |
| 68 | + contain one or more packets. The number of receive sections may be changed | |
| 69 | + via ethtool Rx ring parameters. | |
| 70 | + | |
| 71 | + There is a similar send buffer which is used to aggregate packets for sending. | |
| 72 | + The send area is broken into chunks of 6144 bytes, each of section may | |
| 73 | + contain one or more packets. The send buffer is an optimization, the driver | |
| 74 | + will use slower method to handle very large packets or if the send buffer | |
| 75 | + area is exhausted. | |
| @@ -96,17 +96,6 @@ nf_conntrack_max - INTEGER · 95 unmodified lines | ||
| 96 | 96 | Size of connection tracking table. Default value is |
| 97 | 97 | nf_conntrack_buckets value * 4. |
| 98 | 98 | |
| 99 | −nf_conntrack_default_on - BOOLEAN | |
| 100 | − 0 - don't register conntrack in new net namespaces | |
| 101 | − 1 - register conntrack in new net namespaces (default) | |
| 102 | − | |
| 103 | − This controls wheter newly created network namespaces have connection | |
| 104 | − tracking enabled by default. It will be enabled automatically | |
| 105 | − regardless of this setting if the new net namespace requires | |
| 106 | − connection tracking, e.g. when NAT rules are created. | |
| 107 | − This setting is only visible in initial user namespace, it has no | |
| 108 | − effect on existing namespaces. | |
| 109 | − | |
| 110 | 99 | nf_conntrack_tcp_be_liberal - BOOLEAN |
| 111 | 100 | 0 - disabled (default) |
| 112 | 101 | not 0 - enabled |
| @@ -0,0 +1,82 @@ | ||
| 1 | +1. Introduction | |
| 2 | + | |
| 3 | +rmnet driver is used for supporting the Multiplexing and aggregation | |
| 4 | +Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm | |
| 5 | +Technologies, Inc. modems. | |
| 6 | + | |
| 7 | +This driver can be used to register onto any physical network device in | |
| 8 | +IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator. | |
| 9 | + | |
| 10 | +Multiplexing allows for creation of logical netdevices (rmnet devices) to | |
| 11 | +handle multiple private data networks (PDN) like a default internet, tethering, | |
| 12 | +multimedia messaging service (MMS) or IP media subsystem (IMS). Hardware sends | |
| 13 | +packets with MAP headers to rmnet. Based on the multiplexer id, rmnet | |
| 14 | +routes to the appropriate PDN after removing the MAP header. | |
| 15 | + | |
| 16 | +Aggregation is required to achieve high data rates. This involves hardware | |
| 17 | +sending aggregated bunch of MAP frames. rmnet driver will de-aggregate | |
| 18 | +these MAP frames and send them to appropriate PDN's. | |
| 19 | + | |
| 20 | +2. Packet format | |
| 21 | + | |
| 22 | +a. MAP packet (data / control) | |
| 23 | + | |
| 24 | +MAP header has the same endianness of the IP packet. | |
| 25 | + | |
| 26 | +Packet format - | |
| 27 | + | |
| 28 | +Bit 0 1 2-7 8 - 15 16 - 31 | |
| 29 | +Function Command / Data Reserved Pad Multiplexer ID Payload length | |
| 30 | +Bit 32 - x | |
| 31 | +Function Raw Bytes | |
| 32 | + | |
| 33 | +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command | |
| 34 | +or data packet. Control packet is used for transport level flow control. Data | |
| 35 | +packets are standard IP packets. | |
| 36 | + | |
| 37 | +Reserved bits are usually zeroed out and to be ignored by receiver. | |
| 38 | + | |
| 39 | +Padding is number of bytes to be added for 4 byte alignment if required by | |
| 40 | +hardware. | |
| 41 | + | |
| 42 | +Multiplexer ID is to indicate the PDN on which data has to be sent. | |
| 43 | + | |
| 44 | +Payload length includes the padding length but does not include MAP header | |
| 45 | +length. | |
| 46 | + | |
| 47 | +b. MAP packet (command specific) | |
| 48 | + | |
| 49 | +Bit 0 1 2-7 8 - 15 16 - 31 | |
| 50 | +Function Command Reserved Pad Multiplexer ID Payload length | |
| 51 | +Bit 32 - 39 40 - 45 46 - 47 48 - 63 | |
| 52 | +Function Command name Reserved Command Type Reserved | |
| 53 | +Bit 64 - 95 | |
| 54 | +Function Transaction ID | |
| 55 | +Bit 96 - 127 | |
| 56 | +Function Command data | |
| 57 | + | |
| 58 | +Command 1 indicates disabling flow while 2 is enabling flow | |
| 59 | + | |
| 60 | +Command types - | |
| 61 | +0 for MAP command request | |
| 62 | +1 is to acknowledge the receipt of a command | |
| 63 | +2 is for unsupported commands | |
| 64 | +3 is for error during processing of commands | |
| 65 | + | |
| 66 | +c. Aggregation | |
| 67 | + | |
| 68 | +Aggregation is multiple MAP packets (can be data or command) delivered to | |
| 69 | +rmnet in a single linear skb. rmnet will process the individual | |
| 70 | +packets and either ACK the MAP command or deliver the IP packet to the | |
| 71 | +network stack as needed | |
| 72 | + | |
| 73 | +MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding.... | |
| 74 | +MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad... | |
| 75 | + | |
| 76 | +3. Userspace configuration | |
| 77 | + | |
| 78 | +rmnet userspace configuration is done through netlink library librmnetctl | |
| 79 | +and command line utility rmnetcli. Utility is hosted in codeaurora forum git. | |
| 80 | +The driver uses rtnl_link_ops for communication. | |
| 81 | + | |
| 82 | +https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/dataservices/tree/rmnetctl | |
| @@ -818,10 +818,15 @@ The kernel interface functions are as follows: · 817 unmodified lines | ||
| 818 | 818 | |
| 819 | 819 | (*) Send data through a call. |
| 820 | 820 | |
| 821 | + typedef void (*rxrpc_notify_end_tx_t)(struct sock *sk, | |
| 822 | + unsigned long user_call_ID, | |
| 823 | + struct sk_buff *skb); | |
| 824 | + | |
| 821 | 825 | int rxrpc_kernel_send_data(struct socket *sock, |
| 822 | 826 | struct rxrpc_call *call, |
| 823 | 827 | struct msghdr *msg, |
| 824 | − size_t len); | |
| 828 | + size_t len, | |
| 829 | + rxrpc_notify_end_tx_t notify_end_rx); | |
| 825 | 830 | |
| 826 | 831 | This is used to supply either the request part of a client call or the |
| 827 | 832 | reply part of a server call. msg.msg_iovlen and msg.msg_iov specify the |
| @@ -832,6 +837,11 @@ The kernel interface functions are as follows: · 4 unmodified lines | ||
| 832 | 837 | The msg must not specify a destination address, control data or any flags |
| 833 | 838 | other than MSG_MORE. len is the total amount of data to transmit. |
| 834 | 839 | |
| 840 | + notify_end_rx can be NULL or it can be used to specify a function to be | |
| 841 | + called when the call changes state to end the Tx phase. This function is | |
| 842 | + called with the call-state spinlock held to prevent any reply or final ACK | |
| 843 | + from being delivered first. | |
| 844 | + | |
| 835 | 845 | (*) Receive data from a call. |
| 836 | 846 | |
| 837 | 847 | int rxrpc_kernel_recv_data(struct socket *sock, |
| @@ -965,6 +975,51 @@ The kernel interface functions are as follows: · 127 unmodified lines | ||
| 965 | 975 | size should be set when the call is begun. tx_total_len may not be less |
| 966 | 976 | than zero. |
| 967 | 977 | |
| 978 | + (*) Check to see the completion state of a call so that the caller can assess | |
| 979 | + whether it needs to be retried. | |
| 980 | + | |
| 981 | + enum rxrpc_call_completion { | |
| 982 | + RXRPC_CALL_SUCCEEDED, | |
| 983 | + RXRPC_CALL_REMOTELY_ABORTED, | |
| 984 | + RXRPC_CALL_LOCALLY_ABORTED, | |
| 985 | + RXRPC_CALL_LOCAL_ERROR, | |
| 986 | + RXRPC_CALL_NETWORK_ERROR, | |
| 987 | + }; | |
| 988 | + | |
| 989 | + int rxrpc_kernel_check_call(struct socket *sock, struct rxrpc_call *call, | |
| 990 | + enum rxrpc_call_completion *_compl, | |
| 991 | + u32 *_abort_code); | |
| 992 | + | |
| 993 | + On return, -EINPROGRESS will be returned if the call is still ongoing; if | |
| 994 | + it is finished, *_compl will be set to indicate the manner of completion, | |
| 995 | + *_abort_code will be set to any abort code that occurred. 0 will be | |
| 996 | + returned on a successful completion, -ECONNABORTED will be returned if the | |
| 997 | + client failed due to a remote abort and anything else will return an | |
| 998 | + appropriate error code. | |
| 999 | + | |
| 1000 | + The caller should look at this information to decide if it's worth | |
| 1001 | + retrying the call. | |
| 1002 | + | |
| 1003 | + (*) Retry a client call. | |
| 1004 | + | |
| 1005 | + int rxrpc_kernel_retry_call(struct socket *sock, | |
| 1006 | + struct rxrpc_call *call, | |
| 1007 | + struct sockaddr_rxrpc *srx, | |
| 1008 | + struct key *key); | |
| 1009 | + | |
| 1010 | + This attempts to partially reinitialise a call and submit it again whilst | |
| 1011 | + reusing the original call's Tx queue to avoid the need to repackage and | |
| 1012 | + re-encrypt the data to be sent. call indicates the call to retry, srx the | |
| 1013 | + new address to send it to and key the encryption key to use for signing or | |
| 1014 | + encrypting the packets. | |
| 1015 | + | |
| 1016 | + For this to work, the first Tx data packet must still be in the transmit | |
| 1017 | + queue, and currently this is only permitted for local and network errors | |
| 1018 | + and the call must not have been aborted. Any partially constructed Tx | |
| 1019 | + packet is left as is and can continue being filled afterwards. | |
| 1020 | + | |
| 1021 | + It returns 0 if the call was requeued and an error otherwise. | |
| 1022 | + | |
| 968 | 1023 | |
| 969 | 1024 | ======================= |
| 970 | 1025 | CONFIGURABLE PARAMETERS |
| @@ -1,45 +1,107 @@ | ||
| 1 | −Stream Parser | |
| 2 | −------------- | |
| 1 | +Stream Parser (strparser) | |
| 2 | + | |
| 3 | +Introduction | |
| 4 | +============ | |
| 3 | 5 | |
| 4 | 6 | The stream parser (strparser) is a utility that parses messages of an |
| 5 | −application layer protocol running over a TCP connection. The stream | |
| 7 | +application layer protocol running over a data stream. The stream | |
| 6 | 8 | parser works in conjunction with an upper layer in the kernel to provide |
| 7 | 9 | kernel support for application layer messages. For instance, Kernel |
| 8 | 10 | Connection Multiplexor (KCM) uses the Stream Parser to parse messages |
| 9 | 11 | using a BPF program. |
| 10 | 12 | |
| 13 | +The strparser works in one of two modes: receive callback or general | |
| 14 | +mode. | |
| 15 | + | |
| 16 | +In receive callback mode, the strparser is called from the data_ready | |
| 17 | +callback of a TCP socket. Messages are parsed and delivered as they are | |
| 18 | +received on the socket. | |
| 19 | + | |
| 20 | +In general mode, a sequence of skbs are fed to strparser from an | |
| 21 | +outside source. Message are parsed and delivered as the sequence is | |
| 22 | +processed. This modes allows strparser to be applied to arbitrary | |
| 23 | +streams of data. | |
| 24 | + | |
| 11 | 25 | Interface |
| 12 | −--------- | |
| 26 | +========= | |
| 13 | 27 | |
| 14 | 28 | The API includes a context structure, a set of callbacks, utility |
| 15 | −functions, and a data_ready function. The callbacks include | |
| 16 | −a parse_msg function that is called to perform parsing (e.g. | |
| 17 | −BPF parsing in case of KCM), and a rcv_msg function that is called | |
| 18 | −when a full message has been completed. | |
| 29 | +functions, and a data_ready function for receive callback mode. The | |
| 30 | +callbacks include a parse_msg function that is called to perform | |
| 31 | +parsing (e.g. BPF parsing in case of KCM), and a rcv_msg function | |
| 32 | +that is called when a full message has been completed. | |
| 33 | + | |
| 34 | +Functions | |
| 35 | +========= | |
| 36 | + | |
| 37 | +strp_init(struct strparser *strp, struct sock *sk, | |
| 38 | + const struct strp_callbacks *cb) | |
| 39 | + | |
| 40 | + Called to initialize a stream parser. strp is a struct of type | |
| 41 | + strparser that is allocated by the upper layer. sk is the TCP | |
| 42 | + socket associated with the stream parser for use with receive | |
| 43 | + callback mode; in general mode this is set to NULL. Callbacks | |
| 44 | + are called by the stream parser (the callbacks are listed below). | |
| 45 | + | |
| 46 | +void strp_pause(struct strparser *strp) | |
| 47 | + | |
| 48 | + Temporarily pause a stream parser. Message parsing is suspended | |
| 49 | + and no new messages are delivered to the upper layer. | |
| 50 | + | |
| 51 | +void strp_pause(struct strparser *strp) | |
| 52 | + | |
| 53 | + Unpause a paused stream parser. | |
| 54 | + | |
| 55 | +void strp_stop(struct strparser *strp); | |
| 56 | + | |
| 57 | + strp_stop is called to completely stop stream parser operations. | |
| 58 | + This is called internally when the stream parser encounters an | |
| 59 | + error, and it is called from the upper layer to stop parsing | |
| 60 | + operations. | |
| 61 | + | |
| 62 | +void strp_done(struct strparser *strp); | |
| 63 | + | |
| 64 | + strp_done is called to release any resources held by the stream | |
| 65 | + parser instance. This must be called after the stream processor | |
| 66 | + has been stopped. | |
| 19 | 67 | |
| 20 | −A stream parser can be instantiated for a TCP connection. This is done | |
| 21 | −by: | |
| 68 | +int strp_process(struct strparser *strp, struct sk_buff *orig_skb, | |
| 69 | + unsigned int orig_offset, size_t orig_len, | |
| 70 | + size_t max_msg_size, long timeo) | |
| 22 | 71 | |
| 23 | −strp_init(struct strparser *strp, struct sock *csk, | |
| 24 | − struct strp_callbacks *cb) | |
| 72 | + strp_process is called in general mode for a stream parser to | |
| 73 | + parse an sk_buff. The number of bytes processed or a negative | |
| 74 | + error number is returned. Note that strp_process does not | |
| 75 | + consume the sk_buff. max_msg_size is maximum size the stream | |
| 76 | + parser will parse. timeo is timeout for completing a message. | |
| 25 | 77 | |
| 26 | −strp is a struct of type strparser that is allocated by the upper layer. | |
| 27 | −csk is the TCP socket associated with the stream parser. Callbacks are | |
| 28 | −called by the stream parser. | |
| 78 | +void strp_data_ready(struct strparser *strp); | |
| 79 | + | |
| 80 | + The upper layer calls strp_tcp_data_ready when data is ready on | |
| 81 | + the lower socket for strparser to process. This should be called | |
| 82 | + from a data_ready callback that is set on the socket. Note that | |
| 83 | + maximum messages size is the limit of the receive socket | |
| 84 | + buffer and message timeout is the receive timeout for the socket. | |
| 85 | + | |
| 86 | +void strp_check_rcv(struct strparser *strp); | |
| 87 | + | |
| 88 | + strp_check_rcv is called to check for new messages on the socket. | |
| 89 | + This is normally called at initialization of a stream parser | |
| 90 | + instance or after strp_unpause. | |
| 29 | 91 | |
| 30 | 92 | Callbacks |
| 31 | −--------- | |
| 93 | +========= | |
| 32 | 94 | |
| 33 | −There are four callbacks: | |
| 95 | +There are six callbacks: | |
| 34 | 96 | |
| 35 | 97 | int (*parse_msg)(struct strparser *strp, struct sk_buff *skb); |
| 36 | 98 | |
| 37 | 99 | parse_msg is called to determine the length of the next message |
| 38 | 100 | in the stream. The upper layer must implement this function. It |
| 39 | 101 | should parse the sk_buff as containing the headers for the |
| 40 | − next application layer messages in the stream. | |
| 102 | + next application layer message in the stream. | |
| 41 | 103 | |
| 42 | − The skb->cb in the input skb is a struct strp_rx_msg. Only | |
| 104 | + The skb->cb in the input skb is a struct strp_msg. Only | |
| 43 | 105 | the offset field is relevant in parse_msg and gives the offset |
| 44 | 106 | where the message starts in the skb. |
| 45 | 107 | |
| @@ -50,26 +112,41 @@ int (*parse_msg)(struct strparser *strp, struct sk_buff *skb); · 4 unmodified lines | ||
| 50 | 112 | -ESTRPIPE : current message should not be processed by the |
| 51 | 113 | kernel, return control of the socket to userspace which |
| 52 | 114 | can proceed to read the messages itself |
| 53 | − other < 0 : Error is parsing, give control back to userspace | |
| 115 | + other < 0 : Error in parsing, give control back to userspace | |
| 54 | 116 | assuming that synchronization is lost and the stream |
| 55 | 117 | is unrecoverable (application expected to close TCP socket) |
| 56 | 118 | |
| 57 | 119 | In the case that an error is returned (return value is less than |
| 58 | − zero) the stream parser will set the error on TCP socket and wake | |
| 59 | − it up. If parse_msg returned -ESTRPIPE and the stream parser had | |
| 60 | − previously read some bytes for the current message, then the error | |
| 61 | − set on the attached socket is ENODATA since the stream is | |
| 62 | − unrecoverable in that case. | |
| 120 | + zero) and the parser is in receive callback mode, then it will set | |
| 121 | + the error on TCP socket and wake it up. If parse_msg returned | |
| 122 | + -ESTRPIPE and the stream parser had previously read some bytes for | |
| 123 | + the current message, then the error set on the attached socket is | |
| 124 | + ENODATA since the stream is unrecoverable in that case. | |
| 125 | + | |
| 126 | +void (*lock)(struct strparser *strp) | |
| 127 | + | |
| 128 | + The lock callback is called to lock the strp structure when | |
| 129 | + the strparser is performing an asynchronous operation (such as | |
| 130 | + processing a timeout). In receive callback mode the default | |
| 131 | + function is to lock_sock for the associated socket. In general | |
| 132 | + mode the callback must be set appropriately. | |
| 133 | + | |
| 134 | +void (*unlock)(struct strparser *strp) | |
| 135 | + | |
| 136 | + The unlock callback is called to release the lock obtained | |
| 137 | + by the lock callback. In receive callback mode the default | |
| 138 | + function is release_sock for the associated socket. In general | |
| 139 | + mode the callback must be set appropriately. | |
| 63 | 140 | |
| 64 | 141 | void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb); |
| 65 | 142 | |
| 66 | 143 | rcv_msg is called when a full message has been received and |
| 67 | 144 | is queued. The callee must consume the sk_buff; it can |
| 68 | 145 | call strp_pause to prevent any further messages from being |
| 69 | − received in rcv_msg (see strp_pause below). This callback | |
| 146 | + received in rcv_msg (see strp_pause above). This callback | |
| 70 | 147 | must be set. |
| 71 | 148 | |
| 72 | − The skb->cb in the input skb is a struct strp_rx_msg. This | |
| 149 | + The skb->cb in the input skb is a struct strp_msg. This | |
| 73 | 150 | struct contains two fields: offset and full_len. Offset is |
| 74 | 151 | where the message starts in the skb, and full_len is the |
| 75 | 152 | the length of the message. skb->len - offset may be greater |
| @@ -78,59 +155,53 @@ void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb); · 2 unmodified lines | ||
| 78 | 155 | int (*read_sock_done)(struct strparser *strp, int err); |
| 79 | 156 | |
| 80 | 157 | read_sock_done is called when the stream parser is done reading |
| 81 | − the TCP socket. The stream parser may read multiple messages | |
| 82 | − in a loop and this function allows cleanup to occur when existing | |
| 83 | − the loop. If the callback is not set (NULL in strp_init) a | |
| 84 | − default function is used. | |
| 158 | + the TCP socket in receive callback mode. The stream parser may | |
| 159 | + read multiple messages in a loop and this function allows cleanup | |
| 160 | + to occur when exiting the loop. If the callback is not set (NULL | |
| 161 | + in strp_init) a default function is used. | |
| 85 | 162 | |
| 86 | 163 | void (*abort_parser)(struct strparser *strp, int err); |
| 87 | 164 | |
| 88 | 165 | This function is called when stream parser encounters an error |
| 89 | − in parsing. The default function stops the stream parser for the | |
| 90 | − TCP socket and sets the error in the socket. The default function | |
| 91 | − can be changed by setting the callback to non-NULL in strp_init. | |
| 166 | + in parsing. The default function stops the stream parser and | |
| 167 | + sets the error in the socket if the parser is in receive callback | |
| 168 | + mode. The default function can be changed by setting the callback | |
| 169 | + to non-NULL in strp_init. | |
| 92 | 170 | |
| 93 | −Functions | |
| 94 | −--------- | |
| 171 | +Statistics | |
| 172 | +========== | |
| 95 | 173 | |
| 96 | −The upper layer calls strp_tcp_data_ready when data is ready on the lower | |
| 97 | −socket for strparser to process. This should be called from a data_ready | |
| 98 | −callback that is set on the socket. | |
| 174 | +Various counters are kept for each stream parser instance. These are in | |
| 175 | +the strp_stats structure. strp_aggr_stats is a convenience structure for | |
| 176 | +accumulating statistics for multiple stream parser instances. | |
| 177 | +save_strp_stats and aggregate_strp_stats are helper functions to save | |
| 178 | +and aggregate statistics. | |
| 99 | 179 | |
| 100 | −strp_stop is called to completely stop stream parser operations. This | |
| 101 | −is called internally when the stream parser encounters an error, and | |
| 102 | −it is called from the upper layer when unattaching a TCP socket. | |
| 180 | +Message assembly limits | |
| 181 | +======================= | |
| 103 | 182 | |
| 104 | −strp_done is called to unattach the stream parser from the TCP socket. | |
| 105 | −This must be called after the stream processor has be stopped. | |
| 183 | +The stream parser provide mechanisms to limit the resources consumed by | |
| 184 | +message assembly. | |
| 106 | 185 | |
| 107 | −strp_check_rcv is called to check for new messages on the socket. This | |
| 108 | −is normally called at initialization of the a stream parser instance | |
| 109 | −of after strp_unpause. | |
| 186 | +A timer is set when assembly starts for a new message. In receive | |
| 187 | +callback mode the message timeout is taken from rcvtime for the | |
| 188 | +associated TCP socket. In general mode, the timeout is passed as an | |
| 189 | +argument in strp_process. If the timer fires before assembly completes | |
| 190 | +the stream parser is aborted and the ETIMEDOUT error is set on the TCP | |
| 191 | +socket if in receive callback mode. | |
| 110 | 192 | |
| 111 | −Statistics | |
| 112 | −---------- | |
| 193 | +In receive callback mode, message length is limited to the receive | |
| 194 | +buffer size of the associated TCP socket. If the length returned by | |
| 195 | +parse_msg is greater than the socket buffer size then the stream parser | |
| 196 | +is aborted with EMSGSIZE error set on the TCP socket. Note that this | |
| 197 | +makes the maximum size of receive skbuffs for a socket with a stream | |
| 198 | +parser to be 2*sk_rcvbuf of the TCP socket. | |
| 113 | 199 | |
| 114 | −Various counters are kept for each stream parser for a TCP socket. | |
| 115 | −These are in the strp_stats structure. strp_aggr_stats is a convenience | |
| 116 | −structure for accumulating statistics for multiple stream parser | |
| 117 | −instances. save_strp_stats and aggregate_strp_stats are helper functions | |
| 118 | −to save and aggregate statistics. | |
| 200 | +In general mode the message length limit is passed in as an argument | |
| 201 | +to strp_process. | |
| 119 | 202 | |
| 120 | −Message assembly limits | |
| 121 | −----------------------- | |
| 203 | +Author | |
| 204 | +====== | |
| 122 | 205 | |
| 123 | −The stream parser provide mechanisms to limit the resources consumed by | |
| 124 | −message assembly. | |
| 206 | +Tom Herbert (tom@quantonium.net) | |
| 125 | 207 | |
| 126 | −A timer is set when assembly starts for a new message. The message | |
| 127 | −timeout is taken from rcvtime for the associated TCP socket. If the | |
| 128 | −timer fires before assembly completes the stream parser is aborted | |
| 129 | −and the ETIMEDOUT error is set on the TCP socket. | |
| 130 | − | |
| 131 | −Message length is limited to the receive buffer size of the associated | |
| 132 | −TCP socket. If the length returned by parse_msg is greater than | |
| 133 | −the socket buffer size then the stream parser is aborted with | |
| 134 | −EMSGSIZE error set on the TCP socket. Note that this makes the | |
| 135 | −maximum size of receive skbuffs for a socket with a stream parser | |
| 136 | −to be 2*sk_rcvbuf of the TCP socket. | |
| @@ -13,42 +13,42 @@ an example setup using a data-center-class switch ASIC chip. Other setups · 12 unmodified lines | ||
| 13 | 13 | with SR-IOV or soft switches, such as OVS, are possible. |
| 14 | 14 | |
| 15 | 15 | |
| 16 | − User-space tools | |
| 17 | − | |
| 18 | − user space | | |
| 19 | − +-------------------------------------------------------------------+ | |
| 20 | − kernel | Netlink | |
| 21 | − | | |
| 22 | − +--------------+-------------------------------+ | |
| 23 | − | Network stack | | |
| 24 | − | (Linux) | | |
| 25 | − | | | |
| 26 | − +----------------------------------------------+ | |
| 16 | + User-space tools | |
| 17 | + | |
| 18 | + user space | | |
| 19 | + +-------------------------------------------------------------------+ | |
| 20 | + kernel | Netlink | |
| 21 | + | | |
| 22 | + +--------------+-------------------------------+ | |
| 23 | + | Network stack | | |
| 24 | + | (Linux) | | |
| 25 | + | | | |
| 26 | + +----------------------------------------------+ | |
| 27 | 27 | |
| 28 | 28 | sw1p2 sw1p4 sw1p6 |
| 29 | − sw1p1 + sw1p3 + sw1p5 + eth1 | |
| 30 | − + | + | + | + | |
| 31 | − | | | | | | | | |
| 32 | − +--+----+----+----+-+--+----+---+ +-----+-----+ | |
| 33 | − | Switch driver | | mgmt | | |
| 34 | − | (this document) | | driver | | |
| 35 | − | | | | | |
| 36 | − +--------------+----------------+ +-----------+ | |
| 37 | − | | |
| 38 | − kernel | HW bus (eg PCI) | |
| 39 | − +-------------------------------------------------------------------+ | |
| 40 | − hardware | | |
| 41 | − +--------------+---+------------+ | |
| 42 | − | Switch device (sw1) | | |
| 43 | − | +----+ +--------+ | |
| 44 | − | | v offloaded data path | mgmt port | |
| 45 | − | | | | | |
| 46 | − +--|----|----+----+----+----+---+ | |
| 47 | − | | | | | | | |
| 48 | − + + + + + + | |
| 49 | − p1 p2 p3 p4 p5 p6 | |
| 50 | − | |
| 51 | − front-panel ports | |
| 29 | + sw1p1 + sw1p3 + sw1p5 + eth1 | |
| 30 | + + | + | + | + | |
| 31 | + | | | | | | | | |
| 32 | + +--+----+----+----+----+----+---+ +-----+-----+ | |
| 33 | + | Switch driver | | mgmt | | |
| 34 | + | (this document) | | driver | | |
| 35 | + | | | | | |
| 36 | + +--------------+----------------+ +-----------+ | |
| 37 | + | | |
| 38 | + kernel | HW bus (eg PCI) | |
| 39 | + +-------------------------------------------------------------------+ | |
| 40 | + hardware | | |
| 41 | + +--------------+----------------+ | |
| 42 | + | Switch device (sw1) | | |
| 43 | + | +----+ +--------+ | |
| 44 | + | | v offloaded data path | mgmt port | |
| 45 | + | | | | | |
| 46 | + +--|----|----+----+----+----+---+ | |
| 47 | + | | | | | | | |
| 48 | + + + + + + + | |
| 49 | + p1 p2 p3 p4 p5 p6 | |
| 50 | + | |
| 51 | + front-panel ports | |
| 52 | 52 | |
| 53 | 53 | |
| 54 | 54 | Fig 1. |
| @@ -228,7 +228,7 @@ Learning on the device port should be enabled, as well as learning_sync: · 173 unmodified lines | ||
| 228 | 228 | bridge link set dev DEV learning on self |
| 229 | 229 | bridge link set dev DEV learning_sync on self |
| 230 | 230 | |
| 231 | −Learning_sync attribute enables syncing of the learned/forgotton FDB entry to | |
| 231 | +Learning_sync attribute enables syncing of the learned/forgotten FDB entry to | |
| 232 | 232 | the bridge's FDB. It's possible, but not optimal, to enable learning on the |
| 233 | 233 | device port and on the bridge port, and disable learning_sync. |
| 234 | 234 | |
| @@ -245,7 +245,7 @@ the responsibility of the port driver/device to age out these entries. If the · 10 unmodified lines | ||
| 245 | 245 | port device supports ageing, when the FDB entry expires, it will notify the |
| 246 | 246 | driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the |
| 247 | 247 | device does not support ageing, the driver can simulate ageing using a |
| 248 | −garbage collection timer to monitor FBD entries. Expired entries will be | |
| 248 | +garbage collection timer to monitor FDB entries. Expired entries will be | |
| 249 | 249 | notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for |
| 250 | 250 | example of driver running ageing timer. |
| 251 | 251 | |
| @@ -112,7 +112,7 @@ take nvmem_device as parameter. · 111 unmodified lines | ||
| 112 | 112 | 5. Releasing a reference to the NVMEM |
| 113 | 113 | ===================================== |
| 114 | 114 | |
| 115 | −When a consumers no longer needs the NVMEM, it has to release the reference | |
| 115 | +When a consumer no longer needs the NVMEM, it has to release the reference | |
| 116 | 116 | to the NVMEM it has obtained using the APIs mentioned in the above section. |
| 117 | 117 | The NVMEM framework provides 2 APIs to release a reference to the NVMEM. |
| 118 | 118 | |
| @@ -1,125 +0,0 @@ | ||
| 1 | −System Power Management Sleep States | |
| 2 | − | |
| 3 | −(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 4 | − | |
| 5 | −The kernel supports up to four system sleep states generically, although three | |
| 6 | −of them depend on the platform support code to implement the low-level details | |
| 7 | −for each state. | |
| 8 | − | |
| 9 | −The states are represented by strings that can be read or written to the | |
| 10 | −/sys/power/state file. Those strings may be "mem", "standby", "freeze" and | |
| 11 | −"disk", where the last three always represent Power-On Suspend (if supported), | |
| 12 | −Suspend-To-Idle and hibernation (Suspend-To-Disk), respectively. | |
| 13 | − | |
| 14 | −The meaning of the "mem" string is controlled by the /sys/power/mem_sleep file. | |
| 15 | −It contains strings representing the available modes of system suspend that may | |
| 16 | −be triggered by writing "mem" to /sys/power/state. These modes are "s2idle" | |
| 17 | −(Suspend-To-Idle), "shallow" (Power-On Suspend) and "deep" (Suspend-To-RAM). | |
| 18 | −The "s2idle" mode is always available, while the other ones are only available | |
| 19 | −if supported by the platform (if not supported, the strings representing them | |
| 20 | −are not present in /sys/power/mem_sleep). The string representing the suspend | |
| 21 | −mode to be used subsequently is enclosed in square brackets. Writing one of | |
| 22 | −the other strings present in /sys/power/mem_sleep to it causes the suspend mode | |
| 23 | −to be used subsequently to change to the one represented by that string. | |
| 24 | − | |
| 25 | −Consequently, there are two ways to cause the system to go into the | |
| 26 | −Suspend-To-Idle sleep state. The first one is to write "freeze" directly to | |
| 27 | −/sys/power/state. The second one is to write "s2idle" to /sys/power/mem_sleep | |
| 28 | −and then to write "mem" to /sys/power/state. Similarly, there are two ways | |
| 29 | −to cause the system to go into the Power-On Suspend sleep state (the strings to | |
| 30 | −write to the control files in that case are "standby" or "shallow" and "mem", | |
| 31 | −respectively) if that state is supported by the platform. In turn, there is | |
| 32 | −only one way to cause the system to go into the Suspend-To-RAM state (write | |
| 33 | −"deep" into /sys/power/mem_sleep and "mem" into /sys/power/state). | |
| 34 | − | |
| 35 | −The default suspend mode (ie. the one to be used without writing anything into | |
| 36 | −/sys/power/mem_sleep) is either "deep" (if Suspend-To-RAM is supported) or | |
| 37 | −"s2idle", but it can be overridden by the value of the "mem_sleep_default" | |
| 38 | −parameter in the kernel command line. | |
| 39 | − | |
| 40 | −The properties of all of the sleep states are described below. | |
| 41 | − | |
| 42 | − | |
| 43 | −State: Suspend-To-Idle | |
| 44 | −ACPI state: S0 | |
| 45 | −Label: "s2idle" ("freeze") | |
| 46 | − | |
| 47 | −This state is a generic, pure software, light-weight, system sleep state. | |
| 48 | −It allows more energy to be saved relative to runtime idle by freezing user | |
| 49 | −space and putting all I/O devices into low-power states (possibly | |
| 50 | −lower-power than available at run time), such that the processors can | |
| 51 | −spend more time in their idle states. | |
| 52 | − | |
| 53 | −This state can be used for platforms without Power-On Suspend/Suspend-to-RAM | |
| 54 | −support, or it can be used in addition to Suspend-to-RAM to provide reduced | |
| 55 | −resume latency. It is always supported. | |
| 56 | − | |
| 57 | − | |
| 58 | −State: Standby / Power-On Suspend | |
| 59 | −ACPI State: S1 | |
| 60 | −Label: "shallow" ("standby") | |
| 61 | − | |
| 62 | −This state, if supported, offers moderate, though real, power savings, while | |
| 63 | −providing a relatively low-latency transition back to a working system. No | |
| 64 | −operating state is lost (the CPU retains power), so the system easily starts up | |
| 65 | −again where it left off. | |
| 66 | − | |
| 67 | −In addition to freezing user space and putting all I/O devices into low-power | |
| 68 | −states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline | |
| 69 | −and all low-level system functions are suspended during transitions into this | |
| 70 | −state. For this reason, it should allow more energy to be saved relative to | |
| 71 | −Suspend-To-Idle, but the resume latency will generally be greater than for that | |
| 72 | −state. | |
| 73 | − | |
| 74 | − | |
| 75 | −State: Suspend-to-RAM | |
| 76 | −ACPI State: S3 | |
| 77 | −Label: "deep" | |
| 78 | − | |
| 79 | −This state, if supported, offers significant power savings as everything in the | |
| 80 | −system is put into a low-power state, except for memory, which should be placed | |
| 81 | −into the self-refresh mode to retain its contents. All of the steps carried out | |
| 82 | −when entering Power-On Suspend are also carried out during transitions to STR. | |
| 83 | −Additional operations may take place depending on the platform capabilities. In | |
| 84 | −particular, on ACPI systems the kernel passes control to the BIOS (platform | |
| 85 | −firmware) as the last step during STR transitions and that usually results in | |
| 86 | −powering down some more low-level components that aren't directly controlled by | |
| 87 | −the kernel. | |
| 88 | − | |
| 89 | −System and device state is saved and kept in memory. All devices are suspended | |
| 90 | −and put into low-power states. In many cases, all peripheral buses lose power | |
| 91 | −when entering STR, so devices must be able to handle the transition back to the | |
| 92 | −"on" state. | |
| 93 | − | |
| 94 | −For at least ACPI, STR requires some minimal boot-strapping code to resume the | |
| 95 | −system from it. This may be the case on other platforms too. | |
| 96 | − | |
| 97 | − | |
| 98 | −State: Suspend-to-disk | |
| 99 | −ACPI State: S4 | |
| 100 | −Label: "disk" | |
| 101 | − | |
| 102 | −This state offers the greatest power savings, and can be used even in | |
| 103 | −the absence of low-level platform support for power management. This | |
| 104 | −state operates similarly to Suspend-to-RAM, but includes a final step | |
| 105 | −of writing memory contents to disk. On resume, this is read and memory | |
| 106 | −is restored to its pre-suspend state. | |
| 107 | − | |
| 108 | −STD can be handled by the firmware or the kernel. If it is handled by | |
| 109 | −the firmware, it usually requires a dedicated partition that must be | |
| 110 | −setup via another operating system for it to use. Despite the | |
| 111 | −inconvenience, this method requires minimal work by the kernel, since | |
| 112 | −the firmware will also handle restoring memory contents on resume. | |
| 113 | − | |
| 114 | −For suspend-to-disk, a mechanism called 'swsusp' (Swap Suspend) is used | |
| 115 | −to write memory contents to free swap space. swsusp has some restrictive | |
| 116 | −requirements, but should work in most cases. Some, albeit outdated, | |
| 117 | −documentation can be found in Documentation/power/swsusp.txt. | |
| 118 | −Alternatively, userspace can do most of the actual suspend to disk work, | |
| 119 | −see userland-swsusp.txt. | |
| 120 | − | |
| 121 | −Once memory state is written to disk, the system may either enter a | |
| 122 | −low-power state (like ACPI S4), or it may simply power down. Powering | |
| 123 | −down offers greater savings, and allows this mechanism to work on any | |
| 124 | −system. However, entering a real low-power state allows the user to | |
| 125 | −trigger wake up events (e.g. pressing a key or opening a laptop lid). | |
| @@ -48,12 +48,12 @@ problem: · 47 unmodified lines | ||
| 48 | 48 | time_pps_create(). |
| 49 | 49 | |
| 50 | 50 | This implies that the source has a /dev/... entry. This assumption is |
| 51 | −ok for the serial and parallel port, where you can do something | |
| 51 | +OK for the serial and parallel port, where you can do something | |
| 52 | 52 | useful besides(!) the gathering of timestamps as it is the central |
| 53 | −task for a PPS-API. But this assumption does not work for a single | |
| 53 | +task for a PPS API. But this assumption does not work for a single | |
| 54 | 54 | purpose GPIO line. In this case even basic file-related functionality |
| 55 | 55 | (like read() and write()) makes no sense at all and should not be a |
| 56 | −precondition for the use of a PPS-API. | |
| 56 | +precondition for the use of a PPS API. | |
| 57 | 57 | |
| 58 | 58 | The problem can be simply solved if you consider that a PPS source is |
| 59 | 59 | not always connected with a GPS data source. |
| @@ -88,13 +88,13 @@ Coding example · 28 unmodified lines | ||
| 88 | 88 | -------------- |
| 89 | 89 | |
| 90 | 90 | To register a PPS source into the kernel you should define a struct |
| 91 | −pps_source_info_s as follows: | |
| 91 | +pps_source_info as follows: | |
| 92 | 92 | |
| 93 | 93 | static struct pps_source_info pps_ktimer_info = { |
| 94 | 94 | .name = "ktimer", |
| 95 | 95 | .path = "", |
| 96 | − .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \ | |
| 97 | − PPS_ECHOASSERT | \ | |
| 96 | + .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | | |
| 97 | + PPS_ECHOASSERT | | |
| 98 | 98 | PPS_CANWAIT | PPS_TSFMT_TSPEC, |
| 99 | 99 | .echo = pps_ktimer_echo, |
| 100 | 100 | .owner = THIS_MODULE, |
| @@ -108,13 +108,13 @@ initialization routine as follows: · 7 unmodified lines | ||
| 108 | 108 | |
| 109 | 109 | The pps_register_source() prototype is: |
| 110 | 110 | |
| 111 | − int pps_register_source(struct pps_source_info_s *info, int default_params) | |
| 111 | + int pps_register_source(struct pps_source_info *info, int default_params) | |
| 112 | 112 | |
| 113 | 113 | where "info" is a pointer to a structure that describes a particular |
| 114 | 114 | PPS source, "default_params" tells the system what the initial default |
| 115 | 115 | parameters for the device should be (it is obvious that these parameters |
| 116 | 116 | must be a subset of ones defined in the struct |
| 117 | −pps_source_info_s which describe the capabilities of the driver). | |
| 117 | +pps_source_info which describe the capabilities of the driver). | |
| 118 | 118 | |
| 119 | 119 | Once you have registered a new PPS source into the system you can |
| 120 | 120 | signal an assert event (for example in the interrupt handler routine) |
| @@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it provides a new class: · 21 unmodified lines | ||
| 142 | 142 | Every directory is the ID of a PPS sources defined in the system and |
| 143 | 143 | inside you find several files: |
| 144 | 144 | |
| 145 | − $ ls /sys/class/pps/pps0/ | |
| 146 | − assert clear echo mode name path subsystem@ uevent | |
| 145 | + $ ls -F /sys/class/pps/pps0/ | |
| 146 | + assert dev mode path subsystem@ | |
| 147 | + clear echo name power/ uevent | |
| 148 | + | |
| 147 | 149 | |
| 148 | 150 | Inside each "assert" and "clear" file you can find the timestamp and a |
| 149 | 151 | sequence number: |
| @@ -154,32 +156,32 @@ sequence number: · 4 unmodified lines | ||
| 154 | 156 | Where before the "#" is the timestamp in seconds; after it is the |
| 155 | 157 | sequence number. Other files are: |
| 156 | 158 | |
| 157 | −* echo: reports if the PPS source has an echo function or not; | |
| 159 | + * echo: reports if the PPS source has an echo function or not; | |
| 158 | 160 | |
| 159 | −* mode: reports available PPS functioning modes; | |
| 161 | + * mode: reports available PPS functioning modes; | |
| 160 | 162 | |
| 161 | −* name: reports the PPS source's name; | |
| 163 | + * name: reports the PPS source's name; | |
| 162 | 164 | |
| 163 | −* path: reports the PPS source's device path, that is the device the | |
| 164 | − PPS source is connected to (if it exists). | |
| 165 | + * path: reports the PPS source's device path, that is the device the | |
| 166 | + PPS source is connected to (if it exists). | |
| 165 | 167 | |
| 166 | 168 | |
| 167 | 169 | Testing the PPS support |
| 168 | 170 | ----------------------- |
| 169 | 171 | |
| 170 | 172 | In order to test the PPS support even without specific hardware you can use |
| 171 | −the ktimer driver (see the client subsection in the PPS configuration menu) | |
| 173 | +the pps-ktimer driver (see the client subsection in the PPS configuration menu) | |
| 172 | 174 | and the userland tools available in your distribution's pps-tools package, |
| 173 | −http://linuxpps.org , or https://github.com/ago/pps-tools . | |
| 175 | +http://linuxpps.org , or https://github.com/redlab-i/pps-tools. | |
| 174 | 176 | |
| 175 | −Once you have enabled the compilation of ktimer just modprobe it (if | |
| 177 | +Once you have enabled the compilation of pps-ktimer just modprobe it (if | |
| 176 | 178 | not statically compiled): |
| 177 | 179 | |
| 178 | − # modprobe ktimer | |
| 180 | + # modprobe pps-ktimer | |
| 179 | 181 | |
| 180 | 182 | and the run ppstest as follow: |
| 181 | 183 | |
| 182 | − $ ./ppstest /dev/pps0 | |
| 184 | + $ ./ppstest /dev/pps1 | |
| 183 | 185 | trying PPS source "/dev/pps1" |
| 184 | 186 | found PPS source "/dev/pps1" |
| 185 | 187 | ok, found 1 source(s), now start fetching data... |
| @@ -187,7 +189,7 @@ and the run ppstest as follow: · 1 unmodified line | ||
| 187 | 189 | source 0 - assert 1186592700.388931295, sequence: 365 - clear 0.000000000, sequence: 0 |
| 188 | 190 | source 0 - assert 1186592701.389032765, sequence: 366 - clear 0.000000000, sequence: 0 |
| 189 | 191 | |
| 190 | −Please, note that to compile userland programs you need the file timepps.h . | |
| 192 | +Please note that to compile userland programs, you need the file timepps.h. | |
| 191 | 193 | This is available in the pps-tools repository mentioned above. |
| 192 | 194 | |
| 193 | 195 | |
| @@ -58,20 +58,33 @@ Symbols/Function Pointers · 57 unmodified lines | ||
| 58 | 58 | %ps versatile_init |
| 59 | 59 | %pB prev_fn_of_versatile_init+0x88/0x88 |
| 60 | 60 | |
| 61 | −For printing symbols and function pointers. The ``S`` and ``s`` specifiers | |
| 62 | −result in the symbol name with (``S``) or without (``s``) offsets. Where | |
| 63 | −this is used on a kernel without KALLSYMS - the symbol address is | |
| 64 | −printed instead. | |
| 61 | +The ``F`` and ``f`` specifiers are for printing function pointers, | |
| 62 | +for example, f->func, &gettimeofday. They have the same result as | |
| 63 | +``S`` and ``s`` specifiers. But they do an extra conversion on | |
| 64 | +ia64, ppc64 and parisc64 architectures where the function pointers | |
| 65 | +are actually function descriptors. | |
| 66 | + | |
| 67 | +The ``S`` and ``s`` specifiers can be used for printing symbols | |
| 68 | +from direct addresses, for example, __builtin_return_address(0), | |
| 69 | +(void *)regs->ip. They result in the symbol name with (``S``) or | |
| 70 | +without (``s``) offsets. If KALLSYMS are disabled then the symbol | |
| 71 | +address is printed instead. | |
| 65 | 72 | |
| 66 | 73 | The ``B`` specifier results in the symbol name with offsets and should be |
| 67 | 74 | used when printing stack backtraces. The specifier takes into |
| 68 | 75 | consideration the effect of compiler optimisations which may occur |
| 69 | 76 | when tail-call``s are used and marked with the noreturn GCC attribute. |
| 70 | 77 | |
| 71 | −On ia64, ppc64 and parisc64 architectures function pointers are | |
| 72 | −actually function descriptors which must first be resolved. The ``F`` and | |
| 73 | −``f`` specifiers perform this resolution and then provide the same | |
| 74 | −functionality as the ``S`` and ``s`` specifiers. | |
| 78 | +Examples:: | |
| 79 | + | |
| 80 | + printk("Going to call: %pF\n", gettimeofday); | |
| 81 | + printk("Going to call: %pF\n", p->func); | |
| 82 | + printk("%s: called from %pS\n", __func__, (void *)_RET_IP_); | |
| 83 | + printk("%s: called from %pS\n", __func__, | |
| 84 | + (void *)__builtin_return_address(0)); | |
| 85 | + printk("Faulted at %pS\n", (void *)regs->ip); | |
| 86 | + printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack); | |
| 87 | + | |
| 75 | 88 | |
| 76 | 89 | Kernel Pointers |
| 77 | 90 | =============== |
| @@ -6,9 +6,6 @@ Applying Patches To The Linux Kernel · 5 unmodified lines | ||
| 6 | 6 | Original by: |
| 7 | 7 | Jesper Juhl, August 2005 |
| 8 | 8 | |
| 9 | −Last update: | |
| 10 | − 2016-09-14 | |
| 11 | − | |
| 12 | 9 | .. note:: |
| 13 | 10 | |
| 14 | 11 | This document is obsolete. In most cases, rather than using ``patch`` |
| @@ -344,7 +341,7 @@ possible. · 329 unmodified lines | ||
| 344 | 341 | |
| 345 | 342 | This is a good branch to run for people who want to help out testing |
| 346 | 343 | development kernels but do not want to run some of the really experimental |
| 347 | −stuff (such people should see the sections about -git and -mm kernels below). | |
| 344 | +stuff (such people should see the sections about -next and -mm kernels below). | |
| 348 | 345 | |
| 349 | 346 | The -rc patches are not incremental, they apply to a base 4.x kernel, just |
| 350 | 347 | like the 4.x.y patches described above. The kernel version before the -rcN |
| @@ -380,44 +377,6 @@ Here are 3 examples of how to apply these patches:: · 29 unmodified lines | ||
| 380 | 377 | $ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir |
| 381 | 378 | |
| 382 | 379 | |
| 383 | −The -git kernels | |
| 384 | −================ | |
| 385 | − | |
| 386 | −These are daily snapshots of Linus' kernel tree (managed in a git | |
| 387 | −repository, hence the name). | |
| 388 | − | |
| 389 | −These patches are usually released daily and represent the current state of | |
| 390 | −Linus's tree. They are more experimental than -rc kernels since they are | |
| 391 | −generated automatically without even a cursory glance to see if they are | |
| 392 | −sane. | |
| 393 | − | |
| 394 | −-git patches are not incremental and apply either to a base 4.x kernel or | |
| 395 | −a base 4.x-rc kernel -- you can see which from their name. | |
| 396 | −A patch named 4.7-git1 applies to the 4.7 kernel source and a patch | |
| 397 | −named 4.8-rc3-git2 applies to the source of the 4.8-rc3 kernel. | |
| 398 | − | |
| 399 | −Here are some examples of how to apply these patches:: | |
| 400 | − | |
| 401 | − # moving from 4.7 to 4.7-git1 | |
| 402 | − | |
| 403 | − $ cd ~/linux-4.7 # change to the kernel source dir | |
| 404 | − $ patch -p1 < ../patch-4.7-git1 # apply the 4.7-git1 patch | |
| 405 | − $ cd .. | |
| 406 | − $ mv linux-4.7 linux-4.7-git1 # rename the kernel source dir | |
| 407 | − | |
| 408 | − # moving from 4.7-git1 to 4.8-rc2-git3 | |
| 409 | − | |
| 410 | − $ cd ~/linux-4.7-git1 # change to the kernel source dir | |
| 411 | − $ patch -p1 -R < ../patch-4.7-git1 # revert the 4.7-git1 patch | |
| 412 | − # we now have a 4.7 kernel | |
| 413 | − $ patch -p1 < ../patch-4.8-rc2 # apply the 4.8-rc2 patch | |
| 414 | − # the kernel is now 4.8-rc2 | |
| 415 | − $ patch -p1 < ../patch-4.8-rc2-git3 # apply the 4.8-rc2-git3 patch | |
| 416 | − # the kernel is now 4.8-rc2-git3 | |
| 417 | − $ cd .. | |
| 418 | − $ mv linux-4.7-git1 linux-4.8-rc2-git3 # rename source dir | |
| 419 | − | |
| 420 | − | |
| 421 | 380 | The -mm patches and the linux-next tree |
| 422 | 381 | ======================================= |
| 423 | 382 | |
| @@ -53,7 +53,7 @@ mcelog 0.6 mcelog --version · 52 unmodified lines | ||
| 53 | 53 | iptables 1.4.2 iptables -V |
| 54 | 54 | openssl & libcrypto 1.0.0 openssl version |
| 55 | 55 | bc 1.06.95 bc --version |
| 56 | −Sphinx\ [#f1]_ 1.2 sphinx-build --version | |
| 56 | +Sphinx\ [#f1]_ 1.3 sphinx-build --version | |
| 57 | 57 | ====================== =============== ======================================== |
| 58 | 58 | |
| 59 | 59 | .. [#f1] Sphinx is needed only to build the Kernel documentation |
| @@ -309,18 +309,8 @@ Kernel documentation · 249 unmodified lines | ||
| 309 | 309 | Sphinx |
| 310 | 310 | ------ |
| 311 | 311 | |
| 312 | −The ReST markups currently used by the Documentation/ files are meant to be | |
| 313 | −built with ``Sphinx`` version 1.2 or upper. If you're desiring to build | |
| 314 | −PDF outputs, it is recommended to use version 1.4.6. | |
| 315 | − | |
| 316 | −.. note:: | |
| 317 | − | |
| 318 | − Please notice that, for PDF and LaTeX output, you'll also need ``XeLaTeX`` | |
| 319 | − version 3.14159265. Depending on the distribution, you may also need to | |
| 320 | − install a series of ``texlive`` packages that provide the minimal set of | |
| 321 | − functionalities required for ``XeLaTex`` to work. For PDF output you'll also | |
| 322 | − need ``convert(1)`` from ImageMagick (https://www.imagemagick.org). | |
| 323 | − | |
| 312 | +Please see :ref:`sphinx_install` in ``Documentation/doc-guide/sphinx.rst`` | |
| 313 | +for details about Sphinx requirements. | |
| 324 | 314 | |
| 325 | 315 | Getting updated software |
| 326 | 316 | ======================== |
| @@ -166,12 +166,12 @@ Trees · 165 unmodified lines | ||
| 166 | 166 | - The queues of patches, for both completed versions and in progress |
| 167 | 167 | versions can be found at: |
| 168 | 168 | |
| 169 | − http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git | |
| 169 | + https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git | |
| 170 | 170 | |
| 171 | 171 | - The finalized and tagged releases of all stable kernels can be found |
| 172 | 172 | in separate branches per version at: |
| 173 | 173 | |
| 174 | − http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git | |
| 174 | + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git | |
| 175 | 175 | |
| 176 | 176 | |
| 177 | 177 | Review committee |
| @@ -413,7 +413,7 @@ e-mail discussions. · 412 unmodified lines | ||
| 413 | 413 | |
| 414 | 414 | |
| 415 | 415 | |
| 416 | −11) Sign your work — the Developer's Certificate of Origin | |
| 416 | +11) Sign your work - the Developer's Certificate of Origin | |
| 417 | 417 | ---------------------------------------------------------- |
| 418 | 418 | |
| 419 | 419 | To improve tracking of who did what, especially with patches that can |
| @@ -193,6 +193,39 @@ Example:: · 192 unmodified lines | ||
| 193 | 193 | for (node = rb_first(&mytree); node; node = rb_next(node)) |
| 194 | 194 | printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring); |
| 195 | 195 | |
| 196 | +Cached rbtrees | |
| 197 | +-------------- | |
| 198 | + | |
| 199 | +Computing the leftmost (smallest) node is quite a common task for binary | |
| 200 | +search trees, such as for traversals or users relying on a the particular | |
| 201 | +order for their own logic. To this end, users can use 'struct rb_root_cached' | |
| 202 | +to optimize O(logN) rb_first() calls to a simple pointer fetch avoiding | |
| 203 | +potentially expensive tree iterations. This is done at negligible runtime | |
| 204 | +overhead for maintanence; albeit larger memory footprint. | |
| 205 | + | |
| 206 | +Similar to the rb_root structure, cached rbtrees are initialized to be | |
| 207 | +empty via: | |
| 208 | + | |
| 209 | + struct rb_root_cached mytree = RB_ROOT_CACHED; | |
| 210 | + | |
| 211 | +Cached rbtree is simply a regular rb_root with an extra pointer to cache the | |
| 212 | +leftmost node. This allows rb_root_cached to exist wherever rb_root does, | |
| 213 | +which permits augmented trees to be supported as well as only a few extra | |
| 214 | +interfaces: | |
| 215 | + | |
| 216 | + struct rb_node *rb_first_cached(struct rb_root_cached *tree); | |
| 217 | + void rb_insert_color_cached(struct rb_node *, struct rb_root_cached *, bool); | |
| 218 | + void rb_erase_cached(struct rb_node *node, struct rb_root_cached *); | |
| 219 | + | |
| 220 | +Both insert and erase calls have their respective counterpart of augmented | |
| 221 | +trees: | |
| 222 | + | |
| 223 | + void rb_insert_augmented_cached(struct rb_node *node, struct rb_root_cached *, | |
| 224 | + bool, struct rb_augment_callbacks *); | |
| 225 | + void rb_erase_augmented_cached(struct rb_node *, struct rb_root_cached *, | |
| 226 | + struct rb_augment_callbacks *); | |
| 227 | + | |
| 228 | + | |
| 196 | 229 | Support for Augmented rbtrees |
| 197 | 230 | ----------------------------- |
| 198 | 231 | |
| @@ -16,17 +16,7 @@ The key service can be configured on by enabling: · 15 unmodified lines | ||
| 16 | 16 | |
| 17 | 17 | This document has the following sections: |
| 18 | 18 | |
| 19 | − - Key overview | |
| 20 | − - Key service overview | |
| 21 | − - Key access permissions | |
| 22 | − - SELinux support | |
| 23 | − - New procfs files | |
| 24 | − - Userspace system call interface | |
| 25 | − - Kernel services | |
| 26 | − - Notes on accessing payload contents | |
| 27 | − - Defining a key type | |
| 28 | − - Request-key callback service | |
| 29 | − - Garbage collection | |
| 19 | +.. contents:: :local: | |
| 30 | 20 | |
| 31 | 21 | |
| 32 | 22 | Key Overview |
| @@ -443,7 +433,7 @@ The main syscalls are: · 410 unmodified lines | ||
| 443 | 433 | /sbin/request-key will be invoked in an attempt to obtain a key. The |
| 444 | 434 | callout_info string will be passed as an argument to the program. |
| 445 | 435 | |
| 446 | − See also Documentation/security/keys-request-key.txt. | |
| 436 | + See also Documentation/security/keys/request-key.rst. | |
| 447 | 437 | |
| 448 | 438 | |
| 449 | 439 | The keyctl syscall functions are: |
| @@ -973,7 +963,7 @@ payload contents" for more information. · 523 unmodified lines | ||
| 973 | 963 | If successful, the key will have been attached to the default keyring for |
| 974 | 964 | implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. |
| 975 | 965 | |
| 976 | − See also Documentation/security/keys-request-key.txt. | |
| 966 | + See also Documentation/security/keys/request-key.rst. | |
| 977 | 967 | |
| 978 | 968 | |
| 979 | 969 | * To search for a key, passing auxiliary data to the upcaller, call:: |
| @@ -3,7 +3,7 @@ Key Request Service · 2 unmodified lines | ||
| 3 | 3 | =================== |
| 4 | 4 | |
| 5 | 5 | The key request service is part of the key retention service (refer to |
| 6 | −Documentation/security/keys.txt). This document explains more fully how | |
| 6 | +Documentation/security/core.rst). This document explains more fully how | |
| 7 | 7 | the requesting algorithm works. |
| 8 | 8 | |
| 9 | 9 | The process starts by either the kernel requesting a service by calling |
| @@ -172,4 +172,4 @@ Other uses for trusted and encrypted keys, such as for disk and file encryption · 171 unmodified lines | ||
| 172 | 172 | are anticipated. In particular the new format 'ecryptfs' has been defined in |
| 173 | 173 | in order to use encrypted keys to mount an eCryptfs filesystem. More details |
| 174 | 174 | about the usage can be found in the file |
| 175 | −``Documentation/security/keys-ecryptfs.txt``. | |
| 175 | +``Documentation/security/keys/ecryptfs.rst``. | |
| @@ -4,6 +4,17 @@ · 3 unmodified lines | ||
| 4 | 4 | * |
| 5 | 5 | */ |
| 6 | 6 | |
| 7 | +/* Interim: Code-blocks with line nos - lines and line numbers don't line up. | |
| 8 | + * see: https://github.com/rtfd/sphinx_rtd_theme/issues/419 | |
| 9 | + */ | |
| 10 | + | |
| 11 | +div[class^="highlight"] pre { | |
| 12 | + line-height: normal; | |
| 13 | +} | |
| 14 | +.rst-content .highlight > pre { | |
| 15 | + line-height: normal; | |
| 16 | +} | |
| 17 | + | |
| 7 | 18 | @media screen { |
| 8 | 19 | |
| 9 | 20 | /* content column |
| @@ -56,6 +67,12 @@ · 46 unmodified lines | ||
| 56 | 67 | font-family: "Courier New", Courier, monospace |
| 57 | 68 | } |
| 58 | 69 | |
| 70 | + /* fix bottom margin of lists items */ | |
| 71 | + | |
| 72 | + .rst-content .section ul li:last-child, .rst-content .section ul li p:last-child { | |
| 73 | + margin-bottom: 12px; | |
| 74 | + } | |
| 75 | + | |
| 59 | 76 | /* inline literal: drop the borderbox, padding and red color */ |
| 60 | 77 | |
| 61 | 78 | code, .rst-content tt, .rst-content code { |
| @@ -27,6 +27,7 @@ · 26 unmodified lines | ||
| 27 | 27 | # Please make sure this works on both python2 and python3. |
| 28 | 28 | # |
| 29 | 29 | |
| 30 | +import codecs | |
| 30 | 31 | import os |
| 31 | 32 | import subprocess |
| 32 | 33 | import sys |
| @@ -88,13 +89,10 @@ class KernelDocDirective(Directive): · 55 unmodified lines | ||
| 88 | 89 | try: |
| 89 | 90 | env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd))) |
| 90 | 91 | |
| 91 | − p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True) | |
| 92 | + p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) | |
| 92 | 93 | out, err = p.communicate() |
| 93 | 94 | |
| 94 | − # python2 needs conversion to unicode. | |
| 95 | − # python3 with universal_newlines=True returns strings. | |
| 96 | − if sys.version_info.major < 3: | |
| 97 | − out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8') | |
| 95 | + out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8') | |
| 98 | 96 | |
| 99 | 97 | if p.returncode != 0: |
| 100 | 98 | sys.stderr.write(err) |
| @@ -0,0 +1,3 @@ | ||
| 1 | +docutils==0.12 | |
| 2 | +Sphinx==1.4.9 | |
| 3 | +sphinx_rtd_theme | |
| @@ -149,6 +149,26 @@ static_branch_inc(), will change the branch back to true. Likewise, if the · 148 unmodified lines | ||
| 149 | 149 | key is initialized false, a 'static_branch_inc()', will change the branch to |
| 150 | 150 | true. And then a 'static_branch_dec()', will again make the branch false. |
| 151 | 151 | |
| 152 | +The state and the reference count can be retrieved with 'static_key_enabled()' | |
| 153 | +and 'static_key_count()'. In general, if you use these functions, they | |
| 154 | +should be protected with the same mutex used around the enable/disable | |
| 155 | +or increment/decrement function. | |
| 156 | + | |
| 157 | +Note that switching branches results in some locks being taken, | |
| 158 | +particularly the CPU hotplug lock (in order to avoid races against | |
| 159 | +CPUs being brought in the kernel whilst the kernel is getting | |
| 160 | +patched). Calling the static key API from within a hotplug notifier is | |
| 161 | +thus a sure deadlock recipe. In order to still allow use of the | |
| 162 | +functionnality, the following functions are provided: | |
| 163 | + | |
| 164 | + static_key_enable_cpuslocked() | |
| 165 | + static_key_disable_cpuslocked() | |
| 166 | + static_branch_enable_cpuslocked() | |
| 167 | + static_branch_disable_cpuslocked() | |
| 168 | + | |
| 169 | +These functions are *not* general purpose, and must only be used when | |
| 170 | +you really know that you're in the above context, and no other. | |
| 171 | + | |
| 152 | 172 | Where an array of keys is required, it can be defined as:: |
| 153 | 173 | |
| 154 | 174 | DEFINE_STATIC_KEY_ARRAY_TRUE(keys, count); |
| @@ -61,6 +61,7 @@ show up in /proc/sys/kernel: · 60 unmodified lines | ||
| 61 | 61 | - perf_cpu_time_max_percent |
| 62 | 62 | - perf_event_paranoid |
| 63 | 63 | - perf_event_max_stack |
| 64 | +- perf_event_mlock_kb | |
| 64 | 65 | - perf_event_max_contexts_per_stack |
| 65 | 66 | - pid_max |
| 66 | 67 | - powersave-nap [ PPC only ] |
| @@ -74,6 +75,7 @@ show up in /proc/sys/kernel: · 7 unmodified lines | ||
| 74 | 75 | - reboot-cmd [ SPARC only ] |
| 75 | 76 | - rtsig-max |
| 76 | 77 | - rtsig-nr |
| 78 | +- seccomp/ ==> Documentation/userspace-api/seccomp_filter.rst | |
| 77 | 79 | - sem |
| 78 | 80 | - sem_next_id [ sysv ipc ] |
| 79 | 81 | - sg-big-buff [ generic SCSI device (sg) ] |
| @@ -654,7 +656,9 @@ Controls use of the performance events system by unprivileged · 574 unmodified lines | ||
| 654 | 656 | users (without CAP_SYS_ADMIN). The default value is 2. |
| 655 | 657 | |
| 656 | 658 | -1: Allow use of (almost) all events by all users |
| 657 | −>=0: Disallow raw tracepoint access by users without CAP_IOC_LOCK | |
| 659 | + Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK | |
| 660 | +>=0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN | |
| 661 | + Disallow raw tracepoint access by users without CAP_SYS_ADMIN | |
| 658 | 662 | >=1: Disallow CPU event access by users without CAP_SYS_ADMIN |
| 659 | 663 | >=2: Disallow kernel profiling by users without CAP_SYS_ADMIN |
| 660 | 664 | |
| @@ -673,6 +677,14 @@ The default value is 127. · 12 unmodified lines | ||
| 673 | 677 | |
| 674 | 678 | ============================================================== |
| 675 | 679 | |
| 680 | +perf_event_mlock_kb: | |
| 681 | + | |
| 682 | +Control size of per-cpu ring buffer not counted agains mlock limit. | |
| 683 | + | |
| 684 | +The default value is 512 + 1 page | |
| 685 | + | |
| 686 | +============================================================== | |
| 687 | + | |
| 676 | 688 | perf_event_max_contexts_per_stack: |
| 677 | 689 | |
| 678 | 690 | Controls maximum number of stack frame context entries for |
| @@ -35,9 +35,34 @@ Table : Subdirectories in /proc/sys/net · 34 unmodified lines | ||
| 35 | 35 | bpf_jit_enable |
| 36 | 36 | -------------- |
| 37 | 37 | |
| 38 | −This enables Berkeley Packet Filter Just in Time compiler. | |
| 39 | −Currently supported on x86_64 architecture, bpf_jit provides a framework | |
| 40 | −to speed packet filtering, the one used by tcpdump/libpcap for example. | |
| 38 | +This enables the BPF Just in Time (JIT) compiler. BPF is a flexible | |
| 39 | +and efficient infrastructure allowing to execute bytecode at various | |
| 40 | +hook points. It is used in a number of Linux kernel subsystems such | |
| 41 | +as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) | |
| 42 | +and security (e.g. seccomp). LLVM has a BPF back end that can compile | |
| 43 | +restricted C into a sequence of BPF instructions. After program load | |
| 44 | +through bpf(2) and passing a verifier in the kernel, a JIT will then | |
| 45 | +translate these BPF proglets into native CPU instructions. There are | |
| 46 | +two flavors of JITs, the newer eBPF JIT currently supported on: | |
| 47 | + - x86_64 | |
| 48 | + - arm64 | |
| 49 | + - arm32 | |
| 50 | + - ppc64 | |
| 51 | + - sparc64 | |
| 52 | + - mips64 | |
| 53 | + - s390x | |
| 54 | + | |
| 55 | +And the older cBPF JIT supported on the following archs: | |
| 56 | + - mips | |
| 57 | + - ppc | |
| 58 | + - sparc | |
| 59 | + | |
| 60 | +eBPF JITs are a superset of cBPF JITs, meaning the kernel will | |
| 61 | +migrate cBPF instructions into eBPF instructions and then JIT | |
| 62 | +compile them transparently. Older cBPF JITs can only translate | |
| 63 | +tcpdump filters, seccomp rules, etc, but not mentioned eBPF | |
| 64 | +programs loaded through bpf(2). | |
| 65 | + | |
| 41 | 66 | Values : |
| 42 | 67 | 0 - disable the JIT (default value) |
| 43 | 68 | 1 - enable the JIT |
| @@ -46,9 +71,9 @@ Values : · 2 unmodified lines | ||
| 46 | 71 | bpf_jit_harden |
| 47 | 72 | -------------- |
| 48 | 73 | |
| 49 | −This enables hardening for the Berkeley Packet Filter Just in Time compiler. | |
| 50 | −Supported are eBPF JIT backends. Enabling hardening trades off performance, | |
| 51 | −but can mitigate JIT spraying. | |
| 74 | +This enables hardening for the BPF JIT compiler. Supported are eBPF | |
| 75 | +JIT backends. Enabling hardening trades off performance, but can | |
| 76 | +mitigate JIT spraying. | |
| 52 | 77 | Values : |
| 53 | 78 | 0 - disable JIT hardening (default value) |
| 54 | 79 | 1 - enable JIT hardening for unprivileged users only |
| @@ -57,11 +82,11 @@ Values : · 2 unmodified lines | ||
| 57 | 82 | bpf_jit_kallsyms |
| 58 | 83 | ---------------- |
| 59 | 84 | |
| 60 | −When Berkeley Packet Filter Just in Time compiler is enabled, then compiled | |
| 61 | −images are unknown addresses to the kernel, meaning they neither show up in | |
| 62 | −traces nor in /proc/kallsyms. This enables export of these addresses, which | |
| 63 | −can be used for debugging/tracing. If bpf_jit_harden is enabled, this feature | |
| 64 | −is disabled. | |
| 85 | +When BPF JIT compiler is enabled, then compiled images are unknown | |
| 86 | +addresses to the kernel, meaning they neither show up in traces nor | |
| 87 | +in /proc/kallsyms. This enables export of these addresses, which can | |
| 88 | +be used for debugging/tracing. If bpf_jit_harden is enabled, this | |
| 89 | +feature is disabled. | |
| 65 | 90 | Values : |
| 66 | 91 | 0 - disable JIT kallsyms export (default value) |
| 67 | 92 | 1 - enable JIT kallsyms export for privileged users only |
| @@ -572,7 +572,9 @@ See Documentation/nommu-mmap.txt for more information. · 571 unmodified lines | ||
| 572 | 572 | |
| 573 | 573 | numa_zonelist_order |
| 574 | 574 | |
| 575 | −This sysctl is only for NUMA. | |
| 575 | +This sysctl is only for NUMA and it is deprecated. Anything but | |
| 576 | +Node order will fail! | |
| 577 | + | |
| 576 | 578 | 'where the memory is allocated from' is controlled by zonelists. |
| 577 | 579 | (This documentation ignores ZONE_HIGHMEM/ZONE_DMA32 for simple explanation. |
| 578 | 580 | you may be able to read ZONE_DMA as ZONE_DMA32...) |
| @@ -83,7 +83,7 @@ by writing the name of the desired stm device there, for example: · 82 unmodified lines | ||
| 83 | 83 | $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link |
| 84 | 84 | |
| 85 | 85 | For examples on how to use stm_source interface in the kernel, refer |
| 86 | −to stm_console or stm_heartbeat drivers. | |
| 86 | +to stm_console, stm_heartbeat or stm_ftrace drivers. | |
| 87 | 87 | |
| 88 | 88 | Each stm_source device will need to assume a master and a range of |
| 89 | 89 | channels, depending on how many channels it requires. These are |
| @@ -107,5 +107,16 @@ console in the STP stream, create a "console" policy entry (see the · 17 unmodified lines | ||
| 107 | 107 | beginning of this text on how to do that). When initialized, it will |
| 108 | 108 | consume one channel. |
| 109 | 109 | |
| 110 | +stm_ftrace | |
| 111 | +========== | |
| 112 | + | |
| 113 | +This is another "stm_source" device, once the stm_ftrace has been | |
| 114 | +linked with an stm device, and if "function" tracer is enabled, | |
| 115 | +function address and parent function address which Ftrace subsystem | |
| 116 | +would store into ring buffer will be exported via the stm device at | |
| 117 | +the same time. | |
| 118 | + | |
| 119 | +Currently only Ftrace "function" tracer is supported. | |
| 120 | + | |
| 110 | 121 | [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf |
| 111 | 122 | [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html |
| @@ -523,11 +523,11 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니 · 522 unmodified lines | ||
| 523 | 523 | 즉, ACQUIRE 는 최소한의 "취득" 동작처럼, 그리고 RELEASE 는 최소한의 "공개" |
| 524 | 524 | 처럼 동작한다는 의미입니다. |
| 525 | 525 | |
| 526 | −core-api/atomic_ops.rst 에서 설명되는 어토믹 오퍼레이션들 중에는 완전히 | |
| 527 | −순서잡힌 것들과 (배리어를 사용하지 않는) 완화된 순서의 것들 외에 ACQUIRE 와 | |
| 528 | −RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수행하는 조합된 어토믹 | |
| 529 | −오퍼레이션에서, ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 는 | |
| 530 | −해당 오퍼레이션의 스토어 부분에만 적용됩니다. | |
| 526 | +atomic_t.txt 에 설명된 어토믹 오퍼레이션들 중 일부는 완전히 순서잡힌 것들과 | |
| 527 | +(배리어를 사용하지 않는) 완화된 순서의 것들 외에 ACQUIRE 와 RELEASE 부류의 | |
| 528 | +것들도 존재합니다. 로드와 스토어를 모두 수행하는 조합된 어토믹 오퍼레이션에서, | |
| 529 | +ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 는 해당 | |
| 530 | +오퍼레이션의 스토어 부분에만 적용됩니다. | |
| 531 | 531 | |
| 532 | 532 | 메모리 배리어들은 두 CPU 간, 또는 CPU 와 디바이스 간에 상호작용의 가능성이 있을 |
| 533 | 533 | 때에만 필요합니다. 만약 어떤 코드에 그런 상호작용이 없을 것이 보장된다면, 해당 |
| @@ -617,7 +617,22 @@ RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수 · 83 unmodified lines | ||
| 617 | 617 | 이 변경은 앞의 처음 두가지 결과 중 하나만이 발생할 수 있고, 세번째의 결과는 |
| 618 | 618 | 발생할 수 없도록 합니다. |
| 619 | 619 | |
| 620 | −데이터 의존성 배리어는 의존적 쓰기에 대해서도 순서를 잡아줍니다: | |
| 620 | + | |
| 621 | +[!] 이 상당히 반직관적인 상황은 분리된 캐시를 가지는 기계들에서 가장 잘 | |
| 622 | +발생하는데, 예를 들면 한 캐시 뱅크는 짝수 번호의 캐시 라인들을 처리하고, 다른 | |
| 623 | +뱅크는 홀수 번호의 캐시 라인들을 처리하는 경우임을 알아두시기 바랍니다. 포인터 | |
| 624 | +P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수 번호 캐시 라인에 | |
| 625 | +저장되어 있을 수 있습니다. 여기서 값을 읽어오는 CPU 의 캐시의 홀수 번호 처리 | |
| 626 | +뱅크는 열심히 일감을 처리중인 반면 홀수 번호 처리 뱅크는 할 일 없이 한가한 | |
| 627 | +중이라면 포인터 P (&B) 의 새로운 값과 변수 B 의 기존 값 (2) 를 볼 수 있습니다. | |
| 628 | + | |
| 629 | + | |
| 630 | +의존적 쓰기들의 순서를 맞추는데에는 데이터 의존성 배리어가 필요치 않은데, 이는 | |
| 631 | +리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에 | |
| 632 | +이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기 | |
| 633 | +때문입니다. 하지만 "컨트롤 의존성" 섹션과 | |
| 634 | +Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 바랍니다: | |
| 635 | +컴파일러는 매우 창의적인 많은 방법으로 종속성을 깰 수 있습니다. | |
| 621 | 636 | |
| 622 | 637 | CPU 1 CPU 2 |
| 623 | 638 | =============== =============== |
| @@ -626,28 +641,19 @@ RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수 · 2 unmodified lines | ||
| 626 | 641 | <쓰기 배리어> |
| 627 | 642 | WRITE_ONCE(P, &B); |
| 628 | 643 | Q = READ_ONCE(P); |
| 629 | − <데이터 의존성 배리어> | |
| 630 | − *Q = 5; | |
| 644 | + WRITE_ONCE(*Q, 5); | |
| 631 | 645 | |
| 632 | −이 데이터 의존성 배리어는 Q 로의 읽기가 *Q 로의 스토어와 순서를 맞추게 | |
| 633 | −해줍니다. 이는 다음과 같은 결과를 막습니다: | |
| 646 | +따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 데이터 종속성 배리어가 필요치 | |
| 647 | +않습니다. 달리 말하면, 데이터 종속성 배리어가 없더라도 다음 결과는 생기지 | |
| 648 | +않습니다: | |
| 634 | 649 | |
| 635 | 650 | (Q == &B) && (B == 4) |
| 636 | 651 | |
| 637 | 652 | 이런 패턴은 드물게 사용되어야 함을 알아 두시기 바랍니다. 무엇보다도, 의존성 |
| 638 | 653 | 순서 규칙의 의도는 쓰기 작업을 -예방- 해서 그로 인해 발생하는 비싼 캐시 미스도 |
| 639 | 654 | 없애려는 것입니다. 이 패턴은 드물게 발생하는 에러 조건 같은것들을 기록하는데 |
| 640 | −사용될 수 있고, 이렇게 배리어를 사용해 순서를 지키게 함으로써 그런 기록이 | |
| 641 | −사라지는 것을 막습니다. | |
| 642 | − | |
| 643 | − | |
| 644 | −[!] 상당히 비직관적인 이 상황은 분리된 캐시를 가진 기계, 예를 들어 한 캐시 | |
| 645 | −뱅크가 짝수번 캐시 라인을 처리하고 다른 뱅크는 홀수번 캐시 라인을 처리하는 기계 | |
| 646 | −등에서 가장 잘 발생합니다. 포인터 P 는 홀수 번호의 캐시 라인에 있고, 변수 B 는 | |
| 647 | −짝수 번호 캐시 라인에 있다고 생각해 봅시다. 그런 상태에서 읽기 작업을 하는 CPU | |
| 648 | −의 짝수번 뱅크는 할 일이 쌓여 매우 바쁘지만 홀수번 뱅크는 할 일이 없어 아무 | |
| 649 | −일도 하지 않고 있었다면, 포인터 P 는 새 값 (&B) 을, 그리고 변수 B 는 옛날 값 | |
| 650 | −(2) 을 가지고 있는 상태가 보여질 수도 있습니다. | |
| 655 | +사용될 수 있으며, CPU의 자연적인 순서 보장이 그런 기록들을 사라지지 않게 | |
| 656 | +해줍니다. | |
| 651 | 657 | |
| 652 | 658 | |
| 653 | 659 | 데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. |
| @@ -1848,8 +1854,7 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 · 1194 unmodified lines | ||
| 1848 | 1854 | 이 코드는 객체의 업데이트된 death 마크가 레퍼런스 카운터 감소 동작 |
| 1849 | 1855 | *전에* 보일 것을 보장합니다. |
| 1850 | 1856 | |
| 1851 | − 더 많은 정보를 위해선 Documentation/core-api/atomic_ops.rst 문서를 참고하세요. | |
| 1852 | − 어디서 이것들을 사용해야 할지 궁금하다면 "어토믹 오퍼레이션" 서브섹션을 | |
| 1857 | + 더 많은 정보를 위해선 Documentation/atomic_{t,bitops}.txt 문서를 | |
| 1853 | 1858 | 참고하세요. |
| 1854 | 1859 | |
| 1855 | 1860 | |
| @@ -1956,10 +1961,7 @@ MMIO 쓰기 배리어 · 100 unmodified lines | ||
| 1956 | 1961 | 뒤에 완료됩니다. |
| 1957 | 1962 | |
| 1958 | 1963 | ACQUIRE 앞에서 요청된 메모리 오퍼레이션은 ACQUIRE 오퍼레이션이 완료된 후에 |
| 1959 | − 완료될 수 있습니다. smp_mb__before_spinlock() 뒤에 ACQUIRE 가 실행되는 | |
| 1960 | − 코드 블록은 블록 앞의 스토어를 블록 뒤의 로드와 스토어에 대해 순서 | |
| 1961 | − 맞춥니다. 이건 smp_mb() 보다 완화된 것임을 기억하세요! 많은 아키텍쳐에서 | |
| 1962 | − smp_mb__before_spinlock() 은 사실 아무일도 하지 않습니다. | |
| 1964 | + 완료될 수 있습니다. | |
| 1963 | 1965 | |
| 1964 | 1966 | (2) RELEASE 오퍼레이션의 영향: |
| 1965 | 1967 | |
| @@ -2471,86 +2473,7 @@ _않습니다_. · 505 unmodified lines | ||
| 2471 | 2473 | 전체 메모리 배리어를 내포하고 또 일부는 내포하지 않지만, 커널에서 상당히 |
| 2472 | 2474 | 의존적으로 사용하는 기능 중 하나입니다. |
| 2473 | 2475 | |
| 2474 | −메모리의 어떤 상태를 수정하고 해당 상태에 대한 (예전의 또는 최신의) 정보를 | |
| 2475 | −리턴하는 어토믹 오퍼레이션은 모두 SMP-조건적 범용 메모리 배리어(smp_mb())를 | |
| 2476 | −실제 오퍼레이션의 앞과 뒤에 내포합니다. 이런 오퍼레이션은 다음의 것들을 | |
| 2477 | −포함합니다: | |
| 2478 | − | |
| 2479 | − xchg(); | |
| 2480 | − atomic_xchg(); atomic_long_xchg(); | |
| 2481 | − atomic_inc_return(); atomic_long_inc_return(); | |
| 2482 | − atomic_dec_return(); atomic_long_dec_return(); | |
| 2483 | − atomic_add_return(); atomic_long_add_return(); | |
| 2484 | − atomic_sub_return(); atomic_long_sub_return(); | |
| 2485 | − atomic_inc_and_test(); atomic_long_inc_and_test(); | |
| 2486 | − atomic_dec_and_test(); atomic_long_dec_and_test(); | |
| 2487 | − atomic_sub_and_test(); atomic_long_sub_and_test(); | |
| 2488 | − atomic_add_negative(); atomic_long_add_negative(); | |
| 2489 | − test_and_set_bit(); | |
| 2490 | − test_and_clear_bit(); | |
| 2491 | − test_and_change_bit(); | |
| 2492 | − | |
| 2493 | − /* exchange 조건이 성공할 때 */ | |
| 2494 | − cmpxchg(); | |
| 2495 | − atomic_cmpxchg(); atomic_long_cmpxchg(); | |
| 2496 | − atomic_add_unless(); atomic_long_add_unless(); | |
| 2497 | − | |
| 2498 | −이것들은 메모리 배리어 효과가 필요한 ACQUIRE 부류와 RELEASE 부류 오퍼레이션들을 | |
| 2499 | −구현할 때, 그리고 객체 해제를 위해 레퍼런스 카운터를 조정할 때, 암묵적 메모리 | |
| 2500 | −배리어 효과가 필요한 곳 등에 사용됩니다. | |
| 2501 | − | |
| 2502 | − | |
| 2503 | −다음의 오퍼레이션들은 메모리 배리어를 내포하지 _않기_ 때문에 문제가 될 수 | |
| 2504 | −있지만, RELEASE 부류의 오퍼레이션들과 같은 것들을 구현할 때 사용될 수도 | |
| 2505 | −있습니다: | |
| 2506 | − | |
| 2507 | − atomic_set(); | |
| 2508 | − set_bit(); | |
| 2509 | − clear_bit(); | |
| 2510 | − change_bit(); | |
| 2511 | − | |
| 2512 | −이것들을 사용할 때에는 필요하다면 적절한 (예를 들면 smp_mb__before_atomic() | |
| 2513 | −같은) 메모리 배리어가 명시적으로 함께 사용되어야 합니다. | |
| 2514 | − | |
| 2515 | − | |
| 2516 | −아래의 것들도 메모리 배리어를 내포하지 _않기_ 때문에, 일부 환경에서는 (예를 | |
| 2517 | −들면 smp_mb__before_atomic() 과 같은) 명시적인 메모리 배리어 사용이 필요합니다. | |
| 2518 | − | |
| 2519 | − atomic_add(); | |
| 2520 | − atomic_sub(); | |
| 2521 | − atomic_inc(); | |
| 2522 | − atomic_dec(); | |
| 2523 | − | |
| 2524 | −이것들이 통계 생성을 위해 사용된다면, 그리고 통계 데이터 사이에 관계가 존재하지 | |
| 2525 | −않는다면 메모리 배리어는 필요치 않을 겁니다. | |
| 2526 | − | |
| 2527 | −객체의 수명을 관리하기 위해 레퍼런스 카운팅 목적으로 사용된다면, 레퍼런스 | |
| 2528 | −카운터는 락으로 보호되는 섹션에서만 조정되거나 호출하는 쪽이 이미 충분한 | |
| 2529 | −레퍼런스를 잡고 있을 것이기 때문에 메모리 배리어는 아마 필요 없을 겁니다. | |
| 2530 | − | |
| 2531 | −만약 어떤 락을 구성하기 위해 사용된다면, 락 관련 동작은 일반적으로 작업을 특정 | |
| 2532 | −순서대로 진행해야 하므로 메모리 배리어가 필요할 수 있습니다. | |
| 2533 | − | |
| 2534 | −기본적으로, 각 사용처에서는 메모리 배리어가 필요한지 아닌지 충분히 고려해야 | |
| 2535 | −합니다. | |
| 2536 | − | |
| 2537 | −아래의 오퍼레이션들은 특별한 락 관련 동작들입니다: | |
| 2538 | − | |
| 2539 | − test_and_set_bit_lock(); | |
| 2540 | − clear_bit_unlock(); | |
| 2541 | − __clear_bit_unlock(); | |
| 2542 | − | |
| 2543 | −이것들은 ACQUIRE 류와 RELEASE 류의 오퍼레이션들을 구현합니다. 락 관련 도구를 | |
| 2544 | −구현할 때에는 이것들을 좀 더 선호하는 편이 나은데, 이것들의 구현은 많은 | |
| 2545 | −아키텍쳐에서 최적화 될 수 있기 때문입니다. | |
| 2546 | − | |
| 2547 | −[!] 이런 상황에 사용할 수 있는 특수한 메모리 배리어 도구들이 있습니다만, 일부 | |
| 2548 | −CPU 에서는 사용되는 어토믹 인스트럭션 자체에 메모리 배리어가 내포되어 있어서 | |
| 2549 | −어토믹 오퍼레이션과 메모리 배리어를 함께 사용하는 게 불필요한 일이 될 수 | |
| 2550 | −있는데, 그런 경우에 이 특수 메모리 배리어 도구들은 no-op 이 되어 실질적으로 | |
| 2551 | −아무일도 하지 않습니다. | |
| 2552 | − | |
| 2553 | −더 많은 내용을 위해선 Documentation/core-api/atomic_ops.rst 를 참고하세요. | |
| 2476 | +더 많은 내용을 위해선 Documentation/atomic_t.txt 를 참고하세요. | |
| 2554 | 2477 | |
| 2555 | 2478 | |
| 2556 | 2479 | 디바이스 액세스 |
| @@ -149,9 +149,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 · 148 unmodified lines | ||
| 149 | 149 | 核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册 |
| 150 | 150 | 页等不同格式的文档： |
| 151 | 151 | make pdfdocs |
| 152 | − make psdocs | |
| 153 | 152 | make htmldocs |
| 154 | − make mandocs | |
| 155 | 153 | |
| 156 | 154 | |
| 157 | 155 | 如何成为内核开发者 |
| @@ -87,11 +87,16 @@ Return values · 86 unmodified lines | ||
| 87 | 87 | A seccomp filter may return any of the following values. If multiple |
| 88 | 88 | filters exist, the return value for the evaluation of a given system |
| 89 | 89 | call will always use the highest precedent value. (For example, |
| 90 | −``SECCOMP_RET_KILL`` will always take precedence.) | |
| 90 | +``SECCOMP_RET_KILL_PROCESS`` will always take precedence.) | |
| 91 | 91 | |
| 92 | 92 | In precedence order, they are: |
| 93 | 93 | |
| 94 | −``SECCOMP_RET_KILL``: | |
| 94 | +``SECCOMP_RET_KILL_PROCESS``: | |
| 95 | + Results in the entire process exiting immediately without executing | |
| 96 | + the system call. The exit status of the task (``status & 0x7f``) | |
| 97 | + will be ``SIGSYS``, not ``SIGKILL``. | |
| 98 | + | |
| 99 | +``SECCOMP_RET_KILL_THREAD``: | |
| 95 | 100 | Results in the task exiting immediately without executing the |
| 96 | 101 | system call. The exit status of the task (``status & 0x7f``) will |
| 97 | 102 | be ``SIGSYS``, not ``SIGKILL``. |
| @@ -141,6 +146,15 @@ In precedence order, they are: · 43 unmodified lines | ||
| 141 | 146 | allow use of ptrace, even of other sandboxed processes, without |
| 142 | 147 | extreme care; ptracers can use this mechanism to escape.) |
| 143 | 148 | |
| 149 | +``SECCOMP_RET_LOG``: | |
| 150 | + Results in the system call being executed after it is logged. This | |
| 151 | + should be used by application developers to learn which syscalls their | |
| 152 | + application needs without having to iterate through multiple test and | |
| 153 | + development cycles to build the list. | |
| 154 | + | |
| 155 | + This action will only be logged if "log" is present in the | |
| 156 | + actions_logged sysctl string. | |
| 157 | + | |
| 144 | 158 | ``SECCOMP_RET_ALLOW``: |
| 145 | 159 | Results in the system call being executed. |
| 146 | 160 | |
| @@ -169,7 +183,41 @@ The ``samples/seccomp/`` directory contains both an x86-specific example · 22 unmodified lines | ||
| 169 | 183 | and a more generic example of a higher level macro interface for BPF |
| 170 | 184 | program generation. |
| 171 | 185 | |
| 186 | +Sysctls | |
| 187 | +======= | |
| 172 | 188 | |
| 189 | +Seccomp's sysctl files can be found in the ``/proc/sys/kernel/seccomp/`` | |
| 190 | +directory. Here's a description of each file in that directory: | |
| 191 | + | |
| 192 | +``actions_avail``: | |
| 193 | + A read-only ordered list of seccomp return values (refer to the | |
| 194 | + ``SECCOMP_RET_*`` macros above) in string form. The ordering, from | |
| 195 | + left-to-right, is the least permissive return value to the most | |
| 196 | + permissive return value. | |
| 197 | + | |
| 198 | + The list represents the set of seccomp return values supported | |
| 199 | + by the kernel. A userspace program may use this list to | |
| 200 | + determine if the actions found in the ``seccomp.h``, when the | |
| 201 | + program was built, differs from the set of actions actually | |
| 202 | + supported in the current running kernel. | |
| 203 | + | |
| 204 | +``actions_logged``: | |
| 205 | + A read-write ordered list of seccomp return values (refer to the | |
| 206 | + ``SECCOMP_RET_*`` macros above) that are allowed to be logged. Writes | |
| 207 | + to the file do not need to be in ordered form but reads from the file | |
| 208 | + will be ordered in the same way as the actions_avail sysctl. | |
| 209 | + | |
| 210 | + It is important to note that the value of ``actions_logged`` does not | |
| 211 | + prevent certain actions from being logged when the audit subsystem is | |
| 212 | + configured to audit a task. If the action is not found in | |
| 213 | + ``actions_logged`` list, the final decision on whether to audit the | |
| 214 | + action for that task is ultimately left up to the audit subsystem to | |
| 215 | + decide for all seccomp return values other than ``SECCOMP_RET_ALLOW``. | |
| 216 | + | |
| 217 | + The ``allow`` string is not accepted in the ``actions_logged`` sysctl | |
| 218 | + as it is not possible to log ``SECCOMP_RET_ALLOW`` actions. Attempting | |
| 219 | + to write ``allow`` to the sysctl will result in an EINVAL being | |
| 220 | + returned. | |
| 173 | 221 | |
| 174 | 222 | Adding architecture support |
| 175 | 223 | =========================== |
| @@ -83,6 +83,11 @@ Groups: · 82 unmodified lines | ||
| 83 | 83 | |
| 84 | 84 | Bits for undefined preemption levels are RAZ/WI. |
| 85 | 85 | |
| 86 | + Note that this differs from a CPU's view of the APRs on hardware in which | |
| 87 | + a GIC without the security extensions expose group 0 and group 1 active | |
| 88 | + priorities in separate register groups, whereas we show a combined view | |
| 89 | + similar to GICv2's GICH_APR. | |
| 90 | + | |
| 86 | 91 | For historical reasons and to provide ABI compatibility with userspace we |
| 87 | 92 | export the GICC_PMR register in the format of the GICH_VMCR.VMPriMask |
| 88 | 93 | field in the lower 5 bits of a word, meaning that userspace must always |
| @@ -176,7 +176,8 @@ Architectures: s390 · 175 unmodified lines | ||
| 176 | 176 | |
| 177 | 177 | 3.1. ATTRIBUTE: KVM_S390_VM_TOD_HIGH |
| 178 | 178 | |
| 179 | −Allows user space to set/get the TOD clock extension (u8). | |
| 179 | +Allows user space to set/get the TOD clock extension (u8) (superseded by | |
| 180 | +KVM_S390_VM_TOD_EXT). | |
| 180 | 181 | |
| 181 | 182 | Parameters: address of a buffer in user space to store the data (u8) to |
| 182 | 183 | Returns: -EFAULT if the given address is not accessible from kernel space |
| @@ -190,6 +191,17 @@ the POP (u64). · 7 unmodified lines | ||
| 190 | 191 | Parameters: address of a buffer in user space to store the data (u64) to |
| 191 | 192 | Returns: -EFAULT if the given address is not accessible from kernel space |
| 192 | 193 | |
| 194 | +3.3. ATTRIBUTE: KVM_S390_VM_TOD_EXT | |
| 195 | +Allows user space to set/get bits 0-63 of the TOD clock register as defined in | |
| 196 | +the POP (u64). If the guest CPU model supports the TOD clock extension (u8), it | |
| 197 | +also allows user space to get/set it. If the guest CPU model does not support | |
| 198 | +it, it is stored as 0 and not allowed to be set to a value != 0. | |
| 199 | + | |
| 200 | +Parameters: address of a buffer in user space to store the data | |
| 201 | + (kvm_s390_vm_tod_clock) to | |
| 202 | +Returns: -EFAULT if the given address is not accessible from kernel space | |
| 203 | + -EINVAL if setting the TOD clock extension to != 0 is not supported | |
| 204 | + | |
| 193 | 205 | 4. GROUP: KVM_S390_VM_CRYPTO |
| 194 | 206 | Architectures: s390 |
| 195 | 207 | |
| @@ -0,0 +1,384 @@ | ||
| 1 | +Heterogeneous Memory Management (HMM) | |
| 2 | + | |
| 3 | +Transparently allow any component of a program to use any memory region of said | |
| 4 | +program with a device without using device specific memory allocator. This is | |
| 5 | +becoming a requirement to simplify the use of advance heterogeneous computing | |
| 6 | +where GPU, DSP or FPGA are use to perform various computations. | |
| 7 | + | |
| 8 | +This document is divided as follow, in the first section i expose the problems | |
| 9 | +related to the use of a device specific allocator. The second section i expose | |
| 10 | +the hardware limitations that are inherent to many platforms. The third section | |
| 11 | +gives an overview of HMM designs. The fourth section explains how CPU page- | |
| 12 | +table mirroring works and what is HMM purpose in this context. Fifth section | |
| 13 | +deals with how device memory is represented inside the kernel. Finaly the last | |
| 14 | +section present the new migration helper that allow to leverage the device DMA | |
| 15 | +engine. | |
| 16 | + | |
| 17 | + | |
| 18 | +1) Problems of using device specific memory allocator: | |
| 19 | +2) System bus, device memory characteristics | |
| 20 | +3) Share address space and migration | |
| 21 | +4) Address space mirroring implementation and API | |
| 22 | +5) Represent and manage device memory from core kernel point of view | |
| 23 | +6) Migrate to and from device memory | |
| 24 | +7) Memory cgroup (memcg) and rss accounting | |
| 25 | + | |
| 26 | + | |
| 27 | +------------------------------------------------------------------------------- | |
| 28 | + | |
| 29 | +1) Problems of using device specific memory allocator: | |
| 30 | + | |
| 31 | +Device with large amount of on board memory (several giga bytes) like GPU have | |
| 32 | +historically manage their memory through dedicated driver specific API. This | |
| 33 | +creates a disconnect between memory allocated and managed by device driver and | |
| 34 | +regular application memory (private anonymous, share memory or regular file | |
| 35 | +back memory). From here on i will refer to this aspect as split address space. | |
| 36 | +I use share address space to refer to the opposite situation ie one in which | |
| 37 | +any memory region can be use by device transparently. | |
| 38 | + | |
| 39 | +Split address space because device can only access memory allocated through the | |
| 40 | +device specific API. This imply that all memory object in a program are not | |
| 41 | +equal from device point of view which complicate large program that rely on a | |
| 42 | +wide set of libraries. | |
| 43 | + | |
| 44 | +Concretly this means that code that wants to leverage device like GPU need to | |
| 45 | +copy object between genericly allocated memory (malloc, mmap private/share/) | |
| 46 | +and memory allocated through the device driver API (this still end up with an | |
| 47 | +mmap but of the device file). | |
| 48 | + | |
| 49 | +For flat dataset (array, grid, image, ...) this isn't too hard to achieve but | |
| 50 | +complex data-set (list, tree, ...) are hard to get right. Duplicating a complex | |
| 51 | +data-set need to re-map all the pointer relations between each of its elements. | |
| 52 | +This is error prone and program gets harder to debug because of the duplicate | |
| 53 | +data-set. | |
| 54 | + | |
| 55 | +Split address space also means that library can not transparently use data they | |
| 56 | +are getting from core program or other library and thus each library might have | |
| 57 | +to duplicate its input data-set using specific memory allocator. Large project | |
| 58 | +suffer from this and waste resources because of the various memory copy. | |
| 59 | + | |
| 60 | +Duplicating each library API to accept as input or output memory allocted by | |
| 61 | +each device specific allocator is not a viable option. It would lead to a | |
| 62 | +combinatorial explosions in the library entry points. | |
| 63 | + | |
| 64 | +Finaly with the advance of high level language constructs (in C++ but in other | |
| 65 | +language too) it is now possible for compiler to leverage GPU or other devices | |
| 66 | +without even the programmer knowledge. Some of compiler identified patterns are | |
| 67 | +only do-able with a share address. It is as well more reasonable to use a share | |
| 68 | +address space for all the other patterns. | |
| 69 | + | |
| 70 | + | |
| 71 | +------------------------------------------------------------------------------- | |
| 72 | + | |
| 73 | +2) System bus, device memory characteristics | |
| 74 | + | |
| 75 | +System bus cripple share address due to few limitations. Most system bus only | |
| 76 | +allow basic memory access from device to main memory, even cache coherency is | |
| 77 | +often optional. Access to device memory from CPU is even more limited, most | |
| 78 | +often than not it is not cache coherent. | |
| 79 | + | |
| 80 | +If we only consider the PCIE bus than device can access main memory (often | |
| 81 | +through an IOMMU) and be cache coherent with the CPUs. However it only allows | |
| 82 | +a limited set of atomic operation from device on main memory. This is worse | |
| 83 | +in the other direction the CPUs can only access a limited range of the device | |
| 84 | +memory and can not perform atomic operations on it. Thus device memory can not | |
| 85 | +be consider like regular memory from kernel point of view. | |
| 86 | + | |
| 87 | +Another crippling factor is the limited bandwidth (~32GBytes/s with PCIE 4.0 | |
| 88 | +and 16 lanes). This is 33 times less that fastest GPU memory (1 TBytes/s). | |
| 89 | +The final limitation is latency, access to main memory from the device has an | |
| 90 | +order of magnitude higher latency than when the device access its own memory. | |
| 91 | + | |
| 92 | +Some platform are developing new system bus or additions/modifications to PCIE | |
| 93 | +to address some of those limitations (OpenCAPI, CCIX). They mainly allow two | |
| 94 | +way cache coherency between CPU and device and allow all atomic operations the | |
| 95 | +architecture supports. Saddly not all platform are following this trends and | |
| 96 | +some major architecture are left without hardware solutions to those problems. | |
| 97 | + | |
| 98 | +So for share address space to make sense not only we must allow device to | |
| 99 | +access any memory memory but we must also permit any memory to be migrated to | |
| 100 | +device memory while device is using it (blocking CPU access while it happens). | |
| 101 | + | |
| 102 | + | |
| 103 | +------------------------------------------------------------------------------- | |
| 104 | + | |
| 105 | +3) Share address space and migration | |
| 106 | + | |
| 107 | +HMM intends to provide two main features. First one is to share the address | |
| 108 | +space by duplication the CPU page table into the device page table so same | |
| 109 | +address point to same memory and this for any valid main memory address in | |
| 110 | +the process address space. | |
| 111 | + | |
| 112 | +To achieve this, HMM offer a set of helpers to populate the device page table | |
| 113 | +while keeping track of CPU page table updates. Device page table updates are | |
| 114 | +not as easy as CPU page table updates. To update the device page table you must | |
| 115 | +allow a buffer (or use a pool of pre-allocated buffer) and write GPU specifics | |
| 116 | +commands in it to perform the update (unmap, cache invalidations and flush, | |
| 117 | +...). This can not be done through common code for all device. Hence why HMM | |
| 118 | +provides helpers to factor out everything that can be while leaving the gory | |
| 119 | +details to the device driver. | |
| 120 | + | |
| 121 | +The second mechanism HMM provide is a new kind of ZONE_DEVICE memory that does | |
| 122 | +allow to allocate a struct page for each page of the device memory. Those page | |
| 123 | +are special because the CPU can not map them. They however allow to migrate | |
| 124 | +main memory to device memory using exhisting migration mechanism and everything | |
| 125 | +looks like if page was swap out to disk from CPU point of view. Using a struct | |
| 126 | +page gives the easiest and cleanest integration with existing mm mechanisms. | |
| 127 | +Again here HMM only provide helpers, first to hotplug new ZONE_DEVICE memory | |
| 128 | +for the device memory and second to perform migration. Policy decision of what | |
| 129 | +and when to migrate things is left to the device driver. | |
| 130 | + | |
| 131 | +Note that any CPU access to a device page trigger a page fault and a migration | |
| 132 | +back to main memory ie when a page backing an given address A is migrated from | |
| 133 | +a main memory page to a device page then any CPU access to address A trigger a | |
| 134 | +page fault and initiate a migration back to main memory. | |
| 135 | + | |
| 136 | + | |
| 137 | +With this two features, HMM not only allow a device to mirror a process address | |
| 138 | +space and keeps both CPU and device page table synchronize, but also allow to | |
| 139 | +leverage device memory by migrating part of data-set that is actively use by a | |
| 140 | +device. | |
| 141 | + | |
| 142 | + | |
| 143 | +------------------------------------------------------------------------------- | |
| 144 | + | |
| 145 | +4) Address space mirroring implementation and API | |
| 146 | + | |
| 147 | +Address space mirroring main objective is to allow to duplicate range of CPU | |
| 148 | +page table into a device page table and HMM helps keeping both synchronize. A | |
| 149 | +device driver that want to mirror a process address space must start with the | |
| 150 | +registration of an hmm_mirror struct: | |
| 151 | + | |
| 152 | + int hmm_mirror_register(struct hmm_mirror *mirror, | |
| 153 | + struct mm_struct *mm); | |
| 154 | + int hmm_mirror_register_locked(struct hmm_mirror *mirror, | |
| 155 | + struct mm_struct *mm); | |
| 156 | + | |
| 157 | +The locked variant is to be use when the driver is already holding the mmap_sem | |
| 158 | +of the mm in write mode. The mirror struct has a set of callback that are use | |
| 159 | +to propagate CPU page table: | |
| 160 | + | |
| 161 | + struct hmm_mirror_ops { | |
| 162 | + /* sync_cpu_device_pagetables() - synchronize page tables | |
| 163 | + * | |
| 164 | + * @mirror: pointer to struct hmm_mirror | |
| 165 | + * @update_type: type of update that occurred to the CPU page table | |
| 166 | + * @start: virtual start address of the range to update | |
| 167 | + * @end: virtual end address of the range to update | |
| 168 | + * | |
| 169 | + * This callback ultimately originates from mmu_notifiers when the CPU | |
| 170 | + * page table is updated. The device driver must update its page table | |
| 171 | + * in response to this callback. The update argument tells what action | |
| 172 | + * to perform. | |
| 173 | + * | |
| 174 | + * The device driver must not return from this callback until the device | |
| 175 | + * page tables are completely updated (TLBs flushed, etc); this is a | |
| 176 | + * synchronous call. | |
| 177 | + */ | |
| 178 | + void (*update)(struct hmm_mirror *mirror, | |
| 179 | + enum hmm_update action, | |
| 180 | + unsigned long start, | |
| 181 | + unsigned long end); | |
| 182 | + }; | |
| 183 | + | |
| 184 | +Device driver must perform update to the range following action (turn range | |
| 185 | +read only, or fully unmap, ...). Once driver callback returns the device must | |
| 186 | +be done with the update. | |
| 187 | + | |
| 188 | + | |
| 189 | +When device driver wants to populate a range of virtual address it can use | |
| 190 | +either: | |
| 191 | + int hmm_vma_get_pfns(struct vm_area_struct *vma, | |
| 192 | + struct hmm_range *range, | |
| 193 | + unsigned long start, | |
| 194 | + unsigned long end, | |
| 195 | + hmm_pfn_t *pfns); | |
| 196 | + int hmm_vma_fault(struct vm_area_struct *vma, | |
| 197 | + struct hmm_range *range, | |
| 198 | + unsigned long start, | |
| 199 | + unsigned long end, | |
| 200 | + hmm_pfn_t *pfns, | |
| 201 | + bool write, | |
| 202 | + bool block); | |
| 203 | + | |
| 204 | +First one (hmm_vma_get_pfns()) will only fetch present CPU page table entry and | |
| 205 | +will not trigger a page fault on missing or non present entry. The second one | |
179 more lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 400 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 180 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 1063 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 190 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 526 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 538 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 211 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 140 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 259 lines aren’t shown here.
This diff is large: its 349 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 351 lines aren’t shown here.
This diff is large: its 648 lines aren’t shown here.
This diff is large: its 424 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 247 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 292 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 298 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 279 lines aren’t shown here.
This diff is large: its 292 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 225 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 469 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 238 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 242 lines aren’t shown here.
This diff is large: its 327 lines aren’t shown here.
This diff is large: its 488 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 369 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 305 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 735 lines aren’t shown here.
This diff is large: its 201 lines aren’t shown here.
This diff is large: its 449 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 211 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 322 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 261 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 274 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 2696 lines aren’t shown here.
This diff is large: its 230 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 208 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 279 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 220 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 192 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 217 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 355 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 417 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 487 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 190 lines aren’t shown here.
This diff is large: its 334 lines aren’t shown here.
This diff is large: its 542 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 217 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 229 lines aren’t shown here.
This diff is large: its 548 lines aren’t shown here.
This diff is large: its 241 lines aren’t shown here.
This diff is large: its 645 lines aren’t shown here.
This diff is large: its 442 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 368 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 351 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 265 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 273 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 209 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 452 lines aren’t shown here.
This diff is large: its 601 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 423 lines aren’t shown here.
This diff is large: its 266 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 329 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 403 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 201 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 649 lines aren’t shown here.
This diff is large: its 194 lines aren’t shown here.
This diff is large: its 241 lines aren’t shown here.
This diff is large: its 348 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 445 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 203 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 210 lines aren’t shown here.
This diff is large: its 221 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 377 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 388 lines aren’t shown here.
This diff is large: its 165 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 724 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 377 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 351 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 345 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 1996 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 371 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 228 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 834 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 206 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 254 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 213 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 352 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 446 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 206 lines aren’t shown here.
This diff is large: its 400 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 205 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 3163 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 724 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 306 lines aren’t shown here.
This diff is large: its 293 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 190 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 1307 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
File renamed without changes.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
File renamed without changes.
This diff is large: its 344 lines aren’t shown here.
File renamed without changes.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
File renamed without changes.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 283 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 227 lines aren’t shown here.
This diff is large: its 245 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 213 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 1135 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 468 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 663 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 192 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 305 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 248 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 528 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 254 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 319 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 924 lines aren’t shown here.
This diff is large: its 353 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 346 lines aren’t shown here.
This diff is large: its 421 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 213 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 210 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 583 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 268 lines aren’t shown here.
This diff is large: its 1767 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 165 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 273 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 287 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 198 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 173 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 179 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 614 lines aren’t shown here.
This diff is large: its 441 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 500 lines aren’t shown here.
This diff is large: its 1523 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 224 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 372 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 255 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 297 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 583 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 233 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 638 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 541 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 1622 lines aren’t shown here.
This diff is large: its 647 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 1559 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 194 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 335 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 594 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 487 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 249 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 488 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 450 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 330 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 286 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 705 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 1027 lines aren’t shown here.
This diff is large: its 953 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 468 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 497 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 339 lines aren’t shown here.
This diff is large: its 206 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 304 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 269 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 511 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 302 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 5589 lines aren’t shown here.
This diff is large: its 1010 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 311 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 167 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 312 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 337 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 368 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 5416 lines aren’t shown here.
This diff is large: its 434 lines aren’t shown here.
This diff is large: its 270 lines aren’t shown here.
This diff is large: its 1654 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 217 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 457 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 1719 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 4841 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 795 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 275 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 332 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 537 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 347 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 432 lines aren’t shown here.
This diff is large: its 391 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 1411 lines aren’t shown here.
This diff is large: its 314 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 262 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 218 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 237 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 684 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 1457 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 1291 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 253 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 240 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 649 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 782 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 3193 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 235 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 165 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 300 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 245 lines aren’t shown here.
This diff is large: its 357 lines aren’t shown here.
This diff is large: its 294 lines aren’t shown here.
This diff is large: its 278 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 257 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 680 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 260 lines aren’t shown here.
This diff is large: its 169 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 1576 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 255 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 928 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 1012 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 260 lines aren’t shown here.
This diff is large: its 136 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 202 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 418 lines aren’t shown here.
This diff is large: its 508 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 147 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 501 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 309 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 374 lines aren’t shown here.
This diff is large: its 640 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 308 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 294 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 398 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 307 lines aren’t shown here.
This diff is large: its 349 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 343 lines aren’t shown here.
This diff is large: its 539 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 519 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 835 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 1030 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 267 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 258 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 194 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 363 lines aren’t shown here.
This diff is large: its 325 lines aren’t shown here.
This diff is large: its 247 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 219 lines aren’t shown here.
This diff is large: its 230 lines aren’t shown here.
This diff is larger than a page shows: the files after these aren’t listed. Clone the repository to see all of it.