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 | N: Mohit Kumar | 2091 | N: Mohit Kumar |
| 2092 | D: ST Microelectronics SPEAr13xx PCI host bridge driver | 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 | N: Gabor Kuti | 2095 | N: Gabor Kuti |
| 2096 | E: seasons@falcon.sch.bme.hu | 2096 | E: seasons@falcon.sch.bme.hu |
| @@ -2606,11 +2606,9 @@ E: tmolina@cablespeed.com · 509 unmodified lines | |||
| 2606 | D: bug fixes, documentation, minor hackery | 2606 | D: bug fixes, documentation, minor hackery |
| 2607 | 2607 | ||
| 2608 | N: Paul Moore | 2608 | N: Paul Moore |
| 2609 | E: paul.moore@hp.com | 2609 | E: paul@paul-moore.com |
| 2610 | D: NetLabel author | 2610 | W: http://www.paul-moore.com |
| 2611 | S: Hewlett-Packard | 2611 | D: NetLabel, SELinux, audit |
| 2612 | S: 110 Spit Brook Road | ||
| 2613 | S: Nashua, NH 03062 | ||
| 2614 | 2612 | ||
| 2615 | N: James Morris | 2613 | N: James Morris |
| 2616 | E: jmorris@namei.org | 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 | Ethernet over USB link | 12 | Ethernet over USB link |
| 13 | dev_addr - MAC address of device's end of this | 13 | dev_addr - MAC address of device's end of this |
| 14 | Ethernet over USB link | 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 | device's debugging info useful for kernel developers. Its | 90 | device's debugging info useful for kernel developers. Its |
| 91 | format is not documented intentionally and may change | 91 | format is not documented intentionally and may change |
| 92 | anytime without any notice. | 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 | unique to allow association with event codes. Units after | 119 | unique to allow association with event codes. Units after |
| 120 | application of scale and offset are milliamps. | 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 | What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw | 131 | What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw |
| 123 | KernelVersion: 3.2 | 132 | KernelVersion: 3.2 |
| 124 | Contact: linux-iio@vger.kernel.org | 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 | Description: When a devices supports Thunderbolt secure connect it will | 45 | Description: When a devices supports Thunderbolt secure connect it will |
| 46 | have this attribute. Writing 32 byte hex string changes | 46 | have this attribute. Writing 32 byte hex string changes |
| 47 | authorization to use the secure connection method instead. | 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 | What: /sys/bus/thunderbolt/devices/.../device | 51 | What: /sys/bus/thunderbolt/devices/.../device |
| 50 | Date: Sep 2017 | 52 | Date: Sep 2017 |
| @@ -45,3 +45,16 @@ Contact: Pratyush Anand <pratyush.anand@gmail.com> · 44 unmodified lines | |||
| 45 | Description: | 45 | Description: |
| 46 | Write to this node to issue "U3 exit" for Link Layer | 46 | Write to this node to issue "U3 exit" for Link Layer |
| 47 | Validation device. It is needed for TD.7.36. | 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 | Description: | 57 | Description: |
| 58 | Controls the issue rate of small discard commands. | 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 | What: /sys/fs/f2fs/<disk>/max_victim_search | 69 | What: /sys/fs/f2fs/<disk>/max_victim_search |
| 61 | Date: January 2014 | 70 | Date: January 2014 |
| 62 | Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> | 71 | Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> |
| @@ -130,3 +139,15 @@ Date: June 2017 · 67 unmodified lines | |||
| 130 | Contact: "Chao Yu" <yuchao0@huawei.com> | 139 | Contact: "Chao Yu" <yuchao0@huawei.com> |
| 131 | Description: | 140 | Description: |
| 132 | Controls current reserved blocks in system. | 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 | This output is useful for system wakeup diagnostics of spurious | 274 | This output is useful for system wakeup diagnostics of spurious |
| 275 | wakeup interrupts. | 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 | void * | 517 | void * |
| 518 | dma_alloc_noncoherent(struct device *dev, size_t size, | 518 | dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle, |
| 519 | dma_addr_t *dma_handle, gfp_t flag) | 519 | gfp_t flag, unsigned long attrs) |
| 520 | 520 | ||
| 521 | Identical to dma_alloc_coherent() except that the platform will | 521 | Identical to dma_alloc_coherent() except that when the |
| 522 | choose to return either consistent or non-consistent memory as it sees | 522 | DMA_ATTR_NON_CONSISTENT flags is passed in the attrs argument, the |
| 523 | fit. By using this API, you are guaranteeing to the platform that you | 523 | platform will choose to return either consistent or non-consistent memory |
| 524 | have all the correct and necessary sync points for this memory in the | 524 | as it sees fit. By using this API, you are guaranteeing to the platform |
| 525 | driver should it choose to return non-consistent memory. | 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 | Note: where the platform can return consistent memory, it will | 528 | Note: where the platform can return consistent memory, it will |
| 528 | guarantee that the sync points become nops. | 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 | void | 538 | void |
| 538 | dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr, | 539 | dma_free_attrs(struct device *dev, size_t size, void *cpu_addr, |
| 539 | dma_addr_t dma_handle) | 540 | dma_addr_t dma_handle, unsigned long attrs) |
| 540 | 541 | ||
| 541 | Free memory allocated by the nonconsistent API. All parameters must | 542 | Free memory allocated by the dma_alloc_attrs(). All parameters common |
| 542 | be identical to those passed in (and returned by | 543 | parameters must identical to those otherwise passed to dma_fre_coherent, |
| 543 | dma_alloc_noncoherent()). | 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 | dma_cache_sync(struct device *dev, void *vaddr, size_t size, | 566 | dma_cache_sync(struct device *dev, void *vaddr, size_t size, |
| 565 | enum dma_data_direction direction) | 567 | enum dma_data_direction direction) |
| 566 | 568 | ||
| 567 | Do a partial sync of memory that was allocated by | 569 | Do a partial sync of memory that was allocated by dma_alloc_attrs() with |
| 568 | dma_alloc_noncoherent(), starting at virtual address vaddr and | 570 | the DMA_ATTR_NON_CONSISTENT flag starting at virtual address vaddr and |
| 569 | continuing on for size. Again, you *must* observe the cache line | 571 | continuing on for size. Again, you *must* observe the cache line |
| 570 | boundaries when doing this. | 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 | flags can be ORed together and are: | 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 | - DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. | 595 | - DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. |
| 606 | Do not allow dma_alloc_coherent() to fall back to system memory when | 596 | Do not allow dma_alloc_coherent() to fall back to system memory when |
| 607 | it's out of memory in the declared region. | 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 | 599 | As a simplification for the platforms, only *one* such region of |
| 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 | ||
| 621 | memory may be declared per device. | 600 | memory may be declared per device. |
| 622 | 601 | ||
| 623 | For reasons of efficiency, most platforms choose to track the declared | 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 | .DEFAULT: | 23 | .DEFAULT: |
| 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.) | 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 | @echo " SKIP Sphinx $@ target." | 27 | @echo " SKIP Sphinx $@ target." |
| 26 | 28 | ||
| 27 | else # HAVE_SPHINX | 29 | else # HAVE_SPHINX |
| @@ -95,16 +97,6 @@ endif # HAVE_SPHINX · 67 unmodified lines | |||
| 95 | # The following targets are independent of HAVE_SPHINX, and the rules should | 97 | # The following targets are independent of HAVE_SPHINX, and the rules should |
| 96 | # work or silently pass without Sphinx. | 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 | cleandocs: | 100 | cleandocs: |
| 109 | $(Q)rm -rf $(BUILDDIR) | 101 | $(Q)rm -rf $(BUILDDIR) |
| 110 | $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean | 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 | <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>. | 2080 | <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>. |
| 2081 | <li> <a href="#Tracing and RCU">Tracing and RCU</a>. | 2081 | <li> <a href="#Tracing and RCU">Tracing and RCU</a>. |
| 2082 | <li> <a href="#Energy Efficiency">Energy Efficiency</a>. | 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 | <li> <a href="#Memory Efficiency">Memory Efficiency</a>. | 2085 | <li> <a href="#Memory Efficiency">Memory Efficiency</a>. |
| 2084 | <li> <a href="#Performance, Scalability, Response Time, and Reliability"> | 2086 | <li> <a href="#Performance, Scalability, Response Time, and Reliability"> |
| 2085 | Performance, Scalability, Response Time, and Reliability</a>. | 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 | Flaming me on the Linux-kernel mailing list was apparently not | 2534 | Flaming me on the Linux-kernel mailing list was apparently not |
| 2533 | sufficient to fully vent their ire at RCU's energy-efficiency bugs! | 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 | <h3><a name="Memory Efficiency">Memory Efficiency</a></h3> | 2665 | <h3><a name="Memory Efficiency">Memory Efficiency</a></h3> |
| 2536 | 2666 | ||
| 2537 | <p> | 2667 | <p> |
| @@ -23,6 +23,14 @@ over a rather long period of time, but improvements are always welcome! · 22 unmodified lines | |||
| 23 | Yet another exception is where the low real-time latency of RCU's | 23 | Yet another exception is where the low real-time latency of RCU's |
| 24 | read-side primitives is critically important. | 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 | 1. Does the update code have proper mutual exclusion? | 34 | 1. Does the update code have proper mutual exclusion? |
| 27 | 35 | ||
| 28 | RCU does allow -readers- to run (almost) naked, but -writers- must | 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 | explain how this single task does not become a major bottleneck on | 48 | explain how this single task does not become a major bottleneck on |
| 41 | big multiprocessor machines (for example, if the task is updating | 49 | big multiprocessor machines (for example, if the task is updating |
| 42 | information relating to itself that other tasks can read, there | 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 | 2. Do the RCU read-side critical sections make proper use of | 55 | 2. Do the RCU read-side critical sections make proper use of |
| 46 | rcu_read_lock() and friends? These primitives are needed | 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 | Disabling of preemption can serve as rcu_read_lock_sched(), but | 65 | Disabling of preemption can serve as rcu_read_lock_sched(), but |
| 56 | is less readable. | 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 | 3. Does the update code tolerate concurrent accesses? | 74 | 3. Does the update code tolerate concurrent accesses? |
| 59 | 75 | ||
| 60 | The whole point of RCU is to permit readers to run without | 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 | This works quite well, also. | 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 | pointer updates to properly aligned fields will | 98 | pointer updates to properly aligned fields will |
| 83 | appear atomic, as will individual atomic primitives. | 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 | appear to be atomic to RCU readers, nor will sequences | 101 | appear to be atomic to RCU readers, nor will sequences |
| 86 | of multiple atomic primitives. | 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 | 5. If call_rcu(), or a related primitive such as call_rcu_bh(), | 185 | 5. If call_rcu(), or a related primitive such as call_rcu_bh(), |
| 170 | call_rcu_sched(), or call_srcu() is used, the callback function | 186 | call_rcu_sched(), or call_srcu() is used, the callback function |
| 171 | must be written to be called from softirq context. In particular, | 187 | will be called from softirq context. In particular, it cannot |
| 172 | it cannot block. | 188 | block. |
| 173 | 189 | ||
| 174 | 6. Since synchronize_rcu() can block, it cannot be called from | 190 | 6. Since synchronize_rcu() can block, it cannot be called from |
| 175 | any sort of irq context. The same rule applies for | 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 | synchronize_sched_expedite(), and synchronize_srcu_expedited(). | 194 | synchronize_sched_expedite(), and synchronize_srcu_expedited(). |
| 179 | 195 | ||
| 180 | The expedited forms of these primitives have the same semantics | 196 | The expedited forms of these primitives have the same semantics |
| 181 | as the non-expedited forms, but expediting is both expensive | 197 | as the non-expedited forms, but expediting is both expensive and |
| 182 | and unfriendly to real-time workloads. Use of the expedited | 198 | (with the exception of synchronize_srcu_expedited()) unfriendly |
| 183 | primitives should be restricted to rare configuration-change | 199 | to real-time workloads. Use of the expedited primitives should |
| 184 | operations that would not normally be undertaken while a real-time | 200 | be restricted to rare configuration-change operations that would |
| 185 | workload is running. | 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 | In particular, if you find yourself invoking one of the expedited | 206 | In particular, if you find yourself invoking one of the expedited |
| 188 | primitives repeatedly in a loop, please do everyone a favor: | 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 | of the system, especially to real-time workloads running on | 212 | of the system, especially to real-time workloads running on |
| 194 | the rest of the system. | 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 | 7. If the updater uses call_rcu() or synchronize_rcu(), then the | 215 | 7. If the updater uses call_rcu() or synchronize_rcu(), then the |
| 202 | corresponding readers must use rcu_read_lock() and | 216 | corresponding readers must use rcu_read_lock() and |
| 203 | rcu_read_unlock(). If the updater uses call_rcu_bh() or | 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 | Similarly, disabling preemption is not an acceptable substitute | 335 | Similarly, disabling preemption is not an acceptable substitute |
| 322 | for rcu_read_lock(). Code that attempts to use preemption | 336 | for rcu_read_lock(). Code that attempts to use preemption |
| 323 | disabling where it should be using rcu_read_lock() will break | 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 | If you want to wait for interrupt handlers, NMI handlers, and | 340 | If you want to wait for interrupt handlers, NMI handlers, and |
| 327 | code under the influence of preempt_disable(), you instead | 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 | not the case, a self-spawning RCU callback would prevent the | 370 | not the case, a self-spawning RCU callback would prevent the |
| 357 | victim CPU from ever going offline.) | 371 | victim CPU from ever going offline.) |
| 358 | 372 | ||
| 359 | 14. SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(), | 373 | 14. Unlike other forms of RCU, it -is- permissible to block in an |
| 360 | synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu()) | 374 | SRCU read-side critical section (demarked by srcu_read_lock() |
| 361 | may only be invoked from process context. Unlike other forms of | 375 | and srcu_read_unlock()), hence the "SRCU": "sleepable RCU". |
| 362 | RCU, it -is- permissible to block in an SRCU read-side critical | 376 | Please note that if you don't need to sleep in read-side critical |
| 363 | section (demarked by srcu_read_lock() and srcu_read_unlock()), | 377 | sections, you should be using RCU rather than SRCU, because RCU |
| 364 | hence the "SRCU": "sleepable RCU". Please note that if you | 378 | is almost always faster and easier to use than is SRCU. |
| 365 | don't need to sleep in read-side critical sections, you should be | 379 | |
| 366 | using RCU rather than SRCU, because RCU is almost always faster | 380 | Also unlike other forms of RCU, explicit initialization and |
| 367 | and easier to use than is SRCU. | 381 | cleanup is required either at build time via DEFINE_SRCU() |
| 368 | 382 | or DEFINE_STATIC_SRCU() or at runtime via init_srcu_struct() | |
| 369 | Also unlike other forms of RCU, explicit initialization | 383 | and cleanup_srcu_struct(). These last two are passed a |
| 370 | and cleanup is required via init_srcu_struct() and | 384 | "struct srcu_struct" that defines the scope of a given |
| 371 | cleanup_srcu_struct(). These are passed a "struct srcu_struct" | 385 | SRCU domain. Once initialized, the srcu_struct is passed |
| 372 | that defines the scope of a given SRCU domain. Once initialized, | 386 | to srcu_read_lock(), srcu_read_unlock() synchronize_srcu(), |
| 373 | the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock() | 387 | synchronize_srcu_expedited(), and call_srcu(). A given |
| 374 | synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu(). | 388 | synchronize_srcu() waits only for SRCU read-side critical |
| 375 | A given synchronize_srcu() waits only for SRCU read-side critical | ||
| 376 | sections governed by srcu_read_lock() and srcu_read_unlock() | 389 | sections governed by srcu_read_lock() and srcu_read_unlock() |
| 377 | calls that have been passed the same srcu_struct. This property | 390 | calls that have been passed the same srcu_struct. This property |
| 378 | is what makes sleeping read-side critical sections tolerable -- | 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 | Therefore, SRCU should be used in preference to rw_semaphore | 403 | Therefore, SRCU should be used in preference to rw_semaphore |
| 391 | only in extremely read-intensive situations, or in situations | 404 | only in extremely read-intensive situations, or in situations |
| 392 | requiring SRCU's read-side deadlock immunity or low read-side | 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 | 409 | SRCU's expedited primitive (synchronize_srcu_expedited()) |
| 396 | to other forms of RCU. | 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 | 15. The whole point of call_rcu(), synchronize_rcu(), and friends | 417 | 15. The whole point of call_rcu(), synchronize_rcu(), and friends |
| 399 | is to wait until all pre-existing readers have finished before | 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 | These debugging aids can help you find problems that are | 455 | These debugging aids can help you find problems that are |
| 437 | otherwise extremely difficult to spot. | 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 | Of these, one was allowed to lapse by the assignee, and the | 76 | Of these, one was allowed to lapse by the assignee, and the |
| 77 | others have been contributed to the Linux kernel under GPL. | 77 | others have been contributed to the Linux kernel under GPL. |
| 78 | There are now also LGPL implementations of user-level RCU | 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 | o I hear that RCU needs work in order to support realtime kernels? | 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 | 83 | Realtime-friendly RCU can be enabled via the CONFIG_PREEMPT_RCU |
| 84 | enabled via the CONFIG_PREEMPT_RCU kernel configuration | 84 | kernel configuration parameter. |
| 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. | ||
| 88 | 85 | ||
| 89 | o Where can I find more information on RCU? | 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 | for an example where the compiler can in fact deduce the exact | 25 | for an example where the compiler can in fact deduce the exact |
| 26 | value of the pointer, and thus cause misordering. | 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 | o Avoid cancellation when using the "+" and "-" infix arithmetic | 45 | o Avoid cancellation when using the "+" and "-" infix arithmetic |
| 29 | operators. For example, for a given variable "x", avoid | 46 | operators. For example, for a given variable "x", avoid |
| 30 | "(x-x)". There are similar arithmetic pitfalls from other | 47 | "(x-(uintptr_t)x)" for char* pointers. The compiler is within its |
| 31 | arithmetic operators, such as "(x*0)", "(x/(x+1))" or "(x%1)". | 48 | rights to substitute zero for this sort of expression, so that |
| 32 | The compiler is within its rights to substitute zero for all of | 49 | subsequent accesses no longer depend on the rcu_dereference(), |
| 33 | these expressions, so that subsequent accesses no longer depend | 50 | again possibly resulting in bugs due to misordering. |
| 34 | on the rcu_dereference(), again possibly resulting in bugs due | ||
| 35 | to misordering. | ||
| 36 | 51 | ||
| 37 | Of course, if "p" is a pointer from rcu_dereference(), and "a" | 52 | Of course, if "p" is a pointer from rcu_dereference(), and "a" |
| 38 | and "b" are integers that happen to be equal, the expression | 53 | and "b" are integers that happen to be equal, the expression |
| 39 | "p+a-b" is safe because its value still necessarily depends on | 54 | "p+a-b" is safe because its value still necessarily depends on |
| 40 | the rcu_dereference(), thus maintaining proper ordering. | 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 | o If you are using RCU to protect JITed functions, so that the | 57 | o If you are using RCU to protect JITed functions, so that the |
| 58 | "()" function-invocation operator is applied to a value obtained | 58 | "()" function-invocation operator is applied to a value obtained |
| 59 | (directly or indirectly) from rcu_dereference(), you may need to | 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 | This issue arises on some systems when a newly JITed function is | 61 | This issue arises on some systems when a newly JITed function is |
| 62 | using the same memory that was used by an earlier JITed function. | 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 | o Do not use the results from relational operators ("==", "!=", | 64 | o Do not use the results from relational operators ("==", "!=", |
| 84 | ">", ">=", "<", or "<=") when dereferencing. For example, | 65 | ">", ">=", "<", or "<=") when dereferencing. For example, |
| 85 | the following (quite strange) code is buggy: | 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 | are delayed for a full grace period? Couldn't this result in | 263 | are delayed for a full grace period? Couldn't this result in |
| 264 | rcu_barrier() returning prematurely? | 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 | rcu_barrier() Summary | 272 | rcu_barrier() Summary |
| 268 | 273 | ||
| @@ -276,15 +276,17 @@ o "Free-Block Circulation": Shows the number of torture structures · 275 unmodified lines | |||
| 276 | somehow gets incremented farther than it should. | 276 | somehow gets incremented farther than it should. |
| 277 | 277 | ||
| 278 | Different implementations of RCU can provide implementation-specific | 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 | additional line: | 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 | 284 | This line shows the per-CPU counter state, in this case for Tree SRCU |
| 285 | the values of the "old" and "current" counters for the corresponding CPU. | 285 | using a dynamically allocated srcu_struct (hence "srcud-" rather than |
| 286 | The "idx" value maps the "old" and "current" values to the underlying | 286 | "srcu-"). The numbers in parentheses are the values of the "old" and |
| 287 | array, and is useful for debugging. | 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 | USAGE | 292 | USAGE |
| @@ -304,3 +306,9 @@ checked for such errors. The "rmmod" command forces a "SUCCESS", · 13 unmodified lines | |||
| 304 | "FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first | 306 | "FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first |
| 305 | two are self-explanatory, while the last indicates that while there | 307 | two are self-explanatory, while the last indicates that while there |
| 306 | were no RCU failures, CPU-hotplug problems were detected. | 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 | srcu_read_lock_held | 890 | srcu_read_lock_held |
| 891 | 891 | ||
| 892 | SRCU: Initialization/cleanup | 892 | SRCU: Initialization/cleanup |
| 893 | DEFINE_SRCU | ||
| 894 | DEFINE_STATIC_SRCU | ||
| 893 | init_srcu_struct | 895 | init_srcu_struct |
| 894 | cleanup_srcu_struct | 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 | b. What about the -rt patchset? If readers would need to block | 915 | b. What about the -rt patchset? If readers would need to block |
| 914 | in an non-rt kernel, you need SRCU. If readers would block | 916 | in an non-rt kernel, you need SRCU. If readers would block |
| 915 | in a -rt kernel, but not in a non-rt kernel, SRCU is not | 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 | c. Do you need to treat NMI handlers, hardirq handlers, | 921 | c. Do you need to treat NMI handlers, hardirq handlers, |
| 919 | and code segments with preemption disabled (whether | 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 | LiveCD-based tutorials are available at | 10 | LiveCD-based tutorials are available at |
| 11 | 11 | ||
| 12 | http://tomoyo.sourceforge.jp/1.7/1st-step/ubuntu10.04-live/ | 12 | http://tomoyo.sourceforge.jp/1.8/ubuntu12.04-live.html |
| 13 | http://tomoyo.sourceforge.jp/1.7/1st-step/centos5-live/ | 13 | http://tomoyo.sourceforge.jp/1.8/centos6-live.html |
| 14 | 14 | ||
| 15 | Though these tutorials use non-LSM version of TOMOYO, they are useful for you | 15 | Though these tutorials use non-LSM version of TOMOYO, they are useful for you |
| 16 | to know what TOMOYO is. | 16 | to know what TOMOYO is. |
| @@ -21,35 +21,35 @@ How to enable TOMOYO? · 4 unmodified lines | |||
| 21 | Build the kernel with ``CONFIG_SECURITY_TOMOYO=y`` and pass ``security=tomoyo`` on | 21 | Build the kernel with ``CONFIG_SECURITY_TOMOYO=y`` and pass ``security=tomoyo`` on |
| 22 | kernel's command line. | 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 | Where is documentation? | 26 | Where is documentation? |
| 27 | ======================= | 27 | ======================= |
| 28 | 28 | ||
| 29 | User <-> Kernel interface documentation is available at | 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 | Materials we prepared for seminars and symposiums are available at | 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 | Below lists are chosen from three aspects. | 34 | Below lists are chosen from three aspects. |
| 35 | 35 | ||
| 36 | What is TOMOYO? | 36 | What is TOMOYO? |
| 37 | TOMOYO Linux Overview | 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 | TOMOYO Linux: pragmatic and manageable security for Linux | 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 | TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box | 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 | What can TOMOYO do? | 44 | What can TOMOYO do? |
| 45 | Deep inside TOMOYO Linux | 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 | The role of "pathname based access control" in security. | 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 | History of TOMOYO? | 50 | History of TOMOYO? |
| 51 | Realities of Mainlining | 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 | What is future plan? | 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 | SELinux/SMACK/AppArmor etc. when you want to use TOMOYO. | 60 | SELinux/SMACK/AppArmor etc. when you want to use TOMOYO. |
| 61 | 61 | ||
| 62 | We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM | 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 | LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning | 64 | LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning |
| 65 | to port non-LSM version's functionalities to LSM versions. | 65 | to port non-LSM version's functionalities to LSM versions. |
| @@ -3081,3 +3081,8 @@ · 3080 unmodified lines | |||
| 3081 | 1 = /dev/osd1 Second OSD Device | 3081 | 1 = /dev/osd1 Second OSD Device |
| 3082 | ... | 3082 | ... |
| 3083 | 255 = /dev/osd255 256th OSD Device | 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 | PPT Parallel port support is enabled. | 138 | PPT Parallel port support is enabled. |
| 139 | PS2 Appropriate PS/2 support is enabled. | 139 | PS2 Appropriate PS/2 support is enabled. |
| 140 | RAM RAM disk support is enabled. | 140 | RAM RAM disk support is enabled. |
| 141 | RDT Intel Resource Director Technology. | ||
| 141 | S390 S390 architecture is enabled. | 142 | S390 S390 architecture is enabled. |
| 142 | SCSI Appropriate SCSI support is enabled. | 143 | SCSI Appropriate SCSI support is enabled. |
| 143 | A lot of drivers have their options described inside | 144 | A lot of drivers have their options described inside |
| @@ -2233,6 +2233,17 @@ · 2232 unmodified lines | |||
| 2233 | memory contents and reserves bad memory | 2233 | memory contents and reserves bad memory |
| 2234 | regions that are detected. | 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 | mem_sleep_default= [SUSPEND] Default system suspend mode: | 2247 | mem_sleep_default= [SUSPEND] Default system suspend mode: |
| 2237 | s2idle - Suspend-To-Idle | 2248 | s2idle - Suspend-To-Idle |
| 2238 | shallow - Power-On Suspend or equivalent (if supported) | 2249 | shallow - Power-On Suspend or equivalent (if supported) |
| @@ -2633,9 +2644,10 @@ · 394 unmodified lines | |||
| 2633 | In kernels built with CONFIG_NO_HZ_FULL=y, set | 2644 | In kernels built with CONFIG_NO_HZ_FULL=y, set |
| 2634 | the specified list of CPUs whose tick will be stopped | 2645 | the specified list of CPUs whose tick will be stopped |
| 2635 | whenever possible. The boot CPU will be forced outside | 2646 | whenever possible. The boot CPU will be forced outside |
| 2636 | the range to maintain the timekeeping. | 2647 | the range to maintain the timekeeping. Any CPUs |
| 2637 | The CPUs in this range must also be included in the | 2648 | in this list will have their RCU callbacks offloaded, |
| 2638 | rcu_nocbs= set. | 2649 | just as if they had also been called out in the |
| 2650 | rcu_nocbs= boot parameter. | ||
| 2639 | 2651 | ||
| 2640 | noiotrap [SH] Disables trapped I/O port accesses. | 2652 | noiotrap [SH] Disables trapped I/O port accesses. |
| 2641 | 2653 | ||
| @@ -2696,6 +2708,8 @@ · 54 unmodified lines | |||
| 2696 | nopat [X86] Disable PAT (page attribute table extension of | 2708 | nopat [X86] Disable PAT (page attribute table extension of |
| 2697 | pagetables) support. | 2709 | pagetables) support. |
| 2698 | 2710 | ||
| 2711 | nopcid [X86-64] Disable the PCID cpu feature. | ||
| 2712 | |||
| 2699 | norandmaps Don't use address space randomization. Equivalent to | 2713 | norandmaps Don't use address space randomization. Equivalent to |
| 2700 | echo 0 > /proc/sys/kernel/randomize_va_space | 2714 | echo 0 > /proc/sys/kernel/randomize_va_space |
| 2701 | 2715 | ||
| @@ -2750,6 +2764,15 @@ · 48 unmodified lines | |||
| 2750 | If the dependencies are under your control, you can | 2764 | If the dependencies are under your control, you can |
| 2751 | turn on cpu0_hotplug. | 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 | nptcg= [IA-64] Override max number of concurrent global TLB | 2776 | nptcg= [IA-64] Override max number of concurrent global TLB |
| 2754 | purges which is reported from either PAL_VM_SUMMARY or | 2777 | purges which is reported from either PAL_VM_SUMMARY or |
| 2755 | SAL PALO. | 2778 | SAL PALO. |
| @@ -2769,7 +2792,7 @@ · 13 unmodified lines | |||
| 2769 | Allowed values are enable and disable | 2792 | Allowed values are enable and disable |
| 2770 | 2793 | ||
| 2771 | numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. | 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 | This can be set from sysctl after boot. | 2796 | This can be set from sysctl after boot. |
| 2774 | See Documentation/sysctl/vm.txt for details. | 2797 | See Documentation/sysctl/vm.txt for details. |
| 2775 | 2798 | ||
| @@ -3598,6 +3621,12 @@ · 822 unmodified lines | |||
| 3598 | Run specified binary instead of /init from the ramdisk, | 3621 | Run specified binary instead of /init from the ramdisk, |
| 3599 | used for early userspace startup. See initrd. | 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 | reboot= [KNL] | 3630 | reboot= [KNL] |
| 3602 | Format (x86 or x86_64): | 3631 | Format (x86 or x86_64): |
| 3603 | [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ | 3632 | [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ |
| @@ -4375,6 +4404,10 @@ · 771 unmodified lines | |||
| 4375 | decrease the size and leave more room for directly | 4404 | decrease the size and leave more room for directly |
| 4376 | mapped kernel RAM. | 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 | vmhalt= [KNL,S390] Perform z/VM CP command after system halt. | 4411 | vmhalt= [KNL,S390] Perform z/VM CP command after system halt. |
| 4379 | Format: <command> | 4412 | Format: <command> |
| 4380 | 4413 | ||
| @@ -479,14 +479,6 @@ This governor exposes the following tunables: · 478 unmodified lines | |||
| 479 | 479 | ||
| 480 | # echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate | 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 | ``up_threshold`` | 482 | ``up_threshold`` |
| 491 | If the estimated CPU load is above this value (in percent), the governor | 483 | If the estimated CPU load is above this value (in percent), the governor |
| 492 | will set the frequency to the maximum value allowed for the policy. | 484 | will set the frequency to the maximum value allowed for the policy. |
| @@ -5,12 +5,6 @@ Power Management · 4 unmodified lines | |||
| 5 | .. toctree:: | 5 | .. toctree:: |
| 6 | :maxdepth: 2 | 6 | :maxdepth: 2 |
| 7 | 7 | ||
| 8 | cpufreq | 8 | strategies |
| 9 | intel_pstate | 9 | system-wide |
| 10 | 10 | working-state | |
| 11 | .. only:: subproject and html | ||
| 12 | |||
| 13 | Indices | ||
| 14 | ======= | ||
| 15 | |||
| 16 | * :ref:`genindex` | ||
| @@ -167,35 +167,17 @@ is set. · 166 unmodified lines | |||
| 167 | ``powersave`` | 167 | ``powersave`` |
| 168 | ............. | 168 | ............. |
| 169 | 169 | ||
| 170 | Without HWP, this P-state selection algorithm generally depends on the | 170 | Without HWP, this P-state selection algorithm is similar to the algorithm |
| 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 | ||
| 180 | implemented by the generic ``schedutil`` scaling governor except that the | 171 | implemented by the generic ``schedutil`` scaling governor except that the |
| 181 | utilization metric used by it is based on numbers coming from feedback | 172 | utilization metric used by it is based on numbers coming from feedback |
| 182 | registers of the CPU. It generally selects P-states proportional to the | 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. | 174 | current CPU utilization. |
| 184 | 175 | ||
| 185 | The second variant of the ``powersave`` P-state selection algorithm, used in all | 176 | This algorithm is run by the driver's utilization update callback for the |
| 186 | of the other cases (generally, on processors from the Core line, so it is | 177 | given CPU when it is invoked by the CPU scheduler, but not more often than |
| 187 | referred to as the "Core" algorithm), is based on the values read from the APERF | 178 | every 10 ms. Like in the ``performance`` case, the hardware configuration |
| 188 | and MPERF feedback registers and the previously requested target P-state. | 179 | is not touched if the new P-state turns out to be the same as the current |
| 189 | It does not really take CPU utilization into account explicitly, but as a rule | 180 | one. |
| 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. | ||
| 199 | 181 | ||
| 200 | This is the default P-state selection algorithm if the | 182 | This is the default P-state selection algorithm if the |
| 201 | :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option | 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 | gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func | 702 | gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func |
| 721 | <idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func | 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 | .. _LCEU2015: http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf | 706 | .. _LCEU2015: http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf |
| 751 | .. _SDM: http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html | 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 | .. _ACPI specification: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf | 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 | /* some platform code, e.g. SMP initialization */ | 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 | CPU1_BOOT_REG); | 64 | CPU1_BOOT_REG); |
| 65 | 65 | ||
| 66 | /* Call Exynos specific smc call */ | 66 | /* Call Exynos specific smc call */ |
| @@ -179,6 +179,8 @@ infrastructure: · 178 unmodified lines | |||
| 179 | | FCMA | [19-16] | y | | 179 | | FCMA | [19-16] | y | |
| 180 | |--------------------------------------------------| | 180 | |--------------------------------------------------| |
| 181 | | JSCVT | [15-12] | y | | 181 | | JSCVT | [15-12] | y | |
| 182 | |--------------------------------------------------| | ||
| 183 | | DPB | [3-0] | y | | ||
| 182 | x--------------------------------------------------x | 184 | x--------------------------------------------------x |
| 183 | 185 | ||
| 184 | Appendix I: Example | 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 | schedules that may lead to a lower throughput. If your main or only | 16 | schedules that may lead to a lower throughput. If your main or only |
| 17 | goal, for a given device, is to achieve the maximum-possible | 17 | goal, for a given device, is to achieve the maximum-possible |
| 18 | throughput at all times, then do switch off all low-latency heuristics | 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 | On average CPUs, the current version of BFQ can handle devices | 23 | On average CPUs, the current version of BFQ can handle devices |
| 22 | performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a | 24 | performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a |
| 23 | reference, 30-50 KIOPS correspond to very high bandwidths with | 25 | reference, 30-50 KIOPS correspond to very high bandwidths with |
| 24 | sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and | 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 | 27 | to 120-200 MB/s with 4KB random I/O. BFQ is currently being tested on |
| 26 | multi-queue devices. | 28 | multi-queue devices too. |
| 27 | 29 | ||
| 28 | The table of contents follow. Impatients can just jump to Section 3. | 30 | The table of contents follow. Impatients can just jump to Section 3. |
| 29 | 31 | ||
| @@ -33,7 +35,7 @@ CONTENTS · 3 unmodified lines | |||
| 33 | 1-1 Personal systems | 35 | 1-1 Personal systems |
| 34 | 1-2 Server systems | 36 | 1-2 Server systems |
| 35 | 2. How does BFQ work? | 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 | 4. BFQ group scheduling | 39 | 4. BFQ group scheduling |
| 38 | 4-1 Service guarantees provided | 40 | 4-1 Service guarantees provided |
| 39 | 4-2 Interface | 41 | 4-2 Interface |
| @@ -145,19 +147,28 @@ plus a lot of code, are borrowed from CFQ. · 105 unmodified lines | |||
| 145 | contrast, BFQ may idle the device for a short time interval, | 147 | contrast, BFQ may idle the device for a short time interval, |
| 146 | giving the process the chance to go on being served if it issues | 148 | giving the process the chance to go on being served if it issues |
| 147 | a new request in time. Device idling typically boosts the | 149 | a new request in time. Device idling typically boosts the |
| 148 | throughput on rotational devices, if processes do synchronous | 150 | throughput on rotational devices and on non-queueing flash-based |
| 149 | and sequential I/O. In addition, under BFQ, device idling is | 151 | devices, if processes do synchronous and sequential I/O. In |
| 150 | also instrumental in guaranteeing the desired throughput | 152 | addition, under BFQ, device idling is also instrumental in |
| 151 | fraction to processes issuing sync requests (see the description | 153 | guaranteeing the desired throughput fraction to processes |
| 152 | of the slice_idle tunable in this document, or [1, 2], for more | 154 | issuing sync requests (see the description of the slice_idle |
| 153 | details). | 155 | tunable in this document, or [1, 2], for more details). |
| 154 | 156 | ||
| 155 | - With respect to idling for service guarantees, if several | 157 | - With respect to idling for service guarantees, if several |
| 156 | processes are competing for the device at the same time, but | 158 | processes are competing for the device at the same time, but |
| 157 | all processes (and groups, after the following commit) have | 159 | all processes and groups have the same weight, then BFQ |
| 158 | the same weight, then BFQ guarantees the expected throughput | 160 | guarantees the expected throughput distribution without ever |
| 159 | distribution without ever idling the device. Throughput is | 161 | idling the device. Throughput is thus as high as possible in |
| 160 | thus as high as possible in this common scenario. | 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 | - If low-latency mode is enabled (default configuration), BFQ | 173 | - If low-latency mode is enabled (default configuration), BFQ |
| 163 | executes some special heuristics to detect interactive and soft | 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 | - Queues are scheduled according to a variant of WF2Q+, named | 202 | - Queues are scheduled according to a variant of WF2Q+, named |
| 192 | B-WF2Q+, and implemented using an augmented rb-tree to preserve an | 203 | B-WF2Q+, and implemented using an augmented rb-tree to preserve an |
| 193 | O(log N) overall complexity. See [2] for more details. B-WF2Q+ is | 204 | O(log N) overall complexity. See [2] for more details. B-WF2Q+ is |
| 194 | also ready for hierarchical scheduling. However, for a cleaner | 205 | also ready for hierarchical scheduling, details in Section 4. |
| 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. | ||
| 198 | 206 | ||
| 199 | - B-WF2Q+ guarantees a tight deviation with respect to an ideal, | 207 | - B-WF2Q+ guarantees a tight deviation with respect to an ideal, |
| 200 | perfectly fair, and smooth service. In particular, B-WF2Q+ | 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 | the Idle class, to prevent it from starving. | 257 | the Idle class, to prevent it from starving. |
| 250 | 258 | ||
| 251 | 259 | ||
| 252 | 3. What are BFQ's tunable? | 260 | 3. What are BFQ's tunables and how to properly configure BFQ? |
| 253 | ========================== | 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 | 273 | In particular, the tunables back_seek-max, back_seek_penalty, |
| 256 | fifo_expire_sync below are the same as in CFQ. Their description is | 274 | fifo_expire_async and fifo_expire_sync below are the same as in |
| 257 | just copied from that for CFQ. Some considerations in the description | 275 | CFQ. Their description is just copied from that for CFQ. Some |
| 258 | of slice_idle are copied from CFQ too. | 276 | considerations in the description of slice_idle are copied from CFQ |
| 277 | too. | ||
| 259 | 278 | ||
| 260 | per-process ioprio and weight | 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 | Setting slice_idle to 0 will remove all the idling on queues and one | 305 | Setting slice_idle to 0 will remove all the idling on queues and one |
| 287 | should see an overall improved throughput on faster storage devices | 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 | So depending on storage and workload, it might be useful to set | 311 | So depending on storage and workload, it might be useful to set |
| 291 | slice_idle=0. In general for SATA/SAS disks and software RAID of | 312 | slice_idle=0. In general for SATA/SAS disks and software RAID of |
| 292 | SATA/SAS disks keeping slice_idle enabled should be useful. For any | 313 | SATA/SAS disks keeping slice_idle enabled should be useful. For any |
| 293 | configurations where there are multiple spindles behind single LUN | 314 | configurations where there are multiple spindles behind single LUN |
| 294 | (Host based hardware RAID controller or for storage arrays), setting | 315 | (Host based hardware RAID controller or for storage arrays), or with |
| 295 | slice_idle=0 might end up in better throughput and acceptable | 316 | flash-based fast storage, setting slice_idle=0 might end up in better |
| 296 | latencies. | 317 | throughput and acceptable latencies. |
| 297 | 318 | ||
| 298 | Idling is however necessary to have service guarantees enforced in | 319 | Idling is however necessary to have service guarantees enforced in |
| 299 | case of differentiated weights or differentiated I/O-request lengths. | 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 | where it is beneficial also for throughput, idling can severely impact | 333 | where it is beneficial also for throughput, idling can severely impact |
| 313 | throughput. One important case is random workload. Because of this | 334 | throughput. One important case is random workload. Because of this |
| 314 | issue, BFQ tends to avoid idling as much as possible, when it is not | 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 | 336 | beneficial also for throughput (as detailed in Section 2). As a |
| 316 | of further issues described for the strict_guarantees tunable, | 337 | consequence of this behavior, and of further issues described for the |
| 317 | short-term service guarantees may be occasionally violated. And, in | 338 | strict_guarantees tunable, short-term service guarantees may be |
| 318 | some cases, these guarantees may be more important than guaranteeing | 339 | occasionally violated. And, in some cases, these guarantees may be |
| 319 | maximum throughput. For example, in video playing/streaming, a very | 340 | more important than guaranteeing maximum throughput. For example, in |
| 320 | low drop rate may be more important than maximum throughput. In these | 341 | video playing/streaming, a very low drop rate may be more important |
| 321 | cases, consider setting the strict_guarantees parameter. | 342 | than maximum throughput. In these cases, consider setting the |
| 343 | strict_guarantees parameter. | ||
| 322 | 344 | ||
| 323 | strict_guarantees | 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 | to the maximum number of sectors that can be served during | 442 | to the maximum number of sectors that can be served during |
| 421 | timeout_sync, according to the estimated peak rate. | 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 | weights | 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 | BFQ queues. | 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 | 4. Group scheduling with BFQ | 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 | comp_algorithm RW show and change the compression algorithm | 168 | comp_algorithm RW show and change the compression algorithm |
| 169 | compact WO trigger memory compaction | 169 | compact WO trigger memory compaction |
| 170 | debug_stat RO this file is used for zram debugging purposes | 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 | User space is advised to use the following files to read the device statistics. | 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 | resets the disksize to zero. You must set the disksize again | 232 | resets the disksize to zero. You must set the disksize again |
| 232 | before reusing the device. | 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 | Nitin Gupta | 245 | Nitin Gupta |
| 235 | ngupta@vflare.org | 246 | ngupta@vflare.org |
| @@ -18,7 +18,9 @@ v1 is available under Documentation/cgroup-v1/. · 17 unmodified lines | |||
| 18 | 1-2. What is cgroup? | 18 | 1-2. What is cgroup? |
| 19 | 2. Basic Operations | 19 | 2. Basic Operations |
| 20 | 2-1. Mounting | 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 | 2-3. [Un]populated Notification | 24 | 2-3. [Un]populated Notification |
| 23 | 2-4. Controlling Controllers | 25 | 2-4. Controlling Controllers |
| 24 | 2-4-1. Enabling and Disabling | 26 | 2-4-1. Enabling and Disabling |
| @@ -167,8 +169,11 @@ cgroup v2 currently supports the following mount options. · 142 unmodified lines | |||
| 167 | Delegation section for details. | 169 | Delegation section for details. |
| 168 | 170 | ||
| 169 | 171 | ||
| 170 | Organizing Processes | 172 | Organizing Processes and Threads |
| 171 | -------------------- | 173 | -------------------------------- |
| 174 | |||
| 175 | Processes | ||
| 176 | ~~~~~~~~~ | ||
| 172 | 177 | ||
| 173 | Initially, only the root cgroup exists to which all processes belong. | 178 | Initially, only the root cgroup exists to which all processes belong. |
| 174 | A child cgroup can be created by creating a sub-directory:: | 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 | 0::/test-cgroup/test-cgroup-nested (deleted) | 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 | [Un]populated Notification | 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 | No Internal Process Constraint | 406 | No Internal Process Constraint |
| 303 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 407 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 304 | 408 | ||
| 305 | Non-root cgroups can only distribute resources to their children when | 409 | Non-root cgroups can distribute domain resources to their children |
| 306 | they don't have any processes of their own. In other words, only | 410 | only when they don't have any processes of their own. In other words, |
| 307 | cgroups which don't contain any processes can have controllers enabled | 411 | only domain cgroups which don't contain any processes can have domain |
| 308 | in their "cgroup.subtree_control" files. | 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 | 414 | This guarantees that, when a domain controller is looking at the part |
| 311 | hierarchy which has it enabled, processes are always only on the | 415 | of the hierarchy which has it enabled, processes are always only on |
| 312 | leaves. This rules out situations where child cgroups compete against | 416 | the leaves. This rules out situations where child cgroups compete |
| 313 | internal processes of the parent. | 417 | against internal processes of the parent. |
| 314 | 418 | ||
| 315 | The root cgroup is exempt from this restriction. Root contains | 419 | The root cgroup is exempt from this restriction. Root contains |
| 316 | processes and anonymous resource consumption which can't be associated | 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 | A cgroup can be delegated in two ways. First, to a less privileged | 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" | 441 | user by granting write access of the directory and its "cgroup.procs", |
| 338 | and "cgroup.subtree_control" files to the user. Second, if the | 442 | "cgroup.threads" and "cgroup.subtree_control" files to the user. |
| 339 | "nsdelegate" mount option is set, automatically to a cgroup namespace | 443 | Second, if the "nsdelegate" mount option is set, automatically to a |
| 340 | on namespace creation. | 444 | cgroup namespace on namespace creation. |
| 341 | 445 | ||
| 342 | Because the resource control interface files in a given directory | 446 | Because the resource control interface files in a given directory |
| 343 | control the distribution of the parent's resources, the delegatee | 447 | control the distribution of the parent's resources, the delegatee |
| @@ -644,6 +748,29 @@ Core Interface Files · 300 unmodified lines | |||
| 644 | 748 | ||
| 645 | All cgroup core files are prefixed with "cgroup." | 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 | cgroup.procs | 774 | cgroup.procs |
| 648 | A read-write new-line separated values file which exists on | 775 | A read-write new-line separated values file which exists on |
| 649 | all cgroups. | 776 | all cgroups. |
| @@ -658,9 +785,6 @@ All cgroup core files are prefixed with "cgroup." · 8 unmodified lines | |||
| 658 | the PID to the cgroup. The writer should match all of the | 785 | the PID to the cgroup. The writer should match all of the |
| 659 | following conditions. | 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 | - It must have write access to the "cgroup.procs" file. | 788 | - It must have write access to the "cgroup.procs" file. |
| 665 | 789 | ||
| 666 | - It must have write access to the "cgroup.procs" file of the | 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 | When delegating a sub-hierarchy, write access to this file | 793 | When delegating a sub-hierarchy, write access to this file |
| 670 | should be granted along with the containing directory. | 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 | cgroup.controllers | 825 | cgroup.controllers |
| 673 | A read-only space separated values file which exists on all | 826 | A read-only space separated values file which exists on all |
| 674 | cgroups. | 827 | cgroups. |
| @@ -701,6 +854,38 @@ All cgroup core files are prefixed with "cgroup." · 26 unmodified lines | |||
| 701 | 1 if the cgroup or its descendants contains any live | 854 | 1 if the cgroup or its descendants contains any live |
| 702 | processes; otherwise, 0. | 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 | Controllers | 890 | Controllers |
| 706 | =========== | 891 | =========== |
| @@ -29,7 +29,7 @@ from load_config import loadConfig · 28 unmodified lines | |||
| 29 | # -- General configuration ------------------------------------------------ | 29 | # -- General configuration ------------------------------------------------ |
| 30 | 30 | ||
| 31 | # If your documentation needs a minimal Sphinx version, state it here. | 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 | # Add any Sphinx extension module names here, as strings. They can be | 34 | # Add any Sphinx extension module names here, as strings. They can be |
| 35 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom | 35 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom |
| @@ -271,10 +271,29 @@ latex_elements = { · 235 unmodified lines | |||
| 271 | 271 | ||
| 272 | # Additional stuff for the LaTeX preamble. | 272 | # Additional stuff for the LaTeX preamble. |
| 273 | 'preamble': ''' | 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 | 280 | ''' |
| 277 | \\usepackage{lscape} | 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 | % Put notes in color and let them be inside a table | 298 | % Put notes in color and let them be inside a table |
| 280 | \\definecolor{NoteColor}{RGB}{204,255,255} | 299 | \\definecolor{NoteColor}{RGB}{204,255,255} |
| @@ -325,27 +344,26 @@ latex_elements = { · 44 unmodified lines | |||
| 325 | } | 344 | } |
| 326 | \\makeatother | 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 | # Grouping the document tree into LaTeX files. List of tuples | 368 | # Grouping the document tree into LaTeX files. List of tuples |
| 351 | # (source start file, target name, title, | 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 | genericirq | 20 | genericirq |
| 21 | flexible-arrays | 21 | flexible-arrays |
| 22 | librs | 22 | librs |
| 23 | genalloc | ||
| 23 | 24 | ||
| 24 | Interfaces for kernel debugging | 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 | .. kernel-doc:: include/linux/clk.h | 345 | .. kernel-doc:: include/linux/clk.h |
| 346 | :internal: | 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 | recommended. | 243 | recommended. |
| 244 | 244 | ||
| 245 | Some users depend on the strict execution ordering of ST wq. The | 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 | 246 | combination of ``@max_active`` of 1 and ``WQ_UNBOUND`` used to |
| 247 | achieve this behavior. Work items on such wq are always queued to the | 247 | achieve this behavior. Work items on such wq were always queued to the |
| 248 | unbound worker-pools and only one work item can be active at any given | 248 | unbound worker-pools and only one work item could be active at any given |
| 249 | time thus achieving the same ordering property as ST wq. | 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 | Example Execution Scenarios | 256 | Example Execution Scenarios |
| 253 | =========================== | 257 | =========================== |
| @@ -31,11 +31,13 @@ Setup · 30 unmodified lines | |||
| 31 | CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports | 31 | CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports |
| 32 | CONFIG_FRAME_POINTER, keep it enabled. | 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 | Alternatively, QEMU allows to boot the kernel directly using -kernel, | 36 | Alternatively, QEMU allows to boot the kernel directly using -kernel, |
| 36 | -append, -initrd command line switches. This is generally only useful if | 37 | -append, -initrd command line switches. This is generally only useful if |
| 37 | you do not depend on modules. See QEMU documentation for more details on | 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 | - Enable the gdb stub of QEMU/KVM, either | 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 | - ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot`` | 348 | - ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot`` |
| 349 | - Enter the debugger on reboot notify. | 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 | Using kdb | 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 | 1. Configure kgdboc at boot using kernel parameters:: | 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 | OR | 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 | Amlogic MesonX device tree bindings | 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 | Boards with the Amlogic Meson6 SoC shall have the following properties: | 16 | Boards with the Amlogic Meson6 SoC shall have the following properties: |
| 5 | Required root node property: | 17 | Required root node property: |
| 6 | compatible: "amlogic,meson6" | 18 | compatible: "amlogic,meson6" |
| @@ -61,3 +73,32 @@ Board compatible values (alphabetically, grouped by SoC): · 54 unmodified lines | |||
| 61 | - "amlogic,q201" (Meson gxm s912) | 73 | - "amlogic,q201" (Meson gxm s912) |
| 62 | - "kingnovel,r-box-pro" (Meson gxm S912) | 74 | - "kingnovel,r-box-pro" (Meson gxm S912) |
| 63 | - "nexbox,a1" (Meson gxm s912) | 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 | frame-number = <1> | 108 | frame-number = <1> |
| 109 | interrupts = <0 15 0x8>; | 109 | interrupts = <0 15 0x8>; |
| 110 | reg = <0xf0003000 0x1000>; | 110 | reg = <0xf0003000 0x1000>; |
| 111 | status = "disabled"; | ||
| 112 | }; | 111 | }; |
| 113 | }; | 112 | }; |
| @@ -42,6 +42,10 @@ Raspberry Pi Zero · 41 unmodified lines | |||
| 42 | Required root node properties: | 42 | Required root node properties: |
| 43 | compatible = "raspberrypi,model-zero", "brcm,bcm2835"; | 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 | Generic BCM2835 board | 49 | Generic BCM2835 board |
| 46 | Required root node properties: | 50 | Required root node properties: |
| 47 | compatible = "brcm,bcm2835"; | 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 | - Embedded Trace Macrocell (version 4.x): | 34 | - Embedded Trace Macrocell (version 4.x): |
| 35 | "arm,coresight-etm4x", "arm,primecell"; | 35 | "arm,coresight-etm4x", "arm,primecell"; |
| 36 | 36 | ||
| 37 | - Qualcomm Configurable Replicator (version 1.x): | 37 | - Coresight programmable Replicator : |
| 38 | "qcom,coresight-replicator1x", "arm,primecell"; | 38 | "arm,coresight-dynamic-replicator", "arm,primecell"; |
| 39 | 39 | ||
| 40 | - System Trace Macrocell: | 40 | - System Trace Macrocell: |
| 41 | "arm,coresight-stm", "arm,primecell"; [1] | 41 | "arm,coresight-stm", "arm,primecell"; [1] |
| @@ -200,6 +200,7 @@ described below. · 199 unmodified lines | |||
| 200 | "arm,realview-smp" | 200 | "arm,realview-smp" |
| 201 | "brcm,bcm11351-cpu-method" | 201 | "brcm,bcm11351-cpu-method" |
| 202 | "brcm,bcm23550" | 202 | "brcm,bcm23550" |
| 203 | "brcm,bcm2836-smp" | ||
| 203 | "brcm,bcm-nsp-smp" | 204 | "brcm,bcm-nsp-smp" |
| 204 | "brcm,brahma-b15" | 205 | "brcm,brahma-b15" |
| 205 | "marvell,armada-375-smp" | 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 | gpio-controller; | 183 | gpio-controller; |
| 184 | #gpio-cells = <2>; | 184 | #gpio-cells = <2>; |
| 185 | gpio-ranges = <&cpm_pinctrl 0 0 32>; | 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 | 3 | Boards with a MediaTek SoC shall have the following property: |
| 4 | following property: | ||
| 5 | 4 | ||
| 6 | Required root node property: | 5 | Required root node property: |
| 7 | 6 | ||
| 8 | compatible: Must contain one of | 7 | compatible: Must contain one of |
| 9 | "mediatek,mt2701" | 8 | "mediatek,mt2701" |
| 9 | "mediatek,mt2712" | ||
| 10 | "mediatek,mt6580" | 10 | "mediatek,mt6580" |
| 11 | "mediatek,mt6589" | 11 | "mediatek,mt6589" |
| 12 | "mediatek,mt6592" | 12 | "mediatek,mt6592" |
| @@ -14,7 +14,8 @@ compatible: Must contain one of · 1 unmodified line | |||
| 14 | "mediatek,mt6795" | 14 | "mediatek,mt6795" |
| 15 | "mediatek,mt6797" | 15 | "mediatek,mt6797" |
| 16 | "mediatek,mt7622" | 16 | "mediatek,mt7622" |
| 17 | "mediatek,mt7623" | 17 | "mediatek,mt7623" which is referred to MT7623N SoC |
| 18 | "mediatek,mt7623a" | ||
| 18 | "mediatek,mt8127" | 19 | "mediatek,mt8127" |
| 19 | "mediatek,mt8135" | 20 | "mediatek,mt8135" |
| 20 | "mediatek,mt8173" | 21 | "mediatek,mt8173" |
| @@ -25,6 +26,9 @@ Supported boards: · 4 unmodified lines | |||
| 25 | - Evaluation board for MT2701: | 26 | - Evaluation board for MT2701: |
| 26 | Required root node properties: | 27 | Required root node properties: |
| 27 | - compatible = "mediatek,mt2701-evb", "mediatek,mt2701"; | 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 | - Evaluation board for MT6580: | 32 | - Evaluation board for MT6580: |
| 29 | Required root node properties: | 33 | Required root node properties: |
| 30 | - compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580"; | 34 | - compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580"; |
| @@ -46,9 +50,11 @@ Supported boards: · 15 unmodified lines | |||
| 46 | - Reference board variant 1 for MT7622: | 50 | - Reference board variant 1 for MT7622: |
| 47 | Required root node properties: | 51 | Required root node properties: |
| 48 | - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622"; | 52 | - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622"; |
| 49 | - Evaluation board for MT7623: | 53 | - Reference board for MT7623n with NAND: |
| 50 | Required root node properties: | 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 | - MTK mt8127 tablet moose EVB: | 58 | - MTK mt8127 tablet moose EVB: |
| 53 | Required root node properties: | 59 | Required root node properties: |
| 54 | - compatible = "mediatek,mt8127-moose", "mediatek,mt8127"; | 60 | - compatible = "mediatek,mt8127-moose", "mediatek,mt8127"; |
| @@ -80,6 +80,9 @@ SoCs: · 79 unmodified lines | |||
| 80 | - OMAP5432 | 80 | - OMAP5432 |
| 81 | compatible = "ti,omap5432", "ti,omap5" | 81 | compatible = "ti,omap5432", "ti,omap5" |
| 82 | 82 | ||
| 83 | - DRA762 | ||
| 84 | compatible = "ti,dra762", "ti,dra7" | ||
| 85 | |||
| 83 | - DRA742 | 86 | - DRA742 |
| 84 | compatible = "ti,dra742", "ti,dra74", "ti,dra7" | 87 | compatible = "ti,dra742", "ti,dra74", "ti,dra7" |
| 85 | 88 | ||
| @@ -154,6 +157,9 @@ Boards: · 68 unmodified lines | |||
| 154 | - AM335X phyCORE-AM335x: Development kit | 157 | - AM335X phyCORE-AM335x: Development kit |
| 155 | compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx" | 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 | - OMAP5 EVM : Evaluation Module | 163 | - OMAP5 EVM : Evaluation Module |
| 158 | compatible = "ti,omap5-evm", "ti,omap5" | 164 | compatible = "ti,omap5-evm", "ti,omap5" |
| 159 | 165 | ||
| @@ -184,6 +190,9 @@ Boards: · 24 unmodified lines | |||
| 184 | - AM5718 IDK | 190 | - AM5718 IDK |
| 185 | compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7" | 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 | - DRA742 EVM: Software Development Board for DRA742 | 196 | - DRA742 EVM: Software Development Board for DRA742 |
| 188 | compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" | 197 | compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" |
| 189 | 198 | ||
| @@ -9,9 +9,11 @@ Required properties: · 8 unmodified lines | |||
| 9 | - compatible : should be one of | 9 | - compatible : should be one of |
| 10 | "apm,potenza-pmu" | 10 | "apm,potenza-pmu" |
| 11 | "arm,armv8-pmuv3" | 11 | "arm,armv8-pmuv3" |
| 12 | "arm,cortex-a73-pmu" | ||
| 12 | "arm,cortex-a72-pmu" | 13 | "arm,cortex-a72-pmu" |
| 13 | "arm,cortex-a57-pmu" | 14 | "arm,cortex-a57-pmu" |
| 14 | "arm,cortex-a53-pmu" | 15 | "arm,cortex-a53-pmu" |
| 16 | "arm,cortex-a35-pmu" | ||
| 15 | "arm,cortex-a17-pmu" | 17 | "arm,cortex-a17-pmu" |
| 16 | "arm,cortex-a15-pmu" | 18 | "arm,cortex-a15-pmu" |
| 17 | "arm,cortex-a12-pmu" | 19 | "arm,cortex-a12-pmu" |
| @@ -25,6 +25,7 @@ The 'SoC' element must be one of the following strings: · 24 unmodified lines | |||
| 25 | msm8994 | 25 | msm8994 |
| 26 | msm8996 | 26 | msm8996 |
| 27 | mdm9615 | 27 | mdm9615 |
| 28 | ipq8074 | ||
| 28 | 29 | ||
| 29 | The 'board' element must be one of the following strings: | 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 | dragonboard | 34 | dragonboard |
| 34 | mtp | 35 | mtp |
| 35 | sbc | 36 | sbc |
| 37 | hk01 | ||
| 36 | 38 | ||
| 37 | The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor> | 39 | The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor> |
| 38 | where the minor number may be omitted when it's zero, i.e. v1.0 is the same | 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 | Required root node properties: | 134 | Required root node properties: |
| 135 | - compatible = "phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288"; | 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 | - Rockchip PX3 Evaluation board: | 141 | - Rockchip PX3 Evaluation board: |
| 138 | Required root node properties: | 142 | Required root node properties: |
| 139 | - compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188"; | 143 | - compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188"; |
| @@ -173,6 +177,14 @@ Rockchip platforms device tree bindings · 33 unmodified lines | |||
| 173 | Required root node properties: | 177 | Required root node properties: |
| 174 | - compatible = "rockchip,rk3399-evb", "rockchip,rk3399"; | 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 | - Tronsmart Orion R68 Meta | 188 | - Tronsmart Orion R68 Meta |
| 177 | Required root node properties: | 189 | Required root node properties: |
| 178 | - compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368"; | 190 | - compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368"; |
| @@ -39,6 +39,8 @@ SoCs: · 38 unmodified lines | |||
| 39 | compatible = "renesas,r8a7795" | 39 | compatible = "renesas,r8a7795" |
| 40 | - R-Car M3-W (R8A77960) | 40 | - R-Car M3-W (R8A77960) |
| 41 | compatible = "renesas,r8a7796" | 41 | compatible = "renesas,r8a7796" |
| 42 | - R-Car D3 (R8A77995) | ||
| 43 | compatible = "renesas,r8a77995" | ||
| 42 | 44 | ||
| 43 | 45 | ||
| 44 | Boards: | 46 | Boards: |
| @@ -53,6 +55,8 @@ Boards: · 8 unmodified lines | |||
| 53 | compatible = "renesas,blanche", "renesas,r8a7792" | 55 | compatible = "renesas,blanche", "renesas,r8a7792" |
| 54 | - BOCK-W | 56 | - BOCK-W |
| 55 | compatible = "renesas,bockw", "renesas,r8a7778" | 57 | compatible = "renesas,bockw", "renesas,r8a7778" |
| 58 | - Draak (RTP0RC77995SEB0010S) | ||
| 59 | compatible = "renesas,draak", "renesas,r8a77995" | ||
| 56 | - Genmai (RTK772100BC00000BR) | 60 | - Genmai (RTK772100BC00000BR) |
| 57 | compatible = "renesas,genmai", "renesas,r7s72100" | 61 | compatible = "renesas,genmai", "renesas,r7s72100" |
| 58 | - GR-Peach (X28A-M01-E/F) | 62 | - GR-Peach (X28A-M01-E/F) |
| @@ -64,6 +68,10 @@ Boards: · 5 unmodified lines | |||
| 64 | compatible = "renesas,h3ulcb", "renesas,r8a7795"; | 68 | compatible = "renesas,h3ulcb", "renesas,r8a7795"; |
| 65 | - Henninger | 69 | - Henninger |
| 66 | compatible = "renesas,henninger", "renesas,r8a7791" | 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 | - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) | 75 | - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) |
| 68 | compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" | 76 | compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" |
| 69 | - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) | 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 | <0x0 0x1f227000 0x0 0x1000>; | 57 | <0x0 0x1f227000 0x0 0x1000>; |
| 58 | interrupts = <0x0 0x87 0x4>; | 58 | interrupts = <0x0 0x87 0x4>; |
| 59 | dma-coherent; | 59 | dma-coherent; |
| 60 | status = "ok"; | ||
| 61 | clocks = <&sataclk 0>; | 60 | clocks = <&sataclk 0>; |
| 62 | phys = <&phy2 0>; | 61 | phys = <&phy2 0>; |
| 63 | phy-names = "sata-phy"; | 62 | phy-names = "sata-phy"; |
| @@ -72,7 +71,6 @@ Example: · 8 unmodified lines | |||
| 72 | <0x0 0x1f237000 0x0 0x1000>; | 71 | <0x0 0x1f237000 0x0 0x1000>; |
| 73 | interrupts = <0x0 0x88 0x4>; | 72 | interrupts = <0x0 0x88 0x4>; |
| 74 | dma-coherent; | 73 | dma-coherent; |
| 75 | status = "ok"; | ||
| 76 | clocks = <&sataclk 0>; | 74 | clocks = <&sataclk 0>; |
| 77 | phys = <&phy3 0>; | 75 | phys = <&phy3 0>; |
| 78 | phy-names = "sata-phy"; | 76 | phy-names = "sata-phy"; |
| @@ -13,5 +13,4 @@ Example: · 12 unmodified lines | |||
| 13 | reg = <0x83fe0000 0x4000>; | 13 | reg = <0x83fe0000 0x4000>; |
| 14 | interrupts = <70>; | 14 | interrupts = <70>; |
| 15 | clocks = <&clks 161>; | 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 | devbus-bootcs { | 229 | devbus-bootcs { |
| 230 | status = "okay"; | ||
| 231 | ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>; | 230 | ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>; |
| 232 | 231 | ||
| 233 | /* NOR */ | 232 | /* NOR */ |
| @@ -240,7 +239,6 @@ See the example below, where a more complete device tree is shown: · 6 unmodified lines | |||
| 240 | 239 | ||
| 241 | pcie-controller { | 240 | pcie-controller { |
| 242 | compatible = "marvell,armada-xp-pcie"; | 241 | compatible = "marvell,armada-xp-pcie"; |
| 243 | status = "okay"; | ||
| 244 | device_type = "pci"; | 242 | device_type = "pci"; |
| 245 | 243 | ||
| 246 | #address-cells = <3>; | 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 | pcie@1,0 { | 257 | pcie@1,0 { |
| 260 | /* Port 0, Lane 0 */ | 258 | /* Port 0, Lane 0 */ |
| 261 | status = "okay"; | ||
| 262 | }; | 259 | }; |
| 263 | }; | 260 | }; |
| 264 | 261 | ||
| @@ -84,7 +84,6 @@ gmi@70090000 { · 83 unmodified lines | |||
| 84 | reset-names = "gmi"; | 84 | reset-names = "gmi"; |
| 85 | ranges = <4 0 0xd0000000 0xfffffff>; | 85 | ranges = <4 0 0xd0000000 0xfffffff>; |
| 86 | 86 | ||
| 87 | status = "okay"; | ||
| 88 | 87 | ||
| 89 | bus@4,0 { | 88 | bus@4,0 { |
| 90 | compatible = "simple-bus"; | 89 | compatible = "simple-bus"; |
| @@ -121,7 +120,6 @@ gmi@70090000 { · 30 unmodified lines | |||
| 121 | reset-names = "gmi"; | 120 | reset-names = "gmi"; |
| 122 | ranges = <4 0 0xd0000000 0xfffffff>; | 121 | ranges = <4 0 0xd0000000 0xfffffff>; |
| 123 | 122 | ||
| 124 | status = "okay"; | ||
| 125 | 123 | ||
| 126 | can@4,0 { | 124 | can@4,0 { |
| 127 | reg = <4 0 0x100>; | 125 | reg = <4 0 0x100>; |
| @@ -33,7 +33,6 @@ Example: · 32 unmodified lines | |||
| 33 | #size-cells = <1>; | 33 | #size-cells = <1>; |
| 34 | ranges = <0x702c0000 0x0 0x702c0000 0x00040000>; | 34 | ranges = <0x702c0000 0x0 0x702c0000 0x00040000>; |
| 35 | 35 | ||
| 36 | status = "disabled"; | ||
| 37 | 36 | ||
| 38 | child1 { | 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 | for passing data between firmware and the operating system, like boot | 5 | for passing data between firmware and the operating system, like boot |
| 6 | arguments. Data in the chosen node does not represent the hardware. | 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 | Device trees may specify the device to be used for boot console output | 34 | Device trees may specify the device to be used for boot console output |
| 13 | with a stdout-path property under /chosen, as described in the Devicetree | 35 | with a stdout-path property under /chosen, as described in the Devicetree |
| @@ -102,7 +102,6 @@ uart4: serial@80010000 { · 101 unmodified lines | |||
| 102 | reg = <0x80010000 0x4000>; | 102 | reg = <0x80010000 0x4000>; |
| 103 | clocks = <&acc CLKID_SYS_UART4>, <&acc CLKID_AHB_UART4>; | 103 | clocks = <&acc CLKID_SYS_UART4>, <&acc CLKID_AHB_UART4>; |
| 104 | interrupts = <19>; | 104 | interrupts = <19>; |
| 105 | status = "disabled"; | ||
| 106 | }; | 105 | }; |
| 107 | 106 | ||
| 108 | Clock consumer with only one, _AHB_ sink. | 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 | Required Properties: | 6 | Required Properties: |
| 7 | 7 | ||
| 8 | - compatible: should be "amlogic,gxbb-aoclkc" | 8 | - compatible: value should be different for each SoC family as : |
| 9 | - reg: physical base address of the clock controller and length of memory | 9 | - GXBB (S905) : "amlogic,meson-gxbb-aoclkc" |
| 10 | mapped region. | 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 | - #clock-cells: should be 1. | 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 | preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be | 25 | preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be |
| 24 | used in device tree sources. | 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 | Example: AO Clock controller node: | 32 | Example: AO Clock controller node: |
| 27 | 33 | ||
| 28 | clkc_AO: clock-controller@040 { | 34 | ao_sysctrl: sys-ctrl@0 { |
| 29 | compatible = "amlogic,gxbb-aoclkc"; | 35 | compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"; |
| 30 | reg = <0x0 0x040 0x0 0x4>; | 36 | reg = <0x0 0x0 0x0 0x100>; |
| 37 | |||
| 38 | clkc_AO: clock-controller { | ||
| 39 | compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc"; | ||
| 31 | #clock-cells = <1>; | 40 | #clock-cells = <1>; |
| 32 | #reset-cells = <1>; | 41 | #reset-cells = <1>; |
| 33 | }; | 42 | }; |
| 43 | }; | ||
| 34 | 44 | ||
| 35 | Example: UART controller node that consumes the clock and reset generated | 45 | Example: UART controller node that consumes the clock and reset generated |
| 36 | by the clock controller: | 46 | by the clock controller: |
| @@ -41,5 +51,4 @@ Example: UART controller node that consumes the clock and reset generated · 4 unmodified lines | |||
| 41 | interrupts = <0 90 1>; | 51 | interrupts = <0 90 1>; |
| 42 | clocks = <&clkc_AO CLKID_AO_UART1>; | 52 | clocks = <&clkc_AO CLKID_AO_UART1>; |
| 43 | resets = <&clkc_AO RESET_AO_UART1>; | 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 | reg = <0xc81004c0 0x14>; | 33 | reg = <0xc81004c0 0x14>; |
| 34 | interrupts = <0 90 1>; | 34 | interrupts = <0 90 1>; |
| 35 | clocks = <&clkc CLKID_CLK81>; | 35 | clocks = <&clkc CLKID_CLK81>; |
| 36 | status = "disabled"; | ||
| 37 | }; | 36 | }; |
| @@ -16,18 +16,25 @@ Required Properties: · 15 unmodified lines | |||
| 16 | mapped region. | 16 | mapped region. |
| 17 | 17 | ||
| 18 | - #clock-cells: should be 1. | 18 | - #clock-cells: should be 1. |
| 19 | - #reset-cells: should be 1. | ||
| 19 | 20 | ||
| 20 | Each clock is assigned an identifier and client nodes can use this identifier | 21 | Each clock is assigned an identifier and client nodes can use this identifier |
| 21 | to specify the clock which they consume. All available clocks are defined as | 22 | to specify the clock which they consume. All available clocks are defined as |
| 22 | preprocessor macros in the dt-bindings/clock/meson8b-clkc.h header and can be | 23 | preprocessor macros in the dt-bindings/clock/meson8b-clkc.h header and can be |
| 23 | used in device tree sources. | 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 | Example: Clock controller node: | 31 | Example: Clock controller node: |
| 26 | 32 | ||
| 27 | clkc: clock-controller@c1104000 { | 33 | clkc: clock-controller@c1104000 { |
| 28 | #clock-cells = <1>; | ||
| 29 | compatible = "amlogic,meson8b-clkc"; | 34 | compatible = "amlogic,meson8b-clkc"; |
| 30 | reg = <0xc1108000 0x4>, <0xc1104000 0x460>; | 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 | reg = <0xc81004c0 0x14>; | 46 | reg = <0xc81004c0 0x14>; |
| 40 | interrupts = <0 90 1>; | 47 | interrupts = <0 90 1>; |
| 41 | clocks = <&clkc CLKID_CLK81>; | 48 | clocks = <&clkc CLKID_CLK81>; |
| 42 | status = "disabled"; | ||
| 43 | }; | 49 | }; |
| @@ -81,6 +81,16 @@ Required properties: · 80 unmodified lines | |||
| 81 | "atmel,sama5d2-clk-generated": | 81 | "atmel,sama5d2-clk-generated": |
| 82 | at91 generated clock | 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 | Required properties for SCKC node: | 94 | Required properties for SCKC node: |
| 85 | - reg : defines the IO memory reserved for the SCKC. | 95 | - reg : defines the IO memory reserved for the SCKC. |
| 86 | - #size-cells : shall be 0 (reg is used to encode clk id). | 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 | uart@3e002000 { | 47 | uart@3e002000 { |
| 48 | compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; | 48 | compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; |
| 49 | status = "disabled"; | ||
| 50 | reg = <0x3e002000 0x1000>; | 49 | reg = <0x3e002000 0x1000>; |
| 51 | clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; | 50 | clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; |
| 52 | interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; | 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 | clock-names = "uart", "clk_uart_baud0"; | 465 | clock-names = "uart", "clk_uart_baud0"; |
| 466 | pinctrl-names = "default"; | 466 | pinctrl-names = "default"; |
| 467 | pinctrl-0 = <&uart0_bus>; | 467 | pinctrl-0 = <&uart0_bus>; |
| 468 | status = "disabled"; | ||
| 469 | }; | 468 | }; |
| @@ -38,5 +38,4 @@ Examples: · 37 unmodified lines | |||
| 38 | clocks = <&crg_ctrl HI3660_CLK_MUX_UART0>, | 38 | clocks = <&crg_ctrl HI3660_CLK_MUX_UART0>, |
| 39 | <&crg_ctrl HI3660_PCLK>; | 39 | <&crg_ctrl HI3660_PCLK>; |
| 40 | clock-names = "uartclk", "apb_pclk"; | 40 | clock-names = "uartclk", "apb_pclk"; |
| 41 | status = "disabled"; | ||
| 42 | }; | 41 | }; |
| @@ -27,5 +27,4 @@ Examples: · 26 unmodified lines | |||
| 27 | interrupts = <0 49 4>; | 27 | interrupts = <0 49 4>; |
| 28 | clocks = <&clock HIX5HD2_FIXED_83M>; | 28 | clocks = <&clock HIX5HD2_FIXED_83M>; |
| 29 | clock-names = "apb_pclk"; | 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 | 3 | The IDT VersaClock 5 and VersaClock 6 are programmable i2c clock |
| 4 | from 3 to 12 output clocks. | 4 | generators providing from 3 to 12 output clocks. |
| 5 | 5 | ||
| 6 | ==I2C device node== | 6 | ==I2C device node== |
| 7 | 7 | ||
| 8 | Required properties: | 8 | Required properties: |
| 9 | - compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933" , | 9 | - compatible: shall be one of |
| 10 | "idt,5p49v5935". | 10 | "idt,5p49v5923" |
| 11 | "idt,5p49v5925" | ||
| 12 | "idt,5p49v5933" | ||
| 13 | "idt,5p49v5935" | ||
| 14 | "idt,5p49v6901" | ||
| 11 | - reg: i2c device address, shall be 0x68 or 0x6a. | 15 | - reg: i2c device address, shall be 0x68 or 0x6a. |
| 12 | - #clock-cells: from common clock binding; shall be set to 1. | 16 | - #clock-cells: from common clock binding; shall be set to 1. |
| 13 | - clocks: from common clock binding; list of parent clock handles, | 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 | reference clock. | 21 | reference clock. |
| 16 | - 5p49v5933 and | 22 | - 5p49v5933 and |
| 17 | - 5p49v5935: (optional) property not present (internal | 23 | - 5p49v5935: (optional) property not present (internal |
| 18 | Xtal used) or CLKIN reference | 24 | Xtal used) or CLKIN reference |
| 19 | clock. | 25 | clock. |
| 20 | - clock-names: from common clock binding; clock input names, can be | 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 | - 5p49v5933 and | 30 | - 5p49v5933 and |
| 23 | - 5p49v5935: (optional) property not present or "clkin". | 31 | - 5p49v5935: (optional) property not present or "clkin". |
| 24 | 32 | ||
| @@ -37,6 +45,7 @@ clock specifier, the following mapping applies: · 12 unmodified lines | |||
| 37 | 1 -- OUT1 | 45 | 1 -- OUT1 |
| 38 | 2 -- OUT4 | 46 | 2 -- OUT4 |
| 39 | 47 | ||
| 48 | 5P49V5925 and | ||
| 40 | 5P49V5935: | 49 | 5P49V5935: |
| 41 | 0 -- OUT0_SEL_I2CB | 50 | 0 -- OUT0_SEL_I2CB |
| 42 | 1 -- OUT1 | 51 | 1 -- OUT1 |
| @@ -44,6 +53,13 @@ clock specifier, the following mapping applies: · 1 unmodified line | |||
| 44 | 3 -- OUT3 | 53 | 3 -- OUT3 |
| 45 | 4 -- OUT4 | 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 | ==Example== | 63 | ==Example== |
| 48 | 64 | ||
| 49 | /* 25MHz reference crystal */ | 65 | /* 25MHz reference crystal */ |
| @@ -24,5 +24,4 @@ Examples: · 23 unmodified lines | |||
| 24 | clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, | 24 | clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, |
| 25 | <&clks IMX21_CLK_PER1>; | 25 | <&clks IMX21_CLK_PER1>; |
| 26 | clock-names = "ipg", "per"; | 26 | clock-names = "ipg", "per"; |
| 27 | status = "disabled"; | ||
| 28 | }; | 27 | }; |
| @@ -67,5 +67,4 @@ auart0: serial@8006c000 { · 66 unmodified lines | |||
| 67 | reg = <0x8006c000 0x2000>; | 67 | reg = <0x8006c000 0x2000>; |
| 68 | interrupts = <24 25 23>; | 68 | interrupts = <24 25 23>; |
| 69 | clocks = <&clks 32>; | 69 | clocks = <&clks 32>; |
| 70 | status = "disabled"; | ||
| 71 | }; | 70 | }; |
| @@ -157,5 +157,4 @@ uart1: serial@43f90000 { · 156 unmodified lines | |||
| 157 | interrupts = <45>; | 157 | interrupts = <45>; |
| 158 | clocks = <&clks 79>, <&clks 50>; | 158 | clocks = <&clks 79>, <&clks 50>; |
| 159 | clock-names = "ipg", "per"; | 159 | clock-names = "ipg", "per"; |
| 160 | status = "disabled"; | ||
| 161 | }; | 160 | }; |
| @@ -24,5 +24,4 @@ Examples: · 23 unmodified lines | |||
| 24 | clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, | 24 | clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, |
| 25 | <&clks IMX27_CLK_PER1_GATE>; | 25 | <&clks IMX27_CLK_PER1_GATE>; |
| 26 | clock-names = "ipg", "per"; | 26 | clock-names = "ipg", "per"; |
| 27 | status = "disabled"; | ||
| 28 | }; | 27 | }; |
| @@ -90,5 +90,4 @@ auart0: serial@8006a000 { · 89 unmodified lines | |||
| 90 | reg = <0x8006a000 0x2000>; | 90 | reg = <0x8006a000 0x2000>; |
| 91 | interrupts = <112 70 71>; | 91 | interrupts = <112 70 71>; |
| 92 | clocks = <&clks 45>; | 92 | clocks = <&clks 45>; |
| 93 | status = "disabled"; | ||
| 94 | }; | 93 | }; |
| @@ -87,5 +87,4 @@ uart1: serial@43f90000 { · 86 unmodified lines | |||
| 87 | interrupts = <45>; | 87 | interrupts = <45>; |
| 88 | clocks = <&clks 10>, <&clks 30>; | 88 | clocks = <&clks 10>, <&clks 30>; |
| 89 | clock-names = "ipg", "per"; | 89 | clock-names = "ipg", "per"; |
| 90 | status = "disabled"; | ||
| 91 | }; | 90 | }; |
| @@ -25,5 +25,4 @@ can1: can@53fc8000 { · 24 unmodified lines | |||
| 25 | interrupts = <82>; | 25 | interrupts = <82>; |
| 26 | clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>; | 26 | clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>; |
| 27 | clock-names = "ipg", "per"; | 27 | clock-names = "ipg", "per"; |
| 28 | status = "disabled"; | ||
| 29 | }; | 28 | }; |
| @@ -27,5 +27,4 @@ uart1: serial@02020000 { · 26 unmodified lines | |||
| 27 | interrupts = <0 26 0x04>; | 27 | interrupts = <0 26 0x04>; |
| 28 | clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>; | 28 | clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>; |
| 29 | clock-names = "ipg", "per"; | 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 | #clock-cells = <0>; | 66 | #clock-cells = <0>; |
| 67 | clock-output-names = "dfllCPU_out"; | 67 | clock-output-names = "dfllCPU_out"; |
| 68 | vdd-cpu-supply = <&vdd_cpu>; | 68 | vdd-cpu-supply = <&vdd_cpu>; |
| 69 | status = "okay"; | ||
| 70 | 69 | ||
| 71 | nvidia,sample-rate = <12500>; | 70 | nvidia,sample-rate = <12500>; |
| 72 | nvidia,droop-ctrl = <0x00000f00>; | 71 | nvidia,droop-ctrl = <0x00000f00>; |
| @@ -12,5 +12,4 @@ Examples: · 11 unmodified lines | |||
| 12 | pxa2xx_clks: pxa2xx_clks@41300004 { | 12 | pxa2xx_clks: pxa2xx_clks@41300004 { |
| 13 | compatible = "marvell,pxa-clocks"; | 13 | compatible = "marvell,pxa-clocks"; |
| 14 | #clock-cells = <1>; | 14 | #clock-cells = <1>; |
| 15 | status = "okay"; | ||
| 16 | }; | 15 | }; |
| @@ -22,6 +22,7 @@ Required Properties: · 21 unmodified lines | |||
| 22 | - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2) | 22 | - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2) |
| 23 | - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3) | 23 | - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3) |
| 24 | - "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W) | 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 | - reg: Base address and length of the memory resource used by the CPG/MSSR | 27 | - reg: Base address and length of the memory resource used by the CPG/MSSR |
| 27 | block | 28 | block |
| @@ -30,7 +31,7 @@ Required Properties: · 2 unmodified lines | |||
| 30 | clock-names | 31 | clock-names |
| 31 | - clock-names: List of external parent clock names. Valid names are: | 32 | - clock-names: List of external parent clock names. Valid names are: |
| 32 | - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794, | 33 | - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794, |
| 33 | r8a7795, r8a7796) | 34 | r8a7795, r8a7796, r8a77995) |
| 34 | - "extalr" (r8a7795, r8a7796) | 35 | - "extalr" (r8a7795, r8a7796) |
| 35 | - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794) | 36 | - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794) |
| 36 | 37 | ||
| @@ -81,5 +82,4 @@ Examples · 44 unmodified lines | |||
| 81 | dma-names = "tx", "rx"; | 82 | dma-names = "tx", "rx"; |
| 82 | power-domains = <&cpg>; | 83 | power-domains = <&cpg>; |
| 83 | resets = <&cpg 310>; | 84 | resets = <&cpg 310>; |
| 84 | status = "disabled"; | ||
| 85 | }; | 85 | }; |
| @@ -44,5 +44,4 @@ Examples · 43 unmodified lines | |||
| 44 | interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>; | 44 | interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>; |
| 45 | clocks = <&mstp3_clks R8A7778_CLK_SDHI0>; | 45 | clocks = <&mstp3_clks R8A7778_CLK_SDHI0>; |
| 46 | power-domains = <&cpg_clocks>; | 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 | clocks = <&mstp3_clks R7S72100_CLK_MTU2>; | 50 | clocks = <&mstp3_clks R7S72100_CLK_MTU2>; |
| 51 | clock-names = "fck"; | 51 | clock-names = "fck"; |
| 52 | power-domains = <&cpg_clocks>; | 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 | controllers within the SoC and also implements a reset controller for SoC | 4 | controllers within the SoC and also implements a reset controller for SoC |
| 5 | peripherals. | 5 | peripherals. |
| 6 | 6 | ||
| 7 | Required Properties: | 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 | - reg: physical base address of the controller and length of memory mapped | 12 | - reg: physical base address of the controller and length of memory mapped |
| 11 | region. | 13 | region. |
| 12 | - #clock-cells: should be 1. | 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 | interrupts = <1 23 3 4>, <1 23 4 4>; | 46 | interrupts = <1 23 3 4>, <1 23 4 4>; |
| 47 | clock-names = "uart", "clk_uart_baud2"; | 47 | clock-names = "uart", "clk_uart_baud2"; |
| 48 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>; | 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 | clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3"; | 46 | clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3"; |
| 47 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, | 47 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, |
| 48 | <&clocks SCLK_UART>; | 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 | "clk_uart_baud3"; | 52 | "clk_uart_baud3"; |
| 53 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, | 53 | clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, |
| 54 | <&clocks SCLK_UART>; | 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 | "clk_uart_baud3"; | 73 | "clk_uart_baud3"; |
| 74 | clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>, | 74 | clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>, |
| 75 | <&clock SCLK_UART>; | 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 | "clk_uart_baud1"; | 74 | "clk_uart_baud1"; |
| 75 | clocks = <&clocks UART0>, <&clocks UART0>, | 75 | clocks = <&clocks UART0>, <&clocks UART0>, |
| 76 | <&clocks SCLK_UART0>; | 76 | <&clocks SCLK_UART0>; |
| 77 | status = "disabled"; | ||
| 78 | }; | 77 | }; |
| @@ -12,7 +12,11 @@ generators can be found in [1]. · 11 unmodified lines | |||
| 12 | ==I2C device node== | 12 | ==I2C device node== |
| 13 | 13 | ||
| 14 | Required properties: | 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 | - reg: i2c device address, shall be 0x60 or 0x61. | 20 | - reg: i2c device address, shall be 0x60 or 0x61. |
| 17 | - #clock-cells: from common clock binding; shall be set to 1. | 21 | - #clock-cells: from common clock binding; shall be set to 1. |
| 18 | - clocks: from common clock binding; list of parent clock | 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 | Required properties : | 4 | Required properties : |
| 5 | - compatible: must contain one of the following compatibles: | 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 | - "allwinner,sun6i-a31-ccu" | 9 | - "allwinner,sun6i-a31-ccu" |
| 10 | - "allwinner,sun7i-a20-ccu" | ||
| 7 | - "allwinner,sun8i-a23-ccu" | 11 | - "allwinner,sun8i-a23-ccu" |
| 8 | - "allwinner,sun8i-a33-ccu" | 12 | - "allwinner,sun8i-a33-ccu" |
| 9 | - "allwinner,sun8i-a83t-ccu" | 13 | - "allwinner,sun8i-a83t-ccu" |
| 10 | - "allwinner,sun8i-a83t-r-ccu" | 14 | - "allwinner,sun8i-a83t-r-ccu" |
| 11 | - "allwinner,sun8i-h3-ccu" | 15 | - "allwinner,sun8i-h3-ccu" |
| 12 | - "allwinner,sun8i-h3-r-ccu" | 16 | - "allwinner,sun8i-h3-r-ccu" |
| 17 | + - "allwinner,sun8i-r40-ccu" | ||
| 13 | - "allwinner,sun8i-v3s-ccu" | 18 | - "allwinner,sun8i-v3s-ccu" |
| 14 | - "allwinner,sun9i-a80-ccu" | 19 | - "allwinner,sun9i-a80-ccu" |
| 15 | - "allwinner,sun50i-a64-ccu" | 20 | - "allwinner,sun50i-a64-ccu" |
| 16 | - "allwinner,sun50i-a64-r-ccu" | 21 | - "allwinner,sun50i-a64-r-ccu" |
| 17 | - "allwinner,sun50i-h5-ccu" | 22 | - "allwinner,sun50i-h5-ccu" |
| 23 | - "nextthing,gr8-ccu" | ||
| 18 | 24 | ||
| 19 | - reg: Must contain the registers base address and length | 25 | - reg: Must contain the registers base address and length |
| 20 | - clocks: phandle to the oscillators feeding the CCU. Two are needed: | 26 | - clocks: phandle to the oscillators feeding the CCU. Two are needed: |
| @@ -14,10 +14,9 @@ Required properties: · 13 unmodified lines | |||
| 14 | - compatible: Must be "ti,k2g-sci-clk" | 14 | - compatible: Must be "ti,k2g-sci-clk" |
| 15 | - #clock-cells: Shall be 2. | 15 | - #clock-cells: Shall be 2. |
| 16 | In clock consumers, this cell represents the device ID and clock ID | 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 | 17 | exposed by the PM firmware. The list of valid values for the device IDs |
| 18 | files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and | 18 | and clocks IDs for 66AK2G SoC are documented at |
| 19 | <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc> | 19 | http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data |
| 20 | is the SoC involved, for example 'k2g'. | ||
| 21 | 20 | ||
| 22 | Examples: | 21 | Examples: |
| 23 | -------- | 22 | -------- |
| @@ -81,13 +81,11 @@ atl: atl@4843c000 { · 80 unmodified lines | |||
| 81 | <&atl_clkin2_ck>, <&atl_clkin3_ck>; | 81 | <&atl_clkin2_ck>, <&atl_clkin3_ck>; |
| 82 | clocks = <&atl_gfclk_mux>; | 82 | clocks = <&atl_gfclk_mux>; |
| 83 | clock-names = "fck"; | 83 | clock-names = "fck"; |
| 84 | status = "disabled"; | ||
| 85 | }; | 84 | }; |
| 86 | 85 | ||
| 87 | #include <dt-bindings/clk/ti-dra7-atl.h> | 86 | #include <dt-bindings/clk/ti-dra7-atl.h> |
| 88 | 87 | ||
| 89 | &atl { | 88 | &atl { |
| 90 | status = "okay"; | ||
| 91 | 89 | ||
| 92 | atl2 { | 90 | atl2 { |
| 93 | bws = <DRA7_ATL_WS_MCASP2_FSX>; | 91 | bws = <DRA7_ATL_WS_MCASP2_FSX>; |
| @@ -6,7 +6,6 @@ System clock · 5 unmodified lines | |||
| 6 | 6 | ||
| 7 | Required properties: | 7 | Required properties: |
| 8 | - compatible: should be one of the following: | 8 | - compatible: should be one of the following: |
| 9 | "socionext,uniphier-sld3-clock" - for sLD3 SoC. | ||
| 10 | "socionext,uniphier-ld4-clock" - for LD4 SoC. | 9 | "socionext,uniphier-ld4-clock" - for LD4 SoC. |
| 11 | "socionext,uniphier-pro4-clock" - for Pro4 SoC. | 10 | "socionext,uniphier-pro4-clock" - for Pro4 SoC. |
| 12 | "socionext,uniphier-sld8-clock" - for sLD8 SoC. | 11 | "socionext,uniphier-sld8-clock" - for sLD8 SoC. |
| @@ -14,6 +13,7 @@ Required properties: · 1 unmodified line | |||
| 14 | "socionext,uniphier-pxs2-clock" - for PXs2/LD6b SoC. | 13 | "socionext,uniphier-pxs2-clock" - for PXs2/LD6b SoC. |
| 15 | "socionext,uniphier-ld11-clock" - for LD11 SoC. | 14 | "socionext,uniphier-ld11-clock" - for LD11 SoC. |
| 16 | "socionext,uniphier-ld20-clock" - for LD20 SoC. | 15 | "socionext,uniphier-ld20-clock" - for LD20 SoC. |
| 16 | "socionext,uniphier-pxs3-clock" - for PXs3 SoC | ||
| 17 | - #clock-cells: should be 1. | 17 | - #clock-cells: should be 1. |
| 18 | 18 | ||
| 19 | Example: | 19 | Example: |
| @@ -48,7 +48,6 @@ Media I/O (MIO) clock, SD clock · 28 unmodified lines | |||
| 48 | 48 | ||
| 49 | Required properties: | 49 | Required properties: |
| 50 | - compatible: should be one of the following: | 50 | - compatible: should be one of the following: |
| 51 | "socionext,uniphier-sld3-mio-clock" - for sLD3 SoC. | ||
| 52 | "socionext,uniphier-ld4-mio-clock" - for LD4 SoC. | 51 | "socionext,uniphier-ld4-mio-clock" - for LD4 SoC. |
| 53 | "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC. | 52 | "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC. |
| 54 | "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC. | 53 | "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC. |
| @@ -56,6 +55,7 @@ Required properties: · 1 unmodified line | |||
| 56 | "socionext,uniphier-pxs2-sd-clock" - for PXs2/LD6b SoC. | 55 | "socionext,uniphier-pxs2-sd-clock" - for PXs2/LD6b SoC. |
| 57 | "socionext,uniphier-ld11-mio-clock" - for LD11 SoC. | 56 | "socionext,uniphier-ld11-mio-clock" - for LD11 SoC. |
| 58 | "socionext,uniphier-ld20-sd-clock" - for LD20 SoC. | 57 | "socionext,uniphier-ld20-sd-clock" - for LD20 SoC. |
| 58 | "socionext,uniphier-pxs3-sd-clock" - for PXs3 SoC | ||
| 59 | - #clock-cells: should be 1. | 59 | - #clock-cells: should be 1. |
| 60 | 60 | ||
| 61 | Example: | 61 | Example: |
| @@ -82,11 +82,9 @@ Provided clocks: · 20 unmodified lines | |||
| 82 | 8: USB2 ch0 host | 82 | 8: USB2 ch0 host |
| 83 | 9: USB2 ch1 host | 83 | 9: USB2 ch1 host |
| 84 | 10: USB2 ch2 host | 84 | 10: USB2 ch2 host |
| 85 | 11: USB2 ch3 host | ||
| 86 | 12: USB2 ch0 PHY | 85 | 12: USB2 ch0 PHY |
| 87 | 13: USB2 ch1 PHY | 86 | 13: USB2 ch1 PHY |
| 88 | 14: USB2 ch2 PHY | 87 | 14: USB2 ch2 PHY |
| 89 | 15: USB2 ch3 PHY | ||
| 90 | 88 | ||
| 91 | 89 | ||
| 92 | Peripheral clock | 90 | Peripheral clock |
| @@ -94,7 +92,6 @@ Peripheral clock · 1 unmodified line | |||
| 94 | 92 | ||
| 95 | Required properties: | 93 | Required properties: |
| 96 | - compatible: should be one of the following: | 94 | - compatible: should be one of the following: |
| 97 | "socionext,uniphier-sld3-peri-clock" - for sLD3 SoC. | ||
| 98 | "socionext,uniphier-ld4-peri-clock" - for LD4 SoC. | 95 | "socionext,uniphier-ld4-peri-clock" - for LD4 SoC. |
| 99 | "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC. | 96 | "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC. |
| 100 | "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC. | 97 | "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC. |
| @@ -102,6 +99,7 @@ Required properties: · 1 unmodified line | |||
| 102 | "socionext,uniphier-pxs2-peri-clock" - for PXs2/LD6b SoC. | 99 | "socionext,uniphier-pxs2-peri-clock" - for PXs2/LD6b SoC. |
| 103 | "socionext,uniphier-ld11-peri-clock" - for LD11 SoC. | 100 | "socionext,uniphier-ld11-peri-clock" - for LD11 SoC. |
| 104 | "socionext,uniphier-ld20-peri-clock" - for LD20 SoC. | 101 | "socionext,uniphier-ld20-peri-clock" - for LD20 SoC. |
| 102 | "socionext,uniphier-pxs3-peri-clock" - for PXs3 SoC | ||
| 105 | - #clock-cells: should be 1. | 103 | - #clock-cells: should be 1. |
| 106 | 104 | ||
| 107 | Example: | 105 | Example: |
| @@ -31,5 +31,4 @@ uart0: serial@0x09405000 { · 30 unmodified lines | |||
| 31 | reg = <0x09405000 0x1000>; | 31 | reg = <0x09405000 0x1000>; |
| 32 | interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; | 32 | interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; |
| 33 | clocks = <&lsp1clk ZX296702_UART0_PCLK>; | 33 | clocks = <&lsp1clk ZX296702_UART0_PCLK>; |
| 34 | status = "disabled"; | ||
| 35 | }; | 34 | }; |
| @@ -34,5 +34,4 @@ usbphy0:usb-phy0 { · 33 unmodified lines | |||
| 34 | #phy-cells = <0>; | 34 | #phy-cells = <0>; |
| 35 | clocks = <&topclk USB20_PHY_CLK>; | 35 | clocks = <&topclk USB20_PHY_CLK>; |
| 36 | clock-names = "phyclk"; | 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 | dmas = <&dma1 2 17>; | 66 | dmas = <&dma1 2 17>; |
| 67 | dma-names = "tx"; | 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 | compatible = "fsl,imx28-dcp", "fsl,imx23-dcp"; | 13 | compatible = "fsl,imx28-dcp", "fsl,imx23-dcp"; |
| 14 | reg = <0x80028000 0x2000>; | 14 | reg = <0x80028000 0x2000>; |
| 15 | interrupts = <52 53>; | 15 | interrupts = <52 53>; |
| 16 | status = "okay"; | ||
| 17 | }; | 16 | }; |
| @@ -23,5 +23,4 @@ Example: · 22 unmodified lines | |||
| 23 | interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", | 23 | interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", |
| 24 | "eip"; | 24 | "eip"; |
| 25 | clocks = <&cpm_syscon0 1 26>; | 25 | clocks = <&cpm_syscon0 1 26>; |
| 26 | status = "disabled"; | ||
| 27 | }; | 26 | }; |
| @@ -41,5 +41,4 @@ Examples: · 40 unmodified lines | |||
| 41 | clock-names = "cesa0", "cesa1"; | 41 | clock-names = "cesa0", "cesa1"; |
| 42 | marvell,crypto-srams = <&crypto_sram0>, <&crypto_sram1>; | 42 | marvell,crypto-srams = <&crypto_sram0>, <&crypto_sram1>; |
| 43 | marvell,crypto-sram-size = <0x600>; | 43 | marvell,crypto-sram-size = <0x600>; |
| 44 | status = "okay"; | ||
| 45 | }; | 44 | }; |
| @@ -29,5 +29,4 @@ Examples: · 28 unmodified lines | |||
| 29 | interrupts = <22>; | 29 | interrupts = <22>; |
| 30 | marvell,crypto-srams = <&crypto_sram>; | 30 | marvell,crypto-srams = <&crypto_sram>; |
| 31 | marvell,crypto-sram-size = <0x600>; | 31 | marvell,crypto-sram-size = <0x600>; |
| 32 | status = "okay"; | ||
| 33 | }; | 32 | }; |
| @@ -25,5 +25,4 @@ Examples: · 24 unmodified lines | |||
| 25 | clock-names = "aclk", "hclk", "sclk", "apb_pclk"; | 25 | clock-names = "aclk", "hclk", "sclk", "apb_pclk"; |
| 26 | resets = <&cru SRST_CRYPTO>; | 26 | resets = <&cru SRST_CRYPTO>; |
| 27 | reset-names = "crypto-rst"; | 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 | rockchip,pmu = <&pmugrf>; | 15 | rockchip,pmu = <&pmugrf>; |
| 16 | clocks = <&cru PCLK_DDR_MON>; | 16 | clocks = <&cru PCLK_DDR_MON>; |
| 17 | clock-names = "pclk_ddr_mon"; | 17 | clock-names = "pclk_ddr_mon"; |
| 18 | status = "disabled"; | ||
| 19 | }; | 18 | }; |
| @@ -205,5 +205,4 @@ Example: · 204 unmodified lines | |||
| 205 | rockchip,phy_lpddr4_ck_cs_drv = <PHY_DRV_ODT_80>; | 205 | rockchip,phy_lpddr4_ck_cs_drv = <PHY_DRV_ODT_80>; |
| 206 | rockchip,phy_lpddr4_dq_drv = <PHY_DRV_ODT_80>; | 206 | rockchip,phy_lpddr4_dq_drv = <PHY_DRV_ODT_80>; |
| 207 | rockchip,phy_lpddr4_odt = <PHY_DRV_ODT_60>; | 207 | rockchip,phy_lpddr4_odt = <PHY_DRV_ODT_60>; |
| 208 | status = "disabled"; | ||
| 209 | }; | 208 | }; |
| @@ -34,7 +34,6 @@ Example: · 33 unmodified lines | |||
| 34 | pinctrl-names = "default"; | 34 | pinctrl-names = "default"; |
| 35 | pinctrl-0 = <&pinctrl_fb>; | 35 | pinctrl-0 = <&pinctrl_fb>; |
| 36 | display = <&display0>; | 36 | display = <&display0>; |
| 37 | status = "okay"; | ||
| 38 | #address-cells = <1>; | 37 | #address-cells = <1>; |
| 39 | #size-cells = <1>; | 38 | #size-cells = <1>; |
| 40 | 39 | ||
| @@ -23,7 +23,6 @@ Example: · 22 unmodified lines | |||
| 23 | interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; | 23 | interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; |
| 24 | clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; | 24 | clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; |
| 25 | clock-names = "periph_clk","sys_clk", "slow_clk"; | 25 | clock-names = "periph_clk","sys_clk", "slow_clk"; |
| 26 | status = "disabled"; | ||
| 27 | 26 | ||
| 28 | hlcdc-display-controller { | 27 | hlcdc-display-controller { |
| 29 | compatible = "atmel,hlcdc-display-controller"; | 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 | Example: | 33 | Example: |
| 34 | 34 | ||
| 35 | &mux2_i2c2 { | 35 | &mux2_i2c2 { |
| 36 | status = "okay"; | ||
| 37 | clock-frequency = <100000>; | 36 | clock-frequency = <100000>; |
| 38 | 37 | ||
| 39 | stdp4028@73 { | 38 | stdp4028@73 { |
| @@ -13,6 +13,7 @@ Required properties: · 12 unmodified lines | |||
| 13 | 13 | ||
| 14 | - compatible : Shall contain one or more of | 14 | - compatible : Shall contain one or more of |
| 15 | - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX | 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 | - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX | 17 | - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX |
| 17 | 18 | ||
| 18 | When compatible with generic versions, nodes must list the SoC-specific | 19 | When compatible with generic versions, nodes must list the SoC-specific |
| @@ -43,7 +44,6 @@ Example: · 24 unmodified lines | |||
| 43 | clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>; | 44 | clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>; |
| 44 | clock-names = "iahb", "isfr"; | 45 | clock-names = "iahb", "isfr"; |
| 45 | power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; | 46 | power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; |
| 46 | status = "disabled"; | ||
| 47 | 47 | ||
| 48 | ports { | 48 | ports { |
| 49 | #address-cells = <1>; | 49 | #address-cells = <1>; |
| @@ -25,12 +25,6 @@ Required properties: · 24 unmodified lines | |||
| 25 | size-cells must 1 and 0, respectively. | 25 | size-cells must 1 and 0, respectively. |
| 26 | - port: contains an endpoint node which is connected to the endpoint in the mic | 26 | - port: contains an endpoint node which is connected to the endpoint in the mic |
| 27 | node. The reg value muset be 0. | 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 | Example: | 29 | Example: |
| 36 | SoC specific DT entry: | 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 | reg = <0x4003d000 0x1000>; | 14 | reg = <0x4003d000 0x1000>; |
| 15 | clocks = <&clks VF610_CLK_TCON0>; | 15 | clocks = <&clks VF610_CLK_TCON0>; |
| 16 | clock-names = "ipg"; | 16 | clock-names = "ipg"; |
| 17 | status = "okay"; | ||
| 18 | }; | 17 | }; |
| @@ -116,7 +116,7 @@ Parallel display support · 115 unmodified lines | |||
| 116 | Required properties: | 116 | Required properties: |
| 117 | - compatible: Should be "fsl,imx-parallel-display" | 117 | - compatible: Should be "fsl,imx-parallel-display" |
| 118 | Optional properties: | 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 | display interface. Currently supported types: "rgb24", "rgb565", "bgr666" | 120 | display interface. Currently supported types: "rgb24", "rgb565", "bgr666" |
| 121 | and "lvds666". | 121 | and "lvds666". |
| 122 | - edid: verbatim EDID data block describing attached display. | 122 | - edid: verbatim EDID data block describing attached display. |
| @@ -23,7 +23,6 @@ Example: · 22 unmodified lines | |||
| 23 | reg = <0x44000000 0x10000>; | 23 | reg = <0x44000000 0x10000>; |
| 24 | interrupts = <17>; | 24 | interrupts = <17>; |
| 25 | clocks = <&clks CLK_LCD>; | 25 | clocks = <&clks CLK_LCD>; |
| 26 | status = "okay"; | ||
| 27 | 26 | ||
| 28 | port { | 27 | port { |
| 29 | lcdc_out: endpoint { | 28 | lcdc_out: endpoint { |
| @@ -18,6 +18,5 @@ Example: · 17 unmodified lines | |||
| 18 | power-supply = <...>; | 18 | power-supply = <...>; |
| 19 | backlight = <&backlight>; | 19 | backlight = <&backlight>; |
| 20 | enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; | 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 | When supplied they must be named "dclkin.x" with "x" being the input | 36 | When supplied they must be named "dclkin.x" with "x" being the input |
| 37 | clock numerical index. | 37 | clock numerical index. |
| 38 | 38 | ||
| 39 | - vsps: A list of phandles to the VSP nodes that handle the memory | 39 | - vsps: A list of phandle and channel index tuples to the VSPs that handle |
| 40 | interfaces for the DU channels. | 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 | Required nodes: | 44 | Required nodes: |
| 43 | 45 | ||
| @@ -59,24 +61,24 @@ corresponding to each DU output. · 15 unmodified lines | |||
| 59 | R8A7796 (M3-W) DPAD HDMI LVDS - | 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 { | 66 | du: display@feb00000 { |
| 65 | compatible = "renesas,du-r8a7790"; | 67 | compatible = "renesas,du-r8a7795"; |
| 66 | reg = <0 0xfeb00000 0 0x70000>, | 68 | reg = <0 0xfeb00000 0 0x80000>, |
| 67 | <0 0xfeb90000 0 0x1c>, | 69 | <0 0xfeb90000 0 0x14>; |
| 68 | <0 0xfeb94000 0 0x1c>; | 70 | reg-names = "du", "lvds.0"; |
| 69 | reg-names = "du", "lvds.0", "lvds.1"; | 71 | interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, |
| 70 | interrupt-parent = <&gic>; | 72 | <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>, |
| 71 | interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>, | 73 | <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>, |
| 72 | <0 268 IRQ_TYPE_LEVEL_HIGH>, | 74 | <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>; |
| 73 | <0 269 IRQ_TYPE_LEVEL_HIGH>; | 75 | clocks = <&cpg CPG_MOD 724>, |
| 74 | clocks = <&mstp7_clks R8A7790_CLK_DU0>, | 76 | <&cpg CPG_MOD 723>, |
| 75 | <&mstp7_clks R8A7790_CLK_DU1>, | 77 | <&cpg CPG_MOD 722>, |
| 76 | <&mstp7_clks R8A7790_CLK_DU2>, | 78 | <&cpg CPG_MOD 721>, |
| 77 | <&mstp7_clks R8A7790_CLK_LVDS0>, | 79 | <&cpg CPG_MOD 727>; |
| 78 | <&mstp7_clks R8A7790_CLK_LVDS1>; | 80 | clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; |
| 79 | clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1"; | 81 | vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>; |
| 80 | 82 | ||
| 81 | ports { | 83 | ports { |
| 82 | #address-cells = <1>; | 84 | #address-cells = <1>; |
| @@ -89,12 +91,19 @@ Example: R8A7790 (R-Car H2) DU · 6 unmodified lines | |||
| 89 | }; | 91 | }; |
| 90 | port@1 { | 92 | port@1 { |
| 91 | reg = <1>; | 93 | reg = <1>; |
| 92 | du_out_lvds0: endpoint { | 94 | du_out_hdmi0: endpoint { |
| 95 | remote-endpoint = <&dw_hdmi0_in>; | ||
| 93 | }; | 96 | }; |
| 94 | }; | 97 | }; |
| 95 | port@2 { | 98 | port@2 { |
| 96 | reg = <2>; | 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 | pinctrl-names = "default"; | 59 | pinctrl-names = "default"; |
| 60 | pinctrl-0 = <&edp_hpd>; | 60 | pinctrl-0 = <&edp_hpd>; |
| 61 | 61 | ||
| 62 | status = "disabled"; | ||
| 63 | 62 | ||
| 64 | ports { | 63 | ports { |
| 65 | #address-cells = <1>; | 64 | #address-cells = <1>; |
| @@ -11,7 +11,9 @@ following device-specific properties. · 10 unmodified lines | |||
| 11 | 11 | ||
| 12 | Required properties: | 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 | - reg: See dw_hdmi.txt. | 17 | - reg: See dw_hdmi.txt. |
| 16 | - reg-io-width: See dw_hdmi.txt. Shall be 4. | 18 | - reg-io-width: See dw_hdmi.txt. Shall be 4. |
| 17 | - interrupts: HDMI interrupt number | 19 | - interrupts: HDMI interrupt number |
| @@ -30,7 +32,8 @@ Optional properties · 12 unmodified lines | |||
| 30 | I2C master controller. | 32 | I2C master controller. |
| 31 | - clock-names: See dw_hdmi.txt. The "cec" clock is optional. | 33 | - clock-names: See dw_hdmi.txt. The "cec" clock is optional. |
| 32 | - clock-names: May contain "cec" as defined in dw_hdmi.txt. | 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 | Example: | 38 | Example: |
| 36 | 39 | ||
| @@ -43,7 +46,6 @@ hdmi: hdmi@ff980000 { · 6 unmodified lines | |||
| 43 | interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; | 46 | interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; |
| 44 | clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>; | 47 | clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>; |
| 45 | clock-names = "iahb", "isfr"; | 48 | clock-names = "iahb", "isfr"; |
| 46 | status = "disabled"; | ||
| 47 | ports { | 49 | ports { |
| 48 | hdmi_in: port { | 50 | hdmi_in: port { |
| 49 | #address-cells = <1>; | 51 | #address-cells = <1>; |
| @@ -36,7 +36,6 @@ Example: · 35 unmodified lines | |||
| 36 | resets = <&cru SRST_MIPIDSI0>; | 36 | resets = <&cru SRST_MIPIDSI0>; |
| 37 | reset-names = "apb"; | 37 | reset-names = "apb"; |
| 38 | rockchip,grf = <&grf>; | 38 | rockchip,grf = <&grf>; |
| 39 | status = "okay"; | ||
| 40 | 39 | ||
| 41 | ports { | 40 | ports { |
| 42 | #address-cells = <1>; | 41 | #address-cells = <1>; |
| @@ -65,6 +64,5 @@ Example: · 22 unmodified lines | |||
| 65 | pinctrl-names = "default"; | 64 | pinctrl-names = "default"; |
| 66 | pinctrl-0 = <&lcd_en>; | 65 | pinctrl-0 = <&lcd_en>; |
| 67 | backlight = <&backlight>; | 66 | backlight = <&backlight>; |
| 68 | status = "okay"; | ||
| 69 | }; | 67 | }; |
| 70 | }; | 68 | }; |
| @@ -25,7 +25,6 @@ hdmi: hdmi@20034000 { · 24 unmodified lines | |||
| 25 | clock-names = "pclk"; | 25 | clock-names = "pclk"; |
| 26 | pinctrl-names = "default"; | 26 | pinctrl-names = "default"; |
| 27 | pinctrl-0 = <&hdmi_ctl>; | 27 | pinctrl-0 = <&hdmi_ctl>; |
| 28 | status = "disabled"; | ||
| 29 | 28 | ||
| 30 | hdmi_in: port { | 29 | hdmi_in: port { |
| 31 | #address-cells = <1>; | 30 | #address-cells = <1>; |
| @@ -8,8 +8,12 @@ Required properties: · 7 unmodified lines | |||
| 8 | - compatible: value should be one of the following | 8 | - compatible: value should be one of the following |
| 9 | "rockchip,rk3036-vop"; | 9 | "rockchip,rk3036-vop"; |
| 10 | "rockchip,rk3288-vop"; | 10 | "rockchip,rk3288-vop"; |
| 11 | "rockchip,rk3368-vop"; | ||
| 12 | "rockchip,rk3366-vop"; | ||
| 11 | "rockchip,rk3399-vop-big"; | 13 | "rockchip,rk3399-vop-big"; |
| 12 | "rockchip,rk3399-vop-lit"; | 14 | "rockchip,rk3399-vop-lit"; |
| 15 | "rockchip,rk3228-vop"; | ||
| 16 | "rockchip,rk3328-vop"; | ||
| 13 | 17 | ||
| 14 | - interrupts: should contain a list of all VOP IP block interrupts in the | 18 | - interrupts: should contain a list of all VOP IP block interrupts in the |
| 15 | order: VSYNC, LCD_SYSTEM. The interrupt specifier | 19 | order: VSYNC, LCD_SYSTEM. The interrupt specifier |
| @@ -28,6 +28,5 @@ chosen { · 27 unmodified lines | |||
| 28 | allwinner,pipeline = "de_be0-lcd0-hdmi"; | 28 | allwinner,pipeline = "de_be0-lcd0-hdmi"; |
| 29 | clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>, | 29 | clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>, |
| 30 | <&ahb_gates 44>; | 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 | * STMicroelectronics STM32 lcd-tft display controller | 1 | * STMicroelectronics STM32 lcd-tft display controller |
| 2 | 2 | ||
| 3 | - ltdc: lcd-tft display controller host | 3 | - ltdc: lcd-tft display controller host |
| 4 | must be a sub-node of st-display-subsystem | ||
| 5 | Required properties: | 4 | Required properties: |
| 6 | - compatible: "st,stm32-ltdc" | 5 | - compatible: "st,stm32-ltdc" |
| 7 | - reg: Physical base address of the IP registers and length of memory mapped region. | 6 | - reg: Physical base address of the IP registers and length of memory mapped region. |
| @@ -13,8 +12,40 @@ · 5 unmodified lines | |||
| 13 | Required nodes: | 12 | Required nodes: |
| 14 | - Video port for RGB output. | 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 | soc { | 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 | The Allwinner A10 Display pipeline is composed of several components | 4 | The Allwinner A10 Display pipeline is composed of several components |
| 5 | that are going to be documented below: | 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 | 7 | For all connections between components up to the TCONs in the display |
| 8 | pipeline, if there are multiple components, the local endpoint IDs | 8 | pipeline, when there are multiple components of the same type at the |
| 9 | must correspond to the index of the upstream block. For example, if | 9 | same depth, the local endpoint ID must be the same as the remote |
| 10 | the remote endpoint is Frontend 1, then the local endpoint ID must | 10 | component's index. For example, if the remote endpoint is Frontend 1, |
| 11 | be 1. | 11 | then the local endpoint ID must be 1. |
| 12 | 12 | ||
| 13 | Conversely, for the output ports of the same group, the remote endpoint | 13 | Frontend 0 [0] ------- [0] Backend 0 [0] ------- [0] TCON 0 |
| 14 | ID must be the index of the local hardware block. If the local backend | 14 | [1] -- -- [1] [1] -- -- [1] |
| 15 | is backend 1, then the remote endpoint ID must be 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 | HDMI Encoder | 35 | HDMI Encoder |
| 18 | ------------ | 36 | ------------ |
| @@ -260,7 +278,6 @@ hdmi: hdmi@01c16000 { · 241 unmodified lines | |||
| 260 | <&dma SUN4I_DMA_NORMAL 16>, | 278 | <&dma SUN4I_DMA_NORMAL 16>, |
| 261 | <&dma SUN4I_DMA_DEDICATED 24>; | 279 | <&dma SUN4I_DMA_DEDICATED 24>; |
| 262 | dma-names = "ddc-tx", "ddc-rx", "audio-tx"; | 280 | dma-names = "ddc-tx", "ddc-rx", "audio-tx"; |
| 263 | status = "disabled"; | ||
| 264 | 281 | ||
| 265 | ports { | 282 | ports { |
| 266 | #address-cells = <1>; | 283 | #address-cells = <1>; |
| @@ -72,5 +72,4 @@ sai2: sai@40031000 { · 71 unmodified lines | |||
| 72 | dma-names = "tx", "rx"; | 72 | dma-names = "tx", "rx"; |
| 73 | dmas = <&edma0 0 21>, | 73 | dmas = <&edma0 0 21>, |
| 74 | <&edma0 0 20>; | 74 | <&edma0 0 20>; |
| 75 | status = "disabled"; | ||
| 76 | }; | 75 | }; |
| @@ -30,7 +30,6 @@ xor@d0060900 { · 29 unmodified lines | |||
| 30 | reg = <0xd0060900 0x100 | 30 | reg = <0xd0060900 0x100 |
| 31 | 0xd0060b00 0x100>; | 31 | 0xd0060b00 0x100>; |
| 32 | clocks = <&coreclk 0>; | 32 | clocks = <&coreclk 0>; |
| 33 | status = "okay"; | ||
| 34 | 33 | ||
| 35 | xor00 { | 34 | xor00 { |
| 36 | interrupts = <51>; | 35 | interrupts = <51>; |
| @@ -48,7 +48,6 @@ Each dmas request consists of 3 cells: · 47 unmodified lines | |||
| 48 | Example: | 48 | Example: |
| 49 | 49 | ||
| 50 | spi4: spi@1a280000 { | 50 | spi4: spi@1a280000 { |
| 51 | status = "ok"; | ||
| 52 | spi-max-frequency = <50000000>; | 51 | spi-max-frequency = <50000000>; |
| 53 | 52 | ||
| 54 | pinctrl-0 = <&spi_pins>; | 53 | pinctrl-0 = <&spi_pins>; |
| @@ -25,6 +25,7 @@ Required Properties: · 24 unmodified lines | |||
| 25 | - "renesas,dmac-r8a7794" (R-Car E2) | 25 | - "renesas,dmac-r8a7794" (R-Car E2) |
| 26 | - "renesas,dmac-r8a7795" (R-Car H3) | 26 | - "renesas,dmac-r8a7795" (R-Car H3) |
| 27 | - "renesas,dmac-r8a7796" (R-Car M3-W) | 27 | - "renesas,dmac-r8a7796" (R-Car M3-W) |
| 28 | - "renesas,dmac-r8a77970" (R-Car V3M) | ||
| 28 | 29 | ||
| 29 | - reg: base address and length of the registers block for the DMAC | 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 | - "renesas,r8a7793-usb-dmac" (R-Car M2-N) | 8 | - "renesas,r8a7793-usb-dmac" (R-Car M2-N) |
| 9 | - "renesas,r8a7794-usb-dmac" (R-Car E2) | 9 | - "renesas,r8a7794-usb-dmac" (R-Car E2) |
| 10 | - "renesas,r8a7795-usb-dmac" (R-Car H3) | 10 | - "renesas,r8a7795-usb-dmac" (R-Car H3) |
| 11 | - "renesas,r8a7796-usb-dmac" (R-Car M3-W) | ||
| 11 | - reg: base address and length of the registers block for the DMAC | 12 | - reg: base address and length of the registers block for the DMAC |
| 12 | - interrupts: interrupt specifiers for the DMAC, one for each entry in | 13 | - interrupts: interrupt specifiers for the DMAC, one for each entry in |
| 13 | interrupt-names. | 14 | interrupt-names. |
| @@ -63,7 +63,6 @@ Example: · 62 unmodified lines | |||
| 63 | compatible = "arm,pl011", "arm,primecell"; | 63 | compatible = "arm,pl011", "arm,primecell"; |
| 64 | reg = <0xe0000000 0x1000>; | 64 | reg = <0xe0000000 0x1000>; |
| 65 | interrupts = <0 35 0x4>; | 65 | interrupts = <0 35 0x4>; |
| 66 | status = "disabled"; | ||
| 67 | dmas = <&dmahost 12 0 1>, | 66 | dmas = <&dmahost 12 0 1>, |
| 68 | <&dmahost 13 0 1 0>; | 67 | <&dmahost 13 0 1 0>; |
| 69 | dma-names = "rx", "rx"; | 68 | dma-names = "rx", "rx"; |
| @@ -69,7 +69,6 @@ Example: · 68 unmodified lines | |||
| 69 | 69 | ||
| 70 | sti_uni_player2: sti-uni-player@2 { | 70 | sti_uni_player2: sti-uni-player@2 { |
| 71 | compatible = "st,sti-uni-player"; | 71 | compatible = "st,sti-uni-player"; |
| 72 | status = "disabled"; | ||
| 73 | #sound-dai-cells = <0>; | 72 | #sound-dai-cells = <0>; |
| 74 | st,syscfg = <&syscfg_core>; | 73 | st,syscfg = <&syscfg_core>; |
| 75 | clocks = <&clk_s_d0_flexgen CLK_PCM_2>; | 74 | clocks = <&clk_s_d0_flexgen CLK_PCM_2>; |
| @@ -135,5 +135,4 @@ Example: · 134 unmodified lines | |||
| 135 | <&dma 13 0 0x0>; /* Logical - MemToDev */ | 135 | <&dma 13 0 0x0>; /* Logical - MemToDev */ |
| 136 | dma-names = "rx", "rx"; | 136 | dma-names = "rx", "rx"; |
| 137 | 137 | ||
| 138 | status = "disabled"; | ||
| 139 | }; | 138 | }; |
| @@ -40,7 +40,6 @@ Example: · 39 unmodified lines | |||
| 40 | clock-names = "ahb", "mod"; | 40 | clock-names = "ahb", "mod"; |
| 41 | dmas = <&dma 1 29>, <&dma 1 28>; | 41 | dmas = <&dma 1 29>, <&dma 1 28>; |
| 42 | dma-names = "rx", "tx"; | 42 | dma-names = "rx", "tx"; |
| 43 | status = "disabled"; | ||
| 44 | #address-cells = <1>; | 43 | #address-cells = <1>; |
| 45 | #size-cells = <0>; | 44 | #size-cells = <0>; |
| 46 | }; | 45 | }; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | |||
| 9 | "allwinner,sun8i-a23-dma" | 9 | "allwinner,sun8i-a23-dma" |
| 10 | "allwinner,sun8i-a83t-dma" | 10 | "allwinner,sun8i-a83t-dma" |
| 11 | "allwinner,sun8i-h3-dma" | 11 | "allwinner,sun8i-h3-dma" |
| 12 | "allwinner,sun8i-v3s-dma" | ||
| 12 | - reg: Should contain the registers base address and length | 13 | - reg: Should contain the registers base address and length |
| 13 | - interrupts: Should contain a reference to the interrupt used by this device | 14 | - interrupts: Should contain a reference to the interrupt used by this device |
| 14 | - clocks: Should contain a reference to the parent AHB clock | 15 | - clocks: Should contain a reference to the parent AHB clock |
| @@ -62,7 +62,6 @@ uart1: serial@4806a000 { · 61 unmodified lines | |||
| 62 | interrupts-extended = <&gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; | 62 | interrupts-extended = <&gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; |
| 63 | ti,hwmods = "uart1"; | 63 | ti,hwmods = "uart1"; |
| 64 | clock-frequency = <48000000>; | 64 | clock-frequency = <48000000>; |
| 65 | status = "disabled"; | ||
| 66 | /* Requesting crossbar input 49 and 50 */ | 65 | /* Requesting crossbar input 49 and 50 */ |
| 67 | dmas = <&sdma_xbar 49>, <&sdma_xbar 50>; | 66 | dmas = <&sdma_xbar 49>, <&sdma_xbar 50>; |
| 68 | dma-names = "tx", "rx"; | 67 | dma-names = "tx", "rx"; |
| @@ -9,7 +9,12 @@ execute the actual DMA tansfer. · 8 unmodified lines | |||
| 9 | eDMA3 Channel Controller | 9 | eDMA3 Channel Controller |
| 10 | 10 | ||
| 11 | Required properties: | 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 | - #dma-cells: Should be set to <2>. The first number is the DMA request | 18 | - #dma-cells: Should be set to <2>. The first number is the DMA request |
| 14 | number and the second is the TC the channel is serviced on. | 19 | number and the second is the TC the channel is serviced on. |
| 15 | - reg: Memory map of eDMA CC | 20 | - reg: Memory map of eDMA CC |
| @@ -19,8 +24,19 @@ Required properties: · 3 unmodified lines | |||
| 19 | - ti,tptcs: List of TPTCs associated with the eDMA in the following form: | 24 | - ti,tptcs: List of TPTCs associated with the eDMA in the following form: |
| 20 | <&tptc_phandle TC_priority_number>. The highest priority is 0. | 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 | Optional properties: | 38 | Optional properties: |
| 23 | - ti,hwmods: Name of the hwmods associated to the eDMA CC | 39 | ------------------- |
| 24 | - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow | 40 | - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow |
| 25 | these channels will be SW triggered channels. See example. | 41 | these channels will be SW triggered channels. See example. |
| 26 | - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by | 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 | eDMA3 Transfer Controller | 47 | eDMA3 Transfer Controller |
| 32 | 48 | ||
| 33 | Required properties: | 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 | - reg: Memory map of eDMA TC | 56 | - reg: Memory map of eDMA TC |
| 36 | - interrupts: Interrupt number for TCerrint. | 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 | Optional properties: | 70 | Optional properties: |
| 39 | - ti,hwmods: Name of the hwmods associated to the given eDMA TC | 71 | ------------------- |
| 40 | - interrupt-names: "edma3_tcerrint" | 72 | - interrupt-names: "edma3_tcerrint" |
| 41 | 73 | ||
| 42 | ------------------------------------------------------------------------------ | 74 | ------------------------------------------------------------------------------ |
| 43 | Example: | 75 | Examples: |
| 44 | 76 | ||
| 77 | 1. | ||
| 45 | edma: edma@49000000 { | 78 | edma: edma@49000000 { |
| 46 | compatible = "ti,edma3-tpcc"; | 79 | compatible = "ti,edma3-tpcc"; |
| 47 | ti,hwmods = "tpcc"; | 80 | ti,hwmods = "tpcc"; |
| @@ -102,13 +135,64 @@ mcasp0: mcasp@48038000 { · 54 unmodified lines | |||
| 102 | reg-names = "mpu", "dat"; | 135 | reg-names = "mpu", "dat"; |
| 103 | interrupts = <80>, <81>; | 136 | interrupts = <80>, <81>; |
| 104 | interrupt-names = "tx", "rx"; | 137 | interrupt-names = "tx", "rx"; |
| 105 | status = "disabled"; | ||
| 106 | /* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */ | 138 | /* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */ |
| 107 | dmas = <&edma 8 2>, | 139 | dmas = <&edma 8 2>, |
| 108 | <&edma 9 2>; | 140 | <&edma 9 2>; |
| 109 | dma-names = "tx", "rx"; | 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 | DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc | 197 | DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc |
| 114 | binding. | 198 | binding. |
| @@ -16,8 +16,12 @@ Required properties: · 15 unmodified lines | |||
| 16 | 16 | ||
| 17 | "renesas,r1ex24002" | 17 | "renesas,r1ex24002" |
| 18 | 18 | ||
| 19 | The following manufacturers values have been deprecated: | ||
| 20 | "at", "at24" | ||
| 21 | |||
| 19 | If there is no specific driver for <manufacturer>, a generic | 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 | "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64", | 25 | "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64", |
| 22 | "24c128", "24c256", "24c512", "24c1024", "spd" | 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 | cell-index = <1>; | 31 | cell-index = <1>; |
| 32 | interrupts = <92>; | 32 | interrupts = <92>; |
| 33 | clocks = <&coreclk 0>; | 33 | clocks = <&coreclk 0>; |
| 34 | status = "okay"; | ||
| 35 | 34 | ||
| 36 | fpga_mgr_spi: fpga-mgr@0 { | 35 | fpga_mgr_spi: fpga-mgr@0 { |
| 37 | compatible = "xlnx,fpga-slave-serial"; | 36 | compatible = "xlnx,fpga-slave-serial"; |
| @@ -12,6 +12,9 @@ Required properties: · 11 unmodified lines | |||
| 12 | 1 = active low | 12 | 1 = active low |
| 13 | - registers-number: Number of daisy-chained shift registers | 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 | Example: | 18 | Example: |
| 16 | 19 | ||
| 17 | gpio5: gpio5@0 { | 20 | gpio5: gpio5@0 { |
| @@ -18,7 +18,7 @@ Required properties: · 17 unmodified lines | |||
| 18 | Optional properties: | 18 | Optional properties: |
| 19 | 19 | ||
| 20 | - interrupt-parent : The parent interrupt controller, optional if inherited | 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 | The gpio and interrupt properties are further described in their respective | 23 | The gpio and interrupt properties are further described in their respective |
| 24 | bindings documentation: | 24 | bindings documentation: |
| @@ -1,7 +1,10 @@ | |||
| 1 | Davinci/Keystone GPIO controller bindings | 1 | Davinci/Keystone GPIO controller bindings |
| 2 | 2 | ||
| 3 | Required Properties: | 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 | - reg: Physical base address of the controller and the size of memory mapped | 9 | - reg: Physical base address of the controller and the size of memory mapped |
| 7 | registers. | 10 | registers. |
| @@ -20,7 +23,21 @@ Required Properties: · 12 unmodified lines | |||
| 20 | - ti,ngpio: The number of GPIO pins supported. | 23 | - ti,ngpio: The number of GPIO pins supported. |
| 21 | 24 | ||
| 22 | - ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt | 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 | The GPIO controller also acts as an interrupt controller. It uses the default | 42 | The GPIO controller also acts as an interrupt controller. It uses the default |
| 26 | two cells specifier as described in Documentation/devicetree/bindings/ | 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 | #gpio-cells = <2>; | 23 | #gpio-cells = <2>; |
| 24 | reg = <0x1100 0x080>; | 24 | reg = <0x1100 0x080>; |
| 25 | interrupts = <78 0x8>; | 25 | interrupts = <78 0x8>; |
| 26 | status = "okay"; | ||
| 27 | }; | 26 | }; |
| 28 | 27 | ||
| 29 | Example of gpio-controller node for a ls2080a SoC: | 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 | each, and each PORT module has its own interrupt. | 5 | each, and each PORT module has its own interrupt. |
| 6 | 6 | ||
| 7 | Required properties for GPIO node: | 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 | - reg : The first reg tuple represents the PORT module, the second tuple | 11 | - reg : The first reg tuple represents the PORT module, the second tuple |
| 10 | the GPIO module. | 12 | the GPIO module. |
| 11 | - interrupts : Should be the port interrupt shared by all 32 pins. | 13 | - interrupts : Should be the port interrupt shared by all 32 pins. |
| @@ -2,8 +2,9 @@ · 1 unmodified line | |||
| 2 | 2 | ||
| 3 | Required Properties: | 3 | Required Properties: |
| 4 | 4 | ||
| 5 | - compatible: should contain one of the following. | 5 | - compatible: should contain one or more of the following: |
| 6 | - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller. | 6 | - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller. |
| 7 | - "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO controller. | ||
| 7 | - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller. | 8 | - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller. |
| 8 | - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. | 9 | - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. |
| 9 | - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. | 10 | - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. |
| @@ -13,7 +14,14 @@ Required Properties: · 3 unmodified lines | |||
| 13 | - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller. | 14 | - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller. |
| 14 | - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. | 15 | - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. |
| 15 | - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO controller. | 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 | - reg: Base address and length of each memory resource used by the GPIO | 26 | - reg: Base address and length of each memory resource used by the GPIO |
| 19 | controller hardware module. | 27 | controller hardware module. |
| @@ -43,7 +51,7 @@ interrupt-controller/interrupts.txt. · 23 unmodified lines | |||
| 43 | Example: R8A7779 (R-Car H1) GPIO controller nodes | 51 | Example: R8A7779 (R-Car H1) GPIO controller nodes |
| 44 | 52 | ||
| 45 | gpio0: gpio@ffc40000 { | 53 | gpio0: gpio@ffc40000 { |
| 46 | compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar"; | 54 | compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio"; |
| 47 | reg = <0xffc40000 0x2c>; | 55 | reg = <0xffc40000 0x2c>; |
| 48 | interrupt-parent = <&gic>; | 56 | interrupt-parent = <&gic>; |
| 49 | interrupts = <0 141 0x4>; | 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 | gpio6: gpio@ffc46000 { | 65 | gpio6: gpio@ffc46000 { |
| 58 | compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar"; | 66 | compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio"; |
| 59 | reg = <0xffc46000 0x2c>; | 67 | reg = <0xffc46000 0x2c>; |
| 60 | interrupt-parent = <&gic>; | 68 | interrupt-parent = <&gic>; |
| 61 | interrupts = <0 147 0x4>; | 69 | interrupts = <0 147 0x4>; |
| @@ -42,7 +42,6 @@ spics: spics@e0700000{ · 41 unmodified lines | |||
| 42 | 42 | ||
| 43 | 43 | ||
| 44 | spi0: spi@e0100000 { | 44 | spi0: spi@e0100000 { |
| 45 | status = "okay"; | ||
| 46 | num-cs = <3>; | 45 | num-cs = <3>; |
| 47 | cs-gpios = <&gpio1 7 0>, <&spics 0>, | 46 | cs-gpios = <&gpio1 7 0>, <&spics 0>, |
| 48 | <&spics 1>; | 47 | <&spics 1>; |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | |||
| 17 | * which must be preceded by one of the following vendor specifics: | 17 | * which must be preceded by one of the following vendor specifics: |
| 18 | + "amlogic,meson-gxm-mali" | 18 | + "amlogic,meson-gxm-mali" |
| 19 | + "rockchip,rk3288-mali" | 19 | + "rockchip,rk3288-mali" |
| 20 | + "rockchip,rk3399-mali" | ||
| 20 | 21 | ||
| 21 | - reg : Physical base address of the device and length of the register area. | 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 | * And, optionally, one of the vendor specific compatible: | 10 | * And, optionally, one of the vendor specific compatible: |
| 11 | + allwinner,sun4i-a10-mali | 11 | + allwinner,sun4i-a10-mali |
| 12 | + allwinner,sun7i-a20-mali | 12 | + allwinner,sun7i-a20-mali |
| 13 | + allwinner,sun50i-h5-mali | ||
| 13 | + amlogic,meson-gxbb-mali | 14 | + amlogic,meson-gxbb-mali |
| 14 | + amlogic,meson-gxl-mali | 15 | + amlogic,meson-gxl-mali |
| 15 | + stericsson,db8500-mali | 16 | + stericsson,db8500-mali |
| @@ -58,6 +59,10 @@ to specify one more vendor-specific compatible, among: · 42 unmodified lines | |||
| 58 | Required properties: | 59 | Required properties: |
| 59 | * resets: phandle to the reset line for the GPU | 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 | - stericsson,db8500-mali | 66 | - stericsson,db8500-mali |
| 62 | Required properties: | 67 | Required properties: |
| 63 | * interrupt-names and interrupts: | 68 | * interrupt-names and interrupts: |
| @@ -51,7 +51,6 @@ Example for GK20A: · 50 unmodified lines | |||
| 51 | resets = <&tegra_car 184>; | 51 | resets = <&tegra_car 184>; |
| 52 | reset-names = "gpu"; | 52 | reset-names = "gpu"; |
| 53 | iommus = <&mc TEGRA_SWGROUP_GPU>; | 53 | iommus = <&mc TEGRA_SWGROUP_GPU>; |
| 54 | status = "disabled"; | ||
| 55 | }; | 54 | }; |
| 56 | 55 | ||
| 57 | Example for GM20B: | 56 | Example for GM20B: |
| @@ -70,7 +69,6 @@ Example for GM20B: · 12 unmodified lines | |||
| 70 | resets = <&tegra_car 184>; | 69 | resets = <&tegra_car 184>; |
| 71 | reset-names = "gpu"; | 70 | reset-names = "gpu"; |
| 72 | iommus = <&mc TEGRA_SWGROUP_GPU>; | 71 | iommus = <&mc TEGRA_SWGROUP_GPU>; |
| 73 | status = "disabled"; | ||
| 74 | }; | 72 | }; |
| 75 | 73 | ||
| 76 | Example for GP10B: | 74 | Example for GP10B: |
| @@ -89,5 +87,4 @@ Example for GP10B: · 12 unmodified lines | |||
| 89 | reset-names = "gpu"; | 87 | reset-names = "gpu"; |
| 90 | power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>; | 88 | power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>; |
| 91 | iommus = <&smmu TEGRA186_SID_GPU>; | 89 | iommus = <&smmu TEGRA186_SID_GPU>; |
| 92 | status = "disabled"; | ||
| 93 | }; | 90 | }; |
| @@ -24,5 +24,4 @@ Example: · 23 unmodified lines | |||
| 24 | interrupts = <0 89 0>; | 24 | interrupts = <0 89 0>; |
| 25 | clocks = <&clock 177>, <&clock 277>; | 25 | clocks = <&clock 177>, <&clock 277>; |
| 26 | clock-names = "sclk_fimg2d", "fimg2d"; | 26 | clock-names = "sclk_fimg2d", "fimg2d"; |
| 27 | status = "disabled"; | ||
| 28 | }; | 27 | }; |
| @@ -92,6 +92,5 @@ ssi-controller@48058000 { · 91 unmodified lines | |||
| 92 | interrupts = <69>, | 92 | interrupts = <69>, |
| 93 | <70>; | 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 | - #size-cells : should be 1. | 12 | - #size-cells : should be 1. |
| 13 | 13 | ||
| 14 | - #cooling-cells: should be 2. | ||
| 15 | |||
| 14 | - reg : address and length of the register set for the device. | 16 | - reg : address and length of the register set for the device. |
| 15 | 17 | ||
| 16 | - pinctrl-names : a pinctrl state named "default" must be defined. | 18 | - pinctrl-names : a pinctrl state named "default" must be defined. |
| @@ -28,12 +30,17 @@ fan subnode format: · 11 unmodified lines | |||
| 28 | Under fan subnode there can upto 8 child nodes, with each child node | 30 | Under fan subnode there can upto 8 child nodes, with each child node |
| 29 | representing a fan. If there are 8 fans each fan can have one PWM port and | 31 | representing a fan. If there are 8 fans each fan can have one PWM port and |
| 30 | one/two Fan tach inputs. | 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 | Required properties for each child node: | 36 | Required properties for each child node: |
| 33 | - reg : should specify PWM source port. | 37 | - reg : should specify PWM source port. |
| 34 | integer value in the range 0 to 7 with 0 indicating PWM port A and | 38 | integer value in the range 0 to 7 with 0 indicating PWM port A and |
| 35 | 7 indicating PWM port H. | 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 | - aspeed,fan-tach-ch : should specify the Fan tach input channel. | 44 | - aspeed,fan-tach-ch : should specify the Fan tach input channel. |
| 38 | integer value in the range 0 through 15, with 0 indicating | 45 | integer value in the range 0 through 15, with 0 indicating |
| 39 | Fan tach channel 0 and 15 indicating Fan tach channel 15. | 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 | pwm_tacho: pwmtachocontroller@1e786000 { | 57 | pwm_tacho: pwmtachocontroller@1e786000 { |
| 51 | #address-cells = <1>; | 58 | #address-cells = <1>; |
| 52 | #size-cells = <1>; | 59 | #size-cells = <1>; |
| 60 | #cooling-cells = <2>; | ||
| 53 | reg = <0x1E786000 0x1000>; | 61 | reg = <0x1E786000 0x1000>; |
| 54 | compatible = "aspeed,ast2500-pwm-tacho"; | 62 | compatible = "aspeed,ast2500-pwm-tacho"; |
| 55 | clocks = <&pwm_tacho_fixed_clk>; | 63 | clocks = <&pwm_tacho_fixed_clk>; |
| @@ -58,6 +66,7 @@ pwm_tacho: pwmtachocontroller@1e786000 { · 2 unmodified lines | |||
| 58 | 66 | ||
| 59 | fan@0 { | 67 | fan@0 { |
| 60 | reg = <0x00>; | 68 | reg = <0x00>; |
| 69 | cooling-levels = /bits/ 8 <125 151 177 203 229 255>; | ||
| 61 | aspeed,fan-tach-ch = /bits/ 8 <0x00>; | 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 | #address-cells = <1>; | 20 | #address-cells = <1>; |
| 21 | #size-cells = <0>; | 21 | #size-cells = <0>; |
| 22 | 22 | ||
| 23 | retu-mfd: retu@1 { | 23 | retu: retu@1 { |
| 24 | compatible = "retu-mfd"; | 24 | compatible = "nokia,retu"; |
| 25 | reg = <0x1>; | 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 | #address-cells = <1>; | 102 | #address-cells = <1>; |
| 103 | #size-cells = <0>; | 103 | #size-cells = <0>; |
| 104 | compatible = "i2c-gpio"; | 104 | compatible = "i2c-gpio"; |
| 105 | status = "disabled"; | ||
| 106 | gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */ | 105 | gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */ |
| 107 | &gpio5 5 GPIO_ACTIVE_HIGH /* scl */ | 106 | &gpio5 5 GPIO_ACTIVE_HIGH /* scl */ |
| 108 | >; | 107 | >; |
| @@ -22,7 +22,6 @@ Example: · 21 unmodified lines | |||
| 22 | interrupts = <9>; | 22 | interrupts = <9>; |
| 23 | clocks = <&cmu clk_HFPERCLKI2C0>; | 23 | clocks = <&cmu clk_HFPERCLKI2C0>; |
| 24 | clock-frequency = <100000>; | 24 | clock-frequency = <100000>; |
| 25 | status = "ok"; | ||
| 26 | energymicro,location = <3>; | 25 | energymicro,location = <3>; |
| 27 | 26 | ||
| 28 | eeprom@50 { | 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 | Required properties: | 5 | Required properties: |
| 6 | - compatible: value should be either of the following. | 6 | - compatible: value should be either of the following. |
| 7 | "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for Mediatek mt2701 | 7 | "mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701 |
| 8 | "mediatek,mt6577-i2c": for i2c compatible with mt6577. | 8 | "mediatek,mt6577-i2c": for MediaTek MT6577 |
| 9 | "mediatek,mt6589-i2c": for i2c compatible with mt6589. | 9 | "mediatek,mt6589-i2c": for MediaTek MT6589 |
| 10 | "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for i2c compatible with mt7623. | 10 | "mediatek,mt7622-i2c": for MediaTek MT7622 |
| 11 | "mediatek,mt8173-i2c": for i2c compatible with mt8173. | 11 | "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 |
| 12 | "mediatek,mt8173-i2c": for MediaTek MT8173 | ||
| 12 | - reg: physical base address of the controller and dma base, length of memory | 13 | - reg: physical base address of the controller and dma base, length of memory |
| 13 | mapped region. | 14 | mapped region. |
| 14 | - interrupts: interrupt number to the cpu. | 15 | - interrupts: interrupt number to the cpu. |
| @@ -2,6 +2,8 @@ I2C for R-Car platforms · 1 unmodified line | |||
| 2 | 2 | ||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: | 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 | "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. | 7 | "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. |
| 6 | "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. | 8 | "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. |
| 7 | "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. | 9 | "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. |
| @@ -12,7 +14,8 @@ Required properties: · 4 unmodified lines | |||
| 12 | "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC. | 14 | "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC. |
| 13 | "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC. | 15 | "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC. |
| 14 | "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device. | 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 | "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device. | 19 | "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device. |
| 17 | "renesas,i2c-rcar" (deprecated) | 20 | "renesas,i2c-rcar" (deprecated) |
| 18 | 21 | ||
| @@ -7,6 +7,7 @@ Required properties : · 6 unmodified lines | |||
| 7 | 7 | ||
| 8 | - reg : Offset and length of the register set for the device | 8 | - reg : Offset and length of the register set for the device |
| 9 | - compatible: should be one of the following: | 9 | - compatible: should be one of the following: |
| 10 | - "rockchip,rv1108-i2c": for rv1108 | ||
| 10 | - "rockchip,rk3066-i2c": for rk3066 | 11 | - "rockchip,rk3066-i2c": for rk3066 |
| 11 | - "rockchip,rk3188-i2c": for rk3188 | 12 | - "rockchip,rk3188-i2c": for rk3188 |
| 12 | - "rockchip,rk3228-i2c": for rk3228 | 13 | - "rockchip,rk3228-i2c": for rk3228 |
| @@ -4,6 +4,8 @@ Required properties: · 3 unmodified lines | |||
| 4 | - compatible : | 4 | - compatible : |
| 5 | - "renesas,iic-r8a73a4" (R-Mobile APE6) | 5 | - "renesas,iic-r8a73a4" (R-Mobile APE6) |
| 6 | - "renesas,iic-r8a7740" (R-Mobile A1) | 6 | - "renesas,iic-r8a7740" (R-Mobile A1) |
| 7 | - "renesas,iic-r8a7743" (RZ/G1M) | ||
| 8 | - "renesas,iic-r8a7745" (RZ/G1E) | ||
| 7 | - "renesas,iic-r8a7790" (R-Car H2) | 9 | - "renesas,iic-r8a7790" (R-Car H2) |
| 8 | - "renesas,iic-r8a7791" (R-Car M2-W) | 10 | - "renesas,iic-r8a7791" (R-Car M2-W) |
| 9 | - "renesas,iic-r8a7792" (R-Car V2H) | 11 | - "renesas,iic-r8a7792" (R-Car V2H) |
| @@ -12,7 +14,8 @@ Required properties: · 2 unmodified lines | |||
| 12 | - "renesas,iic-r8a7795" (R-Car H3) | 14 | - "renesas,iic-r8a7795" (R-Car H3) |
| 13 | - "renesas,iic-r8a7796" (R-Car M3-W) | 15 | - "renesas,iic-r8a7796" (R-Car M3-W) |
| 14 | - "renesas,iic-sh73a0" (SH-Mobile AG5) | 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 | - "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device) | 19 | - "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device) |
| 17 | - "renesas,rmobile-iic" (generic device) | 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 | * I2C controller embedded in STMicroelectronics STM32 I2C platform | 1 | * I2C controller embedded in STMicroelectronics STM32 I2C platform |
| 2 | 2 | ||
| 3 | Required properties : | 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 | - reg : Offset and length of the register set for the device | 7 | - reg : Offset and length of the register set for the device |
| 6 | - interrupts : Must contain the interrupt id for I2C event and then the | 8 | - interrupts : Must contain the interrupt id for I2C event and then the |
| 7 | interrupt id for I2C error. | 9 | interrupt id for I2C error. |
| @@ -14,8 +16,16 @@ Required properties : · 6 unmodified lines | |||
| 14 | 16 | ||
| 15 | Optional properties : | 17 | Optional properties : |
| 16 | - clock-frequency : Desired I2C bus clock frequency in Hz. If not specified, | 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 | 19 | the default 100 kHz frequency will be used. |
| 18 | are supported, possible values are 100000 and 400000. | 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 | Example : | 30 | Example : |
| 21 | 31 | ||
| @@ -31,3 +41,16 @@ Example : · 9 unmodified lines | |||
| 31 | pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>; | 41 | pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>; |
| 32 | pinctrl-names = "default"; | 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 | reset-names = "i2c"; | 71 | reset-names = "i2c"; |
| 72 | dmas = <&apbdma 16>, <&apbdma 16>; | 72 | dmas = <&apbdma 16>, <&apbdma 16>; |
| 73 | dma-names = "rx", "tx"; | 73 | dma-names = "rx", "tx"; |
| 74 | status = "disabled"; | ||
| 75 | }; | 74 | }; |
| @@ -11,6 +11,11 @@ Required properties: · 10 unmodified lines | |||
| 11 | - atmel,min-sample-rate-hz: Minimum sampling rate, it depends on SoC. | 11 | - atmel,min-sample-rate-hz: Minimum sampling rate, it depends on SoC. |
| 12 | - atmel,max-sample-rate-hz: Maximum sampling rate, it depends on SoC. | 12 | - atmel,max-sample-rate-hz: Maximum sampling rate, it depends on SoC. |
| 13 | - atmel,startup-time-ms: Startup time expressed in ms, it depends on SoC. | 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 | Example: | 20 | Example: |
| 16 | 21 | ||
| @@ -25,4 +30,5 @@ adc: adc@fc030000 { · 8 unmodified lines | |||
| 25 | atmel,startup-time-ms = <4>; | 30 | atmel,startup-time-ms = <4>; |
| 26 | vddana-supply = <&vdd_3v3_lp_reg>; | 31 | vddana-supply = <&vdd_3v3_lp_reg>; |
| 27 | vref-supply = <&vdd_3v3_lp_reg>; | 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 | clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>; | 37 | clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>; |
| 38 | clock-names = "tsc_clk"; | 38 | clock-names = "tsc_clk"; |
| 39 | interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; | 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 | clocks = <&ccu1 CLK_APB3_ADC0>; | 17 | clocks = <&ccu1 CLK_APB3_ADC0>; |
| 18 | vref-supply = <®_vdda>; | 18 | vref-supply = <®_vdda>; |
| 19 | resets = <&rgu 40>; | 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 | Required properties: | 12 | Required properties: |
| 13 | - compatible: Should be one of: | 13 | - compatible: Should be one of: |
| 14 | - "mediatek,mt2701-auxadc": For MT2701 family of SoCs | 14 | - "mediatek,mt2701-auxadc": For MT2701 family of SoCs |
| 15 | - "mediatek,mt7622-auxadc": For MT7622 family of SoCs | ||
| 15 | - "mediatek,mt8173-auxadc": For MT8173 family of SoCs | 16 | - "mediatek,mt8173-auxadc": For MT8173 family of SoCs |
| 16 | - reg: Address range of the AUXADC unit. | 17 | - reg: Address range of the AUXADC unit. |
| 17 | - clocks: Should contain a clock specifier for each entry in clock-names | 18 | - clocks: Should contain a clock specifier for each entry in clock-names |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | |||
| 6 | - "rockchip,rk3066-tsadc": for rk3036 | 6 | - "rockchip,rk3066-tsadc": for rk3036 |
| 7 | - "rockchip,rk3328-saradc", "rockchip,rk3399-saradc": for rk3328 | 7 | - "rockchip,rk3328-saradc", "rockchip,rk3399-saradc": for rk3328 |
| 8 | - "rockchip,rk3399-saradc": for rk3399 | 8 | - "rockchip,rk3399-saradc": for rk3399 |
| 9 | - "rockchip,rv1108-saradc", "rockchip,rk3399-saradc": for rv1108 | ||
| 9 | 10 | ||
| 10 | - reg: physical base address of the controller and length of memory mapped | 11 | - reg: physical base address of the controller and length of memory mapped |
| 11 | region. | 12 | region. |
| @@ -74,6 +74,11 @@ Optional properties: · 73 unmodified lines | |||
| 74 | * can be 6, 8, 10 or 12 on stm32f4 | 74 | * can be 6, 8, 10 or 12 on stm32f4 |
| 75 | * can be 8, 10, 12, 14 or 16 on stm32h7 | 75 | * can be 8, 10, 12, 14 or 16 on stm32h7 |
| 76 | Default is maximum resolution if unset. | 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 | Example: | 83 | Example: |
| 79 | adc: adc@40012000 { | 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 | clocks = <&ccu1 CLK_APB3_DAC>; | 16 | clocks = <&ccu1 CLK_APB3_DAC>; |
| 17 | vref-supply = <®_vdda>; | 17 | vref-supply = <®_vdda>; |
| 18 | resets = <&rgu 42>; | 18 | resets = <&rgu 42>; |
| 19 | status = "disabled"; | ||
| 20 | }; | 19 | }; |
| @@ -10,7 +10,9 @@ current. · 9 unmodified lines | |||
| 10 | Contents of a stm32 dac root node: | 10 | Contents of a stm32 dac root node: |
| 11 | ----------------------------------- | 11 | ----------------------------------- |
| 12 | Required properties: | 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 | - reg: Offset and length of the device's register set. | 16 | - reg: Offset and length of the device's register set. |
| 15 | - clocks: Must contain an entry for pclk (which feeds the peripheral bus | 17 | - clocks: Must contain an entry for pclk (which feeds the peripheral bus |
| 16 | interface) | 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 | - reg: i2c address of the sensor / spi cs line | 5 | - reg: i2c address of the sensor / spi cs line |
| 6 | 6 | ||
| 7 | Optional properties: | 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 | - interrupt-parent: should be the phandle for the interrupt controller | 16 | - interrupt-parent: should be the phandle for the interrupt controller |
| 9 | - interrupts: interrupt mapping for IRQ. It should be configured with | 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 | Refer to interrupt-controller/interrupts.txt for generic interrupt | 21 | Refer to interrupt-controller/interrupts.txt for generic interrupt |
| 13 | client node bindings. | 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 | Optional properties: | 11 | Optional properties: |
| 12 | - st,drdy-int-pin: the pin on the package that will be used to signal | 12 | - st,drdy-int-pin: the pin on the package that will be used to signal |
| 13 | "data ready" (valid values: 1 or 2). | 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 | - interrupt-parent: should be the phandle for the interrupt controller | 22 | - interrupt-parent: should be the phandle for the interrupt controller |
| 15 | - interrupts: interrupt mapping for IRQ. It should be configured with | 23 | - interrupts: interrupt mapping for IRQ. It should be configured with |
| 16 | flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or | 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 | - st,lis2dh12-accel | 45 | - st,lis2dh12-accel |
| 46 | - st,h3lis331dl-accel | 46 | - st,h3lis331dl-accel |
| 47 | - st,lng2dm-accel | 47 | - st,lng2dm-accel |
| 48 | - st,lis3l02dq | ||
| 48 | 49 | ||
| 49 | Gyroscopes: | 50 | Gyroscopes: |
| 50 | - st,l3g4200d-gyro | 51 | - st,l3g4200d-gyro |
| @@ -52,6 +53,7 @@ Gyroscopes: · 1 unmodified line | |||
| 52 | - st,lsm330dl-gyro | 53 | - st,lsm330dl-gyro |
| 53 | - st,lsm330dlc-gyro | 54 | - st,lsm330dlc-gyro |
| 54 | - st,l3gd20-gyro | 55 | - st,l3gd20-gyro |
| 56 | - st,l3gd20h-gyro | ||
| 55 | - st,l3g4is-gyro | 57 | - st,l3g4is-gyro |
| 56 | - st,lsm330-gyro | 58 | - st,lsm330-gyro |
| 57 | - st,lsm9ds0-gyro | 59 | - st,lsm9ds0-gyro |
| @@ -62,6 +64,7 @@ Magnetometers: · 4 unmodified lines | |||
| 62 | - st,lsm303dlhc-magn | 64 | - st,lsm303dlhc-magn |
| 63 | - st,lsm303dlm-magn | 65 | - st,lsm303dlm-magn |
| 64 | - st,lis3mdl-magn | 66 | - st,lis3mdl-magn |
| 67 | - st,lis2mdl | ||
| 65 | 68 | ||
| 66 | Pressure sensors: | 69 | Pressure sensors: |
| 67 | - st,lps001wp-press | 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 | See ../mfd/stm32-timers.txt for details about the parent node. | 4 | See ../mfd/stm32-timers.txt for details about the parent node. |
| 5 | 5 | ||
| 6 | Required parameters: | 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 | - reg: Identify trigger hardware block. | 10 | - reg: Identify trigger hardware block. |
| 9 | 11 | ||
| 10 | Example: | 12 | Example: |
| @@ -14,7 +16,7 @@ Example: · 3 unmodified lines | |||
| 14 | compatible = "st,stm32-timers"; | 16 | compatible = "st,stm32-timers"; |
| 15 | reg = <0x40010000 0x400>; | 17 | reg = <0x40010000 0x400>; |
| 16 | clocks = <&rcc 0 160>; | 18 | clocks = <&rcc 0 160>; |
| 17 | clock-names = "clk_int"; | 19 | clock-names = "int"; |
| 18 | 20 | ||
| 19 | timer@0 { | 21 | timer@0 { |
| 20 | compatible = "st,stm32-timer-trigger"; | 22 | compatible = "st,stm32-timer-trigger"; |
| @@ -22,6 +22,8 @@ Optional properties for main touchpad device: · 21 unmodified lines | |||
| 22 | experiment to determine which bit corresponds to which input. Use | 22 | experiment to determine which bit corresponds to which input. Use |
| 23 | KEY_RESERVED for unused padding values. | 23 | KEY_RESERVED for unused padding values. |
| 24 | 24 | ||
| 25 | - reset-gpios: GPIO specifier for the touchscreen's reset pin (active low) | ||
| 26 | |||
| 25 | Example: | 27 | Example: |
| 26 | 28 | ||
| 27 | touch@4b { | 29 | touch@4b { |
| @@ -72,7 +72,6 @@ Example: · 71 unmodified lines | |||
| 72 | /* Required Board specific properties */ | 72 | /* Required Board specific properties */ |
| 73 | keypad,num-rows = <5>; | 73 | keypad,num-rows = <5>; |
| 74 | keypad,num-columns = <5>; | 74 | keypad,num-columns = <5>; |
| 75 | status = "okay"; | ||
| 76 | 75 | ||
| 77 | linux,keymap = <MATRIX_KEY(0x00, 0x02, KEY_F) /* key_forward */ | 76 | linux,keymap = <MATRIX_KEY(0x00, 0x02, KEY_F) /* key_forward */ |
| 78 | MATRIX_KEY(0x00, 0x03, KEY_HOME) /* key_home */ | 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 | mode = <DRV260X_LRA_MODE>; | 43 | mode = <DRV260X_LRA_MODE>; |
| 44 | library-sel = <DRV260X_LIB_LRA>; | 44 | library-sel = <DRV260X_LIB_LRA>; |
| 45 | vib-rated-mv = <3200>; | 45 | vib-rated-mv = <3200>; |
| 46 | vib-overdriver-mv = <3200>; | 46 | vib-overdrive-mv = <3200>; |
| 47 | } | 47 | } |
| 48 | 48 | ||
| 49 | For more product information please see the link below: | 49 | For more product information please see the link below: |
| @@ -32,5 +32,4 @@ Example: · 31 unmodified lines | |||
| 32 | pinctrl-1 = <&pinctrl_touchctrl_default>; | 32 | pinctrl-1 = <&pinctrl_touchctrl_default>; |
| 33 | pinctrl-2 = <&pinctrl_touchctrl_gpios>; | 33 | pinctrl-2 = <&pinctrl_touchctrl_gpios>; |
| 34 | vf50-ts-min-pressure = <200>; | 34 | vf50-ts-min-pressure = <200>; |
| 35 | status = "disabled"; | ||
| 36 | }; | 35 | }; |
| @@ -35,5 +35,4 @@ Example: · 34 unmodified lines | |||
| 35 | measure-delay-time = <0xfff>; | 35 | measure-delay-time = <0xfff>; |
| 36 | pre-charge-time = <0xffff>; | 36 | pre-charge-time = <0xffff>; |
| 37 | touchscreen-average-samples = <32>; | 37 | touchscreen-average-samples = <32>; |
| 38 | status = "okay"; | ||
| 39 | }; | 38 | }; |
| @@ -4,8 +4,10 @@ Required properties: · 3 unmodified lines | |||
| 4 | 4 | ||
| 5 | - compatible: should be "fsl,<soc-name>-msi" to identify | 5 | - compatible: should be "fsl,<soc-name>-msi" to identify |
| 6 | Layerscape PCIe MSI controller block such as: | 6 | Layerscape PCIe MSI controller block such as: |
| 7 | "fsl,1s1021a-msi" | 7 | "fsl,ls1021a-msi" |
| 8 | "fsl,1s1043a-msi" | 8 | "fsl,ls1043a-msi" |
| 9 | "fsl,ls1046a-msi" | ||
| 10 | "fsl,ls1043a-v1.1-msi" | ||
| 9 | - msi-controller: indicates that this is a PCIe MSI controller node | 11 | - msi-controller: indicates that this is a PCIe MSI controller node |
| 10 | - reg: physical base address of the controller and length of memory mapped. | 12 | - reg: physical base address of the controller and length of memory mapped. |
| 11 | - interrupts: an interrupt to the parent interrupt controller. | 13 | - interrupts: an interrupt to the parent interrupt controller. |
| @@ -23,7 +25,7 @@ MSI controller node · 11 unmodified lines | |||
| 23 | Examples: | 25 | Examples: |
| 24 | 26 | ||
| 25 | msi1: msi-controller@1571000 { | 27 | msi1: msi-controller@1571000 { |
| 26 | compatible = "fsl,1s1043a-msi"; | 28 | compatible = "fsl,ls1043a-msi"; |
| 27 | reg = <0x0 0x1571000 0x0 0x8>, | 29 | reg = <0x0 0x1571000 0x0 0x8>, |
| 28 | msi-controller; | 30 | msi-controller; |
| 29 | interrupts = <0 116 0x4>; | 31 | interrupts = <0 116 0x4>; |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | |||
| 17 | "mediatek,mt6582-sysirq", "mediatek,mt6577-sysirq": for MT6582 | 17 | "mediatek,mt6582-sysirq", "mediatek,mt6577-sysirq": for MT6582 |
| 18 | "mediatek,mt6580-sysirq", "mediatek,mt6577-sysirq": for MT6580 | 18 | "mediatek,mt6580-sysirq", "mediatek,mt6577-sysirq": for MT6580 |
| 19 | "mediatek,mt6577-sysirq": for MT6577 | 19 | "mediatek,mt6577-sysirq": for MT6577 |
| 20 | "mediatek,mt2712-sysirq", "mediatek,mt6577-sysirq": for MT2712 | ||
| 20 | "mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701 | 21 | "mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701 |
| 21 | - interrupt-controller : Identifies the node as an interrupt controller | 22 | - interrupt-controller : Identifies the node as an interrupt controller |
| 22 | - #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt. | 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 | to associate with its master device. See: | 15 | to associate with its master device. See: |
| 16 | Documentation/devicetree/bindings/iommu/iommu.txt | 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 | Example: | 23 | Example: |
| 19 | 24 | ||
| 20 | vopl_mmu: iommu@ff940300 { | 25 | vopl_mmu: iommu@ff940300 { |
| @@ -18,6 +18,9 @@ LED sub-node properties: · 17 unmodified lines | |||
| 18 | see Documentation/devicetree/bindings/leds/common.txt | 18 | see Documentation/devicetree/bindings/leds/common.txt |
| 19 | - retain-state-suspended: (optional) The suspend state can be retained.Such | 19 | - retain-state-suspended: (optional) The suspend state can be retained.Such |
| 20 | as charge-led gpio. | 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 | - panic-indicator : (optional) | 24 | - panic-indicator : (optional) |
| 22 | see Documentation/devicetree/bindings/leds/common.txt | 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 | clock-frequency = <50000000>; | 24 | clock-frequency = <50000000>; |
| 25 | clock-output-names = "qci_mclk"; | 25 | clock-output-names = "qci_mclk"; |
| 26 | 26 | ||
| 27 | status = "okay"; | ||
| 28 | 27 | ||
| 29 | port { | 28 | port { |
| 30 | #address-cells = <1>; | 29 | #address-cells = <1>; |
| @@ -33,5 +33,4 @@ hdmicec: cec@100B0000 { · 32 unmodified lines | |||
| 33 | hdmi-phandle = <&hdmi>; | 33 | hdmi-phandle = <&hdmi>; |
| 34 | pinctrl-names = "default"; | 34 | pinctrl-names = "default"; |
| 35 | pinctrl-0 = <&hdmi_cec>; | 35 | pinctrl-0 = <&hdmi_cec>; |
| 36 | status = "okay"; | ||
| 37 | }; | 36 | }; |
| @@ -166,7 +166,6 @@ Example: · 165 unmodified lines | |||
| 166 | clock-output-names = "cam_a_clkout", "cam_b_clkout"; | 166 | clock-output-names = "cam_a_clkout", "cam_b_clkout"; |
| 167 | pinctrl-names = "default"; | 167 | pinctrl-names = "default"; |
| 168 | pinctrl-0 = <&cam_port_a_clk_active>; | 168 | pinctrl-0 = <&cam_port_a_clk_active>; |
| 169 | status = "okay"; | ||
| 170 | #address-cells = <1>; | 169 | #address-cells = <1>; |
| 171 | #size-cells = <1>; | 170 | #size-cells = <1>; |
| 172 | 171 | ||
| @@ -189,7 +188,6 @@ Example: · 16 unmodified lines | |||
| 189 | compatible = "samsung,exynos4210-fimc"; | 188 | compatible = "samsung,exynos4210-fimc"; |
| 190 | reg = <0x11800000 0x1000>; | 189 | reg = <0x11800000 0x1000>; |
| 191 | interrupts = <0 85 0>; | 190 | interrupts = <0 85 0>; |
| 192 | status = "okay"; | ||
| 193 | }; | 191 | }; |
| 194 | 192 | ||
| 195 | csis_0: csis@11880000 { | 193 | csis_0: csis@11880000 { |
| @@ -52,7 +52,6 @@ Example: · 51 unmodified lines | |||
| 52 | 52 | ||
| 53 | c8sectpfe@08a20000 { | 53 | c8sectpfe@08a20000 { |
| 54 | compatible = "st,stih407-c8sectpfe"; | 54 | compatible = "st,stih407-c8sectpfe"; |
| 55 | status = "okay"; | ||
| 56 | reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>; | 55 | reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>; |
| 57 | reg-names = "stfe", "stfe-ram"; | 56 | reg-names = "stfe", "stfe-ram"; |
| 58 | interrupts = <GIC_SPI 34 IRQ_TYPE_NONE>, <GIC_SPI 35 IRQ_TYPE_NONE>; | 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 | tvp5147@5d { | 59 | tvp5147@5d { |
| 60 | compatible = "ti,tvp5147"; | 60 | compatible = "ti,tvp5147"; |
| 61 | reg = <0x5d>; | 61 | reg = <0x5d>; |
| 62 | status = "okay"; | ||
| 63 | 62 | ||
| 64 | port { | 63 | port { |
| 65 | composite_in: endpoint { | 64 | composite_in: endpoint { |
| @@ -15,6 +15,9 @@ Required properties: · 14 unmodified lines | |||
| 15 | the register. | 15 | the register. |
| 16 | - "smi" : It's the clock for transfer data and command. | 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 | Example: | 21 | Example: |
| 19 | larb1: larb@16010000 { | 22 | larb1: larb@16010000 { |
| 20 | compatible = "mediatek,mt8173-smi-larb"; | 23 | compatible = "mediatek,mt8173-smi-larb"; |
| @@ -25,3 +28,15 @@ Example: · 4 unmodified lines | |||
| 25 | <&vdecsys CLK_VDEC_LARB_CKEN>; | 28 | <&vdecsys CLK_VDEC_LARB_CKEN>; |
| 26 | clock-names = "apb", "smi"; | 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 | Example: | 130 | Example: |
| 131 | 131 | ||
| 132 | devbus-bootcs@d0010400 { | 132 | devbus-bootcs@d0010400 { |
| 133 | status = "okay"; | ||
| 134 | ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */ | 133 | ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */ |
| 135 | #address-cells = <1>; | 134 | #address-cells = <1>; |
| 136 | #size-cells = <1>; | 135 | #size-cells = <1>; |
| @@ -12,7 +12,6 @@ Example: · 11 unmodified lines | |||
| 12 | pmic@5b { | 12 | pmic@5b { |
| 13 | compatible = "active-semi,act8945a"; | 13 | compatible = "active-semi,act8945a"; |
| 14 | reg = <0x5b>; | 14 | reg = <0x5b>; |
| 15 | status = "okay"; | ||
| 16 | 15 | ||
| 17 | active-semi,vsel-high; | 16 | active-semi,vsel-high; |
| 18 | 17 | ||
| @@ -79,6 +78,5 @@ Example: · 60 unmodified lines | |||
| 79 | active-semi,input-voltage-threshold-microvolt = <6600>; | 78 | active-semi,input-voltage-threshold-microvolt = <6600>; |
| 80 | active-semi,precondition-timeout = <40>; | 79 | active-semi,precondition-timeout = <40>; |
| 81 | active-semi,total-timeout = <3>; | 80 | active-semi,total-timeout = <3>; |
| 82 | status = "okay"; | ||
| 83 | }; | 81 | }; |
| 84 | }; | 82 | }; |
| @@ -25,7 +25,6 @@ Example: · 24 unmodified lines | |||
| 25 | clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; | 25 | clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; |
| 26 | clock-names = "periph_clk","sys_clk", "slow_clk"; | 26 | clock-names = "periph_clk","sys_clk", "slow_clk"; |
| 27 | interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; | 27 | interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; |
| 28 | status = "disabled"; | ||
| 29 | 28 | ||
| 30 | hlcdc-display-controller { | 29 | hlcdc-display-controller { |
| 31 | compatible = "atmel,hlcdc-display-controller"; | 30 | compatible = "atmel,hlcdc-display-controller"; |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | |||
| 8 | - compatible: Should be one of the following | 8 | - compatible: Should be one of the following |
| 9 | "atmel,at91sam9260-smc", "syscon" | 9 | "atmel,at91sam9260-smc", "syscon" |
| 10 | "atmel,sama5d3-smc", "syscon" | 10 | "atmel,sama5d3-smc", "syscon" |
| 11 | "atmel,sama5d2-smc", "syscon" | ||
| 11 | - reg: Contains offset/length value of the SMC memory | 12 | - reg: Contains offset/length value of the SMC memory |
| 12 | region. | 13 | region. |
| 13 | 14 | ||
| @@ -7,7 +7,14 @@ axp209 (X-Powers) · 6 unmodified lines | |||
| 7 | axp221 (X-Powers) | 7 | axp221 (X-Powers) |
| 8 | axp223 (X-Powers) | 8 | axp223 (X-Powers) |
| 9 | axp803 (X-Powers) | 9 | axp803 (X-Powers) |
| 10 | axp806 (X-Powers) | ||
| 10 | axp809 (X-Powers) | 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 | Required properties: | 19 | Required properties: |
| 13 | - compatible: should be one of: | 20 | - compatible: should be one of: |
| @@ -19,6 +26,7 @@ Required properties: · 5 unmodified lines | |||
| 19 | * "x-powers,axp803" | 26 | * "x-powers,axp803" |
| 20 | * "x-powers,axp806" | 27 | * "x-powers,axp806" |
| 21 | * "x-powers,axp809" | 28 | * "x-powers,axp809" |
| 29 | * "x-powers,axp813" | ||
| 22 | - reg: The I2C slave address or RSB hardware address for the AXP chip | 30 | - reg: The I2C slave address or RSB hardware address for the AXP chip |
| 23 | - interrupt-parent: The parent interrupt controller | 31 | - interrupt-parent: The parent interrupt controller |
| 24 | - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin | 32 | - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin |
| @@ -28,12 +36,14 @@ Required properties: · 3 unmodified lines | |||
| 28 | Optional properties: | 36 | Optional properties: |
| 29 | - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz | 37 | - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz |
| 30 | AXP152/20X: range: 750-1875, Default: 1.5 MHz | 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 | 41 | - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is |
| 34 | N_VBUSEN pin is used as an output pin to control an external | 42 | used as an output pin to control an external |
| 35 | regulator to drive the OTG VBus, rather then as an input pin | 43 | regulator to drive the OTG VBus, rather then |
| 36 | which signals whether the board is driving OTG VBus or not. | 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 | - x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is | 48 | - x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is |
| 39 | wired for master mode. The default is slave mode. | 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 | RTC_LDO : LDO : ips-supply : always on | 181 | RTC_LDO : LDO : ips-supply : always on |
| 172 | SW : On/Off Switch : swin-supply | 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 | Example: | 214 | Example: |
| 175 | 215 | ||
| 176 | axp209: pmic@34 { | 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 | - compatible : Should be "dlg,da9052", "dlg,da9053-aa", | 4 | - compatible : Should be "dlg,da9052", "dlg,da9053-aa", |
| 5 | "dlg,da9053-ab", or "dlg,da9053-bb" | 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 | Sub-nodes: | 15 | Sub-nodes: |
| 8 | - regulators : Contain the regulator nodes. The DA9052/53 regulators are | 16 | - regulators : Contain the regulator nodes. The DA9052/53 regulators are |
| 9 | bound using their names as listed below: | 17 | bound using their names as listed below: |
| @@ -29,7 +37,6 @@ Sub-nodes: · 19 unmodified lines | |||
| 29 | Examples: | 37 | Examples: |
| 30 | 38 | ||
| 31 | i2c@63fc8000 { /* I2C1 */ | 39 | i2c@63fc8000 { /* I2C1 */ |
| 32 | status = "okay"; | ||
| 33 | 40 | ||
| 34 | pmic: dialog@48 { | 41 | pmic: dialog@48 { |
| 35 | compatible = "dlg,da9053-aa"; | 42 | compatible = "dlg,da9053-aa"; |
| @@ -116,7 +116,6 @@ ecspi@70010000 { /* ECSPI1 */ · 115 unmodified lines | |||
| 116 | fsl,spi-num-chipselects = <2>; | 116 | fsl,spi-num-chipselects = <2>; |
| 117 | cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */ | 117 | cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */ |
| 118 | <&gpio4 25 0>; /* GPIO4_25 */ | 118 | <&gpio4 25 0>; /* GPIO4_25 */ |
| 119 | status = "okay"; | ||
| 120 | 119 | ||
| 121 | pmic: mc13892@0 { | 120 | pmic: mc13892@0 { |
| 122 | #address-cells = <1>; | 121 | #address-cells = <1>; |
| @@ -26,7 +26,6 @@ Example for i.MX23 SoC: · 25 unmodified lines | |||
| 26 | compatible = "fsl,imx23-lradc"; | 26 | compatible = "fsl,imx23-lradc"; |
| 27 | reg = <0x80050000 0x2000>; | 27 | reg = <0x80050000 0x2000>; |
| 28 | interrupts = <36 37 38 39 40 41 42 43 44>; | 28 | interrupts = <36 37 38 39 40 41 42 43 44>; |
| 29 | status = "okay"; | ||
| 30 | fsl,lradc-touchscreen-wires = <4>; | 29 | fsl,lradc-touchscreen-wires = <4>; |
| 31 | fsl,ave-ctrl = <4>; | 30 | fsl,ave-ctrl = <4>; |
| 32 | fsl,ave-delay = <2>; | 31 | fsl,ave-delay = <2>; |
| @@ -39,7 +38,6 @@ Example for i.MX28 SoC: · 6 unmodified lines | |||
| 39 | compatible = "fsl,imx28-lradc"; | 38 | compatible = "fsl,imx28-lradc"; |
| 40 | reg = <0x80050000 0x2000>; | 39 | reg = <0x80050000 0x2000>; |
| 41 | interrupts = <10 14 15 16 17 18 19 20 21 22 23 24 25>; | 40 | interrupts = <10 14 15 16 17 18 19 20 21 22 23 24 25>; |
| 42 | status = "okay"; | ||
| 43 | fsl,lradc-touchscreen-wires = <5>; | 41 | fsl,lradc-touchscreen-wires = <5>; |
| 44 | fsl,ave-ctrl = <4>; | 42 | fsl,ave-ctrl = <4>; |
| 45 | fsl,ave-delay = <2>; | 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 | RK8XX Power Management Integrated Circuit | 1 | RK8XX Power Management Integrated Circuit |
| 2 | 2 | ||
| 3 | The rk8xx family current members: | 3 | The rk8xx family current members: |
| 4 | rk805 | ||
| 4 | rk808 | 5 | rk808 |
| 5 | rk818 | 6 | rk818 |
| 6 | 7 | ||
| 7 | Required properties: | 8 | Required properties: |
| 8 | - compatible: "rockchip,rk808", "rockchip,rk818" | 9 | - compatible: "rockchip,rk805" |
| 10 | - compatible: "rockchip,rk808" | ||
| 11 | - compatible: "rockchip,rk818" | ||
| 9 | - reg: I2C slave address | 12 | - reg: I2C slave address |
| 10 | - interrupt-parent: The parent interrupt controller. | 13 | - interrupt-parent: The parent interrupt controller. |
| 11 | - interrupts: the interrupt outputs of the controller. | 14 | - interrupts: the interrupt outputs of the controller. |
| @@ -18,6 +21,14 @@ Optional properties: · 6 unmodified lines | |||
| 18 | - rockchip,system-power-controller: Telling whether or not this pmic is controlling | 21 | - rockchip,system-power-controller: Telling whether or not this pmic is controlling |
| 19 | the system power. | 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 | Optional RK808 properties: | 32 | Optional RK808 properties: |
| 22 | - vcc1-supply: The input supply for DCDC_REG1 | 33 | - vcc1-supply: The input supply for DCDC_REG1 |
| 23 | - vcc2-supply: The input supply for DCDC_REG2 | 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 | /* standard regulator bindings here */ | 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 | Following regulators of the RK808 PMIC block are supported. Note that | 79 | Following regulators of the RK808 PMIC block are supported. Note that |
| 60 | the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO | 80 | the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO |
| 61 | number as described in RK808 datasheet. | 81 | number as described in RK808 datasheet. |
| @@ -57,7 +57,6 @@ audio-subsystem { · 56 unmodified lines | |||
| 57 | clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; | 57 | clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; |
| 58 | pinctrl-names = "default"; | 58 | pinctrl-names = "default"; |
| 59 | pinctrl-0 = <&i2s0_bus>; | 59 | pinctrl-0 = <&i2s0_bus>; |
| 60 | status = "disabled"; | ||
| 61 | }; | 60 | }; |
| 62 | 61 | ||
| 63 | serial_3: serial@11460000 { | 62 | serial_3: serial@11460000 { |
| @@ -69,6 +68,5 @@ audio-subsystem { · 5 unmodified lines | |||
| 69 | clock-names = "uart", "clk_uart_baud0"; | 68 | clock-names = "uart", "clk_uart_baud0"; |
| 70 | pinctrl-names = "default"; | 69 | pinctrl-names = "default"; |
| 71 | pinctrl-0 = <&uart_aud_bus>; | 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 | ../interrupt-controller/interrupts.txt | 31 | ../interrupt-controller/interrupts.txt |
| 32 | 32 | ||
| 33 | Optional sub-nodes: | 33 | Optional sub-nodes: |
| 34 | - phys : Contains a phandle to the USB PHY. | ||
| 34 | - regulators : Contains sub-nodes for each of the regulators supplied by | 35 | - regulators : Contains sub-nodes for each of the regulators supplied by |
| 35 | the device. The regulators are bound using their names listed below: | 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 | ralink,rt5350-soc | 15 | ralink,rt5350-soc |
| 16 | ralink,mt7620a-soc | 16 | ralink,mt7620a-soc |
| 17 | ralink,mt7620n-soc | 17 | ralink,mt7620n-soc |
| 18 | ralink,mt7628a-soc | ||
| @@ -47,5 +47,4 @@ ssc0: ssc@f0010000 { · 46 unmodified lines | |||
| 47 | dma-names = "tx", "rx"; | 47 | dma-names = "tx", "rx"; |
| 48 | pinctrl-names = "default"; | 48 | pinctrl-names = "default"; |
| 49 | pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; | 49 | pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; |
| 50 | status = "disabled"; | ||
| 51 | }; | 50 | }; |
| @@ -74,5 +74,4 @@ Example: · 73 unmodified lines | |||
| 74 | phys = <&emmc_phy>; | 74 | phys = <&emmc_phy>; |
| 75 | phy-names = "phy_arasan"; | 75 | phy-names = "phy_arasan"; |
| 76 | #clock-cells = <0>; | 76 | #clock-cells = <0>; |
| 77 | status = "disabled"; | ||
| 78 | }; | 77 | }; |
| @@ -24,7 +24,6 @@ mmc0: mmc@1c40000 { · 23 unmodified lines | |||
| 24 | compatible = "ti,da830-mmc", | 24 | compatible = "ti,da830-mmc", |
| 25 | reg = <0x40000 0x1000>; | 25 | reg = <0x40000 0x1000>; |
| 26 | interrupts = <16>; | 26 | interrupts = <16>; |
| 27 | status = "okay"; | ||
| 28 | bus-width = <4>; | 27 | bus-width = <4>; |
| 29 | max-frequency = <50000000>; | 28 | max-frequency = <50000000>; |
| 30 | dmas = <&edma 16 | 29 | dmas = <&edma 16 |
| @@ -20,5 +20,4 @@ sdhci1: sdhci@10014000 { · 19 unmodified lines | |||
| 20 | dma-names = "rx-tx"; | 20 | dma-names = "rx-tx"; |
| 21 | bus-width = <4>; | 21 | bus-width = <4>; |
| 22 | cd-gpios = <&gpio3 29>; | 22 | cd-gpios = <&gpio3 29>; |
| 23 | status = "okay"; | ||
| 24 | }; | 23 | }; |
| @@ -21,7 +21,6 @@ Example: · 20 unmodified lines | |||
| 21 | vmmc-supply = <®_vcc3v3>; | 21 | vmmc-supply = <®_vcc3v3>; |
| 22 | bus-width = <8>; | 22 | bus-width = <8>; |
| 23 | non-removable; | 23 | non-removable; |
| 24 | status = "okay"; | ||
| 25 | 24 | ||
| 26 | mmccard: mmccard@0 { | 25 | mmccard: mmccard@0 { |
| 27 | reg = <0>; | 26 | reg = <0>; |
| @@ -153,7 +153,6 @@ mmc3: mmc@01c12000 { · 152 unmodified lines | |||
| 153 | bus-width = <4>; | 153 | bus-width = <4>; |
| 154 | non-removable; | 154 | non-removable; |
| 155 | mmc-pwrseq = <&sdhci0_pwrseq> | 155 | mmc-pwrseq = <&sdhci0_pwrseq> |
| 156 | status = "okay"; | ||
| 157 | 156 | ||
| 158 | brcmf: bcrmf@1 { | 157 | brcmf: bcrmf@1 { |
| 159 | reg = <1>; | 158 | reg = <1>; |
| @@ -13,5 +13,4 @@ Example: · 12 unmodified lines | |||
| 13 | reg = <0xd00d4000 0x200>; | 13 | reg = <0xd00d4000 0x200>; |
| 14 | interrupts = <54>; | 14 | interrupts = <54>; |
| 15 | clocks = <&gateclk 17>; | 15 | clocks = <&gateclk 17>; |
| 16 | status = "disabled"; | ||
| 17 | }; | 16 | }; |
| @@ -11,6 +11,8 @@ Required properties: · 10 unmodified lines | |||
| 11 | - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs | 11 | - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs |
| 12 | - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs | 12 | - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs |
| 13 | - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs | 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 | - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs | 16 | - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs |
| 15 | - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs | 17 | - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs |
| 16 | - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs | 18 | - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs |
| @@ -21,7 +23,7 @@ Required properties: · 4 unmodified lines | |||
| 21 | - interrupts: Some SoCs have only 1 shared interrupt, while others have either | 23 | - interrupts: Some SoCs have only 1 shared interrupt, while others have either |
| 22 | 2 or 3 individual interrupts (error, int, card detect). Below is the number | 24 | 2 or 3 individual interrupts (error, int, card detect). Below is the number |
| 23 | of interrupts for each SoC: | 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 | 2: r8a7740, sh73a0 | 27 | 2: r8a7740, sh73a0 |
| 26 | 3: r7s72100 | 28 | 3: r7s72100 |
| 27 | 29 | ||
| @@ -15,6 +15,7 @@ Required Properties: · 14 unmodified lines | |||
| 15 | - "rockchip,rk3288-dw-mshc": for Rockchip RK3288 | 15 | - "rockchip,rk3288-dw-mshc": for Rockchip RK3288 |
| 16 | - "rockchip,rv1108-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RV1108 | 16 | - "rockchip,rv1108-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RV1108 |
| 17 | - "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036 | 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 | - "rockchip,rk3328-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3328 | 19 | - "rockchip,rk3328-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3328 |
| 19 | - "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368 | 20 | - "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368 |
| 20 | - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399 | 21 | - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3399 |
| @@ -63,7 +63,6 @@ Example: · 62 unmodified lines | |||
| 63 | 63 | ||
| 64 | mmc0: sdhci@fe81e000 { | 64 | mmc0: sdhci@fe81e000 { |
| 65 | compatible = "st,sdhci"; | 65 | compatible = "st,sdhci"; |
| 66 | status = "disabled"; | ||
| 67 | reg = <0xfe81e000 0x1000>; | 66 | reg = <0xfe81e000 0x1000>; |
| 68 | interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>; | 67 | interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>; |
| 69 | interrupt-names = "mmcirq"; | 68 | interrupt-names = "mmcirq"; |
| @@ -77,7 +76,6 @@ mmc0: sdhci@fe81e000 { · 7 unmodified lines | |||
| 77 | 76 | ||
| 78 | mmc1: sdhci@09080000 { | 77 | mmc1: sdhci@09080000 { |
| 79 | compatible = "st,sdhci-stih407", "st,sdhci"; | 78 | compatible = "st,sdhci-stih407", "st,sdhci"; |
| 80 | status = "disabled"; | ||
| 81 | reg = <0x09080000 0x7ff>; | 79 | reg = <0x09080000 0x7ff>; |
| 82 | reg-names = "mmc"; | 80 | reg-names = "mmc"; |
| 83 | interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>; | 81 | interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>; |
| @@ -94,7 +92,6 @@ mmc1: sdhci@09080000 { · 10 unmodified lines | |||
| 94 | 92 | ||
| 95 | mmc0: sdhci@09060000 { | 93 | mmc0: sdhci@09060000 { |
| 96 | compatible = "st,sdhci-stih407", "st,sdhci"; | 94 | compatible = "st,sdhci-stih407", "st,sdhci"; |
| 97 | status = "disabled"; | ||
| 98 | reg = <0x09060000 0x7ff>, <0x9061008 0x20>; | 95 | reg = <0x09060000 0x7ff>, <0x9061008 0x20>; |
| 99 | reg-names = "mmc", "top-mmc-delay"; | 96 | reg-names = "mmc", "top-mmc-delay"; |
| 100 | interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>; | 97 | interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>; |
| @@ -12,6 +12,7 @@ Required properties: · 11 unmodified lines | |||
| 12 | * "allwinner,sun4i-a10-mmc" | 12 | * "allwinner,sun4i-a10-mmc" |
| 13 | * "allwinner,sun5i-a13-mmc" | 13 | * "allwinner,sun5i-a13-mmc" |
| 14 | * "allwinner,sun7i-a20-mmc" | 14 | * "allwinner,sun7i-a20-mmc" |
| 15 | * "allwinner,sun8i-a83t-emmc" | ||
| 15 | * "allwinner,sun9i-a80-mmc" | 16 | * "allwinner,sun9i-a80-mmc" |
| 16 | * "allwinner,sun50i-a64-emmc" | 17 | * "allwinner,sun50i-a64-emmc" |
| 17 | * "allwinner,sun50i-a64-mmc" | 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 | provides an interface for MMC, SD, and SDIO types of memory cards. | 4 | provides an interface for MMC, SD, and SDIO types of memory cards. |
| 5 | 5 | ||
| 6 | This file documents differences between the core properties described | 6 | This file documents differences between the core properties described |
| 7 | by mmc.txt and the properties used by the omap_hsmmc driver. | 7 | by mmc.txt and the properties used by the omap_hsmmc driver. |
| 8 | 8 | ||
| 9 | Required properties: | 9 | Required properties: |
| 10 | -------------------- | ||
| 10 | - compatible: | 11 | - compatible: |
| 11 | Should be "ti,omap2-hsmmc", for OMAP2 controllers | 12 | Should be "ti,omap2-hsmmc", for OMAP2 controllers |
| 12 | Should be "ti,omap3-hsmmc", for OMAP3 controllers | 13 | Should be "ti,omap3-hsmmc", for OMAP3 controllers |
| 13 | Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 | 14 | Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 |
| 14 | Should be "ti,omap4-hsmmc", for OMAP4 controllers | 15 | Should be "ti,omap4-hsmmc", for OMAP4 controllers |
| 15 | Should be "ti,am33xx-hsmmc", for AM335x controllers | 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 | Optional properties: | 36 | Optional properties: |
| 19 | ti,dual-volt: boolean, supports dual voltage cards | 37 | -------------------- |
| 20 | <supply-name>-supply: phandle to the regulator device tree node | 38 | - ti,dual-volt: boolean, supports dual voltage cards |
| 21 | "supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc | 39 | - <supply-name>-supply: phandle to the regulator device tree node |
| 22 | ti,non-removable: non-removable slot (like eMMC) | 40 | "supply-name" examples are "vmmc", |
| 23 | ti,needs-special-reset: Requires a special softreset sequence | 41 | "vmmc_aux"(deprecated)/"vqmmc" etc |
| 24 | ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed | 42 | - ti,non-removable: non-removable slot (like eMMC) |
| 25 | dmas: List of DMA specifiers with the controller specific format | 43 | - ti,needs-special-reset: Requires a special softreset sequence |
| 26 | as described in the generic DMA client binding. A tx and rx | 44 | - ti,needs-special-hs-handling: HSMMC IP needs special setting |
| 27 | specifier is required. | 45 | for handling High Speed |
| 28 | dma-names: List of DMA request names. These strings correspond | 46 | - dmas: List of DMA specifiers with the controller specific |
| 29 | 1:1 with the DMA specifiers listed in dmas. The string naming is | 47 | format as described in the generic DMA client |
| 30 | to be "rx" and "tx" for RX and TX DMA requests, respectively. | 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 | Examples: | 54 | Examples: |
| 33 | 55 | ||
| @@ -15,6 +15,8 @@ Required properties: · 14 unmodified lines | |||
| 15 | "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC | 15 | "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC |
| 16 | "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC | 16 | "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC |
| 17 | "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC | 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 | "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC | 20 | "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC |
| 19 | "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC | 21 | "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC |
| 20 | "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC | 22 | "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC |
| @@ -33,10 +35,8 @@ Required properties: · 12 unmodified lines | |||
| 33 | If 2 clocks are specified by the hardware, you must name them as | 35 | If 2 clocks are specified by the hardware, you must name them as |
| 34 | "core" and "cd". If the controller only has 1 clock, naming is not | 36 | "core" and "cd". If the controller only has 1 clock, naming is not |
| 35 | required. | 37 | required. |
| 36 | Below is the number clocks for each supported SoC: | 38 | Devices which have more than 1 clock are listed below: |
| 37 | 1: SH73A0, R8A73A4, R8A7740, R8A7778, R8A7779, R8A7790 | 39 | 2: R7S72100 |
| 38 | R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796 | ||
| 39 | 2: R7S72100 | ||
| 40 | 40 | ||
| 41 | Optional properties: | 41 | Optional properties: |
| 42 | - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable | 42 | - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable |
| @@ -28,5 +28,4 @@ Example: · 27 unmodified lines | |||
| 28 | max-frequency = <50000000>; | 28 | max-frequency = <50000000>; |
| 29 | cap-sdio-irq; | 29 | cap-sdio-irq; |
| 30 | cap-sd-highspeed; | 30 | cap-sd-highspeed; |
| 31 | status = "disabled"; | ||
| 32 | }; | 31 | }; |
| @@ -24,7 +24,6 @@ spi@f0020000 { · 23 unmodified lines | |||
| 24 | #size-cells = <0>; | 24 | #size-cells = <0>; |
| 25 | pinctrl-names = "default"; | 25 | pinctrl-names = "default"; |
| 26 | pinctrl-0 = <&pinctrl_spi0_default>; | 26 | pinctrl-0 = <&pinctrl_spi0_default>; |
| 27 | status = "okay"; | ||
| 28 | 27 | ||
| 29 | m25p80@0 { | 28 | m25p80@0 { |
| 30 | ... | 29 | ... |
| @@ -37,7 +37,6 @@ nor_flash: spi@1100d000 { · 36 unmodified lines | |||
| 37 | clock-names = "spi", "sf"; | 37 | clock-names = "spi", "sf"; |
| 38 | #address-cells = <1>; | 38 | #address-cells = <1>; |
| 39 | #size-cells = <0>; | 39 | #size-cells = <0>; |
| 40 | status = "disabled"; | ||
| 41 | 40 | ||
| 42 | flash@0 { | 41 | flash@0 { |
| 43 | compatible = "jedec,spi-nor"; | 42 | compatible = "jedec,spi-nor"; |
| @@ -1,11 +1,20 @@ | |||
| 1 | * Qualcomm NAND controller | 1 | * Qualcomm NAND controller |
| 2 | 2 | ||
| 3 | Required properties: | 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 | - reg: MMIO address range | 12 | - reg: MMIO address range |
| 6 | - clocks: must contain core clock and always on clock | 13 | - clocks: must contain core clock and always on clock |
| 7 | - clock-names: must contain "core" for the core clock and "aon" for the | 14 | - clock-names: must contain "core" for the core clock and "aon" for the |
| 8 | always on clock | 15 | always on clock |
| 16 | |||
| 17 | EBI2 specific properties: | ||
| 9 | - dmas: DMA specifier, consisting of a phandle to the ADM DMA | 18 | - dmas: DMA specifier, consisting of a phandle to the ADM DMA |
| 10 | controller node and the channel number to be used for | 19 | controller node and the channel number to be used for |
| 11 | NAND. Refer to dma.txt and qcom_adm.txt for more details | 20 | NAND. Refer to dma.txt and qcom_adm.txt for more details |
| @@ -16,6 +25,12 @@ Required properties: · 4 unmodified lines | |||
| 16 | - qcom,data-crci: must contain the ADM data type CRCI block instance | 25 | - qcom,data-crci: must contain the ADM data type CRCI block instance |
| 17 | number specified for the NAND controller on the given | 26 | number specified for the NAND controller on the given |
| 18 | platform | 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 | - #address-cells: <1> - subnodes give the chip-select number | 34 | - #address-cells: <1> - subnodes give the chip-select number |
| 20 | - #size-cells: <0> | 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 | follows. | 41 | follows. |
| 27 | 42 | ||
| 28 | Required properties: | 43 | Required properties: |
| 29 | - compatible: should contain "qcom,nandcs" | ||
| 30 | - reg: a single integer representing the chip-select | 44 | - reg: a single integer representing the chip-select |
| 31 | number (e.g., 0, 1, 2, etc.) | 45 | number (e.g., 0, 1, 2, etc.) |
| 32 | - #address-cells: see partition.txt | 46 | - #address-cells: see partition.txt |
| @@ -43,8 +57,8 @@ partition.txt for more detail. · 10 unmodified lines | |||
| 43 | 57 | ||
| 44 | Example: | 58 | Example: |
| 45 | 59 | ||
| 46 | nand@1ac00000 { | 60 | nand-controller@1ac00000 { |
| 47 | compatible = "qcom,ebi2-nandc"; | 61 | compatible = "qcom,ipq806x-nand"; |
| 48 | reg = <0x1ac00000 0x800>; | 62 | reg = <0x1ac00000 0x800>; |
| 49 | 63 | ||
| 50 | clocks = <&gcc EBI2_CLK>, | 64 | clocks = <&gcc EBI2_CLK>, |
| @@ -59,8 +73,7 @@ nand@1ac00000 { · 8 unmodified lines | |||
| 59 | #address-cells = <1>; | 73 | #address-cells = <1>; |
| 60 | #size-cells = <0>; | 74 | #size-cells = <0>; |
| 61 | 75 | ||
| 62 | nandcs@0 { | 76 | nand@0 { |
| 63 | compatible = "qcom,nandcs"; | ||
| 64 | reg = <0>; | 77 | reg = <0>; |
| 65 | 78 | ||
| 66 | nand-ecc-strength = <4>; | 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 | st,syscfg = <&syscfg_rear>; | 21 | st,syscfg = <&syscfg_rear>; |
| 22 | st,boot-device-reg = <0x958>; | 22 | st,boot-device-reg = <0x958>; |
| 23 | st,boot-device-spi = <0x1a>; | 23 | st,boot-device-spi = <0x1a>; |
| 24 | status = "okay"; | ||
| 25 | }; | 24 | }; |
| 26 | 25 | ||
| @@ -41,7 +41,6 @@ nfc: nand@01c03000 { · 40 unmodified lines | |||
| 41 | #size-cells = <0>; | 41 | #size-cells = <0>; |
| 42 | pinctrl-names = "default"; | 42 | pinctrl-names = "default"; |
| 43 | pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>; | 43 | pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>; |
| 44 | status = "okay"; | ||
| 45 | 44 | ||
| 46 | nand@0 { | 45 | nand@0 { |
| 47 | reg = <0>; | 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 | <0x18110000 0x1000>; | 27 | <0x18110000 0x1000>; |
| 28 | reg-names = "amac_base", "idm_base"; | 28 | reg-names = "amac_base", "idm_base"; |
| 29 | interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; | 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 | Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt: | 29 | Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt: |
| 30 | 30 | ||
| 31 | &usb_host1_ehci { | 31 | &usb_host1_ehci { |
| 32 | status = "okay"; | ||
| 33 | #address-cells = <1>; | 32 | #address-cells = <1>; |
| 34 | #size-cells = <0>; | 33 | #size-cells = <0>; |
| 35 | 34 | ||
| @@ -11,9 +11,20 @@ Required properties: · 10 unmodified lines | |||
| 11 | - interrupts : property with a value describing the interrupt | 11 | - interrupts : property with a value describing the interrupt |
| 12 | number | 12 | number |
| 13 | 13 | ||
| 14 | Optional properties: | 14 | The following are mandatory properties for DRA7x, AM33xx and AM43xx SoCs only: |
| 15 | - ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the | 15 | - ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the |
| 16 | instance number | 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 | - syscon-raminit : Handle to system control region that contains the | 28 | - syscon-raminit : Handle to system control region that contains the |
| 18 | RAMINIT register, register offset to the RAMINIT | 29 | RAMINIT register, register offset to the RAMINIT |
| 19 | register and the CAN instance number (0 offset). | 30 | register and the CAN instance number (0 offset). |
| @@ -56,7 +56,6 @@ m_can1: can@020e8000 { · 55 unmodified lines | |||
| 56 | <&clks IMX6SX_CLK_CANFD>; | 56 | <&clks IMX6SX_CLK_CANFD>; |
| 57 | clock-names = "hclk", "cclk"; | 57 | clock-names = "hclk", "cclk"; |
| 58 | bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>; | 58 | bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>; |
| 59 | status = "disabled"; | ||
| 60 | }; | 59 | }; |
| 61 | 60 | ||
| 62 | Board dts: | 61 | Board dts: |
| @@ -24,7 +24,6 @@ Ethernet switch connected via SPI to the host, CPU port wired to eth0: · 23 unmodified lines | |||
| 24 | pinctrl-0 = <&pinctrl_spi_ksz>; | 24 | pinctrl-0 = <&pinctrl_spi_ksz>; |
| 25 | cs-gpios = <&pioC 25 0>; | 25 | cs-gpios = <&pioC 25 0>; |
| 26 | id = <1>; | 26 | id = <1>; |
| 27 | status = "okay"; | ||
| 28 | 27 | ||
| 29 | ksz9477: ksz9477@0 { | 28 | ksz9477: ksz9477@0 { |
| 30 | compatible = "microchip,ksz9477"; | 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 | spi-cpha; | 33 | spi-cpha; |
| 35 | spi-cpol; | 34 | spi-cpol; |
| 36 | 35 | ||
| 37 | status = "okay"; | ||
| 38 | ports { | 36 | ports { |
| 39 | #address-cells = <1>; | 37 | #address-cells = <1>; |
| 40 | #size-cells = <0>; | 38 | #size-cells = <0>; |
| @@ -27,7 +27,6 @@ Example: · 26 unmodified lines | |||
| 27 | I2C managed mode: | 27 | I2C managed mode: |
| 28 | 28 | ||
| 29 | master: masterdevice@X { | 29 | master: masterdevice@X { |
| 30 | status = "okay"; | ||
| 31 | 30 | ||
| 32 | fixed-link { /* RMII fixed link to LAN9303 */ | 31 | fixed-link { /* RMII fixed link to LAN9303 */ |
| 33 | speed = <100>; | 32 | speed = <100>; |
| @@ -38,7 +37,6 @@ I2C managed mode: · 4 unmodified lines | |||
| 38 | switch: switch@a { | 37 | switch: switch@a { |
| 39 | compatible = "smsc,lan9303-i2c"; | 38 | compatible = "smsc,lan9303-i2c"; |
| 40 | reg = <0xa>; | 39 | reg = <0xa>; |
| 41 | status = "okay"; | ||
| 42 | reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>; | 40 | reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>; |
| 43 | reset-duration = <200>; | 41 | reset-duration = <200>; |
| 44 | 42 | ||
| @@ -67,7 +65,6 @@ I2C managed mode: · 22 unmodified lines | |||
| 67 | MDIO managed mode: | 65 | MDIO managed mode: |
| 68 | 66 | ||
| 69 | master: masterdevice@X { | 67 | master: masterdevice@X { |
| 70 | status = "okay"; | ||
| 71 | phy-handle = <&switch>; | 68 | phy-handle = <&switch>; |
| 72 | 69 | ||
| 73 | mdio { | 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 | The following properties are common to the Ethernet controllers: | 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 | - local-mac-address: array of 6 bytes, specifies the MAC address that was | 7 | - local-mac-address: array of 6 bytes, specifies the MAC address that was |
| 4 | assigned to the network device; | 8 | assigned to the network device; |
| 5 | - mac-address: array of 6 bytes, specifies the MAC address that was last used by | 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 | compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; | 30 | compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; |
| 31 | reg = <0x1e660000 0x180>; | 31 | reg = <0x1e660000 0x180>; |
| 32 | interrupts = <2>; | 32 | interrupts = <2>; |
| 33 | status = "okay"; | ||
| 34 | use-ncsi; | 33 | use-ncsi; |
| 35 | }; | 34 | }; |
| @@ -41,7 +41,6 @@ ethernet@70000 { · 40 unmodified lines | |||
| 41 | interrupts = <8>; | 41 | interrupts = <8>; |
| 42 | clocks = <&gate_clk 4>; | 42 | clocks = <&gate_clk 4>; |
| 43 | tx-csum-limit = <9800> | 43 | tx-csum-limit = <9800> |
| 44 | status = "okay"; | ||
| 45 | phy = <&phy0>; | 44 | phy = <&phy0>; |
| 46 | phy-mode = "rgmii-id"; | 45 | phy-mode = "rgmii-id"; |
| 47 | buffer-manager = <&bm>; | 46 | buffer-manager = <&bm>; |
| @@ -44,7 +44,6 @@ Example for SDIO device follows (calibration data is also available in · 43 unmodified lines | |||
| 44 | below example). | 44 | below example). |
| 45 | 45 | ||
| 46 | &mmc3 { | 46 | &mmc3 { |
| 47 | status = "okay"; | ||
| 48 | vmmc-supply = <&wlan_en_reg>; | 47 | vmmc-supply = <&wlan_en_reg>; |
| 49 | bus-width = <4>; | 48 | bus-width = <4>; |
| 50 | cap-power-off-card; | 49 | cap-power-off-card; |
| @@ -70,7 +69,6 @@ below example). · 19 unmodified lines | |||
| 70 | Example for USB device: | 69 | Example for USB device: |
| 71 | 70 | ||
| 72 | &usb_host1_ohci { | 71 | &usb_host1_ohci { |
| 73 | status = "okay"; | ||
| 74 | #address-cells = <1>; | 72 | #address-cells = <1>; |
| 75 | #size-cells = <0>; | 73 | #size-cells = <0>; |
| 76 | 74 | ||
| @@ -31,7 +31,6 @@ bm: bm@c8000 { · 30 unmodified lines | |||
| 31 | reg = <0xc8000 0xac>; | 31 | reg = <0xc8000 0xac>; |
| 32 | clocks = <&gateclk 13>; | 32 | clocks = <&gateclk 13>; |
| 33 | internal-mem = <&bm_bppi>; | 33 | internal-mem = <&bm_bppi>; |
| 34 | status = "okay"; | ||
| 35 | pool2,capacity = <4096>; | 34 | pool2,capacity = <4096>; |
| 36 | pool1,pkt-size = <512>; | 35 | pool1,pkt-size = <512>; |
| 37 | }; | 36 | }; |
| @@ -45,5 +44,4 @@ bm_bppi: bm-bppi { · 7 unmodified lines | |||
| 45 | #address-cells = <1>; | 44 | #address-cells = <1>; |
| 46 | #size-cells = <1>; | 45 | #size-cells = <1>; |
| 47 | clocks = <&gateclk 13>; | 46 | clocks = <&gateclk 13>; |
| 48 | status = "okay"; | ||
| 49 | }; | 47 | }; |
| @@ -41,6 +41,11 @@ Optional properties (port): · 40 unmodified lines | |||
| 41 | - marvell,loopback: port is loopback mode | 41 | - marvell,loopback: port is loopback mode |
| 42 | - phy: a phandle to a phy node defining the PHY address (as the reg | 42 | - phy: a phandle to a phy node defining the PHY address (as the reg |
| 43 | property, a single integer). | 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 | Example for marvell,armada-375-pp2: | 50 | Example for marvell,armada-375-pp2: |
| 46 | 51 | ||
| @@ -52,12 +57,10 @@ ethernet@f0000 { · 5 unmodified lines | |||
| 52 | <0xc5000 0x100>; | 57 | <0xc5000 0x100>; |
| 53 | clocks = <&gateclk 3>, <&gateclk 19>; | 58 | clocks = <&gateclk 3>, <&gateclk 19>; |
| 54 | clock-names = "pp_clk", "gop_clk"; | 59 | clock-names = "pp_clk", "gop_clk"; |
| 55 | status = "okay"; | ||
| 56 | 60 | ||
| 57 | eth0: eth0@c4000 { | 61 | eth0: eth0@c4000 { |
| 58 | interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; | 62 | interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; |
| 59 | port-id = <0>; | 63 | port-id = <0>; |
| 60 | status = "okay"; | ||
| 61 | phy = <&phy0>; | 64 | phy = <&phy0>; |
| 62 | phy-mode = "gmii"; | 65 | phy-mode = "gmii"; |
| 63 | }; | 66 | }; |
| @@ -65,7 +68,6 @@ ethernet@f0000 { · 1 unmodified line | |||
| 65 | eth1: eth1@c5000 { | 68 | eth1: eth1@c5000 { |
| 66 | interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; | 69 | interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; |
| 67 | port-id = <1>; | 70 | port-id = <1>; |
| 68 | status = "okay"; | ||
| 69 | phy = <&phy3>; | 71 | phy = <&phy3>; |
| 70 | phy-mode = "gmii"; | 72 | phy-mode = "gmii"; |
| 71 | }; | 73 | }; |
| @@ -80,19 +82,37 @@ cpm_ethernet: ethernet@0 { · 8 unmodified lines | |||
| 80 | clock-names = "pp_clk", "gop_clk", "gp_clk"; | 82 | clock-names = "pp_clk", "gop_clk", "gp_clk"; |
| 81 | 83 | ||
| 82 | eth0: eth0 { | 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 | port-id = <0>; | 92 | port-id = <0>; |
| 85 | gop-port-id = <0>; | 93 | gop-port-id = <0>; |
| 86 | }; | 94 | }; |
| 87 | 95 | ||
| 88 | eth1: eth1 { | 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 | port-id = <1>; | 104 | port-id = <1>; |
| 91 | gop-port-id = <2>; | 105 | gop-port-id = <2>; |
| 92 | }; | 106 | }; |
| 93 | 107 | ||
| 94 | eth2: eth2 { | 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 | port-id = <2>; | 116 | port-id = <2>; |
| 97 | gop-port-id = <3>; | 117 | gop-port-id = <3>; |
| 98 | }; | 118 | }; |
| @@ -7,24 +7,32 @@ have dual GMAC each represented by a child node.. · 6 unmodified lines | |||
| 7 | * Ethernet controller node | 7 | * Ethernet controller node |
| 8 | 8 | ||
| 9 | Required properties: | 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 | - reg: Address and length of the register set for the device | 14 | - reg: Address and length of the register set for the device |
| 12 | - interrupts: Should contain the three frame engines interrupts in numeric | 15 | - interrupts: Should contain the three frame engines interrupts in numeric |
| 13 | order. These are fe_int0, fe_int1 and fe_int2. | 16 | order. These are fe_int0, fe_int1 and fe_int2. |
| 14 | - clocks: the clock used by the core | 17 | - clocks: the clock used by the core |
| 15 | - clock-names: the names of the clock listed in the clocks property. These are | 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 | - power-domains: phandle to the power domain that the ethernet is part of | 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 | 23 | - resets: Should contain phandles to the ethsys reset signals |
| 19 | - reset-names: Should contain the reset signal name "eth" | 24 | - reset-names: Should contain the names of reset signal listed in the resets |
| 25 | property | ||
| 26 | These are "fe", "gmac" and "ppe" | ||
| 20 | - mediatek,ethsys: phandle to the syscon node that handles the port setup | 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 | - mediatek,pctl: phandle to the syscon node that handles the ports slew rate | 30 | - mediatek,pctl: phandle to the syscon node that handles the ports slew rate |
| 22 | and driver current | 31 | and driver current |
| 23 | 32 | ||
| 24 | Optional properties: | 33 | Optional properties: |
| 25 | - interrupt-parent: Should be the phandle for the interrupt controller | 34 | - interrupt-parent: Should be the phandle for the interrupt controller |
| 26 | that services interrupts for this device | 35 | that services interrupts for this device |
| 27 | |||
| 28 | * Ethernet MAC node | 36 | * Ethernet MAC node |
| 29 | 37 | ||
| 30 | Required properties: | 38 | Required properties: |
| @@ -66,5 +66,4 @@ Example for GXBB: · 65 unmodified lines | |||
| 66 | <&clkc CLKID_MPLL2>; | 66 | <&clkc CLKID_MPLL2>; |
| 67 | clock-names = "stmmaceth", "clkin0", "clkin1"; | 67 | clock-names = "stmmaceth", "clkin0", "clkin1"; |
| 68 | phy-mode = "rgmii"; | 68 | phy-mode = "rgmii"; |
| 69 | status = "disabled"; | ||
| 70 | }; | 69 | }; |
| @@ -69,7 +69,6 @@ Examples: · 68 unmodified lines | |||
| 69 | }; | 69 | }; |
| 70 | }; | 70 | }; |
| 71 | ethernet@70000 { | 71 | ethernet@70000 { |
| 72 | status = "okay"; | ||
| 73 | phy = <&phy0>; | 72 | phy = <&phy0>; |
| 74 | phy-mode = "rgmii-id"; | 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 | compatible = "fsl,imx28-spi"; | 33 | compatible = "fsl,imx28-spi"; |
| 34 | pinctrl-names = "default"; | 34 | pinctrl-names = "default"; |
| 35 | pinctrl-0 = <&spi2_pins_b &spi2_sck_cfg>; | 35 | pinctrl-0 = <&spi2_pins_b &spi2_sck_cfg>; |
| 36 | status = "okay"; | ||
| 37 | 36 | ||
| 38 | enc28j60: ethernet@0 { | 37 | enc28j60: ethernet@0 { |
| 39 | compatible = "microchip,enc28j60"; | 38 | compatible = "microchip,enc28j60"; |
| @@ -25,7 +25,6 @@ Optional I2C-based chip specific properties: · 24 unmodified lines | |||
| 25 | Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): | 25 | Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): |
| 26 | 26 | ||
| 27 | &uart5 { | 27 | &uart5 { |
| 28 | status = "okay"; | ||
| 29 | 28 | ||
| 30 | nfcmrvluart: nfcmrvluart@5 { | 29 | nfcmrvluart: nfcmrvluart@5 { |
| 31 | compatible = "marvell,nfc-uart"; | 30 | compatible = "marvell,nfc-uart"; |
| @@ -41,7 +40,6 @@ Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): · 9 unmodified lines | |||
| 41 | Example (for ARM-based BeagleBoard Black with 88W8887 on I2C1): | 40 | Example (for ARM-based BeagleBoard Black with 88W8887 on I2C1): |
| 42 | 41 | ||
| 43 | &i2c1 { | 42 | &i2c1 { |
| 44 | status = "okay"; | ||
| 45 | clock-frequency = <400000>; | 43 | clock-frequency = <400000>; |
| 46 | 44 | ||
| 47 | nfcmrvli2c0: i2c@1 { | 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 | &i2c2 { | 18 | &i2c2 { |
| 19 | 19 | ||
| 20 | status = "okay"; | ||
| 21 | 20 | ||
| 22 | npc100: npc100@29 { | 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 | &i2c2 { | 16 | &i2c2 { |
| 17 | 17 | ||
| 18 | status = "okay"; | ||
| 19 | 18 | ||
| 20 | pn532: pn532@24 { | 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 | &i2c2 { | 18 | &i2c2 { |
| 19 | 19 | ||
| 20 | status = "okay"; | ||
| 21 | 20 | ||
| 22 | pn544: pn544@28 { | 21 | pn544: pn544@28 { |
| 23 | 22 | ||
| @@ -12,7 +12,6 @@ Required properties: · 11 unmodified lines | |||
| 12 | Example: | 12 | Example: |
| 13 | 13 | ||
| 14 | &hsi2c_4 { | 14 | &hsi2c_4 { |
| 15 | status = "okay"; | ||
| 16 | s3fwrn5@27 { | 15 | s3fwrn5@27 { |
| 17 | compatible = "samsung,s3fwrn5-i2c"; | 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 | &i2c2 { | 21 | &i2c2 { |
| 22 | 22 | ||
| 23 | status = "okay"; | ||
| 24 | 23 | ||
| 25 | st21nfcb: st21nfcb@8 { | 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 | &mcspi4 { | 20 | &mcspi4 { |
| 21 | 21 | ||
| 22 | status = "okay"; | ||
| 23 | 22 | ||
| 24 | st21nfcb: st21nfcb@0 { | 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 | &i2c2 { | 21 | &i2c2 { |
| 22 | 22 | ||
| 23 | status = "okay"; | ||
| 24 | 23 | ||
| 25 | st21nfca: st21nfca@1 { | 24 | st21nfca: st21nfca@1 { |
| 26 | 25 | ||
| @@ -35,12 +35,10 @@ spi@9840000 { · 34 unmodified lines | |||
| 35 | #address-cells = <1>; | 35 | #address-cells = <1>; |
| 36 | #size-cells = <0>; | 36 | #size-cells = <0>; |
| 37 | cs-gpios = <&pio0 4>; | 37 | cs-gpios = <&pio0 4>; |
| 38 | status = "okay"; | ||
| 39 | 38 | ||
| 40 | st95hf@0{ | 39 | st95hf@0{ |
| 41 | reg = <0>; | 40 | reg = <0>; |
| 42 | compatible = "st,st95hf"; | 41 | compatible = "st,st95hf"; |
| 43 | status = "okay"; | ||
| 44 | spi-max-frequency = <1000000>; | 42 | spi-max-frequency = <1000000>; |
| 45 | enable-gpio = <&pio4 0>; | 43 | enable-gpio = <&pio4 0>; |
| 46 | interrupt-parent = <&pio0>; | 44 | interrupt-parent = <&pio0>; |
| @@ -23,7 +23,6 @@ Optional SoC Specific Properties: · 22 unmodified lines | |||
| 23 | Example (for ARM-based BeagleBone with TRF7970A on SPI1): | 23 | Example (for ARM-based BeagleBone with TRF7970A on SPI1): |
| 24 | 24 | ||
| 25 | &spi1 { | 25 | &spi1 { |
| 26 | status = "okay"; | ||
| 27 | 26 | ||
| 28 | nfc@0 { | 27 | nfc@0 { |
| 29 | compatible = "ti,trf7970a"; | 28 | compatible = "ti,trf7970a"; |
| @@ -41,6 +40,5 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1): · 11 unmodified lines | |||
| 41 | irq-status-read-quirk; | 40 | irq-status-read-quirk; |
| 42 | en2-rf-quirk; | 41 | en2-rf-quirk; |
| 43 | clock-frequency = <27120000>; | 42 | clock-frequency = <27120000>; |
| 44 | status = "okay"; | ||
| 45 | }; | 43 | }; |
| 46 | }; | 44 | }; |
| @@ -35,5 +35,4 @@ etha: ethernet@40400000 { · 34 unmodified lines | |||
| 35 | /* Regmap for sys registers */ | 35 | /* Regmap for sys registers */ |
| 36 | oxsemi,sys-ctrl = <&sys>; | 36 | oxsemi,sys-ctrl = <&sys>; |
| 37 | 37 | ||
| 38 | status = "disabled"; | ||
| 39 | }; | 38 | }; |
| @@ -2,11 +2,7 @@ PHY nodes · 1 unmodified line | |||
| 2 | 2 | ||
| 3 | Required properties: | 3 | Required properties: |
| 4 | 4 | ||
| 5 | - interrupts : <a b> where a is the interrupt number and b is a | 5 | - interrupts : interrupt specifier for the sole interrupt. |
| 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. | ||
| 10 | - interrupt-parent : the phandle for the interrupt controller that | 6 | - interrupt-parent : the phandle for the interrupt controller that |
| 11 | services interrupts for this device. | 7 | services interrupts for this device. |
| 12 | - reg : The ID number for the phy, usually a small integer | 8 | - reg : The ID number for the phy, usually a small integer |
| @@ -52,11 +48,16 @@ Optional Properties: · 39 unmodified lines | |||
| 52 | Mark the corresponding energy efficient ethernet mode as broken and | 48 | Mark the corresponding energy efficient ethernet mode as broken and |
| 53 | request the ethernet to stop advertising it. | 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 | Example: | 56 | Example: |
| 56 | 57 | ||
| 57 | ethernet-phy@0 { | 58 | ethernet-phy@0 { |
| 58 | compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22"; | 59 | compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22"; |
| 59 | interrupt-parent = <40000>; | 60 | interrupt-parent = <&PIC>; |
| 60 | interrupts = <35 1>; | 61 | interrupts = <35 IRQ_TYPE_EDGE_RISING>; |
| 61 | reg = <0>; | 62 | reg = <0>; |
| 62 | }; | 63 | }; |
| @@ -41,7 +41,6 @@ ssp2: spi@80014000 { · 40 unmodified lines | |||
| 41 | compatible = "fsl,imx28-spi"; | 41 | compatible = "fsl,imx28-spi"; |
| 42 | pinctrl-names = "default"; | 42 | pinctrl-names = "default"; |
| 43 | pinctrl-0 = <&spi2_pins_a>; | 43 | pinctrl-0 = <&spi2_pins_a>; |
| 44 | status = "okay"; | ||
| 45 | 44 | ||
| 46 | qca7000: ethernet@0 { | 45 | qca7000: ethernet@0 { |
| 47 | compatible = "qca,qca7000"; | 46 | compatible = "qca,qca7000"; |
| @@ -78,7 +77,6 @@ auart0: serial@8006a000 { · 30 unmodified lines | |||
| 78 | reg = <0x8006a000 0x2000>; | 77 | reg = <0x8006a000 0x2000>; |
| 79 | pinctrl-names = "default"; | 78 | pinctrl-names = "default"; |
| 80 | pinctrl-0 = <&auart0_2pins_a>; | 79 | pinctrl-0 = <&auart0_2pins_a>; |
| 81 | status = "okay"; | ||
| 82 | 80 | ||
| 83 | qca7000: ethernet { | 81 | qca7000: ethernet { |
| 84 | compatible = "qca,qca7000"; | 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 | interface contains. | 4 | interface contains. |
| 5 | 5 | ||
| 6 | Required properties: | 6 | Required properties: |
| 7 | - compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC. | 7 | - compatible: Must contain one or more of the following: |
| 8 | "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC. | 8 | - "renesas,etheravb-r8a7743" for the R8A7743 SoC. |
| 9 | "renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC. | 9 | - "renesas,etheravb-r8a7745" for the R8A7745 SoC. |
| 10 | "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC. | 10 | - "renesas,etheravb-r8a7790" for the R8A7790 SoC. |
| 11 | "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. | 11 | - "renesas,etheravb-r8a7791" for the R8A7791 SoC. |
| 12 | "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC. | 12 | - "renesas,etheravb-r8a7792" for the R8A7792 SoC. |
| 13 | "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC. | 13 | - "renesas,etheravb-r8a7793" for the R8A7793 SoC. |
| 14 | "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible interface. | 14 | - "renesas,etheravb-r8a7794" for the R8A7794 SoC. |
| 15 | "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible interface. | 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 | - "renesas,etheravb-r8a7795" for the R8A7795 SoC. |
| 18 | SoC-specific version corresponding to the platform first | 19 | - "renesas,etheravb-r8a7796" for the R8A7796 SoC. |
| 19 | followed by the generic version. | 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 | - reg: offset and length of (1) the register block and (2) the stream buffer. | 27 | - reg: offset and length of (1) the register block and (2) the stream buffer. |
| 22 | - interrupts: A list of interrupt-specifiers, one for each entry in | 28 | - interrupts: A list of interrupt-specifiers, one for each entry in |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | |||
| 10 | "rockchip,rk3366-gmac": found on RK3366 SoCs | 10 | "rockchip,rk3366-gmac": found on RK3366 SoCs |
| 11 | "rockchip,rk3368-gmac": found on RK3368 SoCs | 11 | "rockchip,rk3368-gmac": found on RK3368 SoCs |
| 12 | "rockchip,rk3399-gmac": found on RK3399 SoCs | 12 | "rockchip,rk3399-gmac": found on RK3399 SoCs |
| 13 | "rockchip,rv1108-gmac": found on RV1108 SoCs | ||
| 13 | - reg: addresses and length of the register sets for the device. | 14 | - reg: addresses and length of the register sets for the device. |
| 14 | - interrupts: Should contain the GMAC interrupts. | 15 | - interrupts: Should contain the GMAC interrupts. |
| 15 | - interrupt-names: Should contain the interrupt names "macirq". | 16 | - interrupt-names: Should contain the interrupt names "macirq". |
| @@ -70,5 +71,4 @@ gmac: ethernet@ff290000 { · 54 unmodified lines | |||
| 70 | tx_delay = <0x30>; | 71 | tx_delay = <0x30>; |
| 71 | rx_delay = <0x10>; | 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 | pinctrl-names = "default", "sleep"; | 15 | pinctrl-names = "default", "sleep"; |
| 16 | pinctrl-0 = <&davinci_mdio_default>; | 16 | pinctrl-0 = <&davinci_mdio_default>; |
| 17 | pinctrl-1 = <&davinci_mdio_sleep>; | 17 | pinctrl-1 = <&davinci_mdio_sleep>; |
| 18 | status = "okay"; | ||
| 19 | 18 | ||
| 20 | ethernetphy0: ethernet-phy@0 { | 19 | ethernetphy0: ethernet-phy@0 { |
| 21 | reg = <0>; | 20 | reg = <0>; |
| @@ -40,7 +40,6 @@ gmii_to_sgmii_converter: phy@0x100000240 { · 39 unmodified lines | |||
| 40 | gmac0: ethernet@ff700000 { | 40 | gmac0: ethernet@ff700000 { |
| 41 | compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac"; | 41 | compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac"; |
| 42 | altr,sysmgr-syscon = <&sysmgr 0x60 0>; | 42 | altr,sysmgr-syscon = <&sysmgr 0x60 0>; |
| 43 | status = "disabled"; | ||
| 44 | reg = <0xff700000 0x2000>; | 43 | reg = <0xff700000 0x2000>; |
| 45 | interrupts = <0 115 4>; | 44 | interrupts = <0 115 4>; |
| 46 | interrupt-names = "macirq"; | 45 | interrupt-names = "macirq"; |
| @@ -34,7 +34,6 @@ Example: · 33 unmodified lines | |||
| 34 | 34 | ||
| 35 | ethernet0: dwmac@9630000 { | 35 | ethernet0: dwmac@9630000 { |
| 36 | device_type = "network"; | 36 | device_type = "network"; |
| 37 | status = "disabled"; | ||
| 38 | compatible = "st,stih407-dwmac", "snps,dwmac", "snps,dwmac-3.710"; | 37 | compatible = "st,stih407-dwmac", "snps,dwmac", "snps,dwmac-3.710"; |
| 39 | reg = <0x9630000 0x8000>; | 38 | reg = <0x9630000 0x8000>; |
| 40 | reg-names = "stmmaceth"; | 39 | reg-names = "stmmaceth"; |
| @@ -18,7 +18,6 @@ Example: · 17 unmodified lines | |||
| 18 | 18 | ||
| 19 | ethernet@40028000 { | 19 | ethernet@40028000 { |
| 20 | compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; | 20 | compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; |
| 21 | status = "disabled"; | ||
| 22 | reg = <0x40028000 0x8000>; | 21 | reg = <0x40028000 0x8000>; |
| 23 | reg-names = "stmmaceth"; | 22 | reg-names = "stmmaceth"; |
| 24 | interrupts = <0 61 0>, <0 62 0>; | 23 | interrupts = <0 61 0>, <0 62 0>; |
| @@ -29,7 +29,6 @@ mmc3: mmc@01c12000 { · 28 unmodified lines | |||
| 29 | vmmc-supply = <®_vmmc3>; | 29 | vmmc-supply = <®_vmmc3>; |
| 30 | bus-width = <4>; | 30 | bus-width = <4>; |
| 31 | non-removable; | 31 | non-removable; |
| 32 | status = "okay"; | ||
| 33 | 32 | ||
| 34 | brcmf: wifi@1 { | 33 | brcmf: wifi@1 { |
| 35 | reg = <1>; | 34 | reg = <1>; |
| @@ -21,7 +21,6 @@ Example: · 20 unmodified lines | |||
| 21 | mmc-pwrseq = <&wifi_pwrseq>; | 21 | mmc-pwrseq = <&wifi_pwrseq>; |
| 22 | bus-width = <4>; | 22 | bus-width = <4>; |
| 23 | non-removable; | 23 | non-removable; |
| 24 | status = "okay"; | ||
| 25 | 24 | ||
| 26 | esp8089: sdio_wifi@1 { | 25 | esp8089: sdio_wifi@1 { |
| 27 | compatible = "esp,esp8089"; | 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 | so that firmware can wakeup host using this device side pin. | 48 | so that firmware can wakeup host using this device side pin. |
| 49 | 49 | ||
| 50 | &mmc3 { | 50 | &mmc3 { |
| 51 | status = "okay"; | ||
| 52 | vmmc-supply = <&wlan_en_reg>; | 51 | vmmc-supply = <&wlan_en_reg>; |
| 53 | mmc-pwrseq = <&wifi_pwrseq>; | 52 | mmc-pwrseq = <&wifi_pwrseq>; |
| 54 | bus-width = <4>; | 53 | bus-width = <4>; |
| @@ -31,7 +31,6 @@ clock, new bindings (for parsing the clock nodes) have to be added. · 30 unmodified lines | |||
| 31 | Example: | 31 | Example: |
| 32 | 32 | ||
| 33 | &mmc3 { | 33 | &mmc3 { |
| 34 | status = "okay"; | ||
| 35 | vmmc-supply = <&wlan_en_reg>; | 34 | vmmc-supply = <&wlan_en_reg>; |
| 36 | bus-width = <4>; | 35 | bus-width = <4>; |
| 37 | cap-power-off-card; | 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 | This binding is intended to represent MTK-EFUSE which is found in most Mediatek SOCs. | 3 | This binding is intended to represent MTK-EFUSE which is found in most Mediatek SOCs. |
| 4 | 4 | ||
| 5 | Required properties: | 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 | - reg: Should contain registers location and length | 10 | - reg: Should contain registers location and length |
| 8 | 11 | ||
| 9 | = Data cells = | 12 | = Data cells = |
| @@ -21,5 +21,4 @@ Example for i.MX28: · 20 unmodified lines | |||
| 21 | #size-cells = <1>; | 21 | #size-cells = <1>; |
| 22 | reg = <0x8002c000 0x2000>; | 22 | reg = <0x8002c000 0x2000>; |
| 23 | clocks = <&clks 25>; | 23 | clocks = <&clks 25>; |
| 24 | status = "okay"; | ||
| 25 | }; | 24 | }; |
| @@ -464,7 +464,6 @@ Example 5: opp-supported-hw · 463 unmodified lines | |||
| 464 | 464 | ||
| 465 | opp_table { | 465 | opp_table { |
| 466 | compatible = "operating-points-v2"; | 466 | compatible = "operating-points-v2"; |
| 467 | status = "okay"; | ||
| 468 | opp-shared; | 467 | opp-shared; |
| 469 | 468 | ||
| 470 | opp-600000000 { | 469 | opp-600000000 { |
| @@ -1,11 +1,11 @@ | |||
| 1 | * Freescale 83xx and 512x PCI bridges | 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 | 83xx/512x specific notes: | 5 | 83xx/512x specific notes: |
| 6 | - reg: should contain two address length tuples | 6 | - reg: should contain two address length tuples |
| 7 | The first is for the internal pci bridge registers | 7 | The first is for the internal PCI bridge registers |
| 8 | The second is for the pci config space access registers | 8 | The second is for the PCI config space access registers |
| 9 | 9 | ||
| 10 | Example (MPC8313ERDB) | 10 | Example (MPC8313ERDB) |
| 11 | pci0: pci@e0008500 { | 11 | pci0: pci@e0008500 { |
| @@ -33,7 +33,6 @@ Example: · 32 unmodified lines | |||
| 33 | pcie0: pcie@d0070000 { | 33 | pcie0: pcie@d0070000 { |
| 34 | compatible = "marvell,armada-3700-pcie"; | 34 | compatible = "marvell,armada-3700-pcie"; |
| 35 | device_type = "pci"; | 35 | device_type = "pci"; |
| 36 | status = "disabled"; | ||
| 37 | reg = <0 0xd0070000 0 0x20000>; | 36 | reg = <0 0xd0070000 0 0x20000>; |
| 38 | #address-cells = <3>; | 37 | #address-cells = <3>; |
| 39 | #size-cells = <2>; | 38 | #size-cells = <2>; |
| @@ -7,21 +7,21 @@ Required properties: · 6 unmodified lines | |||
| 7 | "Txs": TX slave port region | 7 | "Txs": TX slave port region |
| 8 | "Cra": Control register access region | 8 | "Cra": Control register access region |
| 9 | - interrupt-parent: interrupt source phandle. | 9 | - interrupt-parent: interrupt source phandle. |
| 10 | - interrupts: specifies the interrupt source of the parent interrupt controller. | 10 | - interrupts: specifies the interrupt source of the parent interrupt |
| 11 | The format of the interrupt specifier depends on the parent interrupt | 11 | controller. The format of the interrupt specifier depends |
| 12 | controller. | 12 | on the parent interrupt controller. |
| 13 | - device_type: must be "pci" | 13 | - device_type: must be "pci" |
| 14 | - #address-cells: set to <3> | 14 | - #address-cells: set to <3> |
| 15 | - #size-cells: set to <2> | 15 | - #size-cells: set to <2> |
| 16 | - #interrupt-cells: set to <1> | 16 | - #interrupt-cells: set to <1> |
| 17 | - ranges: describes the translation of addresses for root ports and standard | 17 | - ranges: describes the translation of addresses for root ports and |
| 18 | PCI regions. | 18 | standard PCI regions. |
| 19 | - interrupt-map-mask and interrupt-map: standard PCI properties to define the | 19 | - interrupt-map-mask and interrupt-map: standard PCI properties to define the |
| 20 | mapping of the PCIe interface to interrupt numbers. | 20 | mapping of the PCIe interface to interrupt numbers. |
| 21 | 21 | ||
| 22 | Optional properties: | 22 | Optional properties: |
| 23 | - msi-parent: Link to the hardware entity that serves as the MSI controller for this PCIe | 23 | - msi-parent: Link to the hardware entity that serves as the MSI controller |
| 24 | controller. | 24 | for this PCIe controller. |
| 25 | - bus-range: PCI bus numbers covered | 25 | - bus-range: PCI bus numbers covered |
| 26 | 26 | ||
| 27 | Example | 27 | Example |
| @@ -45,5 +45,5 @@ Example · 17 unmodified lines | |||
| 45 | <0 0 0 3 &pcie_0 3>, | 45 | <0 0 0 3 &pcie_0 3>, |
| 46 | <0 0 0 4 &pcie_0 4>; | 46 | <0 0 0 4 &pcie_0 4>; |
| 47 | ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000 | 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 | Required properties: | 6 | Required properties: |
| 7 | - compatible: "axis,artpec6-pcie", "snps,dw-pcie" | 7 | - compatible: "axis,artpec6-pcie", "snps,dw-pcie" |
| 8 | - reg: base addresses and lengths of the PCIe controller (DBI), | 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 | - reg-names: Must include the following entries: | 10 | - reg-names: Must include the following entries: |
| 11 | - "dbi" | 11 | - "dbi" |
| 12 | - "phy" | 12 | - "phy" |
| @@ -1,4 +1,4 @@ | |||
| 1 | * Synopsys Designware PCIe interface | 1 | * Synopsys DesignWare PCIe interface |
| 2 | 2 | ||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: should contain "snps,dw-pcie" to identify the core. | 4 | - compatible: should contain "snps,dw-pcie" to identify the core. |
| @@ -17,29 +17,27 @@ RC mode: · 12 unmodified lines | |||
| 17 | properties to define the mapping of the PCIe interface to interrupt | 17 | properties to define the mapping of the PCIe interface to interrupt |
| 18 | numbers. | 18 | numbers. |
| 19 | EP mode: | 19 | EP mode: |
| 20 | - num-ib-windows: number of inbound address translation | 20 | - num-ib-windows: number of inbound address translation windows |
| 21 | windows | 21 | - num-ob-windows: number of outbound address translation windows |
| 22 | - num-ob-windows: number of outbound address translation | ||
| 23 | windows | ||
| 24 | 22 | ||
| 25 | Optional properties: | 23 | Optional properties: |
| 26 | - num-lanes: number of lanes to use (this property should be specified unless | 24 | - num-lanes: number of lanes to use (this property should be specified unless |
| 27 | the link is brought already up in BIOS) | 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 | - clocks: Must contain an entry for each entry in clock-names. | 27 | - clocks: Must contain an entry for each entry in clock-names. |
| 30 | See ../clocks/clock-bindings.txt for details. | 28 | See ../clocks/clock-bindings.txt for details. |
| 31 | - clock-names: Must include the following entries: | 29 | - clock-names: Must include the following entries: |
| 32 | - "pcie" | 30 | - "pcie" |
| 33 | - "pcie_bus" | 31 | - "pcie_bus" |
| 34 | RC mode: | 32 | RC mode: |
| 35 | - num-viewport: number of view ports configured in | 33 | - num-viewport: number of view ports configured in hardware. If a platform |
| 36 | hardware. If a platform does not specify it, the driver assumes 2. | 34 | does not specify it, the driver assumes 2. |
| 37 | - bus-range: PCI bus numbers covered (it is recommended | 35 | - bus-range: PCI bus numbers covered (it is recommended for new devicetrees |
| 38 | for new devicetrees to specify this property, to keep backwards | 36 | to specify this property, to keep backwards compatibility a range of |
| 39 | compatibility a range of 0x00-0xff is assumed if not present) | 37 | 0x00-0xff is assumed if not present) |
| 38 | |||
| 40 | EP mode: | 39 | EP mode: |
| 41 | - max-functions: maximum number of functions that can be | 40 | - max-functions: maximum number of functions that can be configured |
| 42 | configured | ||
| 43 | 41 | ||
| 44 | Example configuration: | 42 | Example configuration: |
| 45 | 43 | ||
| @@ -1,6 +1,6 @@ | |||
| 1 | * Freescale i.MX6 PCIe interface | 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 | and thus inherits all the common properties defined in designware-pcie.txt. | 4 | and thus inherits all the common properties defined in designware-pcie.txt. |
| 5 | 5 | ||
| 6 | Required properties: | 6 | Required properties: |
| @@ -1,7 +1,7 @@ | |||
| 1 | HiSilicon Hip05 and Hip06 PCIe host bridge DT description | 1 | HiSilicon Hip05 and Hip06 PCIe host bridge DT description |
| 2 | 2 | ||
| 3 | HiSilicon PCIe host controller is based on Designware PCI core. | 3 | HiSilicon PCIe host controller is based on the Synopsys DesignWare PCI core. |
| 4 | It shares common functions with PCIe Designware core driver and inherits | 4 | It shares common functions with the PCIe DesignWare core driver and inherits |
| 5 | common properties defined in | 5 | common properties defined in |
| 6 | Documentation/devicetree/bindings/pci/designware-pci.txt. | 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 | 0x0 0 0 2 &mbigen_pcie 2 11 | 40 | 0x0 0 0 2 &mbigen_pcie 2 11 |
| 41 | 0x0 0 0 3 &mbigen_pcie 3 12 | 41 | 0x0 0 0 3 &mbigen_pcie 3 12 |
| 42 | 0x0 0 0 4 &mbigen_pcie 4 13>; | 42 | 0x0 0 0 4 &mbigen_pcie 4 13>; |
| 43 | status = "ok"; | ||
| 44 | }; | 43 | }; |
| 45 | 44 | ||
| 46 | HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description. | 45 | HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description. |
| @@ -83,5 +82,4 @@ Example: · 36 unmodified lines | |||
| 83 | 0x0 0 0 2 &mbigen_pcie0 650 4 | 82 | 0x0 0 0 2 &mbigen_pcie0 650 4 |
| 84 | 0x0 0 0 3 &mbigen_pcie0 650 4 | 83 | 0x0 0 0 3 &mbigen_pcie0 650 4 |
| 85 | 0x0 0 0 4 &mbigen_pcie0 650 4>; | 84 | 0x0 0 0 4 &mbigen_pcie0 650 4>; |
| 86 | status = "ok"; | ||
| 87 | }; | 85 | }; |
| @@ -1,8 +1,8 @@ | |||
| 1 | HiSilicon Kirin SoCs PCIe host DT description | 1 | HiSilicon Kirin SoCs PCIe host DT description |
| 2 | 2 | ||
| 3 | Kirin PCIe host controller is based on Designware PCI core. | 3 | Kirin PCIe host controller is based on the Synopsys DesignWare PCI core. |
| 4 | It shares common functions with PCIe Designware core driver | 4 | It shares common functions with the PCIe DesignWare core driver and |
| 5 | and inherits common properties defined in | 5 | inherits common properties defined in |
| 6 | Documentation/devicetree/bindings/pci/designware-pci.txt. | 6 | Documentation/devicetree/bindings/pci/designware-pci.txt. |
| 7 | 7 | ||
| 8 | Additional properties are described here: | 8 | Additional properties are described here: |
| @@ -16,7 +16,7 @@ Required properties · 7 unmodified lines | |||
| 16 | "apb": apb Ctrl register defined by Kirin; | 16 | "apb": apb Ctrl register defined by Kirin; |
| 17 | "phy": apb PHY register defined by Kirin; | 17 | "phy": apb PHY register defined by Kirin; |
| 18 | "config": PCIe configuration space registers. | 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 | Optional properties: | 21 | Optional properties: |
| 22 | 22 | ||
| @@ -15,8 +15,10 @@ Required properties: · 14 unmodified lines | |||
| 15 | - compatible: should contain the platform identifier such as: | 15 | - compatible: should contain the platform identifier such as: |
| 16 | "fsl,ls1021a-pcie", "snps,dw-pcie" | 16 | "fsl,ls1021a-pcie", "snps,dw-pcie" |
| 17 | "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie" | 17 | "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie" |
| 18 | "fsl,ls2088a-pcie" | ||
| 19 | "fsl,ls1088a-pcie" | ||
| 18 | "fsl,ls1046a-pcie" | 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 | - interrupts: A list of interrupt outputs of the controller. Must contain an | 22 | - interrupts: A list of interrupt outputs of the controller. Must contain an |
| 21 | entry for each entry in the interrupt-names property. | 23 | entry for each entry in the interrupt-names property. |
| 22 | - interrupt-names: Must include the following entries: | 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 | - marvell,pcie-lane: the physical PCIe lane number, for ports having | 77 | - marvell,pcie-lane: the physical PCIe lane number, for ports having |
| 78 | multiple lanes. If this property is not found, we assume that the | 78 | multiple lanes. If this property is not found, we assume that the |
| 79 | value is 0. | 79 | value is 0. |
| 80 | - reset-gpios: optional gpio to PERST# | 80 | - reset-gpios: optional GPIO to PERST# |
| 81 | - reset-delay-us: delay in us to wait after reset de-assertion, if not | 81 | - reset-delay-us: delay in us to wait after reset de-assertion, if not |
| 82 | specified will default to 100ms, as required by the PCIe specification. | 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 | pcie-controller { | 86 | pcie-controller { |
| 87 | compatible = "marvell,armada-xp-pcie"; | 87 | compatible = "marvell,armada-xp-pcie"; |
| 88 | status = "disabled"; | ||
| 89 | device_type = "pci"; | 88 | device_type = "pci"; |
| 90 | 89 | ||
| 91 | #address-cells = <3>; | 90 | #address-cells = <3>; |
| @@ -147,7 +146,6 @@ pcie-controller { · 55 unmodified lines | |||
| 147 | /* wait 20ms for device settle after reset deassertion */ | 146 | /* wait 20ms for device settle after reset deassertion */ |
| 148 | reset-delay-us = <20000>; | 147 | reset-delay-us = <20000>; |
| 149 | clocks = <&gateclk 5>; | 148 | clocks = <&gateclk 5>; |
| 150 | status = "disabled"; | ||
| 151 | }; | 149 | }; |
| 152 | 150 | ||
| 153 | pcie@2,0 { | 151 | pcie@2,0 { |
| @@ -164,7 +162,6 @@ pcie-controller { · 10 unmodified lines | |||
| 164 | marvell,pcie-port = <0>; | 162 | marvell,pcie-port = <0>; |
| 165 | marvell,pcie-lane = <1>; | 163 | marvell,pcie-lane = <1>; |
| 166 | clocks = <&gateclk 6>; | 164 | clocks = <&gateclk 6>; |
| 167 | status = "disabled"; | ||
| 168 | }; | 165 | }; |
| 169 | 166 | ||
| 170 | pcie@3,0 { | 167 | pcie@3,0 { |
| @@ -181,7 +178,6 @@ pcie-controller { · 10 unmodified lines | |||
| 181 | marvell,pcie-port = <0>; | 178 | marvell,pcie-port = <0>; |
| 182 | marvell,pcie-lane = <2>; | 179 | marvell,pcie-lane = <2>; |
| 183 | clocks = <&gateclk 7>; | 180 | clocks = <&gateclk 7>; |
| 184 | status = "disabled"; | ||
| 185 | }; | 181 | }; |
| 186 | 182 | ||
| 187 | pcie@4,0 { | 183 | pcie@4,0 { |
| @@ -198,7 +194,6 @@ pcie-controller { · 10 unmodified lines | |||
| 198 | marvell,pcie-port = <0>; | 194 | marvell,pcie-port = <0>; |
| 199 | marvell,pcie-lane = <3>; | 195 | marvell,pcie-lane = <3>; |
| 200 | clocks = <&gateclk 8>; | 196 | clocks = <&gateclk 8>; |
| 201 | status = "disabled"; | ||
| 202 | }; | 197 | }; |
| 203 | 198 | ||
| 204 | pcie@5,0 { | 199 | pcie@5,0 { |
| @@ -215,7 +210,6 @@ pcie-controller { · 10 unmodified lines | |||
| 215 | marvell,pcie-port = <1>; | 210 | marvell,pcie-port = <1>; |
| 216 | marvell,pcie-lane = <0>; | 211 | marvell,pcie-lane = <0>; |
| 217 | clocks = <&gateclk 9>; | 212 | clocks = <&gateclk 9>; |
| 218 | status = "disabled"; | ||
| 219 | }; | 213 | }; |
| 220 | 214 | ||
| 221 | pcie@6,0 { | 215 | pcie@6,0 { |
| @@ -232,7 +226,6 @@ pcie-controller { · 10 unmodified lines | |||
| 232 | marvell,pcie-port = <1>; | 226 | marvell,pcie-port = <1>; |
| 233 | marvell,pcie-lane = <1>; | 227 | marvell,pcie-lane = <1>; |
| 234 | clocks = <&gateclk 10>; | 228 | clocks = <&gateclk 10>; |
| 235 | status = "disabled"; | ||
| 236 | }; | 229 | }; |
| 237 | 230 | ||
| 238 | pcie@7,0 { | 231 | pcie@7,0 { |
| @@ -249,7 +242,6 @@ pcie-controller { · 10 unmodified lines | |||
| 249 | marvell,pcie-port = <1>; | 242 | marvell,pcie-port = <1>; |
| 250 | marvell,pcie-lane = <2>; | 243 | marvell,pcie-lane = <2>; |
| 251 | clocks = <&gateclk 11>; | 244 | clocks = <&gateclk 11>; |
| 252 | status = "disabled"; | ||
| 253 | }; | 245 | }; |
| 254 | 246 | ||
| 255 | pcie@8,0 { | 247 | pcie@8,0 { |
| @@ -266,7 +258,6 @@ pcie-controller { · 10 unmodified lines | |||
| 266 | marvell,pcie-port = <1>; | 258 | marvell,pcie-port = <1>; |
| 267 | marvell,pcie-lane = <3>; | 259 | marvell,pcie-lane = <3>; |
| 268 | clocks = <&gateclk 12>; | 260 | clocks = <&gateclk 12>; |
| 269 | status = "disabled"; | ||
| 270 | }; | 261 | }; |
| 271 | 262 | ||
| 272 | pcie@9,0 { | 263 | pcie@9,0 { |
| @@ -283,10 +274,9 @@ pcie-controller { · 10 unmodified lines | |||
| 283 | marvell,pcie-port = <2>; | 274 | marvell,pcie-port = <2>; |
| 284 | marvell,pcie-lane = <0>; | 275 | marvell,pcie-lane = <0>; |
| 285 | clocks = <&gateclk 26>; | 276 | clocks = <&gateclk 26>; |
| 286 | status = "disabled"; | ||
| 287 | }; | 277 | }; |
| 288 | 278 | ||
| 289 | pcie@10,0 { | 279 | pcie@a,0 { |
| 290 | device_type = "pci"; | 280 | device_type = "pci"; |
| 291 | assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; | 281 | assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; |
| 292 | reg = <0x5000 0 0 0 0>; | 282 | reg = <0x5000 0 0 0 0>; |
| @@ -300,6 +290,5 @@ pcie-controller { · 7 unmodified lines | |||
| 300 | marvell,pcie-port = <3>; | 290 | marvell,pcie-port = <3>; |
| 301 | marvell,pcie-lane = <0>; | 291 | marvell,pcie-lane = <0>; |
| 302 | clocks = <&gateclk 27>; | 292 | clocks = <&gateclk 27>; |
| 303 | status = "disabled"; | ||
| 304 | }; | 293 | }; |
| 305 | }; | 294 | }; |
| @@ -1,6 +1,6 @@ | |||
| 1 | * Marvell Armada 7K/8K PCIe interface | 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 | and thus inherits all the common properties defined in designware-pcie.txt. | 4 | and thus inherits all the common properties defined in designware-pcie.txt. |
| 5 | 5 | ||
| 6 | Required properties: | 6 | Required properties: |
| @@ -34,5 +34,4 @@ Example: · 27 unmodified lines | |||
| 34 | interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; | 34 | interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; |
| 35 | num-lanes = <1>; | 35 | num-lanes = <1>; |
| 36 | clocks = <&cpm_syscon0 1 13>; | 36 | clocks = <&cpm_syscon0 1 13>; |
| 37 | status = "disabled"; | ||
| 38 | }; | 37 | }; |
| @@ -1,12 +1,12 @@ | |||
| 1 | TI Keystone PCIe interface | 1 | TI Keystone PCIe interface |
| 2 | 2 | ||
| 3 | Keystone PCI host Controller is based on Designware PCI h/w version 3.65. | 3 | Keystone PCI host Controller is based on the Synopsys DesignWare PCI |
| 4 | It shares common functions with PCIe Designware core driver and inherit | 4 | hardware version 3.65. It shares common functions with the PCIe DesignWare |
| 5 | common properties defined in | 5 | core driver and inherits common properties defined in |
| 6 | Documentation/devicetree/bindings/pci/designware-pci.txt | 6 | Documentation/devicetree/bindings/pci/designware-pci.txt |
| 7 | 7 | ||
| 8 | Please refer to Documentation/devicetree/bindings/pci/designware-pci.txt | 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 | described here as well as properties that are not applicable. | 10 | described here as well as properties that are not applicable. |
| 11 | 11 | ||
| 12 | Required Properties:- | 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 | Optional properties:- | 54 | Optional properties:- |
| 55 | phys: phandle to Generic Keystone SerDes phy for PCI | 55 | phys: phandle to generic Keystone SerDes PHY for PCI |
| 56 | phy-names: name of the Generic Keystine SerDes phy for PCI | 56 | phy-names: name of the generic Keystone SerDes PHY for PCI |
| 57 | - If boot loader already does PCI link establishment, then phys and | 57 | - If boot loader already does PCI link establishment, then phys and |
| 58 | phy-names shouldn't be present. | 58 | phy-names shouldn't be present. |
| 59 | interrupts: platform interrupt for error interrupts. | 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 | 1. pcie_bus clock-names not used. Instead, a phandle to phys is used. | 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 | OHCI and EHCI controllers. | 6 | OHCI and EHCI controllers. |
| 7 | 7 | ||
| 8 | Required properties: | 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 | "renesas,pci-r8a7791" for the R8A7791 SoC; | 12 | "renesas,pci-r8a7791" for the R8A7791 SoC; |
| 11 | "renesas,pci-r8a7793" for the R8A7793 SoC; | 13 | "renesas,pci-r8a7793" for the R8A7793 SoC; |
| 12 | "renesas,pci-r8a7794" for the R8A7794 SoC; | 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 | When compatible with the generic version, nodes must list the | 19 | When compatible with the generic version, nodes must list the |
| @@ -1,12 +1,12 @@ | |||
| 1 | PCI bus bridges have standardized Device Tree bindings: | 1 | PCI bus bridges have standardized Device Tree bindings: |
| 2 | 2 | ||
| 3 | PCI Bus Binding to: IEEE Std 1275-1994 | 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 | And for the interrupt mapping part: | 6 | And for the interrupt mapping part: |
| 7 | 7 | ||
| 8 | Open Firmware Recommended Practice: Interrupt Mapping | 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 | Additionally to the properties specified in the above standards a host bridge | 11 | Additionally to the properties specified in the above standards a host bridge |
| 12 | driver implementation may support the following properties: | 12 | driver implementation may support the following properties: |
| @@ -9,6 +9,7 @@ · 8 unmodified lines | |||
| 9 | - "qcom,pcie-apq8084" for apq8084 | 9 | - "qcom,pcie-apq8084" for apq8084 |
| 10 | - "qcom,pcie-msm8996" for msm8996 or apq8096 | 10 | - "qcom,pcie-msm8996" for msm8996 or apq8096 |
| 11 | - "qcom,pcie-ipq4019" for ipq4019 | 11 | - "qcom,pcie-ipq4019" for ipq4019 |
| 12 | - "qcom,pcie-ipq8074" for ipq8074 | ||
| 12 | 13 | ||
| 13 | - reg: | 14 | - reg: |
| 14 | Usage: required | 15 | Usage: required |
| @@ -20,7 +21,7 @@ · 5 unmodified lines | |||
| 20 | Value type: <stringlist> | 21 | Value type: <stringlist> |
| 21 | Definition: Must include the following entries | 22 | Definition: Must include the following entries |
| 22 | - "parf" Qualcomm specific registers | 23 | - "parf" Qualcomm specific registers |
| 23 | - "dbi" Designware PCIe registers | 24 | - "dbi" DesignWare PCIe registers |
| 24 | - "elbi" External local bus interface registers | 25 | - "elbi" External local bus interface registers |
| 25 | - "config" PCIe configuration space | 26 | - "config" PCIe configuration space |
| 26 | 27 | ||
| @@ -105,6 +106,16 @@ · 78 unmodified lines | |||
| 105 | - "bus_master" Master AXI clock | 106 | - "bus_master" Master AXI clock |
| 106 | - "bus_slave" Slave AXI clock | 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 | - resets: | 119 | - resets: |
| 109 | Usage: required | 120 | Usage: required |
| 110 | Value type: <prop-encoded-array> | 121 | Value type: <prop-encoded-array> |
| @@ -144,6 +155,18 @@ · 33 unmodified lines | |||
| 144 | - "ahb" AHB reset | 155 | - "ahb" AHB reset |
| 145 | - "phy_ahb" PHY AHB reset | 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 | - power-domains: | 170 | - power-domains: |
| 148 | Usage: required for apq8084 and msm8996/apq8096 | 171 | Usage: required for apq8084 and msm8996/apq8096 |
| 149 | Value type: <prop-encoded-array> | 172 | Value type: <prop-encoded-array> |
| @@ -180,7 +203,7 @@ · 30 unmodified lines | |||
| 180 | - <name>-gpios: | 203 | - <name>-gpios: |
| 181 | Usage: optional | 204 | Usage: optional |
| 182 | Value type: <prop-encoded-array> | 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 | - "perst-gpios" PCIe endpoint reset signal line | 207 | - "perst-gpios" PCIe endpoint reset signal line |
| 185 | - "wake-gpios" PCIe endpoint wake signal line | 208 | - "wake-gpios" PCIe endpoint wake signal line |
| 186 | 209 | ||
| @@ -71,7 +71,7 @@ · 70 unmodified lines | |||
| 71 | - interrupt-map: standard PCI properties to define the mapping of the | 71 | - interrupt-map: standard PCI properties to define the mapping of the |
| 72 | PCI interface to interrupt numbers. | 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 | the onboard PCI devices/PCI slots. Each such sub-node must have the | 75 | the onboard PCI devices/PCI slots. Each such sub-node must have the |
| 76 | following mandatory properties: | 76 | following mandatory properties: |
| 77 | 77 | ||
| @@ -14,7 +14,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC; · 13 unmodified lines | |||
| 14 | SoC-specific version corresponding to the platform first | 14 | SoC-specific version corresponding to the platform first |
| 15 | followed by the generic version. | 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 | - #address-cells: set to <3> | 18 | - #address-cells: set to <3> |
| 19 | - #size-cells: set to <2> | 19 | - #size-cells: set to <2> |
| 20 | - bus-range: PCI bus numbers covered | 20 | - bus-range: PCI bus numbers covered |
| @@ -25,15 +25,14 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC; · 4 unmodified lines | |||
| 25 | source for hardware related interrupts (e.g. link speed change). | 25 | source for hardware related interrupts (e.g. link speed change). |
| 26 | - #interrupt-cells: set to <1> | 26 | - #interrupt-cells: set to <1> |
| 27 | - interrupt-map-mask and interrupt-map: standard PCI properties | 27 | - interrupt-map-mask and interrupt-map: standard PCI properties |
| 28 | to define the mapping of the PCIe interface to interrupt | 28 | to define the mapping of the PCIe interface to interrupt numbers. |
| 29 | numbers. | ||
| 30 | - clocks: from common clock binding: clock specifiers for the PCIe controller | 29 | - clocks: from common clock binding: clock specifiers for the PCIe controller |
| 31 | and PCIe bus clocks. | 30 | and PCIe bus clocks. |
| 32 | - clock-names: from common clock binding: should be "pcie" and "pcie_bus". | 31 | - clock-names: from common clock binding: should be "pcie" and "pcie_bus". |
| 33 | 32 | ||
| 34 | Example: | 33 | Example: |
| 35 | 34 | ||
| 36 | SoC specific DT Entry: | 35 | SoC-specific DT Entry: |
| 37 | 36 | ||
| 38 | pcie: pcie@fe000000 { | 37 | pcie: pcie@fe000000 { |
| 39 | compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2"; | 38 | compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2"; |
| @@ -54,5 +53,4 @@ SoC specific DT Entry: · 14 unmodified lines | |||
| 54 | interrupt-map = <0 0 0 0 &gic 0 116 4>; | 53 | interrupt-map = <0 0 0 0 &gic 0 116 4>; |
| 55 | clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; | 54 | clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; |
| 56 | clock-names = "pcie", "pcie_bus"; | 55 | clock-names = "pcie", "pcie_bus"; |
| 57 | status = "disabled"; | ||
| 58 | }; | 56 | }; |
| @@ -19,8 +19,6 @@ Required properties: · 18 unmodified lines | |||
| 19 | - "pm" | 19 | - "pm" |
| 20 | - msi-map: Maps a Requester ID to an MSI controller and associated | 20 | - msi-map: Maps a Requester ID to an MSI controller and associated |
| 21 | msi-specifier data. See ./pci-msi.txt | 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 | - interrupts: Three interrupt entries must be specified. | 22 | - interrupts: Three interrupt entries must be specified. |
| 25 | - interrupt-names: Must include the following names | 23 | - interrupt-names: Must include the following names |
| 26 | - "sys" | 24 | - "sys" |
| @@ -42,11 +40,24 @@ Required properties: · 15 unmodified lines | |||
| 42 | interrupt source. The value must be 1. | 40 | interrupt source. The value must be 1. |
| 43 | - interrupt-map-mask and interrupt-map: standard PCI properties | 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 | Optional Property: | 55 | Optional Property: |
| 46 | - aspm-no-l0s: RC won't support ASPM L0s. This property is needed if | 56 | - aspm-no-l0s: RC won't support ASPM L0s. This property is needed if |
| 47 | using 24MHz OSC for RC's PHY. | 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 | - num-lanes: number of lanes to use | 59 | - num-lanes: number of lanes to use |
| 60 | - vpcie12v-supply: The phandle to the 12v regulator to use for PCIe. | ||
| 50 | - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe. | 61 | - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe. |
| 51 | - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe. | 62 | - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe. |
| 52 | - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe. | 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 | <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>; | 106 | <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>; |
| 96 | reset-names = "core", "mgmt", "mgmt-sticky", "pipe", | 107 | reset-names = "core", "mgmt", "mgmt-sticky", "pipe", |
| 97 | "pm", "pclk", "aclk"; | 108 | "pm", "pclk", "aclk"; |
| 109 | /* deprecated legacy PHY model */ | ||
| 98 | phys = <&pcie_phy>; | 110 | phys = <&pcie_phy>; |
| 99 | phy-names = "pcie-phy"; | 111 | phy-names = "pcie-phy"; |
| 100 | pinctrl-names = "default"; | 112 | pinctrl-names = "default"; |
| @@ -111,3 +123,13 @@ pcie0: pcie@f8000000 { · 10 unmodified lines | |||
| 111 | #interrupt-cells = <1>; | 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 | * Samsung Exynos 5440 PCIe interface | 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 | and thus inherits all the common properties defined in designware-pcie.txt. | 4 | and thus inherits all the common properties defined in designware-pcie.txt. |
| 5 | 5 | ||
| 6 | Required properties: | 6 | Required properties: |
| 7 | - compatible: "samsung,exynos5440-pcie" | 7 | - compatible: "samsung,exynos5440-pcie" |
| 8 | - reg: base addresses and lengths of the pcie controller, | 8 | - reg: base addresses and lengths of the PCIe controller, |
| 9 | the phy controller, additional register for the phy controller. | 9 | the PHY controller, additional register for the PHY controller. |
| 10 | (Registers for the phy controller are DEPRECATED. | 10 | (Registers for the PHY controller are DEPRECATED. |
| 11 | Use the PHY framework.) | 11 | Use the PHY framework.) |
| 12 | - reg-names : First name should be set to "elbi". | 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 | from "ranges". | 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 | - interrupts: A list of interrupt outputs for level interrupt, | 16 | - interrupts: A list of interrupt outputs for level interrupt, |
| 17 | pulse interrupt, special interrupt. | 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 | Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt | 19 | Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt |
| 20 | 20 | ||
| 21 | Other common properties refer to | 21 | For other common properties, refer to |
| 22 | Documentation/devicetree/binding/pci/designware-pcie.txt | 22 | Documentation/devicetree/bindings/pci/designware-pcie.txt |
| 23 | 23 | ||
| 24 | Example: | 24 | Example: |
| 25 | 25 | ||
| 26 | SoC specific DT Entry: | 26 | SoC-specific DT Entry: |
| 27 | 27 | ||
| 28 | pcie@290000 { | 28 | pcie@290000 { |
| 29 | compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; | 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 | pcie@290000 { | 88 | pcie@290000 { |
| 89 | reset-gpio = <&pin_ctrl 5 0>; | 89 | reset-gpio = <&pin_ctrl 5 0>; |
| @@ -1,12 +1,12 @@ | |||
| 1 | SPEAr13XX PCIe DT detail: | 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 | controller. | 5 | controller. |
| 6 | 6 | ||
| 7 | Required properties: | 7 | Required properties: |
| 8 | - compatible : should be "st,spear1340-pcie", "snps,dw-pcie". | 8 | - compatible : should be "st,spear1340-pcie", "snps,dw-pcie". |
| 9 | - phys : phandle to phy node associated with pcie controller | 9 | - phys : phandle to PHY node associated with PCIe controller |
| 10 | - phy-names : must be "pcie-phy" | 10 | - phy-names : must be "pcie-phy" |
| 11 | - All other definitions as per generic PCI bindings | 11 | - All other definitions as per generic PCI bindings |
| 12 | 12 | ||
| @@ -1,6 +1,6 @@ | |||
| 1 | TI PCI Controllers | 1 | TI PCI Controllers |
| 2 | 2 | ||
| 3 | PCIe Designware Controller | 3 | PCIe DesignWare Controller |
| 4 | - compatible: Should be "ti,dra7-pcie" for RC | 4 | - compatible: Should be "ti,dra7-pcie" for RC |
| 5 | Should be "ti,dra7-pcie-ep" for EP | 5 | Should be "ti,dra7-pcie-ep" for EP |
| 6 | - phys : list of PHY specifiers (used by generic PHY framework) | 6 | - phys : list of PHY specifiers (used by generic PHY framework) |
| @@ -13,7 +13,7 @@ PCIe Designware Controller · 6 unmodified lines | |||
| 13 | HOST MODE | 13 | HOST MODE |
| 14 | ========= | 14 | ========= |
| 15 | - reg : Two register ranges as listed in the reg-names property | 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 | The second entry must be "rc-dbics" for the DesignWare PCIe | 17 | The second entry must be "rc-dbics" for the DesignWare PCIe |
| 18 | registers | 18 | registers |
| 19 | The third entry must be "config" for the PCIe configuration space | 19 | The third entry must be "config" for the PCIe configuration space |
| @@ -30,7 +30,7 @@ HOST MODE · 10 unmodified lines | |||
| 30 | DEVICE MODE | 30 | DEVICE MODE |
| 31 | =========== | 31 | =========== |
| 32 | - reg : Four register ranges as listed in the reg-names property | 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 | "ep_dbics" for the standard configuration registers as | 34 | "ep_dbics" for the standard configuration registers as |
| 35 | they are locally accessed within the DIF CS space | 35 | they are locally accessed within the DIF CS space |
| 36 | "ep_dbics2" for the standard configuration registers as | 36 | "ep_dbics2" for the standard configuration registers as |
| @@ -46,7 +46,7 @@ DEVICE MODE · 9 unmodified lines | |||
| 46 | access. | 46 | access. |
| 47 | 47 | ||
| 48 | Optional Property: | 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 | NOTE: Two DT nodes may be added for each PCI controller; one for host | 51 | NOTE: Two DT nodes may be added for each PCI controller; one for host |
| 52 | mode and another for device mode. So in order for PCI to | 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 | Required properties: | 5 | Required properties: |
| 6 | - compatible: should contain "arm,versatile-pci" to identify the Versatile PCI | 6 | - compatible: should contain "arm,versatile-pci" to identify the Versatile PCI |
| 7 | controller. | 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 | entries: | 9 | entries: |
| 10 | - Versatile-specific registers | 10 | - Versatile-specific registers |
| 11 | - Self Config space | 11 | - Self Config space |
| @@ -4,7 +4,7 @@ Required properties: · 3 unmodified lines | |||
| 4 | 4 | ||
| 5 | - compatible: should be "apm,xgene1-msi" to identify | 5 | - compatible: should be "apm,xgene1-msi" to identify |
| 6 | X-Gene v1 PCIe MSI controller block. | 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 | - reg: physical base address (0x79000000) and length (0x900000) for controller | 8 | - reg: physical base address (0x79000000) and length (0x900000) for controller |
| 9 | registers. These registers include the MSI termination address and data | 9 | registers. These registers include the MSI termination address and data |
| 10 | registers as well as the MSI interrupt status registers. | 10 | registers as well as the MSI interrupt status registers. |
| @@ -13,7 +13,8 @@ Required properties: · 2 unmodified lines | |||
| 13 | interrupt number 0x10 to 0x1f. | 13 | interrupt number 0x10 to 0x1f. |
| 14 | - interrupt-names: not required | 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 | Examples: | 19 | Examples: |
| 19 | 20 | ||
| @@ -44,7 +45,6 @@ SoC DTSI: · 24 unmodified lines | |||
| 44 | 45 | ||
| 45 | + PCIe controller node with msi-parent property pointing to MSI node: | 46 | + PCIe controller node with msi-parent property pointing to MSI node: |
| 46 | pcie0: pcie@1f2b0000 { | 47 | pcie0: pcie@1f2b0000 { |
| 47 | status = "disabled"; | ||
| 48 | device_type = "pci"; | 48 | device_type = "pci"; |
| 49 | compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie"; | 49 | compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie"; |
| 50 | #interrupt-cells = <1>; | 50 | #interrupt-cells = <1>; |
| @@ -8,7 +8,7 @@ Required properties: · 7 unmodified lines | |||
| 8 | property. | 8 | property. |
| 9 | - reg-names: Must include the following entries: | 9 | - reg-names: Must include the following entries: |
| 10 | "csr": controller configuration registers. | 10 | "csr": controller configuration registers. |
| 11 | "cfg": pcie configuration space registers. | 11 | "cfg": PCIe configuration space registers. |
| 12 | - #address-cells: set to <3> | 12 | - #address-cells: set to <3> |
| 13 | - #size-cells: set to <2> | 13 | - #size-cells: set to <2> |
| 14 | - ranges: ranges for the outbound memory, I/O regions. | 14 | - ranges: ranges for the outbound memory, I/O regions. |
| @@ -21,11 +21,11 @@ Required properties: · 6 unmodified lines | |||
| 21 | 21 | ||
| 22 | Optional properties: | 22 | Optional properties: |
| 23 | - status: Either "ok" or "disabled". | 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 | Example: | 26 | Example: |
| 27 | 27 | ||
| 28 | SoC specific DT Entry: | 28 | SoC-specific DT Entry: |
| 29 | 29 | ||
| 30 | pcie0: pcie@1f2b0000 { | 30 | pcie0: pcie@1f2b0000 { |
| 31 | status = "disabled"; | 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 | &pcie0 { | 55 | &pcie0 { |
| 56 | status = "ok"; | 56 | status = "ok"; |
| 57 | }; | 57 | }; |
| @@ -15,9 +15,9 @@ Required properties: · 14 unmodified lines | |||
| 15 | - device_type: must be "pci" | 15 | - device_type: must be "pci" |
| 16 | - interrupts: Should contain NWL PCIe interrupt | 16 | - interrupts: Should contain NWL PCIe interrupt |
| 17 | - interrupt-names: Must include the following entries: | 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 | "intx": interrupt asserted when a legacy interrupt is received | 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 | - interrupt-map-mask and interrupt-map: standard PCI properties to define the | 21 | - interrupt-map-mask and interrupt-map: standard PCI properties to define the |
| 22 | mapping of the PCI interface to interrupt numbers. | 22 | mapping of the PCI interface to interrupt numbers. |
| 23 | - ranges: ranges for the PCI memory regions (I/O space region is not | 23 | - ranges: ranges for the PCI memory regions (I/O space region is not |
| @@ -26,7 +26,8 @@ Required properties: · 2 unmodified lines | |||
| 26 | detailed explanation | 26 | detailed explanation |
| 27 | - msi-controller: indicates that this is MSI controller node | 27 | - msi-controller: indicates that this is MSI controller node |
| 28 | - msi-parent: MSI parent of the root complex itself | 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 | - interrupt-controller: identifies the node as an interrupt controller | 31 | - interrupt-controller: identifies the node as an interrupt controller |
| 31 | - #interrupt-cells: should be set to 1 | 32 | - #interrupt-cells: should be set to 1 |
| 32 | - #address-cells: specifies the number of cells needed to encode an | 33 | - #address-cells: specifies the number of cells needed to encode an |
| @@ -61,19 +61,16 @@ Example: · 60 unmodified lines | |||
| 61 | compatible = "apm,xgene-phy"; | 61 | compatible = "apm,xgene-phy"; |
| 62 | reg = <0x0 0x1f21a000 0x0 0x100>; | 62 | reg = <0x0 0x1f21a000 0x0 0x100>; |
| 63 | #phy-cells = <1>; | 63 | #phy-cells = <1>; |
| 64 | status = "disabled"; | ||
| 65 | }; | 64 | }; |
| 66 | 65 | ||
| 67 | phy2: phy@1f22a000 { | 66 | phy2: phy@1f22a000 { |
| 68 | compatible = "apm,xgene-phy"; | 67 | compatible = "apm,xgene-phy"; |
| 69 | reg = <0x0 0x1f22a000 0x0 0x100>; | 68 | reg = <0x0 0x1f22a000 0x0 0x100>; |
| 70 | #phy-cells = <1>; | 69 | #phy-cells = <1>; |
| 71 | status = "ok"; | ||
| 72 | }; | 70 | }; |
| 73 | 71 | ||
| 74 | phy3: phy@1f23a000 { | 72 | phy3: phy@1f23a000 { |
| 75 | compatible = "apm,xgene-phy"; | 73 | compatible = "apm,xgene-phy"; |
| 76 | reg = <0x0 0x1f23a000 0x0 0x100>; | 74 | reg = <0x0 0x1f23a000 0x0 0x100>; |
| 77 | #phy-cells = <1>; | 75 | #phy-cells = <1>; |
| 78 | status = "ok"; | ||
| 79 | }; | 76 | }; |
| @@ -16,5 +16,4 @@ usb_phy: usb_phy@2620738 { · 15 unmodified lines | |||
| 16 | #address-cells = <1>; | 16 | #address-cells = <1>; |
| 17 | #size-cells = <1>; | 17 | #size-cells = <1>; |
| 18 | reg = <0x2620738 32>; | 18 | reg = <0x2620738 32>; |
| 19 | status = "disabled"; | ||
| 20 | }; | 19 | }; |
| @@ -34,7 +34,9 @@ PHY user node · 33 unmodified lines | |||
| 34 | ============= | 34 | ============= |
| 35 | 35 | ||
| 36 | Required Properties: | 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 | phy-names : the names of the PHY corresponding to the PHYs present in the | 40 | phy-names : the names of the PHY corresponding to the PHYs present in the |
| 39 | *phys* phandle | 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 | Required properties (controller (parent) node): | 7 | Required properties (controller (parent) node): |
| 7 | - compatible : should be one of | 8 | - compatible : should be one of |
| 8 | "mediatek,mt2701-u3phy" | 9 | "mediatek,generic-tphy-v1" |
| 9 | "mediatek,mt2712-u3phy" | 10 | "mediatek,generic-tphy-v2" |
| 10 | "mediatek,mt8173-u3phy" | 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 | - clocks : (deprecated, use port's clocks instead) a list of phandle + | 16 | - clocks : (deprecated, use port's clocks instead) a list of phandle + |
| 12 | clock-specifier pairs, one for each entry in clock-names | 17 | clock-specifier pairs, one for each entry in clock-names |
| 13 | - clock-names : (deprecated, use port's one instead) must contain | 18 | - clock-names : (deprecated, use port's one instead) must contain |
| @@ -35,6 +40,8 @@ Required properties (port (child) node): · 21 unmodified lines | |||
| 35 | cell after port phandle is phy type from: | 40 | cell after port phandle is phy type from: |
| 36 | - PHY_TYPE_USB2 | 41 | - PHY_TYPE_USB2 |
| 37 | - PHY_TYPE_USB3 | 42 | - PHY_TYPE_USB3 |
| 43 | - PHY_TYPE_PCIE | ||
| 44 | - PHY_TYPE_SATA | ||
| 38 | 45 | ||
| 39 | Example: | 46 | Example: |
| 40 | 47 | ||
| @@ -44,14 +51,12 @@ u3phy: usb-phy@11290000 { · 3 unmodified lines | |||
| 44 | #address-cells = <2>; | 51 | #address-cells = <2>; |
| 45 | #size-cells = <2>; | 52 | #size-cells = <2>; |
| 46 | ranges; | 53 | ranges; |
| 47 | status = "okay"; | ||
| 48 | 54 | ||
| 49 | u2port0: usb-phy@11290800 { | 55 | u2port0: usb-phy@11290800 { |
| 50 | reg = <0 0x11290800 0 0x100>; | 56 | reg = <0 0x11290800 0 0x100>; |
| 51 | clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; | 57 | clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; |
| 52 | clock-names = "ref"; | 58 | clock-names = "ref"; |
| 53 | #phy-cells = <1>; | 59 | #phy-cells = <1>; |
| 54 | status = "okay"; | ||
| 55 | }; | 60 | }; |
| 56 | 61 | ||
| 57 | u3port0: usb-phy@11290900 { | 62 | u3port0: usb-phy@11290900 { |
| @@ -59,7 +64,6 @@ u3phy: usb-phy@11290000 { · 1 unmodified line | |||
| 59 | clocks = <&clk26m>; | 64 | clocks = <&clk26m>; |
| 60 | clock-names = "ref"; | 65 | clock-names = "ref"; |
| 61 | #phy-cells = <1>; | 66 | #phy-cells = <1>; |
| 62 | status = "okay"; | ||
| 63 | }; | 67 | }; |
| 64 | 68 | ||
| 65 | u2port1: usb-phy@11291000 { | 69 | u2port1: usb-phy@11291000 { |
| @@ -67,7 +71,6 @@ u3phy: usb-phy@11290000 { · 1 unmodified line | |||
| 67 | clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; | 71 | clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; |
| 68 | clock-names = "ref"; | 72 | clock-names = "ref"; |
| 69 | #phy-cells = <1>; | 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 | clocks = <&gate_clk 15>; | 18 | clocks = <&gate_clk 15>; |
| 19 | clock-names = "sata"; | 19 | clock-names = "sata"; |
| 20 | #phy-cells = <0>; | 20 | #phy-cells = <0>; |
| 21 | status = "ok"; | ||
| 22 | }; | 21 | }; |
| 23 | 22 | ||
| 24 | Armada 375 USB cluster | 23 | Armada 375 USB cluster |
| @@ -6,6 +6,7 @@ Required properties (phy (parent) node): · 5 unmodified lines | |||
| 6 | * "rockchip,rk3328-usb2phy" | 6 | * "rockchip,rk3328-usb2phy" |
| 7 | * "rockchip,rk3366-usb2phy" | 7 | * "rockchip,rk3366-usb2phy" |
| 8 | * "rockchip,rk3399-usb2phy" | 8 | * "rockchip,rk3399-usb2phy" |
| 9 | * "rockchip,rv1108-usb2phy" | ||
| 9 | - reg : the address offset of grf for usb-phy configuration. | 10 | - reg : the address offset of grf for usb-phy configuration. |
| 10 | - #clock-cells : should be 0. | 11 | - #clock-cells : should be 0. |
| 11 | - clock-output-names : specify the 480m output clock name. | 12 | - clock-output-names : specify the 480m output clock name. |
| @@ -18,6 +19,10 @@ Optional properties: · 6 unmodified lines | |||
| 18 | usb-phy output 480m and xin24m. | 19 | usb-phy output 480m and xin24m. |
| 19 | Refer to clk/clock-bindings.txt for generic clock | 20 | Refer to clk/clock-bindings.txt for generic clock |
| 20 | consumer properties. | 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 | Required nodes : a sub-node is required for each port the phy provides. | 27 | Required nodes : a sub-node is required for each port the phy provides. |
| 23 | The sub-node name is used to identify host or otg port, | 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 | Required properties (port (child) node): | 33 | Required properties (port (child) node): |
| 29 | - #phy-cells : must be 0. See ./phy-bindings.txt for details. | 34 | - #phy-cells : must be 0. See ./phy-bindings.txt for details. |
| 30 | - interrupts : specify an interrupt for each entry in interrupt-names. | 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 | * "otg-id" : for the otg id interrupt. | 38 | * "otg-id" : for the otg id interrupt. |
| 33 | * "otg-bvalid" : for the otg vbus interrupt. | 39 | * "otg-bvalid" : for the otg vbus interrupt. |
| 34 | * "linestate" : for the host/otg linestate interrupt. | 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 | Optional properties: | 45 | Optional properties: |
| 37 | - phy-supply : phandle to a regulator that provides power to VBUS. | 46 | - phy-supply : phandle to a regulator that provides power to VBUS. |
| @@ -58,14 +67,12 @@ grf: syscon@ff770000 { · 20 unmodified lines | |||
| 58 | <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, | 67 | <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, |
| 59 | <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; | 68 | <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; |
| 60 | interrupt-names = "otg-id", "otg-bvalid", "linestate"; | 69 | interrupt-names = "otg-id", "otg-bvalid", "linestate"; |
| 61 | status = "okay"; | ||
| 62 | }; | 70 | }; |
| 63 | 71 | ||
| 64 | u2phy_host: host-port { | 72 | u2phy_host: host-port { |
| 65 | #phy-cells = <0>; | 73 | #phy-cells = <0>; |
| 66 | interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; | 74 | interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; |
| 67 | interrupt-names = "linestate"; | 75 | interrupt-names = "linestate"; |
| 68 | status = "okay"; | ||
| 69 | }; | 76 | }; |
| 70 | }; | 77 | }; |
| 71 | }; | 78 | }; |
| @@ -25,7 +25,6 @@ Example: · 24 unmodified lines | |||
| 25 | clock-names = "ref"; | 25 | clock-names = "ref"; |
| 26 | #phy-cells = <0>; | 26 | #phy-cells = <0>; |
| 27 | 27 | ||
| 28 | status = "ok"; | ||
| 29 | }; | 28 | }; |
| 30 | 29 | ||
| 31 | phy@100f8830 { | 30 | phy@100f8830 { |
| @@ -35,5 +34,4 @@ Example: · 3 unmodified lines | |||
| 35 | clock-names = "ref"; | 34 | clock-names = "ref"; |
| 36 | #phy-cells = <0>; | 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 | Required properties: | 7 | Required properties: |
| 8 | - compatible: compatible list, contains: | 8 | - compatible: compatible list, contains: |
| 9 | "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 | ||
| 9 | "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, | 10 | "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, |
| 10 | "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996. | 11 | "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996. |
| 11 | 12 | ||
| @@ -38,6 +39,8 @@ Required properties: · 26 unmodified lines | |||
| 38 | "phy", "common", "cfg". | 39 | "phy", "common", "cfg". |
| 39 | For "qcom,msm8996-qmp-usb3-phy" must contain | 40 | For "qcom,msm8996-qmp-usb3-phy" must contain |
| 40 | "phy", "common". | 41 | "phy", "common". |
| 42 | For "qcom,ipq8074-qmp-pcie-phy" must contain: | ||
| 43 | "phy", "common". | ||
| 41 | 44 | ||
| 42 | - vdda-phy-supply: Phandle to a regulator supply to PHY core block. | 45 | - vdda-phy-supply: Phandle to a regulator supply to PHY core block. |
| 43 | - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block. | 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 | one for each entry in clock-names. | 63 | one for each entry in clock-names. |
| 61 | - clock-names: Must contain following for pcie and usb qmp phys: | 64 | - clock-names: Must contain following for pcie and usb qmp phys: |
| 62 | "pipe<lane-number>" for pipe clock specific to each lane. | 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 | - resets: a list of phandles and reset controller specifier pairs, | 74 | - resets: a list of phandles and reset controller specifier pairs, |
| 65 | one for each entry in reset-names. | 75 | one for each entry in reset-names. |
| @@ -96,6 +106,7 @@ Example: · 30 unmodified lines | |||
| 96 | 106 | ||
| 97 | clocks = <&gcc GCC_PCIE_0_PIPE_CLK>; | 107 | clocks = <&gcc GCC_PCIE_0_PIPE_CLK>; |
| 98 | clock-names = "pipe0"; | 108 | clock-names = "pipe0"; |
| 109 | clock-output-names = "pcie_0_pipe_clk_src"; | ||
| 99 | resets = <&gcc GCC_PCIE_0_PHY_BCR>; | 110 | resets = <&gcc GCC_PCIE_0_PHY_BCR>; |
| 100 | reset-names = "lane0"; | 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 | Required properties: | 4 | Required properties: |
| 5 | - compatible: rockchip,rk3399-pcie-phy | 5 | - compatible: rockchip,rk3399-pcie-phy |
| 6 | - #phy-cells: must be 0 | ||
| 7 | - clocks: Must contain an entry in clock-names. | 6 | - clocks: Must contain an entry in clock-names. |
| 8 | See ../clocks/clock-bindings.txt for details. | 7 | See ../clocks/clock-bindings.txt for details. |
| 9 | - clock-names: Must be "refclk" | 8 | - clock-names: Must be "refclk" |
| @@ -11,6 +10,12 @@ Required properties: · 1 unmodified line | |||
| 11 | See ../reset/reset.txt for details. | 10 | See ../reset/reset.txt for details. |
| 12 | - reset-names: Must be "phy" | 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 | Example: | 19 | Example: |
| 15 | 20 | ||
| 16 | grf: syscon@ff770000 { | 21 | grf: syscon@ff770000 { |
| @@ -82,7 +82,6 @@ usbphy: phy@125b0000 { · 81 unmodified lines | |||
| 82 | reg = <0x125b0000 0x100>; | 82 | reg = <0x125b0000 0x100>; |
| 83 | clocks = <&clock 305>, <&clock 2>; | 83 | clocks = <&clock 305>, <&clock 2>; |
| 84 | clock-names = "phy", "ref"; | 84 | clock-names = "phy", "ref"; |
| 85 | status = "okay"; | ||
| 86 | #phy-cells = <1>; | 85 | #phy-cells = <1>; |
| 87 | samsung,sysreg-phandle = <&sys_reg>; | 86 | samsung,sysreg-phandle = <&sys_reg>; |
| 88 | samsung,pmureg-phandle = <&pmu_reg>; | 87 | samsung,pmureg-phandle = <&pmu_reg>; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | |||
| 9 | * allwinner,sun7i-a20-usb-phy | 9 | * allwinner,sun7i-a20-usb-phy |
| 10 | * allwinner,sun8i-a23-usb-phy | 10 | * allwinner,sun8i-a23-usb-phy |
| 11 | * allwinner,sun8i-a33-usb-phy | 11 | * allwinner,sun8i-a33-usb-phy |
| 12 | * allwinner,sun8i-a83t-usb-phy | ||
| 12 | * allwinner,sun8i-h3-usb-phy | 13 | * allwinner,sun8i-h3-usb-phy |
| 13 | * allwinner,sun8i-v3s-usb-phy | 14 | * allwinner,sun8i-v3s-usb-phy |
| 14 | * allwinner,sun50i-a64-usb-phy | 15 | * allwinner,sun50i-a64-usb-phy |
| @@ -17,18 +18,22 @@ Required properties: · 2 unmodified lines | |||
| 17 | * "phy_ctrl" | 18 | * "phy_ctrl" |
| 18 | * "pmu0" for H3, V3s and A64 | 19 | * "pmu0" for H3, V3s and A64 |
| 19 | * "pmu1" | 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 | - #phy-cells : from the generic phy bindings, must be 1 | 23 | - #phy-cells : from the generic phy bindings, must be 1 |
| 22 | - clocks : phandle + clock specifier for the phy clocks | 24 | - clocks : phandle + clock specifier for the phy clocks |
| 23 | - clock-names : | 25 | - clock-names : |
| 24 | * "usb_phy" for sun4i, sun5i or sun7i | 26 | * "usb_phy" for sun4i, sun5i or sun7i |
| 25 | * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i | 27 | * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i |
| 26 | * "usb0_phy", "usb1_phy" for sun8i | 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 | - resets : a list of phandle + reset specifier pairs | 31 | - resets : a list of phandle + reset specifier pairs |
| 28 | - reset-names : | 32 | - reset-names : |
| 29 | * "usb0_reset" | 33 | * "usb0_reset" |
| 30 | * "usb1_reset" | 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 | Optional properties: | 38 | Optional properties: |
| 34 | - usb0_id_det-gpios : gpio phandle for reading the otg id pin value | 39 | - usb0_id_det-gpios : gpio phandle for reading the otg id pin value |
| @@ -37,6 +42,7 @@ Optional properties: · 2 unmodified lines | |||
| 37 | - usb0_vbus-supply : regulator phandle for controller usb0 vbus | 42 | - usb0_vbus-supply : regulator phandle for controller usb0 vbus |
| 38 | - usb1_vbus-supply : regulator phandle for controller usb1 vbus | 43 | - usb1_vbus-supply : regulator phandle for controller usb1 vbus |
| 39 | - usb2_vbus-supply : regulator phandle for controller usb2 vbus | 44 | - usb2_vbus-supply : regulator phandle for controller usb2 vbus |
| 45 | - usb3_vbus-supply : regulator phandle for controller usb3 vbus | ||
| 40 | 46 | ||
| 41 | Example: | 47 | Example: |
| 42 | usbphy: phy@0x01c13400 { | 48 | usbphy: phy@0x01c13400 { |
| @@ -33,6 +33,5 @@ Example: · 32 unmodified lines | |||
| 33 | clock-names = "hsic_480M", "hsic_12M", "phy"; | 33 | clock-names = "hsic_480M", "hsic_12M", "phy"; |
| 34 | resets = <&usb_phy_clk 18>, <&usb_phy_clk 19>; | 34 | resets = <&usb_phy_clk 18>, <&usb_phy_clk 19>; |
| 35 | reset-names = "hsic", "phy"; | 35 | reset-names = "hsic", "phy"; |
| 36 | status = "disabled"; | ||
| 37 | #phy-cells = <0>; | 36 | #phy-cells = <0>; |
| 38 | }; | 37 | }; |
| @@ -148,5 +148,4 @@ dbgu: serial@fffff200 { · 147 unmodified lines | |||
| 148 | interrupts = <1 4 7>; | 148 | interrupts = <1 4 7>; |
| 149 | pinctrl-names = "default"; | 149 | pinctrl-names = "default"; |
| 150 | pinctrl-0 = <&pinctrl_dbgu>; | 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 | usdhc@0219c000 { /* uSDHC4 */ | 61 | usdhc@0219c000 { /* uSDHC4 */ |
| 62 | non-removable; | 62 | non-removable; |
| 63 | vmmc-supply = <®_3p3v>; | 63 | vmmc-supply = <®_3p3v>; |
| 64 | status = "okay"; | ||
| 65 | pinctrl-names = "default"; | 64 | pinctrl-names = "default"; |
| 66 | pinctrl-0 = <&pinctrl_usdhc4_1>; | 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 | i2c1: i2c@30a20000 { | 61 | i2c1: i2c@30a20000 { |
| 62 | pinctrl-names = "default"; | 62 | pinctrl-names = "default"; |
| 63 | pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>; | 63 | pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>; |
| 64 | status = "okay"; | ||
| 65 | }; | 64 | }; |
| 66 | 65 | ||
| 67 | iomuxc-lpsr@302c0000 { | 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 | pinctrl-0 = <&state_dpaux_i2c>; | 56 | pinctrl-0 = <&state_dpaux_i2c>; |
| 57 | pinctrl-1 = <&state_dpaux_off>; | 57 | pinctrl-1 = <&state_dpaux_off>; |
| 58 | pinctrl-names = "default", "idle"; | 58 | pinctrl-names = "default", "idle"; |
| 59 | status = "disabled"; | ||
| 60 | }; | 59 | }; |
| @@ -50,7 +50,6 @@ uart2: serial@900000 { · 49 unmodified lines | |||
| 50 | reg-io-width = <1>; | 50 | reg-io-width = <1>; |
| 51 | current-speed = <115200>; | 51 | current-speed = <115200>; |
| 52 | no-loopback-test; | 52 | no-loopback-test; |
| 53 | status = "disabled"; | ||
| 54 | resets = <&reset 22>; | 53 | resets = <&reset 22>; |
| 55 | pinctrl-names = "default"; | 54 | pinctrl-names = "default"; |
| 56 | pinctrl-0 = <&pinctrl_uart2>; | 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 | ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK | 69 | ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK |
| 70 | SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ | 70 | SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ |
| 71 | SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4 | 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 | 72 | TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USB11D1 USB11H2 USB2D1 |
| 73 | VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 WDTRST2 | 73 | USB2H1 USBCKI VGABIOS_ROM VGAHS VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1 |
| 74 | WDTRST2 | ||
| 74 | 75 | ||
| 75 | aspeed,ast2500-pinctrl, aspeed,g5-pinctrl: | 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 | SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ | 87 | SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ |
| 87 | SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0 | 88 | SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0 |
| 88 | SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 | 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 | Examples | 93 | Examples |
| 92 | ======== | 94 | ======== |
| @@ -268,6 +268,8 @@ output-enable - enable output on a pin without actively driving it · 267 unmodified lines | |||
| 268 | (such as enabling an output buffer) | 268 | (such as enabling an output buffer) |
| 269 | output-low - set the pin to output mode with low level | 269 | output-low - set the pin to output mode with low level |
| 270 | output-high - set the pin to output mode with high level | 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 | slew-rate - set the slew rate | 273 | slew-rate - set the slew rate |
| 272 | 274 | ||
| 273 | For example: | 275 | For example: |
| @@ -5,6 +5,7 @@ The Mediatek's Pin controller is used to control SoC pins. · 4 unmodified lines | |||
| 5 | Required properties: | 5 | Required properties: |
| 6 | - compatible: value should be one of the following. | 6 | - compatible: value should be one of the following. |
| 7 | "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl. | 7 | "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl. |
| 8 | "mediatek,mt2712-pinctrl", compatible with mt2712 pinctrl. | ||
| 8 | "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. | 9 | "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. |
| 9 | "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl. | 10 | "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl. |
| 10 | "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. | 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 | &vga { | 81 | &vga { |
| 82 | pinctrl-names = "default"; | 82 | pinctrl-names = "default"; |
| 83 | pinctrl-0 = <&vga_pins>; | 83 | pinctrl-0 = <&vga_pins>; |
| 84 | status = "okay"; | ||
| 85 | }; | 84 | }; |
| @@ -46,7 +46,8 @@ Valid values for pins are: · 45 unmodified lines | |||
| 46 | gpio0-gpio89 | 46 | gpio0-gpio89 |
| 47 | 47 | ||
| 48 | Valid values for function are: | 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 | gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, | 51 | gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, |
| 51 | gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, | 52 | gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, |
| 52 | gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, | 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 | Supports mux, bias and drive-strength | 50 | Supports mux, bias and drive-strength |
| 51 | 51 | ||
| 52 | Valid values for qcom,function are: | 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 | Example: | 59 | Example: |
| 56 | 60 | ||
| @@ -16,6 +16,7 @@ PMIC's from Qualcomm. · 15 unmodified lines | |||
| 16 | "qcom,pm8941-gpio" | 16 | "qcom,pm8941-gpio" |
| 17 | "qcom,pm8994-gpio" | 17 | "qcom,pm8994-gpio" |
| 18 | "qcom,pma8084-gpio" | 18 | "qcom,pma8084-gpio" |
| 19 | "qcom,pmi8994-gpio" | ||
| 19 | 20 | ||
| 20 | And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" | 21 | And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" |
| 21 | if the device is on an spmi bus or an ssbi bus respectively | 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 | gpio1-gpio36 for pm8941 | 86 | gpio1-gpio36 for pm8941 |
| 86 | gpio1-gpio22 for pm8994 | 87 | gpio1-gpio22 for pm8994 |
| 87 | gpio1-gpio22 for pma8084 | 88 | gpio1-gpio22 for pma8084 |
| 89 | gpio1-gpio10 for pmi8994 | ||
| 88 | 90 | ||
| 89 | - function: | 91 | - function: |
| 90 | Usage: required | 92 | Usage: required |
| @@ -98,7 +100,10 @@ to specify in a pin configuration subnode: · 7 unmodified lines | |||
| 98 | "dtest1", | 100 | "dtest1", |
| 99 | "dtest2", | 101 | "dtest2", |
| 100 | "dtest3", | 102 | "dtest3", |
| 101 | "dtest4" | 103 | "dtest4", |
| 104 | And following values are supported by LV/MV GPIO subtypes: | ||
| 105 | "func3", | ||
| 106 | "func4" | ||
| 102 | 107 | ||
| 103 | - bias-disable: | 108 | - bias-disable: |
| 104 | Usage: optional | 109 | Usage: optional |
| @@ -183,6 +188,25 @@ to specify in a pin configuration subnode: · 78 unmodified lines | |||
| 183 | Value type: <none> | 188 | Value type: <none> |
| 184 | Definition: The specified pins are configured in open-source mode. | 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 | Example: | 210 | Example: |
| 187 | 211 | ||
| 188 | pm8921_gpio: gpio@150 { | 212 | pm8921_gpio: gpio@150 { |
| @@ -24,6 +24,7 @@ Required Properties: · 23 unmodified lines | |||
| 24 | - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. | 24 | - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. |
| 25 | - "renesas,pfc-r8a7795": for R8A7795 (R-Car H3) compatible pin-controller. | 25 | - "renesas,pfc-r8a7795": for R8A7795 (R-Car H3) compatible pin-controller. |
| 26 | - "renesas,pfc-r8a7796": for R8A7796 (R-Car M3-W) compatible pin-controller. | 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 | - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. | 28 | - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. |
| 28 | 29 | ||
| 29 | - reg: Base address and length of each memory resource used by the pin | 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 | Example 1: SH73A0 (SH-Mobile AG5) pin controller node | 113 | Example 1: SH73A0 (SH-Mobile AG5) pin controller node |
| 113 | 114 | ||
| 114 | pfc: pfc@e6050000 { | 115 | pfc: pin-controller@e6050000 { |
| 115 | compatible = "renesas,pfc-sh73a0"; | 116 | compatible = "renesas,pfc-sh73a0"; |
| 116 | reg = <0xe6050000 0x8000>, | 117 | reg = <0xe6050000 0x8000>, |
| 117 | <0xe605801c 0x1c>; | 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 | bus-width = <8>; | 174 | bus-width = <8>; |
| 174 | vmmc-supply = <®_1p8v>; | 175 | vmmc-supply = <®_1p8v>; |
| 175 | status = "okay"; | ||
| 176 | }; | 176 | }; |
| @@ -24,6 +24,7 @@ Required properties for iomux controller: · 23 unmodified lines | |||
| 24 | "rockchip,rk2928-pinctrl": for Rockchip RK2928 | 24 | "rockchip,rk2928-pinctrl": for Rockchip RK2928 |
| 25 | "rockchip,rk3066a-pinctrl": for Rockchip RK3066a | 25 | "rockchip,rk3066a-pinctrl": for Rockchip RK3066a |
| 26 | "rockchip,rk3066b-pinctrl": for Rockchip RK3066b | 26 | "rockchip,rk3066b-pinctrl": for Rockchip RK3066b |
| 27 | "rockchip,rk3128-pinctrl": for Rockchip RK3128 | ||
| 27 | "rockchip,rk3188-pinctrl": for Rockchip RK3188 | 28 | "rockchip,rk3188-pinctrl": for Rockchip RK3188 |
| 28 | "rockchip,rk3228-pinctrl": for Rockchip RK3228 | 29 | "rockchip,rk3228-pinctrl": for Rockchip RK3228 |
| 29 | "rockchip,rk3288-pinctrl": for Rockchip RK3288 | 30 | "rockchip,rk3288-pinctrl": for Rockchip RK3288 |
| @@ -120,7 +121,6 @@ uart2: serial@20064000 { · 90 unmodified lines | |||
| 120 | reg-shift = <2>; | 121 | reg-shift = <2>; |
| 121 | reg-io-width = <1>; | 122 | reg-io-width = <1>; |
| 122 | clocks = <&mux_uart2>; | 123 | clocks = <&mux_uart2>; |
| 123 | status = "okay"; | ||
| 124 | 124 | ||
| 125 | pinctrl-names = "default"; | 125 | pinctrl-names = "default"; |
| 126 | pinctrl-0 = <&uart2_xfer>; | 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 | &usart1 { | 180 | &usart1 { |
| 181 | pinctrl-0 = <&usart1_pins_a>; | 181 | pinctrl-0 = <&usart1_pins_a>; |
| 182 | pinctrl-names = "default"; | 182 | pinctrl-names = "default"; |
| 183 | status = "okay"; | ||
| 184 | }; | 183 | }; |
| @@ -13,6 +13,5 @@ Example: · 12 unmodified lines | |||
| 13 | 13 | ||
| 14 | act8846: act8846@5 { | 14 | act8846: act8846@5 { |
| 15 | compatible = "active-semi,act8846"; | 15 | compatible = "active-semi,act8846"; |
| 16 | status = "okay"; | ||
| 17 | system-power-controller; | 16 | system-power-controller; |
| 18 | } | 17 | } |
| @@ -1,12 +1,13 @@ | |||
| 1 | DT bindings for the Renesas Advanced Power Management Unit | 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 | for CPU core power domain control including SMP boot and CPU Hotplug. | 4 | for CPU core power domain control including SMP boot and CPU Hotplug. |
| 5 | 5 | ||
| 6 | Required properties: | 6 | Required properties: |
| 7 | 7 | ||
| 8 | - compatible: Should be "renesas,<soctype>-apmu", "renesas,apmu" as fallback. | 8 | - compatible: Should be "renesas,<soctype>-apmu", "renesas,apmu" as fallback. |
| 9 | Examples with soctypes are: | 9 | Examples with soctypes are: |
| 10 | - "renesas,r8a7743-apmu" (RZ/G1M) | ||
| 10 | - "renesas,r8a7790-apmu" (R-Car H2) | 11 | - "renesas,r8a7790-apmu" (R-Car H2) |
| 11 | - "renesas,r8a7791-apmu" (R-Car M2-W) | 12 | - "renesas,r8a7791-apmu" (R-Car M2-W) |
| 12 | - "renesas,r8a7792-apmu" (R-Car V2H) | 13 | - "renesas,r8a7792-apmu" (R-Car V2H) |
| @@ -17,6 +17,7 @@ Required properties: · 16 unmodified lines | |||
| 17 | - "renesas,r8a7794-sysc" (R-Car E2) | 17 | - "renesas,r8a7794-sysc" (R-Car E2) |
| 18 | - "renesas,r8a7795-sysc" (R-Car H3) | 18 | - "renesas,r8a7795-sysc" (R-Car H3) |
| 19 | - "renesas,r8a7796-sysc" (R-Car M3-W) | 19 | - "renesas,r8a7796-sysc" (R-Car M3-W) |
| 20 | - "renesas,r8a77995-sysc" (R-Car D3) | ||
| 20 | - reg: Address start and address range for the device. | 21 | - reg: Address start and address range for the device. |
| 21 | - #power-domain-cells: Must be 1. | 22 | - #power-domain-cells: Must be 1. |
| 22 | 23 | ||
| @@ -8,5 +8,4 @@ Example node: · 7 unmodified lines | |||
| 8 | restart { | 8 | restart { |
| 9 | compatible = "st,stih407-restart"; | 9 | compatible = "st,stih407-restart"; |
| 10 | st,syscfg = <&syscfg_sbc_reg>; | 10 | st,syscfg = <&syscfg_sbc_reg>; |
| 11 | status = "okay"; | ||
| 12 | }; | 11 | }; |
| @@ -39,6 +39,8 @@ Required properties: · 38 unmodified lines | |||
| 39 | - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains | 39 | - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains |
| 40 | - "rockchip,rk3399-io-voltage-domain" for rk3399 | 40 | - "rockchip,rk3399-io-voltage-domain" for rk3399 |
| 41 | - "rockchip,rk3399-pmu-io-voltage-domain" for rk3399 pmu-domains | 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 | Deprecated properties: | 45 | Deprecated properties: |
| 44 | - rockchip,grf: phandle to the syscon managing the "general register files" | 46 | - rockchip,grf: phandle to the syscon managing the "general register files" |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | |||
| 29 | pmic@5b { | 29 | pmic@5b { |
| 30 | compatible = "active-semi,act8945a"; | 30 | compatible = "active-semi,act8945a"; |
| 31 | reg = <0x5b>; | 31 | reg = <0x5b>; |
| 32 | status = "okay"; | ||
| 33 | 32 | ||
| 34 | charger { | 33 | charger { |
| 35 | compatible = "active-semi,act8945a-charger"; | 34 | compatible = "active-semi,act8945a-charger"; |
| @@ -43,6 +42,5 @@ Example: · 7 unmodified lines | |||
| 43 | active-semi,input-voltage-threshold-microvolt = <6600>; | 42 | active-semi,input-voltage-threshold-microvolt = <6600>; |
| 44 | active-semi,precondition-timeout = <40>; | 43 | active-semi,precondition-timeout = <40>; |
| 45 | active-semi,total-timeout = <3>; | 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. | 3 | All chips measure battery capacity. |
| 4 | The LTC2943 is compatible with the LTC2941, it adds voltage and | 4 | The LTC2942 is pin compatible with the LTC2941, it adds voltage and |
| 5 | temperature monitoring, and uses a slightly different conversion | 5 | temperature monitoring, and is runtime detected. LTC2943 and LTC2944 |
| 6 | formula for the charge counter. | 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 | Required properties: | 9 | Required properties: |
| 9 | - compatible: Should contain "lltc,ltc2941" or "lltc,ltc2943" which also | 10 | - compatible: Should contain "lltc,ltc2941", "lltc,ltc2942", "lltc,ltc2943" |
| 10 | indicates the type of I2C chip attached. | 11 | or "lltc,ltc2944" which also indicates the type of I2C chip attached. |
| 11 | - reg: The 7-bit I2C address. | 12 | - reg: The 7-bit I2C address. |
| 12 | - lltc,resistor-sense: The sense resistor value in milli-ohms. Can be a 32-bit | 13 | - lltc,resistor-sense: The sense resistor value in milli-ohms. Can be a 32-bit |
| 13 | negative value when the battery has been connected to the wrong end of the | 14 | negative value when the battery has been connected to the wrong end of the |
| @@ -21,5 +21,4 @@ Example: · 20 unmodified lines | |||
| 21 | flt-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>; | 21 | flt-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>; |
| 22 | chg-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; | 22 | chg-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; |
| 23 | cen-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; | 23 | cen-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; |
| 24 | status = "okay"; | ||
| 25 | }; | 24 | }; |
| @@ -12,7 +12,6 @@ Example: · 11 unmodified lines | |||
| 12 | clock-frequency = <50000>; | 12 | clock-frequency = <50000>; |
| 13 | pinctrl-names = "default"; | 13 | pinctrl-names = "default"; |
| 14 | pinctrl-0 = <&pinctrl_i2c2>; | 14 | pinctrl-0 = <&pinctrl_i2c2>; |
| 15 | status = "okay"; | ||
| 16 | 15 | ||
| 17 | max14656@35 { | 16 | max14656@35 { |
| 18 | compatible = "maxim,max14656"; | 17 | compatible = "maxim,max14656"; |
| @@ -20,13 +20,12 @@ List of legacy properties and respective binding document · 19 unmodified lines | |||
| 20 | 1. "enable-sdio-wakeup" Documentation/devicetree/bindings/mmc/mmc.txt | 20 | 1. "enable-sdio-wakeup" Documentation/devicetree/bindings/mmc/mmc.txt |
| 21 | 2. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt | 21 | 2. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt |
| 22 | 3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt | 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 | 23 | 4. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt |
| 24 | 5. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt | ||
| 25 | Documentation/devicetree/bindings/mfd/tc3589x.txt | 24 | Documentation/devicetree/bindings/mfd/tc3589x.txt |
| 26 | Documentation/devicetree/bindings/input/ads7846.txt | 25 | Documentation/devicetree/bindings/input/ads7846.txt |
| 27 | 6. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt | 26 | 5. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt |
| 28 | 7. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt | 27 | 6. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt |
| 29 | 8. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 28 | 7. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt |
| 30 | 29 | ||
| 31 | Examples | 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 | Example: | 14 | Example: |
| 15 | pps { | 15 | pps { |
| 16 | compatible = "pps-gpio"; | 16 | pinctrl-names = "default"; |
| 17 | gpios = <&gpio2 6 0>; | 17 | pinctrl-0 = <&pinctrl_pps>; |
| 18 | 18 | ||
| 19 | gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; | ||
| 19 | assert-falling-edge; | 20 | assert-falling-edge; |
| 21 | |||
| 22 | compatible = "pps-gpio"; | ||
| 23 | status = "okay"; | ||
| 20 | }; | 24 | }; |
| @@ -16,5 +16,4 @@ Example: · 15 unmodified lines | |||
| 16 | ptp: ptp-dte@180af650 { | 16 | ptp: ptp-dte@180af650 { |
| 17 | compatible = "brcm,iproc-ptp-dte", "brcm,ptp-dte"; | 17 | compatible = "brcm,iproc-ptp-dte", "brcm,ptp-dte"; |
| 18 | reg = <0x180af650 0x10>; | 18 | reg = <0x180af650 0x10>; |
| 19 | status = "okay"; | ||
| 20 | }; | 19 | }; |
| @@ -6,7 +6,7 @@ Required properties: · 5 unmodified lines | |||
| 6 | - clocks: This clock defines the base clock frequency of the PWM hardware | 6 | - clocks: This clock defines the base clock frequency of the PWM hardware |
| 7 | system, the period and the duty_cycle of the PWM signal is a multiple of | 7 | system, the period and the duty_cycle of the PWM signal is a multiple of |
| 8 | the base period. | 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 | the cells format. | 10 | the cells format. |
| 11 | 11 | ||
| 12 | Examples: | 12 | Examples: |
| @@ -15,7 +15,7 @@ pwm@2020c000 { · 2 unmodified lines | |||
| 15 | compatible = "brcm,bcm2835-pwm"; | 15 | compatible = "brcm,bcm2835-pwm"; |
| 16 | reg = <0x2020c000 0x28>; | 16 | reg = <0x2020c000 0x28>; |
| 17 | clocks = <&clk_pwm>; | 17 | clocks = <&clk_pwm>; |
| 18 | #pwm-cells = <2>; | 18 | #pwm-cells = <3>; |
| 19 | }; | 19 | }; |
| 20 | 20 | ||
| 21 | clocks { | 21 | clocks { |
| @@ -2,6 +2,8 @@ MediaTek PWM controller · 1 unmodified line | |||
| 2 | 2 | ||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: should be "mediatek,<name>-pwm": | 4 | - compatible: should be "mediatek,<name>-pwm": |
| 5 | - "mediatek,mt2712-pwm": found on mt2712 SoC. | ||
| 6 | - "mediatek,mt7622-pwm": found on mt7622 SoC. | ||
| 5 | - "mediatek,mt7623-pwm": found on mt7623 SoC. | 7 | - "mediatek,mt7623-pwm": found on mt7623 SoC. |
| 6 | - reg: physical base address and length of the controller's registers. | 8 | - reg: physical base address and length of the controller's registers. |
| 7 | - #pwm-cells: must be 2. See pwm.txt in this directory for a description of | 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 | - clock-names: must contain the following: | 12 | - clock-names: must contain the following: |
| 11 | - "top": the top clock generator | 13 | - "top": the top clock generator |
| 12 | - "main": clock used by the PWM core | 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 | - pinctrl-names: Must contain a "default" entry. | 18 | - pinctrl-names: Must contain a "default" entry. |
| 15 | - pinctrl-0: One property must exist for each entry in pinctrl-names. | 19 | - pinctrl-0: One property must exist for each entry in pinctrl-names. |
| 16 | See pinctrl/pinctrl-bindings.txt for details of the property values. | 20 | See pinctrl/pinctrl-bindings.txt for details of the property values. |
| @@ -19,7 +19,6 @@ Example: · 18 unmodified lines | |||
| 19 | compatible = "amlogic,meson-gxbb-pwm"; | 19 | compatible = "amlogic,meson-gxbb-pwm"; |
| 20 | reg = <0x0 0x08550 0x0 0x10>; | 20 | reg = <0x0 0x08550 0x0 0x10>; |
| 21 | #pwm-cells = <3>; | 21 | #pwm-cells = <3>; |
| 22 | status = "disabled"; | ||
| 23 | clocks = <&xtal>, <&xtal>; | 22 | clocks = <&xtal>, <&xtal>; |
| 24 | clock-names = "clkin0", "clkin1"; | 23 | clock-names = "clkin0", "clkin1"; |
| 25 | } | 24 | } |
| @@ -3,10 +3,17 @@ Rockchip PWM controller · 2 unmodified lines | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: should be "rockchip,<name>-pwm" | 4 | - compatible: should be "rockchip,<name>-pwm" |
| 5 | "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs | 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 | "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC | 8 | "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC |
| 8 | - reg: physical base address and length of the controller's registers | 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 | - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.txt in this directory | 17 | - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.txt in this directory |
| 11 | for a description of the cell format. | 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 | reg = <0x01c20e00 0xc>; | 19 | reg = <0x01c20e00 0xc>; |
| 20 | clocks = <&osc24M>; | 20 | clocks = <&osc24M>; |
| 21 | #pwm-cells = <3>; | 21 | #pwm-cells = <3>; |
| 22 | status = "disabled"; | ||
| 23 | }; | 22 | }; |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | |||
| 6 | for am4372 - compatible = "ti,am4372-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; | 6 | for am4372 - compatible = "ti,am4372-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; |
| 7 | for da850 - compatible = "ti,da850-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; | 7 | for da850 - compatible = "ti,da850-ecap", "ti,am3352-ecap", "ti,am33xx-ecap"; |
| 8 | for dra746 - compatible = "ti,dra746-ecap", "ti,am3352-ecap"; | 8 | for dra746 - compatible = "ti,dra746-ecap", "ti,am3352-ecap"; |
| 9 | for 66ak2g - compatible = "ti,k2g-ecap", "ti,am3352-ecap"; | ||
| 9 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of | 10 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
| 10 | the cells format. The PWM channel index ranges from 0 to 4. The only third | 11 | the cells format. The PWM channel index ranges from 0 to 4. The only third |
| 11 | cell flag supported by this binding is PWM_POLARITY_INVERTED. | 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 | ti,hwmods = "epwmss0"; | 26 | ti,hwmods = "epwmss0"; |
| 27 | #address-cells = <1>; | 27 | #address-cells = <1>; |
| 28 | #size-cells = <1>; | 28 | #size-cells = <1>; |
| 29 | status = "disabled"; | ||
| 30 | ranges = <0x48300100 0x48300100 0x80 /* ECAP */ | 29 | ranges = <0x48300100 0x48300100 0x80 /* ECAP */ |
| 31 | 0x48300180 0x48300180 0x80 /* EQEP */ | 30 | 0x48300180 0x48300180 0x80 /* EQEP */ |
| 32 | 0x48300200 0x48300200 0x80>; /* EHRPWM */ | 31 | 0x48300200 0x48300200 0x80>; /* EHRPWM */ |
| @@ -40,7 +39,6 @@ epwmss0: epwmss@48300000 { /* PWMSS for am4372 */ · 7 unmodified lines | |||
| 40 | ti,hwmods = "epwmss0"; | 39 | ti,hwmods = "epwmss0"; |
| 41 | #address-cells = <1>; | 40 | #address-cells = <1>; |
| 42 | #size-cells = <1>; | 41 | #size-cells = <1>; |
| 43 | status = "disabled"; | ||
| 44 | ranges = <0x48300100 0x48300100 0x80 /* ECAP */ | 42 | ranges = <0x48300100 0x48300100 0x80 /* ECAP */ |
| 45 | 0x48300180 0x48300180 0x80 /* EQEP */ | 43 | 0x48300180 0x48300180 0x80 /* EQEP */ |
| 46 | 0x48300200 0x48300200 0x80>; /* EHRPWM */ | 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 | - "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller. | 6 | - "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller. |
| 7 | - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller. | 7 | - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller. |
| 8 | - "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller. | 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 | - "renesas,tpu": for generic R-Car TPU PWM controller. | 9 | - "renesas,tpu": for generic R-Car TPU PWM controller. |
| 11 | 10 | ||
| 12 | - reg: Base address and length of each memory resource used by the PWM | 11 | - reg: Base address and length of each memory resource used by the PWM |
| @@ -52,7 +52,6 @@ Example: · 51 unmodified lines | |||
| 52 | compatible = "active-semi,act8865"; | 52 | compatible = "active-semi,act8865"; |
| 53 | reg = <0x5b>; | 53 | reg = <0x5b>; |
| 54 | active-semi,vsel-high; | 54 | active-semi,vsel-high; |
| 55 | status = "disabled"; | ||
| 56 | 55 | ||
| 57 | regulators { | 56 | regulators { |
| 58 | vcc_1v8_reg: DCDC_REG1 { | 57 | vcc_1v8_reg: DCDC_REG1 { |
| @@ -23,7 +23,6 @@ Example: · 22 unmodified lines | |||
| 23 | pmic@5b { | 23 | pmic@5b { |
| 24 | compatible = "active-semi,act8945a"; | 24 | compatible = "active-semi,act8945a"; |
| 25 | reg = <0x5b>; | 25 | reg = <0x5b>; |
| 26 | status = "okay"; | ||
| 27 | 26 | ||
| 28 | active-semi,vsel-high; | 27 | active-semi,vsel-high; |
| 29 | 28 | ||
| @@ -1,4 +1,4 @@ | |||
| 1 | Mediatek MT6311 Regulator Driver | 1 | Mediatek MT6311 Regulator |
| 2 | 2 | ||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: "mediatek,mt6311-regulator" | 4 | - compatible: "mediatek,mt6311-regulator" |
| @@ -1,4 +1,4 @@ | |||
| 1 | Mediatek MT6323 Regulator Driver | 1 | Mediatek MT6323 Regulator |
| 2 | 2 | ||
| 3 | All voltage regulators are defined as subnodes of the regulators node. A list | 3 | All voltage regulators are defined as subnodes of the regulators node. A list |
| 4 | of regulators provided by this controller are defined as subnodes of the | 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 | Required properties: | 3 | Required properties: |
| 4 | - compatible: "mediatek,mt6397-regulator" | 4 | - compatible: "mediatek,mt6397-regulator" |
| @@ -71,7 +71,7 @@ Continuous Voltage With Enable GPIO Example: · 70 unmodified lines | |||
| 71 | * Inverted PWM logic, and the duty cycle range is limited | 71 | * Inverted PWM logic, and the duty cycle range is limited |
| 72 | * to 30%-70%. | 72 | * to 30%-70%. |
| 73 | */ | 73 | */ |
| 74 | pwm-dutycycle-range <700 300>; /* */ | 74 | pwm-dutycycle-range = <700 300>; /* */ |
| 75 | }; | 75 | }; |
| 76 | 76 | ||
| 77 | Voltage Table Example: | 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 | = SUBNODES | 65 | = SUBNODES |
| 66 | The adsp node may have an subnode named "smd-edge" that describes the SMD edge, | 66 | The adsp node may have an subnode named either "smd-edge" or "glink-edge" that |
| 67 | channels and devices related to the ADSP. See ../soc/qcom/qcom,smd.txt for | 67 | describes the communication edge, channels and devices related to the ADSP. |
| 68 | details on how to describe the SMD edge. | 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 | = EXAMPLE | 72 | = EXAMPLE |
| @@ -90,6 +90,11 @@ the memory regions used by the Hexagon firmware. Each sub-node must contain: · 89 unmodified lines | |||
| 90 | Value type: <phandle> | 90 | Value type: <phandle> |
| 91 | Definition: reference to the reserved-memory for the region | 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 | = EXAMPLE | 98 | = EXAMPLE |
| 94 | The following example describes the resources needed to boot control the | 99 | The following example describes the resources needed to boot control the |
| 95 | Hexagon, as it is found on MSM8974 boards. | 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 | "ti,k2hk-dsp" for DSPs on Keystone 2 66AK2H/K SoCs | 26 | "ti,k2hk-dsp" for DSPs on Keystone 2 66AK2H/K SoCs |
| 27 | "ti,k2l-dsp" for DSPs on Keystone 2 66AK2L SoCs | 27 | "ti,k2l-dsp" for DSPs on Keystone 2 66AK2L SoCs |
| 28 | "ti,k2e-dsp" for DSPs on Keystone 2 66AK2E SoCs | 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 | - reg: Should contain an entry for each value in 'reg-names'. | 31 | - reg: Should contain an entry for each value in 'reg-names'. |
| 31 | Each entry should have the memory region's start address | 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 | should be defined in this order, | 38 | should be defined in this order, |
| 38 | "l2sram", "l1pram", "l1dram" | 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 | - ti,syscon-dev: Should be a pair of the phandle to the Keystone Device | 41 | - ti,syscon-dev: Should be a pair of the phandle to the Keystone Device |
| 45 | State Control node, and the register offset of the DSP | 42 | State Control node, and the register offset of the DSP |
| 46 | boot address register within that node's address space. | 43 | boot address register within that node's address space. |
| 47 | 44 | ||
| 48 | - resets: Should contain the phandle to the reset controller node | 45 | - resets: Should contain the phandle to the reset controller node |
| 49 | managing the resets for this device, and a reset | 46 | managing the resets for this device, and a reset |
| 50 | specifier. Please refer to the following reset bindings | 47 | specifier. Please refer to either of the following reset |
| 51 | for the reset argument specifier as per SoC, | 48 | bindings for the reset argument specifier as per SoC, |
| 52 | Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 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 | - interrupt-parent: Should contain a phandle to the Keystone 2 IRQ controller | 54 | - interrupt-parent: Should contain a phandle to the Keystone 2 IRQ controller |
| 56 | IP node that is used by the ARM CorePac processor to | 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 | The gpio device to be used is as per the bindings in, | 74 | The gpio device to be used is as per the bindings in, |
| 76 | Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt | 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 | Optional properties: | 93 | Optional properties: |
| 79 | -------------------- | 94 | -------------------- |
| 80 | 95 | ||
| @@ -85,8 +100,10 @@ Optional properties: · 4 unmodified lines | |||
| 85 | Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt | 100 | Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt |
| 86 | 101 | ||
| 87 | 102 | ||
| 88 | Example: | 103 | Examples: |
| 89 | -------- | 104 | --------- |
| 105 | |||
| 106 | 1. | ||
| 90 | /* 66AK2H/K DSP aliases */ | 107 | /* 66AK2H/K DSP aliases */ |
| 91 | aliases { | 108 | aliases { |
| 92 | rproc0 = &dsp0; | 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 | clock-names = "stmmaceth"; | 80 | clock-names = "stmmaceth"; |
| 81 | resets = <&rgu 22>; | 81 | resets = <&rgu 22>; |
| 82 | reset-names = "stmmaceth"; | 82 | reset-names = "stmmaceth"; |
| 83 | status = "disabled"; | ||
| 84 | }; | 83 | }; |
| @@ -26,6 +26,7 @@ Required properties: · 25 unmodified lines | |||
| 26 | - "renesas,r8a7794-rst" (R-Car E2) | 26 | - "renesas,r8a7794-rst" (R-Car E2) |
| 27 | - "renesas,r8a7795-rst" (R-Car H3) | 27 | - "renesas,r8a7795-rst" (R-Car H3) |
| 28 | - "renesas,r8a7796-rst" (R-Car M3-W) | 28 | - "renesas,r8a7796-rst" (R-Car M3-W) |
| 29 | - "renesas,r8a77995-rst" (R-Car D3) | ||
| 29 | - reg: Address start and address range for the device. | 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 | Required properties: | 7 | Required properties: |
| 8 | - compatible: should be one of the following: | 8 | - compatible: should be one of the following: |
| 9 | "socionext,uniphier-sld3-reset" - for sLD3 SoC | ||
| 10 | "socionext,uniphier-ld4-reset" - for LD4 SoC | 9 | "socionext,uniphier-ld4-reset" - for LD4 SoC |
| 11 | "socionext,uniphier-pro4-reset" - for Pro4 SoC | 10 | "socionext,uniphier-pro4-reset" - for Pro4 SoC |
| 12 | "socionext,uniphier-sld8-reset" - for sLD8 SoC | 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 | Required properties: | 37 | Required properties: |
| 39 | - compatible: should be one of the following: | 38 | - compatible: should be one of the following: |
| 40 | "socionext,uniphier-sld3-mio-reset" - for sLD3 SoC | ||
| 41 | "socionext,uniphier-ld4-mio-reset" - for LD4 SoC | 39 | "socionext,uniphier-ld4-mio-reset" - for LD4 SoC |
| 42 | "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC | 40 | "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC |
| 43 | "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC | 41 | "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC |
| @@ -92,3 +90,28 @@ Example: · 48 unmodified lines | |||
| 92 | 90 | ||
| 93 | other nodes ... | 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 | - "wakeup-source": mark the chip as a wakeup source, independently of | 25 | - "wakeup-source": mark the chip as a wakeup source, independently of |
| 26 | the availability of an IRQ line connected to the SoC. | 26 | the availability of an IRQ line connected to the SoC. |
| 27 | (Legacy property supported: "isil,irq2-can-wakeup-machine") | ||
| 28 | 27 | ||
| 29 | - "interrupt-parent", "interrupts": for passing the interrupt line | 28 | - "interrupt-parent", "interrupts": for passing the interrupt line |
| 30 | of the SoC connected to IRQ#2 of the RTC chip. | 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 | interrupts = <17 1>; | 45 | interrupts = <17 1>; |
| 46 | interrupt-names = "alarm"; | 46 | interrupt-names = "alarm"; |
| 47 | st,syscfg = <&pwrcfg>; | 47 | st,syscfg = <&pwrcfg>; |
| 48 | status = "disabled"; | ||
| 49 | }; | 48 | }; |
| @@ -10,7 +10,7 @@ Required properties: · 9 unmodified lines | |||
| 10 | 10 | ||
| 11 | Required properties for new device trees | 11 | Required properties for new device trees |
| 12 | - clocks : phandle to the 32kHz external oscillator | 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 | - #clock-cells : must be equals to 1. The RTC provides two clocks: the | 14 | - #clock-cells : must be equals to 1. The RTC provides two clocks: the |
| 15 | LOSC and its external output, with index 0 and 1 | 15 | LOSC and its external output, with index 0 and 1 |
| 16 | respectively. | 16 | respectively. |
| @@ -21,7 +21,7 @@ rtc: rtc@01f00000 { · 4 unmodified lines | |||
| 21 | compatible = "allwinner,sun6i-a31-rtc"; | 21 | compatible = "allwinner,sun6i-a31-rtc"; |
| 22 | reg = <0x01f00000 0x54>; | 22 | reg = <0x01f00000 0x54>; |
| 23 | interrupts = <0 40 4>, <0 41 4>; | 23 | interrupts = <0 40 4>, <0 41 4>; |
| 24 | clock-output-names = "osc32k"; | 24 | clock-output-names = "osc32k", "osc32k-out"; |
| 25 | clocks = <&ext_osc32k>; | 25 | clocks = <&ext_osc32k>; |
| 26 | #clock-cells = <1>; | 26 | #clock-cells = <1>; |
| 27 | }; | 27 | }; |
| @@ -85,5 +85,4 @@ Example: · 84 unmodified lines | |||
| 85 | <366 1>,<367 1>/* cq30-31 */ | 85 | <366 1>,<367 1>/* cq30-31 */ |
| 86 | <376 4>,/* fatal ecc */ | 86 | <376 4>,/* fatal ecc */ |
| 87 | <381 4>;/* fatal axi */ | 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 | &i2c2 { | 20 | &i2c2 { |
| 21 | 21 | ||
| 22 | status = "okay"; | ||
| 23 | 22 | ||
| 24 | st33zp24: st33zp24@13 { | 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 | &mcspi4 { | 19 | &mcspi4 { |
| 20 | 20 | ||
| 21 | status = "okay"; | ||
| 22 | 21 | ||
| 23 | st33zp24@0 { | 22 | st33zp24@0 { |
| 24 | 23 | ||
| @@ -8,6 +8,12 @@ Required properties: · 7 unmodified lines | |||
| 8 | the firmware event log | 8 | the firmware event log |
| 9 | - linux,sml-size : size of the memory allocated for the firmware event log | 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 | Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C) | 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 | compatible = "nuvoton,npct650", "nuvoton,npct601"; | 23 | compatible = "nuvoton,npct650", "nuvoton,npct601"; |
| 18 | linux,sml-base = <0x7f 0xfd450000>; | 24 | linux,sml-base = <0x7f 0xfd450000>; |
| 19 | linux,sml-size = <0x10000>; | 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 | &mcspi4 { | 14 | &mcspi4 { |
| 15 | 15 | ||
| 16 | status = "okay"; | ||
| 17 | 16 | ||
| 18 | tpm_tis@0 { | 17 | tpm_tis@0 { |
| 19 | 18 | ||
| @@ -14,6 +14,8 @@ Required properties: · 13 unmodified lines | |||
| 14 | tegra132, or tegra210. | 14 | tegra132, or tegra210. |
| 15 | - "nxp,lpc3220-uart" | 15 | - "nxp,lpc3220-uart" |
| 16 | - "ralink,rt2880-uart" | 16 | - "ralink,rt2880-uart" |
| 17 | - For MediaTek BTIF, must contain '"mediatek,<chip>-btif", | ||
| 18 | "mediatek,mtk-btif"' where <chip> is mt7622, mt7623. | ||
| 17 | - "altr,16550-FIFO32" | 19 | - "altr,16550-FIFO32" |
| 18 | - "altr,16550-FIFO64" | 20 | - "altr,16550-FIFO64" |
| 19 | - "altr,16550-FIFO128" | 21 | - "altr,16550-FIFO128" |
| @@ -15,7 +15,6 @@ arcuart0: serial@c0fc1000 { · 14 unmodified lines | |||
| 15 | interrupts = <5>; | 15 | interrupts = <5>; |
| 16 | clock-frequency = <80000000>; | 16 | clock-frequency = <80000000>; |
| 17 | current-speed = <115200>; | 17 | current-speed = <115200>; |
| 18 | status = "okay"; | ||
| 19 | }; | 18 | }; |
| 20 | 19 | ||
| 21 | Note: Each port should have an alias correctly numbered in "aliases" node. | 20 | Note: Each port should have an alias correctly numbered in "aliases" node. |
| @@ -15,7 +15,6 @@ serial@b00260000 { · 14 unmodified lines | |||
| 15 | compatible = "axis,etraxfs-uart"; | 15 | compatible = "axis,etraxfs-uart"; |
| 16 | reg = <0xb0026000 0x1000>; | 16 | reg = <0xb0026000 0x1000>; |
| 17 | interrupts = <68>; | 17 | interrupts = <68>; |
| 18 | status = "disabled"; | ||
| 19 | dtr-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>; | 18 | dtr-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>; |
| 20 | dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>; | 19 | dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>; |
| 21 | rng-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>; | 20 | rng-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>; |
| @@ -3,6 +3,7 @@ · 2 unmodified lines | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible should contain: | 4 | - compatible should contain: |
| 5 | * "mediatek,mt2701-uart" for MT2701 compatible UARTS | 5 | * "mediatek,mt2701-uart" for MT2701 compatible UARTS |
| 6 | * "mediatek,mt2712-uart" for MT2712 compatible UARTS | ||
| 6 | * "mediatek,mt6580-uart" for MT6580 compatible UARTS | 7 | * "mediatek,mt6580-uart" for MT6580 compatible UARTS |
| 7 | * "mediatek,mt6582-uart" for MT6582 compatible UARTS | 8 | * "mediatek,mt6582-uart" for MT6582 compatible UARTS |
| 8 | * "mediatek,mt6589-uart" for MT6589 compatible UARTS | 9 | * "mediatek,mt6589-uart" for MT6589 compatible UARTS |
| @@ -33,5 +33,4 @@ serial@70006000 { · 32 unmodified lines | |||
| 33 | reset-names = "serial"; | 33 | reset-names = "serial"; |
| 34 | dmas = <&apbdma 8>, <&apbdma 8>; | 34 | dmas = <&apbdma 8>, <&apbdma 8>; |
| 35 | dma-names = "rx", "tx"; | 35 | dma-names = "rx", "tx"; |
| 36 | status = "disabled"; | ||
| 37 | }; | 36 | }; |
| @@ -72,13 +72,10 @@ Examples: · 71 unmodified lines | |||
| 72 | }; | 72 | }; |
| 73 | 73 | ||
| 74 | uarta: serial@12490000 { | 74 | uarta: serial@12490000 { |
| 75 | status = "ok"; | ||
| 76 | }; | 75 | }; |
| 77 | 76 | ||
| 78 | uartb: serial@16340000 { | 77 | uartb: serial@16340000 { |
| 79 | status = "ok"; | ||
| 80 | }; | 78 | }; |
| 81 | 79 | ||
| 82 | uartc: serial@1a240000 { | 80 | uartc: serial@1a240000 { |
| 83 | status = "ok"; | ||
| 84 | }; | 81 | }; |
| @@ -41,6 +41,8 @@ Required properties: · 40 unmodified lines | |||
| 41 | - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART. | 41 | - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART. |
| 42 | - "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART. | 42 | - "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART. |
| 43 | - "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART. | 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 | - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. | 46 | - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. |
| 45 | - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. | 47 | - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. |
| 46 | - "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART, | 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 | The properties described hereafter shall be given to a half-duplex capable | 5 | The properties described hereafter shall be given to a half-duplex capable |
| 6 | UART node. | 6 | UART node. |
| 7 | 7 | ||
| 8 | Required properties: | 8 | Optional properties: |
| 9 | - rs485-rts-delay: prop-encoded-array <a b> where: | 9 | - rs485-rts-delay: prop-encoded-array <a b> where: |
| 10 | * a is the delay between rts signal and beginning of data sent in milliseconds. | 10 | * a is the delay between rts signal and beginning of data sent in milliseconds. |
| 11 | it corresponds to the delay before sending data. | 11 | it corresponds to the delay before sending data. |
| 12 | * b is the delay between end of data sent and rts signal in milliseconds | 12 | * b is the delay between end of data sent and rts signal in milliseconds |
| 13 | it corresponds to the delay after sending data and actual release of the line. | 13 | it corresponds to the delay after sending data and actual release of the line. |
| 14 | 14 | If this property is not specified, <0 0> is assumed. | |
| 15 | Optional properties: | ||
| 16 | - linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485 | 15 | - linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485 |
| 17 | feature at boot time. It can be disabled later with proper ioctl. | 16 | feature at boot time. It can be disabled later with proper ioctl. |
| 18 | - rs485-rx-during-tx: empty property that enables the receiving of data even | 17 | - rs485-rx-during-tx: empty property that enables the receiving of data even |
| @@ -43,7 +43,6 @@ Examples: · 42 unmodified lines | |||
| 43 | rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; | 43 | rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; |
| 44 | cts-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; | 44 | cts-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; |
| 45 | rts-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; | 45 | rts-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; |
| 46 | status = "okay"; | ||
| 47 | }; | 46 | }; |
| 48 | 47 | ||
| 49 | scifa4: serial@e6c80000 { | 48 | scifa4: serial@e6c80000 { |
| @@ -54,5 +53,4 @@ Examples: · 4 unmodified lines | |||
| 54 | clock-names = "fck"; | 53 | clock-names = "fck"; |
| 55 | power-domains = <&pd_a3sp>; | 54 | power-domains = <&pd_a3sp>; |
| 56 | uart-has-rtscts; | 55 | uart-has-rtscts; |
| 57 | status = "okay"; | ||
| 58 | }; | 56 | }; |
| @@ -1,12 +1,19 @@ | |||
| 1 | * STMicroelectronics STM32 USART | 1 | * STMicroelectronics STM32 USART |
| 2 | 2 | ||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: Can be either "st,stm32-usart", "st,stm32-uart", | 4 | - compatible: can be either: |
| 5 | "st,stm32f7-usart" or "st,stm32f7-uart" depending on whether | 5 | - "st,stm32-usart", |
| 6 | the device supports synchronous mode and is compatible with | 6 | - "st,stm32-uart", |
| 7 | stm32(f4) or stm32f7. | 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 | - reg: The address and length of the peripheral registers space | 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 | - clocks: The input clock of the USART instance | 17 | - clocks: The input clock of the USART instance |
| 11 | 18 | ||
| 12 | Optional properties: | 19 | Optional properties: |
| @@ -19,5 +19,4 @@ Example: · 18 unmodified lines | |||
| 19 | reg = <0x01c2a000 0x400>; | 19 | reg = <0x01c2a000 0x400>; |
| 20 | interrupts = <0 62 4>; | 20 | interrupts = <0 62 4>; |
| 21 | clocks = <&apb1_gates 6>; | 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 | - include/dt-bindings/power/mt8173-power.h | 12 | - include/dt-bindings/power/mt8173-power.h |
| 13 | - include/dt-bindings/power/mt6797-power.h | 13 | - include/dt-bindings/power/mt6797-power.h |
| 14 | - include/dt-bindings/power/mt2701-power.h | 14 | - include/dt-bindings/power/mt2701-power.h |
| 15 | - include/dt-bindings/power/mt7622-power.h | ||
| 15 | 16 | ||
| 16 | Required properties: | 17 | Required properties: |
| 17 | - compatible: Should be one of: | 18 | - compatible: Should be one of: |
| 18 | - "mediatek,mt2701-scpsys" | 19 | - "mediatek,mt2701-scpsys" |
| 19 | - "mediatek,mt6797-scpsys" | 20 | - "mediatek,mt6797-scpsys" |
| 21 | - "mediatek,mt7622-scpsys" | ||
| 20 | - "mediatek,mt8173-scpsys" | 22 | - "mediatek,mt8173-scpsys" |
| 21 | - #power-domain-cells: Must be 1 | 23 | - #power-domain-cells: Must be 1 |
| 22 | - reg: Address range of the SCPSYS unit | 24 | - reg: Address range of the SCPSYS unit |
| @@ -26,6 +28,7 @@ Required properties: · 3 unmodified lines | |||
| 26 | enabled before enabling certain power domains. | 28 | enabled before enabling certain power domains. |
| 27 | Required clocks for MT2701: "mm", "mfg", "ethif" | 29 | Required clocks for MT2701: "mm", "mfg", "ethif" |
| 28 | Required clocks for MT6797: "mm", "mfg", "vdec" | 30 | Required clocks for MT6797: "mm", "mfg", "vdec" |
| 31 | Required clocks for MT7622: "hif_sel" | ||
| 29 | Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" | 32 | Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt" |
| 30 | 33 | ||
| 31 | Optional properties: | 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 | 3 | This binding describes a Qualcomm GLINK edge, a fifo based mechanism for |
| 4 | communication with the Resource Power Management system on various Qualcomm | 4 | communication between subsystem-pairs on various Qualcomm platforms. Two types |
| 5 | platforms. | 5 | of edges can be described by the binding; the GLINK RPM edge and a SMEM based |
| 6 | edge. | ||
| 6 | 7 | ||
| 7 | - compatible: | 8 | - compatible: |
| 8 | Usage: required | 9 | Usage: required for glink-rpm |
| 9 | Value type: <stringlist> | 10 | Value type: <stringlist> |
| 10 | Definition: must be "qcom,glink-rpm" | 11 | Definition: must be "qcom,glink-rpm" |
| 11 | 12 | ||
| @@ -16,7 +17,7 @@ platforms. · 4 unmodified lines | |||
| 16 | signal this processor about communication related events | 17 | signal this processor about communication related events |
| 17 | 18 | ||
| 18 | - qcom,rpm-msg-ram: | 19 | - qcom,rpm-msg-ram: |
| 19 | Usage: required | 20 | Usage: required for glink-rpm |
| 20 | Value type: <prop-encoded-array> | 21 | Value type: <prop-encoded-array> |
| 21 | Definition: handle to RPM message memory resource | 22 | Definition: handle to RPM message memory resource |
| 22 | 23 | ||
| @@ -78,7 +78,6 @@ Example for APQ8064: · 77 unmodified lines | |||
| 78 | interrupts = <0 152 0x0>; | 78 | interrupts = <0 152 0x0>; |
| 79 | clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; | 79 | clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; |
| 80 | clock-names = "core", "iface"; | 80 | clock-names = "core", "iface"; |
| 81 | status = "ok"; | ||
| 82 | }; | 81 | }; |
| 83 | }; | 82 | }; |
| 84 | 83 | ||
| @@ -21,6 +21,7 @@ Required Properties: · 20 unmodified lines | |||
| 21 | - "rockchip,rk3328-grf", "syscon": for rk3328 | 21 | - "rockchip,rk3328-grf", "syscon": for rk3328 |
| 22 | - "rockchip,rk3368-grf", "syscon": for rk3368 | 22 | - "rockchip,rk3368-grf", "syscon": for rk3368 |
| 23 | - "rockchip,rk3399-grf", "syscon": for rk3399 | 23 | - "rockchip,rk3399-grf", "syscon": for rk3399 |
| 24 | - "rockchip,rv1108-grf", "syscon": for rv1108 | ||
| 24 | - compatible: PMUGRF should be one of the following: | 25 | - compatible: PMUGRF should be one of the following: |
| 25 | - "rockchip,rk3368-pmugrf", "syscon": for rk3368 | 26 | - "rockchip,rk3368-pmugrf", "syscon": for rk3368 |
| 26 | - "rockchip,rk3399-pmugrf", "syscon": for rk3399 | 27 | - "rockchip,rk3399-pmugrf", "syscon": for rk3399 |
| @@ -28,6 +29,8 @@ Required Properties: · 1 unmodified line | |||
| 28 | - "rockchip,rk3288-sgrf", "syscon": for rk3288 | 29 | - "rockchip,rk3288-sgrf", "syscon": for rk3288 |
| 29 | - compatible: USB2PHYGRF should be one of the followings | 30 | - compatible: USB2PHYGRF should be one of the followings |
| 30 | - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328 | 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 | - reg: physical base address of the controller and length of memory mapped | 34 | - reg: physical base address of the controller and length of memory mapped |
| 32 | region. | 35 | region. |
| 33 | 36 | ||
| @@ -7,6 +7,7 @@ Required properties for power domain controller: · 6 unmodified lines | |||
| 7 | - compatible: Should be one of the following. | 7 | - compatible: Should be one of the following. |
| 8 | "rockchip,rk3288-power-controller" - for RK3288 SoCs. | 8 | "rockchip,rk3288-power-controller" - for RK3288 SoCs. |
| 9 | "rockchip,rk3328-power-controller" - for RK3328 SoCs. | 9 | "rockchip,rk3328-power-controller" - for RK3328 SoCs. |
| 10 | "rockchip,rk3366-power-controller" - for RK3366 SoCs. | ||
| 10 | "rockchip,rk3368-power-controller" - for RK3368 SoCs. | 11 | "rockchip,rk3368-power-controller" - for RK3368 SoCs. |
| 11 | "rockchip,rk3399-power-controller" - for RK3399 SoCs. | 12 | "rockchip,rk3399-power-controller" - for RK3399 SoCs. |
| 12 | - #power-domain-cells: Number of cells in a power-domain specifier. | 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 | - reg: index of the power domain, should use macros in: | 19 | - reg: index of the power domain, should use macros in: |
| 19 | "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain. | 20 | "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain. |
| 20 | "include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain. | 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 | "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain. | 23 | "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain. |
| 22 | "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain. | 24 | "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain. |
| 23 | - clocks (optional): phandles to clocks which need to be enabled while power domain | 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 | The index should use macros in: | 95 | The index should use macros in: |
| 94 | "include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain. | 96 | "include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain. |
| 95 | "include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain. | 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 | "include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain. | 99 | "include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain. |
| 97 | "include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain. | 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 | - power-domains: phandle pointing to the corresponding PM domain node | 46 | - power-domains: phandle pointing to the corresponding PM domain node |
| 47 | and an ID representing the device. | 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 | Example (K2G): | 52 | Example (K2G): |
| 52 | -------------------- | 53 | -------------------- |
| 53 | uart0: serial@02530c00 { | 54 | uart0: serial@02530c00 { |
| 54 | compatible = "ns16550a"; | 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 | compatible = "marvell,a370db-audio"; | 23 | compatible = "marvell,a370db-audio"; |
| 24 | marvell,audio-controller = <&audio_controller>; | 24 | marvell,audio-controller = <&audio_controller>; |
| 25 | marvell,audio-codec = <&audio_codec &spdif_out &spdif_in>; | 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 | Must be "tx". | 13 | Must be "tx". |
| 14 | - clock-names | 14 | - clock-names |
| 15 | Tuple listing input clock names. | 15 | Tuple listing input clock names. |
| 16 | Required elements: "pclk", "gclk" and "aclk". | 16 | Required elements: "pclk" and "gclk". |
| 17 | - clocks | 17 | - clocks |
| 18 | Please refer to clock-bindings.txt. | 18 | Please refer to clock-bindings.txt. |
| 19 | - assigned-clocks | 19 | - assigned-clocks |
| 20 | Should be <&classd_gclk>. | 20 | Should be <&classd_gclk>. |
| 21 | - assigned-clock-parents | ||
| 22 | Should be <&audio_pll_pmc>. | ||
| 23 | 21 | ||
| 24 | Optional properties: | 22 | Optional properties: |
| 25 | - pinctrl-names, pinctrl-0 | 23 | - pinctrl-names, pinctrl-0 |
| @@ -45,10 +43,9 @@ classd: classd@fc048000 { · 19 unmodified lines | |||
| 45 | (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | 43 | (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
| 46 | | AT91_XDMAC_DT_PERID(47))>; | 44 | | AT91_XDMAC_DT_PERID(47))>; |
| 47 | dma-names = "tx"; | 45 | dma-names = "tx"; |
| 48 | clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>; | 46 | clocks = <&classd_clk>, <&classd_gclk>; |
| 49 | clock-names = "pclk", "gclk", "aclk"; | 47 | clock-names = "pclk", "gclk"; |
| 50 | assigned-clocks = <&classd_gclk>; | 48 | assigned-clocks = <&classd_gclk>; |
| 51 | assigned-clock-parents = <&audio_pll_pmc>; | ||
| 52 | 49 | ||
| 53 | pinctrl-names = "default"; | 50 | pinctrl-names = "default"; |
| 54 | pinctrl-0 = <&pinctrl_classd_default>; | 51 | pinctrl-0 = <&pinctrl_classd_default>; |
| @@ -45,7 +45,6 @@ Example: · 44 unmodified lines | |||
| 45 | &ssc0 { | 45 | &ssc0 { |
| 46 | #sound-dai-cells = <0>; | 46 | #sound-dai-cells = <0>; |
| 47 | 47 | ||
| 48 | status = "okay"; | ||
| 49 | }; | 48 | }; |
| 50 | 49 | ||
| 51 | &i2c { | 50 | &i2c { |
| @@ -47,21 +47,17 @@ Example: · 46 unmodified lines | |||
| 47 | 47 | ||
| 48 | ssp0: ssp_port@0 { | 48 | ssp0: ssp_port@0 { |
| 49 | reg = <0>; | 49 | reg = <0>; |
| 50 | status = "okay"; | ||
| 51 | }; | 50 | }; |
| 52 | 51 | ||
| 53 | ssp1: ssp_port@1 { | 52 | ssp1: ssp_port@1 { |
| 54 | reg = <1>; | 53 | reg = <1>; |
| 55 | status = "disabled"; | ||
| 56 | }; | 54 | }; |
| 57 | 55 | ||
| 58 | ssp2: ssp_port@2 { | 56 | ssp2: ssp_port@2 { |
| 59 | reg = <2>; | 57 | reg = <2>; |
| 60 | status = "disabled"; | ||
| 61 | }; | 58 | }; |
| 62 | 59 | ||
| 63 | spdif: spdif_port@3 { | 60 | spdif: spdif_port@3 { |
| 64 | reg = <3>; | 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 | dmas = <&edma0 3 1 | 47 | dmas = <&edma0 3 1 |
| 48 | &edma0 2 1>; | 48 | &edma0 2 1>; |
| 49 | dma-names = "tx", "rx"; | 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 | "txa", "txb", "txc"; | 61 | "txa", "txb", "txc"; |
| 62 | fsl,asrc-rate = <48000>; | 62 | fsl,asrc-rate = <48000>; |
| 63 | fsl,asrc-width = <16>; | 63 | fsl,asrc-width = <16>; |
| 64 | status = "okay"; | ||
| 65 | }; | 64 | }; |
| @@ -59,5 +59,4 @@ esai: esai@02024000 { · 58 unmodified lines | |||
| 59 | fsl,fifo-depth = <128>; | 59 | fsl,fifo-depth = <128>; |
| 60 | fsl,esai-synchronous; | 60 | fsl,esai-synchronous; |
| 61 | big-endian; | 61 | big-endian; |
| 62 | status = "disabled"; | ||
| 63 | }; | 62 | }; |
| @@ -59,5 +59,4 @@ spdif: spdif@02004000 { · 58 unmodified lines | |||
| 59 | "rxtx7"; | 59 | "rxtx7"; |
| 60 | 60 | ||
| 61 | big-endian; | 61 | big-endian; |
| 62 | status = "okay"; | ||
| 63 | }; | 62 | }; |
| @@ -13,5 +13,4 @@ Example node: · 12 unmodified lines | |||
| 13 | 13 | ||
| 14 | hdmi_audio: hdmi_audio@0 { | 14 | hdmi_audio: hdmi_audio@0 { |
| 15 | compatible = "linux,hdmi-audio"; | 15 | compatible = "linux,hdmi-audio"; |
| 16 | status = "okay"; | ||
| 17 | }; | 16 | }; |
| @@ -3,7 +3,8 @@ Mediatek AFE PCM controller for mt2701 · 2 unmodified lines | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible = "mediatek,mt2701-audio"; | 4 | - compatible = "mediatek,mt2701-audio"; |
| 5 | - reg: register location and size | 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 | - power-domains: should define the power domain | 8 | - power-domains: should define the power domain |
| 8 | - clock-names: should have these clock names: | 9 | - clock-names: should have these clock names: |
| 9 | "infra_sys_audio_clk", | 10 | "infra_sys_audio_clk", |
| @@ -59,6 +60,7 @@ Example: · 49 unmodified lines | |||
| 59 | <0 0x112A0000 0 0x20000>; | 60 | <0 0x112A0000 0 0x20000>; |
| 60 | interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>, | 61 | interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>, |
| 61 | <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>; | 62 | <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>; |
| 63 | interrupt-names = "afe", "asys"; | ||
| 62 | power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>; | 64 | power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>; |
| 63 | clocks = <&infracfg CLK_INFRA_AUDIO>, | 65 | clocks = <&infracfg CLK_INFRA_AUDIO>, |
| 64 | <&topckgen CLK_TOP_AUD_MUX1_SEL>, | 66 | <&topckgen CLK_TOP_AUD_MUX1_SEL>, |
| @@ -31,8 +31,22 @@ Required properties · 30 unmodified lines | |||
| 31 | - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node. | 31 | - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node. |
| 32 | - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node. | 32 | - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node. |
| 33 | - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node. | 33 | - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node. |
| 34 | |||
| 35 | Optional Properties: | 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 | - qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor | 50 | - qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor |
| 37 | connected. | 51 | connected. |
| 38 | - qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor | 52 | - qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor |
| @@ -48,6 +62,8 @@ spmi_bus { · 9 unmodified lines | |||
| 48 | reg-names = "pmic-codec-core"; | 62 | reg-names = "pmic-codec-core"; |
| 49 | clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>; | 63 | clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>; |
| 50 | clock-names = "mclk"; | 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 | interrupt-parent = <&spmi_bus>; | 67 | interrupt-parent = <&spmi_bus>; |
| 52 | interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>, | 68 | interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>, |
| 53 | <0x1 0xf0 0x1 IRQ_TYPE_NONE>, | 69 | <0x1 0xf0 0x1 IRQ_TYPE_NONE>, |
| @@ -199,10 +199,10 @@ Ex) · 198 unmodified lines | |||
| 199 | sound { | 199 | sound { |
| 200 | compatible = "simple-scu-audio-card"; | 200 | compatible = "simple-scu-audio-card"; |
| 201 | ... | 201 | ... |
| 202 | simple-audio-card,cpu@0 { | 202 | simple-audio-card,cpu-0 { |
| 203 | sound-dai = <&rcar_sound 0>; | 203 | sound-dai = <&rcar_sound 0>; |
| 204 | }; | 204 | }; |
| 205 | simple-audio-card,cpu@1 { | 205 | simple-audio-card,cpu-1 { |
| 206 | sound-dai = <&rcar_sound 1>; | 206 | sound-dai = <&rcar_sound 1>; |
| 207 | }; | 207 | }; |
| 208 | simple-audio-card,codec { | 208 | simple-audio-card,codec { |
| @@ -441,79 +441,79 @@ rcar_sound: sound@ec500000 { · 232 unmodified lines | |||
| 441 | "clk_a", "clk_b", "clk_c", "clk_i"; | 441 | "clk_a", "clk_b", "clk_c", "clk_i"; |
| 442 | 442 | ||
| 443 | rcar_sound,dvc { | 443 | rcar_sound,dvc { |
| 444 | dvc0: dvc@0 { | 444 | dvc0: dvc-0 { |
| 445 | dmas = <&audma0 0xbc>; | 445 | dmas = <&audma0 0xbc>; |
| 446 | dma-names = "tx"; | 446 | dma-names = "tx"; |
| 447 | }; | 447 | }; |
| 448 | dvc1: dvc@1 { | 448 | dvc1: dvc-1 { |
| 449 | dmas = <&audma0 0xbe>; | 449 | dmas = <&audma0 0xbe>; |
| 450 | dma-names = "tx"; | 450 | dma-names = "tx"; |
| 451 | }; | 451 | }; |
| 452 | }; | 452 | }; |
| 453 | 453 | ||
| 454 | rcar_sound,mix { | 454 | rcar_sound,mix { |
| 455 | mix0: mix@0 { }; | 455 | mix0: mix-0 { }; |
| 456 | mix1: mix@1 { }; | 456 | mix1: mix-1 { }; |
| 457 | }; | 457 | }; |
| 458 | 458 | ||
| 459 | rcar_sound,ctu { | 459 | rcar_sound,ctu { |
| 460 | ctu00: ctu@0 { }; | 460 | ctu00: ctu-0 { }; |
| 461 | ctu01: ctu@1 { }; | 461 | ctu01: ctu-1 { }; |
| 462 | ctu02: ctu@2 { }; | 462 | ctu02: ctu-2 { }; |
| 463 | ctu03: ctu@3 { }; | 463 | ctu03: ctu-3 { }; |
| 464 | ctu10: ctu@4 { }; | 464 | ctu10: ctu-4 { }; |
| 465 | ctu11: ctu@5 { }; | 465 | ctu11: ctu-5 { }; |
| 466 | ctu12: ctu@6 { }; | 466 | ctu12: ctu-6 { }; |
| 467 | ctu13: ctu@7 { }; | 467 | ctu13: ctu-7 { }; |
| 468 | }; | 468 | }; |
| 469 | 469 | ||
| 470 | rcar_sound,src { | 470 | rcar_sound,src { |
| 471 | src0: src@0 { | 471 | src0: src-0 { |
| 472 | interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>; | 472 | interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>; |
| 473 | dmas = <&audma0 0x85>, <&audma1 0x9a>; | 473 | dmas = <&audma0 0x85>, <&audma1 0x9a>; |
| 474 | dma-names = "rx", "tx"; | 474 | dma-names = "rx", "tx"; |
| 475 | }; | 475 | }; |
| 476 | src1: src@1 { | 476 | src1: src-1 { |
| 477 | interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>; | 477 | interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>; |
| 478 | dmas = <&audma0 0x87>, <&audma1 0x9c>; | 478 | dmas = <&audma0 0x87>, <&audma1 0x9c>; |
| 479 | dma-names = "rx", "tx"; | 479 | dma-names = "rx", "tx"; |
| 480 | }; | 480 | }; |
| 481 | src2: src@2 { | 481 | src2: src-2 { |
| 482 | interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>; | 482 | interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>; |
| 483 | dmas = <&audma0 0x89>, <&audma1 0x9e>; | 483 | dmas = <&audma0 0x89>, <&audma1 0x9e>; |
| 484 | dma-names = "rx", "tx"; | 484 | dma-names = "rx", "tx"; |
| 485 | }; | 485 | }; |
| 486 | src3: src@3 { | 486 | src3: src-3 { |
| 487 | interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>; | 487 | interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>; |
| 488 | dmas = <&audma0 0x8b>, <&audma1 0xa0>; | 488 | dmas = <&audma0 0x8b>, <&audma1 0xa0>; |
| 489 | dma-names = "rx", "tx"; | 489 | dma-names = "rx", "tx"; |
| 490 | }; | 490 | }; |
| 491 | src4: src@4 { | 491 | src4: src-4 { |
| 492 | interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>; | 492 | interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>; |
| 493 | dmas = <&audma0 0x8d>, <&audma1 0xb0>; | 493 | dmas = <&audma0 0x8d>, <&audma1 0xb0>; |
| 494 | dma-names = "rx", "tx"; | 494 | dma-names = "rx", "tx"; |
| 495 | }; | 495 | }; |
| 496 | src5: src@5 { | 496 | src5: src-5 { |
| 497 | interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>; | 497 | interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>; |
| 498 | dmas = <&audma0 0x8f>, <&audma1 0xb2>; | 498 | dmas = <&audma0 0x8f>, <&audma1 0xb2>; |
| 499 | dma-names = "rx", "tx"; | 499 | dma-names = "rx", "tx"; |
| 500 | }; | 500 | }; |
| 501 | src6: src@6 { | 501 | src6: src-6 { |
| 502 | interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>; | 502 | interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>; |
| 503 | dmas = <&audma0 0x91>, <&audma1 0xb4>; | 503 | dmas = <&audma0 0x91>, <&audma1 0xb4>; |
| 504 | dma-names = "rx", "tx"; | 504 | dma-names = "rx", "tx"; |
| 505 | }; | 505 | }; |
| 506 | src7: src@7 { | 506 | src7: src-7 { |
| 507 | interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>; | 507 | interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>; |
| 508 | dmas = <&audma0 0x93>, <&audma1 0xb6>; | 508 | dmas = <&audma0 0x93>, <&audma1 0xb6>; |
| 509 | dma-names = "rx", "tx"; | 509 | dma-names = "rx", "tx"; |
| 510 | }; | 510 | }; |
| 511 | src8: src@8 { | 511 | src8: src-8 { |
| 512 | interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>; | 512 | interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>; |
| 513 | dmas = <&audma0 0x95>, <&audma1 0xb8>; | 513 | dmas = <&audma0 0x95>, <&audma1 0xb8>; |
| 514 | dma-names = "rx", "tx"; | 514 | dma-names = "rx", "tx"; |
| 515 | }; | 515 | }; |
| 516 | src9: src@9 { | 516 | src9: src-9 { |
| 517 | interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>; | 517 | interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>; |
| 518 | dmas = <&audma0 0x97>, <&audma1 0xba>; | 518 | dmas = <&audma0 0x97>, <&audma1 0xba>; |
| 519 | dma-names = "rx", "tx"; | 519 | dma-names = "rx", "tx"; |
| @@ -521,52 +521,52 @@ rcar_sound: sound@ec500000 { · 1 unmodified line | |||
| 521 | }; | 521 | }; |
| 522 | 522 | ||
| 523 | rcar_sound,ssi { | 523 | rcar_sound,ssi { |
| 524 | ssi0: ssi@0 { | 524 | ssi0: ssi-0 { |
| 525 | interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>; | 525 | interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>; |
| 526 | dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>; | 526 | dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>; |
| 527 | dma-names = "rx", "tx", "rxu", "txu"; | 527 | dma-names = "rx", "tx", "rxu", "txu"; |
| 528 | }; | 528 | }; |
| 529 | ssi1: ssi@1 { | 529 | ssi1: ssi-1 { |
| 530 | interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>; | 530 | interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>; |
| 531 | dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>; | 531 | dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>; |
| 532 | dma-names = "rx", "tx", "rxu", "txu"; | 532 | dma-names = "rx", "tx", "rxu", "txu"; |
| 533 | }; | 533 | }; |
| 534 | ssi2: ssi@2 { | 534 | ssi2: ssi-2 { |
| 535 | interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>; | 535 | interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>; |
| 536 | dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>; | 536 | dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>; |
| 537 | dma-names = "rx", "tx", "rxu", "txu"; | 537 | dma-names = "rx", "tx", "rxu", "txu"; |
| 538 | }; | 538 | }; |
| 539 | ssi3: ssi@3 { | 539 | ssi3: ssi-3 { |
| 540 | interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>; | 540 | interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>; |
| 541 | dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>; | 541 | dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>; |
| 542 | dma-names = "rx", "tx", "rxu", "txu"; | 542 | dma-names = "rx", "tx", "rxu", "txu"; |
| 543 | }; | 543 | }; |
| 544 | ssi4: ssi@4 { | 544 | ssi4: ssi-4 { |
| 545 | interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>; | 545 | interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>; |
| 546 | dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>; | 546 | dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>; |
| 547 | dma-names = "rx", "tx", "rxu", "txu"; | 547 | dma-names = "rx", "tx", "rxu", "txu"; |
| 548 | }; | 548 | }; |
| 549 | ssi5: ssi@5 { | 549 | ssi5: ssi-5 { |
| 550 | interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>; | 550 | interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>; |
| 551 | dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>; | 551 | dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>; |
| 552 | dma-names = "rx", "tx", "rxu", "txu"; | 552 | dma-names = "rx", "tx", "rxu", "txu"; |
| 553 | }; | 553 | }; |
| 554 | ssi6: ssi@6 { | 554 | ssi6: ssi-6 { |
| 555 | interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>; | 555 | interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>; |
| 556 | dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>; | 556 | dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>; |
| 557 | dma-names = "rx", "tx", "rxu", "txu"; | 557 | dma-names = "rx", "tx", "rxu", "txu"; |
| 558 | }; | 558 | }; |
| 559 | ssi7: ssi@7 { | 559 | ssi7: ssi-7 { |
| 560 | interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>; | 560 | interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>; |
| 561 | dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>; | 561 | dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>; |
| 562 | dma-names = "rx", "tx", "rxu", "txu"; | 562 | dma-names = "rx", "tx", "rxu", "txu"; |
| 563 | }; | 563 | }; |
| 564 | ssi8: ssi@8 { | 564 | ssi8: ssi-8 { |
| 565 | interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>; | 565 | interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>; |
| 566 | dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>; | 566 | dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>; |
| 567 | dma-names = "rx", "tx", "rxu", "txu"; | 567 | dma-names = "rx", "tx", "rxu", "txu"; |
| 568 | }; | 568 | }; |
| 569 | ssi9: ssi@9 { | 569 | ssi9: ssi-9 { |
| 570 | interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>; | 570 | interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>; |
| 571 | dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>; | 571 | dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>; |
| 572 | dma-names = "rx", "tx", "rxu", "txu"; | 572 | dma-names = "rx", "tx", "rxu", "txu"; |
| @@ -621,7 +621,6 @@ Example: simple sound card · 48 unmodified lines | |||
| 621 | /* Single DAI */ | 621 | /* Single DAI */ |
| 622 | #sound-dai-cells = <0>; | 622 | #sound-dai-cells = <0>; |
| 623 | 623 | ||
| 624 | status = "okay"; | ||
| 625 | 624 | ||
| 626 | rcar_sound,dai { | 625 | rcar_sound,dai { |
| 627 | dai0 { | 626 | dai0 { |
| @@ -667,7 +666,6 @@ Example: simple sound card for Multi channel · 39 unmodified lines | |||
| 667 | /* Single DAI */ | 666 | /* Single DAI */ |
| 668 | #sound-dai-cells = <0>; | 667 | #sound-dai-cells = <0>; |
| 669 | 668 | ||
| 670 | status = "okay"; | ||
| 671 | 669 | ||
| 672 | rcar_sound,dai { | 670 | rcar_sound,dai { |
| 673 | dai0 { | 671 | dai0 { |
| @@ -29,11 +29,13 @@ pdm: pdm@ff040000 { · 28 unmodified lines | |||
| 29 | dma-names = "rx"; | 29 | dma-names = "rx"; |
| 30 | pinctrl-names = "default", "sleep"; | 30 | pinctrl-names = "default", "sleep"; |
| 31 | pinctrl-0 = <&pdmm0_clk | 31 | pinctrl-0 = <&pdmm0_clk |
| 32 | &pdmm0_fsync | ||
| 33 | &pdmm0_sdi0 | 32 | &pdmm0_sdi0 |
| 34 | &pdmm0_sdi1 | 33 | &pdmm0_sdi1 |
| 35 | &pdmm0_sdi2 | 34 | &pdmm0_sdi2 |
| 36 | &pdmm0_sdi3>; | 35 | &pdmm0_sdi3>; |
| 37 | pinctrl-1 = <&pdmm0_sleep>; | 36 | pinctrl-1 = <&pdmm0_clk_sleep |
| 38 | status = "disabled"; | 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 | - compatible: "rockchip,rk3399-gru-sound" | 4 | - compatible: "rockchip,rk3399-gru-sound" |
| 5 | - rockchip,cpu: The phandle of the Rockchip I2S controller that's | 5 | - rockchip,cpu: The phandle of the Rockchip I2S controller that's |
| 6 | connected to the codecs | 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 | Optional properties: | 9 | Optional properties: |
| 10 | - dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready. | 10 | - dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready. |
| @@ -7,8 +7,12 @@ Required properties: · 6 unmodified lines | |||
| 7 | 7 | ||
| 8 | - compatible: should be one of the following: | 8 | - compatible: should be one of the following: |
| 9 | - "rockchip,rk3066-i2s": for rk3066 | 9 | - "rockchip,rk3066-i2s": for rk3066 |
| 10 | - "rockchip,rk3036-i2s", "rockchip,rk3066-i2s": for rk3036 | ||
| 10 | - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188 | 11 | - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188 |
| 12 | - "rockchip,rk3228-i2s", "rockchip,rk3066-i2s": for rk3228 | ||
| 11 | - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288 | 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 | - "rockchip,rk3368-i2s", "rockchip,rk3066-i2s": for rk3368 | 16 | - "rockchip,rk3368-i2s", "rockchip,rk3066-i2s": for rk3368 |
| 13 | - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399 | 17 | - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399 |
| 14 | - reg: physical base address of the controller and length of memory mapped | 18 | - reg: physical base address of the controller and length of memory mapped |
| @@ -41,6 +41,5 @@ spdif: spdif@0x1011e000 { · 40 unmodified lines | |||
| 41 | dma-names = "tx"; | 41 | dma-names = "tx"; |
| 42 | clock-names = "hclk", "mclk"; | 42 | clock-names = "hclk", "mclk"; |
| 43 | clocks = <&cru HCLK_SPDIF>, <&cru SCLK_SPDIF>; | 43 | clocks = <&cru HCLK_SPDIF>, <&cru SCLK_SPDIF>; |
| 44 | status = "disabled"; | ||
| 45 | #sound-dai-cells = <0>; | 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 | Optional properties: | 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 | Pins on the device (for linking into audio routes) for RT5663: | 23 | Pins on the device (for linking into audio routes) for RT5663: |
| 16 | 24 | ||
| 17 | * IN1P | 25 | * IN1P |
| @@ -7,9 +7,6 @@ Required properties: · 6 unmodified lines | |||
| 7 | - model - the user-visible name of this sound complex | 7 | - model - the user-visible name of this sound complex |
| 8 | - clocks - should contain entries matching clock names in the clock-names | 8 | - clocks - should contain entries matching clock names in the clock-names |
| 9 | property | 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 | - samsung,audio-widgets - this property specifies off-codec audio elements | 10 | - samsung,audio-widgets - this property specifies off-codec audio elements |
| 14 | like headphones or speakers, for details see widgets.txt | 11 | like headphones or speakers, for details see widgets.txt |
| 15 | - samsung,audio-routing - a list of the connections between audio | 12 | - samsung,audio-routing - a list of the connections between audio |
| @@ -46,9 +43,6 @@ sound { · 30 unmodified lines | |||
| 46 | "IN1", "Mic Jack", | 43 | "IN1", "Mic Jack", |
| 47 | "Mic Jack", "MICBIAS"; | 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 | cpu { | 46 | cpu { |
| 53 | sound-dai = <&i2s0 0>; | 47 | sound-dai = <&i2s0 0>; |
| 54 | }; | 48 | }; |
| @@ -86,6 +86,9 @@ Optional CPU/CODEC subnodes properties: · 85 unmodified lines | |||
| 86 | in dai startup() and disabled with | 86 | in dai startup() and disabled with |
| 87 | clk_disable_unprepare() in dai | 87 | clk_disable_unprepare() in dai |
| 88 | shutdown(). | 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 | Example 1 - single DAI link: | 93 | Example 1 - single DAI link: |
| 91 | 94 | ||
| @@ -24,6 +24,7 @@ Optional subnode properties: · 23 unmodified lines | |||
| 24 | - simple-audio-card,convert-rate : platform specified sampling rate convert | 24 | - simple-audio-card,convert-rate : platform specified sampling rate convert |
| 25 | - simple-audio-card,convert-channels : platform specified converted channel size (2 - 8 ch) | 25 | - simple-audio-card,convert-channels : platform specified converted channel size (2 - 8 ch) |
| 26 | - simple-audio-card,prefix : see routing | 26 | - simple-audio-card,prefix : see routing |
| 27 | - simple-audio-card,widgets : Please refer to widgets.txt. | ||
| 27 | - simple-audio-card,routing : A list of the connections between audio components. | 28 | - simple-audio-card,routing : A list of the connections between audio components. |
| 28 | Each entry is a pair of strings, the first being the connection's sink, | 29 | Each entry is a pair of strings, the first being the connection's sink, |
| 29 | the second being the connection's source. Valid names for sources. | 30 | the second being the connection's source. Valid names for sources. |
| @@ -53,7 +53,6 @@ Example: · 52 unmodified lines | |||
| 53 | 53 | ||
| 54 | sti_uni_player1: sti-uni-player@0x8D81000 { | 54 | sti_uni_player1: sti-uni-player@0x8D81000 { |
| 55 | compatible = "st,stih407-uni-player-hdmi"; | 55 | compatible = "st,stih407-uni-player-hdmi"; |
| 56 | status = "okay"; | ||
| 57 | #sound-dai-cells = <0>; | 56 | #sound-dai-cells = <0>; |
| 58 | st,syscfg = <&syscfg_core>; | 57 | st,syscfg = <&syscfg_core>; |
| 59 | clocks = <&clk_s_d0_flexgen CLK_PCM_1>; | 58 | clocks = <&clk_s_d0_flexgen CLK_PCM_1>; |
| @@ -66,7 +65,6 @@ Example: · 6 unmodified lines | |||
| 66 | 65 | ||
| 67 | sti_uni_player2: sti-uni-player@0x8D82000 { | 66 | sti_uni_player2: sti-uni-player@0x8D82000 { |
| 68 | compatible = "st,stih407-uni-player-pcm-out"; | 67 | compatible = "st,stih407-uni-player-pcm-out"; |
| 69 | status = "okay"; | ||
| 70 | #sound-dai-cells = <0>; | 68 | #sound-dai-cells = <0>; |
| 71 | st,syscfg = <&syscfg_core>; | 69 | st,syscfg = <&syscfg_core>; |
| 72 | clocks = <&clk_s_d0_flexgen CLK_PCM_2>; | 70 | clocks = <&clk_s_d0_flexgen CLK_PCM_2>; |
| @@ -78,7 +76,6 @@ Example: · 5 unmodified lines | |||
| 78 | 76 | ||
| 79 | sti_uni_player3: sti-uni-player@0x8D85000 { | 77 | sti_uni_player3: sti-uni-player@0x8D85000 { |
| 80 | compatible = "st,stih407-uni-player-spdif"; | 78 | compatible = "st,stih407-uni-player-spdif"; |
| 81 | status = "okay"; | ||
| 82 | #sound-dai-cells = <0>; | 79 | #sound-dai-cells = <0>; |
| 83 | st,syscfg = <&syscfg_core>; | 80 | st,syscfg = <&syscfg_core>; |
| 84 | clocks = <&clk_s_d0_flexgen CLK_SPDIFF>; | 81 | clocks = <&clk_s_d0_flexgen CLK_SPDIFF>; |
| @@ -90,7 +87,6 @@ Example: · 5 unmodified lines | |||
| 90 | 87 | ||
| 91 | sti_uni_reader1: sti-uni-reader@0x8D84000 { | 88 | sti_uni_reader1: sti-uni-reader@0x8D84000 { |
| 92 | compatible = "st,stih407-uni-reader-hdmi"; | 89 | compatible = "st,stih407-uni-reader-hdmi"; |
| 93 | status = "disabled"; | ||
| 94 | #sound-dai-cells = <0>; | 90 | #sound-dai-cells = <0>; |
| 95 | st,syscfg = <&syscfg_core>; | 91 | st,syscfg = <&syscfg_core>; |
| 96 | reg = <0x8D84000 0x158>; | 92 | reg = <0x8D84000 0x158>; |
| @@ -125,7 +121,6 @@ Example of audio card declaration: · 28 unmodified lines | |||
| 125 | sound { | 121 | sound { |
| 126 | compatible = "simple-audio-card"; | 122 | compatible = "simple-audio-card"; |
| 127 | simple-audio-card,name = "sti audio card"; | 123 | simple-audio-card,name = "sti audio card"; |
| 128 | status = "okay"; | ||
| 129 | 124 | ||
| 130 | simple-audio-card,dai-link@0 { | 125 | simple-audio-card,dai-link@0 { |
| 131 | /* DAC */ | 126 | /* DAC */ |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | |||
| 8 | - compatible: should be one of the following: | 8 | - compatible: should be one of the following: |
| 9 | - "allwinner,sun4i-a10-i2s" | 9 | - "allwinner,sun4i-a10-i2s" |
| 10 | - "allwinner,sun6i-a31-i2s" | 10 | - "allwinner,sun6i-a31-i2s" |
| 11 | - "allwinner,sun8i-h3-i2s" | ||
| 11 | - reg: physical base address of the controller and length of memory mapped | 12 | - reg: physical base address of the controller and length of memory mapped |
| 12 | region. | 13 | region. |
| 13 | - interrupts: should contain the I2S interrupt. | 14 | - interrupts: should contain the I2S interrupt. |
| @@ -22,6 +23,7 @@ Required properties: · 8 unmodified lines | |||
| 22 | 23 | ||
| 23 | Required properties for the following compatibles: | 24 | Required properties for the following compatibles: |
| 24 | - "allwinner,sun6i-a31-i2s" | 25 | - "allwinner,sun6i-a31-i2s" |
| 26 | - "allwinner,sun8i-h3-i2s" | ||
| 25 | - resets: phandle to the reset line for this codec | 27 | - resets: phandle to the reset line for this codec |
| 26 | 28 | ||
| 27 | Example: | 29 | Example: |
| @@ -39,5 +39,4 @@ spdif: spdif@01c21000 { · 38 unmodified lines | |||
| 39 | clock-names = "apb", "spdif"; | 39 | clock-names = "apb", "spdif"; |
| 40 | dmas = <&dma 0 2>, <&dma 0 2>; | 40 | dmas = <&dma 0 2>, <&dma 0 2>; |
| 41 | dma-names = "rx", "tx"; | 41 | dma-names = "rx", "tx"; |
| 42 | status = "okay"; | ||
| 43 | }; | 42 | }; |
| @@ -17,7 +17,6 @@ Required properties: · 16 unmodified lines | |||
| 17 | Example: | 17 | Example: |
| 18 | 18 | ||
| 19 | tas5720: tas5720@6c { | 19 | tas5720: tas5720@6c { |
| 20 | status = "okay"; | ||
| 21 | compatible = "ti,tas5720"; | 20 | compatible = "ti,tas5720"; |
| 22 | reg = <0x6c>; | 21 | reg = <0x6c>; |
| 23 | dvdd-supply = <&vdd_3v3_reg>; | 22 | dvdd-supply = <&vdd_3v3_reg>; |
| @@ -3,7 +3,9 @@ Texas Instruments - tlv320aic32x4 Codec module · 2 unmodified lines | |||
| 3 | The tlv320aic32x4 serial control bus communicates through I2C protocols | 3 | The tlv320aic32x4 serial control bus communicates through I2C protocols |
| 4 | 4 | ||
| 5 | Required properties: | 5 | Required properties: |
| 6 | - compatible: Should be "ti,tlv320aic32x4" | 6 | - compatible - "string" - One of: |
| 7 | "ti,tlv320aic32x4" TLV320AIC3204 | ||
| 8 | "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256 | ||
| 7 | - reg: I2C slave address | 9 | - reg: I2C slave address |
| 8 | - supply-*: Required supply regulators are: | 10 | - supply-*: Required supply regulators are: |
| 9 | "iov" - digital IO power supply | 11 | "iov" - digital IO power supply |
| @@ -18,6 +20,8 @@ Optional properties: · 8 unmodified lines | |||
| 18 | - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt | 20 | - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt |
| 19 | - clocks/clock-names: Clock named 'mclk' for the master clock of the codec. | 21 | - clocks/clock-names: Clock named 'mclk' for the master clock of the codec. |
| 20 | See clock/clock-bindings.txt for information about the detailed format. | 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 | Example: | 27 | Example: |
| @@ -27,4 +31,11 @@ codec: tlv320aic32x4@18 { · 3 unmodified lines | |||
| 27 | reg = <0x18>; | 31 | reg = <0x18>; |
| 28 | clocks = <&clks 201>; | 32 | clocks = <&clks 201>; |
| 29 | clock-names = "mclk"; | 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 | 3 - MICBIAS output is connected to AVDD, | 26 | 3 - MICBIAS output is connected to AVDD, |
| 27 | If this node is not mentioned or if the value is incorrect, then MicBias | 27 | If this node is not mentioned or if the value is incorrect, then MicBias |
| 28 | is powered down. | 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 | - AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the | 34 | - AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the |
| 30 | device as covered in Documentation/devicetree/bindings/regulator/regulator.txt | 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 | interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; | 27 | interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; |
| 28 | dmas = <&dma 5>, <&dma 6>; | 28 | dmas = <&dma 5>, <&dma 6>; |
| 29 | dma-names = "tx", "rx"; | 29 | dma-names = "tx", "rx"; |
| 30 | status = "okay"; | ||
| 31 | }; | 30 | }; |
| 32 | 31 | ||
| 33 | sound { | 32 | sound { |
| @@ -24,5 +24,4 @@ Example: · 23 unmodified lines | |||
| 24 | interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; | 24 | interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; |
| 25 | dmas = <&dma 4>; | 25 | dmas = <&dma 4>; |
| 26 | dma-names = "tx"; | 26 | dma-names = "tx"; |
| 27 | status = "okay"; | ||
| 28 | }; | 27 | }; |
| @@ -28,7 +28,6 @@ spi1: spi@0x4000c400 { /* USART1 */ · 27 unmodified lines | |||
| 28 | clocks = <&cmu 20>; | 28 | clocks = <&cmu 20>; |
| 29 | cs-gpios = <&gpio 51 1>; // D3 | 29 | cs-gpios = <&gpio 51 1>; // D3 |
| 30 | energymicro,location = <1>; | 30 | energymicro,location = <1>; |
| 31 | status = "ok"; | ||
| 32 | 31 | ||
| 33 | ks8851@0 { | 32 | ks8851@0 { |
| 34 | compatible = "ks8851"; | 33 | compatible = "ks8851"; |
| @@ -36,6 +35,5 @@ spi1: spi@0x4000c400 { /* USART1 */ · 1 unmodified line | |||
| 36 | reg = <0>; | 35 | reg = <0>; |
| 37 | interrupt-parent = <&boardfpga>; | 36 | interrupt-parent = <&boardfpga>; |
| 38 | interrupts = <4>; | 37 | interrupts = <4>; |
| 39 | status = "ok"; | ||
| 40 | }; | 38 | }; |
| 41 | }; | 39 | }; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | |||
| 9 | - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31 | 9 | - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31 |
| 10 | - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 | 10 | - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 |
| 11 | - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51 | 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 | - reg : Offset and length of the register set for the device | 13 | - reg : Offset and length of the register set for the device |
| 13 | - interrupts : Should contain CSPI/eCSPI interrupt | 14 | - interrupts : Should contain CSPI/eCSPI interrupt |
| 14 | - cs-gpios : Specifies the gpio pins to be used for chipselects. | 15 | - cs-gpios : Specifies the gpio pins to be used for chipselects. |
| @@ -38,5 +38,4 @@ spi@7000d600 { · 37 unmodified lines | |||
| 38 | reset-names = "spi"; | 38 | reset-names = "spi"; |
| 39 | dmas = <&apbdma 16>, <&apbdma 16>; | 39 | dmas = <&apbdma 16>, <&apbdma 16>; |
| 40 | dma-names = "rx", "tx"; | 40 | dma-names = "rx", "tx"; |
| 41 | status = "disabled"; | ||
| 42 | }; | 41 | }; |
| @@ -34,5 +34,4 @@ spi@7000c380 { · 33 unmodified lines | |||
| 34 | reset-names = "spi"; | 34 | reset-names = "spi"; |
| 35 | dmas = <&apbdma 11>, <&apbdma 11>; | 35 | dmas = <&apbdma 11>, <&apbdma 11>; |
| 36 | dma-names = "rx", "tx"; | 36 | dma-names = "rx", "tx"; |
| 37 | status = "disabled"; | ||
| 38 | }; | 37 | }; |
| @@ -34,5 +34,4 @@ spi@7000d600 { · 33 unmodified lines | |||
| 34 | reset-names = "spi"; | 34 | reset-names = "spi"; |
| 35 | dmas = <&apbdma 16>, <&apbdma 16>; | 35 | dmas = <&apbdma 16>, <&apbdma 16>; |
| 36 | dma-names = "rx", "tx"; | 36 | dma-names = "rx", "tx"; |
| 37 | status = "disabled"; | ||
| 38 | }; | 37 | }; |
| @@ -24,6 +24,5 @@ Example: · 23 unmodified lines | |||
| 24 | interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>; | 24 | interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>; |
| 25 | #address-cells = <1>; | 25 | #address-cells = <1>; |
| 26 | #size-cells = <0>; | 26 | #size-cells = <0>; |
| 27 | status = "disabled"; | ||
| 28 | }; | 27 | }; |
| 29 | 28 | ||
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | |||
| 6 | "renesas,msiof-r8a7792" (R-Car V2H) | 6 | "renesas,msiof-r8a7792" (R-Car V2H) |
| 7 | "renesas,msiof-r8a7793" (R-Car M2-N) | 7 | "renesas,msiof-r8a7793" (R-Car M2-N) |
| 8 | "renesas,msiof-r8a7794" (R-Car E2) | 8 | "renesas,msiof-r8a7794" (R-Car E2) |
| 9 | "renesas,msiof-r8a7795" (R-Car H3) | ||
| 9 | "renesas,msiof-r8a7796" (R-Car M3-W) | 10 | "renesas,msiof-r8a7796" (R-Car M3-W) |
| 10 | "renesas,msiof-sh73a0" (SH-Mobile AG5) | 11 | "renesas,msiof-sh73a0" (SH-Mobile AG5) |
| 11 | "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) | 12 | "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) |
| @@ -78,5 +79,4 @@ Example: · 66 unmodified lines | |||
| 78 | dma-names = "tx", "rx"; | 79 | dma-names = "tx", "rx"; |
| 79 | #address-cells = <1>; | 80 | #address-cells = <1>; |
| 80 | #size-cells = <0>; | 81 | #size-cells = <0>; |
| 81 | status = "disabled"; | ||
| 82 | }; | 82 | }; |
| @@ -23,7 +23,6 @@ spi@80000500 { · 22 unmodified lines | |||
| 23 | reg = <0x80000500 0x4>; | 23 | reg = <0x80000500 0x4>; |
| 24 | interrupts = <15>; | 24 | interrupts = <15>; |
| 25 | clocks = <&clks CLPS711X_CLK_SPI>; | 25 | clocks = <&clks CLPS711X_CLK_SPI>; |
| 26 | status = "disabled"; | ||
| 27 | }; | 26 | }; |
| 28 | 27 | ||
| 29 | syscon3: syscon@80002200 { | 28 | syscon3: syscon@80002200 { |
| @@ -39,7 +39,6 @@ dspi0@4002c000 { · 38 unmodified lines | |||
| 39 | pinctrl-names = "default"; | 39 | pinctrl-names = "default"; |
| 40 | pinctrl-0 = <&pinctrl_dspi0_1>; | 40 | pinctrl-0 = <&pinctrl_dspi0_1>; |
| 41 | big-endian; | 41 | big-endian; |
| 42 | status = "okay"; | ||
| 43 | 42 | ||
| 44 | sflash: at26df081a@0 { | 43 | sflash: at26df081a@0 { |
| 45 | #address-cells = <1>; | 44 | #address-cells = <1>; |
| @@ -57,5 +57,4 @@ spi: spi@1100a000 { · 56 unmodified lines | |||
| 57 | clock-names = "parent-clk", "sel-clk", "spi-clk"; | 57 | clock-names = "parent-clk", "sel-clk", "spi-clk"; |
| 58 | cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; | 58 | cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; |
| 59 | mediatek,pad-select = <1>, <0>; | 59 | mediatek,pad-select = <1>, <0>; |
| 60 | status = "disabled"; | ||
| 61 | }; | 60 | }; |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | |||
| 29 | cell-index = <0>; | 29 | cell-index = <0>; |
| 30 | reg = <0x10600 0x28>; | 30 | reg = <0x10600 0x28>; |
| 31 | interrupts = <23>; | 31 | interrupts = <23>; |
| 32 | status = "disabled"; | ||
| 33 | }; | 32 | }; |
| 34 | 33 | ||
| 35 | Example with SPI direct mode support (optionally): | 34 | Example with SPI direct mode support (optionally): |
| @@ -48,7 +47,6 @@ Example with SPI direct mode support (optionally): · 12 unmodified lines | |||
| 48 | <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */ | 47 | <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */ |
| 49 | <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */ | 48 | <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */ |
| 50 | interrupts = <23>; | 49 | interrupts = <23>; |
| 51 | status = "disabled"; | ||
| 52 | }; | 50 | }; |
| 53 | 51 | ||
| 54 | To enable the direct mode, the board specific 'ranges' property in the | 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 | Required Properties: | 6 | Required Properties: |
| 7 | 7 | ||
| 8 | - compatible: should be one of the following. | 8 | - compatible: should be one of the following. |
| 9 | "rockchip,rv1108-spi" for rv1108 SoCs. | ||
| 9 | "rockchip,rk3036-spi" for rk3036 SoCS. | 10 | "rockchip,rk3036-spi" for rk3036 SoCS. |
| 10 | "rockchip,rk3066-spi" for rk3066 SoCs. | 11 | "rockchip,rk3066-spi" for rk3066 SoCs. |
| 11 | "rockchip,rk3188-spi" for rk3188 SoCs. | 12 | "rockchip,rk3188-spi" for rk3188 SoCs. |
| @@ -18,7 +18,6 @@ spi1: spi@01c06000 { · 17 unmodified lines | |||
| 18 | interrupts = <11>; | 18 | interrupts = <11>; |
| 19 | clocks = <&ahb_gates 21>, <&spi1_clk>; | 19 | clocks = <&ahb_gates 21>, <&spi1_clk>; |
| 20 | clock-names = "ahb", "mod"; | 20 | clock-names = "ahb", "mod"; |
| 21 | status = "disabled"; | ||
| 22 | #address-cells = <1>; | 21 | #address-cells = <1>; |
| 23 | #size-cells = <0>; | 22 | #size-cells = <0>; |
| 24 | }; | 23 | }; |
| @@ -39,7 +39,6 @@ spi0: spi@01c68000 { · 38 unmodified lines | |||
| 39 | pinctrl-names = "default"; | 39 | pinctrl-names = "default"; |
| 40 | pinctrl-0 = <&spi0_pins>; | 40 | pinctrl-0 = <&spi0_pins>; |
| 41 | resets = <&ccu RST_BUS_SPI0>; | 41 | resets = <&ccu RST_BUS_SPI0>; |
| 42 | status = "disabled"; | ||
| 43 | #address-cells = <1>; | 42 | #address-cells = <1>; |
| 44 | #size-cells = <0>; | 43 | #size-cells = <0>; |
| 45 | }; | 44 | }; |
| @@ -26,7 +26,6 @@ spi1: spi@fffcc000 { · 25 unmodified lines | |||
| 26 | clock-names = "spi_clk"; | 26 | clock-names = "spi_clk"; |
| 27 | cs-gpios = <&pioB 3 0>; | 27 | cs-gpios = <&pioB 3 0>; |
| 28 | atmel,fifo-size = <32>; | 28 | atmel,fifo-size = <32>; |
| 29 | status = "okay"; | ||
| 30 | 29 | ||
| 31 | mmc-slot@0 { | 30 | mmc-slot@0 { |
| 32 | compatible = "mmc-spi-slot"; | 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 | Required properties: | 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 | - reg : sram controller register offset + length | 15 | - reg : sram controller register offset + length |
| 14 | 16 | ||
| 15 | SRAM nodes | 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 | SRAM controller as subnodes. These sections are represented following | 24 | SRAM controller as subnodes. These sections are represented following |
| 23 | once again the representation described in the mmio-sram binding. | 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 | - allwinner,sun4i-a10-sram-a3-a4 | 28 | - allwinner,sun4i-a10-sram-a3-a4 |
| 27 | - allwinner,sun4i-a10-sram-d | 29 | - allwinner,sun4i-a10-sram-d |
| 28 | 30 | ||
| 31 | The valid sections compatible for A64 are: | ||
| 32 | - allwinner,sun50i-a64-sram-c | ||
| 33 | |||
| 29 | Devices using SRAM sections | 34 | Devices using SRAM sections |
| 30 | --------------------------- | 35 | --------------------------- |
| 31 | 36 | ||
| @@ -59,7 +64,6 @@ sram-controller@01c00000 { · 27 unmodified lines | |||
| 59 | emac_sram: sram-section@8000 { | 64 | emac_sram: sram-section@8000 { |
| 60 | compatible = "allwinner,sun4i-a10-sram-a3-a4"; | 65 | compatible = "allwinner,sun4i-a10-sram-a3-a4"; |
| 61 | reg = <0x8000 0x4000>; | 66 | reg = <0x8000 0x4000>; |
| 62 | status = "disabled"; | ||
| 63 | }; | 67 | }; |
| 64 | }; | 68 | }; |
| 65 | }; | 69 | }; |
| @@ -20,5 +20,4 @@ Example: · 19 unmodified lines | |||
| 20 | compatible = "marvell,armada370-thermal"; | 20 | compatible = "marvell,armada370-thermal"; |
| 21 | reg = <0xd0018300 0x4 | 21 | reg = <0xd0018300 0x4 |
| 22 | 0xd0018304 0x4>; | 22 | 0xd0018304 0x4>; |
| 23 | status = "okay"; | ||
| 24 | }; | 23 | }; |
| @@ -77,7 +77,6 @@ Example 1): · 76 unmodified lines | |||
| 77 | interrupts = <2 4>; | 77 | interrupts = <2 4>; |
| 78 | clocks = <&clock 383>; | 78 | clocks = <&clock 383>; |
| 79 | clock-names = "tmu_apbif"; | 79 | clock-names = "tmu_apbif"; |
| 80 | status = "disabled"; | ||
| 81 | vtmu-supply = <&tmu_regulator_node>; | 80 | vtmu-supply = <&tmu_regulator_node>; |
| 82 | #include "exynos4412-tmu-sensor-conf.dtsi" | 81 | #include "exynos4412-tmu-sensor-conf.dtsi" |
| 83 | }; | 82 | }; |
| @@ -11,6 +11,7 @@ Required properties: · 10 unmodified lines | |||
| 11 | - compatible: | 11 | - compatible: |
| 12 | - "mediatek,mt8173-thermal" : For MT8173 family of SoCs | 12 | - "mediatek,mt8173-thermal" : For MT8173 family of SoCs |
| 13 | - "mediatek,mt2701-thermal" : For MT2701 family of SoCs | 13 | - "mediatek,mt2701-thermal" : For MT2701 family of SoCs |
| 14 | - "mediatek,mt2712-thermal" : For MT2712 family of SoCs | ||
| 14 | - reg: Address range of the thermal controller | 15 | - reg: Address range of the thermal controller |
| 15 | - interrupts: IRQ for the thermal controller | 16 | - interrupts: IRQ for the thermal controller |
| 16 | - clocks, clock-names: Clocks needed for the thermal controller. required | 17 | - clocks, clock-names: Clocks needed for the thermal controller. required |
| @@ -36,7 +36,6 @@ Example: · 35 unmodified lines | |||
| 36 | clocks = <&cpg CPG_MOD 522>; | 36 | clocks = <&cpg CPG_MOD 522>; |
| 37 | power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; | 37 | power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; |
| 38 | #thermal-sensor-cells = <1>; | 38 | #thermal-sensor-cells = <1>; |
| 39 | status = "okay"; | ||
| 40 | }; | 39 | }; |
| 41 | 40 | ||
| 42 | thermal-zones { | 41 | thermal-zones { |
| @@ -4,6 +4,7 @@ Required properties: · 3 unmodified lines | |||
| 4 | - compatible : should be "rockchip,<name>-tsadc" | 4 | - compatible : should be "rockchip,<name>-tsadc" |
| 5 | "rockchip,rk3228-tsadc": found on RK3228 SoCs | 5 | "rockchip,rk3228-tsadc": found on RK3228 SoCs |
| 6 | "rockchip,rk3288-tsadc": found on RK3288 SoCs | 6 | "rockchip,rk3288-tsadc": found on RK3288 SoCs |
| 7 | "rockchip,rk3328-tsadc": found on RK3328 SoCs | ||
| 7 | "rockchip,rk3368-tsadc": found on RK3368 SoCs | 8 | "rockchip,rk3368-tsadc": found on RK3368 SoCs |
| 8 | "rockchip,rk3399-tsadc": found on RK3399 SoCs | 9 | "rockchip,rk3399-tsadc": found on RK3399 SoCs |
| 9 | - reg : physical base address of the controller and length of memory mapped | 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 | Required Properties: | 12 | Required Properties: |
| 13 | 13 | ||
| 14 | - compatible: must contain one or more of the following: | 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 | - "renesas,cmt-48-sh73a0" for the sh73A0 48-bit CMT | 15 | - "renesas,cmt-48-sh73a0" for the sh73A0 48-bit CMT |
| 38 | (CMT1) | 16 | (CMT1) |
| 39 | - "renesas,cmt-48-r8a7740" for the r8a7740 48-bit CMT | 17 | - "renesas,cmt-48-r8a7740" for the r8a7740 48-bit CMT |
| 40 | (CMT1) | 18 | (CMT1) |
| 41 | - "renesas,cmt-48" for all non-second generation 48-bit CMT | 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 | This is a fallback for the above renesas,cmt-48-* entries. | 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 | 23 | - "renesas,cmt0-r8a73a4" for the 32-bit CMT0 device included in r8a73a4. |
| 46 | (CMT[01]) | 24 | - "renesas,cmt1-r8a73a4" for the 48-bit CMT1 device included in r8a73a4. |
| 47 | - "renesas,cmt-48-r8a7790" for the r8a7790 48-bit CMT | 25 | - "renesas,cmt0-r8a7790" for the 32-bit CMT0 device included in r8a7790. |
| 48 | (CMT[01]) | 26 | - "renesas,cmt1-r8a7790" for the 48-bit CMT1 device included in r8a7790. |
| 49 | - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT | 27 | - "renesas,cmt0-r8a7791" for the 32-bit CMT0 device included in r8a7791. |
| 50 | (CMT[01]) | 28 | - "renesas,cmt1-r8a7791" for the 48-bit CMT1 device included in r8a7791. |
| 51 | - "renesas,cmt-48-gen2" for all second generation 48-bit CMT | 29 | - "renesas,cmt0-r8a7793" for the 32-bit CMT0 device included in r8a7793. |
| 52 | (CMT[01] on r8a73a4, r8a7790 and r8a7791) | 30 | - "renesas,cmt1-r8a7793" for the 48-bit CMT1 device included in r8a7793. |
| 53 | This is a fallback for the renesas,cmt-48-r8a73a4, | 31 | - "renesas,cmt0-r8a7794" for the 32-bit CMT0 device included in r8a7794. |
| 54 | renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries. | 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 | - reg: base address and length of the registers block for the timer module. | 39 | - reg: base address and length of the registers block for the timer module. |
| 57 | - interrupts: interrupt-specifier for the timer, one per channel. | 40 | - interrupts: interrupt-specifier for the timer, one per channel. |
| @@ -59,21 +42,29 @@ Required Properties: · 1 unmodified line | |||
| 59 | in clock-names. | 42 | in clock-names. |
| 60 | - clock-names: must contain "fck" for the functional clock. | 43 | - clock-names: must contain "fck" for the functional clock. |
| 61 | 44 | ||
| 62 | - renesas,channels-mask: bitmask of the available channels. | ||
| 63 | 45 | ||
| 64 | 46 | Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes | |
| 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. | ||
| 69 | 47 | ||
| 70 | cmt0: timer@ffca0000 { | 48 | cmt0: timer@ffca0000 { |
| 71 | compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2"; | 49 | compatible = "renesas,cmt0-r8a7790", "renesas,rcar-gen2-cmt0"; |
| 72 | reg = <0 0xffca0000 0 0x1004>; | 50 | reg = <0 0xffca0000 0 0x1004>; |
| 73 | interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>, | 51 | interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>, |
| 74 | <0 142 IRQ_TYPE_LEVEL_HIGH>; | 52 | <0 142 IRQ_TYPE_LEVEL_HIGH>; |
| 75 | clocks = <&mstp1_clks R8A7790_CLK_CMT0>; | 53 | clocks = <&mstp1_clks R8A7790_CLK_CMT0>; |
| 76 | clock-names = "fck"; | 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 | adi,adxl345 Three-Axis Digital Accelerometer | 21 | adi,adxl345 Three-Axis Digital Accelerometer |
| 22 | adi,adxl346 Three-Axis Digital Accelerometer (backward-compatibility value "adi,adxl345" must be listed too) | 22 | adi,adxl346 Three-Axis Digital Accelerometer (backward-compatibility value "adi,adxl345" must be listed too) |
| 23 | ams,iaq-core AMS iAQ-Core VOC Sensor | 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 | at,24c08 i2c serial eeprom (24cxx) | 34 | at,24c08 i2c serial eeprom (24cxx) |
| 25 | atmel,at97sc3204t i2c trusted platform module (TPM) | 35 | atmel,at97sc3204t i2c trusted platform module (TPM) |
| 26 | capella,cm32181 CM32181: Ambient Light Sensor | 36 | capella,cm32181 CM32181: Ambient Light Sensor |
| @@ -36,7 +46,9 @@ dallas,ds1775 Tiny Digital Thermometer and Thermostat · 9 unmodified lines | |||
| 36 | dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM | 46 | dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM |
| 37 | dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O | 47 | dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O |
| 38 | dallas,ds75 Digital Thermometer and Thermostat | 48 | dallas,ds75 Digital Thermometer and Thermostat |
| 49 | devantech,srf02 Devantech SRF02 ultrasonic ranger in I2C mode | ||
| 39 | devantech,srf08 Devantech SRF08 ultrasonic ranger | 50 | devantech,srf08 Devantech SRF08 ultrasonic ranger |
| 51 | devantech,srf10 Devantech SRF10 ultrasonic ranger | ||
| 40 | dlg,da9053 DA9053: flexible system level PMIC with multicore support | 52 | dlg,da9053 DA9053: flexible system level PMIC with multicore support |
| 41 | dlg,da9063 DA9063: system PMIC for quad-core application processors | 53 | dlg,da9063 DA9063: system PMIC for quad-core application processors |
| 42 | domintech,dmard09 DMARD09: 3-axis Accelerometer | 54 | domintech,dmard09 DMARD09: 3-axis Accelerometer |
| @@ -54,6 +66,7 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec · 11 unmodified lines | |||
| 54 | gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface | 66 | gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface |
| 55 | infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) | 67 | infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) |
| 56 | infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) | 68 | infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) |
| 69 | isil,isl1208 Intersil ISL1208 Low Power RTC with Battery Backed SRAM | ||
| 57 | isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor | 70 | isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor |
| 58 | isil,isl29030 Intersil ISL29030 Ambient Light and Proximity Sensor | 71 | isil,isl29030 Intersil ISL29030 Ambient Light and Proximity Sensor |
| 59 | maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator | 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 | taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface | 181 | taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface |
| 169 | ti,ads7828 8-Channels, 12-bit ADC | 182 | ti,ads7828 8-Channels, 12-bit ADC |
| 170 | ti,ads7830 8-Channels, 8-bit ADC | 183 | ti,ads7830 8-Channels, 8-bit ADC |
| 184 | ti,amc6821 Temperature Monitoring and Fan Control | ||
| 171 | ti,tsc2003 I2C Touch-Screen Controller | 185 | ti,tsc2003 I2C Touch-Screen Controller |
| 172 | ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface | 186 | ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface |
| 173 | ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface | 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 | Example: | 10 | Example: |
| 11 | unittest { | 11 | unittest { |
| 12 | compatible = "unittest"; | 12 | compatible = "unittest"; |
| 13 | status = "okay"; | ||
| 14 | }; | 13 | }; |
| 15 | 14 | ||
| 16 | 2) OF unittest i2c adapter platform device | 15 | 2) OF unittest i2c adapter platform device |
| @@ -25,7 +24,6 @@ Children nodes contain unittest i2c devices. · 8 unmodified lines | |||
| 25 | Example: | 24 | Example: |
| 26 | unittest-i2c-bus { | 25 | unittest-i2c-bus { |
| 27 | compatible = "unittest-i2c-bus"; | 26 | compatible = "unittest-i2c-bus"; |
| 28 | status = "okay"; | ||
| 29 | }; | 27 | }; |
| 30 | 28 | ||
| 31 | 3) OF unittest i2c device | 29 | 3) OF unittest i2c device |
| @@ -40,7 +38,6 @@ All other properties are optional · 8 unmodified lines | |||
| 40 | Example: | 38 | Example: |
| 41 | unittest-i2c-dev { | 39 | unittest-i2c-dev { |
| 42 | compatible = "unittest-i2c-dev"; | 40 | compatible = "unittest-i2c-dev"; |
| 43 | status = "okay"; | ||
| 44 | }; | 41 | }; |
| 45 | 42 | ||
| 46 | 4) OF unittest i2c mux device | 43 | 4) OF unittest i2c mux device |
| @@ -55,7 +52,6 @@ Children nodes contain unittest i2c bus nodes per channel. · 8 unmodified lines | |||
| 55 | Example: | 52 | Example: |
| 56 | unittest-i2c-mux { | 53 | unittest-i2c-mux { |
| 57 | compatible = "unittest-i2c-mux"; | 54 | compatible = "unittest-i2c-mux"; |
| 58 | status = "okay"; | ||
| 59 | #address-cells = <1>; | 55 | #address-cells = <1>; |
| 60 | #size-cells = <0>; | 56 | #size-cells = <0>; |
| 61 | channel-0 { | 57 | channel-0 { |
| @@ -65,7 +61,6 @@ Example: · 3 unmodified lines | |||
| 65 | i2c-dev { | 61 | i2c-dev { |
| 66 | reg = <8>; | 62 | reg = <8>; |
| 67 | compatible = "unittest-i2c-dev"; | 63 | compatible = "unittest-i2c-dev"; |
| 68 | status = "okay"; | ||
| 69 | }; | 64 | }; |
| 70 | }; | 65 | }; |
| 71 | }; | 66 | }; |
| @@ -25,5 +25,4 @@ Example: · 24 unmodified lines | |||
| 25 | phys = <&usbphy 0>; | 25 | phys = <&usbphy 0>; |
| 26 | phy-names = "usb"; | 26 | phy-names = "usb"; |
| 27 | extcon = <&usbphy 0>; | 27 | extcon = <&usbphy 0>; |
| 28 | status = "disabled"; | ||
| 29 | }; | 28 | }; |
| @@ -4,9 +4,9 @@ · 3 unmodified lines | |||
| 4 | - reg: offset and length of the usbss register sets | 4 | - reg: offset and length of the usbss register sets |
| 5 | - ti,hwmods : must be "usb_otg_hs" | 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 | at least a control module node, USB node and a PHY node. The second USB | 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 | Reset module | 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 | usb_phy: usb-phy { | 42 | usb_phy: usb-phy { |
| 43 | compatible = "ti,da830-usb-phy"; | 43 | compatible = "ti,da830-usb-phy"; |
| 44 | #phy-cells = <0>; | 44 | #phy-cells = <0>; |
| 45 | status = "okay"; | ||
| 46 | }; | 45 | }; |
| 47 | usb0: usb@200000 { | 46 | usb0: usb@200000 { |
| 48 | compatible = "ti,da830-musb"; | 47 | compatible = "ti,da830-musb"; |
| @@ -66,7 +65,6 @@ Example: · 17 unmodified lines | |||
| 66 | "rx1", "rx2", "rx3", "rx4", | 65 | "rx1", "rx2", "rx3", "rx4", |
| 67 | "tx1", "tx2", "tx3", "tx4"; | 66 | "tx1", "tx2", "tx3", "tx4"; |
| 68 | 67 | ||
| 69 | status = "okay"; | ||
| 70 | 68 | ||
| 71 | cppi41dma: dma-controller@201000 { | 69 | cppi41dma: dma-controller@201000 { |
| 72 | compatible = "ti,da830-cppi41"; | 70 | compatible = "ti,da830-cppi41"; |
| @@ -42,7 +42,6 @@ or "device". · 41 unmodified lines | |||
| 42 | Example: | 42 | Example: |
| 43 | 43 | ||
| 44 | st_dwc3: dwc3@8f94000 { | 44 | st_dwc3: dwc3@8f94000 { |
| 45 | status = "disabled"; | ||
| 46 | compatible = "st,stih407-dwc3"; | 45 | compatible = "st,stih407-dwc3"; |
| 47 | reg = <0x08f94000 0x1000>, <0x110 0x4>; | 46 | reg = <0x08f94000 0x1000>, <0x110 0x4>; |
| 48 | reg-names = "reg-glue", "syscfg-reg"; | 47 | reg-names = "reg-glue", "syscfg-reg"; |
| @@ -18,7 +18,6 @@ Example device node: · 17 unmodified lines | |||
| 18 | usb@0 { | 18 | usb@0 { |
| 19 | #address-cells = <0x2>; | 19 | #address-cells = <0x2>; |
| 20 | #size-cells = <0x1>; | 20 | #size-cells = <0x1>; |
| 21 | status = "okay"; | ||
| 22 | compatible = "xlnx,zynqmp-dwc3"; | 21 | compatible = "xlnx,zynqmp-dwc3"; |
| 23 | clock-names = "bus_clk" "ref_clk"; | 22 | clock-names = "bus_clk" "ref_clk"; |
| 24 | clocks = <&clk125>, <&clk125>; | 23 | clocks = <&clk125>, <&clk125>; |
| @@ -31,7 +31,6 @@ Example: · 30 unmodified lines | |||
| 31 | clocks = <&clk_s_a1_ls 0>; | 31 | clocks = <&clk_s_a1_ls 0>; |
| 32 | phys = <&usb2_phy>; | 32 | phys = <&usb2_phy>; |
| 33 | phy-names = "usb"; | 33 | phy-names = "usb"; |
| 34 | status = "okay"; | ||
| 35 | 34 | ||
| 36 | resets = <&powerdown STIH416_USB1_POWERDOWN>, | 35 | resets = <&powerdown STIH416_USB1_POWERDOWN>, |
| 37 | <&softreset STIH416_USB1_SOFTRESET>; | 36 | <&softreset STIH416_USB1_SOFTRESET>; |
| @@ -40,7 +40,6 @@ Example: · 39 unmodified lines | |||
| 40 | port@0 { | 40 | port@0 { |
| 41 | reg = <0>; | 41 | reg = <0>; |
| 42 | phys = <&usb2phy 1>; | 42 | phys = <&usb2phy 1>; |
| 43 | status = "disabled"; | ||
| 44 | }; | 43 | }; |
| 45 | }; | 44 | }; |
| 46 | 45 | ||
| @@ -75,7 +74,6 @@ Example: · 28 unmodified lines | |||
| 75 | port@0 { | 74 | port@0 { |
| 76 | reg = <0>; | 75 | reg = <0>; |
| 77 | phys = <&usb2phy 1>; | 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 | interrupt-parent = <&mic>; | 21 | interrupt-parent = <&mic>; |
| 22 | interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; | 22 | interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; |
| 23 | transceiver = <&isp1301>; | 23 | transceiver = <&isp1301>; |
| 24 | status = "okay"; | ||
| 25 | }; | 24 | }; |
| @@ -12,8 +12,21 @@ Required properties: · 11 unmodified lines | |||
| 12 | MPU. | 12 | MPU. |
| 13 | - ranges: allows valid 1:1 translation between child's address space and | 13 | - ranges: allows valid 1:1 translation between child's address space and |
| 14 | parent's address space. | 14 | parent's address space. |
| 15 | - clocks: Clock IDs array as required by the controller. | 15 | |
| 16 | - clock-names: names of clocks correseponding to IDs in the clock property. | 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 | Sub-nodes: | 31 | Sub-nodes: |
| 19 | The dwc3 core should be added as subnode to Keystone DWC3 glue. | 32 | The dwc3 core should be added as subnode to Keystone DWC3 glue. |
| @@ -31,7 +44,6 @@ Example: · 11 unmodified lines | |||
| 31 | clock-names = "usb"; | 44 | clock-names = "usb"; |
| 32 | interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; | 45 | interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; |
| 33 | ranges; | 46 | ranges; |
| 34 | status = "disabled"; | ||
| 35 | 47 | ||
| 36 | dwc3@2690000 { | 48 | dwc3@2690000 { |
| 37 | compatible = "synopsys,dwc3"; | 49 | compatible = "synopsys,dwc3"; |
| @@ -11,7 +11,11 @@ into two parts. · 10 unmodified lines | |||
| 11 | ------------------------------------------------------------------------ | 11 | ------------------------------------------------------------------------ |
| 12 | 12 | ||
| 13 | Required properties: | 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 | - reg : specifies physical base address and size of the registers | 19 | - reg : specifies physical base address and size of the registers |
| 16 | - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control | 20 | - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control |
| 17 | - interrupts : interrupt used by the controller | 21 | - interrupts : interrupt used by the controller |
| @@ -68,10 +72,14 @@ usb30: usb@11270000 { · 50 unmodified lines | |||
| 68 | 72 | ||
| 69 | In the case, xhci is added as subnode to mtu3. An example and the DT binding | 73 | In the case, xhci is added as subnode to mtu3. An example and the DT binding |
| 70 | details of mtu3 can be found in: | 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 | Required properties: | 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 | - reg : specifies physical base address and size of the registers | 83 | - reg : specifies physical base address and size of the registers |
| 76 | - reg-names: should be "mac" for xHCI MAC | 84 | - reg-names: should be "mac" for xHCI MAC |
| 77 | - interrupts : interrupt used by the host controller | 85 | - interrupts : interrupt used by the host controller |
| @@ -1,7 +1,11 @@ | |||
| 1 | The device node for Mediatek USB3.0 DRD controller | 1 | The device node for Mediatek USB3.0 DRD controller |
| 2 | 2 | ||
| 3 | Required properties: | 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 | - reg : specifies physical base address and size of the registers | 9 | - reg : specifies physical base address and size of the registers |
| 6 | - reg-names: should be "mac" for device IP and "ippc" for IP port control | 10 | - reg-names: should be "mac" for device IP and "ippc" for IP port control |
| 7 | - interrupts : interrupt used by the device IP | 11 | - interrupts : interrupt used by the device IP |
| @@ -44,7 +48,7 @@ Optional properties: · 36 unmodified lines | |||
| 44 | Sub-nodes: | 48 | Sub-nodes: |
| 45 | The xhci should be added as subnode to mtu3 as shown in the following example | 49 | The xhci should be added as subnode to mtu3 as shown in the following example |
| 46 | if host mode is enabled. The DT binding details of xhci can be found in: | 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 | Example: | 53 | Example: |
| 50 | ssusb: usb@11271000 { | 54 | ssusb: usb@11271000 { |
| @@ -71,7 +75,6 @@ ssusb: usb@11271000 { · 20 unmodified lines | |||
| 71 | #address-cells = <2>; | 75 | #address-cells = <2>; |
| 72 | #size-cells = <2>; | 76 | #size-cells = <2>; |
| 73 | ranges; | 77 | ranges; |
| 74 | status = "disabled"; | ||
| 75 | 78 | ||
| 76 | usb_host: xhci@11270000 { | 79 | usb_host: xhci@11270000 { |
| 77 | compatible = "mediatek,mt8173-xhci"; | 80 | compatible = "mediatek,mt8173-xhci"; |
| @@ -82,6 +85,5 @@ ssusb: usb@11271000 { · 4 unmodified lines | |||
| 82 | clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>; | 85 | clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>; |
| 83 | clock-names = "sys_ck", "ref_ck"; | 86 | clock-names = "sys_ck", "ref_ck"; |
| 84 | vusb33-supply = <&mt6397_vusb_reg>; | 87 | vusb33-supply = <&mt6397_vusb_reg>; |
| 85 | status = "disabled"; | ||
| 86 | }; | 88 | }; |
| 87 | }; | 89 | }; |
| @@ -29,7 +29,6 @@ Example: · 28 unmodified lines | |||
| 29 | clock-names = "ic", "clk48"; | 29 | clock-names = "ic", "clk48"; |
| 30 | phys = <&usb2_phy>; | 30 | phys = <&usb2_phy>; |
| 31 | phy-names = "usb"; | 31 | phy-names = "usb"; |
| 32 | status = "okay"; | ||
| 33 | 32 | ||
| 34 | resets = <&powerdown STIH416_USB0_POWERDOWN>, | 33 | resets = <&powerdown STIH416_USB0_POWERDOWN>, |
| 35 | <&softreset STIH416_USB0_SOFTRESET>; | 34 | <&softreset STIH416_USB0_SOFTRESET>; |
| @@ -29,7 +29,6 @@ Example device nodes: · 28 unmodified lines | |||
| 29 | clock-names = "ref"; | 29 | clock-names = "ref"; |
| 30 | #phy-cells = <0>; | 30 | #phy-cells = <0>; |
| 31 | 31 | ||
| 32 | status = "ok"; | ||
| 33 | }; | 32 | }; |
| 34 | 33 | ||
| 35 | ss_phy: phy@100f8830 { | 34 | ss_phy: phy@100f8830 { |
| @@ -39,7 +38,6 @@ Example device nodes: · 3 unmodified lines | |||
| 39 | clock-names = "ref"; | 38 | clock-names = "ref"; |
| 40 | #phy-cells = <0>; | 39 | #phy-cells = <0>; |
| 41 | 40 | ||
| 42 | status = "ok"; | ||
| 43 | }; | 41 | }; |
| 44 | 42 | ||
| 45 | usb3_0: usb30@0 { | 43 | usb3_0: usb30@0 { |
| @@ -51,7 +49,6 @@ Example device nodes: · 5 unmodified lines | |||
| 51 | 49 | ||
| 52 | ranges; | 50 | ranges; |
| 53 | 51 | ||
| 54 | status = "ok"; | ||
| 55 | 52 | ||
| 56 | dwc3@10000000 { | 53 | dwc3@10000000 { |
| 57 | compatible = "snps,dwc3"; | 54 | compatible = "snps,dwc3"; |
| @@ -3,20 +3,30 @@ Renesas Electronics USB3.0 Peripheral driver · 2 unmodified lines | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: Must contain one of the following: | 4 | - compatible: Must contain one of the following: |
| 5 | - "renesas,r8a7795-usb3-peri" | 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 | - reg: Base address and length of the register for the USB3.0 Peripheral | 14 | - reg: Base address and length of the register for the USB3.0 Peripheral |
| 7 | - interrupts: Interrupt specifier for the USB3.0 Peripheral | 15 | - interrupts: Interrupt specifier for the USB3.0 Peripheral |
| 8 | - clocks: clock phandle and specifier pair | 16 | - clocks: clock phandle and specifier pair |
| 9 | 17 | ||
| 10 | Example: | 18 | Example of R-Car H3 ES1.x: |
| 11 | usb3_peri0: usb@ee020000 { | 19 | usb3_peri0: usb@ee020000 { |
| 12 | compatible = "renesas,r8a7795-usb3-peri"; | 20 | compatible = "renesas,r8a7795-usb3-peri", |
| 21 | "renesas,rcar-gen3-usb3-peri"; | ||
| 13 | reg = <0 0xee020000 0 0x400>; | 22 | reg = <0 0xee020000 0 0x400>; |
| 14 | interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; | 23 | interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; |
| 15 | clocks = <&cpg CPG_MOD 328>; | 24 | clocks = <&cpg CPG_MOD 328>; |
| 16 | }; | 25 | }; |
| 17 | 26 | ||
| 18 | usb3_peri1: usb@ee060000 { | 27 | usb3_peri1: usb@ee060000 { |
| 19 | compatible = "renesas,r8a7795-usb3-peri"; | 28 | compatible = "renesas,r8a7795-usb3-peri", |
| 29 | "renesas,rcar-gen3-usb3-peri"; | ||
| 20 | reg = <0 0xee060000 0 0x400>; | 30 | reg = <0 0xee060000 0 0x400>; |
| 21 | interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; | 31 | interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; |
| 22 | clocks = <&cpg CPG_MOD 327>; | 32 | clocks = <&cpg CPG_MOD 327>; |
| @@ -29,13 +29,11 @@ Example device nodes: · 28 unmodified lines | |||
| 29 | #address-cells = <2>; | 29 | #address-cells = <2>; |
| 30 | #size-cells = <2>; | 30 | #size-cells = <2>; |
| 31 | ranges; | 31 | ranges; |
| 32 | status = "disabled"; | ||
| 33 | usbdrd_dwc3_0: dwc3@fe800000 { | 32 | usbdrd_dwc3_0: dwc3@fe800000 { |
| 34 | compatible = "snps,dwc3"; | 33 | compatible = "snps,dwc3"; |
| 35 | reg = <0x0 0xfe800000 0x0 0x100000>; | 34 | reg = <0x0 0xfe800000 0x0 0x100000>; |
| 36 | interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; | 35 | interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; |
| 37 | dr_mode = "otg"; | 36 | dr_mode = "otg"; |
| 38 | status = "disabled"; | ||
| 39 | }; | 37 | }; |
| 40 | }; | 38 | }; |
| 41 | 39 | ||
| @@ -48,12 +46,10 @@ Example device nodes: · 6 unmodified lines | |||
| 48 | #address-cells = <2>; | 46 | #address-cells = <2>; |
| 49 | #size-cells = <2>; | 47 | #size-cells = <2>; |
| 50 | ranges; | 48 | ranges; |
| 51 | status = "disabled"; | ||
| 52 | usbdrd_dwc3_1: dwc3@fe900000 { | 49 | usbdrd_dwc3_1: dwc3@fe900000 { |
| 53 | compatible = "snps,dwc3"; | 50 | compatible = "snps,dwc3"; |
| 54 | reg = <0x0 0xfe900000 0x0 0x100000>; | 51 | reg = <0x0 0xfe900000 0x0 0x100000>; |
| 55 | interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; | 52 | interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; |
| 56 | dr_mode = "otg"; | 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 | Usually, we only use device tree for hard wired USB device. | 3 | Usually, we only use device tree for hard wired USB device. |
| 4 | The reference binding doc is from: | 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 | Required properties: | 7 | Required properties: |
| 8 | - compatible: usbVID,PID. The textual representation of VID, PID shall | 8 | - compatible: usbVID,PID. The textual representation of VID, PID shall |
| @@ -16,7 +16,6 @@ Required properties: · 7 unmodified lines | |||
| 16 | Example: | 16 | Example: |
| 17 | 17 | ||
| 18 | &usb1 { | 18 | &usb1 { |
| 19 | status = "okay"; | ||
| 20 | 19 | ||
| 21 | #address-cells = <1>; | 20 | #address-cells = <1>; |
| 22 | #size-cells = <0>; | 21 | #size-cells = <0>; |
| @@ -3,12 +3,13 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. · 2 unmodified lines | |||
| 3 | This isn't an exhaustive list, but you should add new prefixes to it before | 3 | This isn't an exhaustive list, but you should add new prefixes to it before |
| 4 | using them to avoid name-space collisions. | 4 | using them to avoid name-space collisions. |
| 5 | 5 | ||
| 6 | abcn Abracon Corporation | ||
| 7 | abilis Abilis Systems | 6 | abilis Abilis Systems |
| 7 | abracon Abracon Corporation | ||
| 8 | actions Actions Semiconductor Co., Ltd. | 8 | actions Actions Semiconductor Co., Ltd. |
| 9 | active-semi Active-Semi International Inc | 9 | active-semi Active-Semi International Inc |
| 10 | ad Avionic Design GmbH | 10 | ad Avionic Design GmbH |
| 11 | adapteva Adapteva, Inc. | 11 | adapteva Adapteva, Inc. |
| 12 | adaptrum Adaptrum, Inc. | ||
| 12 | adh AD Holdings Plc. | 13 | adh AD Holdings Plc. |
| 13 | adi Analog Devices, Inc. | 14 | adi Analog Devices, Inc. |
| 14 | advantech Advantech Corporation | 15 | advantech Advantech Corporation |
| @@ -47,6 +48,7 @@ avic Shanghai AVIC Optoelectronics Co., Ltd. · 32 unmodified lines | |||
| 47 | axentia Axentia Technologies AB | 48 | axentia Axentia Technologies AB |
| 48 | axis Axis Communications AB | 49 | axis Axis Communications AB |
| 49 | bananapi BIPAI KEJI LIMITED | 50 | bananapi BIPAI KEJI LIMITED |
| 51 | bhf Beckhoff Automation GmbH & Co. KG | ||
| 50 | boe BOE Technology Group Co., Ltd. | 52 | boe BOE Technology Group Co., Ltd. |
| 51 | bosch Bosch Sensortec GmbH | 53 | bosch Bosch Sensortec GmbH |
| 52 | boundary Boundary Devices Inc. | 54 | boundary Boundary Devices Inc. |
| @@ -176,6 +178,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd. · 123 unmodified lines | |||
| 176 | kyo Kyocera Corporation | 178 | kyo Kyocera Corporation |
| 177 | lacie LaCie | 179 | lacie LaCie |
| 178 | lantiq Lantiq Semiconductor | 180 | lantiq Lantiq Semiconductor |
| 181 | lattice Lattice Semiconductor | ||
| 179 | lego LEGO Systems A/S | 182 | lego LEGO Systems A/S |
| 180 | lenovo Lenovo Group Ltd. | 183 | lenovo Lenovo Group Ltd. |
| 181 | lg LG Corporation | 184 | lg LG Corporation |
| @@ -196,6 +199,7 @@ mediatek MediaTek Inc. · 14 unmodified lines | |||
| 196 | megachips MegaChips | 199 | megachips MegaChips |
| 197 | melexis Melexis N.V. | 200 | melexis Melexis N.V. |
| 198 | melfas MELFAS Inc. | 201 | melfas MELFAS Inc. |
| 202 | mellanox Mellanox Technologies | ||
| 199 | memsic MEMSIC Inc. | 203 | memsic MEMSIC Inc. |
| 200 | merrii Merrii Technology Co., Ltd. | 204 | merrii Merrii Technology Co., Ltd. |
| 201 | micrel Micrel Inc. | 205 | micrel Micrel Inc. |
| @@ -207,7 +211,7 @@ miramems MiraMEMS Sensing Technology Co., Ltd. · 5 unmodified lines | |||
| 207 | mitsubishi Mitsubishi Electric Corporation | 211 | mitsubishi Mitsubishi Electric Corporation |
| 208 | mosaixtech Mosaix Technologies, Inc. | 212 | mosaixtech Mosaix Technologies, Inc. |
| 209 | motorola Motorola, Inc. | 213 | motorola Motorola, Inc. |
| 210 | moxa Moxa | 214 | moxa Moxa Inc. |
| 211 | mpl MPL AG | 215 | mpl MPL AG |
| 212 | mqmaker mqmaker Inc. | 216 | mqmaker mqmaker Inc. |
| 213 | msi Micro-Star International Co. Ltd. | 217 | msi Micro-Star International Co. Ltd. |
| @@ -250,6 +254,7 @@ oxsemi Oxford Semiconductor, Ltd. · 36 unmodified lines | |||
| 250 | panasonic Panasonic Corporation | 254 | panasonic Panasonic Corporation |
| 251 | parade Parade Technologies Inc. | 255 | parade Parade Technologies Inc. |
| 252 | pericom Pericom Technology Inc. | 256 | pericom Pericom Technology Inc. |
| 257 | pervasive Pervasive Displays, Inc. | ||
| 253 | phytec PHYTEC Messtechnik GmbH | 258 | phytec PHYTEC Messtechnik GmbH |
| 254 | picochip Picochip Ltd | 259 | picochip Picochip Ltd |
| 255 | pine64 Pine64 | 260 | pine64 Pine64 |
| @@ -288,6 +293,7 @@ schindler Schindler · 32 unmodified lines | |||
| 288 | seagate Seagate Technology PLC | 293 | seagate Seagate Technology PLC |
| 289 | semtech Semtech Corporation | 294 | semtech Semtech Corporation |
| 290 | sensirion Sensirion AG | 295 | sensirion Sensirion AG |
| 296 | sff Small Form Factor Committee | ||
| 291 | sgx SGX Sensortech | 297 | sgx SGX Sensortech |
| 292 | sharp Sharp Corporation | 298 | sharp Sharp Corporation |
| 293 | si-en Si-En Technology Ltd. | 299 | si-en Si-En Technology Ltd. |
| @@ -342,6 +348,7 @@ tpo TPO · 48 unmodified lines | |||
| 342 | tronfy Tronfy | 348 | tronfy Tronfy |
| 343 | tronsmart Tronsmart | 349 | tronsmart Tronsmart |
| 344 | truly Truly Semiconductors Limited | 350 | truly Truly Semiconductors Limited |
| 351 | tsd Theobroma Systems Design und Consulting GmbH | ||
| 345 | tyan Tyan Computer Corporation | 352 | tyan Tyan Computer Corporation |
| 346 | ucrobotics uCRobotics | 353 | ucrobotics uCRobotics |
| 347 | udoo Udoo | 354 | udoo Udoo |
| @@ -354,6 +361,7 @@ variscite Variscite Ltd. · 6 unmodified lines | |||
| 354 | via VIA Technologies, Inc. | 361 | via VIA Technologies, Inc. |
| 355 | virtio Virtual I/O Device Specification, developed by the OASIS consortium | 362 | virtio Virtual I/O Device Specification, developed by the OASIS consortium |
| 356 | vivante Vivante Corporation | 363 | vivante Vivante Corporation |
| 364 | vocore VoCore Studio | ||
| 357 | voipac Voipac Technologies s.r.o. | 365 | voipac Voipac Technologies s.r.o. |
| 358 | wd Western Digital Corp. | 366 | wd Western Digital Corp. |
| 359 | wetek WeTek Electronics, limited. | 367 | wetek WeTek Electronics, limited. |
| @@ -15,5 +15,4 @@ owire: owire@63fa4000 { · 14 unmodified lines | |||
| 15 | compatible = "fsl,imx53-owire", "fsl,imx21-owire"; | 15 | compatible = "fsl,imx53-owire", "fsl,imx21-owire"; |
| 16 | reg = <0x63fa4000 0x4000>; | 16 | reg = <0x63fa4000 0x4000>; |
| 17 | clocks = <&clks 159>; | 17 | clocks = <&clks 159>; |
| 18 | status = "disabled"; | ||
| 19 | }; | 18 | }; |
| @@ -8,9 +8,49 @@ Required properties: · 7 unmodified lines | |||
| 8 | - reg: physical base address of the controller and length of memory mapped | 8 | - reg: physical base address of the controller and length of memory mapped |
| 9 | region | 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 | Example: | 49 | Example: |
| 12 | 50 | ||
| 13 | wdt1: watchdog@1e785000 { | 51 | wdt1: watchdog@1e785000 { |
| 14 | compatible = "aspeed,ast2400-wdt"; | 52 | compatible = "aspeed,ast2400-wdt"; |
| 15 | reg = <0x1e785000 0x1c>; | 53 | reg = <0x1e785000 0x1c>; |
| 54 | aspeed,reset-type = "system"; | ||
| 55 | aspeed,external-signal; | ||
| 16 | }; | 56 | }; |
| @@ -31,5 +31,4 @@ Example: · 30 unmodified lines | |||
| 31 | atmel,watchdog-type = "hardware"; | 31 | atmel,watchdog-type = "hardware"; |
| 32 | atmel,dbg-halt; | 32 | atmel,dbg-halt; |
| 33 | atmel,idle-halt; | 33 | atmel,idle-halt; |
| 34 | status = "okay"; | ||
| 35 | }; | 34 | }; |
| @@ -48,5 +48,4 @@ Example: · 47 unmodified lines | |||
| 48 | atmel,idle-halt; | 48 | atmel,idle-halt; |
| 49 | atmel,max-heartbeat-sec = <16>; | 49 | atmel,max-heartbeat-sec = <16>; |
| 50 | atmel,min-heartbeat-sec = <0>; | 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 | reg = <0x20300 0x28>, <0x20108 0x4>; | 41 | reg = <0x20300 0x28>, <0x20108 0x4>; |
| 42 | interrupts = <3>; | 42 | interrupts = <3>; |
| 43 | timeout-sec = <10>; | 43 | timeout-sec = <10>; |
| 44 | status = "okay"; | ||
| 45 | clocks = <&gate_clk 7>; | 44 | clocks = <&gate_clk 7>; |
| 46 | }; | 45 | }; |
| @@ -2,7 +2,11 @@ Meson SoCs Watchdog timer · 1 unmodified line | |||
| 2 | 2 | ||
| 3 | Required properties: | 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 | - reg : Specifies base physical address and size of the registers. | 10 | - reg : Specifies base physical address and size of the registers. |
| 7 | 11 | ||
| 8 | Example: | 12 | Example: |
| @@ -3,9 +3,11 @@ Mediatek SoCs Watchdog timer · 2 unmodified lines | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | 4 | ||
| 5 | - compatible should contain: | 5 | - compatible should contain: |
| 6 | * "mediatek,mt2701-wdt" for MT2701 compatible watchdog timers | 6 | "mediatek,mt2701-wdt", "mediatek,mt6589-wdt": for MT2701 |
| 7 | * "mediatek,mt6589-wdt" for all compatible watchdog timers (MT2701, | 7 | "mediatek,mt6589-wdt": for MT6589 |
| 8 | 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 | - reg : Specifies base physical address and size of the registers. | 12 | - reg : Specifies base physical address and size of the registers. |
| 11 | 13 | ||
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | |||
| 6 | Examples with soctypes are: | 6 | Examples with soctypes are: |
| 7 | - "renesas,r8a7795-wdt" (R-Car H3) | 7 | - "renesas,r8a7795-wdt" (R-Car H3) |
| 8 | - "renesas,r8a7796-wdt" (R-Car M3-W) | 8 | - "renesas,r8a7796-wdt" (R-Car M3-W) |
| 9 | - "renesas,r8a77995-wdt" (R-Car D3) | ||
| 9 | - "renesas,r7s72100-wdt" (RZ/A1) | 10 | - "renesas,r7s72100-wdt" (RZ/A1) |
| 10 | 11 | ||
| 11 | When compatible with the generic version, nodes must list the SoC-specific | 12 | When compatible with the generic version, nodes must list the SoC-specific |
| @@ -281,6 +281,8 @@ · 280 unmodified lines | |||
| 281 | capabilities of the underlying ICAP hardware | 281 | capabilities of the underlying ICAP hardware |
| 282 | differ between different families. May be | 282 | differ between different families. May be |
| 283 | 'virtex2p', 'virtex4', or 'virtex5'. | 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 | vi) Xilinx Uart 16550 | 287 | vi) Xilinx Uart 16550 |
| 286 | 288 | ||
| @@ -1282,7 +1282,7 @@ hierarchy and routing of interrupts in the hardware. · 1281 unmodified lines | |||
| 1282 | The interrupt tree model is fully described in the | 1282 | The interrupt tree model is fully described in the |
| 1283 | document "Open Firmware Recommended Practice: Interrupt | 1283 | document "Open Firmware Recommended Practice: Interrupt |
| 1284 | Mapping Version 0.9". The document is available at: | 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 | 1) interrupts property | 1287 | 1) interrupts property |
| 1288 | ---------------------- | 1288 | ---------------------- |
| @@ -181,13 +181,6 @@ Currently, the types available are: · 180 unmodified lines | |||
| 181 | - Used by the client drivers to register a callback that will be | 181 | - Used by the client drivers to register a callback that will be |
| 182 | called on a regular basis through the DMA controller interrupt | 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 | * DMA_PRIVATE | 184 | * DMA_PRIVATE |
| 192 | - The devices only supports slave transfers, and as such isn't | 185 | - The devices only supports slave transfers, and as such isn't |
| 193 | available for async transfers. | 186 | available for async transfers. |
| @@ -395,6 +388,13 @@ where to put them) · 201 unmodified lines | |||
| 395 | when DMA_CTRL_REUSE is already set | 388 | when DMA_CTRL_REUSE is already set |
| 396 | - Terminating the channel | 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 | General Design Notes | 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 | ``Documentation``. Some of these will likely be converted to reStructuredText | 19 | ``Documentation``. Some of these will likely be converted to reStructuredText |
| 20 | over time, but the bulk of them will remain in plain text. | 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 | Sphinx Build | 126 | Sphinx Build |
| 23 | ============ | 127 | ============ |
| 24 | 128 | ||
| @@ -118,7 +222,7 @@ Here are some specific guidelines for the kernel documentation: · 93 unmodified lines | |||
| 118 | the C domain | 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 | function prototype: | 226 | function prototype: |
| 123 | 227 | ||
| 124 | .. code-block:: rst | 228 | .. code-block:: rst |
| @@ -229,6 +333,7 @@ Rendered as: · 104 unmodified lines | |||
| 229 | 333 | ||
| 230 | - column 3 | 334 | - column 3 |
| 231 | 335 | ||
| 336 | .. _sphinx_kfigure: | ||
| 232 | 337 | ||
| 233 | Figures & Images | 338 | Figures & Images |
| 234 | ================ | 339 | ================ |
| @@ -259,5 +259,4 @@ wakeup.bin · 258 unmodified lines | |||
| 259 | wakeup.elf | 259 | wakeup.elf |
| 260 | wakeup.lds | 260 | wakeup.lds |
| 261 | zImage* | 261 | zImage* |
| 262 | zconf.hash.c | ||
| 263 | zoffset.h | 262 | zoffset.h |
| @@ -4,7 +4,7 @@ Driver Basics · 3 unmodified lines | |||
| 4 | Driver Entry and Exit points | 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 | :internal: | 8 | :internal: |
| 9 | 9 | ||
| 10 | Driver device table | 10 | Driver device table |
| @@ -103,9 +103,6 @@ Kernel utility functions · 92 unmodified lines | |||
| 103 | .. kernel-doc:: kernel/panic.c | 103 | .. kernel-doc:: kernel/panic.c |
| 104 | :export: | 104 | :export: |
| 105 | 105 | ||
| 106 | .. kernel-doc:: kernel/sys.c | ||
| 107 | :export: | ||
| 108 | |||
| 109 | .. kernel-doc:: kernel/rcu/tree.c | 106 | .. kernel-doc:: kernel/rcu/tree.c |
| 110 | :export: | 107 | :export: |
| 111 | 108 | ||
| @@ -139,9 +139,6 @@ DMA Fences · 138 unmodified lines | |||
| 139 | Seqno Hardware Fences | 139 | Seqno Hardware Fences |
| 140 | ~~~~~~~~~~~~~~~~~~~~~ | 140 | ~~~~~~~~~~~~~~~~~~~~~ |
| 141 | 141 | ||
| 142 | .. kernel-doc:: drivers/dma-buf/seqno-fence.c | ||
| 143 | :export: | ||
| 144 | |||
| 145 | .. kernel-doc:: include/linux/seqno-fence.h | 142 | .. kernel-doc:: include/linux/seqno-fence.h |
| 146 | :internal: | 143 | :internal: |
| 147 | 144 | ||
| @@ -44,17 +44,6 @@ request_firmware_nowait · 43 unmodified lines | |||
| 44 | .. kernel-doc:: drivers/base/firmware_class.c | 44 | .. kernel-doc:: drivers/base/firmware_class.c |
| 45 | :functions: request_firmware_nowait | 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 | request firmware API expected driver use | 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 | uio-howto | 44 | uio-howto |
| 45 | firmware/index | 45 | firmware/index |
| 46 | pinctl | 46 | pinctl |
| 47 | gpio | ||
| 47 | misc_devices | 48 | misc_devices |
| 48 | 49 | ||
| 49 | .. only:: subproject and html | 50 | .. only:: subproject and html |
| @@ -47,4 +47,3 @@ used by one consumer at a time. · 46 unmodified lines | |||
| 47 | 47 | ||
| 48 | .. kernel-doc:: drivers/pwm/core.c | 48 | .. kernel-doc:: drivers/pwm/core.c |
| 49 | :export: | 49 | :export: |
| 50 | |||
| @@ -516,7 +516,7 @@ mirrored table is performed. · 515 unmodified lines | |||
| 516 | 516 | ||
| 517 | The most important field in the nand_bbt_descr structure is the | 517 | The most important field in the nand_bbt_descr structure is the |
| 518 | options field. The options define most of the table properties. Use the | 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 | - Number of bits per block | 521 | - Number of bits per block |
| 522 | 522 | ||
| @@ -843,7 +843,7 @@ Chip option constants · 320 unmodified lines | |||
| 843 | Constants for chip id table | 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 | describe the chip functionality:: | 847 | describe the chip functionality:: |
| 848 | 848 | ||
| 849 | /* Buswitdh is 16 bit */ | 849 | /* Buswitdh is 16 bit */ |
| @@ -865,7 +865,7 @@ describe the chip functionality:: · 15 unmodified lines | |||
| 865 | Constants for runtime options | 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 | describe the functionality:: | 869 | describe the functionality:: |
| 870 | 870 | ||
| 871 | /* The hw ecc generator provides a syndrome instead a ecc value on read | 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 | with an [XXX] identifier. See the chapter "Documentation hints" for an | 956 | with an [XXX] identifier. See the chapter "Documentation hints" for an |
| 957 | explanation. | 957 | explanation. |
| 958 | 958 | ||
| 959 | .. kernel-doc:: include/linux/mtd/nand.h | 959 | .. kernel-doc:: include/linux/mtd/rawnand.h |
| 960 | :internal: | 960 | :internal: |
| 961 | 961 | ||
| 962 | Public Functions Provided | 962 | Public Functions Provided |
| @@ -675,7 +675,7 @@ sub-domain of the parent domain. · 674 unmodified lines | |||
| 675 | 675 | ||
| 676 | Support for power domains is provided through the :c:member:`pm_domain` field of | 676 | Support for power domains is provided through the :c:member:`pm_domain` field of |
| 677 | |struct device|. This field is a pointer to an object of type | 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 | of power management callbacks analogous to the subsystem-level and device driver | 679 | of power management callbacks analogous to the subsystem-level and device driver |
| 680 | callbacks that are executed for the given device during all power transitions, | 680 | callbacks that are executed for the given device during all power transitions, |
| 681 | instead of the respective subsystem-level callbacks. Specifically, if a | 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 | data which is made available by the channel subsystem for each channel | 75 | data which is made available by the channel subsystem for each channel |
| 76 | attached device. | 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 | :internal: | 79 | :internal: |
| 80 | 80 | ||
| 81 | .. kernel-doc:: drivers/s390/cio/cmf.c | 81 | .. kernel-doc:: drivers/s390/cio/cmf.c |
| @@ -224,14 +224,6 @@ mid to lowlevel SCSI driver interface · 223 unmodified lines | |||
| 224 | .. kernel-doc:: drivers/scsi/hosts.c | 224 | .. kernel-doc:: drivers/scsi/hosts.c |
| 225 | :export: | 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 | Transport classes | 227 | Transport classes |
| 236 | ----------------- | 228 | ----------------- |
| 237 | 229 | ||
| @@ -312,6 +312,7 @@ IRQ · 311 unmodified lines | |||
| 312 | devm_irq_alloc_descs_from() | 312 | devm_irq_alloc_descs_from() |
| 313 | devm_irq_alloc_generic_chip() | 313 | devm_irq_alloc_generic_chip() |
| 314 | devm_irq_setup_generic_chip() | 314 | devm_irq_setup_generic_chip() |
| 315 | devm_irq_sim_init() | ||
| 315 | 316 | ||
| 316 | LED | 317 | LED |
| 317 | devm_led_classdev_register() | 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 | Macbook Pro 17", iMac 20" : | 27 | Macbook Pro 17", iMac 20" : |
| 28 | video=efifb:i20 | 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 | Edgar Hucek <gimli@dark-green.com> | 37 | Edgar Hucek <gimli@dark-green.com> |
| @@ -148,6 +148,13 @@ C. Boot options · 147 unmodified lines | |||
| 148 | Actually, the underlying fb driver is totally ignorant of console | 148 | Actually, the underlying fb driver is totally ignorant of console |
| 149 | rotation. | 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 | C. Attaching, Detaching and Unloading | 158 | C. Attaching, Detaching and Unloading |
| 152 | 159 | ||
| 153 | Before going on how to attach, detach and unload the framebuffer console, an | 160 | Before going on how to attach, detach and unload the framebuffer console, an |
| @@ -25,7 +25,7 @@ · 24 unmodified lines | |||
| 25 | | mn10300: | ok | | 25 | | mn10300: | ok | |
| 26 | | nios2: | ok | | 26 | | nios2: | ok | |
| 27 | | openrisc: | ok | | 27 | | openrisc: | ok | |
| 28 | | parisc: | TODO | | 28 | | parisc: | ok | |
| 29 | | powerpc: | ok | | 29 | | powerpc: | ok | |
| 30 | | s390: | ok | | 30 | | s390: | ok | |
| 31 | | score: | TODO | | 31 | | score: | TODO | |
| @@ -22,7 +22,7 @@ prototypes: · 21 unmodified lines | |||
| 22 | struct vfsmount *(*d_automount)(struct path *path); | 22 | struct vfsmount *(*d_automount)(struct path *path); |
| 23 | int (*d_manage)(const struct path *, bool); | 23 | int (*d_manage)(const struct path *, bool); |
| 24 | struct dentry *(*d_real)(struct dentry *, const struct inode *, | 24 | struct dentry *(*d_real)(struct dentry *, const struct inode *, |
| 25 | unsigned int); | 25 | unsigned int, unsigned int); |
| 26 | 26 | ||
| 27 | locking rules: | 27 | locking rules: |
| 28 | rename_lock ->d_lock may block rcu-walk | 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 | void (*mark_pages_cached)(void *cookie_netfs_data, | 151 | void (*mark_pages_cached)(void *cookie_netfs_data, |
| 152 | struct address_space *mapping, | 152 | struct address_space *mapping, |
| 153 | struct pagevec *cached_pvec); | 153 | struct pagevec *cached_pvec); |
| 154 | |||
| 155 | void (*now_uncached)(void *cookie_netfs_data); | ||
| 156 | }; | 154 | }; |
| 157 | 155 | ||
| 158 | This has the following fields: | 156 | This has the following fields: |
| @@ -41,6 +41,11 @@ Igor Mammedov (DFS support) · 40 unmodified lines | |||
| 41 | Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code) | 41 | Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code) |
| 42 | Scott Lovenberg | 42 | Scott Lovenberg |
| 43 | Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features) | 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 | Test case and Bug Report contributors | 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 | 1 | This module supports the SMB3 family of advanced network protocols (as well |
| 2 | features such as hierarchical dfs like namespace, hardlinks, locking and more. | 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 | It was designed to comply with the SNIA CIFS Technical Reference (which | 6 | It was designed to comply with the SNIA CIFS Technical Reference (which |
| 4 | supersedes the 1992 X/Open SMB Standard) as well as to perform best practice | 7 | supersedes the 1992 X/Open SMB Standard) as well as to perform best practice |
| 5 | practical interoperability with Windows 2000, Windows XP, Samba and equivalent | 8 | practical interoperability with Windows 2000, Windows XP, Samba and equivalent |
| 6 | servers. This code was developed in participation with the Protocol Freedom | 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 | Please see | 13 | Please see |
| 10 | http://protocolfreedom.org/ and | 14 | http://protocolfreedom.org/ and |
| @@ -15,30 +19,11 @@ for more details. · 4 unmodified lines | |||
| 15 | For questions or bug reports please contact: | 19 | For questions or bug reports please contact: |
| 16 | sfrench@samba.org (sfrench@us.ibm.com) | 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 | Build instructions: | 24 | Build instructions: |
| 19 | ================== | 25 | ================== |
| 20 | For Linux 2.4: | 26 | For Linux: |
| 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: | ||
| 42 | 1) Download the kernel (e.g. from http://www.kernel.org) | 27 | 1) Download the kernel (e.g. from http://www.kernel.org) |
| 43 | and change directory into the top of the kernel directory tree | 28 | and change directory into the top of the kernel directory tree |
| 44 | (e.g. /usr/src/linux-2.5.73) | 29 | (e.g. /usr/src/linux-2.5.73) |
| @@ -61,16 +46,13 @@ would simply type "make install"). · 16 unmodified lines | |||
| 61 | If you do not have the utility mount.cifs (in the Samba 3.0 source tree and on | 46 | If you do not have the utility mount.cifs (in the Samba 3.0 source tree and on |
| 62 | the CIFS VFS web site) copy it to the same directory in which mount.smbfs and | 47 | the CIFS VFS web site) copy it to the same directory in which mount.smbfs and |
| 63 | similar files reside (usually /sbin). Although the helper software is not | 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 | 49 | required, mount.cifs is recommended. Most distros include a "cifs-utils" |
| 65 | "net" may also be helpful since it may someday provide easier mount syntax for | 50 | package that includes this utility so it is recommended to install this. |
| 66 | users who are used to Windows e.g. | 51 | |
| 67 | net use <mount point> <UNC name or cifs URL> | ||
| 68 | Note that running the Winbind pam/nss module (logon service) on all of your | 52 | Note that running the Winbind pam/nss module (logon service) on all of your |
| 69 | Linux clients is useful in mapping Uids and Gids consistently across the | 53 | Linux clients is useful in mapping Uids and Gids consistently across the |
| 70 | domain to the proper network user. The mount.cifs mount helper can be | 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: | 55 | found at cifs-utils.git on git.samba.org |
| 72 | |||
| 73 | gcc samba/source/client/mount.cifs.c -o mount.cifs | ||
| 74 | 56 | ||
| 75 | If cifs is built as a module, then the size and number of network buffers | 57 | If cifs is built as a module, then the size and number of network buffers |
| 76 | and maximum number of simultaneous requests to one server can be configured. | 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 | on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made | 61 | on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made |
| 80 | at module initialization time (by running insmod cifs.ko) can be seen. | 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 | Allowing User Mounts | 76 | Allowing User Mounts |
| 83 | ==================== | 77 | ==================== |
| 84 | To permit users to mount and unmount over directories they own is possible | 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 | by default. This can be changed, as with nfs and other filesystems, | 92 | by default. This can be changed, as with nfs and other filesystems, |
| 99 | by simply specifying "nosuid" among the mount options. For user mounts | 93 | by simply specifying "nosuid" among the mount options. For user mounts |
| 100 | though to be able to pass the suid flag to mount requires rebuilding | 94 | though to be able to pass the suid flag to mount requires rebuilding |
| 101 | mount.cifs with the following flag: | 95 | mount.cifs with the following flag: CIFS_ALLOW_USR_SUID |
| 102 | |||
| 103 | gcc samba/source/client/mount.cifs.c -DCIFS_ALLOW_USR_SUID -o mount.cifs | ||
| 104 | 96 | ||
| 105 | There is a corresponding manual page for cifs mounting in the Samba 3.0 and | 97 | There is a corresponding manual page for cifs mounting in the Samba 3.0 and |
| 106 | later source tree in docs/manpages/mount.cifs.8 | 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 | Use instructions: | 181 | Use instructions: |
| 190 | ================ | 182 | ================ |
| 191 | Once the CIFS VFS support is built into the kernel or installed as a module | 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 | 184 | (cifs.ko), you can use mount syntax like the following to access Samba or |
| 193 | servers: | 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 | Before -o the option -v may be specified to make the mount.cifs | 189 | Before -o the option -v may be specified to make the mount.cifs |
| 198 | mount helper display the mount steps more verbosely. | 190 | mount helper display the mount steps more verbosely. |
| 199 | After -o the following commonly used cifs vfs specific options | 191 | After -o the following commonly used cifs vfs specific options |
| 200 | are supported: | 192 | are supported: |
| 201 | 193 | ||
| 202 | user=<username> | 194 | username=<username> |
| 203 | pass=<password> | 195 | password=<password> |
| 204 | domain=<domain name> | 196 | domain=<domain name> |
| 205 | 197 | ||
| 206 | Other cifs mount options are described below. Use of TCP names (in addition to | 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 | filenames (ie those which contain valid Linux characters, which normally | 238 | filenames (ie those which contain valid Linux characters, which normally |
| 247 | would be forbidden for Windows/CIFS semantics) as long as the server is | 239 | would be forbidden for Windows/CIFS semantics) as long as the server is |
| 248 | configured for Unix Extensions (and the client has not disabled | 240 | configured for Unix Extensions (and the client has not disabled |
| 249 | /proc/fs/cifs/LinuxExtensionsEnabled). | 241 | /proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option |
| 250 | 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 | CIFS VFS Mount Options | 247 | CIFS VFS Mount Options |
| 253 | ====================== | 248 | ====================== |
| 254 | A partial list of the supported mount options follows: | 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 | the CIFS session. | 251 | the CIFS session. |
| 257 | password The user password. If the mount helper is | 252 | password The user password. If the mount helper is |
| 258 | installed, the user will be prompted for password | 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 | A Partial List of Missing Features | 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 | is a partial list of the known problems and missing features: | 8 | is a partial list of the known problems and missing features: |
| 9 | 9 | ||
| 10 | a) SMB3 (and SMB3.02) missing optional features: | 10 | a) SMB3 (and SMB3.02) missing optional features: |
| 11 | - RDMA | 11 | - RDMA (started) |
| 12 | - multichannel (started) | 12 | - multichannel (started) |
| 13 | - directory leases (improved metadata caching) | 13 | - directory leases (improved metadata caching) |
| 14 | - T10 copy offload (copy chunk is only mechanism supported) | 14 | - T10 copy offload (copy chunk is only mechanism supported) |
| 15 | - encrypted shares | ||
| 16 | 15 | ||
| 17 | b) improved sparse file support | 16 | b) improved sparse file support |
| 18 | 17 | ||
| 19 | c) Directory entry caching relies on a 1 second timer, rather than | 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 | d) quota support (needs minor kernel change since quota calls | 21 | d) quota support (needs minor kernel change since quota calls |
| 23 | to make it to network filesystems or deviceless filesystems) | 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) | 24 | e) Better optimize open to reduce redundant opens (using reference |
| 26 | Including support for changing the time remotely (utimes command). | 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 | 28 | f) Finish inotify support so kde and gnome file list windows |
| 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 | ||
| 41 | will autorefresh (partially complete by Asser). Needs minor kernel | 29 | will autorefresh (partially complete by Asser). Needs minor kernel |
| 42 | vfs change to support removing D_NOTIFY on a file. | 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 | the CIFS statistics (started) | 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 | (requires minor protocol extension) to enable better support for SELINUX | 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 | mount or a per server basis to client UIDs or nobody if no mapping | 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 | 42 | exists. Also better integration with winbind for resolving SID owners |
| 55 | allow better permission checking when UIDs differ on the server | 43 | |
| 56 | and client. Add new protocol request to the CIFS protocol | 44 | k) Add tools to take advantage of more smb3 specific ioctls and features |
| 57 | standard for asking the server for the corresponding name of a | 45 | |
| 58 | particular uid. | 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 | 59 | q) Allow mount.cifs to be more verbose in reporting errors with dialect |
| 67 | such as "CopyChunk" (fast server side file copy) | 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 | 67 | t) split cifs and smb3 support into separate modules so legacy (and less |
| 74 | file attribute via chflags) | 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 | KNOWN BUGS | 75 | KNOWN BUGS |
| 80 | ==================================== | 76 | ==================================== |
| @@ -1,24 +1,28 @@ | |||
| 1 | This is the client VFS module for the Common Internet File System | 1 | This is the client VFS module for the SMB3 NAS protocol as well |
| 2 | (CIFS) protocol which is the successor to the Server Message Block | 2 | older dialects such as the Common Internet File System (CIFS) |
| 3 | protocol which was the successor to the Server Message Block | ||
| 3 | (SMB) protocol, the native file sharing mechanism for most early | 4 | (SMB) protocol, the native file sharing mechanism for most early |
| 4 | PC operating systems. New and improved versions of CIFS are now | 5 | PC operating systems. New and improved versions of CIFS are now |
| 5 | called SMB2 and SMB3. These dialects are also supported by the | 6 | called SMB2 and SMB3. These dialects are also supported by the |
| 6 | CIFS VFS module. CIFS is fully supported by network | 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 | as well by Samba (which provides excellent CIFS | 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 | this network filesystem client can mount to a wide variety of | 12 | this network filesystem client can mount to a wide variety of |
| 11 | servers. | 13 | servers. |
| 12 | 14 | ||
| 13 | The intent of this module is to provide the most advanced network | 15 | The intent of this module is to provide the most advanced network |
| 14 | file system function for CIFS compliant servers, including better | 16 | file system function for SMB3 compliant servers, including advanced |
| 15 | POSIX compliance, secure per-user session establishment, high | 17 | security features, excellent parallelized high performance i/o, better |
| 16 | performance safe distributed caching (oplock), optional packet | 18 | POSIX compliance, secure per-user session establishment, encryption, |
| 19 | high performance safe distributed caching (leases/oplocks), optional packet | ||
| 17 | signing, large files, Unicode support and other internationalization | 20 | signing, large files, Unicode support and other internationalization |
| 18 | improvements. Since both Samba server and this filesystem client support | 21 | improvements. Since both Samba server and this filesystem client support |
| 19 | the CIFS Unix extensions, the combination can provide a reasonable | 22 | the CIFS Unix extensions (and in the future SMB3 POSIX extensions), |
| 20 | alternative to NFSv4 for fileserving in some Linux to Linux environments, | 23 | the combination can provide a reasonable alternative to other network and |
| 21 | not just in Linux to Windows environments. | 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 | This filesystem has an mount utility (mount.cifs) that can be obtained from | 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 | - implementing an mmap file operation for DAX files which sets the | 63 | - implementing an mmap file operation for DAX files which sets the |
| 64 | VM_MIXEDMAP and VM_HUGEPAGE flags on the VMA, and setting the vm_ops to | 64 | VM_MIXEDMAP and VM_HUGEPAGE flags on the VMA, and setting the vm_ops to |
| 65 | include handlers for fault, pmd_fault, page_mkwrite, pfn_mkwrite. These | 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 | 66 | handlers should probably call dax_iomap_fault() passing the appropriate |
| 67 | handlers), dax_iomap_pmd_fault(), dax_pfn_mkwrite() passing the appropriate | 67 | fault size and iomap operations. |
| 68 | iomap operations. | ||
| 69 | - calling iomap_zero_range() passing appropriate iomap operations instead of | 68 | - calling iomap_zero_range() passing appropriate iomap operations instead of |
| 70 | block_truncate_page() for DAX files | 69 | block_truncate_page() for DAX files |
| 71 | - ensuring that there is sufficient locking between reads, writes, | 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 | with "mode=lfs". | 164 | with "mode=lfs". |
| 165 | usrquota Enable plain user disk quota accounting. | 165 | usrquota Enable plain user disk quota accounting. |
| 166 | grpquota Enable plain group disk quota accounting. | 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 | DEBUGFS ENTRIES | 179 | DEBUGFS ENTRIES |
| @@ -209,6 +219,15 @@ Files in /sys/fs/f2fs/<devname> · 39 unmodified lines | |||
| 209 | gc_idle = 1 will select the Cost Benefit approach | 219 | gc_idle = 1 will select the Cost Benefit approach |
| 210 | & setting gc_idle = 2 will select the greedy approach. | 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 | reclaim_segments This parameter controls the number of prefree | 231 | reclaim_segments This parameter controls the number of prefree |
| 213 | segments to be reclaimed. If the number of prefree | 232 | segments to be reclaimed. If the number of prefree |
| 214 | segments is larger than the number of segments | 233 | segments is larger than the number of segments |
| @@ -45,14 +45,11 @@ upstream version of the kernel client. · 44 unmodified lines | |||
| 45 | BUILDING THE USERSPACE FILESYSTEM ON A SINGLE SERVER | 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 | 48 | You can omit --prefix if you don't care that things are sprinkled around in |
| 49 | until then the path to where the kernel with the Orangefs kernel client | 49 | /usr/local. As of version 2.9.6, Orangefs uses Berkeley DB by default, we |
| 50 | patch was built is needed to ensure that pvfs2-client-core (the bridge | 50 | will probably be changing the default to lmdb soon. |
| 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. | ||
| 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 | make | 54 | make |
| 58 | 55 | ||
| @@ -82,9 +79,6 @@ prove things are working with: · 23 unmodified lines | |||
| 82 | 79 | ||
| 83 | /opt/osf/bin/pvfs2-ls /mymountpoint | 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 | If stuff seems to be working, turn on the client core: | 82 | If stuff seems to be working, turn on the client core: |
| 89 | /opt/osf/sbin/pvfs2-client -p /opt/osf/sbin/pvfs2-client-core | 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 | [mandatory] | 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 | (see rootfs for one kind of solution and bdev/socket/pipe for another). | 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 | swap_activate: Called when swapon is used on a file to allocate | 829 | swap_activate: Called when swapon is used on a file to allocate |
| 830 | space if necessary and pin the block lookup information in | 830 | space if necessary and pin the block lookup information in |
| 831 | memory. A return value of zero indicates success, | 831 | memory. A return value of zero indicates success, |
| 832 | in which case this file can be used to back swapspace. The | 832 | in which case this file can be used to back swapspace. |
| 833 | swapspace operations will be proxied to this address space's | ||
| 834 | ->swap_{out,in} methods. | ||
| 835 | 833 | ||
| 836 | swap_deactivate: Called during swapoff on files where swap_activate | 834 | swap_deactivate: Called during swapoff on files where swap_activate |
| 837 | was successful. | 835 | was successful. |
| @@ -990,7 +988,7 @@ struct dentry_operations { · 152 unmodified lines | |||
| 990 | struct vfsmount *(*d_automount)(struct path *); | 988 | struct vfsmount *(*d_automount)(struct path *); |
| 991 | int (*d_manage)(const struct path *, bool); | 989 | int (*d_manage)(const struct path *, bool); |
| 992 | struct dentry *(*d_real)(struct dentry *, const struct inode *, | 990 | struct dentry *(*d_real)(struct dentry *, const struct inode *, |
| 993 | unsigned int); | 991 | unsigned int, unsigned int); |
| 994 | }; | 992 | }; |
| 995 | 993 | ||
| 996 | d_revalidate: called when the VFS needs to revalidate a dentry. This | 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 | NAND flash MTD subsystem and provides chip access and partition parsing like | 84 | NAND flash MTD subsystem and provides chip access and partition parsing like |
| 85 | any other NAND driving hardware. | 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 | Apart from this there are special GPIO drivers in subsystems like MMC/SD to | 92 | Apart from this there are special GPIO drivers in subsystems like MMC/SD to |
| 88 | read card detect and write protect GPIO lines, and in the TTY serial subsystem | 93 | read card detect and write protect GPIO lines, and in the TTY serial subsystem |
| 89 | to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The | 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 | This is done by registering "ranges" of pins, which are essentially | 460 | This is done by registering "ranges" of pins, which are essentially |
| 461 | cross-reference tables. These are described in | 461 | cross-reference tables. These are described in |
| 462 | Documentation/pinctrl.txt | 462 | Documentation/driver-api/pinctl.rst |
| 463 | 463 | ||
| 464 | While the pin allocation is totally managed by the pinctrl subsystem, | 464 | While the pin allocation is totally managed by the pinctrl subsystem, |
| 465 | gpio (under gpiolib) is still maintained by gpio drivers. It may happen | 465 | gpio (under gpiolib) is still maintained by gpio drivers. It may happen |
| @@ -201,6 +201,8 @@ drivers. · 200 unmodified lines | |||
| 201 | Open/Close, File Operations and IOCTLs | 201 | Open/Close, File Operations and IOCTLs |
| 202 | ====================================== | 202 | ====================================== |
| 203 | 203 | ||
| 204 | .. _drm_driver_fops: | ||
| 205 | |||
| 204 | File Operations | 206 | File Operations |
| 205 | --------------- | 207 | --------------- |
| 206 | 208 | ||
| @@ -296,3 +296,12 @@ Auxiliary Modeset Helpers · 295 unmodified lines | |||
| 296 | 296 | ||
| 297 | .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c | 297 | .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c |
| 298 | :export: | 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 | .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c | 523 | .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c |
| 524 | :doc: overview | 524 | :doc: overview |
| 525 | 525 | ||
| 526 | .. kernel-doc:: include/drm/drm_color_mgmt.h | ||
| 527 | :internal: | ||
| 528 | |||
| 529 | .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c | 526 | .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c |
| 530 | :export: | 527 | :export: |
| 531 | 528 | ||
| @@ -554,60 +551,8 @@ various modules/drivers. · 22 unmodified lines | |||
| 554 | Vertical Blanking | 551 | Vertical Blanking |
| 555 | ================= | 552 | ================= |
| 556 | 553 | ||
| 557 | Vertical blanking plays a major role in graphics rendering. To achieve | 554 | .. kernel-doc:: drivers/gpu/drm/drm_vblank.c |
| 558 | tear-free display, users must synchronize page flips and/or rendering to | 555 | :doc: vblank handling |
| 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. | ||
| 611 | 556 | ||
| 612 | Vertical Blanking and Interrupt Handling Functions Reference | 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 | holding the lock. | 191 | holding the lock. |
| 192 | 192 | ||
| 193 | When the last reference to a GEM object is released the GEM core calls | 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 | operation. That operation is mandatory for GEM-enabled drivers and must | 195 | operation. That operation is mandatory for GEM-enabled drivers and must |
| 196 | free the GEM object and all associated resources. | 196 | free the GEM object and all associated resources. |
| 197 | 197 | ||
| @@ -492,7 +492,7 @@ DRM Sync Objects · 294 unmodified lines | |||
| 492 | :doc: Overview | 492 | :doc: Overview |
| 493 | 493 | ||
| 494 | .. kernel-doc:: include/drm/drm_syncobj.h | 494 | .. kernel-doc:: include/drm/drm_syncobj.h |
| 495 | :export: | 495 | :internal: |
| 496 | 496 | ||
| 497 | .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c | 497 | .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c |
| 498 | :export: | 498 | :export: |
| @@ -160,6 +160,8 @@ other hand, a driver requires shared state between clients which is · 159 unmodified lines | |||
| 160 | visible to user-space and accessible beyond open-file boundaries, they | 160 | visible to user-space and accessible beyond open-file boundaries, they |
| 161 | cannot support render nodes. | 161 | cannot support render nodes. |
| 162 | 162 | ||
| 163 | .. _drm_driver_ioctl: | ||
| 164 | |||
| 163 | IOCTL Support on Device Nodes | 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 | :functions: i915_perf_open_ioctl | 417 | :functions: i915_perf_open_ioctl |
| 418 | .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c | 418 | .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c |
| 419 | :functions: i915_perf_release | 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 | i915 Perf Stream | 425 | i915 Perf Stream |
| 422 | ---------------- | 426 | ---------------- |
| @@ -477,4 +481,16 @@ specific details than found in the more high-level sections. · 54 unmodified lines | |||
| 477 | .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c | 481 | .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c |
| 478 | :internal: | 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 | crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in | 108 | crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in |
| 109 | __drm_atomic_helper_crtc_duplicate_state(). | 109 | __drm_atomic_helper_crtc_duplicate_state(). |
| 110 | 110 | ||
| 111 | - Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_ | 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 | 112 | prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this |
| 113 | is a function useful to implement the fb->dirty function. | 113 | is a function useful to implement the fb->dirty function. |
| 114 | 114 | ||
| 115 | - Create a new drm_fb_dirty function which does essentially what e.g. | 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 | 8 fans. It also contains an integrated watchdog which is currently | 18 | 8 fans. It also contains an integrated watchdog which is currently |
| 19 | implemented in this driver. | 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 | Specification of the chip can be found here: | 25 | Specification of the chip can be found here: |
| 22 | ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf | 26 | ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf |
| 23 | ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf | 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 | Addresses scanned: - | 29 | Addresses scanned: - |
| 30 | Datasheet: | 30 | Datasheet: |
| 31 | http://www.national.com/pf/LM/LM5066.html | 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 | Author: Guenter Roeck <linux@roeck-us.net> | 38 | Author: Guenter Roeck <linux@roeck-us.net> |
| 34 | 39 | ||
| @@ -37,8 +42,8 @@ Description · 2 unmodified lines | |||
| 37 | ----------- | 42 | ----------- |
| 38 | 43 | ||
| 39 | This driver supports hardware monitoring for National Semiconductor / TI LM25056, | 44 | This driver supports hardware monitoring for National Semiconductor / TI LM25056, |
| 40 | LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and | 45 | LM25063, LM25066, LM5064, and LM5066/LM5066I Power Management, Monitoring, |
| 41 | Protection ICs. | 46 | Control, and Protection ICs. |
| 42 | 47 | ||
| 43 | The driver is a client driver to the core PMBus driver. Please see | 48 | The driver is a client driver to the core PMBus driver. Please see |
| 44 | Documentation/hwmon/pmbus for details on PMBus client drivers. | 49 | Documentation/hwmon/pmbus for details on PMBus client drivers. |
| @@ -42,6 +42,10 @@ i2c-arb-gpio-challenge Parent-locked · 41 unmodified lines | |||
| 42 | i2c-mux-gpio Normally parent-locked, mux-locked iff | 42 | i2c-mux-gpio Normally parent-locked, mux-locked iff |
| 43 | all involved gpio pins are controlled by the | 43 | all involved gpio pins are controlled by the |
| 44 | same i2c root adapter that they mux. | 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 | i2c-mux-pca9541 Parent-locked | 49 | i2c-mux-pca9541 Parent-locked |
| 46 | i2c-mux-pca954x Parent-locked | 50 | i2c-mux-pca954x Parent-locked |
| 47 | i2c-mux-pinctrl Normally parent-locked, mux-locked iff | 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 | i2c-mux-reg Parent-locked | 54 | i2c-mux-reg Parent-locked |
| 51 | 55 | ||
| 52 | In drivers/iio/ | 56 | In drivers/iio/ |
| 57 | gyro/mpu3050 Mux-locked | ||
| 53 | imu/inv_mpu6050/ Mux-locked | 58 | imu/inv_mpu6050/ Mux-locked |
| 54 | 59 | ||
| 55 | In drivers/media/ | 60 | In drivers/media/ |
| 61 | dvb-frontends/lgdt3306a Mux-locked | ||
| 56 | dvb-frontends/m88ds3103 Parent-locked | 62 | dvb-frontends/m88ds3103 Parent-locked |
| 57 | dvb-frontends/rtl2830 Parent-locked | 63 | dvb-frontends/rtl2830 Parent-locked |
| 58 | dvb-frontends/rtl2832 Mux-locked | 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 | keyboard | 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 | consumes keyboard keystrokes and handles user input for VT consoles. | 113 | consumes keyboard keystrokes and handles user input for VT consoles. |
| 114 | 114 | ||
| 115 | mousedev | 115 | mousedev |
| @@ -12,7 +12,6 @@ Linux Joystick support · 11 unmodified lines | |||
| 12 | 12 | ||
| 13 | .. toctree:: | 13 | .. toctree:: |
| 14 | :maxdepth: 3 | 14 | :maxdepth: 3 |
| 15 | :numbered: | ||
| 16 | 15 | ||
| 17 | joystick | 16 | joystick |
| 18 | joystick-api | 17 | joystick-api |
| @@ -297,9 +297,9 @@ more details, with real examples. · 296 unmodified lines | |||
| 297 | ccflags-y specifies options for compiling with $(CC). | 297 | ccflags-y specifies options for compiling with $(CC). |
| 298 | 298 | ||
| 299 | Example: | 299 | Example: |
| 300 | # drivers/acpi/Makefile | 300 | # drivers/acpi/acpica/Makefile |
| 301 | ccflags-y := -Os | 301 | ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA |
| 302 | ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT | 302 | ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT |
| 303 | 303 | ||
| 304 | This variable is necessary because the top Makefile owns the | 304 | This variable is necessary because the top Makefile owns the |
| 305 | variable $(KBUILD_CFLAGS) and uses it for compilation flags for the | 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 | Sysfs device attributes for the sensors and fan are on the | 121 | Sysfs device attributes for the sensors and fan are on the |
| 122 | thinkpad_hwmon device's sysfs attribute space, but you should locate it | 122 | thinkpad_hwmon device's sysfs attribute space, but you should locate it |
| 123 | looking for a hwmon device with the name attribute of "thinkpad", or | 123 | looking for a hwmon device with the name attribute of "thinkpad", or |
| 124 | better yet, through libsensors. | 124 | better yet, through libsensors. For 4.14+ sysfs attributes were moved to the |
| 125 | 125 | hwmon device (/sys/bus/platform/devices/thinkpad_hwmon/hwmon/hwmon? or | |
| 126 | /sys/class/hwmon/hwmon?). | ||
| 126 | 127 | ||
| 127 | Driver version | 128 | Driver version |
| 128 | -------------- | 129 | -------------- |
| @@ -1478,3 +1479,7 @@ Sysfs interface changelog: · 1349 unmodified lines | |||
| 1478 | 0x020700: Support for mute-only mixers. | 1479 | 0x020700: Support for mute-only mixers. |
| 1479 | Volume control in read-only mode by default. | 1480 | Volume control in read-only mode by default. |
| 1480 | Marker for ALSA mixer support. | 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 | a process being blocked on the mutex, it is fine to allocate | 97 | a process being blocked on the mutex, it is fine to allocate |
| 98 | the waiter on the process's stack (local variable). This | 98 | the waiter on the process's stack (local variable). This |
| 99 | structure holds a pointer to the task, as well as the mutex that | 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 | 100 | the task is blocked on. It also has rbtree node structures to |
| 101 | place the task in the waiter_list of a mutex as well as the | 101 | place the task in the waiters rbtree of a mutex as well as the |
| 102 | pi_list of a mutex owner task (described below). | 102 | pi_waiters rbtree of a mutex owner task (described below). |
| 103 | 103 | ||
| 104 | waiter is sometimes used in reference to the task that is waiting | 104 | waiter is sometimes used in reference to the task that is waiting |
| 105 | on a mutex. This is the same as waiter->task. | 105 | on a mutex. This is the same as waiter->task. |
| @@ -179,53 +179,34 @@ again. · 73 unmodified lines | |||
| 179 | | | 179 | | |
| 180 | F->L5-+ | 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 | 186 | Mutex Waiters Tree |
| 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 | ||
| 205 | ----------------- | 187 | ----------------- |
| 206 | 188 | ||
| 207 | Every mutex keeps track of all the waiters that are blocked on itself. The mutex | 189 | Every mutex keeps track of all the waiters that are blocked on itself. The |
| 208 | has a plist to store these waiters by priority. This list is protected by | 190 | mutex has a rbtree to store these waiters by priority. This tree is protected |
| 209 | a spin lock that is located in the struct of the mutex. This lock is called | 191 | by 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 | 192 | wait_lock. |
| 211 | interrupt context, the wait_lock can be taken without disabling interrupts. | ||
| 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 | 198 | To keep track of the PI chains, each process has its own PI rbtree. This is |
| 218 | a list of all top waiters of the mutexes that are owned by the process. | 199 | a tree 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 | 200 | Note that this tree only holds the top waiters and not all waiters that are |
| 220 | blocked on mutexes owned by the process. | 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 | is waiting on a mutex that is owned by the task. So if the task has | 204 | is waiting on a mutex that is owned by the task. So if the task has |
| 224 | inherited a priority, it will always be the priority of the task that is | 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 | 208 | This tree is stored in the task structure of a process as a rbtree called |
| 228 | pi_list. This list is protected by a spin lock also in the task structure, | 209 | pi_waiters. It is protected by a spin lock also in the task structure, |
| 229 | called pi_lock. This lock may also be taken in interrupt context, so when | 210 | called pi_lock. This lock may also be taken in interrupt context, so when |
| 230 | locking the pi_lock, interrupts must be disabled. | 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 | The mutex structure contains a pointer to the owner of the mutex. If the | 294 | The mutex structure contains a pointer to the owner of the mutex. If the |
| 314 | mutex is not owned, this owner is set to NULL. Since all architectures | 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 | 296 | have the task structure on at least a two byte alignment (and if this is |
| 316 | not true, the rtmutex.c code will be broken!), this allows for the two | 297 | not true, the rtmutex.c code will be broken!), this allows for the least |
| 317 | least significant bits to be used as flags. This part is also described | 298 | significant bit to be used as a flag. Bit 0 is used as the "Has Waiters" |
| 318 | in Documentation/rt-mutex.txt, but will also be briefly described here. | 299 | flag. It's set whenever there are waiters on a mutex. |
| 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. | ||
| 323 | 300 | ||
| 301 | See Documentation/locking/rt-mutex.txt for further details. | ||
| 324 | 302 | ||
| 325 | cmpxchg Tricks | 303 | cmpxchg Tricks |
| 326 | -------------- | 304 | -------------- |
| @@ -359,40 +337,31 @@ Priority adjustments · 32 unmodified lines | |||
| 359 | -------------------- | 337 | -------------------- |
| 360 | 338 | ||
| 361 | The implementation of the PI code in rtmutex.c has several places that a | 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 | process this is rather easy to know what needs to be adjusted. | 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, | 343 | 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 | 344 | and rt_mutex_setprio. rt_mutex_setprio is only used in rt_mutex_adjust_prio. |
| 367 | to already be taken), rt_mutex_getprio, and rt_mutex_setprio. | ||
| 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 | 355 | (Note: For the "prio" field in task_struct, the lower the number, the |
| 372 | task's own normal priority, or if a process of a higher priority is waiting on | 356 | higher the priority. A "prio" of 5 is of higher priority than a |
| 373 | a mutex owned by the task, then that higher priority should be returned. | 357 | "prio" of 10.) |
| 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. | ||
| 378 | 358 | ||
| 379 | (Note: if looking at the code, you will notice that the lower number of | 359 | It is interesting to note that rt_mutex_adjust_prio can either increase |
| 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 | ||
| 391 | or decrease the priority of the task. In the case that a higher priority | 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 | would increase/boost the task's priority. But if a higher priority task | 362 | would increase/boost the task's priority. But if a higher priority task |
| 394 | were for some reason to leave the mutex (timeout or signal), this same function | 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 | always contains the highest priority task that is waiting on a mutex owned | 365 | always contains the highest priority task that is waiting on a mutex owned |
| 397 | by the task, so we only need to compare the priority of that top pi waiter | 366 | by the task, so we only need to compare the priority of that top pi waiter |
| 398 | to the normal priority of the given task. | 367 | to the normal priority of the given task. |
| @@ -412,9 +381,10 @@ priorities. · 13 unmodified lines | |||
| 412 | 381 | ||
| 413 | rt_mutex_adjust_prio_chain is called with a task to be checked for PI | 382 | rt_mutex_adjust_prio_chain is called with a task to be checked for PI |
| 414 | (de)boosting (the owner of a mutex that a process is blocking on), a flag to | 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 | that is the process's waiter struct that is blocked on the mutex (although this | 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 | For this explanation, I will not mention deadlock detection. This explanation | 389 | For this explanation, I will not mention deadlock detection. This explanation |
| 420 | will try to stay at a high level. | 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 | Before this function is called, the task has already had rt_mutex_adjust_prio | 395 | Before this function is called, the task has already had rt_mutex_adjust_prio |
| 426 | performed on it. This means that the task is set to the priority that it | 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 | 397 | should be at, but the rbtree 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 | 398 | with the new priorities, and 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 | 399 | in the pi_waiters and waiters trees that the task is blocked on. This function |
| 430 | solves all that. | 400 | solves all that. |
| 431 | 401 | ||
| 432 | A loop is entered, where task is the owner to be checked for PI changes that | 402 | The main operation of this function is summarized by Thomas Gleixner in |
| 433 | was passed by parameter (for the first iteration). The pi_lock of this task is | 403 | rtmutex.c. See the 'Chain walk basics and protection scope' comment for further |
| 434 | taken to prevent any more changes to the pi_list of the task. This also | 404 | details. |
| 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 | |||
| 554 | 405 | ||
| 555 | Taking of a mutex (The walk through) | 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 | fails). Only when the owner field of the mutex is NULL can the lock be | 414 | fails). Only when the owner field of the mutex is NULL can the lock be |
| 564 | taken with the CMPXCHG and nothing else needs to be done. | 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 | 417 | If there is contention on the lock, we go about the slow path |
| 567 | we go about the slow path (rt_mutex_slowlock). | 418 | (rt_mutex_slowlock). |
| 568 | 419 | ||
| 569 | The slow path function is where the task's waiter structure is created on | 420 | The slow path function is where the task's waiter structure is created on |
| 570 | the stack. This is because the waiter structure is only needed for the | 421 | the stack. This is because the waiter structure is only needed for the |
| 571 | scope of this function. The waiter structure holds the nodes to store | 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 | 423 | the task on the waiters tree of the mutex, and if need be, the pi_waiters |
| 573 | the owner. | 424 | tree of the owner. |
| 574 | 425 | ||
| 575 | The wait_lock of the mutex is taken since the slow path of unlocking the | 426 | The wait_lock of the mutex is taken since the slow path of unlocking the |
| 576 | mutex also takes this lock. | 427 | mutex also takes this lock. |
| @@ -581,102 +432,45 @@ contention). · 4 unmodified lines | |||
| 581 | 432 | ||
| 582 | try_to_take_rt_mutex is used every time the task tries to grab a mutex in the | 433 | try_to_take_rt_mutex is used every time the task tries to grab a mutex in the |
| 583 | slow path. The first thing that is done here is an atomic setting of | 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 | 435 | the "Has Waiters" flag of the mutex's owner field. By setting this flag |
| 585 | be false, because if the mutex has no owner, there are no waiters and | 436 | now, the current owner of the mutex being contended for can't release the mutex |
| 586 | the current task also won't have any waiters. But we don't have the lock | 437 | without going into the slow unlock path, and it would then need to grab the |
| 587 | yet, so we assume we are going to be a waiter. The reason for this is to | 438 | wait_lock, which this code currently holds. So setting the "Has Waiters" flag |
| 588 | play nice for those architectures that do have CMPXCHG. By setting this flag | 439 | forces the current owner to synchronize with this code. |
| 589 | now, the owner of the mutex can't release the mutex without going into the | 440 | |
| 590 | slow unlock path, and it would then need to grab the wait_lock, which this | 441 | The lock is taken if the following are true: |
| 591 | code currently holds. So setting the "Has Waiters" flag forces the owner | 442 | 1) The lock has no owner |
| 592 | to synchronize with this code. | 443 | 2) The current task is the highest priority against all other |
| 593 | 444 | waiters of the lock | |
| 594 | Now that we know that we can't have any races with the owner releasing the | 445 | |
| 595 | mutex, we check to see if we can take the ownership. This is done if the | 446 | If the task succeeds to acquire the lock, then the task is set as the |
| 596 | mutex doesn't have a owner, or if we can steal the mutex from a pending | 447 | owner of the lock, and if the lock still has waiters, the top_waiter |
| 597 | owner. Let's look at the situations we have here. | 448 | (highest priority task waiting on the lock) is added to this task's |
| 598 | 449 | pi_waiters tree. | |
| 599 | 1) Has owner that is pending | 450 | |
| 600 | ---------------------------- | 451 | If the lock is not taken by try_to_take_rt_mutex(), then the |
| 601 | 452 | task_blocks_on_rt_mutex() function is called. This will add the task to | |
| 602 | The mutex has a owner, but it hasn't woken up and the mutex flag | 453 | the lock's waiter tree and propagate the pi chain of the lock as well |
| 603 | "Pending Owner" is set. The first check is to see if the owner isn't the | 454 | as the lock's owner's pi_waiters tree. This is described in the next |
| 604 | current task. This is because this function is also used for the pending | 455 | section. |
| 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. | ||
| 662 | 456 | ||
| 663 | Task blocks on mutex | 457 | Task blocks on mutex |
| 664 | -------------------- | 458 | -------------------- |
| 665 | 459 | ||
| 666 | The accounting of a mutex and process is done with the waiter structure of | 460 | The accounting of a mutex and process is done with the waiter structure of |
| 667 | the process. The "task" field is set to the process, and the "lock" field | 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 | 462 | to the mutex. The rbtree node of waiter are initialized to the processes |
| 669 | priority. | 463 | current priority. |
| 670 | 464 | ||
| 671 | Since the wait_lock was taken at the entry of the slow lock, we can safely | 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 | 466 | add the waiter to the task waiter tree. If the current process is the |
| 673 | priority process currently waiting on this mutex, then we remove the | 467 | highest 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, | 468 | previous top waiter process (if it exists) from the pi_waiters of the owner, |
| 675 | and add the current process to that list. Since the pi_list of the owner | 469 | and add the current process to that tree. Since the pi_waiter of the owner |
| 676 | has changed, we call rt_mutex_adjust_prio on the owner to see if the owner | 470 | has changed, we call rt_mutex_adjust_prio on the owner to see if the owner |
| 677 | should adjust its priority accordingly. | 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 | (or deadlock checking is on), we unlock the wait_lock of the mutex and go ahead | 474 | (or deadlock checking is on), we unlock the wait_lock of the mutex and go ahead |
| 681 | and run rt_mutex_adjust_prio_chain on the owner, as described earlier. | 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 | Waking up in the loop | 480 | Waking up in the loop |
| 687 | --------------------- | 481 | --------------------- |
| 688 | 482 | ||
| 689 | The schedule can then wake up for a few reasons. | 483 | The task can then wake up for a couple of reasons: |
| 690 | 1) we were given pending ownership of the mutex. | 484 | 1) The previous lock owner released the lock, and the task now is top_waiter |
| 691 | 2) we received a signal and was TASK_INTERRUPTIBLE | 485 | 2) we received a signal or timeout |
| 692 | 3) we had a timeout and was TASK_INTERRUPTIBLE | ||
| 693 | 486 | ||
| 694 | In any of these cases, we continue the loop and once again try to grab the | 487 | In both cases, the task will try again to acquire the lock. If it |
| 695 | ownership of the mutex. If we succeed, we exit the loop, otherwise we continue | 488 | does, then it will take itself off the waiters tree and set itself back |
| 696 | and on signal and timeout, will exit the loop, or if we had the mutex stolen | 489 | to the TASK_RUNNING state. |
| 697 | we just simply add ourselves back on the lists and go back to sleep. | ||
| 698 | 490 | ||
| 699 | Note: For various reasons, because of timeout and signals, the steal mutex | 491 | In first case, if the lock was acquired by another task before this task |
| 700 | algorithm needs to be careful. This is because the current process is | 492 | could get the lock, then it will go back to sleep and wait to be woken again. |
| 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 | ---------------------------------------- | ||
| 707 | 493 | ||
| 708 | If a timeout or signal occurred, the waiter's "task" field would not be | 494 | The second case is only applicable for tasks that are grabbing a mutex |
| 709 | NULL and the task needs to be taken off the wait_list of the mutex and perhaps | 495 | that can wake up before getting the lock, either due to a signal or |
| 710 | pi_list of the owner. If this process was a high priority process, then | 496 | a timeout (i.e. rt_mutex_timed_futex_lock()). When woken, it will try to |
| 711 | the rt_mutex_adjust_prio_chain needs to be executed again on the owner, | 497 | take the lock again, if it succeeds, then the task will return with the |
| 712 | but this time it will be lowering the priorities. | 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 | Unlocking the Mutex | 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 | owner field is set to NULL, the wait_lock is released and nothing more is | 526 | owner field is set to NULL, the wait_lock is released and nothing more is |
| 740 | needed. | 527 | needed. |
| 741 | 528 | ||
| 742 | If there are waiters, then we need to wake one up and give that waiter | 529 | If there are waiters, then we need to wake one up. |
| 743 | pending ownership. | ||
| 744 | 530 | ||
| 745 | On the wake up code, the pi_lock of the current owner is taken. The top | 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 | 532 | waiter of the lock is found and removed from the waiters tree of the mutex |
| 747 | as well as the pi_list of the current owner. The task field of the new | 533 | as well as the pi_waiters tree of the current owner. The "Has Waiters" bit is |
| 748 | pending owner's waiter structure is set to NULL, and the owner field of the | 534 | marked to prevent lower priority tasks from stealing the lock. |
| 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. | ||
| 761 | 535 | ||
| 762 | Finally we unlock the pi_lock of the pending owner and wake it up. | 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 | Author: Steven Rostedt <rostedt@goodmis.org> | 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 | Updates | 555 | Updates |
| 779 | ------- | 556 | ------- |
| 780 | 557 | ||
| 781 | This document was originally written for 2.6.17-rc3-mm1 | 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 | well-designed applications to use userspace locks in critical parts of | 28 | well-designed applications to use userspace locks in critical parts of |
| 29 | an high priority thread, without losing determinism. | 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 | priority order. For same priorities FIFO order is chosen. For each | 32 | priority order. For same priorities FIFO order is chosen. For each |
| 33 | rtmutex, only the top priority waiter is enqueued into the owner's | 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 | the top priority waiter of a task changes (for example it timed out or | 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 | 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 | 37 | priority enqueueing is handled by "pi_waiters". |
| 38 | for more details.] | ||
| 39 | 38 | ||
| 40 | RT-mutexes are optimized for fastpath operations and have no internal | 39 | RT-mutexes are optimized for fastpath operations and have no internal |
| 41 | locking overhead when locking an uncontended mutex or unlocking a mutex | 40 | locking overhead when locking an uncontended mutex or unlocking a mutex |
| @@ -46,34 +45,29 @@ is used] · 4 unmodified lines | |||
| 46 | The state of the rt-mutex is tracked via the owner field of the rt-mutex | 45 | The state of the rt-mutex is tracked via the owner field of the rt-mutex |
| 47 | structure: | 46 | structure: |
| 48 | 47 | ||
| 49 | rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1 | 48 | lock->owner holds the task_struct pointer of the owner. Bit 0 is used to |
| 50 | are used to keep track of the "owner is pending" and "rtmutex has | 49 | keep track of the "lock has waiters" state. |
| 51 | waiters" state. | ||
| 52 | 50 | ||
| 53 | owner bit1 bit0 | 51 | owner bit0 |
| 54 | NULL 0 0 mutex is free (fast acquire possible) | 52 | NULL 0 lock is free (fast acquire possible) |
| 55 | NULL 0 1 invalid state | 53 | NULL 1 lock is free and has waiters and the top waiter |
| 56 | NULL 1 0 Transitional state* | 54 | is going to take the lock* |
| 57 | NULL 1 1 invalid state | 55 | taskpointer 0 lock is held (fast release possible) |
| 58 | taskpointer 0 0 mutex is held (fast release possible) | 56 | taskpointer 1 lock is held and has waiters** |
| 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 | ||
| 62 | 57 | ||
| 63 | Pending-ownership handling is a performance optimization: | 58 | The fast atomic compare exchange based acquire and release is only |
| 64 | pending-ownership is assigned to the first (highest priority) waiter of | 59 | possible when bit 0 of lock->owner is 0. |
| 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. | ||
| 69 | 60 | ||
| 70 | The pending-ownership optimization is especially important for the | 61 | (*) It also can be a transitional state when grabbing the lock |
| 71 | uninterrupted workflow of high-prio tasks which repeatedly | 62 | with ->wait_lock is held. To prevent any fast path cmpxchg to the lock, |
| 72 | takes/releases locks that have lower-prio waiters. Without this | 63 | we need to set the bit0 before looking at the lock, and the owner may be |
| 73 | optimization the higher-prio thread would ping-pong to the lower-prio | 64 | NULL in this small time, hence this can be a transitional state. |
| 74 | task [because at unlock time we always assign a new owner]. | ||
| 75 | 65 | ||
| 76 | (*) The "mutex has waiters" bit gets set to take the lock. If the lock | 66 | (**) There is a small time when bit 0 is set but there are no |
| 77 | doesn't already have an owner, this bit is quickly cleared if there are | 67 | waiters. This can happen when grabbing the lock in the slow path. |
| 78 | no waiters. So this is a transitional state to synchronize with looking | 68 | To prevent a cmpxchg of the owner releasing the lock, we need to |
| 79 | at the owner field of the mutex and the mutex owner releasing the lock. | 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 | This means that ACQUIRE acts as a minimal "acquire" operation and | 498 | This means that ACQUIRE acts as a minimal "acquire" operation and |
| 499 | RELEASE acts as a minimal "release" operation. | 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 | 501 | A subset of the atomic operations described in atomic_t.txt have ACQUIRE and |
| 502 | ACQUIRE and RELEASE variants in addition to fully-ordered and relaxed (no | 502 | RELEASE variants in addition to fully-ordered and relaxed (no barrier |
| 503 | barrier semantics) definitions. For compound atomics performing both a load | 503 | semantics) definitions. For compound atomics performing both a load and a |
| 504 | and a store, ACQUIRE semantics apply only to the load and RELEASE semantics | 504 | store, ACQUIRE semantics apply only to the load and RELEASE semantics apply |
| 505 | apply only to the store portion of the operation. | 505 | only to the store portion of the operation. |
| 506 | 506 | ||
| 507 | Memory barriers are only required where there's a possibility of interaction | 507 | Memory barriers are only required where there's a possibility of interaction |
| 508 | between two CPUs or between a CPU and a device. If it can be guaranteed that | 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 | This enforces the occurrence of one of the two implications, and prevents the | 594 | This enforces the occurrence of one of the two implications, and prevents the |
| 595 | third possibility from arising. | 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 | CPU 1 CPU 2 | 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 | <write barrier> | 620 | <write barrier> |
| 604 | WRITE_ONCE(P, &B); | 621 | WRITE_ONCE(P, &B); |
| 605 | Q = READ_ONCE(P); | 622 | Q = READ_ONCE(P); |
| 606 | <data dependency barrier> | 623 | WRITE_ONCE(*Q, 5); |
| 607 | *Q = 5; | ||
| 608 | 624 | ||
| 609 | The data-dependency barrier must order the read into Q with the store | 625 | Therefore, no data-dependency barrier is required to order the read into |
| 610 | into *Q. This prohibits this outcome: | 626 | Q with the store into *Q. In other words, this outcome is prohibited, |
| 627 | even without a data-dependency barrier: | ||
| 611 | 628 | ||
| 612 | (Q == &B) && (B == 4) | 629 | (Q == &B) && (B == 4) |
| 613 | 630 | ||
| 614 | Please note that this pattern should be rare. After all, the whole point | 631 | Please note that this pattern should be rare. After all, the whole point |
| 615 | of dependency ordering is to -prevent- writes to the data structure, along | 632 | of dependency ordering is to -prevent- writes to the data structure, along |
| 616 | with the expensive cache misses associated with those writes. This pattern | 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 | 634 | can be used to record rare error conditions and the like, and the CPUs' |
| 618 | prevents such records from being lost. | 635 | naturally occurring ordering 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). | ||
| 629 | 636 | ||
| 630 | 637 | ||
| 631 | The data dependency barrier is very important to the RCU system, | 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 | This makes sure that the death mark on the object is perceived to be set | 1883 | This makes sure that the death mark on the object is perceived to be set |
| 1877 | *before* the reference counter is decremented. | 1884 | *before* the reference counter is decremented. |
| 1878 | 1885 | ||
| 1879 | See Documentation/core-api/atomic_ops.rst for more information. See the | 1886 | See Documentation/atomic_{t,bitops}.txt for more information. |
| 1880 | "Atomic operations" subsection for information on where to use these. | ||
| 1881 | 1887 | ||
| 1882 | 1888 | ||
| 1883 | (*) lockless_dereference(); | 1889 | (*) lockless_dereference(); |
| @@ -1982,10 +1988,7 @@ for each construct. These operations all imply certain barriers: · 98 unmodified lines | |||
| 1982 | ACQUIRE operation has completed. | 1988 | ACQUIRE operation has completed. |
| 1983 | 1989 | ||
| 1984 | Memory operations issued before the ACQUIRE may be completed after | 1990 | Memory operations issued before the ACQUIRE may be completed after |
| 1985 | the ACQUIRE operation has completed. An smp_mb__before_spinlock(), | 1991 | the ACQUIRE operation has completed. |
| 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. | ||
| 1989 | 1992 | ||
| 1990 | (2) RELEASE operation implication: | 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 | some don't, but they're very heavily relied on as a group throughout the | 2506 | some don't, but they're very heavily relied on as a group throughout the |
| 2504 | kernel. | 2507 | kernel. |
| 2505 | 2508 | ||
| 2506 | Any atomic operation that modifies some state in memory and returns information | 2509 | See Documentation/atomic_t.txt for more 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. | ||
| 2588 | 2510 | ||
| 2589 | 2511 | ||
| 2590 | ACCESSING DEVICES | 2512 | ACCESSING DEVICES |
| @@ -30,8 +30,6 @@ atm.txt · 29 unmodified lines | |||
| 30 | - info on where to get ATM programs and support for Linux. | 30 | - info on where to get ATM programs and support for Linux. |
| 31 | ax25.txt | 31 | ax25.txt |
| 32 | - info on using AX.25 and NET/ROM code for Linux | 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 | baycom.txt | 33 | baycom.txt |
| 36 | - info on the driver for Baycom style amateur radio modems | 34 | - info on the driver for Baycom style amateur radio modems |
| 37 | bonding.txt | 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 | - Configuring DPAA Ethernet in your kernel | 13 | - Configuring DPAA Ethernet in your kernel |
| 14 | - DPAA Ethernet Frame Processing | 14 | - DPAA Ethernet Frame Processing |
| 15 | - DPAA Ethernet Features | 15 | - DPAA Ethernet Features |
| 16 | - DPAA IRQ Affinity and Receive Side Scaling | ||
| 16 | - Debugging | 17 | - Debugging |
| 17 | 18 | ||
| 18 | DPAA Ethernet Overview | 19 | DPAA Ethernet Overview |
| @@ -147,7 +148,10 @@ gradually. · 128 unmodified lines | |||
| 147 | 148 | ||
| 148 | The driver has Rx and Tx checksum offloading for UDP and TCP. Currently the Rx | 149 | The driver has Rx and Tx checksum offloading for UDP and TCP. Currently the Rx |
| 149 | checksum offload feature is enabled by default and cannot be controlled through | 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 | The driver has support for multiple prioritized Tx traffic classes. Priorities | 156 | The driver has support for multiple prioritized Tx traffic classes. Priorities |
| 153 | range from 0 (lowest) to 3 (highest). These are mapped to HW workqueues with | 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 | tc qdisc add dev <int> root handle 1: \ | 170 | tc qdisc add dev <int> root handle 1: \ |
| 167 | mqprio num_tc 4 map 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 hw 1 | 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 | Debugging | 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 | qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places | 45 | qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places |
| 46 | such as team driver, PTP code, etc where BPF is being used. | 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 | Original BPF paper: | 50 | Original BPF paper: |
| 51 | 51 | ||
| @@ -337,7 +337,7 @@ Examples for low-level BPF: · 285 unmodified lines | |||
| 337 | jeq #14, good /* __NR_rt_sigprocmask */ | 337 | jeq #14, good /* __NR_rt_sigprocmask */ |
| 338 | jeq #13, good /* __NR_rt_sigaction */ | 338 | jeq #13, good /* __NR_rt_sigaction */ |
| 339 | jeq #35, good /* __NR_nanosleep */ | 339 | jeq #35, good /* __NR_nanosleep */ |
| 340 | bad: ret #0 /* SECCOMP_RET_KILL */ | 340 | bad: ret #0 /* SECCOMP_RET_KILL_THREAD */ |
| 341 | good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ | 341 | good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ |
| 342 | 342 | ||
| 343 | The above example code can be placed into a file (here called "foo"), and | 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 | before a conversion to the new layout is being done behind the scenes! | 596 | before a conversion to the new layout is being done behind the scenes! |
| 597 | 597 | ||
| 598 | Currently, the classic BPF format is being used for JITing on most 32-bit | 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 | 599 | architectures, whereas x86-64, aarch64, s390x, powerpc64, sparc64, arm32 perform |
| 600 | compilation from eBPF instruction set. | 600 | JIT compilation from eBPF instruction set. |
| 601 | 601 | ||
| 602 | Some core changes of the new internal format: | 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 | bpf_exit | 793 | bpf_exit |
| 794 | 794 | ||
| 795 | After the call the registers R1-R5 contain junk values and cannot be read. | 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 | Also in the new design, eBPF is limited to 4096 insns, which means that any | 798 | Also in the new design, eBPF is limited to 4096 insns, which means that any |
| 799 | program will terminate quickly and will only call a fixed number of kernel | 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 | BPF_JSGE 0x70 /* eBPF only: signed '>=' */ | 906 | BPF_JSGE 0x70 /* eBPF only: signed '>=' */ |
| 907 | BPF_CALL 0x80 /* eBPF only: function call */ | 907 | BPF_CALL 0x80 /* eBPF only: function call */ |
| 908 | BPF_EXIT 0x90 /* eBPF only: function return */ | 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 | So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF | 914 | So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF |
| 911 | and eBPF. There are only two registers in classic BPF, so it means A += X. | 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 | and has type PTR_TO_CTX. | 1021 | and has type PTR_TO_CTX. |
| 1018 | If verifier sees an insn that does R2=R1, then R2 has now type | 1022 | If verifier sees an insn that does R2=R1, then R2 has now type |
| 1019 | PTR_TO_CTX as well and can be used on the right hand side of expression. | 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 | since addition of two valid pointers makes invalid pointer. | 1025 | since addition of two valid pointers makes invalid pointer. |
| 1022 | (In 'secure' mode verifier will reject any type of pointer arithmetic to make | 1026 | (In 'secure' mode verifier will reject any type of pointer arithmetic to make |
| 1023 | sure that kernel addresses don't leak to unprivileged users) | 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 | been rejected. | 1043 | been rejected. |
| 1040 | 1044 | ||
| 1041 | load/store instructions are allowed only with registers of valid types, which | 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 | For example: | 1047 | For example: |
| 1044 | bpf_mov R1 = 1 | 1048 | bpf_mov R1 = 1 |
| 1045 | bpf_mov R2 = 2 | 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 | If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know | 1062 | If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know |
| 1059 | that offset 8 of size 4 bytes can be accessed for reading, otherwise | 1063 | that offset 8 of size 4 bytes can be accessed for reading, otherwise |
| 1060 | the verifier will reject the program. | 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 | stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8, | 1066 | stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8, |
| 1063 | so it will fail verification, since it's out of bounds. | 1067 | so it will fail verification, since it's out of bounds. |
| 1064 | 1068 | ||
| @@ -1069,7 +1073,7 @@ For example: · 4 unmodified lines | |||
| 1069 | bpf_ld R0 = *(u32 *)(R10 - 4) | 1073 | bpf_ld R0 = *(u32 *)(R10 - 4) |
| 1070 | bpf_exit | 1074 | bpf_exit |
| 1071 | is invalid program. | 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 | and R10 - 4 is within stack bounds, there were no stores into that location. | 1077 | and R10 - 4 is within stack bounds, there were no stores into that location. |
| 1074 | 1078 | ||
| 1075 | Pointer register spill/fill is tracked as well, since four (R6-R9) | 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 | See details of eBPF verifier in kernel/bpf/verifier.c | 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 | Direct packet access | 1166 | Direct packet access |
| 1098 | -------------------- | 1167 | -------------------- |
| 1099 | In cls_bpf and act_bpf programs the verifier allows direct access to the packet | 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 | which is zero bytes. | 1190 | which is zero bytes. |
| 1122 | 1191 | ||
| 1123 | More complex packet access may look like: | 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 | 6: r0 = *(u8 *)(r3 +7) /* load 7th byte from the packet */ | 1194 | 6: r0 = *(u8 *)(r3 +7) /* load 7th byte from the packet */ |
| 1126 | 7: r4 = *(u8 *)(r3 +12) | 1195 | 7: r4 = *(u8 *)(r3 +12) |
| 1127 | 8: r4 *= 14 | 1196 | 8: r4 *= 14 |
| @@ -1135,26 +1204,31 @@ More complex packet access may look like: · 7 unmodified lines | |||
| 1135 | 16: r2 += 8 | 1204 | 16: r2 += 8 |
| 1136 | 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */ | 1205 | 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */ |
| 1137 | 18: if r2 > r1 goto pc+2 | 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 | 19: r1 = *(u8 *)(r3 +4) | 1208 | 19: r1 = *(u8 *)(r3 +4) |
| 1140 | The state of the register R3 is R3=pkt(id=2,off=0,r=8) | 1209 | The state of the register R3 is R3=pkt(id=2,off=0,r=8) |
| 1141 | id=2 means that two 'r3 += rX' instructions were seen, so r3 points to some | 1210 | id=2 means that two 'r3 += rX' instructions were seen, so r3 points to some |
| 1142 | offset within a packet and since the program author did | 1211 | offset within a packet and since the program author did |
| 1143 | 'if (r3 + 8 > r1) goto err' at insn #18, the safe range is [R3, R3 + 8). | 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 | 1213 | The verifier only allows 'add'/'sub' operations on packet registers. Any other |
| 1145 | operation will set the register state to 'unknown_value' and it won't be | 1214 | operation will set the register state to 'SCALAR_VALUE' and it won't be |
| 1146 | available for direct packet access. | 1215 | available for direct packet access. |
| 1147 | Operation 'r3 += rX' may overflow and become less than original skb->data, | 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 | 1217 | therefore the verifier has to prevent that. So when it sees 'r3 += rX' |
| 1149 | upper zero bits in all 'uknown_value' registers, so when it sees | 1218 | instruction and rX is more than 16-bit value, any subsequent bounds-check of r3 |
| 1150 | 'r3 += rX' instruction and rX is more than 16-bit value, it will error as: | 1219 | against skb->data_end will not give us 'range' information, so attempts to read |
| 1151 | "cannot add integer value with N upper zero bits to ptr_to_packet" | 1220 | through the pointer will give "invalid access to packet" error. |
| 1152 | Ex. after insn 'r4 = *(u8 *)(r3 +12)' (insn #7 above) the state of r4 is | 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 | 1222 | R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) which means that upper 56 bits |
| 1154 | to be zero. After insn 'r4 *= 14' the state becomes R4=inv52, since | 1223 | of the register are guaranteed to be zero, and nothing is known about the lower |
| 1155 | multiplying 8-bit value by constant 14 will keep upper 52 bits as zero. | 1224 | 8 bits. After insn 'r4 *= 14' the state becomes |
| 1156 | Similarly 'r2 >>= 48' will make R2=inv48, since the shift is not sign | 1225 | R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), since multiplying an 8-bit |
| 1157 | extending. This logic is implemented in evaluate_reg_alu() function. | 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 | The end result is that bpf program author can access packet directly | 1233 | The end result is that bpf program author can access packet directly |
| 1160 | using normal C code as: | 1234 | using normal C code as: |
| @@ -1214,6 +1288,22 @@ The map is defined by: · 53 unmodified lines | |||
| 1214 | . key size in bytes | 1288 | . key size in bytes |
| 1215 | . value size in bytes | 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 | Understanding eBPF verifier messages | 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 | The include/net/mac802154.h defines following functions: | 86 | The include/net/mac802154.h defines following functions: |
| 87 | - struct ieee802154_dev *ieee802154_alloc_device | 87 | - struct ieee802154_hw * |
| 88 | (size_t priv_size, struct ieee802154_ops *ops): | 88 | ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops): |
| 89 | allocation of IEEE 802.15.4 compatible device | 89 | allocation of IEEE 802.15.4 compatible hardware device |
| 90 | 90 | ||
| 91 | - void ieee802154_free_device(struct ieee802154_dev *dev): | 91 | - void ieee802154_free_hw(struct ieee802154_hw *hw): |
| 92 | freeing allocated device | 92 | freeing allocated hardware device |
| 93 | 93 | ||
| 94 | - int ieee802154_register_device(struct ieee802154_dev *dev): | 94 | - int ieee802154_register_hw(struct ieee802154_hw *hw): |
| 95 | register PHY in the system | 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 | freeing registered PHY | 98 | freeing registered PHY |
| 99 | 99 | ||
| 100 | Moreover IEEE 802.15.4 device operations structure should be filled. | 100 | Moreover IEEE 802.15.4 device operations structure should be filled. |
| @@ -6,6 +6,7 @@ Contents: · 5 unmodified lines | |||
| 6 | .. toctree:: | 6 | .. toctree:: |
| 7 | :maxdepth: 2 | 7 | :maxdepth: 2 |
| 8 | 8 | ||
| 9 | batman-adv | ||
| 9 | kapi | 10 | kapi |
| 10 | z8530book | 11 | z8530book |
| 11 | 12 | ||
| @@ -109,7 +109,10 @@ neigh/default/unres_qlen_bytes - INTEGER · 108 unmodified lines | |||
| 109 | queued for each unresolved address by other network layers. | 109 | queued for each unresolved address by other network layers. |
| 110 | (added in linux 3.3) | 110 | (added in linux 3.3) |
| 111 | Setting negative value is meaningless and will return error. | 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 | neigh/default/unres_qlen - INTEGER | 117 | neigh/default/unres_qlen - INTEGER |
| 115 | The maximum number of packets which may be queued for each | 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 | unexpected packet loss. The current default value is calculated | 122 | unexpected packet loss. The current default value is calculated |
| 120 | according to default value of unres_qlen_bytes and true size of | 123 | according to default value of unres_qlen_bytes and true size of |
| 121 | packet. | 124 | packet. |
| 122 | Default: 31 | 125 | Default: 101 |
| 123 | 126 | ||
| 124 | mtu_expires - INTEGER | 127 | mtu_expires - INTEGER |
| 125 | Time, in seconds, that cached PMTU information is kept. | 128 | Time, in seconds, that cached PMTU information is kept. |
| @@ -353,12 +356,7 @@ tcp_l3mdev_accept - BOOLEAN · 227 unmodified lines | |||
| 353 | compiled with CONFIG_NET_L3_MASTER_DEV. | 356 | compiled with CONFIG_NET_L3_MASTER_DEV. |
| 354 | 357 | ||
| 355 | tcp_low_latency - BOOLEAN | 358 | tcp_low_latency - BOOLEAN |
| 356 | If set, the TCP stack makes decisions that prefer lower | 359 | This is a legacy option, it has no effect anymore. |
| 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 | ||
| 362 | 360 | ||
| 363 | tcp_max_orphans - INTEGER | 361 | tcp_max_orphans - INTEGER |
| 364 | Maximal number of TCP sockets not attached to any user file handle, | 362 | Maximal number of TCP sockets not attached to any user file handle, |
| @@ -1291,8 +1289,7 @@ tag - INTEGER · 926 unmodified lines | |||
| 1291 | xfrm4_gc_thresh - INTEGER | 1289 | xfrm4_gc_thresh - INTEGER |
| 1292 | The threshold at which we will start garbage collecting for IPv4 | 1290 | The threshold at which we will start garbage collecting for IPv4 |
| 1293 | destination cache entries. At twice this value the system will | 1291 | destination cache entries. At twice this value the system will |
| 1294 | refuse new allocations. The value must be set below the flowcache | 1292 | refuse new allocations. |
| 1295 | limit (4096 * number of online cpus) to take effect. | ||
| 1296 | 1293 | ||
| 1297 | igmp_link_local_mcast_reports - BOOLEAN | 1294 | igmp_link_local_mcast_reports - BOOLEAN |
| 1298 | Enable IGMP reports for link local multicast groups in the | 1295 | Enable IGMP reports for link local multicast groups in the |
| @@ -1356,6 +1353,15 @@ flowlabel_state_ranges - BOOLEAN · 57 unmodified lines | |||
| 1356 | FALSE: disabled | 1353 | FALSE: disabled |
| 1357 | Default: true | 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 | anycast_src_echo_reply - BOOLEAN | 1365 | anycast_src_echo_reply - BOOLEAN |
| 1360 | Controls the use of anycast addresses as source addresses for ICMPv6 | 1366 | Controls the use of anycast addresses as source addresses for ICMPv6 |
| 1361 | echo reply | 1367 | echo reply |
| @@ -1674,6 +1680,9 @@ accept_dad - INTEGER · 312 unmodified lines | |||
| 1674 | 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate | 1680 | 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate |
| 1675 | link-local address has been found. | 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 | force_tllao - BOOLEAN | 1686 | force_tllao - BOOLEAN |
| 1678 | Enable sending the target link-layer address option even when | 1687 | Enable sending the target link-layer address option even when |
| 1679 | responding to a unicast neighbor solicitation. | 1688 | responding to a unicast neighbor solicitation. |
| @@ -1721,16 +1730,23 @@ suppress_frag_ndisc - INTEGER · 41 unmodified lines | |||
| 1721 | 1730 | ||
| 1722 | optimistic_dad - BOOLEAN | 1731 | optimistic_dad - BOOLEAN |
| 1723 | Whether to perform Optimistic Duplicate Address Detection (RFC 4429). | 1732 | Whether to perform Optimistic Duplicate Address Detection (RFC 4429). |
| 1724 | 0: disabled (default) | 1733 | 0: disabled (default) |
| 1725 | 1: enabled | 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 | use_optimistic - BOOLEAN | 1740 | use_optimistic - BOOLEAN |
| 1728 | If enabled, do not classify optimistic addresses as deprecated during | 1741 | If enabled, do not classify optimistic addresses as deprecated during |
| 1729 | source address selection. Preferred addresses will still be chosen | 1742 | source address selection. Preferred addresses will still be chosen |
| 1730 | before optimistic addresses, subject to other ranking in the source | 1743 | before optimistic addresses, subject to other ranking in the source |
| 1731 | address selection algorithm. | 1744 | address selection algorithm. |
| 1732 | 0: disabled (default) | 1745 | 0: disabled (default) |
| 1733 | 1: enabled | 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 | stable_secret - IPv6 address | 1751 | stable_secret - IPv6 address |
| 1736 | This IPv6 address will be used as a secret to generate IPv6 | 1752 | This IPv6 address will be used as a secret to generate IPv6 |
| @@ -1778,8 +1794,7 @@ ratelimit - INTEGER · 41 unmodified lines | |||
| 1778 | xfrm6_gc_thresh - INTEGER | 1794 | xfrm6_gc_thresh - INTEGER |
| 1779 | The threshold at which we will start garbage collecting for IPv6 | 1795 | The threshold at which we will start garbage collecting for IPv6 |
| 1780 | destination cache entries. At twice this value the system will | 1796 | destination cache entries. At twice this value the system will |
| 1781 | refuse new allocations. The value must be set below the flowcache | 1797 | refuse new allocations. |
| 1782 | limit (4096 * number of online cpus) to take effect. | ||
| 1783 | 1798 | ||
| 1784 | 1799 | ||
| 1785 | IPv6 Update by: | 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 | patch is a good way to ensure your patch is ignored or pushed to | 111 | patch is a good way to ensure your patch is ignored or pushed to |
| 112 | the bottom of the priority list. | 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 | Q: How can I tell what patches are queued up for backporting to the | 122 | Q: How can I tell what patches are queued up for backporting to the |
| 115 | various stable releases? | 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 | Size of connection tracking table. Default value is | 96 | Size of connection tracking table. Default value is |
| 97 | nf_conntrack_buckets value * 4. | 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 | nf_conntrack_tcp_be_liberal - BOOLEAN | 99 | nf_conntrack_tcp_be_liberal - BOOLEAN |
| 111 | 0 - disabled (default) | 100 | 0 - disabled (default) |
| 112 | not 0 - enabled | 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 | (*) Send data through a call. | 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 | int rxrpc_kernel_send_data(struct socket *sock, | 825 | int rxrpc_kernel_send_data(struct socket *sock, |
| 822 | struct rxrpc_call *call, | 826 | struct rxrpc_call *call, |
| 823 | struct msghdr *msg, | 827 | struct msghdr *msg, |
| 824 | size_t len); | 828 | size_t len, |
| 829 | rxrpc_notify_end_tx_t notify_end_rx); | ||
| 825 | 830 | ||
| 826 | This is used to supply either the request part of a client call or the | 831 | This is used to supply either the request part of a client call or the |
| 827 | reply part of a server call. msg.msg_iovlen and msg.msg_iov specify the | 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 | The msg must not specify a destination address, control data or any flags | 837 | The msg must not specify a destination address, control data or any flags |
| 833 | other than MSG_MORE. len is the total amount of data to transmit. | 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 | (*) Receive data from a call. | 845 | (*) Receive data from a call. |
| 836 | 846 | ||
| 837 | int rxrpc_kernel_recv_data(struct socket *sock, | 847 | int rxrpc_kernel_recv_data(struct socket *sock, |
| @@ -965,6 +975,51 @@ The kernel interface functions are as follows: · 127 unmodified lines | |||
| 965 | size should be set when the call is begun. tx_total_len may not be less | 975 | size should be set when the call is begun. tx_total_len may not be less |
| 966 | than zero. | 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 | CONFIGURABLE PARAMETERS | 1025 | CONFIGURABLE PARAMETERS |
| @@ -1,45 +1,107 @@ | |||
| 1 | Stream Parser | 1 | Stream Parser (strparser) |
| 2 | ------------- | 2 | |
| 3 | Introduction | ||
| 4 | ============ | ||
| 3 | 5 | ||
| 4 | The stream parser (strparser) is a utility that parses messages of an | 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 | parser works in conjunction with an upper layer in the kernel to provide | 8 | parser works in conjunction with an upper layer in the kernel to provide |
| 7 | kernel support for application layer messages. For instance, Kernel | 9 | kernel support for application layer messages. For instance, Kernel |
| 8 | Connection Multiplexor (KCM) uses the Stream Parser to parse messages | 10 | Connection Multiplexor (KCM) uses the Stream Parser to parse messages |
| 9 | using a BPF program. | 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 | Interface | 25 | Interface |
| 12 | --------- | 26 | ========= |
| 13 | 27 | ||
| 14 | The API includes a context structure, a set of callbacks, utility | 28 | The API includes a context structure, a set of callbacks, utility |
| 15 | functions, and a data_ready function. The callbacks include | 29 | functions, and a data_ready function for receive callback mode. The |
| 16 | a parse_msg function that is called to perform parsing (e.g. | 30 | callbacks include a parse_msg function that is called to perform |
| 17 | BPF parsing in case of KCM), and a rcv_msg function that is called | 31 | parsing (e.g. BPF parsing in case of KCM), and a rcv_msg function |
| 18 | when a full message has been completed. | 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 | 68 | int strp_process(struct strparser *strp, struct sk_buff *orig_skb, |
| 21 | by: | 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, | 72 | strp_process is called in general mode for a stream parser to |
| 24 | struct strp_callbacks *cb) | 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. | 78 | void strp_data_ready(struct strparser *strp); |
| 27 | csk is the TCP socket associated with the stream parser. Callbacks are | 79 | |
| 28 | called by the stream parser. | 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 | Callbacks | 92 | Callbacks |
| 31 | --------- | 93 | ========= |
| 32 | 94 | ||
| 33 | There are four callbacks: | 95 | There are six callbacks: |
| 34 | 96 | ||
| 35 | int (*parse_msg)(struct strparser *strp, struct sk_buff *skb); | 97 | int (*parse_msg)(struct strparser *strp, struct sk_buff *skb); |
| 36 | 98 | ||
| 37 | parse_msg is called to determine the length of the next message | 99 | parse_msg is called to determine the length of the next message |
| 38 | in the stream. The upper layer must implement this function. It | 100 | in the stream. The upper layer must implement this function. It |
| 39 | should parse the sk_buff as containing the headers for the | 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 | the offset field is relevant in parse_msg and gives the offset | 105 | the offset field is relevant in parse_msg and gives the offset |
| 44 | where the message starts in the skb. | 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 | -ESTRPIPE : current message should not be processed by the | 112 | -ESTRPIPE : current message should not be processed by the |
| 51 | kernel, return control of the socket to userspace which | 113 | kernel, return control of the socket to userspace which |
| 52 | can proceed to read the messages itself | 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 | assuming that synchronization is lost and the stream | 116 | assuming that synchronization is lost and the stream |
| 55 | is unrecoverable (application expected to close TCP socket) | 117 | is unrecoverable (application expected to close TCP socket) |
| 56 | 118 | ||
| 57 | In the case that an error is returned (return value is less than | 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 | 120 | zero) and the parser is in receive callback mode, then it will set |
| 59 | it up. If parse_msg returned -ESTRPIPE and the stream parser had | 121 | the error on TCP socket and wake it up. If parse_msg returned |
| 60 | previously read some bytes for the current message, then the error | 122 | -ESTRPIPE and the stream parser had previously read some bytes for |
| 61 | set on the attached socket is ENODATA since the stream is | 123 | the current message, then the error set on the attached socket is |
| 62 | unrecoverable in that case. | 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 | void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb); | 141 | void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb); |
| 65 | 142 | ||
| 66 | rcv_msg is called when a full message has been received and | 143 | rcv_msg is called when a full message has been received and |
| 67 | is queued. The callee must consume the sk_buff; it can | 144 | is queued. The callee must consume the sk_buff; it can |
| 68 | call strp_pause to prevent any further messages from being | 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 | must be set. | 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 | struct contains two fields: offset and full_len. Offset is | 150 | struct contains two fields: offset and full_len. Offset is |
| 74 | where the message starts in the skb, and full_len is the | 151 | where the message starts in the skb, and full_len is the |
| 75 | the length of the message. skb->len - offset may be greater | 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 | int (*read_sock_done)(struct strparser *strp, int err); | 155 | int (*read_sock_done)(struct strparser *strp, int err); |
| 79 | 156 | ||
| 80 | read_sock_done is called when the stream parser is done reading | 157 | read_sock_done is called when the stream parser is done reading |
| 81 | the TCP socket. The stream parser may read multiple messages | 158 | the TCP socket in receive callback mode. The stream parser may |
| 82 | in a loop and this function allows cleanup to occur when existing | 159 | read multiple messages in a loop and this function allows cleanup |
| 83 | the loop. If the callback is not set (NULL in strp_init) a | 160 | to occur when exiting the loop. If the callback is not set (NULL |
| 84 | default function is used. | 161 | in strp_init) a default function is used. |
| 85 | 162 | ||
| 86 | void (*abort_parser)(struct strparser *strp, int err); | 163 | void (*abort_parser)(struct strparser *strp, int err); |
| 87 | 164 | ||
| 88 | This function is called when stream parser encounters an error | 165 | This function is called when stream parser encounters an error |
| 89 | in parsing. The default function stops the stream parser for the | 166 | in parsing. The default function stops the stream parser and |
| 90 | TCP socket and sets the error in the socket. The default function | 167 | sets the error in the socket if the parser is in receive callback |
| 91 | can be changed by setting the callback to non-NULL in strp_init. | 168 | mode. The default function can be changed by setting the callback |
| 169 | to non-NULL in strp_init. | ||
| 92 | 170 | ||
| 93 | Functions | 171 | Statistics |
| 94 | --------- | 172 | ========== |
| 95 | 173 | ||
| 96 | The upper layer calls strp_tcp_data_ready when data is ready on the lower | 174 | Various counters are kept for each stream parser instance. These are in |
| 97 | socket for strparser to process. This should be called from a data_ready | 175 | the strp_stats structure. strp_aggr_stats is a convenience structure for |
| 98 | callback that is set on the socket. | 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 | 180 | Message assembly limits |
| 101 | is called internally when the stream parser encounters an error, and | 181 | ======================= |
| 102 | it is called from the upper layer when unattaching a TCP socket. | ||
| 103 | 182 | ||
| 104 | strp_done is called to unattach the stream parser from the TCP socket. | 183 | The stream parser provide mechanisms to limit the resources consumed by |
| 105 | This must be called after the stream processor has be stopped. | 184 | message assembly. |
| 106 | 185 | ||
| 107 | strp_check_rcv is called to check for new messages on the socket. This | 186 | A timer is set when assembly starts for a new message. In receive |
| 108 | is normally called at initialization of the a stream parser instance | 187 | callback mode the message timeout is taken from rcvtime for the |
| 109 | of after strp_unpause. | 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 | 193 | In receive callback mode, message length is limited to the receive |
| 112 | ---------- | 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. | 200 | In general mode the message length limit is passed in as an argument |
| 115 | These are in the strp_stats structure. strp_aggr_stats is a convenience | 201 | to strp_process. |
| 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. | ||
| 119 | 202 | ||
| 120 | Message assembly limits | 203 | Author |
| 121 | ----------------------- | 204 | ====== |
| 122 | 205 | ||
| 123 | The stream parser provide mechanisms to limit the resources consumed by | 206 | Tom Herbert (tom@quantonium.net) |
| 124 | message assembly. | ||
| 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 | with SR-IOV or soft switches, such as OVS, are possible. | 13 | with SR-IOV or soft switches, such as OVS, are possible. |
| 14 | 14 | ||
| 15 | 15 | ||
| 16 | User-space tools | 16 | User-space tools |
| 17 | 17 | ||
| 18 | user space | | 18 | user space | |
| 19 | +-------------------------------------------------------------------+ | 19 | +-------------------------------------------------------------------+ |
| 20 | kernel | Netlink | 20 | kernel | Netlink |
| 21 | | | 21 | | |
| 22 | +--------------+-------------------------------+ | 22 | +--------------+-------------------------------+ |
| 23 | | Network stack | | 23 | | Network stack | |
| 24 | | (Linux) | | 24 | | (Linux) | |
| 25 | | | | 25 | | | |
| 26 | +----------------------------------------------+ | 26 | +----------------------------------------------+ |
| 27 | 27 | ||
| 28 | sw1p2 sw1p4 sw1p6 | 28 | sw1p2 sw1p4 sw1p6 |
| 29 | sw1p1 + sw1p3 + sw1p5 + eth1 | 29 | sw1p1 + sw1p3 + sw1p5 + eth1 |
| 30 | + | + | + | + | 30 | + | + | + | + |
| 31 | | | | | | | | | 31 | | | | | | | | |
| 32 | +--+----+----+----+-+--+----+---+ +-----+-----+ | 32 | +--+----+----+----+----+----+---+ +-----+-----+ |
| 33 | | Switch driver | | mgmt | | 33 | | Switch driver | | mgmt | |
| 34 | | (this document) | | driver | | 34 | | (this document) | | driver | |
| 35 | | | | | | 35 | | | | | |
| 36 | +--------------+----------------+ +-----------+ | 36 | +--------------+----------------+ +-----------+ |
| 37 | | | 37 | | |
| 38 | kernel | HW bus (eg PCI) | 38 | kernel | HW bus (eg PCI) |
| 39 | +-------------------------------------------------------------------+ | 39 | +-------------------------------------------------------------------+ |
| 40 | hardware | | 40 | hardware | |
| 41 | +--------------+---+------------+ | 41 | +--------------+----------------+ |
| 42 | | Switch device (sw1) | | 42 | | Switch device (sw1) | |
| 43 | | +----+ +--------+ | 43 | | +----+ +--------+ |
| 44 | | | v offloaded data path | mgmt port | 44 | | | v offloaded data path | mgmt port |
| 45 | | | | | | 45 | | | | | |
| 46 | +--|----|----+----+----+----+---+ | 46 | +--|----|----+----+----+----+---+ |
| 47 | | | | | | | | 47 | | | | | | | |
| 48 | + + + + + + | 48 | + + + + + + |
| 49 | p1 p2 p3 p4 p5 p6 | 49 | p1 p2 p3 p4 p5 p6 |
| 50 | 50 | ||
| 51 | front-panel ports | 51 | front-panel ports |
| 52 | 52 | ||
| 53 | 53 | ||
| 54 | Fig 1. | 54 | Fig 1. |
| @@ -228,7 +228,7 @@ Learning on the device port should be enabled, as well as learning_sync: · 173 unmodified lines | |||
| 228 | bridge link set dev DEV learning on self | 228 | bridge link set dev DEV learning on self |
| 229 | bridge link set dev DEV learning_sync on self | 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 | the bridge's FDB. It's possible, but not optimal, to enable learning on the | 232 | the bridge's FDB. It's possible, but not optimal, to enable learning on the |
| 233 | device port and on the bridge port, and disable learning_sync. | 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 | port device supports ageing, when the FDB entry expires, it will notify the | 245 | port device supports ageing, when the FDB entry expires, it will notify the |
| 246 | driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the | 246 | driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the |
| 247 | device does not support ageing, the driver can simulate ageing using a | 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 | notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for | 249 | notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for |
| 250 | example of driver running ageing timer. | 250 | example of driver running ageing timer. |
| 251 | 251 | ||
| @@ -112,7 +112,7 @@ take nvmem_device as parameter. · 111 unmodified lines | |||
| 112 | 5. Releasing a reference to the NVMEM | 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 | to the NVMEM it has obtained using the APIs mentioned in the above section. | 116 | to the NVMEM it has obtained using the APIs mentioned in the above section. |
| 117 | The NVMEM framework provides 2 APIs to release a reference to the NVMEM. | 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 | time_pps_create(). | 48 | time_pps_create(). |
| 49 | 49 | ||
| 50 | This implies that the source has a /dev/... entry. This assumption is | 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 | useful besides(!) the gathering of timestamps as it is the central | 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 | purpose GPIO line. In this case even basic file-related functionality | 54 | purpose GPIO line. In this case even basic file-related functionality |
| 55 | (like read() and write()) makes no sense at all and should not be a | 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 | The problem can be simply solved if you consider that a PPS source is | 58 | The problem can be simply solved if you consider that a PPS source is |
| 59 | not always connected with a GPS data source. | 59 | not always connected with a GPS data source. |
| @@ -88,13 +88,13 @@ Coding example · 28 unmodified lines | |||
| 88 | -------------- | 88 | -------------- |
| 89 | 89 | ||
| 90 | To register a PPS source into the kernel you should define a struct | 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 | static struct pps_source_info pps_ktimer_info = { | 93 | static struct pps_source_info pps_ktimer_info = { |
| 94 | .name = "ktimer", | 94 | .name = "ktimer", |
| 95 | .path = "", | 95 | .path = "", |
| 96 | .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \ | 96 | .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | |
| 97 | PPS_ECHOASSERT | \ | 97 | PPS_ECHOASSERT | |
| 98 | PPS_CANWAIT | PPS_TSFMT_TSPEC, | 98 | PPS_CANWAIT | PPS_TSFMT_TSPEC, |
| 99 | .echo = pps_ktimer_echo, | 99 | .echo = pps_ktimer_echo, |
| 100 | .owner = THIS_MODULE, | 100 | .owner = THIS_MODULE, |
| @@ -108,13 +108,13 @@ initialization routine as follows: · 7 unmodified lines | |||
| 108 | 108 | ||
| 109 | The pps_register_source() prototype is: | 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 | where "info" is a pointer to a structure that describes a particular | 113 | where "info" is a pointer to a structure that describes a particular |
| 114 | PPS source, "default_params" tells the system what the initial default | 114 | PPS source, "default_params" tells the system what the initial default |
| 115 | parameters for the device should be (it is obvious that these parameters | 115 | parameters for the device should be (it is obvious that these parameters |
| 116 | must be a subset of ones defined in the struct | 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 | Once you have registered a new PPS source into the system you can | 119 | Once you have registered a new PPS source into the system you can |
| 120 | signal an assert event (for example in the interrupt handler routine) | 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 | Every directory is the ID of a PPS sources defined in the system and | 142 | Every directory is the ID of a PPS sources defined in the system and |
| 143 | inside you find several files: | 143 | inside you find several files: |
| 144 | 144 | ||
| 145 | $ ls /sys/class/pps/pps0/ | 145 | $ ls -F /sys/class/pps/pps0/ |
| 146 | assert clear echo mode name path subsystem@ uevent | 146 | assert dev mode path subsystem@ |
| 147 | clear echo name power/ uevent | ||
| 148 | |||
| 147 | 149 | ||
| 148 | Inside each "assert" and "clear" file you can find the timestamp and a | 150 | Inside each "assert" and "clear" file you can find the timestamp and a |
| 149 | sequence number: | 151 | sequence number: |
| @@ -154,32 +156,32 @@ sequence number: · 4 unmodified lines | |||
| 154 | Where before the "#" is the timestamp in seconds; after it is the | 156 | Where before the "#" is the timestamp in seconds; after it is the |
| 155 | sequence number. Other files are: | 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 | 165 | * path: reports the PPS source's device path, that is the device the |
| 164 | PPS source is connected to (if it exists). | 166 | PPS source is connected to (if it exists). |
| 165 | 167 | ||
| 166 | 168 | ||
| 167 | Testing the PPS support | 169 | Testing the PPS support |
| 168 | ----------------------- | 170 | ----------------------- |
| 169 | 171 | ||
| 170 | In order to test the PPS support even without specific hardware you can use | 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 | and the userland tools available in your distribution's pps-tools package, | 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 | not statically compiled): | 178 | not statically compiled): |
| 177 | 179 | ||
| 178 | # modprobe ktimer | 180 | # modprobe pps-ktimer |
| 179 | 181 | ||
| 180 | and the run ppstest as follow: | 182 | and the run ppstest as follow: |
| 181 | 183 | ||
| 182 | $ ./ppstest /dev/pps0 | 184 | $ ./ppstest /dev/pps1 |
| 183 | trying PPS source "/dev/pps1" | 185 | trying PPS source "/dev/pps1" |
| 184 | found PPS source "/dev/pps1" | 186 | found PPS source "/dev/pps1" |
| 185 | ok, found 1 source(s), now start fetching data... | 187 | ok, found 1 source(s), now start fetching data... |
| @@ -187,7 +189,7 @@ and the run ppstest as follow: · 1 unmodified line | |||
| 187 | source 0 - assert 1186592700.388931295, sequence: 365 - clear 0.000000000, sequence: 0 | 189 | source 0 - assert 1186592700.388931295, sequence: 365 - clear 0.000000000, sequence: 0 |
| 188 | source 0 - assert 1186592701.389032765, sequence: 366 - clear 0.000000000, sequence: 0 | 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 | This is available in the pps-tools repository mentioned above. | 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 | %ps versatile_init | 58 | %ps versatile_init |
| 59 | %pB prev_fn_of_versatile_init+0x88/0x88 | 59 | %pB prev_fn_of_versatile_init+0x88/0x88 |
| 60 | 60 | ||
| 61 | For printing symbols and function pointers. The ``S`` and ``s`` specifiers | 61 | The ``F`` and ``f`` specifiers are for printing function pointers, |
| 62 | result in the symbol name with (``S``) or without (``s``) offsets. Where | 62 | for example, f->func, &gettimeofday. They have the same result as |
| 63 | this is used on a kernel without KALLSYMS - the symbol address is | 63 | ``S`` and ``s`` specifiers. But they do an extra conversion on |
| 64 | printed instead. | 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 | The ``B`` specifier results in the symbol name with offsets and should be | 73 | The ``B`` specifier results in the symbol name with offsets and should be |
| 67 | used when printing stack backtraces. The specifier takes into | 74 | used when printing stack backtraces. The specifier takes into |
| 68 | consideration the effect of compiler optimisations which may occur | 75 | consideration the effect of compiler optimisations which may occur |
| 69 | when tail-call``s are used and marked with the noreturn GCC attribute. | 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 | 78 | Examples:: |
| 72 | actually function descriptors which must first be resolved. The ``F`` and | 79 | |
| 73 | ``f`` specifiers perform this resolution and then provide the same | 80 | printk("Going to call: %pF\n", gettimeofday); |
| 74 | functionality as the ``S`` and ``s`` specifiers. | 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 | Kernel Pointers | 89 | Kernel Pointers |
| 77 | =============== | 90 | =============== |
| @@ -6,9 +6,6 @@ Applying Patches To The Linux Kernel · 5 unmodified lines | |||
| 6 | Original by: | 6 | Original by: |
| 7 | Jesper Juhl, August 2005 | 7 | Jesper Juhl, August 2005 |
| 8 | 8 | ||
| 9 | Last update: | ||
| 10 | 2016-09-14 | ||
| 11 | |||
| 12 | .. note:: | 9 | .. note:: |
| 13 | 10 | ||
| 14 | This document is obsolete. In most cases, rather than using ``patch`` | 11 | This document is obsolete. In most cases, rather than using ``patch`` |
| @@ -344,7 +341,7 @@ possible. · 329 unmodified lines | |||
| 344 | 341 | ||
| 345 | This is a good branch to run for people who want to help out testing | 342 | This is a good branch to run for people who want to help out testing |
| 346 | development kernels but do not want to run some of the really experimental | 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 | The -rc patches are not incremental, they apply to a base 4.x kernel, just | 346 | The -rc patches are not incremental, they apply to a base 4.x kernel, just |
| 350 | like the 4.x.y patches described above. The kernel version before the -rcN | 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 | $ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir | 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 | The -mm patches and the linux-next tree | 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 | iptables 1.4.2 iptables -V | 53 | iptables 1.4.2 iptables -V |
| 54 | openssl & libcrypto 1.0.0 openssl version | 54 | openssl & libcrypto 1.0.0 openssl version |
| 55 | bc 1.06.95 bc --version | 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 | .. [#f1] Sphinx is needed only to build the Kernel documentation | 59 | .. [#f1] Sphinx is needed only to build the Kernel documentation |
| @@ -309,18 +309,8 @@ Kernel documentation · 249 unmodified lines | |||
| 309 | Sphinx | 309 | Sphinx |
| 310 | ------ | 310 | ------ |
| 311 | 311 | ||
| 312 | The ReST markups currently used by the Documentation/ files are meant to be | 312 | Please see :ref:`sphinx_install` in ``Documentation/doc-guide/sphinx.rst`` |
| 313 | built with ``Sphinx`` version 1.2 or upper. If you're desiring to build | 313 | for details about Sphinx requirements. |
| 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 | |||
| 324 | 314 | ||
| 325 | Getting updated software | 315 | Getting updated software |
| 326 | ======================== | 316 | ======================== |
| @@ -166,12 +166,12 @@ Trees · 165 unmodified lines | |||
| 166 | - The queues of patches, for both completed versions and in progress | 166 | - The queues of patches, for both completed versions and in progress |
| 167 | versions can be found at: | 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 | - The finalized and tagged releases of all stable kernels can be found | 171 | - The finalized and tagged releases of all stable kernels can be found |
| 172 | in separate branches per version at: | 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 | Review committee | 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 | To improve tracking of who did what, especially with patches that can | 419 | To improve tracking of who did what, especially with patches that can |
| @@ -193,6 +193,39 @@ Example:: · 192 unmodified lines | |||
| 193 | for (node = rb_first(&mytree); node; node = rb_next(node)) | 193 | for (node = rb_first(&mytree); node; node = rb_next(node)) |
| 194 | printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring); | 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 | Support for Augmented rbtrees | 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 | This document has the following sections: | 17 | This document has the following sections: |
| 18 | 18 | ||
| 19 | - Key overview | 19 | .. contents:: :local: |
| 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 | ||
| 30 | 20 | ||
| 31 | 21 | ||
| 32 | Key Overview | 22 | Key Overview |
| @@ -443,7 +433,7 @@ The main syscalls are: · 410 unmodified lines | |||
| 443 | /sbin/request-key will be invoked in an attempt to obtain a key. The | 433 | /sbin/request-key will be invoked in an attempt to obtain a key. The |
| 444 | callout_info string will be passed as an argument to the program. | 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 | The keyctl syscall functions are: | 439 | The keyctl syscall functions are: |
| @@ -973,7 +963,7 @@ payload contents" for more information. · 523 unmodified lines | |||
| 973 | If successful, the key will have been attached to the default keyring for | 963 | If successful, the key will have been attached to the default keyring for |
| 974 | implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. | 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 | * To search for a key, passing auxiliary data to the upcaller, call:: | 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 | The key request service is part of the key retention service (refer to | 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 | the requesting algorithm works. | 7 | the requesting algorithm works. |
| 8 | 8 | ||
| 9 | The process starts by either the kernel requesting a service by calling | 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 | are anticipated. In particular the new format 'ecryptfs' has been defined in | 172 | are anticipated. In particular the new format 'ecryptfs' has been defined in |
| 173 | in order to use encrypted keys to mount an eCryptfs filesystem. More details | 173 | in order to use encrypted keys to mount an eCryptfs filesystem. More details |
| 174 | about the usage can be found in the file | 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 | @media screen { | 18 | @media screen { |
| 8 | 19 | ||
| 9 | /* content column | 20 | /* content column |
| @@ -56,6 +67,12 @@ · 46 unmodified lines | |||
| 56 | font-family: "Courier New", Courier, monospace | 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 | /* inline literal: drop the borderbox, padding and red color */ | 76 | /* inline literal: drop the borderbox, padding and red color */ |
| 60 | 77 | ||
| 61 | code, .rst-content tt, .rst-content code { | 78 | code, .rst-content tt, .rst-content code { |
| @@ -27,6 +27,7 @@ · 26 unmodified lines | |||
| 27 | # Please make sure this works on both python2 and python3. | 27 | # Please make sure this works on both python2 and python3. |
| 28 | # | 28 | # |
| 29 | 29 | ||
| 30 | import codecs | ||
| 30 | import os | 31 | import os |
| 31 | import subprocess | 32 | import subprocess |
| 32 | import sys | 33 | import sys |
| @@ -88,13 +89,10 @@ class KernelDocDirective(Directive): · 55 unmodified lines | |||
| 88 | try: | 89 | try: |
| 89 | env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd))) | 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 | out, err = p.communicate() | 93 | out, err = p.communicate() |
| 93 | 94 | ||
| 94 | # python2 needs conversion to unicode. | 95 | out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8') |
| 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') | ||
| 98 | 96 | ||
| 99 | if p.returncode != 0: | 97 | if p.returncode != 0: |
| 100 | sys.stderr.write(err) | 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 | key is initialized false, a 'static_branch_inc()', will change the branch to | 149 | key is initialized false, a 'static_branch_inc()', will change the branch to |
| 150 | true. And then a 'static_branch_dec()', will again make the branch false. | 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 | Where an array of keys is required, it can be defined as:: | 172 | Where an array of keys is required, it can be defined as:: |
| 153 | 173 | ||
| 154 | DEFINE_STATIC_KEY_ARRAY_TRUE(keys, count); | 174 | DEFINE_STATIC_KEY_ARRAY_TRUE(keys, count); |
| @@ -61,6 +61,7 @@ show up in /proc/sys/kernel: · 60 unmodified lines | |||
| 61 | - perf_cpu_time_max_percent | 61 | - perf_cpu_time_max_percent |
| 62 | - perf_event_paranoid | 62 | - perf_event_paranoid |
| 63 | - perf_event_max_stack | 63 | - perf_event_max_stack |
| 64 | - perf_event_mlock_kb | ||
| 64 | - perf_event_max_contexts_per_stack | 65 | - perf_event_max_contexts_per_stack |
| 65 | - pid_max | 66 | - pid_max |
| 66 | - powersave-nap [ PPC only ] | 67 | - powersave-nap [ PPC only ] |
| @@ -74,6 +75,7 @@ show up in /proc/sys/kernel: · 7 unmodified lines | |||
| 74 | - reboot-cmd [ SPARC only ] | 75 | - reboot-cmd [ SPARC only ] |
| 75 | - rtsig-max | 76 | - rtsig-max |
| 76 | - rtsig-nr | 77 | - rtsig-nr |
| 78 | - seccomp/ ==> Documentation/userspace-api/seccomp_filter.rst | ||
| 77 | - sem | 79 | - sem |
| 78 | - sem_next_id [ sysv ipc ] | 80 | - sem_next_id [ sysv ipc ] |
| 79 | - sg-big-buff [ generic SCSI device (sg) ] | 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 | users (without CAP_SYS_ADMIN). The default value is 2. | 656 | users (without CAP_SYS_ADMIN). The default value is 2. |
| 655 | 657 | ||
| 656 | -1: Allow use of (almost) all events by all users | 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 | >=1: Disallow CPU event access by users without CAP_SYS_ADMIN | 662 | >=1: Disallow CPU event access by users without CAP_SYS_ADMIN |
| 659 | >=2: Disallow kernel profiling by users without CAP_SYS_ADMIN | 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 | perf_event_max_contexts_per_stack: | 688 | perf_event_max_contexts_per_stack: |
| 677 | 689 | ||
| 678 | Controls maximum number of stack frame context entries for | 690 | Controls maximum number of stack frame context entries for |
| @@ -35,9 +35,34 @@ Table : Subdirectories in /proc/sys/net · 34 unmodified lines | |||
| 35 | bpf_jit_enable | 35 | bpf_jit_enable |
| 36 | -------------- | 36 | -------------- |
| 37 | 37 | ||
| 38 | This enables Berkeley Packet Filter Just in Time compiler. | 38 | This enables the BPF Just in Time (JIT) compiler. BPF is a flexible |
| 39 | Currently supported on x86_64 architecture, bpf_jit provides a framework | 39 | and efficient infrastructure allowing to execute bytecode at various |
| 40 | to speed packet filtering, the one used by tcpdump/libpcap for example. | 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 | Values : | 66 | Values : |
| 42 | 0 - disable the JIT (default value) | 67 | 0 - disable the JIT (default value) |
| 43 | 1 - enable the JIT | 68 | 1 - enable the JIT |
| @@ -46,9 +71,9 @@ Values : · 2 unmodified lines | |||
| 46 | bpf_jit_harden | 71 | bpf_jit_harden |
| 47 | -------------- | 72 | -------------- |
| 48 | 73 | ||
| 49 | This enables hardening for the Berkeley Packet Filter Just in Time compiler. | 74 | This enables hardening for the BPF JIT compiler. Supported are eBPF |
| 50 | Supported are eBPF JIT backends. Enabling hardening trades off performance, | 75 | JIT backends. Enabling hardening trades off performance, but can |
| 51 | but can mitigate JIT spraying. | 76 | mitigate JIT spraying. |
| 52 | Values : | 77 | Values : |
| 53 | 0 - disable JIT hardening (default value) | 78 | 0 - disable JIT hardening (default value) |
| 54 | 1 - enable JIT hardening for unprivileged users only | 79 | 1 - enable JIT hardening for unprivileged users only |
| @@ -57,11 +82,11 @@ Values : · 2 unmodified lines | |||
| 57 | bpf_jit_kallsyms | 82 | bpf_jit_kallsyms |
| 58 | ---------------- | 83 | ---------------- |
| 59 | 84 | ||
| 60 | When Berkeley Packet Filter Just in Time compiler is enabled, then compiled | 85 | When BPF JIT compiler is enabled, then compiled images are unknown |
| 61 | images are unknown addresses to the kernel, meaning they neither show up in | 86 | addresses to the kernel, meaning they neither show up in traces nor |
| 62 | traces nor in /proc/kallsyms. This enables export of these addresses, which | 87 | in /proc/kallsyms. This enables export of these addresses, which can |
| 63 | can be used for debugging/tracing. If bpf_jit_harden is enabled, this feature | 88 | be used for debugging/tracing. If bpf_jit_harden is enabled, this |
| 64 | is disabled. | 89 | feature is disabled. |
| 65 | Values : | 90 | Values : |
| 66 | 0 - disable JIT kallsyms export (default value) | 91 | 0 - disable JIT kallsyms export (default value) |
| 67 | 1 - enable JIT kallsyms export for privileged users only | 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 | numa_zonelist_order | 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 | 'where the memory is allocated from' is controlled by zonelists. | 578 | 'where the memory is allocated from' is controlled by zonelists. |
| 577 | (This documentation ignores ZONE_HIGHMEM/ZONE_DMA32 for simple explanation. | 579 | (This documentation ignores ZONE_HIGHMEM/ZONE_DMA32 for simple explanation. |
| 578 | you may be able to read ZONE_DMA as ZONE_DMA32...) | 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 | $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link | 83 | $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link |
| 84 | 84 | ||
| 85 | For examples on how to use stm_source interface in the kernel, refer | 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 | Each stm_source device will need to assume a master and a range of | 88 | Each stm_source device will need to assume a master and a range of |
| 89 | channels, depending on how many channels it requires. These are | 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 | beginning of this text on how to do that). When initialized, it will | 107 | beginning of this text on how to do that). When initialized, it will |
| 108 | consume one channel. | 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 | [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf | 121 | [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf |
| 111 | [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html | 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 | 즉, ACQUIRE 는 최소한의 "취득" 동작처럼, 그리고 RELEASE 는 최소한의 "공개" | 523 | 즉, ACQUIRE 는 최소한의 "취득" 동작처럼, 그리고 RELEASE 는 최소한의 "공개" |
| 524 | 처럼 동작한다는 의미입니다. | 524 | 처럼 동작한다는 의미입니다. |
| 525 | 525 | ||
| 526 | core-api/atomic_ops.rst 에서 설명되는 어토믹 오퍼레이션들 중에는 완전히 | 526 | atomic_t.txt 에 설명된 어토믹 오퍼레이션들 중 일부는 완전히 순서잡힌 것들과 |
| 527 | 순서잡힌 것들과 (배리어를 사용하지 않는) 완화된 순서의 것들 외에 ACQUIRE 와 | 527 | (배리어를 사용하지 않는) 완화된 순서의 것들 외에 ACQUIRE 와 RELEASE 부류의 |
| 528 | RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수행하는 조합된 어토믹 | 528 | 것들도 존재합니다. 로드와 스토어를 모두 수행하는 조합된 어토믹 오퍼레이션에서, |
| 529 | 오퍼레이션에서, ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 는 | 529 | ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 는 해당 |
| 530 | 해당 오퍼레이션의 스토어 부분에만 적용됩니다. | 530 | 오퍼레이션의 스토어 부분에만 적용됩니다. |
| 531 | 531 | ||
| 532 | 메모리 배리어들은 두 CPU 간, 또는 CPU 와 디바이스 간에 상호작용의 가능성이 있을 | 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 | CPU 1 CPU 2 | 637 | CPU 1 CPU 2 |
| 623 | =============== =============== | 638 | =============== =============== |
| @@ -626,28 +641,19 @@ RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수 · 2 unmodified lines | |||
| 626 | <쓰기 배리어> | 641 | <쓰기 배리어> |
| 627 | WRITE_ONCE(P, &B); | 642 | WRITE_ONCE(P, &B); |
| 628 | Q = READ_ONCE(P); | 643 | Q = READ_ONCE(P); |
| 629 | <데이터 의존성 배리어> | 644 | WRITE_ONCE(*Q, 5); |
| 630 | *Q = 5; | ||
| 631 | 645 | ||
| 632 | 이 데이터 의존성 배리어는 Q 로의 읽기가 *Q 로의 스토어와 순서를 맞추게 | 646 | 따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 데이터 종속성 배리어가 필요치 |
| 633 | 해줍니다. 이는 다음과 같은 결과를 막습니다: | 647 | 않습니다. 달리 말하면, 데이터 종속성 배리어가 없더라도 다음 결과는 생기지 |
| 648 | 않습니다: | ||
| 634 | 649 | ||
| 635 | (Q == &B) && (B == 4) | 650 | (Q == &B) && (B == 4) |
| 636 | 651 | ||
| 637 | 이런 패턴은 드물게 사용되어야 함을 알아 두시기 바랍니다. 무엇보다도, 의존성 | 652 | 이런 패턴은 드물게 사용되어야 함을 알아 두시기 바랍니다. 무엇보다도, 의존성 |
| 638 | 순서 규칙의 의도는 쓰기 작업을 -예방- 해서 그로 인해 발생하는 비싼 캐시 미스도 | 653 | 순서 규칙의 의도는 쓰기 작업을 -예방- 해서 그로 인해 발생하는 비싼 캐시 미스도 |
| 639 | 없애려는 것입니다. 이 패턴은 드물게 발생하는 에러 조건 같은것들을 기록하는데 | 654 | 없애려는 것입니다. 이 패턴은 드물게 발생하는 에러 조건 같은것들을 기록하는데 |
| 640 | 사용될 수 있고, 이렇게 배리어를 사용해 순서를 지키게 함으로써 그런 기록이 | 655 | 사용될 수 있으며, CPU의 자연적인 순서 보장이 그런 기록들을 사라지지 않게 |
| 641 | 사라지는 것을 막습니다. | 656 | 해줍니다. |
| 642 | |||
| 643 | |||
| 644 | [!] 상당히 비직관적인 이 상황은 분리된 캐시를 가진 기계, 예를 들어 한 캐시 | ||
| 645 | 뱅크가 짝수번 캐시 라인을 처리하고 다른 뱅크는 홀수번 캐시 라인을 처리하는 기계 | ||
| 646 | 등에서 가장 잘 발생합니다. 포인터 P 는 홀수 번호의 캐시 라인에 있고, 변수 B 는 | ||
| 647 | 짝수 번호 캐시 라인에 있다고 생각해 봅시다. 그런 상태에서 읽기 작업을 하는 CPU | ||
| 648 | 의 짝수번 뱅크는 할 일이 쌓여 매우 바쁘지만 홀수번 뱅크는 할 일이 없어 아무 | ||
| 649 | 일도 하지 않고 있었다면, 포인터 P 는 새 값 (&B) 을, 그리고 변수 B 는 옛날 값 | ||
| 650 | (2) 을 가지고 있는 상태가 보여질 수도 있습니다. | ||
| 651 | 657 | ||
| 652 | 658 | ||
| 653 | 데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. | 659 | 데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. |
| @@ -1848,8 +1854,7 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 · 1194 unmodified lines | |||
| 1848 | 이 코드는 객체의 업데이트된 death 마크가 레퍼런스 카운터 감소 동작 | 1854 | 이 코드는 객체의 업데이트된 death 마크가 레퍼런스 카운터 감소 동작 |
| 1849 | *전에* 보일 것을 보장합니다. | 1855 | *전에* 보일 것을 보장합니다. |
| 1850 | 1856 | ||
| 1851 | 더 많은 정보를 위해선 Documentation/core-api/atomic_ops.rst 문서를 참고하세요. | 1857 | 더 많은 정보를 위해선 Documentation/atomic_{t,bitops}.txt 문서를 |
| 1852 | 어디서 이것들을 사용해야 할지 궁금하다면 "어토믹 오퍼레이션" 서브섹션을 | ||
| 1853 | 참고하세요. | 1858 | 참고하세요. |
| 1854 | 1859 | ||
| 1855 | 1860 | ||
| @@ -1956,10 +1961,7 @@ MMIO 쓰기 배리어 · 100 unmodified lines | |||
| 1956 | 뒤에 완료됩니다. | 1961 | 뒤에 완료됩니다. |
| 1957 | 1962 | ||
| 1958 | ACQUIRE 앞에서 요청된 메모리 오퍼레이션은 ACQUIRE 오퍼레이션이 완료된 후에 | 1963 | ACQUIRE 앞에서 요청된 메모리 오퍼레이션은 ACQUIRE 오퍼레이션이 완료된 후에 |
| 1959 | 완료될 수 있습니다. smp_mb__before_spinlock() 뒤에 ACQUIRE 가 실행되는 | 1964 | 완료될 수 있습니다. |
| 1960 | 코드 블록은 블록 앞의 스토어를 블록 뒤의 로드와 스토어에 대해 순서 | ||
| 1961 | 맞춥니다. 이건 smp_mb() 보다 완화된 것임을 기억하세요! 많은 아키텍쳐에서 | ||
| 1962 | smp_mb__before_spinlock() 은 사실 아무일도 하지 않습니다. | ||
| 1963 | 1965 | ||
| 1964 | (2) RELEASE 오퍼레이션의 영향: | 1966 | (2) RELEASE 오퍼레이션의 영향: |
| 1965 | 1967 | ||
| @@ -2471,86 +2473,7 @@ _않습니다_. · 505 unmodified lines | |||
| 2471 | 전체 메모리 배리어를 내포하고 또 일부는 내포하지 않지만, 커널에서 상당히 | 2473 | 전체 메모리 배리어를 내포하고 또 일부는 내포하지 않지만, 커널에서 상당히 |
| 2472 | 의존적으로 사용하는 기능 중 하나입니다. | 2474 | 의존적으로 사용하는 기능 중 하나입니다. |
| 2473 | 2475 | ||
| 2474 | 메모리의 어떤 상태를 수정하고 해당 상태에 대한 (예전의 또는 최신의) 정보를 | 2476 | 더 많은 내용을 위해선 Documentation/atomic_t.txt 를 참고하세요. |
| 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 를 참고하세요. | ||
| 2554 | 2477 | ||
| 2555 | 2478 | ||
| 2556 | 디바이스 액세스 | 2479 | 디바이스 액세스 |
| @@ -149,9 +149,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 · 148 unmodified lines | |||
| 149 | 核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册 | 149 | 核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册 |
| 150 | 页等不同格式的文档： | 150 | 页等不同格式的文档： |
| 151 | make pdfdocs | 151 | make pdfdocs |
| 152 | make psdocs | ||
| 153 | make htmldocs | 152 | make htmldocs |
| 154 | make mandocs | ||
| 155 | 153 | ||
| 156 | 154 | ||
| 157 | 如何成为内核开发者 | 155 | 如何成为内核开发者 |
| @@ -87,11 +87,16 @@ Return values · 86 unmodified lines | |||
| 87 | A seccomp filter may return any of the following values. If multiple | 87 | A seccomp filter may return any of the following values. If multiple |
| 88 | filters exist, the return value for the evaluation of a given system | 88 | filters exist, the return value for the evaluation of a given system |
| 89 | call will always use the highest precedent value. (For example, | 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 | In precedence order, they are: | 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 | Results in the task exiting immediately without executing the | 100 | Results in the task exiting immediately without executing the |
| 96 | system call. The exit status of the task (``status & 0x7f``) will | 101 | system call. The exit status of the task (``status & 0x7f``) will |
| 97 | be ``SIGSYS``, not ``SIGKILL``. | 102 | be ``SIGSYS``, not ``SIGKILL``. |
| @@ -141,6 +146,15 @@ In precedence order, they are: · 43 unmodified lines | |||
| 141 | allow use of ptrace, even of other sandboxed processes, without | 146 | allow use of ptrace, even of other sandboxed processes, without |
| 142 | extreme care; ptracers can use this mechanism to escape.) | 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 | ``SECCOMP_RET_ALLOW``: | 158 | ``SECCOMP_RET_ALLOW``: |
| 145 | Results in the system call being executed. | 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 | and a more generic example of a higher level macro interface for BPF | 183 | and a more generic example of a higher level macro interface for BPF |
| 170 | program generation. | 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 | Adding architecture support | 222 | Adding architecture support |
| 175 | =========================== | 223 | =========================== |
| @@ -83,6 +83,11 @@ Groups: · 82 unmodified lines | |||
| 83 | 83 | ||
| 84 | Bits for undefined preemption levels are RAZ/WI. | 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 | For historical reasons and to provide ABI compatibility with userspace we | 91 | For historical reasons and to provide ABI compatibility with userspace we |
| 87 | export the GICC_PMR register in the format of the GICH_VMCR.VMPriMask | 92 | export the GICC_PMR register in the format of the GICH_VMCR.VMPriMask |
| 88 | field in the lower 5 bits of a word, meaning that userspace must always | 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 | 3.1. ATTRIBUTE: KVM_S390_VM_TOD_HIGH | 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 | Parameters: address of a buffer in user space to store the data (u8) to | 182 | Parameters: address of a buffer in user space to store the data (u8) to |
| 182 | Returns: -EFAULT if the given address is not accessible from kernel space | 183 | Returns: -EFAULT if the given address is not accessible from kernel space |
| @@ -190,6 +191,17 @@ the POP (u64). · 7 unmodified lines | |||
| 190 | Parameters: address of a buffer in user space to store the data (u64) to | 191 | Parameters: address of a buffer in user space to store the data (u64) to |
| 191 | Returns: -EFAULT if the given address is not accessible from kernel space | 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 | 4. GROUP: KVM_S390_VM_CRYPTO | 205 | 4. GROUP: KVM_S390_VM_CRYPTO |
| 194 | Architectures: s390 | 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.